From 16383639fc13234c5234bb26290cfe591061bece Mon Sep 17 00:00:00 2001 From: orveth Date: Tue, 25 Aug 2026 13:57:45 -0700 Subject: [PATCH 1/2] ui: the harness family filters claims, it does not bind dispatch MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- web/app/src/ui/docks.ts | 19 +++++++++++++------ web/app/test/capability.test.ts | 2 +- 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/web/app/src/ui/docks.ts b/web/app/src/ui/docks.ts index 3b7565205..9e9c3a442 100644 --- a/web/app/src/ui/docks.ts +++ b/web/app/src/ui/docks.ts @@ -259,13 +259,20 @@ const OPERATOR_DECLARED = { }; /** - * The one capability field backed by a mechanism, and the only one current as - * of the beat that carries it (protocol v1 §4.5.3, §4.5.4). + * The only capability field current as of the beat that carries it, and a + * claim filter rather than a dispatch guarantee (protocol v1 §4.5.3, §4.5.4). + * + * The wording here is constrained for the same reason `LAST_OBSERVED`'s is. + * Nothing at the seat reads `harness_family`: dispatch selects a harness by the + * offer's `agent` preset alone. Any verb implying it binds execution — enforced, + * pinned, guaranteed, exact-or-nothing at dispatch — states a fact no code + * supports, and a multi-harness seat matching the filter can run a different + * harness within the family. */ -const ENFORCED_AT_DISPATCH = { - mark: "enforced at dispatch", +const FILTERS_CLAIMS_NOT_DISPATCH = { + mark: "filters claims, not dispatch", markClass: "provenance", - title: "Read from the live roster each time a beat is drafted, so it is current as of this beat. Dispatch binds to the named family exactly or not at all — the only one of the three filterable fields backed by a mechanism.", + title: "Read from the live roster each time a beat is drafted, so it is current as of this beat. It decides which seats may claim a job, never which harness runs one — dispatch selects by the offer's `agent` preset alone, so a seat configured with several presets in this family can match and run a different one. A buyer that needs the execution guarantee must name the preset.", }; /** @@ -322,7 +329,7 @@ const AS_OF_SEAT_START = { export function capabilityRows(s: { harnessFamilies?: string[]; harnessModels?: HarnessModel[]; capabilities?: string[]; harnessVariant?: string | null; hardware?: string | null } | null): ProfileRow[] { if (!s) return []; return [ - ["Harness family", s.harnessFamilies?.length ? s.harnessFamilies.join(" · ") : null, ENFORCED_AT_DISPATCH], + ["Harness family", s.harnessFamilies?.length ? s.harnessFamilies.join(" · ") : null, FILTERS_CLAIMS_NOT_DISPATCH], ["Harness model", s.harnessModels?.length ? s.harnessModels.map((m) => `${m.family} ${m.model}`).join(" · ") : null, LAST_OBSERVED], ["Capabilities", s.capabilities?.length ? s.capabilities.join(" · ") : null, AS_OF_SEAT_START], diff --git a/web/app/test/capability.test.ts b/web/app/test/capability.test.ts index be57b8908..b66b2163f 100644 --- a/web/app/test/capability.test.ts +++ b/web/app/test/capability.test.ts @@ -135,7 +135,7 @@ test("every capability row wears the mark its provenance earns", () => { // Tuple-typed, not inferred: destructuring a `string[][]` yields // `string | undefined` under noUncheckedIndexedAccess. const filterable: [string, string][] = [ - ["Harness family", "enforced at dispatch"], + ["Harness family", "filters claims, not dispatch"], ["Harness model", "last observed"], ["Capabilities", "as of seat start"], ]; From d781a2dcdaa6c01cff2e3ec7a42cc2b1469d743f Mon Sep 17 00:00:00 2001 From: orveth Date: Tue, 25 Aug 2026 16:40:47 -0700 Subject: [PATCH 2/2] ui: put the harness-family contract under a test that can fail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- web/app/src/ui/docks.ts | 22 +++++++++++-------- web/app/test/capability.test.ts | 38 +++++++++++++++++++++++++++++++-- 2 files changed, 49 insertions(+), 11 deletions(-) diff --git a/web/app/src/ui/docks.ts b/web/app/src/ui/docks.ts index 9e9c3a442..8a15c190f 100644 --- a/web/app/src/ui/docks.ts +++ b/web/app/src/ui/docks.ts @@ -306,17 +306,21 @@ const AS_OF_SEAT_START = { * * THE ROWS ARE NOT EQUAL, and the difference is provenance, not confidence. * Protocol v1 §4.5.3 is explicit that a reader MUST NOT read the three - * filterable fields as three grades of proof: `harness_family` is an - * ENFORCEMENT, `harness_model` is an ECHO a buyer can notice a divergence - * against, and `capabilities` is a SILENCE — no event carries a capability back - * at all. §4.5.4 then gives the three different freshness guarantees, and only + * filterable fields as three grades of proof, and that NONE of the three is an + * enforcement: `harness_model` is ECHOED, so a divergence is at least visible + * in a buyer's own records, while `harness_family` and `capabilities` are both + * SILENCE — nothing at the seat reads the family, and no event carries a + * capability back at all. One inconsistency signal and two silences. §4.5.4 + * then gives the three different freshness guarantees, and only * `harness_family` is current as of the beat carrying it. * - * So every row wears its own mark and the marks differ where the proof differs. - * Flush and unmarked, the weakest row reads as solidly as the enforced one, and - * a buyer commits sats on the weakest of the three. The last two rows are free - * text an operator typed; they stay marked apart from all three, because - * nothing pays out on them. + * So every row wears its own mark, and the marks differ 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, and that is what the marks carry. Flush and unmarked, the stalest + * row would read as solidly as the freshest, and a buyer commits sats on the + * stalest of the three. The last two rows are free text an operator typed; + * they stay marked apart from all three, because nothing pays out on them. * * Every row is an ANNOUNCEMENT either way. This reader sees the claim, never * the probe. A mark says what a claim is worth, not that anything verified it diff --git a/web/app/test/capability.test.ts b/web/app/test/capability.test.ts index b66b2163f..cbcfcb64c 100644 --- a/web/app/test/capability.test.ts +++ b/web/app/test/capability.test.ts @@ -130,8 +130,11 @@ test("every capability row wears the mark its provenance earns", () => { assert.match(profileRowHtml(row!), /class="unverified">operator-declared { + // This is the row a buyer reads before paying for a family, and the title is + // where the contract is stated — the mark beside it is a chip with no room + // for one. §4.5.3: the family is neither enforced nor echoed. It decides who + // may be CONSIDERED and never what executes, because dispatch selects on the + // offer's `agent` preset alone. + // + // ⚠ The forbidden list below is an INCLUSION filter, exactly as in the model + // row's test: it pins the spellings this claim has already worn here and + // CANNOT prove a new one is safe. The load-bearing assertions are the three + // positive ones. + const row = rowOf(capabilityRows({ harnessFamilies: ["codex"] }), "Harness family"); + const title = row?.[2]?.title ?? ""; + assert.notEqual(title, "", "positive control: an empty title would pass every doesNotMatch below"); + + for (const shape of [/enforced/i, /enforcement/i, /backed by a mechanism/i, /exactly or not at all/i, /binds dispatch/i]) { + assert.doesNotMatch(title, shape, `claims the family binds execution, which no code supports: ${shape}`); + } + + // The three a buyer needs, asserted separately so that satisfying one cannot + // stand in for another: what the field DOES, what it does NOT do, and what to + // name instead when the execution guarantee is the thing being bought. + assert.match(title, /decides which seats may claim a job/, "must say the family filters claimant eligibility"); + assert.match(title, /never which harness runs one/, "must say the family does not select what executes"); + assert.match(title, /must name the preset/, "must say the `agent` preset is what buys the execution guarantee"); + + // Assert on the RENDERED attribute too. The object field and the string a + // buyer actually hovers are different artifacts, and only the second one ships. + assert.match(profileRowHtml(row!), /title="[^"]*never which harness runs one/); +}); + test("the model row never states an execution fact", () => { // The emitter names this defect family: any wording that upgrades this // SELF-REPORT into an EXECUTION FACT is the same error, and it has been