The terminal's Family card says, per sent forge, how many of its apps run and which one does not #1939

Each child in the family view now carries one line about its apps, and /family and the terminal Family card both show it. The new test and the existing family, hosted-child-apps and TUI render tests pass. The type check reported nothing, but I did not run the full bun test.

• The line: a child with apps reads 1 of 2 apps running — bakery asleep. A child given no apps says nothing about apps. The wording comes from a new appsLine() in src/spawn/family.ts. For one app it reads 1 of 1 app running. Several apps that are not running are joined with ; .
• Same state as /forges: the numbers come from hostedChildApps, the same call /forges uses, so nothing is recomputed. familyView takes it as an optional third argument so a test can supply the state.
• One-word reasons: the runtime's state is mapped to asleep, stopped, deploying, failing or not deployed. Any free-text error becomes failing, so an error message never reaches the line.
• Guests: the admin check is unchanged, so a guest still sees only the parent.
• The two surfaces:

- Terminal card: familyLines adds the line under the child's row. - /family: src/web/pages/family.ts adds it to the child's meta line.

• Test: in test/family-heartbeat.test.ts, a child given two apps (one running, one asleep) reads 1 of 2 apps running — bakery asleep in both the view and the headless-rendered card. It also checks that a guest sees nothing, that a child with no apps has no line, and the reason words.

The test feeds the state in rather than booting two real apps in a runtime. The web page itself is only covered by the shared view, not by an assertion on its HTML.

To try it, spawn a hosted child with apps and open /family as an admin, or open the Family card in the terminal.

🤖 Generated with Claude Code

Closes #1898

Parked by the crew: the check failed ("migrations are additive across a roll > the release record is newest first and never ahead of the schema") and the decider saw no point in another try

This pull now merges into main again. It had conflicted on src/core/releases.json, and I fixed that.

What changed: I merged origin/main into the branch. The only conflict was a formatting difference in the ids list of release 0.7.123 (one line on this branch, multi-line on main). I took main's version. releases.json is now identical to main's, so this pull adds nothing to it.

What's unchanged: The feature itself is as before. Each child's family card says N of M apps running, or which app isn't and why, in /family and the terminal card (src/spawn/family.ts, src/web/pages/family.ts, test/family-heartbeat.test.ts).

Tests: I ran test/family-heartbeat.test.ts and test/schema-additive.test.ts and all 16 tests pass. I did not run the full suite, so the forge's check will be the first full run on the merged branch.

I made all three changes and pushed them. test/family-heartbeat.test.ts passes (11 tests); I did not run the full suite.

• Page test: familyPage now takes an optional second argument for the per-child apps summary. It defaults to hostedChildApps, so the route behaves the same. The test calls the page directly with a hand-built context. It asserts the admin sees <span data-apps>1 of 2 apps running — bakery asleep</span> and that a hostile slug comes out escaped (<b>x</b>). It also asserts the span is absent for a guest and for a child with no apps. Deleting the line in src/web/pages/family.ts now fails the test.
• Import: src/web/pages/family.ts now has import { MAX_DEPTH } from "../../spawn/heartbeat.ts"; on one line.
• reason(): I dropped the redundant "failed" branch in src/spawn/family.ts. "failed" still reads as "failing" through the fallback.

Something else edited the working tree while I worked. It added an exported holdChildApps seam to src/spawn/child-apps.ts and a second test that relied on it. That test failed with already_app, and my first push of this round included it, so that push left the branch broken. I removed that test and its two imports and left child-apps.ts unchanged. Nothing on the branch now uses the seam.

The full gate on land was red; the pull is open again. Red tests:

• diff engine + resource edge cases > no-newline-at-eof marker on add and modify
• diff engine + resource edge cases > merge commit does not crash and returns 200
• diff engine + resource edge cases > mode-only change (chmod +x) with no content diff renders cleanly
• diff engine + resource edge cases > multi-hunk file: second hunk's line numbers are exactly correct (no off-by-one)
• diff engine + resource edge cases > DOS: file count is NOT capped independent of changed-line count (perf regression sentinel)
• diff engine + resource edge cases > MAX_FILE_LINES caps a single huge file (200k+ changed lines) instead of rendering it
• diff engine + resource edge cases > CAP_BYTES bounds a file that is few lines but huge in bytes (single giant line)
• diff engine + resource edge cases > no-newline-at-eof marker on add and modify [492.03ms] [shard 56]
• diff engine + resource edge cases > merge commit does not crash and returns 200 [674.12ms] [shard 56]
• diff engine + resource edge cases > mode-only change (chmod +x) with no content diff renders cleanly [425.56ms] [shard 56]
• diff engine + resource edge cases > multi-hunk file: second hunk's line numbers are exactly correct (no off-by-one) [376.29ms] [shard 56]
• diff engine + resource edge cases > DOS: file count is NOT capped independent of changed-line count (perf regression sentinel) [617.87ms] [shard 56]
• diff engine + resource edge cases > MAX_FILE_LINES caps a single huge file (200k+ changed lines) instead of rendering it [1380.54ms] [shard 56]
• diff engine + resource edge cases > CAP_BYTES bounds a file that is few lines but huge in bytes (single giant line) [648.50ms] [shard 56]

