The sentinel files no never-green-check issue in trevato/forge for another repository #3926

Both changes are pushed, but I couldn't run bun x tsc --noEmit. It fails here with "bun is unable to write files to tempdir: ReadOnlyFileSystem", and node_modules has no local tsc. The forge's check will type-check it. bun test test/sentinel.test.ts passes (34 tests).

What changed

• runStreaks in src/crew/sentinel.ts now files the gate: finding ("The check in … has not been green") only for the sentinel's own repository.
• That repository is whatever sentinelRepoPath() names, resolved to its id with getRepo.
• A never-green check in any other repository files nothing here. It stays visible on that repository's checks and in the degraded list.
• The agent-run (push) streaks in the same function are unchanged.
• #3895's own-repository helper wasn't on this branch, so I resolved the id inline rather than write a shared helper. If #3895 lands first, that line should switch to its helper.

Tests (test/sentinel.test.ts)

• New "a gate never green" describe, with two cases:

- 15 failed check runs in another repository yield no finding. This case fails with the change reverted. - 15 in the sentinel's own repository still yield it.

• The default sentinel repository is trevato/forge, so the existing fixtures in alice/forge no longer matched. The "faults of the day" block now sets FORGE_SENTINEL_REPO=alice/forge and leaves it set for the later suites.
• The "schedule" test now clears that variable for its first two assertions, because they expect no finding. It then restores it afterwards.

Not done: I made no change to how the other repository's check is surfaced.

Closes #3918

Both changes are pushed, but I couldn't run bun x tsc --noEmit. It fails here with "bun is unable to write files to tempdir: ReadOnlyFileSystem", and node_modules has no local tsc. The forge's check will type-check it. bun test test/sentinel.test.ts passes (34 tests).

What changed

• runStreaks in src/crew/sentinel.ts now files the gate: finding ("The check in … has not been green") only for the sentinel's own repository.
• That repository is whatever sentinelRepoPath() names, resolved to its id with getRepo.
• A never-green check in any other repository files nothing here. It stays visible on that repository's checks and in the degraded list.
• The agent-run (push) streaks in the same function are unchanged.
• #3895's own-repository helper wasn't on this branch, so I resolved the id inline rather than write a shared helper. If #3895 lands first, that line should switch to its helper.

Tests (test/sentinel.test.ts)

• New "a gate never green" describe, with two cases:

- 15 failed check runs in another repository yield no finding. This case fails with the change reverted. - 15 in the sentinel's own repository still yield it.

• The default sentinel repository is trevato/forge, so the existing fixtures in alice/forge no longer matched. The "faults of the day" block now sets FORGE_SENTINEL_REPO=alice/forge and leaves it set for the later suites.
• The "schedule" test now clears that variable for its first two assertions, because they expect no finding. It then restores it afterwards.

Not done: I made no change to how the other repository's check is surfaced.

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

The sentinel now files a never-green check finding only for its own repository (FORGE_SENTINEL_REPO, default trevato/forge). I could not reproduce the red gate, so I have not fixed what turned it red.

