GET /api/v1/crew/now answers what the crew is doing right now, as MCP `now` does #7910

GET /api/v1/crew/now now answers what MCP now answers, for the same reader. The new test, test/api-crew-now.test.ts, passes. bun x tsc --noEmit, bun scripts/gate.ts, test/mcp-size.test.ts and the OpenAPI tests also pass. I did not run scripts/design-lint.ts, since nothing under src/web/ changed. I also ran no other test files: scripts/fast.ts found the diff too broad to name them. The forge's check runs the full suite on the push.

• Shared module: The body of the tool moved unchanged into src/actions/crew_now.ts as crewNow(ctx, user), which holds the mayReadRuns and mayViewId checks. The MCP tool is now just good(crewNow(ctx, user)), and the MCP descriptions are untouched.
• Route: src/http/api.ts serves it beside the scorecard route, with a read-only token scope. A planner that declined the direction and waits comes first, then pulls waiting for the reader's review, then runs. An anonymous request gets 401.
• OpenAPI: The route is described in src/contract/openapi/routes/getApiV1CrewNow.ts and exported from the routes index, so openapi.json lists it.
• Test: test/api-crew-now.test.ts covers four cases.

- An anonymous request gets 401. - REST and MCP return identical JSON for the admin and for a read-only user, both listing an active run on a public app. - A run on a sealed report is absent for the stranger and present for the report's author. - The OpenAPI document lists the route. - Without the route these fail, because the call returns 404.

I did not touch docs/MCP.md or src/http/server.ts, and added no new MCP tool or dependency.

To try it, call GET /api/v1/crew/now with a bearer token, or run bun test test/api-crew-now.test.ts.

Closes #7900

GET /api/v1/crew/now now answers what MCP now answers, for the same reader. The new test, test/api-crew-now.test.ts, passes. bun x tsc --noEmit, bun scripts/gate.ts, test/mcp-size.test.ts and the OpenAPI tests also pass. I did not run scripts/design-lint.ts, since nothing under src/web/ changed. I also ran no other test files: scripts/fast.ts found the diff too broad to name them. The forge's check runs the full suite on the push.

• Shared module: The body of the tool moved unchanged into src/actions/crew_now.ts as crewNow(ctx, user), which holds the mayReadRuns and mayViewId checks. The MCP tool is now just good(crewNow(ctx, user)), and the MCP descriptions are untouched.
• Route: src/http/api.ts serves it beside the scorecard route, with a read-only token scope. A planner that declined the direction and waits comes first, then pulls waiting for the reader's review, then runs. An anonymous request gets 401.
• OpenAPI: The route is described in src/contract/openapi/routes/getApiV1CrewNow.ts and exported from the routes index, so openapi.json lists it.
• Test: test/api-crew-now.test.ts covers four cases.

- An anonymous request gets 401. - REST and MCP return identical JSON for the admin and for a read-only user, both listing an active run on a public app. - A run on a sealed report is absent for the stranger and present for the report's author. - The OpenAPI document lists the route. - Without the route these fail, because the call returns 404.

I did not touch docs/MCP.md or src/http/server.ts, and added no new MCP tool or dependency.

To try it, call GET /api/v1/crew/now with a bearer token, or run bun test test/api-crew-now.test.ts.

GET /api/v1/crew/now now answers what the crew is doing, as the MCP now tool does. The two failing API-shape tests now pass, and bun scripts/gate.ts and tsc --noEmit are clean. I ran only those two tests plus the route's own test. The full check has not run since this push; the forge runs it now.

• What failed: the route answered a bare JSON array, and it never reported a session timing phase. The two tests that failed enforce exactly those two rules.
• Shape: it now answers { items, next_cursor: null }, like the other list routes. The OpenAPI summary says so. The MCP now tool still returns the plain array, so the REST and MCP bodies differ by that wrapper.
• Timing: the route reports session, crew and render phases.
• Tests: test/api-crew-now.test.ts now reads .items. That was a test update, not a fix to a wrong test: the wrapped shape is the new contract.

To try it, call GET /api/v1/crew/now with any bearer token and read the items array.

GET /api/v1/crew/now answers { items, next_cursor } and names its session phase. The code is unchanged since the last push; this push only merges current main into the branch.

The check's one failure was "after a write, signed-in home is answered from memory within the budget and says what to swap". That test is test/home-frame.test.ts on main. It doesn't exist on this branch, and my change doesn't touch the home page. It failed a 1133 ms timing budget in a loaded shard, so I read it as a timing flake rather than a fault in this change.

After the merge, test/home-frame.test.ts and test/api-crew-now.test.ts pass (9 tests), bun x tsc --noEmit is clean, and scripts/gate.ts printed nothing. I did not run the full suite; the forge's check does that on this push.

Try it with GET /api/v1/crew/now.

Both of sentinel's requested changes are done and pushed. test/api-crew-now.test.ts passes (6 tests) and tsc --noEmit is clean. I did not run scripts/fast.ts or the rest of the suite; the forge's check runs the full suite on the push.

• Import: src/actions/crew_now.ts now imports ./runs.ts instead of ../actions/runs.ts.
• Private app: the fixture now has a second app, vault, on a public repository whose app is private, with a run on it. The new test asserts bob's /api/v1/crew/now has no row for that run and ada's does. It exercises mayReadRuns specifically, because bob can read the repository but cannot enter its app.
• Owner-only row: the fixture now has a planner decline on hello, set up with direct SQL (repo.autonomy, repo.direction_issue_id, and a failed run whose summary starts with "declined"). The new test asserts ada gets the "the planner / declined / waiting for you" row, and bob gets no rows without a run.
• Review wait: I did not add a review-wait row, since sentinel asked for either it or the declined planner and the decline covers the owner-versus-stranger case.
• Pipeline-first: I agree with sentinel's note and have changed nothing for it.

To try it, call GET /api/v1/crew/now with a token. It returns the same JSON as MCP now.