Problem
Proposal-Only Output is the Loop's invariant: a Run's sole external effect is a draft pull request a human merges (CONTEXT.md; loop/README.md, "Proposal-Only Output"; ADR 0010, ADR 0014). It is right for tourbot, and it is also why a chain of sub-issues stalls overnight: the Selector will not pick the next ticket while the previous one's Proposal is open (proposal-open), and nothing merges that Proposal until the operator is back at a keyboard. Last night's run on parent-engagement-planning #365 had that shape - each landing unblocked the next ticket - and a loop that cannot land works one ticket per human visit.
The operator wants to choose per target whether the Loop proposes or lands (grilling on the Tracewake extraction, 2026-09-02). Landing can come later; this issue keeps the idea from dying with the session.
What it would be
• A per-target setting, landing: propose | land, default propose. propose is today's behaviour, unchanged.
• land is the Selector's act, not the Run's: off the box, as the operator, after the Route has read the checks green - the same place awaiting-review is applied today. The box's token stays Contents + Pull requests with no way to merge, so a Run still cannot land anything whatever its prompt said; the only thing that can is reviewed Selector code acting on a green Proposal.
• Journaled under its own event kind (issue.landed) so the Journal stays readable by outcome, and mailed the way a green Proposal is mailed today.
• Red checks, checks still pending past the wait, and no checks at all route to ready-for-human exactly as now. land never lands an unverified Proposal.
What it needs first
This is a trust ruling rather than a configuration option, and it wants its own ADR before any code: land removes the human merge gate that ADR 0010's content-trust collapse and spec #73's blast-radius argument both lean on. The ADR has to answer which targets may ever be land (a personal repository, yes; tourbot, presumably never), whether land needs green checks alone or green checks plus a label the operator applies per issue, and what the operator reads afterwards - a merged pull request carrying the Run's comment, or a notice asking for a post-merge read.
Acceptance criteria
• A per-target landing setting exists, propose is the default, and a target with no setting behaves exactly as today - proved by the offline Selector suite.
• With landing: land, a Proposal whose checks are green is merged by the Selector as the operator and journaled issue.landed; red, pending-past-timeout and no-checks Proposals still route to ready-for-human.
• The box's GitHub token is unchanged and assert-credentials.sh still passes.
• An ADR records the ruling and names which targets may be land.
• tests/selector-mutations.py covers the new guard: removing the green-checks condition turns the suite red.
Context
Filed from the Tracewake extraction grilling on 2026-09-02, as a child of orchestration #322. It moves to the Tracewake repository with the extraction.
Originally filed as Educational-Travel-Adventures/orchestration#337.
Problem
Proposal-Only Output is the Loop's invariant: a Run's sole external effect is a draft pull request a human merges (
CONTEXT.md;loop/README.md, "Proposal-Only Output"; ADR 0010, ADR 0014). It is right for tourbot, and it is also why a chain of sub-issues stalls overnight: the Selector will not pick the next ticket while the previous one's Proposal is open (proposal-open), and nothing merges that Proposal until the operator is back at a keyboard. Last night's run on parent-engagement-planning #365 had that shape - each landing unblocked the next ticket - and a loop that cannot land works one ticket per human visit.The operator wants to choose per target whether the Loop proposes or lands (grilling on the Tracewake extraction, 2026-09-02). Landing can come later; this issue keeps the idea from dying with the session.
What it would be
• A per-target setting,
landing: propose | land, defaultpropose.proposeis today's behaviour, unchanged.•
landis the Selector's act, not the Run's: off the box, as the operator, after the Route has read the checks green - the same placeawaiting-reviewis applied today. The box's token stays Contents + Pull requests with no way to merge, so a Run still cannot land anything whatever its prompt said; the only thing that can is reviewed Selector code acting on a green Proposal.• Journaled under its own event kind (
issue.landed) so the Journal stays readable by outcome, and mailed the way a green Proposal is mailed today.• Red checks, checks still pending past the wait, and no checks at all route to
ready-for-humanexactly as now.landnever lands an unverified Proposal.What it needs first
This is a trust ruling rather than a configuration option, and it wants its own ADR before any code:
landremoves the human merge gate that ADR 0010's content-trust collapse and spec #73's blast-radius argument both lean on. The ADR has to answer which targets may ever beland(a personal repository, yes; tourbot, presumably never), whetherlandneeds green checks alone or green checks plus a label the operator applies per issue, and what the operator reads afterwards - a merged pull request carrying the Run's comment, or a notice asking for a post-merge read.Acceptance criteria
• A per-target
landingsetting exists,proposeis the default, and a target with no setting behaves exactly as today - proved by the offline Selector suite.• With
landing: land, a Proposal whose checks are green is merged by the Selector as the operator and journaledissue.landed; red, pending-past-timeout and no-checks Proposals still route toready-for-human.• The box's GitHub token is unchanged and
assert-credentials.shstill passes.• An ADR records the ruling and names which targets may be
land.•
tests/selector-mutations.pycovers the new guard: removing the green-checks condition turns the suite red.Context
Filed from the Tracewake extraction grilling on 2026-09-02, as a child of orchestration #322. It moves to the Tracewake repository with the extraction.
Originally filed as Educational-Travel-Adventures/orchestration#337.