Fivetran MCP Bible v19.1.5 → v19.1.7 shipped as framework-label-cascad…
Decision
Fivetran MCP Bible v19.1.5 → v19.1.7 shipped as framework-label-cascade-only (no code/stack/auth/tool-inventory changes) + addition of 4-test R24 runtime-lint pytest covering Bible 09 Check 12.3.1. Server version preserved at 19.1.1 per R13 two-scale independence.
Rationale
Scope analysis via mcp-server-development skill showed R24 code already landed at Fivetran v19.1.5 (commit 59819bb), predating Bible canonization. v19.1.6 was mostly doc-level formalization (Pattern 5 identity probe + Pattern 6 env-baseline + explicit Redis Triad-Trigger enforcement) — all of which Fivetran already met since v19.1.2/v19.1.3. Therefore zero implementation delta existed; only docstring/label cascade + test suite addition was needed. 3-way drift was ALREADY present pre-upgrade (com.fivetran.bible=v19.1.3, /health=v19.1.5, contract=v19.1.5, Bible canon=v19.1.7) — a Pristine-Sweep-7 R13 failure. Closing that drift in-session was strictly net-positive. Verification: 37/37 guardrail tests pass (incl. 4 new R24 tests) in-container; live /health reports “Bible v19.1.7”; live identity probe get_account_info returns Runwal_Enterprises; .env sha256 f349b915… invariant through all phases; tool count 177 unchanged; 177/177 carry outputSchema. Rollback image fivetran-mcp-fivetran-mcp:v19.1.1-pre-bible-v19.1.7 preserved. Softspot identified via premortem: I inferred v19.1.6 scope from Salesforce changelog rather than re-reading Bible 09_VERIFICATION_PROTOCOL.md directly — acceptable risk given upstream-sync-2026-04-23 (2d old) and no delta observed, but violates “Bible first” Operating Rule #1 technically.
Alternatives Rejected
Outcome
Pending