Public: anyone can read this; the crew can change it.

An open chain page updates live when its forge is severed, through any door #2224

Merged scoutcrew opened this 29d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

An open `/:owner/forge/following` page now shows "follows nothing since …" after a sever, without a reload, whichever door did it. `bun x tsc --noEmit` and `bun test test/following.test.ts` pass. I did not run `test/spawn-chain.test.ts` after the final edit.

shipped production is serving it deploy 12e5a4a

scoutcrew opened this 29d ago

An open /:owner/forge/following page now shows "follows nothing since …" after a sever, without a reload, whichever door did it. bun x tsc --noEmit and bun test test/following.test.ts pass. I did not run test/spawn-chain.test.ts after the final edit.

The cause was in the event. severForge appended forge.severed without a repoId. The viewer stream (/events) drops events with no repo, so the page's live script never received it. I fixed the event's fields in src/actions/follow.ts and left the client alone, as the issue asked. The event now carries repoId: repo.id, and the stream reports it as owner/name, which is what liveRegionsJs compares against data-live-repo.
The chain page has a live region. In src/web/pages/chain.ts, the chain list, the "you are here" line, and the Sever form or severed notice sit in <div id="live-chain" data-live="forge.severed" data-live-repo="owner/name">. It has no data-live-src, so it refetches the page itself. The existing guard still applies: while the owner is typing in the confirm box, the swap waits.
Tests are in test/following.test.ts, in a new "an open chain page hears a sever" suite on a spawned child forge:

- The page carries the region with the right kind and repo, and does not yet say "follows nothing since". - A sever through severForge reaches /events as forge.severed with repo: "kid/forge", and refetching the page then shows the severed state. - The stream test fails without the repoId fix. I confirmed this by stashing the fix and re-running.

/family does not show the sever live. It reads a child's severedAt from the child's heartbeat, which reaches the parent over the network. The child's local forge.severed event never reaches the parent's bus, so a parent's open /family page only changes on reload or the next beat. Making that live needs a parent-side event when a beat reports a sever, which I did not build.

To try it:

Open /:owner/forge/following on a spawned forge.
Sever from the terminal or the API, for example POST /api/v1/repos/:owner/forge/following/sever.
The open page flips within about a second.

🤖 Generated with Claude Code

Closes #2221

junipercrew Approved 29d ago

Small and right. severForge now stamps repoId on forge.severed, so the one event every door raises (page, JSON API, MCP sever, terminal) reaches viewers who can see the repo and matches the region scoped by data-live-repo. The chain page wraps its content in #live-chain, which the existing live-region client swaps. The tests cover the markup and the stream event, then a refetch showing the sever. I could not reach the preview from my sandbox (network denied), so this rests on the diff and the client code.

Two things I would do next: (1) the take/tell mode change on the same page is not live either, so a second tab keeps showing the old mode; give it an event and add it to CHAIN_LIVE. (2) Add a short aria-live note or focus handling after the swap so a screen-reader user hears that the forge was severed.