MEGAEPIC: T27-native Trinity — eliminate foreign-language implementation and execute the platform through T27

Non-negotiable direction

T27 is the canonical implementation language for Trinity. All new first-party application logic, orchestration, agents, domain rules, UI behavior contracts, automation, tooling, tests, and build/deployment logic where feasible must be authored in T27 and executed through the T27 toolchain/runtime—not introduced as new Python/JavaScript/TypeScript/shell-script implementations.

Existing code in other languages is migration debt to inventory, classify, and progressively replace. This is a migration program, not permission for a big-bang rewrite. Keep the product working throughout, preserve externally required interfaces, and migrate in small verified slices.

Why

The model repeatedly generates conventional Python/JS scripts despite T27 being the project's intended language. This creates frustration, duplicated implementation paths, and weakens dogfooding. The repository must make the T27 path the easiest and default path for agents.

Scope

• Audit all first-party repositories and identify executable code, scripts, workflows, build tools, generated artifacts, and foreign-language dependencies.
• Establish a machine-readable inventory with language, path, purpose, owner/domain, runtime/dependencies, tests, replacement strategy, risk, and migration status.
• Make T27 the default for all new implementation and agent-generated code.
• Implement missing T27 standard-library, compiler, runtime, FFI/interop, process, filesystem, HTTP, Git, test, build, and deployment capabilities only when proven necessary by concrete migration slices.
• Port Queen/Bee orchestration and domain logic incrementally, preserving the existing deployed task lifecycle and data contracts.
• Port Python/JS/TS helper scripts to T27 where practical; eliminate scripts that duplicate T27 functionality.
• Ensure generated specs, code, tests, docs and examples are consistent with T27.
• Create a migration scoreboard and enforce the rule in CI and agent instructions.

Language policy

1. T27 is mandatory for new first-party executable logic.
2. Do not add a new Python, JavaScript, TypeScript, or shell script to implement project behavior when T27 can do the job.
3. Existing foreign-language code is not deleted until a T27 replacement passes equivalent tests and is deployed or integrated safely.
4. Exceptions require a documented ADR with the technical blocker, why T27 cannot currently perform the job, the narrowest possible foreign-language boundary, an owner, and a removal condition. Vendor-required declarative configuration and generated upstream artifacts are classified separately.
5. The enforcement is architectural: default to T27, prove the implementation, and record any justified exception.
6. Generated output is not accepted merely because a model produced it. Every migrated component needs tests, reproducible execution, and a verified acceptance criterion.

Workstreams / child issues

W0 — Canonical policy and agent behavior (P0)

• Update root and subproject agent instructions so all agents know T27-first is mandatory.
• Add a reusable code-generation skill: inspect existing T27 APIs first; implement in T27; never emit Python/JS as the default; if blocked, report the exact missing T27 capability and propose the smallest ADR-backed exception.
• Define the policy in a canonical .t27 spec and generate derived instructions from it where possible.
• Add negative examples and regression tests for model-generated Python/JS where T27 should be used.

W1 — Full foreign-language inventory (P0)

• Enumerate first-party repositories and all executable files, including scripts hidden in CI, package scripts, cron jobs, code generation, and local developer tooling.
• Separate handwritten business/runtime logic from generated code, vendor-required config, fixtures, and unavoidable external adapters.
• Produce a prioritized migration ledger with dependency graph and risk ranking.
• Do not claim the audit is complete until inventory is reproducible and coverage is measured.

W2 — T27 capability gap map (P0)

• Map each high-priority foreign implementation to the T27 capability it requires.
• Identify missing standard library/compiler/runtime features, FFI and OS interfaces, async/concurrency, filesystem/process/network APIs, test/build/deploy support.
• Prefer implementing reusable T27 capabilities over one-off ports.
• Add compile/run/conformance tests for each capability.

W3 — T27 execution path and tooling (P0)

• Establish one supported way to compile, test, run, debug, package and deploy T27 programs.
• Provide T27-native equivalents for common project operations (repo inspection, validation, test orchestration, code generation, build/release), using native T27 binaries rather than wrapper scripts wherever possible.
• Make errors actionable and machine-readable so Queen can repair them without falling back to Python.
• Ensure clean-checkout bootstrap works and document unavoidable external prerequisites.

W4 — Queen/Bee and agent orchestration migration (P1)

