How Theo’s systems are actually made

Theo’s public account is t3dotgg. Two repositories give useful, different views: T3 Code is a multi-client coding-agent application; Melee for Mac is a fork that its owner explicitly labels an automated experiment. The latter is particularly strong evidence of the workflow you are interested in: preserve a hard invariant, make verification executable, improve navigation and tooling, then integrate bounded batches with recorded results.

This report combines direct source inspection, GitHub PR and check-run metadata, and a small local execution of the Melee verifier tests. It does not claim that we rebuilt either application or reproduced their gameplay/performance results. The video was published July 21, 2026. Melee’s inspected changes are September 8, and many T3 improvements below are August or September; they show later applications of the ideas, not proof they were the exact implementation used during filming.

The strongest direct connections

T3 Code: boundaries that make agent work tractable

Read the architecture overview alongside the RPC contracts. The server owns workspace files, Git, terminals, and provider processes. Web, desktop, and mobile clients control that environment through authenticated RPC. Shared client connection/domain state lives in packages/client-runtime; provider differences live behind adapters. This localizes changes and makes ownership explicit. Authentication and per-method authorization remain distinct.

The event path is concrete in OrchestrationEngine.ts: a command reaches the decider; generated events, projections, and a durable command receipt commit in one SQL transaction; in-memory state and event publication follow commit. Reactors perform later external work. An acknowledgement therefore proves recorded intent, not finished work. Apply that distinction to a job queue, deployment, or import before considering whether your system needs event sourcing at all.

Tests have a separate completion mechanism. DrainableWorker.ts tracks outstanding work across enqueue and completion so drain waits for the current item as well as queued items. RuntimeReceiptBus.ts provides test milestones; its production implementation is intentionally a no-op. Do not mistake those runtime receipts for durable command receipts or use a test-only bus as production truth.

Their lint rules are working policy, with explicit limits

The plugin index registers six rules. vite.config.ts loads the plugin and selects severities/scopes. Examples:

• no-inline-schema-compile identifies selected immediately invoked Schema compiler calls inside functions, where recompilation is avoidable. Fixtures distinguish hoisted decoders and dynamic factory cases. It is configured as a warning, so the rule’s presence alone does not establish a blocking CI gate.
• no-native-title-tooltip visits JSX intrinsic elements and flags direct title attributes while allowing specific accessibility uses. It is an error. Custom-component props and spread attributes are outside this narrow check; it does not prove that every possible native tooltip is prevented.
• PR #9300 moves exception policy into configuration, updates stale per-file ceilings, and enables unused-disable reporting in the command CI actually runs. A rule with an obsolete exception budget can silently allow new regressions.

Apply: start with the runnable built-in-rule example. Introduce a custom AST rule only when an existing rule cannot express the failure. Test the forbidden case, legitimate exceptions, and the exact editor/CI entrypoint. Use diagnostics that identify the approved replacement.

Environment setup must be exercised, not merely documented

The test-t3-app skill describes per-worktree test state, the dev runner’s actual origin, and pairing/recovery. PR #5586, merged August 7, ties repeated agent setup failures to inherited service-launcher variables and contradictory instructions. The code now removes the misleading variables before starting a development server; the skill and root instructions agree on the intended workflow. Its session counts and timing range are the PR author’s audit, not measurements repeated here.

t3.json contains a worktree setup recipe. However, PR #10501 records that this recipe had not been imported for a particular saved project. A checked-in setup recipe was therefore insufficient to prove setup would run. Its .env symlinks are repository-specific; use your project’s existing scoped credential mechanism when adapting this pattern.

Apply: launch from a fresh worktree, verify the resulting origin and state directory, and test the actual configured entry point the agent will use. Keep the user’s working app and data distinct from the test instance. Record what is configured versus still manual.

Tool adapters must preserve the intended operation

PR #9128, merged September 2, fixes a skill picker whose output worked differently across providers. The Claude adapter translates the selected skill into the CLI’s native invocation shape and handles user-only/disabled discovery semantics. Inspect ClaudeSkillDispatch.ts and its neighboring tests. The PR reports behavior tested against a specific Claude Code version; do not treat that parser behavior as a timeless cross-provider standard.

PR #10501, merged September 8, addresses three real consumer failures: enormous snapshot text lost useful locators to truncation, non-object evaluation results broke structured output, and screenshots lacked a saved artifact path. The implementation bounds text, wraps evaluation results, and can save PNGs. Configuration can still be wrong even after the code fix.

PR #10572, also merged September 8, repairs a different ownership problem: a desktop-local recording path was unreadable by a remote agent. browserRecordingUpload.ts transfers the finalized file through the existing attachment path; the broker claims it in the agent environment. The PR reports a real transfer with matching hashes. I inspected that code and evidence claim, but did not repeat the transfer.

