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

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.0",
+      "version": "1.25.1",
       "author": {
         "name": "Murat K Ozcan (TEA Creator) & Brian (BMad) Madison"
       },

package/CHANGELOG.md

@@ -7,6 +7,20 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [1.25.1] - 2026-09-09
+
+### Changed
+
+- `eval-quality` moves from 1.3.0 to 1.4.0, which closes three findings this repository raised against it, and the probe corpora record what changed. Measured on the stored replay across the two versions: `test-review`'s five plants that had failed pre-flight on `seeded-faults-scoped` with a null verdict and exit 3 now pass pre-flight and score, taking the suite's defect class from four exercised and four caught to nine and nine at a rate of 1; `trace`'s O-023 and O-024 move from `abstained` to `passed-clean-control`, because a bare `count-tolerance` with `expected: 0` now counts a collection observed to be present and empty; and `trace`'s three defect probes report `condition-artifact-channel-contract-local`, the reason AD-9's gate refused them, where before a rejected probe surfaced only as `infrastructure-error` and exit 3. `expected-strength.json` records a `qualification` field per probe, so a rejection that changes its reason shows up as a diff.
+- Each trace fixture set is staged under its own project root, declared as `projectRoot` in `test/fixtures/trace-eval/ground-truth.json` and named for the epic the set traces: `tenant-data-export` and `api-token-lifecycle`. Both sets used to stage at one `project/` root and `buildPrompt` read nothing off the set it was given, so the two sets sent byte-identical prompts and the staged workspace, which is the run's real input, was nameable from no request. The whole prompt is written against the set's root now, so a leg can ask for the set it means: `stagedWorkspaceFor` stages the set the prompt names, the stored-evidence port answers with that set's stored run, and the stub agent resolves `{project-root}` off the prompt the way a real agent does. `validateCorpus` fails a corpus whose two sets share a root or whose root names the set's role, because a run that read `clean` in the directory it works in would have been handed the answer.
+
+### Fixed
+
+- Four passages describing limitations that no longer exist. `test/probes/README.md` and `docs/explanation/eval-quality-command-adapter.md` each said a rejected probe carries no reason across the boundary; the adapter document also said "this collection is empty" has no spelling, and argued that no leg TEA could add repairs `seeded-faults-scoped` firing on a leg carrying the fault leg's own request. All four are rewritten against what 1.4.0 does, with the measured before and after. One finding stays open and belongs to TEA rather than to `eval-quality`: `trace`'s three defect probes address a file the command wrote, which the qualification gate refuses by design. The other is closed below.
+- `trace`'s three defect probes failed pre-flight on `seeded-faults-scoped`, reported as `D-001: the manifestation witness fires on clean leg "witness-gate-withheld"`. The witness was right and the leg was not clean. AD-10 reads every other leg of an operation as a clean leg, `trace-fixture-set` declares `stateChangeMarker: true` so no control leg is planned for it, and the only other legs it had were its two sensitivity witness legs, both staging the seeded set. The manifestation witness asserts a coverage number the seeded workspace produces and `allow_gate` does not move, so it fired there truthfully. Both witness legs stage the clean set now, where P0 coverage is 100 and the relation asserting 50 resolves false, so the check is satisfied on evidence rather than on an authored relation. The `allow_gate` differential is unchanged and holds on either set. Measured on the stored replay, the three probes move from `preflight: failed: seeded-faults-scoped` to `preflight: passed` and lose the `pre-flight verdict did not pass` line from their basis; they are still refused by the qualification gate, so their verdict, exit code and strength are unchanged. All thirty-one probes in the corpus pre-flight now.
+- Every signature channel `tea-trace-runner` could carry, measured through `runScore` rather than asserted: an `artifact` pointer is refused as `condition-artifact-channel-contract-local`, a `stdout` pointer as `condition-pointer-unwritable`, and an `exit-code` condition is admitted and discriminates nothing, since `cli/lib/runner-exit-codes.js` gives 0 to every run whose agent completed. The three probes keep the signature that states the truth about the plant, and `test/probes/README.md` and `docs/explanation/eval-quality-command-adapter.md` name the reason code rather than describing the refusal in prose.
+- Stale numbers and claims throughout `docs/explanation/eval-quality-command-adapter.md`, checked against `test/probes/expected-strength.json` and against the contracts rather than reread. Its corpus table was pinned at `eval-quality` 1.3.0 and said `test-review` caught four of four with five plants firing on a witness leg; the baseline says nine of nine. It said eight probes cannot be pre-flighted; none is left. It said seven of `trace`'s twenty-six oracles abstain on the clean control; five do, measured on `P-004`, and all five are `for-any` quantifiers over the seeded export named in the artifact's own `verdictBasis`. It said no request shape names a trace fixture set, which the project root now does. The dated live pre-flight table is kept as the measurement it was, with what has moved under it since recorded beside it, including that `trace` now spawns three legs where it spawned two because its manifestation witnesses no longer share a request with a witness leg.
+
 ## [1.25.0] - 2026-09-09
 
 ### Added

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