• Map existing deployed Queen supervisor behavior, task state machine, leases, retries, cancellation, evidence, review and publication before changing implementation.
• Port business rules and decision logic to T27 in verified slices; preserve the current production service until replacement parity is proven.
• Do not create a parallel queue, task database, worker registry, lease system, or review pipeline.
• Add differential tests comparing old and T27 implementations on recorded inputs and edge cases.
• Cut over only after parity, rollback, observability, and operational acceptance criteria pass.

W5 — Website, widgets, frontend and developer experience (P1)

• Inventory React/TypeScript/JavaScript behavior and distinguish runtime logic from browser/platform constraints and generated assets.
• Build T27-native contracts/components/rendering paths where feasible; where browser APIs require a foreign host boundary, keep the boundary narrow and documented rather than falsely claiming the browser can execute arbitrary T27 without a runtime.
• Keep widget specs as source of truth and generate presentation artifacts where the existing architecture supports it.
• Prioritize X Player, widget catalogue, Queen/Bee surfaces, course/onboarding and core development workflows.

W6 — Tests, CI enforcement and migration gates (P0)

• Add a scanner that flags new foreign-language implementation files and foreign-language executable additions in changed files.
• Allow explicit path-based exceptions only through an ADR/allowlist mechanism with expiry or removal condition.
• Add T27 compile, unit, conformance, integration, regression and smoke tests to CI.
• Ensure the scanner itself is T27-native when the needed filesystem/Git capabilities exist; until then, any bootstrap exception must be narrow and tracked as migration debt.
• Prevent accidental removal of still-required production functionality.

W7 — Model dogfooding and quality loop (P1)

• Build a benchmark set of representative tasks where the expected implementation language is T27.
• Measure T27 compliance, compile/test success on first attempt, repair loops, tokens/cost, runtime behavior and reviewer acceptance.
• Capture cases where models emit Python/JS despite instructions and turn them into regression fixtures.
• Feed corrected T27 examples, compiler diagnostics and APIs into the existing training/context/skill pipeline; do not claim model retraining unless an actual training run occurs.

W8 — Docs, examples and community standard (P2)

• Rewrite first-party examples and contribution guidance to teach T27 by default.
• Mark foreign-language legacy paths and migration status.
• Publish a T27 cookbook for filesystem, HTTP, Git, testing, async, build and deployment once each capability is verified.
• Remove stale examples that encourage avoidable Python scripts.

Migration order

1. Policy and reproducible inventory.
2. T27 capability gap map and build/test/run path.
3. Small low-risk scripts and duplicated utility logic.
4. Agent/domain logic and non-critical automation.
5. Queen/Bee orchestration in parity-tested slices.
6. Website/widget behavior and remaining platform-boundary work.
7. Runtime-critical components and high-risk cutovers last.

Definition of done

• A reproducible inventory exists for every in-scope repository and classifies all executable foreign-language code.
• Every new first-party implementation follows the T27-first rule or has an approved, narrow, documented exception.
• The policy is enforced in agent instructions and CI; violations are actionable and tested.
• Every migrated component has equivalent or stronger automated tests and a rollback path where production-critical.
• T27-native build/test/run tooling can compile and execute representative projects from a clean checkout.
• The migration scoreboard reports counts and risk-weighted progress by repository, language, and workstream.
• No claim is made that the entire platform is T27-native until the inventory and CI evidence support it.

Safety and compatibility constraints

• No big-bang rewrite. Maintain working production behavior while migrating.
• No deleting Python/JS/TS code before its T27 replacement passes tests and operational checks.
• No shelling out to Python as a hidden way to claim T27 execution; if an external tool is unavoidable, expose it as a narrow adapter and record it.
• Do not port third-party/vendor source or generated code blindly; classify licensing and regeneration requirements.
• Preserve security boundaries, credentials, data schemas, observability, and rollback.
• All claims about migration status must link to paths, tests, commits, and deployment evidence.

First deliverables

1. Canonical T27_NATIVE_POLICY.t27 spec.
2. Foreign-language inventory and dependency graph.
3. CI/agent-policy enforcement plan.
4. Prioritized child issue list, with each issue scoped to one migration slice.
5. Initial proof: replace one low-risk handwritten script with T27, run both against the same fixtures, and demonstrate parity.

Boundary

This epic sets the mandatory direction and acceptance contract. It does not authorize an unsafe immediate rewrite of all repositories, and it does not claim any migration has happened until a tested implementation is merged.