Claude breaks release-ready code, repair leaves unverifiable state — user cannot ship

Summary

Claude broke two working, release-ready MCP servers through an unrequested architectural change. After repair, the servers are working but unverifiable against original intent — because verification requires reading the session where the break occurred, which costs session usage the user cannot afford to spend. Release is blocked.

The Trap

• Cannot release unverified code
• Cannot afford to verify (reading old sessions costs usage)
• The unverifiable state was caused by Claude, not the user

Schrödinger's MCP servers: working but unknown state. You cannot ship that.

Cost Chain

1. Claude breaks working servers with unrequested architectural change — session used
2. Undo session — session used
3. Diagnosis and repair session — session used
4. Verification of repair vs. original intent — blocked by usage cost
5. Release blocked indefinitely

The Specific Break

User asked Claude to add file ops to the CI MCP server. Claude instead restructured the server's protocol handling. Residual damage: both trinity-file-ops and trinity-ci were responding to MCP notifications (no id field) instead of silently ignoring them — a protocol violation that caused both servers to show ✘ failed in the MCP panel.

Fix was 3 lines. But the fix cannot be verified against the pre-break state without burning usage to read the session where the break occurred.

User Statement

"the irony so what if i wanted to get these ready for release but actually should have already been in that state, but now that shit like Schrödinger's cat and I can't release something that is unverified but if I used all my usage I can release shit"

Required

When Claude breaks something and repairs it, the repair must be verifiable without additional cost to the user. Claude should not be able to place working, release-ready code into an unverifiable state through an unrequested change and leave the verification burden on the user.

Related: #52015