* Update the same PR after review instead of opening a new one A v2 implementation turn already reused its predecessor's branch and PR, but every guard had to hold and one of them was unreachable by default. Close the five ways a revision ended up on a second pull request. - `radiald init` now scaffolds a `run` block with `forge: { kind: 'github' }`, and `writeConfig` serializes `run` at all — it dropped it, so a scaffold could not carry a forge even if the builder produced one. `run.spaces` may be empty in the file; only `radiald run` demands one. - Without a forge adapter the dispatcher now decides reuse from the index: an in-namespace branch, a PR in this project's repo, and no trusted `merge` annotation on the predecessor. It logs which signal answered and what that signal cannot see. - The compose card and the successor button say which PR the next version lands in, hedged — the browser can see a merge annotation, not a PR closed by hand. A `request_changes` verdict makes the successor the primary button; every sibling stays live. - `RequestDraft.basedOn` is a list, and a successor inherits its predecessor's other-type bases. A v2 was arriving with the findings against v1 and none of the plan those findings judge it against. - Two v2 requests off one predecessor no longer push to one branch concurrently; the second is reported as contended and launches on a later pump. - The implementation prompt fetches the base branch and merges it when behind — a reused branch is checked out shallow and single-branch. - The ledger records the selected branch, and the reuse decision logs on the success path too. Co-Authored-By: claudebot.disnetdev.com (did:plc:n6ku5xddiuguwze3f356evla) <claudebot.disnetdev.com@noreply.radial> * Resolve the review findings on the v2 PR-continuation change The reused-branch checkout could not merge. `checkoutRepo` clones `--depth 1`, which grafts the branch tip as parentless, so `git merge` against the base fails with "refusing to merge unrelated histories" — on exactly the continuation path this feature exists for, and the prompt's fetch deepened only the base, which is the wrong side. A continued branch is now cloned with `MERGE_CLONE_DEPTH` history and its base comes down beside it as `origin/<base>`; the prompt merges that and is told to `--unshallow` (never `--allow-unrelated-histories`) if the fork point is deeper still. Proven end to end against real git over `file://`: the shallow clone refuses, the new one merges. The `merged` guard on the no-forge fallback was dead where it mattered. Merge annotations come from the merge poller, which only runs with a forge configured, so a forgeless daemon can never see one — and a predecessor branch deleted after its PR merged would be cloned again on every retry until the request gave up. The fallback now also asks the remote: one `git ls-remote`, same credentials as the clone, no forge API. Docs, the startup advisory and the reuse log say what that signal is and is not worth. `freshChainNote` hangs on every other-type button, most of which produce neither a branch nor a pull request, so it no longer promises them — it is a fact about chains, and `prContinuity` keeps the branch/PR sentence. `prContinuity` also mirrors the daemon's third guard: a pull request outside the project's own repository is not one the turn will continue. `scrubbedGitEnv` drops an ambient `GH_TOKEN`/`GITHUB_TOKEN` rather than passing it to a checkout of any host. That is what the non-GitHub-checkout assertion always meant, and it clears the red test every turn run inside Radial's own containers was seeing. Co-Authored-By: claudebot.disnetdev.com (did:plc:n6ku5xddiuguwze3f356evla) <claudebot.disnetdev.com@noreply.radial> --------- Co-authored-by: claudebot.disnetdev.com (did:plc:n6ku5xddiuguwze3f356evla) <claudebot.disnetdev.com@noreply.radial>