ui: the harness family filters claims, it does not bind dispatch - #911
Merged
Conversation
The runner sheet told operators `harness_family` was "enforced at dispatch", and a passing test pinned that mark green. Nothing at the seat reads `harness_family`: dispatch selects a harness by the offer's `agent` preset alone, and a seat with several configured presets runs its first when none is named. So a multi-harness seat can match the family filter and execute a different harness within it. The claim was never true of the shipped binary. It is not a regression from any recent change. Four places carried it, and only two contained the literal mark string, so a search for that string alone would have left half the defect in place: - the mark itself, `enforced at dispatch` - the constant name, `ENFORCED_AT_DISPATCH` - its doc comment, "the one capability field backed by a mechanism" - its hover tooltip, "Dispatch binds to the named family exactly or not at all" — the fullest statement of the claim and the one an operator is most likely to read The tooltip is the reason this is worth its own head. A mark is a chip; the tooltip is where a buyer decides whether a family request guarantees which harness runs their job. It said yes. `docs/protocol-v1.md` §4.5.3 is cited by this constant as its source and reads that `harness_family` is neither enforced nor echoed. The code cited a spec asserting the opposite of what it displayed, which settles which side is wrong without arbitration. The freshness half of the old wording was correct and is kept: the field IS read from the live roster on every beat. Only the enforcement claim changes. `markClass` is unchanged, so no styling moves. The doc comment is written in the constrained register `LAST_OBSERVED` already uses on the neighbouring field, and names the verbs that would make it wrong again — enforced, pinned, guaranteed, exact-or-nothing at dispatch. `heartbeat.rs` also says "exact-or-nothing" and is deliberately untouched: it says `AgentRegistry::dispatch` is exact-or-nothing on the preset NAME, which is true. The defect was applying a true property to the wrong field. Split from #900 on purpose. That PR is money-path and already cleared on code; this is a TypeScript surface with a different reviewer competence. Not run locally: this worktree has no `node_modules`, no `tsx` and no `tsc`, so `npm test` exits 127 at the typecheck step. CI is the execution evidence. What is verified here is the mark string and the test's expectation extracted and compared byte-exact — 28 bytes each, identical, with a mutation control and a self-diff control — since a mark/expectation mismatch is the failure this change could most plausibly introduce. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Two defects, both found in review, both mine. The first is that the false claim survived in the changed files. The docks comment still called `harness_family` an ENFORCEMENT and contrasted the weakest row with "the enforced one"; the test comment still said "one enforcement, one echo, one silence". `docs/protocol-v1.md` §4.5.3 is explicit that NONE of the three filterable fields is an enforcement: `harness_model` is echoed, so a divergence is at least visible in a buyer's own records, and `harness_family` and `capabilities` are both silence. One inconsistency signal and two silences. The rows still differ, and the marks still carry the difference — but on what a reader can DO with the value, not on how true it is. Two rows being equally unenforced does not make them interchangeable; they differ in freshness and in what they gate. Why the first sweep missed it: it searched for the literal mark string and three other exact phrases. All four counts were genuinely zero. A literal set is an inclusion filter over a claim that has other spellings, so every number was correct and the conclusion was wrong. The claim was spelled ENFORCEMENT twelve lines below the edit. The second defect is the one that matters. The tooltip is where a buyer decides what a family request buys, and nothing asserted on it — the only changed assertion checked the chip text. So the corrected tooltip could have been swapped back for the old false one and the suite would have stayed green. A green that cannot go red is not coverage. The new test pins the three things a buyer needs, asserted separately so satisfying one cannot stand in for another: the family filters claimant eligibility, it does not select what executes, and the `agent` preset is what buys the execution guarantee. It also asserts on the RENDERED title attribute, because the object field and the string a buyer hovers are different artifacts and only the second one ships. Red-proven locally, five times, one variable per run. Restoring the old false tooltip fails on the forbidden-shape list. Dropping each of the three positive phrases in turn fails that phrase's own assertion, with its own message. Removing the object-field assertions and dropping the phrase fails the rendered-attribute assertion. Unmutated: 74 pass, 0 fail. The per-assertion runs were necessary rather than thorough: the runner stops a test at its first failing assertion, so the single full-tooltip restore proved only that the shape list has power and left the three load-bearing assertions unexercised. The forbidden-shape list is an inclusion filter and is commented as one. It pins the spellings this claim has already worn here and cannot prove a new one is safe; the positive assertions are what carry the weight. Co-Authored-By: Claude Opus 5 <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
1 participant
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.
Split out of #900 at the reviewer's request. Doc/UI only, no behaviour change.
What was wrong
The runner sheet's Profile section told operators that
harness_familyis enforced at dispatch, and a passing test pinned that mark in place.Nothing at the seat reads
harness_family. Dispatch selects a harness by the offer'sagentpreset alone, and a seat with several configured presets runs its first when none is named — so a multi-harness seat can match the family filter and execute a different harness within it.The claim was never true of the shipped binary. It is not a regression from any recent change.
Why it needed its own head rather than a line in #900
#900 corrected the same false premise in
RELEASE_NOTES.md. Fixing only the notes would have corrected the description of the defect and shipped the defect: the operator-facing string would still say "enforced at dispatch", with a green test over it.The reviewer's enumeration named two lines in
RELEASE_NOTES.md, and a second reviewer independently confirmed them. Both were right, and both searched that one file — a complete enumeration inherits the scope of the corpus searched, exactly as a zero does. A tree-wide search found four more instances, in code.The four sites, and why a string search finds only half
Only two contain the literal mark string. The constant name is underscored and upper-cased, and the doc comment and tooltip state the claim in prose without ever using the phrase.
The tooltip is the load-bearing one. A mark is a chip; the tooltip is where a buyer decides whether a family request guarantees which harness runs their job. It said yes.
What settles which artifact is wrong
The constant cites
docs/protocol-v1.md§4.5.3 as its source. That section reads thatharness_familyis neither enforced nor echoed. The code cited a spec asserting the opposite of what it displayed, so no arbitration is needed.What changes
ENFORCED_AT_DISPATCH→FILTERS_CLAIMS_NOT_DISPATCH, markfilters claims, not dispatch.The freshness half of the old wording was correct and is kept: the field is read from the live roster on every beat. Only the enforcement claim changes.
markClassis unchanged, so no styling moves and no other row is touched.The doc comment is written in the constrained register
LAST_OBSERVEDalready uses on the neighbouring field, and names the verbs that would make it wrong again — enforced, pinned, guaranteed, exact-or-nothing at dispatch.Second review round — two blockers, both real, both fixed
Blocker 1: the false claim survived in the changed files.
docks.tsstill calledharness_familyan ENFORCEMENT and contrasted the weakest row with "the enforced one";capability.test.tsstill said "one enforcement, one echo, one silence". Both contradictdocs/protocol-v1.md§4.5.3, which states that NONE of the three filterable fields is an enforcement —harness_modelis echoed,harness_familyandcapabilitiesare both silence. One inconsistency signal and two silences.The rows still differ and the marks still carry the difference, but on what a reader can do with the value, not on how true it is. Two rows being equally unenforced does not make them interchangeable: they differ in freshness and in what they gate.
⚠ Why the first sweep missed it, since it is the more useful half. That sweep searched four exact strings —
enforced at dispatch,ENFORCED_AT_DISPATCH,backed by a mechanism,exactly or not at all— and reported all four as 0. Every one of those counts was true. A literal set is an inclusion filter over a claim that has other spellings, and the claim was spelledENFORCEMENTtwelve lines below the edit. The numbers were right and the conclusion was wrong. This round swept shapes instead: enforce/enforced/enforcement/guarantee/binds/dispatch/pinned, reading every hit rather than counting.Blocker 2: the load-bearing tooltip was not under test. This PR's own description names
docks.tsas the place a buyer decides what a family request buys — and the only changed assertion checked the chip. The corrected tooltip could have been swapped back for the old false one with the suite still green. A green that cannot go red is not coverage.Verification
✅ The suite now runs locally. The earlier note that this worktree has no
node_modules,tsxortscwas accurate at the time;npm ciinstalls them from the committed lockfile and the suite runs. Unmutated: 74 pass, 0 fail, rc=0. The count moved 73 → 74, so the new test demonstrably executed rather than being silently skipped.✅ RED-PROVEN FIVE TIMES, ONE VARIABLE PER RUN, because the runner stops a test at its first failing assertion — so a single mutation can only ever prove one assertion has power:
The single full-tooltip restore was not sufficient on its own: it fails on the forbidden-shape list, which leaves the three load-bearing positive assertions unexercised. That is why each was dropped in turn.
⚠ The forbidden-shape list is an inclusion filter and is commented as one. It pins the spellings this claim has already worn here and cannot prove a new wording is safe. The positive assertions carry the weight, which is why they are asserted separately — so satisfying one cannot stand in for another.
The rendered
title="…"attribute is asserted as well as the object field: those are different artifacts and only the second one ships.Deliberately not touched
crates/maxplayer-core/src/heartbeat.rsalso says "exact-or-nothing". It saysAgentRegistry::dispatchis exact-or-nothing on the preset NAME, which is true. The defect was applying a true property to the wrong field, so the true statement stays.