@@ -27,7 +27,7 @@ That last one had no TEA equivalent at all. A harness could spawn anything.
 
 **`eval-all.js`'s child spawn stays.** It uses `stdio: 'inherit'` so a forty-minute matrix prints as it goes. A probe captures and returns at the end, which is wrong for an operator watching one.
 
-**The `--version`, `git`, and keychain probes stay.** They interrogate the environment rather than probe a system under test, so the adapter does not cover them. None passed a timeout, so any one could hang CI rather than fail it; all seven now go through `test/lib/bounded-probe.js`, which is a ten-second deadline, a SIGKILL, and a reason the caller can act on.
+**The `--version`, `git`, and keychain probes stay.** They interrogate the environment rather than probe a system under test, so the adapter does not cover them. None passed a timeout, so any one could hang CI rather than fail it; all eight now go through `test/lib/bounded-probe.js`, which is a ten-second deadline, a SIGKILL, and a reason the caller can act on. Eight is four `--version` probes, three `git` reads, and the keychain lookup.
 
 ## The policy is the seam
 
@@ -90,13 +90,19 @@ Every probe names the oracle that catches it, and that is enforced rather than i
 generator reads a probe's `behaviorId` out of the contract and refuses one whose behavior discharges
 more than a single oracle.
 
-What the corpus scores, at `eval-quality` 1.3.0:
+What the corpus scores, read off `test/probes/expected-strength.json` as it stands:
 
 | Contract                               | defect        | gameability           | Not scored, and why                                                                                     |
 | -------------------------------------- | ------------- | --------------------- | ------------------------------------------------------------------------------------------------------- |
-| `test-review`                          | 4 of 4 caught | refused               | five plants fire on a witness leg the plan calls clean; the gameability signature reads a written file  |
+| `test-review`                          | 9 of 9 caught | refused               | the gameability signature reads a written file, so AD-9's gate refuses it                               |
 | the eight fragment-selection contracts | none authored | 1 of 1 caught on each | fragment selection seeds no defect; it is a routing measurement with a required set and a forbidden set |
-| `trace`                                | refused       | none authored         | all three plants fire on a witness leg the plan calls clean, and the signature reads a written file     |
+| `trace`                                | refused       | none authored         | all three signatures read a written file, so AD-9's gate refuses them                                   |
+
+The two numbers that moved and what moved them: `test-review`'s defect class went from four exercised
+and four caught to nine and nine when `eval-quality` 1.4.0 dropped a clean leg that had issued the
+fault leg's own request, and `trace`'s three plants stopped failing pre-flight when its witness legs
+moved off the seeded set. Both are `seeded-faults-scoped`, and both are below. Every probe in the
+corpus now pre-flights, so what is left unscored is the qualification gate alone.
 
 A clean control never enters the vector, which is AD-7's rule rather than a gap: what it establishes
 is that the contract does not fire where there is nothing to find.
@@ -104,9 +110,10 @@ is that the contract does not fire where there is nothing to find.
 `npm run eval:preflight` and `npm run eval:contract-strength` read their exit code against
 `test/probes/expected-strength.json` rather than against pass and fail directly: 0 when every probe
 reached the outcome the corpus records, 1 when a verdict moved, 2 when a pre-flight outcome moved.
-Eight probes that cannot be pre-flighted would otherwise make both scripts red on every run, and a
-script that is always red stops being read before the day it means something, which is a declaration
-nothing enforces arriving from the other direction.
+Eight probes could not be pre-flighted when that rule was written, and both scripts would have been
+red on every run, which is how a script stops being read before the day it means something. All
+thirty-one pre-flight now, so the baseline is what says a green run is green rather than what excuses
+a red one, and the rule is what catches the first probe to stop.
 
 ### The behavior grouping was a defect, and it is fixed
 
@@ -132,7 +139,9 @@ probe there would have been voted by `O-001` whatever criterion it withheld.
 ### What the probe vocabulary cannot say about a command
 
 Four limits, all measured against the installed package rather than inferred, and all recorded in
-`test/probes/expected-strength.json` so the day one closes is visible.
+`test/probes/expected-strength.json` so the day one closes is visible. Three have closed since they
+were written: two upstream in `eval-quality` 1.4.0 and one here, in the trace contract. Each is kept
+with what closed it, because a limit that vanishes silently teaches nobody why it was there.
 
 **A defect signature cannot address a file a command wrote.** `qualifyProbe` refuses an `artifact`
 pointer outright as `condition-artifact-channel-contract-local`: an artifact identifier is minted per
