Close the M2 loop: a run opens a pull request, and /fix lands on it

[artyomsv]

What

The M2 loop ran end to end for the first time, and this is what it took. Everything here was
found by running it against a real forge and a real model, not by reading the code.

docs/UNVERIFIED.md said the loop was "covered in three places and joined in none". It is joined
now, and three of the four things that stopped it were defects nothing had ever executed.

The three fixes

1. Codex never started. codex-cli 0.146.0 does not read OPENAI_API_KEY: with the variable
set and no ~/.codex/auth.json it exits 1 at once, printing No such file or directory (os error 2)
and no NDJSON. Every run this deployment dispatched died in about thirty seconds and was reported as
MODEL_UNAVAILABLE, because "exited non-zero and said nothing" was the only reading the classifier
had — so the diagnosis went to the model and to the key while the CLI had never run. The arm now
performs the login OpenAI documents for programmatic use, piping the key from printenv so argv
still carries no secret, and a failed login exits with a code of its own and is reported as an agent
failure rather than as a model that would not answer.

2. Nothing opened a pull request. M2 shipped the PullRequestSink port, three forge adapters
and the body builder, and no caller — pullRequestSink(...) was reachable from nothing. The
milestone's own goal, "a run can end at a pull request rather than at a branch", was true of the
parts and false of the product. The result saga now proposes what a build run pushed:

• Last, and after the projection, because it reads the row the projection has just written.
• A fix run proposes nothing: its change is already on a pull request's own source branch
  (ADR-040) and already under review.
• The forge is asked for an existing request for that head before one is opened, so a redelivered
  result cannot propose twice — and the run's own number is checked first so it does not even ask.
• Opening happens after the push succeeded and can fail on its own, so a failure is recorded
  beside the run and never changes its status. The work is on the remote either way, and throwing
  would nack the record and re-run every consumer that already applied it.
• V57 adds the four columns this needs. The task line a title needs is stored at dispatch,
  because the prompt is not a column and a finished run knows only a branch and a list of paths.

3. wasNull() answered about the wrong column. The plan read pr_number, then built its record
— and the argument list read three more columns before asking wasNull(), which reports on the last
column read. It answered about the task summary, which is present on every dispatched run, so a
queued row came back with pr_number = 0. Zero is not null, "already proposed" was therefore true,
and the opener returned with no log line, no error and no row. The first live run after the wiring
landed pushed a branch that nothing proposed, silently. The projection test now queues a row with
a summary and asserts the number is absent, which is the pairing that makes the trap visible.

What ran, in order

Step	Result
POST /api/runs → agent → push	branch spire/issue-28-5 as the FACTORY account
Pull request opened by the run	#29
Webhook → review of that pull request	completed, by the REVIEWER account
A planted BLOCKER on a second pull request	found by the reviewer unaided
/fix on that finding → run → push	onto the pull request's own branch, no second request

ADR-038's separation held throughout: the reviewer is one account, the factory another, and the
run id of a fix is the finding's own comment id.

Also here

• docs/superpowers/specs/2026-09-10-accounts-scopes-and-roles-analysis.md — the analysis of the
  duplicated credentials on the Accounts and Context screens, per-provider scope introspection with
  sources and dates (GitHub fine-grained tokens report nothing; Atlassian classic tokens have no
  scopes at all), why ADR-038 stands unamended, and two options with a recommendation.
• docs/factory/ROADMAP.md M3 — the authorisation rule the first live /fix argued for:
  authorise on write access to the repository, not on authorship, because "the pull request's
  author" on a public repository means any stranger.

Verification

• testFast --rerun-tasks green; spire-orchestrator and spire-harness-codex green (1210 + 48).
• Mutation-verified: the login step, the login-failure classification, the shell quoting guard, the
  BUILD-only rule, the already-proposed guard, the find-first, the never-fail-the-run catch, the
  saga's ordering, and the wasNull read — each broken on purpose, each killed by its own test.
• Rebased onto master after Renew OIDC sessions instead of re-authenticating the browser #131; no file in this branch touches that work.

Not fixed here

A refused /fix is logged and posts no reply to the thread, so from the forge's side it looks
ignored. Found while running this; it belongs with M3's actor allowlist rather than with the wiring.

[artyomsv]

Reviewed the changes at 7e6a42f. Three actionable findings are attached inline: the shell invocation breaks two existing worker tests, proposal outcomes are unavailable through the runs API/UI, and a re-armed dispatch can propose its new work with the previous prompt's summary.

Validation: inspected the dispatch/result/projection/forge paths and changed tests; checked the current CI logs (fast tests pass; service tests fail in two RunUnitBuilderTest cases); reproduced the stale-summary retry against an isolated PostgreSQL 17 instance using the actual queued() SQL extracted from this commit. The reproduction accepted the retry with Task B while returning Task A as task_summary. I did not rerun the full Java suite locally. The temporary database was removed and the worktree is unchanged.

Submitted as a COMMENT review because the authenticated GitHub account is the PR author; GitHub does not permit requesting changes on one's own PR.