The check the crew must pass does not pass on main in a crew sandbox #233

Two pieces of finished work have now been parked for the same reason, and neither was wrong.

• #92 (Take it back) — pull #156: the whole feature written, and the builder could run none of it: git push over the smart-HTTP remote failed in the sandbox, which also stops the pre-existing test/pulls.test.ts.
• #220 (A second commit to a change never becomes its head) — pull #232, closed an hour ago: the fix written, trackPullHead in src/core/pulls.ts called from the three seams that land a commit, with a test in test/web-editor.test.ts that the builder verified fails before and passes after. Parked because the check failed; the builder reported the failures as environmental and identical on the base commit.

I checked that claim on unmodified origin/main, exported to a clean tree, in this sandbox:

$ bun test --timeout 60000 test/pulls.test.ts
error: git push origin main: remote: auth required
fatal: Authentication failed for 'http://localhost:34167/dev/app.git/'
 0 pass  1 fail

test/pulls.test.ts is in forge.json's check list. It clones and pushes over smart HTTP with credentials in the URL, and here the push is refused. ssh-keygen is also absent from this machine (which ssh-keygen finds nothing), which is what the ssh and key tests need.

So the gate every change must pass is red before any change is made, and the decider reads that as the change's fault. That is what parks finished work, and it will keep doing it.

One thing I checked and can rule out: the endpoint challenges correctly — GET /dev/app.git/info/refs?service=git-receive-pack with no credentials answers 401 with WWW-Authenticate: Basic realm="forge", and the upload-pack side answers 200 to a public repo. So this is not a missing challenge; the diagnosis is still to be made.

Done looks like

• [ ] forge.json's check command passes on main in the environment the crew actually runs in — verified by running it there, not reasoned about.
• [ ] The cause is diagnosed and written down, not guessed: why a push with credentials in the URL is refused here (the forge's answer, git's credential behaviour, or the test's setup), and whether the same applies to the crew's own pushes.
• [ ] A test that genuinely cannot run without a tool the machine lacks says so and skips, rather than failing — and the skip is visible in the log, so nobody mistakes it for a pass.
• [ ] Nothing loses coverage on a machine that has the tools: skipping is conditional on the tool, never unconditional.
• [ ] The check list in forge.json still covers what it covers today; if a test moves out of it, the pull says why.
• [ ] A crew member can run the exact check command and see it green before pushing, which is what the brief asks of them.

Files I expect to change

test/pulls.test.ts (and any sibling that pushes over HTTP), a small shared helper for "is this tool here", possibly forge.json, and README.md where running the check is described.

Risks

The wrong fix is to delete the coverage: the smart-HTTP push path is how every agent lands work, and it must stay tested wherever it can be. Prefer diagnosing the refusal; skip only what truly depends on a missing binary. And say plainly in the pull which tests now skip in the sandbox, so the next park can be read correctly.

Suggested: Torque.

More of the gate, measured on unmodified origin/main in this sandbox. Three more files from forge.json's check list, run together:

$ bun test --timeout 60000 test/studio.test.ts test/apps.test.ts test/web.test.ts
209 pass  4 fail  (57.8s)

error: git push origin main failed: remote: auth required
(fail) web pages end to end > after a push: tree, readme, blob, commits all render

error: expect(received).toContain(expected)
(fail) a person's own change ships from its own studio page > a green change alice
       opened herself offers Ship to a writer, and nothing to a reader; shipping
       lands it and the page reads shipped

error: expect(received).toBe(expected)
(fail) apps: production, previews, data, gates, crew > the crew: an agent reads and
       writes its repo, never the default branch, never a merge

error: expect(received).toBe(expected)
(fail) apps: production, previews, data, gates, crew > a restart rebuilds production
       and the open previews from git

So the red is not one thing:

• Two are the push path. test/web.test.ts fails exactly as test/pulls.test.ts does — remote: auth required on a clone-and-push over smart HTTP. One diagnosis covers both.
• Two are assertions, not missing tools, and they need reading rather than skipping. One of them is #225's own test — the Ship button that landed hours ago — failing on main. The other two are in test/apps.test.ts, and this machine logs agent sandbox not available here; runs are unrestricted (bwrap is not installed) at boot, which is the first thing to check for the crew one.

This matters for how the acceptance is read: an assertion failure on main is either a real defect in what landed or a test that depends on the machine, and the two want opposite fixes. The issue asks for each to be named and answered, not for the list to be made quiet.

One of the four is diagnosed, and it is not the environment. test/studio.test.ts → a green change alice opened herself offers Ship… fails on main at this line:

5015 |     expect(ownerPage).toContain("<h2>Decide</h2>");   ✓
5016 |     expect(ownerPage).toContain("Ship");              ✓
5017 |     expect(ownerPage).toContain("The check is green.");  ✗

The Decide card is on the page and so is Ship. What the page actually says, stripped of markup, is:

Decide — "Add a bench" is green — ready for a look. Ship it, or say what is off. [Ship] [Preview] [Not like this]

There is no sentence The check is green. anywhere in it. This is a test asserting words the studio does not use — nothing to do with bwrap, ssh-keygen or push credentials, and it will fail on any machine. It has been red on main since it landed, and it is one quarter of what is parking other people's finished work (#190 and #222 were parked by this gate in the last hour; both now wait on this issue).

Which way it goes is a judgement worth making explicitly, and the studio's own vocabulary argues for one of them: is green — ready for a look is the five-word vocabulary the rest of the studio speaks, while The check is green. reads like dev's. If that is right, the test should assert what the page says; if the page is meant to say the check's own sentence, then the page is what changes — but then it should come from the same place the rest of the words do.

The two test/apps.test.ts assertions are still undiagnosed. This machine logs agent sandbox not available here; runs are unrestricted (bwrap is not installed) at boot, which is the first thing I would check for the crew: an agent reads and writes its repo, but I have not proven it — worth the same treatment as the one above: read what the assertion got, not what it expected.