@@ -141,7 +150,9 @@ contract, so a signature carrying one resolves only against the contract it was
 output as its descriptor channel. Measured across TEA's three commands: a structured stdout signature
 against `tea-fragment-selection-runner` qualifies, the same shape against `tea-test-review` does not,
 an artifact signature against either is refused, and an `exit-code` signature qualifies against all
-three.
+three. Measured again on `tea-trace-runner` through `runScore`, one channel at a time over the same
+stored evidence: `artifact` is refused as `condition-artifact-channel-contract-local`, `stdout` as
+`condition-pointer-unwritable`, and `exit-code` is admitted.
 
 What is left is the exit code, and whether that is honest depends on the command. For
 `tea-test-review` it discriminates: a review that finds a gating defect exits 1 and one that finds
@@ -153,43 +164,105 @@ since every completed trace run exits 0 whatever it wrote, so its three probes k
 that states the truth about the plant and are refused rather than given one that would qualify and
 mean nothing.
 
-**`seeded-faults-scoped` compares a run against itself.** AD-10 asks whether a seeded fault fires anywhere
-it should not, and `planPreflight` answers it against every leg already registered for the operation,
-which for a TEA contract is its sensitivity witness legs. `test-review`'s differential drives one leg
-at a seeded fixture and `trace`'s drives both at the seeded set, so a plant in a file a witness leg
-reads fires on a leg the plan calls clean. Five of the nine review plants land there, and all three
-trace plants: the live pre-flight reports `D-001: the manifestation witness fires on clean leg
-"witness-gate-evaluated"`. The four review plants in the file no witness leg reads pre-flight cleanly
-and score, and the defect class catches all four.
+**`seeded-faults-scoped` compares a run against itself.** AD-10 asks whether a seeded fault fires
+anywhere it should not, and `planPreflight` answers it against every leg already registered for the
+operation, which for a TEA contract is its sensitivity witness legs. `test-review`'s differential
+drove one leg at a seeded fixture and `trace`'s drove both at the seeded set, so at `eval-quality`
+1.3.0 a plant in a file a witness leg read fired on a leg the plan called clean. Five of the nine
+review plants landed there, and all three trace plants: the live pre-flight reported `D-001: the
+manifestation witness fires on clean leg "witness-gate-evaluated"`. The four review plants in the
+file no witness leg reads pre-flighted cleanly and scored, and the defect class caught all four.
 
-No leg TEA can add repairs it, and the reason is sharper than "a plant sits in a file a witness
+No leg TEA could add repaired it, and the reason was sharper than "a plant sits in a file a witness
 reads". For those five plants the fault leg's request is byte for byte the sensitivity leg's request:
 the same executable, the same `--files`, the same `--json`, the same `--agent`. The observation cache
-collapses them into one spawn for exactly that reason. So the check resolves the manifestation
+collapses them into one spawn for exactly that reason. So the check resolved the manifestation
 relation against a run identical to the fault run, and no relation true on the one can be false on
-the other. Adding a leg that reads an unplanted fixture changes nothing, because the check fails on a
-leg that fires rather than on the absence of a leg that does not, and adding legs can only add ways
-to fire. Making the seeded witness leg read an unplanted fixture is not available either: the
+the other. Adding a leg that reads an unplanted fixture changed nothing, because the check fails on a
+leg that fires rather than on the absence of a leg that does not, and adding legs could only add ways
+to fire. Making the seeded witness leg read an unplanted fixture was not available either: the
 differential it asserts is that two file lists produce different severity counts, and two unplanted
 lists produce the same counts, so the witness would fail instead. The one remaining shape, a witness
 whose relation compares the `reviewedFiles` the verdict echoes back, is the "the evidence contains
 the string I sent" condition the probe-side qualification gate exists to reject, and authoring it
 contract-side to get a green pre-flight would be gaming the witness.
 
