bmad-method-test-architecture-enterprise 1.25.1 → 1.25.2

package/.claude-plugin/marketplace.json

@@ -31,7 +31,7 @@
       "name": "bmad-method-test-architecture-enterprise",
       "source": "./",
       "description": "Master Test Architect module for quality strategy, test automation, CI/CD quality gates, and structured testing education. Part of the BMad Method ecosystem.",
-      "version": "1.25.1",
+      "version": "1.25.2",
       "author": {
         "name": "Murat K Ozcan (TEA Creator) & Brian (BMad) Madison"
       },

package/CHANGELOG.md

@@ -7,6 +7,14 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [1.25.2] - 2026-09-09
+
+### Fixed
+
+- `trace`'s clean control scored FAIL at exit 2 because five of its twenty-six oracles abstained. `O-009`, `O-010`, `O-011`, `O-013` and `O-014` are `for-any` quantifiers over the seeded set's summary, and `P-004`'s record carried one observation that both plan steps selected, so those five quantified over the clean summary's empty or absent collections. Two changes close it and they work only together: each plan step binds `stdin.prompt` as a literal of that set's own prompt, and the clean control's record carries both fixture sets' runs. Measured on the stored replay, `P-004` moves from FAIL at exit 2 with five abstentions to CONCERNS at exit 0 with all twenty-six oracles resolving `passed-clean-control`; four unsatisfied AD-20 coverage rules hold it at CONCERNS and are separate work. Either half alone is worse than neither, and both were run before this was accepted: two observations under the old matcher bindings leave every observation satisfying both steps, so `exactly-one` reports selector ambiguity on all twenty-six oracles at exit 3; literals over one observation select nothing, so all twenty-six resolve `unreached` and the run reports CONCERNS at exit 0 having examined no evidence, which is a silent green worse than the FAIL it replaces. A literal is compared with `deepEquals`, so the contract's literal and the record's prompt are both `buildPrompt` from `test/eval-trace.js`, and `traceEvidence` throws when the contract on disk binds any other bytes. The record used to carry the placeholder `The prompt the trace harness assembles for <case>.`, which is a prompt no run has ever sent. The control still catches a false positive: a clean summary damaged to derive FAIL with an invented blocker, reported as a defect finding, resolves `O-016` to `false-positive` and the probe to FAIL at exit 2. `test/contracts/trace.contract.json` grows 3.6 kilobytes, the size of the two prompts; the eight fragment-selection contracts keep the matcher binding, where the same fix costs 42 to 143 kilobytes each and roughly doubles every file.
+- A stale reason in `test/contracts/README.md`, surfaced by the contradiction the entry above created. The paragraph on `trace.contract.json`'s witness said its two plan steps share one prompt on purpose because `test/eval-trace.js` names no fact about either fixture set in it, and it said the witness legs are runnable only against a staged workspace of the seeded set. Both stopped being true one release earlier: each set declares its own `projectRoot`, the whole prompt is written against it, and both witness legs stage the clean set. The `allow_gate` reasoning, the differential-and-invariance argument, and the pointer to `testData.setup` all survive and are kept. `testData.setup` in the contract itself was already correct and needed no change.
+- A stale illustration in `docs/explanation/eval-quality-command-adapter.md`. The passage on AD-4 said `trace`'s five `for-any` oracles over the seeded export "still abstain on a clean run", which stopped being true once each plan step selected its own set's run. AD-4's rule is unchanged and the sentence now dates the abstention it describes.
+
 ## [1.25.1] - 2026-09-09
 
 ### Changed

package/docs/explanation/eval-quality-command-adapter.md

@@ -249,8 +249,9 @@ spelling to have committed to.
 
 One limit is worth knowing before writing a new oracle. Every quantifier still abstains over an empty
 collection, which is AD-4's whole purpose and is why `trace`'s five `for-any` oracles over the seeded
-export still abstain on a clean run: they ask whether some element exists, and an empty collection is
-an honest "nothing was checked". `deep-equality` against a literal `[]` also still abstains, so the
+export abstained on the clean control for as long as they were resolved against the clean set's
+summary: they ask whether some element exists, and an empty collection is an honest "nothing was
+checked". `deep-equality` against a literal `[]` also still abstains, so the
 two spellings of "this collection is empty" disagree. eval-quality records that disagreement in AD-4
 rather than hiding it. The bare `count-tolerance` assertion is the one to write.
 
