docs: rule 4's scoped exception for a recorder in one process (#421) - #434
Merged
Conversation
`TraceTap._record` raises on a topic or payload field the inventory does not name, which SYSTEM.md rule 4 forbids of a consumer. The strictness is deliberate — `trace.py` has always said a stray field must break a test rather than rot quietly — but it was an exception the module claimed for itself and the rule did not grant. Ruled: the tap stays strict, and rule 4 says where strictness is allowed rather than being weakened. The rule exists because anything at all can publish on a shared bus. An instrument reading a bus inside one process has no such publishers: everything on it is our own code, a payload outside the inventory there is our own bug, and failing on it is an assertion rather than a fault. The tap runs in `bench` and in the suite and nowhere else. The limit is stated with it, because it is the half that will matter later: a recorder that watches a broker may not fail loudly and must record what it can. The #390 audit read this as a crash surface opening the day the bridge went; it does not, because nothing attaches the tap to a broker. The day something does, the exception is gone with it. No code changes. The behaviour was already what was ruled; what was missing was the rule saying so. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NNNTTEXDua7ZG2M7fvTLjk
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.
Closes #421
The trace tap raises on a payload outside the inventory, which rule 4 forbids
of a consumer. Ruled in conversation: the tap stays strict, and rule 4
gains the boundary rather than losing its force.
The second half is the part that will matter later. The #390 audit read this as
a crash surface that opens the day the bridge goes; it does not, because
TraceTapis constructed only inbench/runner.pyand the suite, always on anin-process bus. The day anything attaches a tap to the broker, the reason for
the exception is gone and the rule binds it like every other consumer.
No code changes — the tap already behaves as ruled. What was missing was
the rule saying so, and
trace.py's docstring claiming an exception nothinggranted.
🤖 Generated with Claude Code
https://claude.ai/code/session_01NNNTTEXDua7ZG2M7fvTLjk