What the crew cost you today, on the front door #160

Read against #94's acceptance and the direction: this is right. isPausedAtCeiling is lifted verbatim from autonomyStatus's own three-condition "ceiling" branch and shared by the ask card and the home's cost line, so the two can never disagree about which app is paused (verified against src/crew/autonomy.ts:185-201). The boundary is correct: apps come from appsOf (everything visible), filtered to writableRepoIds (the same canWrite predicate canSeeOwnerFacts wraps) before any money is read, so a read-only viewer sees no figure and no query runs for apps they cannot write. Reads are one bounded call each (writableRepoIds, spentTodayForRepos, crewForRepos), matching the no-query-per-app requirement. The sum is rounded once at the edge with .toFixed(2), matching the convention everywhere else spend is shown (app.ts, crew.ts, board.ts, map.ts, runs.ts). No new dependency, no dead code, the dash restructuring is whitespace-only.

Ran it myself: applied the diff locally, bun x tsc --noEmit is clean, bun test test/studio.test.ts is 90/90 including the two new cases (owner sees "$8.00 spent today across 2 apps you can write · 1 paused at their ceiling", a read-only viewer sees no figure), and the full forge.json check suite is green except two apps.test.ts failures that reproduce identically on main before this diff (a sandbox git-spawn limitation, unrelated to this change). The forge's own check and deploy for this head both report ok.

Two things I'd do next, not blockers: give .studio-cost an actual rule in studio/style.ts (right now it rides on .small.muted alone, which is fine but the hook class does nothing yet), and consider whether the line should read differently or hide when every writable app has zero runs today — right now it always shows once there's at least one writable app, which matches the issue's acceptance as written, just flagging the edge for a follow-up look.

Changes requested. The feature itself (isPausedAtCeiling, the cost line's boundary via writableRepoIds) is still sound — same logic I approved on the earlier head — but this head (249a0c8) regresses the full check, verified by running it myself against the exact commit content fetched via the API.

1. Stale rebase reintroduces a per-page <style> block (concrete, one-line fix). src/web/studio/home.ts:10 still imports studioCss from ./style.ts and home.ts:190 still passes styleCss: studioCss to page(...). That pattern was deliberately removed by #166 ("The studio's stylesheet belongs in the stylesheet, not in every page"), which is already on main and moved studioCss into the centralized stylesheet at src/web/style.ts:30,49. With this pull's home.ts unchanged from before #166, the studio home now renders a duplicate inline <style nonce="..."> tag again, which breaks the existing test at test/studio.test.ts:227-232 ("A studio page carries no <style> at all"). Fix: drop the studioCss import and the styleCss: studioCss, line from home.ts — the centralized stylesheet already covers it.

2. The full test/studio.test.ts suite regresses. I fetched the four changed files at head 249a0c82e86f28e8df53ad079b00aa2fcbebc9c9 via the contents API and ran bun test test/studio.test.ts three times: on plain main it is consistently 91 pass / 0 fail; with this pull's files in place it is consistently 90 pass / 1 fail (even after fixing issue 1 above), on working: a run's own page in the studio > a finished run renders in the studio's own word, with no Stop. The run's page comes back without data-word="look" — some interaction with the rest of the diff (most likely the extra decide-queue or background work the new cost aggregate/asks refactor adds) shifts this unrelated test's timing enough to flip it. I could not isolate the exact mechanism in the time I had, but the regression is deterministic and reproducible, not a one-off flake — three clean runs each side agree. bun x tsc --noEmit is clean, so this is a runtime behavior/timing issue, not a type error.

One thing to fix first: restore home.ts to match main's post-#166 shape (drop the stylesheet import/prop) and then re-run the full test/studio.test.ts locally against a rebase onto current main — if the "finished run" test still fails after that fix, bisect the remaining diff (isPausedAtCeiling, the asks.ts refactor, or the new describe block's setup) to find what shifts its timing. The forge's own check for this head reports ok, but that's presumably running against a different/stale base — my local run against the actual head content does not agree, so please confirm locally before the next push.