@@ -273,33 +274,47 @@ Three findings, all measured, none of them tuned away.
   before. `test-review` leaves `whole-body`, `malformed-input` and `state-change-read-back`
   unsatisfied; every fragment-selection contract leaves `malformed-input` unsatisfied. Each scores the
   run down to CONCERNS without blocking it, which is exactly the weight AD-20 gives a coverage gap.
-- **`trace`'s clean control scores FAIL, and what remains of it is one thing.** Measured on the
-  stored replay, five of its twenty-six oracles abstain on `P-004`: `O-009`, `O-010`, `O-011`,
+- **`trace`'s clean control scored FAIL. Closed, and the two halves that closed it work only
+  together.** Five of its twenty-six oracles abstained on `P-004`: `O-009`, `O-010`, `O-011`,
   `O-013` and `O-014`, every one a `for-any` quantifier over the seeded export, and every one named
   in the artifact's `verdictBasis`. It was seven. `O-023` and `O-024`, the two asserting that a
   collection is empty, moved to `passed-clean-control` when `eval-quality` 1.4.0 gave that claim a
   spelling.
 
-  The five abstain because the record carries only the clean set's observation and both plan steps
-  select it. The reason recorded here used to be that no request shape names a fixture set; that is
-  no longer true, since each set is staged under its own project root and the prompt is written
-  against it. What is left is the binding: `stdin.prompt` is bound `{matcher: 'any'}`, so one
-  observation is selected by both steps, which is the same limit as the bullet below. The trace
-  prompt is 1.8 kilobytes rather than fragment selection's 28, so the size argument against a literal
-  does not apply here either. What a literal binding needs beside it is a record carrying both sets'
-  observations, and whether one probe's record may carry the run of a set it did not seed is a
-  question about what a clean control means rather than a mechanical change, so it is not made here.
-  Neither half is a case for giving the clean set a member so an oracle has something to read: that
-  would mutate a control to make the instrument work.
+  The five abstained because the record carried one observation and both plan steps selected it, so
+  the seeded set's oracles quantified over the clean summary's empty or absent collections. Each
+  step binds its own set's prompt as a literal now, and the clean control's record carries both
+  sets' runs, so the seeded step selects the seeded run and the clean step selects the clean one.
+  Measured on the stored replay, all twenty-six oracles resolve `passed-clean-control` and `P-004`
+  moves from FAIL at exit 2 to CONCERNS at exit 0. What holds it at CONCERNS is the four unsatisfied
+  AD-20 coverage rules the bullet above describes, which is separate work.
+
+  Either half on its own is worse than neither, which is why they landed together. Two observations
+  under the old matcher bindings leave every observation satisfying both steps, and `exactly-one`
+  then reports selector ambiguity on all twenty-six oracles at exit 3. Literals over one observation
+  select nothing: all twenty-six resolve `unreached` and the run reports CONCERNS at exit 0 having
+  examined no evidence at all, which is a silent green and is worse than the FAIL it replaces. A
+  literal is compared with `deepEquals`, so the contract's literal and the record's prompt are both
+  `buildPrompt` from `test/eval-trace.js`, and `traceEvidence` in `test/lib/probe-scoring.js` throws
+  when the contract on disk binds any other bytes. Both states above were run before the change was
+  accepted, so the failure mode is one somebody has seen.
 
 - **A plan cannot tell two steps apart when both bind their inputs by matcher.** Each
   fragment-selection contract declares one plan step per case, distinguished only by the prompt, and