-**"This collection is empty" has no spelling.** The evaluator intercepts an empty array on every
-quantifier and on every single-operand leaf and returns `insufficient-evidence` with an
-`empty-collection` condition before the operator runs, so `count-tolerance` with `expected: 0` never
-counts and `deep-equality` against a literal `[]` never compares. Two of `trace`'s oracles make
-exactly that claim about its clean set, and both abstain on the run they were written to confirm.
-`count-tolerance` is the spelling this repository now uses, because it is the claim the oracle is
-making and it starts working the day an empty collection counts as evidence for a cardinality check.
-
-**A rejected probe carries no reason across the boundary.** The qualification gate computes a closed
-list of twenty reason codes and none of them reaches the evidence artifact or any published export.
-A probe the gate rejects surfaces as `infrastructure-error` on every oracle and exit 3, and a corpus
-author reading that has nothing to act on. Reading the reasons needs `qualifyProbe`, which is not on
-the exports map, and that would be the third reach into `dist/` this document already records two of.
-TEA does not take it.
+TEA raised it upstream, and 1.4.0 fixes it in the reducer. A clean leg is dropped when it issued the
+fault leg's request and received the fault leg's answer, compared over the request with the
+correlation identifier neutralised and over the projected evidence with the observation identifier
+neutralised. Both halves are required: dropping on the answer alone would discard AD-10's own worked
+example of two distinct nonexistent identifiers both returning 404, which are the legs the check
+exists to read. A check left with no clean leg to examine now fails and names why, where it reported
+satisfied before.
+
+Measured on the stored replay across the two versions, `test-review`'s five plants move from
+`preflight: failed: seeded-faults-scoped` with a null verdict and exit 3 to `preflight: passed`,
+`CONCERNS`, exit 0, each carrying its own strength vector. The suite's defect class goes from four
+exercised and four caught to nine and nine, still at a rate of 1. `expected-strength.json` records
+the move.
+
+`trace`'s three plants failed on that same run, and that was the fix working: their witness fired on
+`witness-gate-withheld`, a leg that issues a different request and receives a different answer, so
+the reducer kept it in the examined set and the check reported a real scoping problem in the trace
+contract. That problem is now closed, and the shape of it is worth keeping.
+
+The witness was right and the leg was not clean. AD-10 reads every other leg of an operation as a
+clean leg. `trace-fixture-set` carries `stateChangeMarker: true`, so `selectControl` plans no control
+leg for it, and the only other legs it had were its two sensitivity witness legs, both staged against
+the seeded set. `D-001` asserts that P0 coverage is 50, which is what the seeded workspace produces
+and what `allow_gate` does not move, so the relation was true on a seeded run with the gate withheld.
+It fired there because the plant was there.
+
+Nothing in the request could say otherwise. The run's real input is the staged workspace, both sets
+were staged at one `project/` root, and `buildPrompt` took a fixture set and read nothing off it, so
+the two sets sent byte-identical prompts and no leg could ask for the set without the plant. Each set
+now declares a `projectRoot` in `test/fixtures/trace-eval/ground-truth.json`,
+`tenant-data-export` and `api-token-lifecycle`, and the whole prompt is written against it:
+`{project-root}`, `{config_source}`, `{test_artifacts}`, `{test_dir}`, `{source_dir}`, the epic
+directory, and both deliverable paths. `stagedWorkspaceFor` stages the set the leg's prompt names,
+the stored-evidence port answers with that set's stored run, and the stub agent resolves
+`{project-root}` off the prompt the way a real agent does.
+
+The contract's two witness legs now trace the clean set, which is the set that establishes what
+"clean leg" means for this operation. P0 coverage there is 100, so `D-001`'s relation resolves false
+on both legs and the check is satisfied on evidence. The `allow_gate` differential is untouched and
+holds on either set: the clean set writes `gate_basis: "priority_thresholds"` when the gate is
+allowed and `"none"` when it is withheld, the same pair the seeded set writes. Measured on the stored
+replay, the three probes move from `preflight: failed: seeded-faults-scoped` to `preflight: passed`,
+and their basis loses the `pre-flight verdict did not pass` line. They are still refused by the
+qualification gate, so their verdict, exit code and strength are unchanged.
+
+The project roots name the epic each set traces and not the set's role. A run that read `clean` in
+the directory it works in would have been handed the answer, which is the rule the corpus already
+follows when it keeps every inline label out of the fixture files, so `validateCorpus` fails a
+project root carrying `seeded`, `clean`, `control`, `planted` or `gap`.
+
+**"This collection is empty" has a spelling, as of 1.4.0.** Through 1.3.0 the evaluator intercepted
+an empty array on every quantifier and every single-operand leaf and returned `insufficient-evidence`
+with an `empty-collection` condition before the operator ran, so `count-tolerance` with `expected: 0`
+never counted. `trace`'s O-023 and O-024 make exactly that claim about its clean set, and both
+abstained on the run they were written to confirm. TEA raised it upstream and 1.4.0 exempts the three
+operators that read a property of the collection itself: `count-tolerance` reads its cardinality,
+`existence` and `absence` read its presence. Measured on the stored replay across the two versions,
+O-023 and O-024 move from `abstained` to `passed-clean-control`, so `count-tolerance` was the right
+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
+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.
+
+**A rejected probe names its reason, as of 1.4.0.** The qualification gate computes a closed list of
+twenty reason codes. Through 1.3.0 none of them reached the evidence artifact or any published
+export, so a probe the gate rejected surfaced as `infrastructure-error` and exit 3 and a corpus
+author reading that had nothing to act on. Reading the reasons meant calling `qualifyProbe`, which
+was off the exports map, and taking it would have been the third reach into `dist/` this document
+already records two of. TEA raised that upstream instead. `runScore` now returns `qualification`
+beside the artifact and the ladder, `QUALIFICATION_FAILURES` publishes the closed set, and
+`test-probe-corpus` records the codes per probe in `expected-strength.json`. No reach into `dist/`
+was needed and the count stays at two.
 
 ### What the scoring half says about TEA's contracts
 
