R44 prometheus surface 11 — additive vs in-place rename (snowflake-mcp v22.0.4)
Decision
For Bible v19.1.8 R44 surface 11 (prometheus *_info gauge labels), adopt ADDITIVELY: emit framework=“Bible-v19.1.8” (R44 spec format), bible=“v19.1.8” (legacy v22.0.3-era consumer compat), and runtime=“fastmcp-3.0” (renamed from old framework=fastmcp-3.0 to free that label for the Bible value). Three label changes total, zero information lost, zero consumer breakage.
Rationale
Bible R44 verification (cascade-check.sh) literally greps for framework=“Bible-vX.Y.Z”. Snowflake-mcp v22.0.3 was emitting framework=“fastmcp-3.0” + bible=“v19.1.7” — two labels carrying separate info. In-place rename would break any Grafana dashboard parsing the v22.0.3 scheme. The chosen middle path: rename framework=fastmcp-3.0 to runtime=fastmcp-3.0 (preserves runtime visibility under new label name), then put Bible-vX.Y.Z in the now-free framework= slot, AND keep bible= for backward compat. Net: all three pieces of info accessible, R44 cascade-check passes, no consumer loses access.
Alternatives Rejected
REJECTED: in-place rename bible= to framework=“Bible-…” (breaks any consumer of bible=). REJECTED: keep two labels and propose Bible v19.1.9 to accept either form (defers compliance, requires upstream PR review cycle, leaves snowflake out-of-spec until merged). REJECTED: emit only framework=“Bible-…” and drop runtime info (loses fastmcp version visibility for ops monitoring).
Outcome
Pending