-  the prompt is bound `{matcher: 'any'}` because the alternative is a 28-kilobyte literal per step. A
-  record carrying one observation is therefore selected by every step, and the oracles of the other
-  cases resolve against evidence that is not theirs. The designated oracle still votes correctly, so
-  the strength vector is unaffected, and the surrounding outcome rows are noise. This is the limit
-  `test/contracts/README.md` records as "a plan cannot declare that two steps must receive different
-  inputs", with its consequence now measured.
+  the prompt is bound `{matcher: 'any'}`. A record carrying one observation is therefore selected by
+  every step, and the oracles of the other cases resolve against evidence that is not theirs. The
+  designated oracle still votes correctly, so the strength vector is unaffected, and the surrounding
+  outcome rows are noise. This is the limit `test/contracts/README.md` records as "a plan cannot
+  declare that two steps must receive different inputs", with its consequence now measured.
+
+  The trace contract closed this with literals; the eight fragment-selection contracts keep the
+  matcher, and the reason is size. Their prompts carry the workflow's knowledge-loading rules and its
+  whole fragment index, 21 to 43 kilobytes per step, so binding each step's prompt as a literal adds
+  between 42 and 143 kilobytes to a contract and roughly doubles every one of the eight files: 1.7x
+  for `bmad-testarch-nfr`, 2.7x for `bmad-testarch-automate`, measured from the prompts those
+  contracts already carry on their witness legs. Trace pays 3.6 kilobytes on 108 for the same fix,
+  because its two prompts are 1.8 kilobytes each, the size of the prompt the file already carries on
+  each of its two witness legs.
 
 ### What the live pre-flight measured
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "bmad-method-test-architecture-enterprise",
-  "version": "1.25.1",
+  "version": "1.25.2",
   "description": "Master Test Architect for quality strategy, test automation, and release gates",
   "keywords": [
     "bmad",

package/test/contracts/README.md

@@ -116,19 +116,21 @@ input-insensitive by design, and the contract now states that as its own claim i
 nothing.
 
 `trace.contract.json`, the tenth, states its witness over standard input on one prompt value,
-`allow_gate`. Its two plan steps share one prompt on purpose: `test/eval-trace.js` names no fact about
-either fixture set in it, so the seeded and clean summaries differ because of the staged workspace and
-never because of the prompt. A differential between the two steps would attribute the difference to
-the wrong input, and an invariance claim would be false. `allow_gate` is the one prompt value the
-ground truth establishes an effect for, through `skillRuleCitations.gateEligibility`: step-05
-evaluates a gate only when it is true and writes `gate_basis` as `none` otherwise, so two prompts
-differing in that value, in one staged workspace, produce two `gate_basis` values. That is a true and
-checkable claim that the command reads its standard input, and it is the claim the witness makes. The
-legs are runnable only against a staged workspace of the seeded set, which is the coupling
-`docs/explanation/eval-quality-command-adapter.md` records for every artifact-writing command. The
-contract itself states this reasoning in `testData.setup`, beside the sentence about the shared
-prompt, because `SensitivityWitness` is a strict object with no prose field of its own; do not look for
-it on the witness.
+`allow_gate`. Its two plan steps send two prompts, each written against its own fixture set's project
+root, and each step binds that prompt as its `stdin.prompt` literal. The summaries the two sets
+produce differ because of the files staged under those roots, so a differential across the two sets
+would attribute to the prompt a difference the staged workspace produced, and an invariance claim over
+them would be false. `allow_gate` is the one prompt value the ground truth establishes an effect for,
+through `skillRuleCitations.gateEligibility`: step-05 evaluates a gate only when it is true and writes
+`gate_basis` as `none` otherwise, so two prompts differing in that value, over one staged fixture set,
+produce two `gate_basis` values. That is a true and checkable claim that the command reads its
+standard input, and it is the claim the witness makes. Both its legs stage the clean set, because AD-10
+reads every other leg of an operation as a clean leg, and they are runnable only against that staged
+workspace, which is the coupling `docs/explanation/eval-quality-command-adapter.md` records for every
+artifact-writing command. The contract itself states this reasoning in `testData.setup`, because
+`SensitivityWitness` is a strict object with no prose field of its own; do not look for it on the
+witness. The section "A plan cannot declare that two steps must receive different inputs" below
+records what those literals cost and what they bought.
 
 ## What the operator vocabulary cannot say
 
@@ -145,6 +147,18 @@ cases differ only in the prompt sent to the runner, and that is the property tha
 mean anything. `sensitivityWitness` expresses a two-leg version of this inside one operation and
 nothing expresses it across plan steps.
 
+Answered for `trace`, at a price the eight fragment-selection contracts cannot pay. Binding each
+step's `stdin.prompt` as a literal of that step's own prompt is what tells the two steps apart: the
+seeded step selects the seeded run, the clean step selects the clean one, and `trace`'s clean control
+moved from FAIL at exit 2 with five oracles abstaining to CONCERNS at exit 0 with all twenty-six
+resolving `passed-clean-control`. It costs 3.6 kilobytes on `trace.contract.json` and 42 to 143
+kilobytes on a fragment-selection contract, which roughly doubles each of those eight files, so they
+keep the matcher. A literal is compared with `deepEquals`, so both sides of one have to come from a
+single function: `tools/generate-contracts.js` and `test/lib/probe-scoring.js` both call `buildPrompt`
+from `test/eval-trace.js`, and the record builder throws when the contract on disk carries any other
+bytes. A prompt restated in either place would select nothing and every oracle would resolve
+`unreached`, which reads as a clean run at exit 0.
+
 **An empty collection is no evidence.** AD-4 resolves a quantifier over an
 empty collection to `insufficient-evidence` with an `empty-collection` introduction condition. The
 `test-review` harness reads a verdict whose findings array is empty as a reviewer that named nothing,

package/test/contracts/trace.contract.json

@@ -2701,7 +2701,7 @@
         "environment": null,
         "stdin": {
           "prompt": {
-            "matcher": "any"
+            "literal": "You are running the TEA workflow `bmad-testarch-trace` against the project in `tenant-data-export/`.\n\nThe workflow is in `skill/`. Read `skill/instructions.md` first, then execute every step file it\nnames in order, in full, without skipping or reordering. The step files are under `skill/steps-c/`.\n\n----- run configuration -----\nResolve the workflow placeholders to these values:\n\n- `{project-root}`: `tenant-data-export`\n- `{config_source}`: `tenant-data-export/_bmad/tea/config.yaml`\n- `{test_artifacts}`: `tenant-data-export/test-artifacts`\n- `{test_dir}`: `tenant-data-export/tests`\n- `{source_dir}`: `tenant-data-export/src`\n- `{skill-root}`: `skill`\n- `gate_type`: `epic`\n- `decision_mode`: `deterministic`\n- `collection_mode`: `contract_static`\n- `allow_gate`: `true`\n- `coverage_basis`: `auto`\n- `summary_confidence`: `auto`\n- `coverage_levels`: `e2e,api,component,unit,live`\n\nThe trace target is the epic under `tenant-data-export/docs/epics/`. Resolve the coverage oracle from it the\nway step-01 says to.\n\n----- what to produce -----\nWrite both deliverables the workflow declares:\n\n- `tenant-data-export/test-artifacts/traceability-matrix.md`, from `skill/trace-template.md`, carrying the\n  detailed mapping with one section per criterion, each stating its coverage status and the tests\n  that establish it as `file:line`.\n- `tenant-data-export/test-artifacts/e2e-trace-summary.json` at schema_version 0.3.0, exactly as\n  `skill/steps-c/step-05-gate-decision.md` section 3b defines it.\n\nDo not add, edit, or delete any file under `tenant-data-export/docs/`, `tenant-data-export/src/`, or `tenant-data-export/tests/`.\nThis workflow does not generate tests.\n\nWhen you are done, print one line naming the two files you wrote. Nothing else you print is read."
           }
         }
       }
