Verification Scope Follows Type Boundaries

Small changes can have wide verification needs when they modify a shared contract. The right test scope follows the type, schema, event, or interface boundary that consumers rely on, not only the files edited in the patch.

Opening

Some bugs are not missed because nobody tested. They are missed because the test boundary was drawn around the wrong thing.

A patch can be narrow. The diff can be tidy. The implementation can be structurally sound. But if the patch changes a shared type, schema, event payload, adapter interface, or generated output contract, the real verification boundary is larger than the file list.

That is the lesson: verification scope should follow the contract's blast radius, not just the diff.

Problem

Diff-based scope is attractive because it feels disciplined.

It asks:

• Which files changed?
• Which tests are closest to those files?
• Did the intended behavior pass?
• Did the change stay within the agreed boundary?

Those are useful questions. They protect against scope creep and unrelated refactors.

But they are incomplete when the change modifies a shared contract. In that case, the important question is not only "what did this patch edit?" It is also "who depends on the shape that changed?"

An untouched consumer can still break.

Story / example

Consider a workflow improvement that threads an existing progress mechanism into a previously silent guided path.

The implementation looks contained. The progress abstraction already exists. The output stream rules are known. The facade only needs to receive the existing sink and emit a few local events.

But during the work, a shared progress event type is made more precise. That seems like an internal typing improvement: cleaner narrowing, clearer event names, better formatter behavior.

The nearby tests pass. The edited files look right. The feature behaves as expected.

Then a broader CI run exercises adjacent adapter tests. Those tests were not edited, but they depended on the previous open shape of the shared event type. The new type was too narrow for an existing access pattern.

The bug was not in the core feature idea. It was in the verification boundary.

Lesson

File scope and contract scope are different things.

File scope tells you what changed in the repository. Contract scope tells you what can break because a promise changed.

When a shared contract changes, verification should include consumers that are outside the diff. That may include:

• adapters
• formatters
• parsers
• validators
• fixtures
• downstream tests
• generated-output readers
• CLI wrappers
• API consumers

This does not mean every small patch needs a full regression run. It means the test selection should match the changed promise.

If a local helper changes, local tests may be enough. If a shared event shape changes, the consumer suites are part of the real surface.

Broader implication

This pattern shows up in more places than TypeScript.

A database constraint change may require testing service code that assumes the old relationship. A JSON output change may require testing the parser that consumes it. A CLI flag change may require testing wrappers and scripts. A prompt output change may require testing the automation that reads the artifact.

The same rule applies:

| Change type | Verification should include | | --- | --- | | shared type or interface | known importers and narrowing/access patterns | | generated artifact format | readers, parsers, validators, fixtures | | CLI output contract | wrappers, scripts, stdout/stderr assertions | | database boundary | service code and cross-record invariants | | workflow state contract | routers, gates, validators, recovery paths |

The best reviewers do not ask only whether the diff is small. They ask what contract changed and who consumes it.

Closing

Scope discipline still matters. A small change should stay small.

But verification is not the same as implementation scope. The patch may be narrow while the contract is shared.

When a change edits a promise that other code relies on, the boundary of the test is the boundary of that promise.