[spec][Trinity S12] Consume canonical t27 contracts and prove clean-clone project reproduction #989

Parent epic: #988

Work package: S12. Canonical authoring repository: gHashTag/trinity. Proposed new paths become canonical only after S01 records ownership; extend existing domain specifications in place.

Problem

A set of specifications is not yet a recreated project. Trinity needs a consumer integration and independent evidence that a clean pinned checkout generates, builds and executes the declared project profile.

Existing work to reuse

• Canonical t27 specifications from this epic
• Existing Queen catalog and acceptance infrastructure

Related existing issues (not replaced):

• CI: main has no build.zig matching its own source tree (2217 files vs a build script from March) #616
• Eighteen workflows have never succeeded — 8182 runs, zero green #810
• Exposed API credential found in this repository #601
• apps/website divergence: the site publishes from trinity while tri-27 claims to be it — the live Queen game exists only here #974
• Turn the Queen dashboard into a one-screen strategy cabinet #890
• feat(fpga): add trinity-fpga as submodule + XVC WiFi JTAG flash pipeline #588
• "One source, four targets" has under 1% runtime coverage, and no tool compares all four on any spec t27#3004
• gen-c, gen-rust and gen (Zig) are not byte-deterministic: 1, 3 and 2 files differ between two identical runs t27#3006

Scope and deliverables

• Consume the canonical t27 manifest/specs byte-identically with pinned revision and compiler hashes; map retained adapters and external packages explicitly.
• Implement one documented clean-clone command for the approved headless profile, then separate optional web/native/FPGA/training/network profile runs.
• Publish a machine-readable capability -> spec -> generated artifact/adapter -> build/test -> evidence index; fail on drift, missing targets, swallowed exit codes and invalid artifacts.
• Refresh Queen's project/spec catalog from the verified manifest and publish website plus docsite together through the established publisher when release acceptance is met.

Acceptance criteria

• A clean runner without the developer's caches executes the entire declared profile; target compilation failure, failed assertion, missing output and partial/empty test graph all fail the gate.
• At least one end-to-end task exercises CLI/MCP, tri-api tool policy, state persistence and Queen lifecycle projection using declared fixtures, with independent expected outputs.
• Negative mutation of an output, spec hash, dependency, permission decision and test exit code is detected.
• Every capability is measured complete, explicitly blocked or intentionally excluded with reason. No coverage percentage uses catalog counts as executable coverage, and the epic closes only for its approved scope.

Every executable claim must name its source/spec/compiler/dependency revisions, actual command, generated artifact and checked runtime result. Catalog presence, source parsing, typecheck.ok, an empty test set or a module shell cannot substitute for this evidence. Declared/unsupported behavior must remain labeled.

Dependencies

gHashTag/t27#3563
gHashTag/t27#3564
gHashTag/t27#3565
gHashTag/t27#3566
gHashTag/t27#3567
gHashTag/t27#3568
gHashTag/t27#3569
gHashTag/t27#3570
gHashTag/t27#3571
gHashTag/t27#3572
gHashTag/t27#3573

Existing issue references are reuse/blocker links, not new ownership of their implementation. Assess the applicable upstream blocker before enabling a capability.

Audited implementation anchors

Trinity baseline: 03ae2f93f5af2fd4fa23e4c613a3c0e19ac51530; t27 baseline: bff21b85b206a0dd367876343e56dcd8312d81ba. Refresh the pinned inventory before implementing if upstream changed.

• build.zig
• .github/workflows/ci.yml
• apps/website/scripts
• apps/website/qa
• apps/website/public/t27/manifest.json