[maxigimenez]

gh is no longer installable on the machine the runner runs on, which took GitHub polling, labelling and commenting with it. Nothing about that was load-bearing: gh lived in exactly one file, and the six calls Sentinel0 actually made are plain REST.

The gh removal

GitHubRestClient (packages/common/src/github.ts) makes them over fetch. It sits in common rather than the orchestrator because cloud-api needs three of the same calls to answer the dashboard's pickers, and two clients would be two places that know GitHub's field names.

The token arrives through a provider function, never a constructor string. A PAT is a constant and would not need one; a GitHub App installation token expires hourly, and the provider is the shape that serves both — moving to an App changes how a token is obtained and nothing else in the file.

Two REST behaviours that are not gh behaviours, both of which fail silently, both pinned by tests:

	gh	REST
GET /issues	issues only	also returns pull requests — unfiltered, every open PR raises a ticket trigger
review requests	one reviewRequests array	split into requested_reviewers + requested_teams — reading one makes a team-targeted route never match

getPullRequestDiff is deleted, not ported. It has had no callers since the Hermes pivot — fetching a diff is the agent's job under that boundary — so porting it would have re-crossed the boundary in the wrong direction.

What remains is five calls: list issues, list pulls, ensure/add/remove labels, post a comment. Labels are the half that cannot be given up: sentinel0:in-progress is the loop guard, and a runner that cannot write labels re-fires every route on every cycle. The comment exists for postFailure, the one case an agent structurally cannot report on its own behalf.

A fine-grained PAT with Issues: read and write and Pull requests: read covers all of it. No Contents, nothing that could push code.

Credentials

Cloud as broker, not proxy. GET /v1/runner/integrations hands the runner its tokens; the runner still calls api.github.com itself, so trigger collection survives a cloud outage the same way cached routes do. Proxying the data too would have made polling stop whenever Railway did.

• Encrypted at rest, AES-256-GCM under SENTINEL0_SECRET_KEY. crypto.ts throws rather than deriving a key from nothing — a deployment that quietly encrypted every token under a guessable constant would look exactly like a working one.
• Runner-scoped endpoint, because it is the only one anywhere returning a plaintext secret. A snt_usr_ key is rejected before the handler runs.
• IntegrationStore keeps tokens in memory only. A decrypted PAT in ~/.sentinel0/ is a worse trade than a runner that needs its control plane once at boot. GITHUB_TOKEN / LINEAR_API_KEY stay as an explicit fallback the cloud always outranks.
• Precedence is project override, then organization default, resolved by resolveIntegration in common so the cloud and the dashboard cannot disagree.
• PUT /v1/integrations/:provider verifies the token before storing it and returns the account it authenticated as. Saved unverified, a bad credential fails hours later as a 401 in a log nobody reads.

The dashboard

Storing the token in the cloud is what lets Add project stop asking people to type things it could look up. The free-form JSON textarea hinted use {} asked an operator to know the filter schema, spell a slug correctly, and guess a repository's labels — three mistakes discovered hours later as an empty poll. It now offers the repositories the credential can reach and that repository's real labels. The JSON escape hatch stays, behind a disclosure.

Organization pages gain the design's second-level rail (showOrgRail in sentinel0 App Noir.dc.html). That group had outgrown a flat list: five destinations, each a settings surface rather than a view of work, would have buried Runs and Routes in the primary sidebar. Settings splits three ways — Slack moves to Integrations beside the credentials it belongs with, and the runner table to its own page, having been the only table on a page of forms.

Driving it in a browser found one bug worth naming: end on every rail NavLink left the rail blank on /projects/new; end on none of them leaves Settings lit across everything nested under it. It is now derived from the list — only entries another entry sits under need it — with a test for each half.

Deploying this

Two steps before it works, both in docs/deploy-cloud.md:

1. Set SENTINEL0_SECRET_KEY on the Railway API service — 32 random bytes, base64 or hex:

   node -e "console.log(require('crypto').randomBytes(32).toString('base64'))"
   

   Losing or rotating it makes stored credentials unreadable; they are re-added, not recovered.
2. Apply migration 007_integrations.sql.

Verification

pnpm build, pnpm lint and pnpm test all pass — 526 tests, 43 of them new. Both new screens were driven in a browser against fixture data.

Known gaps

• The agents' gh is untouched. route-catalog.ts still tells agents to run gh pr view / gh pr diff / gh pr review inside their own Hermes profiles, under their own identities. Sentinel0's token cannot help them. If the machine's constraint applies to Hermes too, those routes still degrade — that is a separate change.
• HostExecutor is now dead. Nothing in the monorepo constructs it. Left in place rather than removing a subpath export from a package the CLI bundles; worth deciding separately.
• test/fixtures/integrations.json is hand-written, with no Postgres available to record from. Marked in the fixtures README as the second documented exception alongside runs_run_2.json.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RbctixjBYjPL823X6CEMd3