H4b: "trust this issue" action and a runner guard for untrusted issues

[mchwang]

Who this is for: whoever builds lane H's last step (H4b), and reviewers of lanes F and G.
What it covers: the "trust this issue" action, and the runner guard that makes trust matter.

Summary

• Today, an issue whose author is not a repository collaborator shows "! Needs trust" on the Issues screen, but nothing records a trust decision and nothing enforces one.
• POST /api/runner start and resume (F: wire the runner and startup recovery into the server #91, PRs F: wire the runner and startup recovery into the server (#91, part 1) #102 and F: start and resume a task's plan through /api/runner (#91, part 2) #105) run a task's plan without checking who wrote its issue. So an issue from anyone can reach an execute agent.
• H4b adds a recorded trust decision, a guard on the runner, and the action on the Issues screen.

Why

The design ("Keeping unattended runs safe", "Which issues can be queued" and "Which comments reach the agent"):

• By default, only issues written by repository collaborators can be queued.
• Other issues need you to click "trust this issue". codeboost records that choice.
• By default, only collaborators' comments reach the agent. After "trust this issue", other people's comments are included too, inside the same data block.
• Every invocation records which comments it was given.

docs/implementation/issue-prioritization.md (H4b) says the trust record goes through the Store owner (lane F) after F1's Store changes. Those have landed (F1a, #53, and later migrations up to schema v9), so H4b is unblocked.

What exists

Piece	Where	State
Trust classification	github/issues.ts: trust: 'trusted' | 'requires-approval', from the repository's current collaborator list (not author_association; see #41, #42)	Done
Trust mark on the Issues screen	web/public/app.js: "✓ Collaborator" or "! Needs trust"	Done
Collaborator-only comments in execute prompts	GhIssueGateway.issueText	Done
Recorded trust decision	—	Missing
Runner guard	start, resume in web/server.ts (runChoice), ItemExecutor.begin	Missing
Record of comments given to each invocation	—	Missing

Needed

1. Store. A trust record keyed by repository identity and issue number. It holds who decided, when, and the issue author login at that time. Use an append-only record or one row per issue with a revoke. A schema version bump with a migration test.
   • Trust is scoped to one repository. An issue number alone never matches (AGENTS.md: preserve repository identity).
   • If the issue's author changes (for example, the account is deleted and becomes ghost), the earlier decision no longer applies.
2. Runner guard. start and resume refuse a task whose issue is neither written by a current collaborator nor trusted. The check reads the author and collaborator list from GitHub at admission (bounded, fail closed: a read that fails or is incomplete refuses). It uses the same rules as GhIssueGateway. A refusal is a recorded, definite outcome like the other /api/runner refusals.
3. Comments after trust. For a trusted issue, issueText includes every comment, still as untrusted data in the same block. For an untrusted collaborator-written issue, behaviour does not change.
4. Comment record. Each execute attempt records which comments its prompt carried (comment IDs or a digest plus count), so a person can see what the agent was given.
5. API and screen. POST /api/issues with {"action":"trust", ...} and {"action":"untrust", ...}, with an idempotency key and the issue's current author as a precondition. The Issues screen gets the button and shows "✓ Trusted by you on ". Follow DESIGN.md. Keep focus on the control while the request runs (AGENTS.md, "Async review UI"). Remove the note that says trusting is not available.
6. Demo mode. The action works against fixture issues and never contacts GitHub.

Questions to decide before coding

1. Does trust also let a planning invocation include non-collaborator comments, or only execute? (Planning is not yet live; lane G.)
2. Is revoking trust allowed while a task for that issue is running? Suggested: allowed, but it applies only at the next admission. A running attempt is not stopped.
3. Should the guard also run before publishing a PR (F: publish a finished task's pull request in production #103), in case trust was revoked after the run?

Done when

• Tests show start and resume refuse an untrusted issue, and run it after trust is recorded.
• Tests show a failed or incomplete collaborator read refuses.
• Tests show trust for owner/a#5 does not apply to owner/b#5.
• Tests show a trusted issue's prompt includes non-collaborator comments, and an untrusted one does not.
• The attempt record lists the comments supplied.
• Browser tests cover the button, focus, stale responses and demo mode.
• docs/implementation/issue-prioritization.md gets an H4b section.

Related: #41, #42, #55 (H4a), #91, #103, #107.

🤖 Generated with Claude Code