@@ -2721,7 +2721,7 @@
         "environment": null,
         "stdin": {
           "prompt": {
-            "matcher": "any"
+            "literal": "You are running the TEA workflow `bmad-testarch-trace` against the project in `api-token-lifecycle/`.\n\nThe workflow is in `skill/`. Read `skill/instructions.md` first, then execute every step file it\nnames in order, in full, without skipping or reordering. The step files are under `skill/steps-c/`.\n\n----- run configuration -----\nResolve the workflow placeholders to these values:\n\n- `{project-root}`: `api-token-lifecycle`\n- `{config_source}`: `api-token-lifecycle/_bmad/tea/config.yaml`\n- `{test_artifacts}`: `api-token-lifecycle/test-artifacts`\n- `{test_dir}`: `api-token-lifecycle/tests`\n- `{source_dir}`: `api-token-lifecycle/src`\n- `{skill-root}`: `skill`\n- `gate_type`: `epic`\n- `decision_mode`: `deterministic`\n- `collection_mode`: `contract_static`\n- `allow_gate`: `true`\n- `coverage_basis`: `auto`\n- `summary_confidence`: `auto`\n- `coverage_levels`: `e2e,api,component,unit,live`\n\nThe trace target is the epic under `api-token-lifecycle/docs/epics/`. Resolve the coverage oracle from it the\nway step-01 says to.\n\n----- what to produce -----\nWrite both deliverables the workflow declares:\n\n- `api-token-lifecycle/test-artifacts/traceability-matrix.md`, from `skill/trace-template.md`, carrying the\n  detailed mapping with one section per criterion, each stating its coverage status and the tests\n  that establish it as `file:line`.\n- `api-token-lifecycle/test-artifacts/e2e-trace-summary.json` at schema_version 0.3.0, exactly as\n  `skill/steps-c/step-05-gate-decision.md` section 3b defines it.\n\nDo not add, edit, or delete any file under `api-token-lifecycle/docs/`, `api-token-lifecycle/src/`, or `api-token-lifecycle/tests/`.\nThis workflow does not generate tests.\n\nWhen you are done, print one line naming the two files you wrote. Nothing else you print is read."
           }
         }
       }

