Epic: t27o as a service -- golden specs for every repo that installs the Trinity app, with zero LLM tokens #8998

Owner idea, 2026-10-11 (translated): everyone who installs our app in a repository can get golden specs, without spending tokens.

The idea

t27o (Ouroboros) is written in t27 and compiles to a plain native binary. It converts lower.rs in 0.12 s, and its core is deterministic:

• parse;
• skeleton;
• contract;
• oracle;
• reuse lookup (DRY);
• behavioural equivalence check;
• emit .t27.

No LLM runs in that path, so producing a golden spec costs zero LLM tokens. The only cost is compute. That compute runs in the user's own GitHub Actions: the app installs a workflow, and the workflow downloads the signed t27o binary, runs the oracle on the user's code in the user's CI, and opens a PR. So it costs us nothing and needs no servers. We never execute untrusted code on our labs. There is no licence question, because the owner converts their own code in their own repository.

A golden spec

A golden spec is a .t27 spec that:

• is behaviourally equivalent to the original on the oracle vectors and the translated tests;
• reuses existing t27 code instead of copying it;
• is sealed;
• carries a Sigstore attestation from the producing workflow run.

Golden means "equivalent on N recorded vectors and tests", not a proof for all inputs, and the report says so. Everything that does not qualify goes to the report with its refusal reason, also token-free. The bee/LLM fallback (see #8969) is opt-in.

Honest limits

• Coverage. Today about 17% of functions on plain Rust (see t27o (Ouroboros): Rust front end MVP -- skeleton, normalisation and a rustc oracle, written in t27 (Closes #8966) #8970). The target is 40-60% on ordinary code after t27o (Ouroboros): next Rust subset steps, ranked by the refusal table #8968, the Zig and Python front ends, and the std table.
• Out of reach. I/O, networking, async, unsafe, FFI and GPU code stay in the report until t27 expresses them.
• Scope. GitHub Apps act only where installed. We never open PRs in repos that did not install the app; anything else would be spam under GitHub's acceptable-use rules.

Plan

• t27o (Ouroboros): Rust front end MVP -- skeleton, normalisation and a rustc oracle, written in t27 #8966 t27o MVP (Rust front end, skeleton, oracle) -- PR t27o (Ouroboros): Rust front end MVP -- skeleton, normalisation and a rustc oracle, written in t27 (Closes #8966) #8970
• t27o (Ouroboros): next Rust subset steps, ranked by the refusal table #8968 next subset steps (cfg, Result/?, read-only String/Vec, tuple structs, std table, use for reuse)
• t27o (Ouroboros): CLI tri t27o <file.rs> with --oracle/--check (net <= 0 hand lines) #8967 CLI tri t27o
• t27o: Zig front end, with a round-trip check over our own corpus via gen-zig #8994 Zig front end + round-trip over our own corpus via gen-zig
• t27o: Python front end, with types inferred from oracle traces #8995 Python front end (the largest foreign debt in our repos)
• t27o: ship a standalone signed binary and a GitHub Action (runs in the user's CI) #8996 standalone signed binary + GitHub Action (runs in the user's CI)
• Trinity GitHub App: install -> t27o workflow -> golden-spec PRs, plus the golden criteria in .t27 #8997 Trinity GitHub App integration + golden criteria in .t27 + badge
• t27o (Ouroboros): refused bodies become bee issues with skeleton, callees and oracle vectors #8969 opt-in bee fallback for refused bodies (the only token-spending part)

Rollout:

1. Our own repos (t27, trinity, trios, BrowserOS, 999-multibots), which also pays down the only-t27 debt everywhere.
2. Opt-in for external repos.

Related:

• see Epic: t27b builds itself -- ELF, C-ABI bridge, self-built modules, fixed point #8951 (t27b builds itself)
• see AGENTS.md: the matryoshka rule -- every layer is generated from .t27 and compiles itself #8920 (the matryoshka rule)
• see AGENTS.md and the t27b-loop skill: DRY -- never add a spec or function that already exists #8963 (DRY)

User Scenarios

• Given a repository owner installs the Trinity GitHub App, When the app's workflow runs t27o on the repository's code in the user's GitHub Actions, Then a PR is opened containing zero-token golden .t27 specs with Sigstore attestations for functions that pass behavioural equivalence on oracle vectors and translated tests.
• Given a repository with Rust code containing I/O, async, unsafe, or FFI, When t27o analyses the code, Then those functions appear in the refusal report with documented reasons and no LLM tokens are spent.

Requirements

FR-001: t27o MUST compile to a standalone signed native binary that runs in the user's GitHub Actions without external services.
FR-002: The Trinity GitHub App MUST only act on repositories where it is installed and MUST open PRs with golden specs sealed with Sigstore attestations from the producing workflow run.
FR-003: Golden specs MUST be behaviourally equivalent to the original code on oracle vectors and translated tests, MUST reuse existing t27 code via DRY lookup, and MUST carry a refusal report for non-qualifying bodies.
FR-004: The bee/LLM fallback for refused bodies MUST be opt-in only and MUST be the only token-spending path.

Success Criteria

• t27c specs/tools/mcp/trinity.t27 exits 0
• t27c specs/account/repo.t27 exits 0
• 5 tests pass for golden spec generation on the t27 repo corpus (specs/tools/mcp/trinity.t27, specs/account/repo.t27)
• Signed t27o binary executes in GitHub Actions workflow and opens PR with .t27 specs and Sigstore attestation (exit 0)

Boundary

• specs/tools/mcp/trinity.t27
• specs/account/repo.t27
• .claude/agents/trinity.md
• .github/ISSUE_TEMPLATE/epic.md
• docs/wave_ecosystem_2026-07-08/EPIC.md