6o. Issue triage and GitHub Issues — BY HAND, once per environment

Unhandled errors are grouped into issues in the console (docs/proposals/60-issue-triage.md): Needs you shows the open ones and the ones that came back, and the ones somebody has taken, quietly, with whose they are. Logs → Issues is the list; an issue's page takes it, resolves it (Fixed with a commit, deploy or change; Not a bug / expected; Upstream; Won't fix with the reason), reopens it, and files it on GitHub. None of that needs anything set up. Filing and the two-way sync do, and are off until Ant does the four steps below — Waiting on Ant.

Issues auto-resolve (DESIGN.md §17, decision 97; nothing to set up). An issue nobody has taken, last seen before a control-plane deploy that has now run for 24 hours, is resolved Fixed by the platform on the scheduler's hourly pass, with the note "no recurrence for 24h after deploy <hash>" — the hash staging.yml kept for that run. It comes back by itself on its next occurrence. To keep one open on purpose, take it: a taken issue is never auto-resolved. A pass that resolved any says so in the scheduler's log (issue-auto-resolve: resolved …); a deploy is dated from the first pass that saw it, so a Worker without DIVVENT_DEPLOYED_FROM (a deploy before 2026-09-30) notes none, and nothing is auto-resolved until the next deploy.

The repository is private (checked 2026-09-28). If it is ever made public, remove the token first (Logs → Issues → Remove the token): an issue carries no customer data, but it does carry Worker names, route ids and trace ids.

1. The scheduler's key. Per environment, run node scripts/issues-key.mjs | gh secret set DIVVENT_ISSUES_KEY --env staging (and --env production). It is an RSA private key; the console never sees it. The next deploy puts it on the scheduler and no other Worker, and the scheduler publishes its public half within five minutes — Logs → Issues then says The scheduler's key: published.
2. The token. On GitHub, Settings → Developer settings → Fine-grained tokens → Generate: resource owner divvent-hq, Only select repositories → divvent-hq/divvent, Repository permissions → Issues: Read and write and nothing else (Metadata: read is added by GitHub). One token per environment, with an expiry, and put it in the credential register. Paste it into Logs → Issues → GitHub token in that environment's console. It is sealed to the scheduler's key as it is kept: nobody can read it back, the field empties as it is sent, and no command takes it as an argument. Rotating is pasting a new one.
3. The webhook secret. Per environment, a long random string: node -e "console.log(require('node:crypto').randomBytes(32).toString('hex'))" | gh secret set GITHUB_WEBHOOK_SECRET --env staging — keep the value for step 4 (or generate it, set it in both places, and let the terminal go). The next deploy puts it on the portal alone.
4. The webhook. On the repository, Settings → Webhooks → Add webhook: payload URL https://app.divvent.dev/github/issues (production's portal for production — one webhook per environment), content type application/json, the secret from step 3, Let me select individual events → Issues only, active. GitHub's ping answers 200; Recent Deliveries shows each one's status.

What it then does. Create GitHub issue on an issue's page is filed within five minutes, once ever. Closing it on GitHub — by hand or by a commit saying Fixes #123 — resolves ours as Fixed and links the commit; closed as not planned is Won't fix. Reopening it there reopens ours. Ours coming back reopens GitHub's with a comment; resolving or reopening ours in the console closes or reopens GitHub's. Automatic filing is at the foot of Logs → Issues, off by default and per environment: at N occurrences in an hour, or anything that answered somebody with a 5xx.

When it does not. Logs → Issues says which half is missing: key not published (step 1, or the scheduler is not ticking — Logs shows its faults), token not set or sealed to a key the scheduler no longer holds (step 2 again, after a key rotation). An issue's page says Filing failed — GitHub answered 401 for a token that expired or lost its scope; set a new one and Create GitHub issue again. A webhook delivery GitHub shows as 400 had a signature that did not verify (the two secrets differ); 404 means the portal has no secret; 429 means more than 60 in a minute.