package/test/lib/probe-scoring.js

@@ -41,6 +41,11 @@ const fs = require('node:fs');
 const path = require('node:path');
 
 const { digest } = require('./eval-record');
+// The prompt a trace observation carries is the prompt the harness assembles, and
+// tools/generate-contracts.js binds the same function's output as each trace plan
+// step's stdin literal. One function on both sides is the whole guard; `legs` in
+// traceEvidence says what a restated prompt would cost.
+const { buildPrompt: buildTracePrompt } = require('../eval-trace');
 const {
   evaluatorConfiguration,
   isolationManifest,
@@ -276,12 +281,42 @@ function traceArtifacts(caseId) {
 function traceEvidence(contract) {
   const [seededStep, cleanStep] = contract.interactionPlan;
   const groundTruth = readJson(path.join(PROJECT_ROOT, 'test', 'fixtures', 'trace-eval', 'ground-truth.json'));
+
+  /**
+   * One entry per fixture set: the plan step that selects it, the stored run its
+   * project root names, and the prompt the harness assembles for it.
+   *
+   * `buildTracePrompt` is test/eval-trace.js's own `buildPrompt`, which is also
+   * what tools/generate-contracts.js calls to build each step's stdin literal. A
+   * literal is compared with `deepEquals`, so a prompt restated here in any other
+   * form would select nothing, all twenty-six oracles would resolve `unreached`,
+   * and the run would report clean at exit 0 having examined no evidence. The
+   * equality below is the tripwire: the prompt this record will carry is checked
+   * against the literal the contract on disk binds, so a divergence fails the run
+   * where it would otherwise pass it silently.
+   */
+  const legs = groundTruth.fixtureSets.map((set) => {
+    const seeded = set.id.startsWith('seeded');
+    const step = seeded ? seededStep : cleanStep;
+    const prompt = buildTracePrompt(set);
+    if (step.inputBinding.stdin?.prompt?.literal !== prompt) {
+      throw new Error(
+        `${step.stepId} binds a stdin literal that is not the prompt the harness assembles for ${set.id}; run node tools/generate-contracts.js`,
+      );
+    }
+    return {
+      caseId: seeded ? 'seeded-correct-run' : 'clean-correct-run',
+      observationId: seeded ? 'trace-seeded-run' : 'trace-clean-run',
+      projectRoot: set.projectRoot,
+      step,
+      prompt,
+    };
+  });
+
   // The stored run each fixture set's project root names. A trace prompt is written
   // against one project root, and that root is the only thing in the request that
   // says which set the leg is asking for, so it is what the port stages against.
-  const caseByProjectRoot = new Map(
-    groundTruth.fixtureSets.map((set) => [set.projectRoot, set.id.startsWith('seeded') ? 'seeded-correct-run' : 'clean-correct-run']),
-  );
+  const caseByProjectRoot = new Map(legs.map((leg) => [leg.projectRoot, leg.caseId]));
 
   return {
     /**
@@ -313,41 +348,61 @@ function traceEvidence(contract) {
     },
     recordInputs(probe) {
       const clean = probe.expectedClean;
-      const caseId = clean ? 'clean-correct-run' : 'seeded-correct-run';
-      // One observation, and the other step's oracles then have nothing of their
-      // own to read. Both steps declare the same operation and send the same
-      // prompt, because what makes a trace run the seeded set or the clean set is
-      // the staged workspace and no request shape names one, so a record carrying
-      // both runs is ambiguous under `exactly-one` and a record carrying one
-      // leaves five seeded-set oracles quantifying over an absent collection. The
-      // clean control's FAIL is that, plus two oracles asserting an empty array.
-      const step = clean ? cleanStep : seededStep;
-      const observationId = clean ? 'trace-clean-run' : 'trace-seeded-run';
-      const observations = [
+      // The clean control's record carries both runs. Each step binds its own set's
+      // prompt as a literal, so the seeded step selects the seeded observation and
+      // the clean step selects the clean one, and the oracles of each quantify over
+      // the summary their own set produced. With one observation both steps selected
+      // it, so five of the seeded step's `for-any` oracles quantified over the clean
+      // summary's empty or absent collections and abstained, which was the control's
+      // FAIL at exit 2. Two observations under a matcher binding are worse: every
+      // observation satisfies both steps, and `exactly-one` then reports selector
+      // ambiguity on all twenty-six oracles. The literals and the second observation
+      // work only together.
+      //
+      // A defect probe carries its seeded run alone. AD-9's qualification gate
+      // resolves every one of its oracles before a selection is read, so a second
+      // observation would add evidence nothing reaches.
+      //
+      // Two things this record still states loosely, and nothing reads either today.
+      // `conditionArm` stays `clean-correct-run` for a record that now carries two
+      // runs, and P-004's `baselinePassEvidence` in test/probes/trace.probes.json
+      // names the clean summary's digest alone.
+      const selected = clean ? legs : legs.filter((leg) => leg.caseId === 'seeded-correct-run');
+      const observations = selected.map((leg, index) =>
         recordObservation({
-          observationId,
-          sequence: 1,
-          operationId: step.operationId,
-          callInputs: { option: { agent: 'claude' }, stdin: { prompt: `The prompt the trace harness assembles for ${caseId}.` } },
+          observationId: leg.observationId,
+          sequence: index + 1,
+          operationId: leg.step.operationId,
+          callInputs: { option: { agent: 'claude' }, stdin: { prompt: leg.prompt } },
           stdout: { kind: 'text', value: '' },
           stderr: { kind: 'text', value: '' },
           exitCode: 0,
-          artifacts: traceArtifacts(caseId),
+          artifacts: traceArtifacts(leg.caseId),
         }),
-      ];
+      );
+      // Every trace oracle reads one step's interaction, so its disposition cites
+      // that step's observation. A record carrying one run has nothing of the other
+      // step's to cite, and a `held` disposition citing nothing is scored as an
+      // unsupported claim, so those oracles cite the run the record does carry.
+      const observationIdByStep = new Map(selected.map((leg) => [leg.step.stepId, leg.observationId]));
+      const stepOf = (pointer) => String(pointer).split('/')[2];
+      const citedObservationId = (oracle) => {
+        const target = (oracle.direction?.evidenceTargets ?? []).find((pointer) => observationIdByStep.has(stepOf(pointer)));
+        return target === undefined ? observations[0].observationId : observationIdByStep.get(stepOf(target));
+      };
       return {
         observations,
         findings: [],
-        // Both stored runs are recorded as scoring every check they were given,
-        // so every oracle held on the evidence the harness read.
+        // Every stored run in this record is recorded as scoring every check it was
+        // given, so every oracle held on the evidence the harness read.
         oracleDispositions: contract.oracles.map((oracle) => ({
           oracleId: oracle.id,
           disposition: 'held',
-          observationIds: [observationId],
+          observationIds: [citedObservationId(oracle)],
           note: null,
         })),
         evaluatorRecommendation: 'PASS',
-        conditionArm: caseId,
+        conditionArm: clean ? 'clean-correct-run' : 'seeded-correct-run',
       };
     },
   };

package/test/probes/expected-strength.json

@@ -308,9 +308,14 @@
         "expectedClean": true,
         "behaviorId": "B-016",
         "preflight": "passed",
-        "verdict": "FAIL",
-        "exitCode": 2,
-        "basis": ["oracle resolved abstained at or above the severity floor"],
+        "verdict": "CONCERNS",
+        "exitCode": 0,
+        "basis": [
+          "coverage gap malformed-input unsatisfied at or above the severity floor",
+          "coverage gap state-change-read-back unsatisfied at or above the severity floor",
+          "coverage gap success-indicator-separation unsatisfied at or above the severity floor",
+          "coverage gap whole-body unsatisfied at or above the severity floor"
+        ],
         "qualification": null,
         "strength": {
           "defect": null,

package/tools/generate-contracts.js

@@ -22,7 +22,8 @@
  *     name for that contract's sourceSpecDigest,
  *   - cli/trace-runner.js's TRACE_REQUEST_KEYS and DEFAULT_AGENT for that
  *     contract's request shape and witness legs, and test/eval-trace.js's
- *     buildPrompt for the two prompts the witness legs send, and
+ *     buildPrompt for the two prompts the witness legs send and for the literal
+ *     each of its two plan steps binds on standard input, and
  *   - the trace workflow's step-05 for the key set of the summary the run writes.
  *
  * The prose that is genuinely authored (an oracle's commentary, a behavior's lead
@@ -69,8 +70,8 @@ const { VERDICT_KEYS, DEFAULT_AGENT } = require('../cli/test-review');
 // owns its own request shape and its own default agent, so both are read from it.
 const { SELECTION_REQUEST_KEYS, DEFAULT_AGENT: SELECTION_DEFAULT_AGENT } = require('../cli/fragment-selection-runner');
 // And for the trace command: its request shape and default agent are its own, and
-// the prompt its witness legs send is the harness's, because the harness is the
-// only thing that assembles one.
+// the prompt its witness legs send and the literal each of its plan steps binds
+// are the harness's, because the harness is the only thing that assembles one.
 const { TRACE_REQUEST_KEYS, DEFAULT_AGENT: TRACE_DEFAULT_AGENT, EXIT_CODES: TRACE_EXIT_CODES } = require('../cli/trace-runner');
 const { vendorEnvironmentNames } = require('../cli/lib/runner-exit-codes');
 const {
@@ -2278,20 +2279,31 @@ function buildTraceContract() {
       operationId: TRACE_OPERATION,
       after: null,
       cardinality: 'exactly-one',
-      // The agent is bound as `any` rather than pinned: which vendor answered is
-      // the runner record's to state. The prompt is bound as `any` for the reason
-      // the fragment-selection contracts give: its bytes are evidence, and the
-      // sealed record carries their digest.
+      // The agent is bound as `any`: which vendor answered is the runner record's
+      // to state.
       //
-      // The two steps no longer send the same prompt. Each fixture set is staged
-      // under its own project root and the prompt is written against it, so the
-      // request now says which set a run traces. What the matcher leaves open is
-      // which observation a step selects: a record carrying one observation is
-      // selected by both steps, so the other set's oracles quantify over evidence
-      // that is not theirs. That is the limit test/contracts/README.md records as
-      // "a plan cannot declare that two steps must receive different inputs", and
-      // it is a property of the matcher rather than of the prompts.
-      inputBinding: { argument: null, option: { agent: { matcher: 'any' } }, environment: null, stdin: { prompt: { matcher: 'any' } } },
+      // Standard input is bound as a literal, and the literal is the prompt the
+      // harness assembles for this fixture set. Both steps declare the same
+      // operation, so under a matcher binding every observation satisfies both
+      // steps: one observation is selected twice and the other set's oracles
+      // quantify over evidence that is not theirs, which is what held the clean
+      // control at FAIL with five abstentions. The prompt is the only part of the
+      // request that tells the two steps apart, because the project root it is
+      // written against is the one fact about the set the request carries.
+      //
+      // buildTracePrompt is test/eval-trace.js's own buildPrompt, the function
+      // that assembles the prompt the live run sends and the prompt
+      // test/lib/probe-scoring.js puts on a trace observation. A literal is
+      // compared with deepEquals, so a prompt restated here in any other form
+      // would select nothing, every oracle would resolve `unreached`, and a run
+      // that examined no evidence at all would report clean at exit 0. One
+      // function on both sides is what makes that unrepresentable.
+      inputBinding: {
+        argument: null,
+        option: { agent: { matcher: 'any' } },
+        environment: null,
+        stdin: { prompt: { literal: buildTracePrompt(set) } },
+      },
     })),
     scopedResources: null,
     forbiddenInputs: FORBIDDEN_INPUTS,