Gate. bun scripts/gate.ts is clean here. bun test on test/sentinel.test.ts and on the other sentinel, crew, red-main, board, asks and review suites gives 127 passes and no failures. I could not run tsc --noEmit because bun install fails in this sandbox (it can't write its tempdir), so node_modules is missing and I haven't checked types. The failure message named no test, so the log may point to something this change doesn't touch, such as a flake or a shard timeout. If it goes red again, the new push's log should name the test.

Changes in this push

• When the sentinel repository does not resolve, runStreaks now logs a warning. Before, every never-green finding was silently dropped (juniper's line comment).
• The README's sentinel section now says a never-green check in any other repository stays on that repository's checks and the degraded list (juniper's second suggestion).

Not done: I left the inline own-id lookup in place because the shared helper from #3895 has not landed.

The sentinel now files a never-green check finding only for its own repository (FORGE_SENTINEL_REPO, default trevato/forge). I have not fixed the last failed check, because it failed before any test ran. The check's bun install got HTTP 429 from registry.npmjs.org, and the forge's egress proxy had already capped that check at 8 connections to the registry. Nothing in this diff touches dependencies or install, so there was nothing in the code to fix. I pushed an empty commit to run the check again.

If it fails the same way, the cause is the registry rate limit or the proxy's per-check connection cap, and someone should look at those rather than this pull.

• Gate and tests: scripts/gate.ts is clean here, and the sentinel, crew, red-main, board, asks and review test files pass (127 tests, no failures). I couldn't run tsc --noEmit in my sandbox, so types are unchecked here.
• Logging: runStreaks logs a warning when the sentinel repository doesn't resolve, so findings aren't dropped silently.
• README: the sentinel section now says where a never-green check in another repository still shows. That is on that repository's checks and the degraded list.
• Not done: I kept the inline own-id lookup because the shared helper from #3895 hasn't landed.

The sentinel now files a never-green check finding only for its own repository (FORGE_SENTINEL_REPO, default trevato/forge). The last two checks failed on the install step, so no test had run. I've made a fix in forge.json but haven't seen it pass in the forge's check yet.

Cause of the failed checks. The egress proxy limits a check to 8 connections to registry.npmjs.org. bun install opens up to 48 at once by default. The proxy refuses the extra connections ("egress capped"), and bun reports that as a registry 429. That is why my empty re-run failed the same way.

Fix. forge.json now sets check.install to bun install --network-concurrency 4, which stays under the cap. This is a change to the repository's own check config, outside the sentinel work. If the cap is meant to be lifted or raised for installs, drop that line.

Tests. test/apps.test.ts, test/check-list.test.ts and test/sentinel.test.ts pass (67 tests), and scripts/gate.ts was clean earlier. I did not run tsc locally because bun install fails in my sandbox.

Other changes. The sentinel logs a warning when its repository doesn't resolve, so it no longer drops findings silently. The README says a never-green check in any other repository stays on that repository's checks and the degraded list. I left the inline own-id lookup in place because the shared helper from #3895 hasn't landed.

The sentinel now files a never-green check finding only for its own repository (FORGE_SENTINEL_REPO, default trevato/forge). I've addressed all three of juniper's points. The sentinel tests pass (34 of 34), but I couldn't run tsc here, so types are unchecked.

• forge.json: I removed the check.install line, so the pull no longer touches check configuration. Earlier checks failed because bun install opens up to 48 registry connections while the egress proxy caps a check at 8, which bun reports as a 429. If the pull's check hits that again, it needs its own issue rather than a change here. I haven't filed one.
• Warning: the "sentinel repository does not resolve" log in runStreaks now fires once per process instead of on every hunt.
• Test environment: the sentinel suite saves FORGE_SENTINEL_REPO at load and restores it in its afterAll. That also covers the two earlier tests that set it and never restored it.

I haven't switched the inline own-id lookup to the shared helper, because #3895 hasn't landed.

The sentinel change is finished, but this pull's check can't pass until the install failure is fixed elsewhere, so I have not pushed again.

I changed nothing this turn. The failure is in bun install, before any test runs. The egress proxy lets a check hold 8 connections to the registry at once. bun install opens up to 48 and reports the refused ones as 429s. The same install failed on all four of this pull's checks (this one is the fourth), so another push would fail the same way.

I did not put the --network-concurrency 4 line back in forge.json, because juniper asked me to take it out and file the problem separately. I filed it as #3983 and proposed lowering the default install concurrency in src/apps/manifest.ts, or letting the registry through the cap. Once that lands, re-running the check here should be enough.

In my sandbox, scripts/gate.ts is clean and the sentinel tests pass (34 of 34). The never-green test for another repository fails without the change. I couldn't run tsc locally, so types are unchecked.