Pin the telltale wire contract (consumer side) - #66
Merged
Conversation
telltale declares this payload in src/read.ts as TelltaleIssueDTO / IssuesResponse; this repo declares it again in feedback.ts as TelltaleIssue / FeedbackIssuesResponse. They agree today, field for field. Nothing made them keep agreeing - either side could add, rename or drop a field with both suites green and the wire broken. That is finding 2 of the 2026-08-31 integration audit. The contract JSON is vendored byte-for-byte from NEXUS docs/contracts/, where the mechanism is documented; telltale vendors the same file and pins the same hash. Moving the contract for one side leaves the OTHER side's constant stale and red, which is what forces a wire change to be read by both. Two independent checks, deliberately not one: - runtime: the contract's canonical SHA-256 still matches, and TelltaleIssue's key set equals the contract's exactly - an added field fails as loudly as a removed one. - compile time: Record<keyof TelltaleIssue, true> makes tsc fail if the interface gains or loses a field, so `npm run check` catches drift even before the suite runs. Hashing is over the canonical JSON, not raw bytes, so a CRLF checkout does not produce a spurious failure. Both halves were proved to fail before being kept, per the rule that a verification which cannot fail is not verification: contract gains a `severity` field -> 2 of 5 tests red (hash + key set) test declares a field the interface lacks -> tsc 1 ERROR reverted -> 22 files / 159 tests green, check 357 files 0 errors Suite went 154 -> 159. No existing test changed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
telltaledeclares this payload insrc/read.ts(TelltaleIssueDTO/IssuesResponse); this repo declares it again infeedback.ts(TelltaleIssue/FeedbackIssuesResponse). They agree today, field for field — and nothing made them keep agreeing. Either side could add, rename or drop a field with both suites green and the wire broken. That is finding 2 of the 2026-08-31 integration audit, and the gapSYSTEM-TEST-PLAN.mdrecords as "no contract test between any two stages."Mechanism
The contract JSON is vendored byte-for-byte from NEXUS
docs/contracts/, where it is documented.telltalevendors the same file and pins the same hash. Moving the contract for one side leaves the other side's constant stale and red — that duplication is the mechanism, not redundancy. A shared package would give the same guarantee only if both sides upgraded, and nothing forces an upgrade.Two independent checks, deliberately not one:
TelltaleIssue's key set ≠ contract's, exactly — an added field fails as loudly as a removed onenpm run check)Record<keyof TelltaleIssue, true>makestscfail if the interface gains or loses a field, before the suite even runsHashing is over the canonical JSON, not raw bytes — a byte hash would fail spuriously the first time someone checks the file out with CRLF.
Proved to fail before being kept
A verification that cannot fail is not verification, so both halves were driven red on purpose:
Suite went 154 → 159. No existing test changed.
Scope
Consumer side only. The producer-side twin in
telltaleis written but not yet opened — that repo had an active working session in it at the time.🤖 Generated with Claude Code