@@ -200,16 +273,25 @@ 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 it is two different things.** Seven of its twenty-six
-  oracles abstain. Five belong to the seeded set and resolve against a record carrying only the clean
-  set's observation, and TEA cannot repair that: both plan steps declare one 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 the other set's oracles reading nothing. Binding the prompt literally
-  was tried and the generator's comment records why it does not work. The other two assert that a
-  collection is empty, which the vocabulary cannot say at all. 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.
+- **`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`,
+  `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.
+
 - **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
@@ -221,11 +303,12 @@ Three findings, all measured, none of them tuned away.
 
 ### What the live pre-flight measured
 
-The first pre-flight this repository has ever run, on 2026-09-09 against `claude`. Twenty-one legs
-spawned, 55 minutes of model time, and every leg cached under a digest of its request so a second
-invocation pays for nothing it has already answered. The three manifestation witnesses `trace` gained
-at `eval-quality` 1.3.0 cost nothing: their request is the one its `allow_gate: true` witness leg
-already sends, and the cache is keyed on the request.
+The first pre-flight this repository has ever run, on 2026-09-09 against `claude`, at `eval-quality`
+1.3.0. Twenty-one legs spawned, 55 minutes of model time, and every leg cached under a digest of its
+request so a second invocation pays for nothing it has already answered. The three manifestation
+witnesses `trace` gained at 1.3.0 cost nothing on that run: their request was the one its
+`allow_gate: true` witness leg already sent, and the cache is keyed on the request. The table is that
+run and has not been re-measured; what has changed under it since is below.
 
 | Suite                                  | Legs spawned | Model time | Pre-flight                                                                           |
 | -------------------------------------- | -----------: | ---------: | ------------------------------------------------------------------------------------ |
@@ -241,6 +324,15 @@ the `false` leg wrote `gate_basis: "none"` and no gate at all, which is what ste
 `test-review`'s differential is the file list: the seeded fixture drew five findings and exit 1, the
 clean control drew none and exit 0.
 
+Two things about that table have moved since, both on the stored replay rather than on a repeat of
+the live run. `test-review`'s pre-flight outcome is now nine of nine defect probes rather than four,
+because `eval-quality` 1.4.0 drops a clean leg that issued the fault leg's own request. `trace`'s is
+now all four probes passing, because its witness legs moved to the clean set. That move also costs a
+leg: the three manifestation witnesses trace the seeded set while the two witness legs trace the
+clean set, so their request is no longer one the cache already holds and `trace` spawns three legs
+where it spawned two. The three still share one request between them, so it is one extra spawn and
+not three.
+
 Two things the live run found that no deterministic check could.
 
 **The two witness legs shared a staged workspace, and the second read the first's file.** The first
@@ -265,8 +357,8 @@ prompt the harness assembles for case X", which parses, compiles, and is schedul
 then measures nothing when a real agent is finally handed it. `tools/generate-contracts.js` reads
 `buildPrompt` out of `test/eval-fragment-selection.js` now, the same way the trace witness already
 read its two prompts from its own harness, so a leg sends the prompt the suite sends. The contracts
-grew from around 20 kilobytes to around 90, which is what the trace contract already paid for the
-same correctness.
+grew from around 20 kilobytes to between 59 and 109, which is what the trace contract already paid
+for the same correctness.
 
 `test-review`'s request shape declared an environment permitting three API keys and forbidding `HOME`.
 The adapter closes the child environment to `PATH` plus what the request declares, and
@@ -284,9 +376,9 @@ Two path couplings closed with them. `runReview` states `--project-root` because
 
 Also done: `eval-trace.js`'s `runCase` probes `tea-trace-runner` (`cli/trace-runner.js`), the command the trace suite had no equivalent of. The runner's whole surface is a prompt on standard input and an agent run in the working directory. It builds no prompt and knows no vendor, and it declares `scoped-artifact-writes`, the one capability a trace run needs and a selection does not. The two workflow artifacts are the authorization's artifact map, supplied per run because each case stages its own workspace, and they come back tagged, so a file the run never wrote is `absent` and a missing artifact rather than an `existsSync` race. Both runner commands share one exit-code table in `cli/lib/runner-exit-codes.js`, because a caller holding an observation cannot tell which command produced it. `trace.contract.json` is the tenth contract, generated from `test/fixtures/trace-eval/ground-truth.json` with 26 oracles over the summary artifact, and `npm run test:contract-oracles` evaluates every one of them over the fourteen stored trace runs, under both fixture sets' oracles, and compares each with the `scoreRun` check it restates. The whole chain was verified with a stub vendor: `npm run test:probe-targets` spawns the harness itself, reads its result record back, and sees every threshold met on a correct run, a quality failure on a run that wrote a test, and a missing-artifact failure on a run that wrote nothing.
 
-The trace witness is a differential over standard input on one prompt value, `allow_gate`. The two plan steps share one prompt on purpose, since the harness names no fact about either set in it, so a differential between the two steps would attribute to the prompt a difference the staged workspace produced, and an invariance claim would be false because the two summaries differ. `allow_gate` is the one prompt value the corpus establishes an effect for: 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 workspace produce two `gate_basis` values.
+The trace witness is a differential over standard input on one prompt value, `allow_gate`. The differential is on that value rather than between the two fixture sets, because the seeded and clean summaries differ from the staged files rather than from the prompt, so a differential between the sets would attribute to the prompt a difference the prompt did not cause, and an invariance claim would be false because the two summaries differ. `allow_gate` is the one prompt value the corpus establishes an effect for: 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 set produce two `gate_basis` values. Both witness legs stage the clean set, which is what makes them clean legs for `seeded-faults-scoped`.
 
-Two more couplings, both found by running it. A relative `--agent-cmd` passed the harness pre-flight, which probes it from the harness's own directory, and then failed every run, because the runner executes in the staged workspace and a relative path resolves there; `parseArgs` resolves a path against the operator's directory now. And the trace witness legs are runnable only against a staged workspace of the seeded set, because the run's real input is the working directory, which the request shape cannot name; that is the same coupling `test-review`'s legs have with `--project-root`.
+Two more couplings, both found by running it. A relative `--agent-cmd` passed the harness pre-flight, which probes it from the harness's own directory, and then failed every run, because the runner executes in the staged workspace and a relative path resolves there; `parseArgs` resolves a path against the operator's directory now. And the trace witness legs are runnable only against a staged workspace, because the run's real input is the working directory; that is the same coupling `test-review`'s legs have with `--project-root`. Which set that workspace holds is in the request now: each fixture set declares its own `projectRoot`, the prompt is written against it, and `stagedWorkspaceFor` stages the set the leg names. Staging one set for every leg is what made the two witness legs seeded runs, which is the scoping failure `seeded-faults-scoped` reported against all three defect probes.
 
 One coupling worth naming, and it did not change with the scoring half: two of the entry points TEA
 reaches are addressed by file path into `dist/`, because neither the compiler CLI nor the evaluator is

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "bmad-method-test-architecture-enterprise",
-  "version": "1.25.0",
+  "version": "1.25.1",
   "description": "Master Test Architect for quality strategy, test automation, and release gates",
   "keywords": [
     "bmad",
@@ -137,7 +137,7 @@
     "eslint-plugin-n": "^17.21.3",
     "eslint-plugin-unicorn": "^60.0.0",
     "eslint-plugin-yml": "^1.18.0",
-    "eval-quality": "1.3.0",
+    "eval-quality": "1.4.0",
     "husky": "^9.1.7",
     "jest": "^30.0.4",
     "lint-staged": "^16.1.1",

package/test/contracts/trace.contract.json

@@ -2640,7 +2640,7 @@
                   "environment": {},
                   "stdin": {
                     "kind": "text",
-                    "value": "You are running the TEA workflow `bmad-testarch-trace` against the project in `project/`.\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}`: `project`\n- `{config_source}`: `project/_bmad/tea/config.yaml`\n- `{test_artifacts}`: `project/test-artifacts`\n- `{test_dir}`: `project/tests`\n- `{source_dir}`: `project/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 `project/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- `project/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- `project/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 `project/docs/`, `project/src/`, or `project/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."
+                    "value": "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."
                   }
                 }
               },
@@ -2654,7 +2654,7 @@
                   "environment": {},
                   "stdin": {
                     "kind": "text",
-                    "value": "You are running the TEA workflow `bmad-testarch-trace` against the project in `project/`.\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}`: `project`\n- `{config_source}`: `project/_bmad/tea/config.yaml`\n- `{test_artifacts}`: `project/test-artifacts`\n- `{test_dir}`: `project/tests`\n- `{source_dir}`: `project/src`\n- `{skill-root}`: `skill`\n- `gate_type`: `epic`\n- `decision_mode`: `deterministic`\n- `collection_mode`: `contract_static`\n- `allow_gate`: `false`\n- `coverage_basis`: `auto`\n- `summary_confidence`: `auto`\n- `coverage_levels`: `e2e,api,component,unit,live`\n\nThe trace target is the epic under `project/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- `project/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- `project/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 `project/docs/`, `project/src/`, or `project/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."
+                    "value": "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`: `false`\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."
                   }
                 }
               }
