gstack now asks a Capy Captain in plain words
2 days ago
This pull request makes gstack Capy aware. When it runs under a Capy Captain, every decision now reaches the person in plain words. Plan approvals arrive as a five part brief with a one word reply. Each branch keeps a record of who approved what. And the ship step puts before and after pictures of the change at the top of the pull request.
Ask about this presentation
Chapters
0:00gstack asks a Capy Captain in plain words
0:21Why: the relay lost the plain words
0:42The plan gate, before and after
1:06The Captain brief
1:31Who gets asked
1:56Standing approvals and fresh asks
2:23The approval record
2:50What keeps the record honest
3:17Before and after images on the merge ask
3:43Evidence
4:05What to know before you rely on it
Show transcriptHide transcript
This pull request makes gstack Capy aware. When it runs under a Capy Captain, every decision now reaches the person in plain words. Plan approvals arrive as a five part brief with a one word reply. Each branch keeps a record of who approved what. And the ship step puts before and after pictures of the change at the top of the pull request.
On October 17th, Garry had to write this. He runs gstack through one Captain, GStack Minder, and about 30 crew threads, so every plan gate and every merge ask reaches him through a relay. Each thread and the Captain translated gate output by hand, so the shape depended on who wrote it. Three days later he asked for the fix.
This is the plan gate a thread used to relay. A gate line with a run id, then numbered items with option letters, and a reply grammar built from those letters. The Captain rewrote it into plain language by hand, and the codes leaked through anyway. Here is the same gate now. It opens with the decision in one sentence, says reply rec to take every recommendation, and then explains the plan.
The brief comes from gstack owner brief render, with the captain flag. The first four sections are read straight from the reviewed plan, through a new fence aware heading parser. The last one is built from the gate itself. It lists every choice rec would take, in words. Gate ids and the rec hash move to one trailing line for the relaying agent. And a plan missing a section prints not ready for approval, and exits with code 1.
How does a workflow know it is under Capy? The Capy launch line sets a flag, and skill start prints Capy on, plus one block of instructions. A crew thread sends a needs you report to its Captain. A thread with no Captain asks the person with a Capy question. The agent picks the route, since Capy keeps crew membership to itself. The block is printed at runtime, so the generated skill files stay the same size.
Some decisions are already settled. A standing approval, like merge when green through a merge train, lives in the Captain's rules, and the thread cites it instead of asking again. A fixed list always needs the person's own words. That covers a product or behaviour decision, spend over a stated cap, anything published outside the repository, a change to a threshold, a budget or a trial count, closing someone's contribution without landing it, and anything destructive.
Every answer gets written down. gstack approvals add stores one row per answer, with the person's exact words, who said them, what the answer covers, and what is still pending. After an autoplan gate is answered, import pulls the reply the gate already stored, and a second run adds zero rows. Render prints this table, which comes from this pull request's own body: the plan approval, a standing approval for paid evals, and merge when green.
The record is one file per repository and branch, under the state root. A Capy machine's state root gets thrown away, so under Capy every write is mirrored to the private Drive folder. Every field goes through the secret scanner first, and a hit refuses the whole row. Cells are escaped, so the table can never be read as an approval citation. And a fresh machine with no record and no mirror says the record is unavailable, rather than showing an empty table.
Merge asks get pictures. Before, the ship step's pull request body opened with a summary and test coverage, so a merge decision meant reading the diff. Under Capy it now opens with what changed, why, and approvals. These two images come from the new PR shots command. It reads text only and runs nothing, then stacks before over after at GitHub's 880 pixel column, showing only the changed hunks.
Four new test files cover the record, the brief, the images, and the whole Captain flow, from the gate, to the relay line, to the brief, to a relayed answer landing in the record and its mirror. Before merge, the remote free tier ran about 21 thousand tests with zero failures. Three focused paid ship cases passed, and typecheck came back clean.
Three things to know before you rely on it. Two gate ceilings moved: the Capy skill's context budget went from about 2,900 to 3,500 tokens, and ship's parity cap rose slightly for the new section. Eval thresholds stayed where they were. Owners copy the skill folder over their Drive copy by hand to pick up the new guidance. And outside Capy, the only change is one status line. That is gstack, asking a Capy Captain in plain words.

