Skip to content

docs: rule 4's scoped exception for a recorder in one process (#421) - #434

Merged
iot49 merged 1 commit into
mainfrom
trace-tap/rule-4-exception
Sep 5, 2026
Merged

docs: rule 4's scoped exception for a recorder in one process (#421)#434
iot49 merged 1 commit into
mainfrom
trace-tap/rule-4-exception

Conversation

@iot49

@iot49 iot49 commented Sep 5, 2026

Copy link
Copy Markdown
Collaborator

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.

A recorder on a bus where every publisher is in the same process may fail
loudly — that is an assertion about our own code. One that watches a broker
may not, and must record what it can.

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
TraceTap is constructed only in bench/runner.py and the suite, always on an
in-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 nothing
granted.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NNNTTEXDua7ZG2M7fvTLjk

`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
@iot49
iot49 merged commit 9e79384 into main Sep 5, 2026
1 check passed
@iot49
iot49 deleted the trace-tap/rule-4-exception branch September 5, 2026 06:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

lib: the trace tap raises on a payload it cannot parse

1 participant