复核重点（自己做完再对照一遍）：Do the scenarios prove the effects (stored records, returned structure, log lines) or only echo the implementation? Are scripted model submissions realistic for the case-review pack (quotations copied from the real fixture text, finding codes from the closed set)? Is any scenario vacuous (passes when the feature is broken)? Mutation check: break the implementation in small ways and see whether a scenario fails.
规格
PACKAGE acceptance - the end-to-end proof on synthetic data. Everything is built; your job is to prove it works as a whole and to find what does not.
Use createTestHub() (hub/server/testing.ts), the real synthetic packs from packs/ (publish them through the real publishPack and assign them to test users) and the synthetic fixtures. A scripted model is a plain TypeScript function that produces submissions; drive the Hub only through its MCP interface with the official SDK client over loopback, plus the console over HTTP for scenario 12.
Write one test file per scenario 1-13 of docs/hub-r4-architecture.md section 9, each asserting real effects: returned structuredContent, isError, stored records (query the records package), the call-log lines, the objects on disk, the console HTML. Add: (14) knowledge sync over both name families and several versions with synthetic listing pages and command trees, idempotent on a second run and incremental when one build is added, the version diff between two roots showing only the changed subtrees; (15) FAMX and FAMY aliasing end to end: a run started with the product name FAMY and one started with FAMX lock the same line and the same catalog; (16) the whole review of a ~150-node mind-map fixture fetched through the stubbed agile system pack by external id agile:mindmap: with linked story and bug text bound as expected sources; (17) restart: stop the Hub process object, start a new one on the same data, previous runs and results are intact; (18) crash safety: kill the sandbox child mid-function and see an incomplete terminal with a reason, not a crash; (19) concurrency: ten parallel submit_result calls for different runs and two for the same (run, digest); (20) injected defects (section 6b of the brief): take the synthetic ~150-node mind-map fixture, inject known defects with scripts/real/benchmark/inject.ts (duplicate_title, empty_title, bad_priority, no_expected, two_expected, empty_expected, remove_negative; the module is plain TypeScript you may import in tests), run the case-review pack once on the untouched fixture and once on each mutated copy through the MCP interface with a scripted client that hands in every item as handled without findings, and assert the DIFFERENCE between the two results: the items the Hub's literal (structure and tags) requirement newly flags are exactly the items of the injected truth (every injected defect found, nothing else new), the document-level defect (remove_negative) shows up in the coverage fact when the pack has it, and a defect found on an item is attributed to that item and requirement; (21) a scripted model that cites a finding with a location that does not exist, a non-verbatim quotation, a command the catalog lacks as present, and a verdict inconsistent with its dispositions: each is refused or routed to repair exactly as the pack and the brief say, and the stored records show it; (22) the Hub-computed answers do not depend on the model: two different scripted submissions of the same items give the same fact-requirement terminals.
Then write docs/hub-r4-coverage.md: a table of every model element (node tools/show-element.ts --list) with milestone-1 status (implemented / contract only / out of scope), the files that implement it, the tests that cover it, and the open gaps. For every rule of the elements marked implemented, check the code or say plainly it is not implemented; this is an audit, be skeptical and list what you could NOT verify.
Mutation spot-checks: for ten important behaviours (receipt isError, partition disjointness, QUOTE_MISMATCH rejection, repair rounds, absent equals forbidden, route allow-list, login once, digest of a record, token revocation, claim validity binding) temporarily break the implementation in a scratch copy of the worktree outside the repo, confirm a scenario fails, and report each mutation and the failing test. Never leave a mutation in the repository.