pr-pipeline: inputs from the 2,000-PRs effort, and the local-lane work waiting on deployed lanes #6202

Problem

The 2,000-PRs effort (integration branch feat/poteto-2500-prs-digest) planned merge authority, a post-PR
stage and a post-merge stage before #6139 added the PR pipeline convention (docs/conventions/pr-pipeline/,
ADRs 0049-0051). The pipeline now governs those stages. The effort's merge work is redesigned as the local
babysit lane that docs/conventions/pr-pipeline/README.md:204 allows ("A repository has one merge
authority: either the local babysit lane (loop-lane) or pr-merge"). That lane reads the same rung and
work-class config as pr-merge; no second merge rubric is built.

The effort builds none of this local-lane work until the pipeline's verify, merge and post-merge lanes are
deployed. Until then the local lane has no review verdict to read, and nothing lowers the merge rung after
a bad merge. This issue does two things. It hands the pipeline effort the items that belong in its lanes
or schema, and it records the deferred work and its design, so that work can be re-planned once the lanes
exist. Slice numbers below are the effort's own work-unit numbers, given so its pull request can cross-refer.

Inputs for the pipeline effort

1. Say which merge authority a repository uses. README:204 states the one-authority rule, but the
   schema has no field for it. Proposal: merge.authority with values pr-merge and local-babysit.
   Until such a field exists, the local lane treats any configured pr-merge lane as "not mine". Lanes
   and slots are enabled by default in the schema.
2. Name the rung-lowering repository variable and the kill switch (README:100, README:198-200), so a
   local lane can honour both. Proposal: a 404 from a readable variables endpoint means "not lowered",
   and any other failure means rung off.
3. Tie verdict check runs to the lanes App. Any workflow with checks: write can post a check run
   named <lane> / <activity>. Name the App's identity in a lane-power file, so readers accept only check
   runs that App posted.
4. Add to the reader-forced denied paths: AGENTS.md, CLAUDE.md and .claude/** at any depth;
   every docs/conventions/*.yaml lane-power or policy file (for example execution-target.yaml, which
   chooses where unattended stages run); docs/conventions/workspace-environment.md (a repository's entry file), whose setup,
   up, info and down commands lanes run unattended in every worktree; and the merge wrapper's
   scripts. Until the pipeline adopts them,
   the local lane keeps its own forced set as a superset of the pipeline's.
5. Read team config at the base SHA. README:98-99 covers the lane's own config. A skill a lane calls
   should also read docs/conventions/*.yaml and instruction files at base-sha, not the PR head, or a PR
   can change the rules it is judged by. The effort's shared reader (lib/parse-concern-value.sh) gains a
   validated --ref for this.
6. Record a relocated <root> where a local reader can find it. README:37-38 lets a repository move
   <root>; plugin readers use the fixed docs/conventions.
7. Post-merge smoke check and canary. Where a consumer deploys, post-merge-verify should run the
   consumer's declared smoke check against that environment, and a silent-revert canary alert should file
   a raw issue linking the PR. Candidate activity: a non-interactive verification:confirm post-merge mode.
8. C4 (structural work) under the local lane. Proposal: the local lane refuses C4 at any rung, because
   ADR 0050 requires three independent checkers including a Codex judge, which only CI lanes provide. C4
   autonomy stays with pr-merge.
9. When a respond lane counts as active. Proposal: enabled in config, and its workflow file present on
   the default branch. babysit-prs stands down for that duty only then. A consumer who copies the example
   config, which enables every lane, must not lose babysit's feedback, CI-fix and base-update work while
   the lanes do not exist.
10. Refine and verify slots. code-metrics:audit-suppressions as a pr-run-checks gate (its
    non-interactive findings output ships in the effort), and code-tidying:dissolve-comments report --added-since as a pr-refine slot, in place of a local comment pass at PR prep.
11. Skills the example lanes call ask questions nobody answers under dontAsk.
    source-control:pull-request asks for approval (SKILL.md:229,236) when called as fix-ci and
    address-feedback. verification:confirm asks for the goal (SKILL.md:115) when called as
    check-intent. batch-simplify is called without its unattended flag. review:fanout is a review
    fan-out, not a late-comment sweeper. None of the called skills writes detector-findings or a record
    bundle.
12. Plan comment as a check-intent input. With plan_store: tracker (planning's userConfig, or
    the plan_store key in docs/conventions/planning.yaml, which wins), /planning:plan posts the
    approved plan to the claimed work item through /work-items:track publish-plan as one comment whose
    first line is <!-- planning:plan v1 -->; a re-publish edits that comment in place. check-intent
    may read it through the issue input, taking only a comment whose first line is that marker and
    whose author is a trusted actor (the newest when there are several), and treats the plan text as
    data.
13. Plugins for CI lanes. The cloud bootstrap's plugin list covers local-lane stages only. CI lanes
    need the plugins that own their activities' skills.
14. Model and effort per lane. The schema sets no model or effort per lane or activity. ADR 0045 makes
    the multi-agent plugin the routing owner.
15. The review of record. pr-review runs review:code-review, which reads only CLAUDE.md and
    REVIEW.md. The effort's paved-path and file-size rules reach that review only through REVIEW.md.
    feat(source-control): call review:explain-change from the pull-request ready flow #6107 adds an explain call at ready, beside the pr-explain lane.
16. Upstream producer naming and trust. The standards vocabulary has no upstream function words for
    the effort's monthly upstream-drift workflow. The issues it files as github-actions[bot] carry text
    from upstream repositories into intake, so that bot should not count as a trusted actor.

Deferred local-lane work

Each item waits for the deployed verify, merge and post-merge lanes, then is re-planned against them. The
design that was planned before deferral is in each collapsed section.

Constraints for that re-plan:

• No local merge authority without a deployed post-merge-verify.
• The local lane never writes work-class: labels: a label the operator's own identity sets cannot be told
  apart from a human's (README:141-143).
• A config parse error resolves the whole file to rung off, never one key from a partly parsed file.
• The canonical example config is a reader test fixture.

Done when

• The pipeline effort has accepted, declined or scheduled each of the 16 inputs, and recorded its answer
  here.
• Inputs 1-3 and 7 are settled, and the verify, merge and post-merge lanes are deployed. The deferred work
  is then re-planned, citing this issue, and the issue closes.

Amendment (auto-merge-safe-prs)

Decisions from the auto-merge-safe-prs plan, accepted by the user on 2026-10-12. Where this section and the
text above disagree, this section wins. Phase numbers refer to that plan.

What changes

• Merges are no longer human-only. The babysit lane may merge, without a human, a same-repository C2
  pull request that the new diff risk scorer rates LOW, on review evidence bound to the pinned head SHA.
  Everything else stays human-merged.
• The wrapper is the one merge authority. babysit_merge.py (--unattended) makes every unattended
  merge decision, on every host. No GitHub Actions merge workflow is built, and pr-merge is not deployed
  in this repository.
• The deferral ends early for this repository. The deferred local-lane work no longer waits for the
  pipeline's verify, merge and post-merge lanes. The constraint "No local merge authority without a deployed
  post-merge-verify" is met by the wrapper's own post-merge check (phase 10) instead.
• V1 merges nothing until two things are live: the post-merge check (phase 10), and the agent identity,
  a GitHub App installed on this repository only (filed in melodic-software/github-iac). Until both exist,
  the unattended path refuses. It is turned on by one human-merged config change (phase 15).
• C2 only at launch. C3 joins only by a merged config change once its promotion evidence holds. C4 stays
  human-gated and C5 human-merged; no C4 rung is added.

Answers to the inputs and deferred items

• Input 1: accepted as merge.authority (local-babysit | pr-merge), plus merge.agent-identity,
  which is required when the authority is local-babysit (phase 5).
• Input 2: accepted. The rung-lowering variable is CLAUDE_LANES_MERGE_RUNG_CAP (off/C2/C3),
  human-set and lower-only; the wrapper never writes it. A 404 after a proven-readable listing means no cap;
  any other failure means off. Kill switches: CLAUDE_LANES_DISABLED (org) and
  CLAUDE_LANES_REPO_DISABLED (repository) must each read exactly false; a read error or a
  repository-level CLAUDE_LANES_DISABLED shadow refuses. A post-merge failure is recorded as a marker issue
  that only a human can clear by closing it.
• Input 3: superseded by run-bound evidence. Per lane, the newest run of the lane's caller workflow on
  the pinned SHA must conclude success and carry a completion annotation and marker for that SHA (phase 9).
  This depends on the review lanes failing when no review completed (fix(review): AI review lanes report success without posting a review on large PRs #7257, phase 3). The App-posted check
  run design in items 23 and 30 is replaced by this.
• Input 4: accepted as the HIGH path floor, fixed in code and unioned with merge.diff-check.denied-paths.
  A HIGH path is never auto-merged.
• Input 5: accepted. Config is read at the base SHA.
• Input 7: accepted as four post-merge signals: the scheduled full pr-require-checks run, a full run
  dispatched per auto-merged SHA, the silent-revert canary, and a read-back that the merged headRefOid
  equals the pinned SHA. A red full run gets one re-run of its failed jobs first: red again counts as a
  failure, green records a flake. A failure files the demotion marker issue, which holds the rung at off
  until a human closes it directly. Only one unattended merge is in flight at a time. No auto-revert in V1. No deploy-target smoke
  check, but owner decision 16 (2026-10-14) requires a per-PR live smoke of changed skills before the first unattended merge of any PR touching plugins/*/skills/** or plugins/*/agents/**; until it exists those PRs are excluded from auto-merge.
• Input 8: accepted. C4 is refused locally.
• Item 22: adopted, except that babysit_loop_merge does not retire. It stays as a second cap, lowered
  to c2-mechanical (phase 2). The effective rung is the minimum of merge.rung, babysit_loop_merge, the
  cap variable and any open demotion.
• Item 24: adopted. Merges go through the merge queue with --match-head-commit, never --auto, and
  only when every required check is green; an armed auto-merge is a refusal that the wrapper disarms.
• Item 25: the proposal stands. The paired raise c3-this-run can no longer widen an unattended merge.

New external effects

• Merge-group backstop job (phase 11). A new job in pr-require-checks.yml, needed by ci-status,
  with issues: read. For every queue entry a non-human enqueued, it re-checks from the base SHA the rung,
  the kill switches and the fixed rules (HIGH paths, size, label provenance, demotion issue, holds, one merge
  in flight, ALLGREEN grouping), and fails the group on any miss. It can eject queue entries.
• Post-merge alert workflow (phase 12). A new workflow_run workflow with issues: write only. When a
  scheduled or dispatched full run, or the canary, fails on main, it files the demotion issue as
  github-actions[bot], so detection does not wait for a lane cycle.