EPIC: Recreate Trinity from executable t27 specifications and verified project contracts

[gHashTag]

Outcome

Create the canonical, executable specification set and the consumer pipeline needed to reproduce the approved Trinity project profile from a clean checkout. This epic coordinates specifications, reuse of existing projects, generated/handwritten boundaries and independent acceptance evidence. It does not claim that the present corpus already generates the whole project.

Audit before planning (2026-09-12)

Inspected Trinity main at 03ae2f93f5af2fd4fa23e4c613a3c0e19ac51530, t27 at bff21b85b206a0dd367876343e56dcd8312d81ba, existing open/closed issues, and https://t27.ai/#/queen (COMB and PROJECT views).

• Trinity is a mixed implementation: dozens of Zig build artifacts, React/TypeScript web UI, Swift native UI, and pinned external packages. The five-binary/zero-dependency summary is not an accurate inventory of current main.
• Queen displays a public snapshot with 760 catalog/spec entries, 651 issues and five repository contributors: t27 575 specs, tri-net 113, trinity-fpga 64, Trinity 3, tt-trinity-corona 5. Those counts are observed snapshot data, not live GitHub counts or proof of executable coverage.
• Current Trinity's tracked tree has 31 .t27 files outside the website mirror, 947 .t27 mirror files, 764 .tri and 1,981 .vibee files. These extensions include different dialects and metadata forms; counts cannot be added into a generation claim.
• VSA and numeric implementations are already owned by zig-hdc / zig-golden-float; training is extracted to trinity-training. tri-net, trinity-fpga and tt-trinity-corona have their own specifications and work queues. The public Queen supervisor is a separate trios service.
• Existing t27 catalogs for skills/crons (specs: skills and crons as first-class .t27 specs t27#3544), agents (specs/agents: the 27-agent alphabet as first-class .t27 specs (layer 4) t27#3545), tools (specs/tools: the tri CLI and the MCP servers as first-class .t27 specs (layer 5) t27#3547), system docs (specs/docs: system documentation as declared .t27 document (7 chapters) + docs/system bodies + i18n docs-ru contract t27#3550) and viewport (specs/ui/viewport.t27: one viewport contract for the site's explorers (breakpoints, touch targets, QA matrix) t27#3557) are implemented work to extend, not rebuild. Trinity chore(spec): propose organism .tri specs (mozg + dna) upstream in t27 #604 already points organism contracts to t27.
• Existing compiler boundaries remain relevant: Zig-бэкенд: сигнатуры без тела делают вывод некомпилируемым (0 из 9 спек) t27#3472 (bodyless .tri Zig sample), "One source, four targets" has under 1% runtime coverage, and no tool compares all four on any spec t27#3004 (multi-target runtime coverage), gen-c, gen-rust and gen (Zig) are not byte-deterministic: 1, 3 and 2 files differ between two identical runs t27#3006 (nondeterministic generation), [spec] specs/memory/tmem: Trinity Memory contracts (types, Bridge, TensorPack, Stream Compute, Conformance Lab, Edge Demo) t27#3561 (experimental tmem). A WASM typecheck result or a module shell cannot establish runtime behavior.
• Main CI currently swallows a failed test command through tee: CI: main has no build.zig matching its own source tree (2217 files vs a build script from March) #616, fixed gate proposed in fix(ci): propagate test failures through tee (#616) #987. The full test graph must still be repaired; a green summary alone is insufficient.

Existing projects and canonical ownership

Repository	Role in this epic
gHashTag/t27	Language/compiler and canonical shared/project specifications; register proposed missing specs/trinity namespace in specs/OWNERS.md
gHashTag/trinity	Project consumer, Zig application/runtime integration, web/native adapters, reproduction acceptance; parent epic
gHashTag/tri-27	Extracted website snapshot/design work; current production source remains Trinity, tracked in #974
gHashTag/ghashtag.github.io	Existing t27.ai publisher; no source switch implied by this epic
gHashTag/zig-hdc / zig-golden-float	Existing numeric/VSA implementations consumed by pinned contracts
gHashTag/trinity-training	Existing training infrastructure; local HSLM placeholder is not a replacement
gHashTag/tri-net	Existing networking implementation/specs; adapter boundary
gHashTag/trinity-fpga / tt-trinity-corona	Existing hardware projects and physical-evidence boundaries
gHashTag/trios	Existing external Queen supervisor, accessed through documented contracts

The ownership choice follows t27's specs/OWNERS.md and specs/tools/README.md: author canonical contracts in t27, then re-vendor a byte-identical pinned copy into Trinity. Shared VSA/Queen/tools/docs contracts remain in their existing namespaces. New missing project-specific contracts may use specs/trinity only after S01 records ownership. No second authored source of truth is introduced.

Scope and execution order

S01 first records the complete capability inventory and the initial headless reproduction profile. Every shipped capability must have a disposition; optional native, website, training, network and physical-hardware profiles may have independent acceptance milestones. Scope cannot shrink silently to make a green result. Host adapters remain explicit until generation is actually demonstrated.

Foundation: S01 -> S02 -> S03. Core contracts S04-S08 follow their listed prerequisites. Queen S09-S10 and external adapters S11 reuse them. S12 integrates the complete approved profile and produces the evidence index.

Each child must start by comparing its existing canonical specs and open issues, reuse rather than duplicate them, and record exact compiler/source/dependency revisions. New specs require behavior bodies or explicit declaration-only status, schema/negative checks, target compilation and runtime assertions for executable claims. Raw credentials and private transcripts must never enter specifications or evidence.

Child issues

• [spec][Trinity S01] Define the canonical project manifest, ownership and coverage baseline t27#3563 — S01: Define the canonical project manifest, ownership and coverage baseline (depends on none)
• [spec][Trinity S02] Prove the executable t27 subset and compiler capability contract t27#3564 — S02: Prove the executable t27 subset and compiler capability contract (depends on S01)
• [spec][Trinity S03] Specify the build graph, pinned dependencies and generation provenance t27#3565 — S03: Specify the build graph, pinned dependencies and generation provenance (depends on S01, S02)
• [spec][Trinity S04] Define executable numeric, VSA and SDK compatibility contracts t27#3566 — S04: Define executable numeric, VSA and SDK compatibility contracts (depends on S01, S02)
• [spec][Trinity S05] Specify VM, TRI27 bytecode and host ABI behavior t27#3567 — S05: Specify VM, TRI27 bytecode and host ABI behavior (depends on S01, S02, S04)
• [spec][Trinity S06] Specify Trinity CLI and MCP commands from one verified registry t27#3568 — S06: Specify Trinity CLI and MCP commands from one verified registry (depends on S01, S02, S03)
• [spec][Trinity S07] Specify the tri-api agent loop, tool protocol and permission boundary t27#3569 — S07: Specify the tri-api agent loop, tool protocol and permission boundary (depends on S01, S02, S06)
• [spec][Trinity S08] Define durable sessions, memory and provenance using existing organism contracts t27#3570 — S08: Define durable sessions, memory and provenance using existing organism contracts (depends on S01, S02, S07)
• [spec][Trinity S09] Reconcile Queen phases and specify task leases, retries and evidence t27#3571 — S09: Reconcile Queen phases and specify task leases, retries and evidence (depends on S01, S02, S06, S08)
• [spec][Trinity S10] Specify Queen project views and snapshot/live evidence contracts t27#3572 — S10: Specify Queen project views and snapshot/live evidence contracts (depends on S01, S06, S09)
• [spec][Trinity S11] Specify adapters to existing training, network and hardware projects t27#3573 — S11: Specify adapters to existing training, network and hardware projects (depends on S01, S02, S03, S04, S05)
• [spec][Trinity S12] Consume canonical t27 contracts and prove clean-clone project reproduction #989 — S12: Consume canonical t27 contracts and prove clean-clone project reproduction (depends on S01, S02, S03, S04, S05, S06, S07, S08, S09, S10, S11)

Existing tasks to reuse (not replaced by this epic)

• Security incident: Exposed API credential found in this repository #601; source fix PR fix(security): load translator key from environment (#601) #986, revocation/history still separate.
• Build/test debt and CI purpose: 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; existing dev-enforcement PR fix(ci): rewrite dev-enforcement — it had never run a single job #786.
• Queen visual/release acceptance and publisher ownership: Turn the Queen dashboard into a one-screen strategy cabinet #890, apps/website divergence: the site publishes from trinity while tri-27 claims to be it — the live Queen game exists only here #974.
• FPGA integration: feat(fpga): add trinity-fpga as submodule + XVC WiFi JTAG flash pipeline #588. Organism source pointer: chore(spec): propose organism .tri specs (mozg + dna) upstream in t27 #604. Experimental memory: [spec] specs/memory/tmem: Trinity Memory contracts (types, Bridge, TensorPack, Stream Compute, Conformance Lab, Edge Demo) t27#3561.
• Compiler fixes/evidence: Zig-бэкенд: сигнатуры без тела делают вывод некомпилируемым (0 из 9 спек) t27#3472, "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. Broad language roadmap [EPIC] t27 Language Roadmap: 12 workstreams (R-TT completion -> Trinity provenance) t27#1219 remains separate.

Epic acceptance

• Canonical inventory, ownership, dialects, targets and explicit scope approved and versioned.
• Each in-scope capability has an executable contract or an explicitly declared host/external adapter with independent conformance evidence.
• Pinned clean-clone generation/build/test completes for every enabled profile; missing/partial work fails visibly.
• Source, spec, compiler, dependency and artifact hashes tie each claim to an actual run.
• Queen renders the same project identities and evidence states, with snapshot/live distinctions and verified desktop/mobile paths.
• Existing security, compiler, build and hardware blockers are resolved for any capability claimed complete; unknown is not pass.

Repository analysis was read-only except for the separately linked remediation PRs. GitHub Projects boards could not be inventoried because the current token lacks read:project; this epic uses native issue/sub-issue relationships and does not invent or create another board.

Source anchors

• Build targets, pinned packages, Trinity facade.
• TRI27 validation path, Queen cycle.
• Catalog manifest, discovery-only shared core.
• Canonical spec owners, existing tools editing contract.