I tried several agentic terminals, including cmux, herdr, and vibe island. Each had ideas I liked, but none fit how I work. They all centered the agents. I needed a terminal centered on my attention because attention is scarce. My day turns on what should I drive to closed today? No screen kept the answer visible and easy to read.
I've also been living the "you can build anything you can imagine" narrative long enough to know that itch to build something for myself. I resisted it for quite some time before finally saying fuck it and spinning up my own. pt is a terminal cockpit for a single operator, written in Go. It does four things. It keeps a ranked answer to what should I drive to closed today on screen at all times. It gives work to AI coding agents. Each agent works in its own copy of the repo and receives an explicit list of files it may touch. When a worker reports completion, pt re-runs the checks and rebuilds the change from the files on disk before opening a pull request. As of this week, pt also runs workers on rented cloud machines and uses them to build its own features. My job then shrinks to reviewing pull requests. After ten days and more than 500 commits, pt has 89 internal packages. The test suite accounts for more than half the code.
This post is a blueprint and a retro in the same spirit as the ctx drawing. It covers the kernel, the factory, the failures that shaped them, and the result. After nearly 400 merged PRs in two weeks, the factory could prove that it built its own features. I still wasn't using it to drive my workday. The last sheet covers the two capabilities that stuck. It also explains why they point to ctx and what replaces the experiment.
Attention first, agents second #
Every agentic terminal I tried centered the agent conversation and pushed my work state to the edge. That structure was backwards for my work. Four PRs, two agents, a ticket, and a half-finished thought could all be open at once. Nothing on screen showed which one would close today. Model quality had almost nothing to do with this constraint.
I gave a talk at AI Engineer London, Untethered Productivity, about working away from the desk. I use voice at 179 words per minute. Agents keep working while I walk the dog, and a watch shows the trail of what they did. pt is the desk side of the same stack. The cockpit endpoint in sheet 10 connects the two by serving the same deck to my phone.
pt's north star doc states its product law, and reviews enforce it. The home surface answers what should I drive to closed today. Closure follows a chain (PR → merge → deploy → verify → ticket). Work counts as done only after that chain has receipts end to end. The deck ranks a finite set of commitments. It has panes for sessions, research, artifacts, and a coach inbox. An attention surface that lies about freshness is worse than no surface. The header therefore reports data age as CACHE
, STALE
, REFRESHING
, or LIVE
.
The PR pane is the core feature because it matches my current work. Demand for shipped software has only grown. During a working day, I move features through upwards of ten codebases by iterating, testing, verifying, and releasing. At that volume, any PR I must remember stalls. My standalone pr-babysitter streams every open PR across every codebase into pt. It ranks them and resolves their checks, reviews, and mergeability. A few keystrokes assign each PR a disposition. Babysit tells agents to handle reviewer findings, failed tests, and other red checks until the PR is green. Auto-merge tells the system to ship a well-understood, important change when it is ready without showing it to me again. Every PR on the deck has a decision for the machinery to execute.
Two more laws apply throughout the system. The deterministic core works offline. Every pane renders from durable local state before consulting a network or model. Automation also requires consent, so pt never silently expands its authority. That law is why the proactive layer was built last instead of demoed first.
One bus, receipts everywhere #
Every pane uses the same components. Work contracts follow an 8-state lifecycle (drafted → dispatched → running → verifying → delivered / needs_input / failed → closed) and live in SQLite behind an event outbox. A typed event bus carries metadata-only events. Projections reduce the event log into the data each surface needs. Those surfaces include the attention inbox, the fleet table, the debrief window, forensics ("where did attention actually go this week"), and the chronicle (a publishable draft of what the stores can account for over a window).
"Unified system bus" often means that someone imported a pub/sub library. pt's writers append domain events to an outbox in the same SQLite transaction as the state change. This transaction creates the state and event together. Consumers use leased, durable cursors. If a projector dies during replay, it resumes where it stopped and avoids applying an event twice. Events contain only metadata such as IDs, states, and digests, which keeps the bus from becoming a second source of truth. A filterable artifact ledger stores artifacts from every chat, tool, lane, and PR behind one query surface. Finding "the thing that agent produced Tuesday" takes one filter.
The receipt system covers every stored claim, including a decision, closure, verification verdict, or delivery. Each claim carries a sha256 over its canonical JSON. Readers independently re-derive the digests from that JSON. pt decisions
verifies every receipt as it prints and marks each row as verified or corrupt. SQLite integrity was never my concern. Agents now write data, so each record needs independent byte-for-byte verification. That makes the records usable as an audit trail.
What Go actually buys here #
Sheet 10 covers my repeated question about using TypeScript. The engineering answer is that pt has a fan-out workload, and goroutines make fan-out nearly free. During one refresh, pt sweeps GitHub for ranked PR checks, reviews, and mergeability. It walks the process table and lsof
output to inventory live agent sessions across five CLIs. Those are Claude Code, Codex, Crush, Pi, and OpenCode, each with a transcript format that pt parses natively. The same refresh polls Firecrawl research jobs and tails SQLite stores. Contexts make every task cancellable. This required no job queue or worker-pool framework. When ten lanes, the delegation unit defined in sheet 04, verify at once, each claims a worktree through a lease that records its hostname and pid. pt immediately reclaims a stale lease only if the hostname matches and the process is provably dead. All other stale leases wait out their TTL. Goroutines, SQLite, and about a page of code provided correct multi-host behavior.
Go also simplifies distribution. GoReleaser produces one static binary per platform. It needs no runtime or node_modules, and modernc.org/sqlite
removes the need for cgo. pt
on my PATH is the last green release. pt-dev
is an atomic, commit-stamped build of the checkout I am testing. The installer builds a temporary file beside the destination and verifies the embedded commit. It includes -dirty
when the tree has uncommitted work. Only then does it swap the new file into place, which prevents a broken build from replacing a working one. A release workflow turns every merge to main into a tagged release, oldest first. It stops when no unreleased merges remain.
I also had history with Go before LLMs got faster than me. git-xargs, my tool for running one command or script across many GitHub repos, came from that period. So did my interest in Charm's projects. In 2022, I built Tea Tutor, a quiz app served over SSH with Bubble Tea and Wish. In 2023, I wrote about a Bubble Tea state-machine pattern that I used for multi-step deployment tooling at work. When I chose a foundation for pt, I already knew and admired this open source base. It had every package I needed to style the harness into a place I wanted to work. That history pushed me toward Go.
The TUI runs on Bubble Tea v2 and Lipgloss. Golden-frame tests cover three widths. A PTY driver, pt see
, types a keystroke script into the compiled binary and asserts on the screen contents. A design-gate palette ratchet fails CI if a stray color appears. A legibility budget decides whether each cell renders a mark as pixel art or braille. These tools let an agent inspect the screen while fixing a UI bug.
A keystroke starts the live capture engine, which copies the terminal session into a timed cast. An optional VHS pipeline renders casts to MP4 when vhs
, ttyd
, and ffmpeg
are on the PATH. For days, MP4 rendering failed to complete end to end. The pipeline fell back to a cast and a manifest, so it never lost a recording. It first rendered the night before this drawing shipped. That result collapsed the TUI. pt sized the VHS canvas using my terminal's 8×16 cell metrics, but VHS renders about 10.2×19.4 per cell. The 39 rows of absolute positioning then landed in a 31-row terminal and broke the layout. Measuring VHS's real grid produced the correct 184×40 geometry and the clean render below. The generator fix is filed as pt #492. The full flow now runs inside the TUI. I can record with a keystroke, then use the recordings surface to render, open, or copy the path without leaving pt.
Lanes: delegation with receipts #
After several worse versions, the delegation machinery settled on one issue, one worktree, one branch, one contract, one PR per lane. I call this machinery the factory. A lane request freezes the exact 40-character base commit and gives the worker an explicit set of paths. It also names the verification commands and sets a budget and deadline. The dispatcher moves the contract through its lifecycle, starts the worker CLI, and drives it through a typed event stream. The worker can use Claude Code, Codex, or my gateway wrapper. Each runtime handles credentials differently. For subscription-backed workers, pt scrubs provider environment prefixes so a metered API key cannot silently replace the seat I already pay for. The gateway worker receives exactly the credential envelope it was given and a hard cost ceiling it cannot exceed.
Delivery works differently from most systems. The worker leaves its changes uncommitted because pt builds the commit. Verification runs the declared commands in the lane's worktree. Publication then recaptures the granted files through no-follow file descriptors, so it will not follow a symlink swapped in by a malicious or confused worker. pt digests the files and compares them with the delivered attestation. It creates Git blobs from those exact bytes, advances the branch, and opens the PR. The receipts come from the filesystem that the worker left behind, so a false success report cannot pass. Publication can also be retried independently. If Git or GitHub fails after verified delivery, a reconciler derives the same commit and PR from the durable contract without another model call. Repeated retries produce the same result without creating forks.
A wave uses one safety invariant. Concurrent lanes cannot hold overlapping path grants. This keeps ten parallel agents from overwriting each other's files. Semantic conflicts between changes appear later, when CI and the merge train verify each PR against the new base. This invariant also cost me more calendar time than any other part of the project, as sheet 06 explains.
The patterns that stopped being temporary #
After ten days of agent work in this codebase, some conventions remained scaffolding while others became structure. The following choices survived dozens of unattended sessions. I would use all of them again before writing a feature.
Three-valued exits, and unknown is never a guess. Every verification command exits 0 for pass, 1 for fail, or 2 for unknown. The code handles each state differently. A GitHub outage exits 2 and remains unknown through the pane header. When an external system is unavailable, pt reports an explicit unknown. Because agents apply defaults at scale, this refusal to guess became the most useful design decision in the repo.
Strict inputs, bounded everything. Every manifest and config uses DisallowUnknownFields
, a size cap, and a schema version. A stale key causes an immediate error. Outputs have similar limits. Projection text has a byte cap, lists have maximum lengths, and the CLI enforces a JSON schema for worker handoffs. Agents produce plausible-looking data at high volume. pt rejects mismatched data at the boundary and returns a clear error.
Deterministic identity for idempotency. Contract-store commands use IDs derived from the contract and operation, such as commandID(contract, "deliver")
. A retry retrieves the previous result and avoids applying the operation twice. The approval recorder derives request identity from the contract ID and the revision that blocked. Retrying the same transition is byte-identical. A later block on a new revision gets a different request. All write operations are safe to retry.
Closed vocabularies. Failure codes such as lane:supervisor_lost
and lane:worker_needs_input:verification_failure
are closed enums with Valid()
methods. The merge-train planner's exclusion reasons, input reasons, and work shapes use the same pattern. The linter requires exhaustive switches for all of them. Provider prose is transient. Durable failures receive typed codes that I can grep at 2am.
Every external edge is an injected seam. GitHub, the model CLIs, the verification runner, tmux, and the clock all sit behind interfaces. The top level wires in the production implementations. Most codebases apply this standard practice only partly. pt applies it throughout because agents write most of its tests. An agent can test the dependencies it can fake.
The discoverability gate. A command ships only when it appears beyond the switch statement in main.go
. One table in usage.go
feeds pt --help
and the unknown-command error. A test fails if any command lacks a README reference row. One night, an agent wired a feature, but verification refused delivery because that row was missing. The gate caught the exact omission it was designed to catch.
** pt doctor as a contract with my future self.** It reports one line per dependency in three groups. Executables include the install command that fixes each one. Secret checks test only for presence because pt never reads or prints a value. Live probes prove provider authority. An installed CLI without a login is only half a dependency. Each repeated setup problem became a doctor line that I no longer had to remember.
The islands, and building it backwards #
Hardening the loops, lanes, and factory for parallel feature development took far more wall time than any feature. For a while, the failure mode was unclear.
The machinery worked. Thirty merged commits carry Co-authored-by: PT Lanes
. Feature integration stayed flat, and a codebase review found the structural cause. Every lane in a wave needs disjoint path grants. Shared files such as cmd/pt/main.go
prevented any lane from touching the wiring. Agents produced isolated leaf packages with 90% test coverage throughout the day. At the low point, 34 of the then-82 internal packages were finished and tested but imported by nothing. The gym and phone cockpit projection were built but inactive. The approvals engine and merge-train planner were also inactive. Integration remained a manual task, while I kept assigning more leaf packages.
The fix required zero machinery changes. The overlap check is pairwise within a wave. A wave with one lane holding broad grants to cmd/pt
, the target package, and the README had always been legal. The invariant allowed one broad-grant integration lane at a time.
The slow start also prevented pt from hosting a real workday. Its job is to rank the deck, dispatch lanes, and drive commitments to closed. The loop took so long to harden that I never ran one real work block inside it. I built the larger system before proving its core workflow. For most of the project, building the tool fragmented the attention it was supposed to organize. If I ran the project again, I would force one ugly end-to-end work block through in the first days. Everything else could harden after that.
This creates a design choice for a new AI-era codebase. You can build the factory loop first and use it to build the rest of the system. You can also put the factory in a generic layer above every repo. In my experience, the loop pays rent quickly once it closes. Closing it still required deep, repo-specific work on verification and publication that a generic layer cannot supply. The execution substrate, including sandboxes, orbs, worktrees, and schedulers, is generic and should be rented or reused. The verification layer defines "done" and controls merges for a specific repo, so it belongs to that repo and should be built first. Autonomous work depends on this definition of correctness. Improving harness performance before adding repo-specific verification increases the rate of plausible invalid changes.
The night it wired itself #
The corrected pattern first ran for real one night. The full account is its own post.
A solo broad-grant lane wired the orphaned merge-train planner into the CLI in PR #446. It used $1.32 of seat time and took about seven minutes. The previous attempt cost $1.25 to learn the grant recipe. The discoverability gate from sheet 05 refused it because I had not given the worker access to write the README row. The corrected grant recipe then produced closures, per-PR care state, and the decision log. It wired crash recovery into startup and added approvals to every blocked contract. It also added pt cockpit serve
, pt's first network listener, which put my real day on my phone as JSON. By the end of the night, twelve PRs had merged for roughly six dollars total. Two streams ran in parallel once I understood that disjoint grant sets can run concurrently.
The evening also tested the consent and receipt rules beyond my written tests. While on battery, my laptop entered Maintenance Sleep and killed two workers during their contracts. The contracts ended as typed failures. I recovered the finished work from one by using the documented operator-pickup path. Using the new crash recovery found a bug within the hour. Contracts that had expired before the sweep existed poisoned every startup, and one poisoned orphan blocked all dispatch. I found the cause and fixed it that night. A typed error pointed to the correct line. Merging on lane receipts also allowed lint debt through, which the next PR's CI caught. I then added the linter rules to the worker brief in the lane recipe. The structural fix for the sleep kills landed before this drawing shipped as pt #504. The dispatcher renews a heartbeat while it drives, and the sweep trusts that heartbeat over the wall clock. This prevents that class of long-runner kill.
Each failure that night left enough typed data to understand and recover the work. Failure without receipts is a debugging session; failure with receipts is a changelog.
The scenario library is the asset #
A working dispatch loop takes a weekend. Verification and recovery consumed most of the schedule. The acceptance gate on each work item determines whether unattended hours produce integrated features or plausible garbage. Building those gates is slow, cumulative work that requires a person.
pt uses a machine-enforced golden catalog. Every horizon feature has a falsifiable rent gate, which defines the observable outcome that proves the feature earns its keep. It also has a reachability test. CI fails if the catalog cites a package as landed evidence and that package has zero importers. The catalog records the gap between pt's capabilities and the capabilities that have proved useful. Dozens of items say implemented
while their rent verdicts remain unknown
. A receipt for primitive execution leaves the feature's value unknown. The repo records this gap. The reachability gate exists because the islands stretch showed that "implemented" and "reachable" can drift 34 packages apart.
The resulting operational rule requires a human-approved acceptance scenario before any work item enters an unattended queue. Cross-cutting gates such as the README row, errcheck, and exhaustive switches go in the worker's brief before the PR. I now spend more evening time curating gates than reviewing diffs.
The memory it plugs into #
ctx owns my memory. pt connects to it over MCP Streamable HTTP as another client. Briefings and recaps flow into the coach and debrief surfaces. Before outbound text leaves the process, pt scrubs six secret-shaped patterns from it.
This separation was useful before pt could do anything useful. Building pt took dozens of sessions across machines and agent CLIs. ctx remained live throughout the project. Each session started with the decisions, gotchas, and lane recipes learned by earlier sessions, regardless of which tool or laptop I opened. pt is the first project I have built without re-explaining the context because the memory layer existed first.
ctx also gave pt its credential model. ctx is my secret manager, and its vault mints short-lived keys on the server for a named purpose. I had built this pattern and documented it in the ctx drawing before pt existed. pt did not need to build secret management. It could assume low-trust remote access to one central store. I have never pasted the same API key onto each machine in this project. Inside pt, a secret exists only in the environment of an unstarted exec.Cmd
. pt never persists or logs it, and the audit contains only metadata. Subscription runtimes have their provider environment prefixes scrubbed, as described in sheet 04. Worker machines hold no standing credentials. This became a practical requirement when workers moved to rented orbs that I will never see. The systems are separate enough that either can be replaced independently. pt runs work using information and credentials supplied by ctx.
The rewrite I kept not doing #
I repeatedly considered rebuilding the project as a unified web codebase on Bun. One TypeScript tree could support the rich visuals I want for image-gen galleries and research panels, then produce per-platform distributions from the same code. The idea returned whenever progress stalled and looked like an architecture decision.
Each stall came from loop hardening or integration debt, both independent of the language. The Go code caused none of these stalls. A serving interface answered the visual question. The Go core serves projections, and each interface renders them. pt cockpit serve
is the first implementation. It builds a bounded, versioned, phone-sized JSON snapshot for each request over plain net/http
. Richer web surfaces can use the same interface. A local web view can render image galleries, and a reading pane can render research from projections already maintained by the kernel. This approach keeps the binary, goroutines, PTY tests, and eighty-nine existing packages while using web interfaces where they fit.
If you are considering the same rewrite, write down the problem it should fix. Then check whether one serving endpoint solves it. That worked for my project. The endpoint took ninety minutes, and an agent wrote it.
Proactivity on consent, and the factory leaves the laptop #
The staged vision has remained the same since I wrote the golden list. Version 1.0 makes attention legible. Version 2.0 makes delegation trustworthy, 3.0 makes it compound, and 4.0 makes it unprompted. Success means that the number of prompts typed per day trends toward zero.
The proactivity layer is designed but disabled. Standing orders convert a repeated prompt into a stored rule. They currently run only in dry-run mode, and every evaluation emits a metadata receipt. A trust dial expands autonomy after verified success streaks and reduces it after failures. It always stays within an envelope I approved beforehand. An escalation ladder enforces a minimum approval level for external writes. A night shift can only draft a question for the morning. The law in sheet 01 requires consent at every rung. Operating the manual version each day shows me which actions I would approve before I wire them. The learning loop uses the same approach. Merge outcomes currently reorder coach proposals, which is the one closed loop. The gym stores verified contract outcomes as eval cases. It refuses to score deliveries against their own evidence because self-scoring would report a win rate of 1.0 forever. The repo records that reason. The apprentice converts my corrections into candidate steering rules, but nothing applies them yet. The machinery labels these incomplete components as half-built.
The factory began moving off the laptop while I worked on this drawing. Local lanes die when the laptop lid closes. The Maintenance Sleep incident in sheet 07 killed two workers during their contracts. The flat-cost part of the solution is still ahead of me. A home server, which pt already cross-compiles for Linux, would own the state and run the shift. It would alternate parallel build waves with singleton integration waves overnight, following FIG. 4 on a timer. The MacBooks and my phone would become thin clients over the cockpit's HTTP surface.
Burst execution has shipped. An adapter for Amp's orbs, ephemeral remote machines billed by the minute, became a first-class pt runtime through three PRs in one evening. #474 built the amp_orb
runtime. In #476, the contract store rejected the first orb delivery and required a receipt-chain fix. #477 proved the full path. A remote orb built a pull request and pushed it to a quarantine branch. pt then fetched, verified, and published it locally through the same path used by every local lane. The orb remains an untrusted worker, and pt re-verifies the bytes before accepting its output.
The orb runtime runs implementation workers in parallel on separate machines. Local waves always shared one machine's CPU, battery, and lid. The first multi-orb wave started that same night with three workers on three remote machines. Each had a five-dollar cap. pt preflighted them as one wave and checked that their path authority was disjoint. One worker implemented pt doctor --fix
. The other two built a testing library with acceptance scenarios for the newly wired commands and fixed the lane machinery. They sent their quarantine deliveries to one contract store, while my laptop only performed verification. The waves also tested scale. Solo orbs are rock solid, and three concurrent orbs survived the night. A nine-way follow-up exposed a spawn race in the amp CLI's local startup. It silently killed six lanes before thread creation because the runner discarded stderr. The failures cost minutes because the same manifest can run again at lower concurrency. The race produced two machinery-debt items: bounded stderr capture in the orb runner and spawn jitter for waves. A startup-contention bug still blocks the ten-concurrent target. Any bounded task can now run elsewhere through pt lane --runtime amp_orb
. Closing the lid loses no work. The thread remains on Amp, the quarantine branch remains on GitHub, and a d orb costs nothing. Verification and publication still wait for my laptop to fetch the delivery. The home server would remove that last dependency.
The orb runtime is the first working part of the planned end state. It lets me issue a bug fix or feature from the deck, my phone, or a trailhead. The factory can run elsewhere and return a receipted PR.
What stuck, and where it points #
After two weeks, the ledger showed nearly 400 merged pull requests, including 73 on the biggest day. The factory had proved that it built its own features on rented machines, and the TUI could record, render, and manage video of itself. I had driven zero real workdays through the deck. I spent those two weeks optimizing the factory and ran no real work inside it. Sheet 06 described the missing work block. Because the tool was supposed to help me spend attention deliberately, zero real workdays meant it failed its own gate.
Finding this took ten days of building, the tuition itemized above, and about six dollars for the night the loop first closed. It also used a coding-agent seat heavily. pt enforced subscription allowance before metered tokens by scrubbing the environment.
The second finding concerns the interface. The useful terminal features remained useful, including its speed, deck, keystroke dispositions, and built-in VHS recording. Image galleries and image generation fit a web interface better. Web interfaces also fit research reading panes and graphs of work. Sheet 10 established the right boundary by having the core serve projections. I still kept the TUI at the center. I was building web software inside a TUI that does not run JavaScript, which made each of those features harder to build.
I set the new direction by checking which pieces survived two weeks of daily use without a second visit. Exactly two did: cross-agent memory and cross-agent secret usage. Both are ctx capabilities that shipped before pt existed, and both have run untouched since. Every harness opens with my context and can use scoped credentials without holding a standing key. This result showed that ctx should handle more of the durable work.
pt is parked, and ctx will close the loop. The current upgrade gives ctx a complete work graph with first-class records for work items, verifiers, and dependencies. ctx extracts, indexes, and durably stores every artifact from every session, including PRs, decisions, generated images, and recordings. It preserves these records regardless of which agent created them. ctx also dispatches orbs to start arbitrary work from my desktop or phone and preserves their outcomes, artifacts, and context. The harnesses remain interchangeable. pi is my daily driver because I can open-source my extensions without chasing parity with every agent SDK release. Claude Code, Codex, and DeepSeek remain first-class clients. ctx stores the record produced by each harness.
The target is to hand off a complete to-do. Merge these five PRs. After they deploy, verify the app in production. Then draft the two emails that link the latest deployment and create the Notion page with the right context attached. Report completion only after every gate has a receipt. FIG. 7 shows the first version running in ctx. It has an input set of PRs and a verification gate that failed when a sixth PR entered the scope. An orb holds a lease on the Notion artifact, and every state change has an evaluation receipt. Each completed run produces a verified ledger of finished work. Those ledgers accumulate into training data.
pt showed that verification should come before generation. Failures need receipts, and the loop needs early use on real work. Contracts, path grants, byte-level recapture, and rent gates move into the work graph as node types. The model-improvement plan also fits ctx better. ctx provides an API over a durable store, so a future model or agent SDK can connect as another client and inherit the full context, tools, and gates. pt had to reimplement support around each model and harness change. ctx can accept those changes through new clients. The parked terminal still pays out because you get to keep the neural connections. Two weeks of work on contract lifecycles, verification authorities, and trust ladders now applies to the system replacing it.
- [01]
[zackproser/pt — the repository: north star, golden list, contract-lane docs](https://github.com/zackproser/pt) - [02]
[Untethered Productivity at AI Engineer London — the attention thesis, pointed away from the desk](https://zackproser.com/blog/aie-london-untethered-productivity) - [03]
[Untethered Productivity — the recorded talk on YouTube](https://www.youtube.com/watch?v=so9l_MwS2yg) - [04]
[Untethered Productivity — the interactive slides](https://zackproser.b-cdn.net/talks/untethered-productivity/index-v3.html) - [05]
[ctx: The Personal Context Engine Every One of My Agents Shares (TDD-015)](https://zackproser.com/blog/ctx-personal-context-engine) - [06]
[The night my terminal harness wired itself — the companion war story](https://zackproser.com/blog/pt-wires-itself) - [07]
[zackproser/pr-babysitter — standalone ranked PR state extension](https://github.com/zackproser/pr-babysitter) - [08]
[Charm — Bubble Tea v2 / Lipgloss, the TUI stack](https://charm.sh) - [09]
[git-xargs — fan one command out across many GitHub repos](https://github.com/gruntwork-io/git-xargs) - [10]
[Tea Tutor deep dive — quizzes over SSH on Bubble Tea and Wish (2022)](https://zackproser.com/blog/teatutor-deepdive) - [11]
[The Bubble Tea state-machine pattern (2023)](https://zackproser.com/blog/bubbletea-state-machine) - [12]
[Amp, "What Are Orbs?" — ephemeral remote machines for agents](https://ampcode.com/what-are-orbs)
Anything on this sheet still unclear — or anything you were too polite to ask out loud? File an RFI. Answers come from the drawing itself and cite their sheet numbers, and every question is recorded in the drawing log so the next revision can answer it in print.