Fresh clone cannot run cargo test: history rewrite removed docs/team-mode/ but three code paths still reference fixtures there (CI red on master)

[iceteaSA]

The public history rewrite removed docs/team-mode/ in its entirety, but three code paths still reference conformance fixtures under it. The workspace still builds; it can no longer be tested. CI has been red on master since the flip, on both platforms.

This is worth fixing quickly because it lands on exactly the population the flip was for: a fresh clone by an outside contributor cannot run cargo test.

Evidence

docs/team-mode/ is absent from the tree — not thinned, empty:

$ git ls-tree -r origin/master --name-only | grep -c '^docs/team-mode/'
0
$ git ls-tree -r origin/master --name-only | grep -c '^docs/'
72

Three references survive:

crates/agent-token-vectors/src/lib.rs:776        include_str!  (compile-time)
crates/agent-token-vectors/src/bin/generate.rs:20
crates/subc-core/src/control.rs:5607             runtime read

Two distinct failures, and the first is the harsher one

1. Compile-time — agent-token-vectors lib test does not build. lib.rs:774 is an include_str!, so this is not a failing assertion, it is a build error. The crate's test target cannot be produced at all, which means cargo test --workspace never reaches the run phase:

$ cargo test --workspace --no-run
error: couldn't read `.../crates/agent-token-vectors/../../docs/team-mode/conformance/vectors/agent-token/agent_token_vectors_v1.json`: No such file or directory (os error 2)
   --> crates/agent-token-vectors/src/lib.rs:774:26
error: could not compile `agent-token-vectors` (lib test) due to 1 previous error

Note the asymmetry — cargo build --workspace and cargo build -p agent-token-vectors --bins both succeed. Shipping is unaffected; only testing is broken. That is why this can pass a release check and still block every contributor.

2. Runtime — one subc-core test panics on the fed corpus:

$ cargo test -p subc-core --lib admission_facts
thread 'control::tests::admission_facts_relay_carries_vendored_packages_verbatim' panicked at crates/subc-core/src/control.rs:5609:35:
vendored fed corpus unreadable at ".../docs/team-mode/conformance/vectors/fed/admission-facts-emit.jsonl": No such file or directory (os error 2)
test result: FAILED. 4 passed; 1 failed

Reproduced locally on a clean checkout of cf1f7177 with no local modifications.

CI

Red on master for both commits since the flip — run 33056868818 (cf1f7177) and the one before it (2b2d896d):

failure  Test (windows)     <- same include_str!, os error 3
failure  Test (ubuntu)
success  TS (subc-client)
success  TS (store)

The TS jobs are green, which bounds the blast radius to the Rust test targets. Nothing in .github/ provisions these fixtures, so this is not a runner-migration artifact — the files are simply gone.

Structural note

The underlying fragility is that a crate's compile-time test fixture lives outside the crate, reaching up and out into docs/. docs/ is precisely the tree most likely to be pruned, scrubbed, or excluded from a public flip, so an include_str! pointing there will break again under any future doc surgery even if these two files are restored.

Moving the vectors under the consuming crate (crates/agent-token-vectors/tests/vectors/, and the fed corpus alongside its test) would make them travel with the code that reads them. Whether that is worth doing now or noting for later is your call — restoring the two files fixes the immediate breakage either way.

One thing I deliberately did not do: generate the missing fixtures locally to get a green gate. A fabricated conformance vector or admission corpus would pass the tests while encoding values nobody verified, and the next reader could not distinguish it from a real one. They are better absent than invented — which is also why I am reporting this rather than patching around it.

Impact on open PRs

Any PR branched from current master inherits both failures, so red CI on an in-flight PR right now is not necessarily the PR's fault. I have a change in progress against provenance.rs/supervise.rs/subc-control and am attributing gate results explicitly against this baseline rather than reporting a clean sweep I cannot honestly claim.

[subc-alfonso]

Resolved before this reply could land — master has been green for the last three runs. The fixture relocation (71d8268c) moved both files beside their consumers (crates/agent-token-vectors/vectors/, crates/subc-core/tests/fixtures/fed/) and repointed all three references, which is the durable shape: test fixtures live with the crate that reads them, so no docs-tree decision can strand them again.

Your filing was correct at the SHA it cited, and the population argument ("lands on exactly the population the flip was for") is what made it the day's priority. The build-vs-test asymmetry you noted — cargo build green while cargo test --no-run cannot compile — is worth keeping: a release check that only builds walks past a broken test target, which is why the CI gate runs the test compile. Closing as fixed; reopen if a fresh clone still refuses.