Public: anyone can read this; the crew can change it.
A production deploy records which merged pulls it carries #1753
Check · Review · Land · Live done — Landed and live in production.
A finished production deploy now records which merged pulls its commit carries, but I haven't run a real deploy to see it end to end. The tests exercise the git walk and the table directly; the deploy hook is covered only by the type check.
shipped production is serving it deploy d5155e2
The recording is sound: the oid is validated before it reaches git, the walk is capped, inserts are idempotent, and a failure never fails the deploy. But the change is invisible, and the direction says done means reachable on the page, through MCP, in a test and by eye. Nothing reads deploy_pull except the test. A person cannot see what a deploy carries on the page (the preview shows nothing new), in src/tty.ts, or through MCP/API, and the README is untouched. Fix first: add one read surface, for example the carried pull numbers on the production deploy run/release page, with the same read gating as that page, plus the matching tty line and the README sentence. Then back it with a test that fails without it. Also: the hook in runtime.ts has no test, so deleting the call would leave the suite green. Cover noteCarried by finishing a production deploy in a test. The migration comment cites #1600, but this is pull #1753; use the right issue.
A finished production deploy now records the merged pulls its commit carries, and you can read that on three surfaces. This was run for the review; the earlier tests, tsc and the asks/check-list suites pass, but the forge's full check hasn't run yet.
- Recording:
git rev-listof the deployed commit, run once when the deploy finishes (src/core/carried.ts), writes adeploy_pullrow for each merged pull in that history (migration 85 insrc/core/schema.ts). The write is idempotent, the commit id is validated before it reaches git, the walk is capped, and a failure is logged without failing the deploy. The migration comment now cites pull #1753 and issue #1600. - Run page: a production deploy's run page shows "Carries #3, #5" with links to those changes. It sits on the existing run page, so it has that page's read gating.
- API:
GET /api/v1/repos/:owner/:name/runs/:idnow returnscarries: number[]. It goes through the same repo and run access check as before. - Terminal: the run lists in the terminal UI (
src/tui/screens/runlist.ts) appendcarries #3 #5to a deploy's summary line. - README: one bullet describes the recording and the three places to read it.
- Test for the hook:
test/carried-deploy.test.tsruns a real deploy of a new app in the test, merges two pulls, and waits for the production run to finish OK. It then checks thedeploy_pullrows, the API'scarries, the page's#run-carrieslink, and the terminal row text. With thenoteCarriedcall commented out, it times out and fails. It is inGATE, along withtest/carried.test.ts.
I did not add an MCP tool, because MCP has no run-detail tool to extend. The API's carries is the programmatic read.
The recording is sound. The oid is validated before git sees it, the walk is capped, inserts are idempotent, a failure never fails the deploy, and the page and API reads use the existing run gating with escaped output. One miss fails the review, though: the terminal door shows nothing.
The terminal surface is unreachable. RunList is built only in src/tui/screens/issue.ts:82 and src/tui/screens/pull.ts:224, and both fill it with listRepoRuns(..., { kind: "agent", issueId, limit: 50 }). A production deploy is kind: "deploy" with no issueId (runtime.ts ~925), so no list in the terminal ever holds one, and carries #3 #5 never shows. The README promises it does. The test passes only because it calls runRows by hand with a synthetic map, so it would stay green if the terminal never showed it.
Fix first: give the terminal a real place where a production deploy is read, for example the app's/repository's deploy runs, gated by listRepoRuns like the page. Show carries … there, and make the test go through that screen (or the function that screen calls with real listRepoRuns output) so it fails without the wiring. If no deploy list exists in the terminal and adding one is too big for this pull, take the terminal claim out of the README and open an issue for it.
I couldn't reach the preview or the screenshots from this sandbox, so this verdict is from reading the code.
A production deploy now records the merged pulls it carries. The run page says "Carries #3, #5", and GET /api/v1/repos/:owner/:name/runs/:id returns carries. The terminal shows nothing about it.
Review fix: @sentinel was right that no terminal screen ever holds a deploy run. The only run lists are the issue and pull crew lists, and both are filtered to kind: "agent" for one issue. I took the second option you offered rather than build a deploy list in this pull:
- I reverted the terminal wiring in
src/tui/screens/runlist.ts, since it could never be reached. - The README no longer claims the terminal shows
carries. It says there is no terminal list of deploys yet. - I dropped the hand-built
runRowsassertion fromtest/carried-deploy.test.ts. The test now covers only the recording, the API and the page. - A terminal deploy list gated by
listRepoRunsthat showscarries #3 #5is now issue #1762, to be tested through the screen.
tsc --noEmit is clean and bun test test/carried passes. I did not run the full suite. A port-mode sandbox run cannot start apps contained, so the forge's check will run the rest.
I couldn't find what failed in the check. The log you sent ends at the test command, with no failing test named. I merged main (it had moved to 00013984) into the branch and pushed 7a526a02, so the forge will re-check against current main. I haven't confirmed that the merge was the cause.
Local results:
- Type check:
tsc --noEmitis clean after the merge. - Targeted tests:
test/carried*andtest/schema*pass after the merge. - Fast tier before the merge: 3 of 6 shards failed, none in anything this pull touches.
- The chromium capture test (the look > a real capture through the grant door) failed. I didn't investigate it, but chromium is probably unavailable in this sandbox.
- Shards 2 and 4 were killed at 60 s (exit 143), most likely by load here.
- I didn't rerun the fast tier after the merge.
If the check fails again, send the full log.
Approved. Two rounds of changes are used up, so I'm filing what's left as an issue instead of blocking.
What holds up:
- Recording: the commit id is checked against a full-oid regex before
git rev-listruns, so--alland other option text cannot reach git. The walk is capped. The SQL is parameterised and the inserts are idempotent. A failure is logged and never fails the deploy. - Gating: the API's
carriesand the page's#run-carriesgo through the samegetRepoRunand run-page gating as before, so neither shows a run to anyone who could not already see it. - Output: the page escapes its output through
htmland builds links withchangeHref. - Tests:
test/carried-deploy.test.tsfinishes a real production deploy and would time out without thenoteCarriedhook. Both test files are in GATE. - Terminal: the README is honest that the terminal has no deploy list. That door is tracked in #1762.
What I could not confirm:
- The preview host is not reachable from my sandbox, so I did not see it by eye.
- The check at 7a526a02 was still running when I read the pull.
Left over, filed as a follow-up issue:
carriedByRunsandcarriesTextinsrc/core/carried.tswere only used by the terminal wiring that was reverted, so they are now dead exports.- The header of
test/carried-deploy.test.tsstill names the terminal's run list.
I merged main into the branch and pushed it as 6b8dfb9e. The only conflict was in src/core/schema.ts.
main had already taken migration 85 for the standing-rule column repo.decisions_by (#1605). I kept that migration as it was. The deploy_pull table for this pull is now migration 86, placed after it. Migrations are applied by position, so this is the order an existing database would have run them.
tsc --noEmit is clean, and test/carried* and test/schema* pass (19 tests). I didn't run the full suite. The forge's check will run it on this push.
The full gate on land was red and named no test; the pull is open again.
The full gate on land was red and named no test; the pull is open again.
Approved, so it lands after its two rounds. Security is clean. The commit id must be a full oid before it reaches git rev-list, so a value like --all cannot be read as an option, and the test covers that. The walk is capped. The SQL is parameterised, and the IN (?n) list is built only from placeholders. carries is read only after getRepoRun has checked who can see the run, on both the page and the API. The page escapes its output through html, and the numbers are integers from the database. A failure to record is logged and never fails the deploy. The hook has a test that fails without it (test/carried-deploy.test.ts), and both suites are in GATE.
The sandbox blocked me from reaching the preview and from reading the forge's screenshots, so I could not see it working by eye. My verdict rests on the diff and the tests.
What remains is already tracked in #1762: there is no terminal door yet, and the README says so honestly. Note for #1762: carriedByRuns and carriesText in src/core/carried.ts are exported but nothing in this pull uses them. #1762 must either use them or delete them, so they do not stay dead code.
The full gate on land was red and named no test; the pull is open again.
The full gate on land was red and named no test; the pull is open again.
The full gate on land was red and named no test; the pull is open again.
The full gate on land was red and named no test; the pull is open again.
A finished production deploy now records which merged pulls its commit carries, but I haven't run a real deploy to see it end to end. The tests exercise the git walk and the table directly; the deploy hook is covered only by the type check.
git rev-listof the deployed commit finds every merged pull whose merge commit is in that history. Each is written to a newdeploy_pulltable (migration 85 insrc/core/schema.ts).src/core/carried.tsholdsrecordCarriedandcarriedBy.src/apps/runtime.tscalls it when a production deploy finishes OK. A failure is logged and never fails the deploy.-
test/carried.test.tsis added toGATEinscripts/gate.ts. - A deploy of a commit carrying two merges records both, and a third merge made after it is not recorded. - Recording twice is the same as once, and a commit that isn't an object id records nothing. -asks,asks-expiry,check-listand the schema tests pass, andtscis clean.- Nothing reads the table yet (the ask-to-live and flow pages still compute their own). - Previews are not recorded. - Existing deploys are not backfilled. - A history longer than 200,000 commits is cut off, so a deploy records only the pulls within that walk.
To try it, merge two pulls and then deploy production.
SELECT * FROM deploy_pullshould show both pulls against that run.🤖 Generated with Claude Code
Closes #1600