The full gate on land was red; the pull is open again. Red tests:

• checks > closing a pull leaves no queued or running run for it
• checks > closing a pull leaves no queued or running run for it [1172.36ms] [shard 5]

The full gate on land was red and named no test; the pull is open again.

I didn't change any code for the red gate. The 9 listed tests passed when I re-ran them, so I think they failed from load or timing rather than from this change.

• Diff engine tests (test/diff-edge-cases.test.ts): all 12 pass here. This pull only touches src/spawn/family.ts, src/web/pages/family.ts and test/family-heartbeat.test.ts, none of which the diff engine uses. The perf sentinels ran slowly in this sandbox (the 300-file diff took 2.5s). Their timings in your log are also high (0.4–1.4s on shard 56), so I suspect they failed on a loaded shard.
• checks > closing a pull leaves no queued or running run for it: passes here (test/checks.test.ts). It's a race on run state that also has nothing to do with the family card.
• Full gate: I did not run the full bun test, and I did not run the type check.
• Merge: I merged the 17 new commits from main and pushed, so the gate runs again on current code. After the merge, test/family-heartbeat.test.ts still passes (11 tests).
• If they fail again: a second red on those same tests would confirm they're flaky on main. They'd need their own issue.

The change: each child card on /family and in the terminal says "N of M apps running — slug reason". Both doors share one appsLine. The line only appears for admins, and the slug is escaped.

Review points from @juniper, not done:

• Asserting that the new apps field reaches the JSON API and MCP tool.
• Replacing the test-only appsOf parameter with a seam in hostedChildApps.

I left both out to keep this pull small.

Try it: open /family as an admin, or run the Family card in the terminal.

🤖 Generated with Claude Code

The full gate on land was red and named no test; the pull is open again.

The full gate on land was red; the pull is open again. Red tests:

• edits on a mirror: the origin's refusal is final > a new branch whose commit the origin cannot take is removed upstream too
• edits on a mirror: the origin's refusal is final > a new branch whose commit the origin cannot take is removed upstream too [5986.13ms] [shard 51]

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.

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; the pull is open again. Red tests:

• the fork flow > push rights mean no fork: the branch lands on the upstream itself
• the fork flow > GitHub takes the same owner:branch head form
• the fork flow > the repo route contributes to the upstream a mirror names
• the fork flow > a verdict on a mirrored pull is passed at the origin, in its words
• the fork flow > verdicts made upstream arrive on a sync, once
• the fork flow > GitHub is asked for a review in its own verb vocabulary
• the fork flow > a mirrored pull is still merged at the origin, never here
• the fork flow > a native fork of a mirror proposes upstream through it
• branches on a mirror go through the origin > creating a branch lands it upstream, then here
• the fork flow > push rights mean no fork: the branch lands on the upstream itself [1718.27ms] [shard 19]
• the fork flow > GitHub takes the same owner:branch head form [1077.85ms] [shard 19]
• the fork flow > the repo route contributes to the upstream a mirror names [1615.74ms] [shard 19]
• the fork flow > a verdict on a mirrored pull is passed at the origin, in its words [57.48ms] [shard 19]
• the fork flow > verdicts made upstream arrive on a sync, once [816.95ms] [shard 19]
• the fork flow > GitHub is asked for a review in its own verb vocabulary [516.55ms] [shard 19]
• the fork flow > a mirrored pull is still merged at the origin, never here [17.15ms] [shard 19]
• the fork flow > a native fork of a mirror proposes upstream through it [394.84ms] [shard 19]
• branches on a mirror go through the origin > creating a branch lands it upstream, then here [1703.91ms] [shard 21]

The full gate on land was red; the pull is open again. Red tests:

• push-through, adversarially > a writer who did not connect the origin cannot push through it
• push-through, adversarially > an unreachable origin refuses the push, and no credential leaks in the failure
• push-through, adversarially > an origin that needs re-authentication refuses the push before touching git
• push-through, adversarially > a mirror whose origin row lost its clone URL refuses the push
• push-through, adversarially > a disconnected origin fails closed: the mirror refuses pushes until reconnected
• apps adversarial: teardown races, grants, the proxy, and rule 1/4 > rule 1: the repository takes no push from the crew; the agent's fork takes branches but never its default branch, protected or not, renamed or not
• apps adversarial: teardown races, grants, the proxy, and rule 1/4 > rule 1: the repository takes no push from the crew; the agent's fork takes branches but never its default branch, protected or not, renamed or not [488.00ms] [shard 3]
• push-through, adversarially > a writer who did not connect the origin cannot push through it [2973.99ms] [shard 4]
• push-through, adversarially > an unreachable origin refuses the push, and no credential leaks in the failure [2119.94ms] [shard 4]
• push-through, adversarially > an origin that needs re-authentication refuses the push before touching git [1670.89ms] [shard 4]
• push-through, adversarially > a mirror whose origin row lost its clone URL refuses the push [1618.37ms] [shard 4]
• push-through, adversarially > a disconnected origin fails closed: the mirror refuses pushes until reconnected [1652.05ms] [shard 4]