@@ -2738,7 +2738,7 @@
     "human-labels"
   ],
   "testData": {
-    "setup": "Each plan step stages one fixture set from test/fixtures/trace-eval/ into a disposable workspace: the set's files under project/, a resolved _bmad/tea/config.yaml whose test_artifacts points inside that workspace, and the bmad-testarch-trace workflow under skill/. ground-truth.json is never staged, and the harness asserts that no staged file carries its bytes or its keys before the run. The workspace is the authorization's working directory, and the prompt on standard input names project/ and skill/ and resolves every placeholder; it is the same text for both steps, because it names no fact about either set. That shared prompt is why the sensitivity witness differs its two legs on allow_gate rather than between the two steps: the seeded and clean summaries differ because of the staged workspace, so a differential between the steps would attribute to the prompt a difference the prompt did not cause, 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 the same reasoning that gives the fragment-selection contract for this workflow an invariance witness: the claim is moved onto an input the run demonstrably reads, and stated as what it is.",
+    "setup": "Each plan step stages one fixture set from test/fixtures/trace-eval/ into a disposable workspace: the set's files under its own project root (tenant-data-export/ for seeded-tenant-data-export, api-token-lifecycle/ for clean-api-token-lifecycle), a resolved _bmad/tea/config.yaml whose test_artifacts points inside that workspace, and the bmad-testarch-trace workflow under skill/. ground-truth.json is never staged, and the harness asserts that no staged file carries its bytes or its keys before the run. The workspace is the authorization's working directory, and the prompt on standard input names the project root and skill/ and resolves every placeholder against them. The project root is the one fact about the set the prompt carries, and it carries the epic the set traces rather than the set's role, so it says which set a leg is asking for and suggests no coverage status. The sensitivity witness differs its two legs on allow_gate rather than between the two sets: the seeded and clean summaries differ because of the staged workspace, so a differential between the sets would attribute to the prompt a difference the staged files produced, 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, over one staged fixture set, produce two gate_basis values. That is the same reasoning that gives the fragment-selection contract for this workflow an invariance witness: the claim is moved onto an input the run demonstrably reads, and stated as what it is. Both witness legs stage the clean set, because they are the only other legs this operation has and AD-10 reads them as its clean legs when it asks whether a seeded fault is scoped to its own leg.",
     "cleanup": "Delete the workspace. The corpus under test/fixtures/trace-eval/ is read-only and the harness digests it before and after every run.",
     "principals": null,
     "resources": null
@@ -2749,8 +2749,8 @@
     "maxCostUsd": "8.00"
   },
   "safetyLimits": [
-    "The runner writes only inside the staged workspace, and only its two deliverables under project/test-artifacts/; the harness fails a run that changed the repository or the staged corpus.",
-    "The run adds, edits, and deletes nothing under project/docs/, project/src/, or project/tests/. The workflow does not generate tests, and a run that did has moved the benchmark.",
+    "The runner writes only inside the staged workspace, and only its two deliverables under the fixture set's own test-artifacts/; the harness fails a run that changed the repository or the staged corpus.",
+    "The run adds, edits, and deletes nothing under the fixture set's docs/, src/, or tests/. The workflow does not generate tests, and a run that did has moved the benchmark.",
     "No credential value appears in a prompt, an artifact, a log, or a result file."
   ],
   "requiredEvidence": [

package/test/eval-contract-strength.js

@@ -36,9 +36,9 @@
  * test-review leg names its fixtures by repository-relative path and writes
  * `verdict.json` beside them, and the policy's `cwd` is what both resolve
  * against, so the fixtures are copied into the run directory and the artifact
- * lands there. A trace leg needs the seeded set staged, which is what
- * test/eval-trace.js already does for its own runs. A selection needs nothing on
- * disk at all.
+ * lands there. A trace leg needs its own fixture set staged, which is what
+ * test/eval-trace.js already does for its own runs, and the leg's prompt says which
+ * set that is. A selection needs nothing on disk at all.
  *
  * Usage:
  *   npm run eval:preflight                     # the live pre-flight, cached, nothing scored
@@ -49,9 +49,9 @@
  * Exit codes are read against `test/probes/expected-strength.json`, the same
  * baseline the deterministic gate compares to: 0 when every probe reached the
  * outcome the corpus records, 1 when a verdict moved, 2 when a pre-flight outcome
- * moved. Eight of the thirty-one probes cannot be pre-flighted today and the
- * baseline says so, so their failure is not news and does not colour the run;
- * one of them starting to pass is news, and so is one that stops.
+ * moved. Eight of the thirty-one probes could not be pre-flighted when that rule
+ * was written, and the baseline said so; all thirty-one pre-flight now, so a
+ * failure here is news and the baseline is what says so.
  */
 
 'use strict';
@@ -64,7 +64,7 @@ const { digest } = require('./lib/eval-record');
 const { validateArtifact } = require('./lib/eval-quality-inputs');
 const { createProbePort, hostEnvironment } = require('./lib/probe-targets');
 const { runSuite, sealContract, suites } = require('./lib/probe-scoring');
-const { stageWorkspace } = require('./eval-trace');
+const { stageWorkspace, traceArtifactPaths } = require('./eval-trace');
 
 const PROJECT_ROOT = path.join(__dirname, '..');
 const REVIEW_FIXTURE_DIR = path.join('test', 'fixtures', 'test-review-eval');
@@ -160,9 +160,13 @@ const slug = (suiteId) => suiteId.replaceAll(/[^a-z\d]+/gi, '-');
  * The run directory one suite's legs execute in, and the artifact paths that
  * directory makes true.
  *
- * A trace leg is staged by the trace harness itself, so the seeded set arrives
- * exactly as `npm run eval:trace` stages it, under the same `project/` prefix its
- * artifact override names.
+ * A trace leg is staged by the trace harness itself, so the set arrives exactly as
+ * `npm run eval:trace` stages it, under the same project root its artifact override
+ * names. Which set that is comes out of the leg's own prompt: each fixture set has
+ * its own project root and the prompt is written against it, so a leg that traces
+ * the clean set asks for the clean set. Staging one set for every leg is what made
+ * the contract's two witness legs seeded runs, which is the scoping failure
+ * `seeded-faults-scoped` reported against all three defect probes.
  *
  * A test-review leg is the coupling `docs/explanation/eval-quality-command-adapter.md`
  * records: its `--files` are repository-relative, its `--json` is a bare
@@ -177,20 +181,19 @@ const slug = (suiteId) => suiteId.replaceAll(/[^a-z\d]+/gi, '-');
  * A selection leg gets an empty directory, which is what its `read-only`
  * declaration is for.
  */
-function stagedWorkspaceFor(suiteId) {
+function stagedWorkspaceFor(suiteId, request) {
   if (suiteId === 'trace') {
     const groundTruth = JSON.parse(fs.readFileSync(TRACE_GROUND_TRUTH, 'utf8'));
-    const seeded = groundTruth.fixtureSets.find((set) => set.id.startsWith('seeded'));
-    const staged = stageWorkspace(seeded);
+    const prompt = String(request?.channels?.stdin?.value ?? '');
+    const set = groundTruth.fixtureSets.find((entry) => prompt.includes(`\`{project-root}\`: \`${entry.projectRoot}\``));
+    if (set === undefined) {
+      throw new Error('a trace leg sent a prompt naming no fixture set project root, so there is no set to stage for it');
+    }
+    const staged = stageWorkspace(set);
     return {
       root: staged.dir,
       cwd: staged.dir,
-      artifacts: {
-        'tea-trace-runner': {
-          summary: path.join('project', 'test-artifacts', 'e2e-trace-summary.json'),
-          matrix: path.join('project', 'test-artifacts', 'traceability-matrix.md'),
-        },
-      },
+      artifacts: { 'tea-trace-runner': traceArtifactPaths(set) },
     };
   }
   const dir = fs.mkdtempSync(path.join(os.tmpdir(), `tea-${slug(suiteId)}-preflight-`));
@@ -254,7 +257,7 @@ function cachingPort({ makePort, contract, cacheDir, agent, force, counters, log
         },
       };
       log(`  ${colors.yellow}running${colors.reset} leg ${request.probeId} (${key})`);
-      const { port: realPort, workspace } = await makePort();
+      const { port: realPort, workspace } = await makePort(augmented);
       const startedAt = Date.now();
       let observation;
       try {
@@ -334,8 +337,8 @@ async function runOneSuite(suite, options, stats) {
     port = cacheOnlyPort(cacheDir, [stats, suiteStats]);
   } else {
     port = cachingPort({
-      makePort: async () => {
-        const staged = stagedWorkspaceFor(suite.id);
+      makePort: async (request) => {
+        const staged = stagedWorkspaceFor(suite.id, request);
         const { port: realPort } = await createProbePort({ cwd: staged.cwd, interfaceIds, artifacts: staged.artifacts });
         return { port: realPort, workspace: staged };
       },