Apply: validate the operation from the consumer’s environment. A skill name appearing in a menu is not invocation proof; a returned local filename is not artifact-delivery proof. Keep useful structured detail and bounded readable output, and expose the resulting file to the intended recipient.

PR history: changes, dates, and evidence

The inspected T3 snapshot is 6c583620ff7a. The latest commit at the end of the video’s publication day is 23c18fda7a96; this is a day-level cutoff, not the exact recording time.

Four custom rules already appear in the July 21 plugin; the tooltip and mobile-theme rules are later additions. Both the July 21 and September 9 web package configurations select a unit test project. PR #2928 proves historical browser-test work; it does not establish that a dedicated browser-test job is still wired into today’s CI. The current application-testing skill describes integrated browser checks. The specific Twitch two-account sentinel described in the video was not located in these inspected public sources.

Melee: the verification command you linked

Your comparison contains 123 commits and 207 changed files at inspection. The fork is 123 commits ahead and 12 behind the compared upstream; its common ancestor is 05a1394faea2aac458e4bdd030621d8a5631ae62. These are moving-branch counts; the inspected fork head is a276aeb70f98.

The September 8 commit you linked adds a 75-line verifier and nine focused tests. It explicitly builds the final executable and report, runs the existing diff target, checks that required artifacts exist, and compares the output to the expected manifest hash. Failed commands stop success reporting even if an old artifact exists. This makes a precise outcome callable through one command.

The follow-up commit closes another false-success path: a matching executable can still link original objects where source work is incomplete. Its verify_report requires matching and complete code/data counts, matching functions, complete units, positive totals, and per-unit completion. The manifest is the fixed reference for this project, not something an agent should rewrite to obtain green.

The commit being accessible under doldecomp/melee does not establish an upstream merge. It is present in the fork comparison. The visible integration record is fork PR #1, which combines the verifier with matching-preserving cleanup and explicit documentation of what public CI cannot check.

What I executed locally

• The original verifier’s 9 tests passed.
• The inspected current verifier’s 15 tests passed.
• A synthetic comparison gave both implementations a matching fixture hash and successful mocked build/diff commands, with incomplete source measures. The initial verifier accepted it; the current verifier rejected it before printing success.

These runs validate the Python verifier behavior. Build commands were mocked and the fixture bytes were synthetic. They do not certify a real Melee executable, native application, gameplay, or performance. Guide 09 turns this into a general method for defining a completion contract.

Melee’s implementation path and supporting tools

The native runtime overview and build script show the actual path: produce and verify the GameCube executable, translate it and the disc loader into C with pinned recompilation dependencies, then compile ARM64 code against a Dolphin-derived compatibility runtime. This is static recompilation, not simply compiling the decompiled game C against native macOS APIs. Original memory-layout assumptions remain in guest memory. Strict native mode rejects uncovered CPU execution rather than silently falling back to a PowerPC interpreter or JIT.

Keep the invariants separate. A matching input GameCube executable does not prove that later rendering hooks preserve every native behavior. PR #12 adds predicted rendering between 60 Hz simulation updates and optional textures; its author explicitly leaves physical 120 Hz display validation open. PR #13 is open at inspection, and its lighting changes are not part of the inspected master snapshot. Its screenshot pairs and stated test conditions are evidence to assess, not proof we ran the game.

The earlier PRs provide a useful sequence of infrastructure improvements:

GitHub’s check-run API reports successful Linux/macOS/Windows tool tests, style checks, and a native-library build on the inspected heads of Melee PRs #12 and #13. Those public checks have no original game data and cannot establish a matching game build. For T3 #7209 and #10501, the relevant Check/Test runs succeeded; several preview jobs were skipped. Skipped preview jobs are not preview-validation evidence. Compact check snapshots were kept in the research workspace and are summarized here rather than reproduced.

What to take away

1. A completion contract: name the actual output, the source/input completeness requirement, and the consumer-visible outcome. Reject a plausible proxy result when it leaves the requirement unproved.
2. Small executable feedback: encode recurring mistakes in existing lint/type/test/build boundaries, then prove both rejection and legitimate success.
3. Explicit ownership: isolate agent writes and test state; put provider quirks behind adapters; verify remote artifact accessibility where it matters.
4. Calibrated knowledge: keep durable decisions and surprising constraints close to their relevant code. Use source maps as entry points and generated dependency data as evidence with known limits.
5. Evidence with provenance: distinguish local execution, remote CI, PR-author reports, and untested hardware. Keep source and native-output invariants separate.

These extend the four companion skills and the implementation guides. They do not justify a mandatory event-sourcing rewrite, copying Theo’s stack, or adopting another repository’s authority rules. Choose the smallest mechanism that fixes a recurring failure in your actual system.