process: autopilot — one grant, human checkpoint at sprint end

AGENTS.md

@@ -31,7 +31,9 @@ on a decision, or what is blocked:
 2. read this file and `PROCESS.md`;
 3. enter the session with `skills/rdd-start/SKILL.md` — it verifies the store
    binding before selection and the active release for normal delivery; then use
-   `skills/rdd-deliver/SKILL.md` for end-to-end delivery, or the applicable
+   `skills/rdd-deliver/SKILL.md` for end-to-end delivery,
+   `skills/rdd-autopilot/SKILL.md` for a sprint under a human's autopilot
+   grant, or the applicable
    focused `skills/rdd-*/SKILL.md` when the request explicitly ends at one
    process pass; use `skills/rdd-verify/SKILL.md` for entered verification work
    requiring new tests, and `skills/rdd-reverse-engineer/SKILL.md` to

PROCESS.md

@@ -43,6 +43,8 @@ Humans decide product intent, scope, architecture, acceptance, priority,
 release, and workflow. Agents establish facts and propose options; they do not
 make those decisions by assumption. Ask humans only for decisions that cannot
 be established from authoritative records, code, tests, or runtime evidence.
+Under an autopilot grant an agent may take a reversible product decision as a
+recorded assumption pending confirmation (§Autopilot).
 
 | Tag | Source |
 |---|---|
@@ -311,7 +313,8 @@ bookkeeping is never bundled with a decision. A human's answer — to a gate
 or to a question — is a decision about that gate or question, never an
 instruction to enter the next phase: the agent applies it, reports what
 moved, and waits for the human's word before any further phase, in the
-complete loop as in a focused pass.
+complete loop as in a focused pass. Under an autopilot grant the agent
+continues instead (§Autopilot).
 
 ### Automatic transitions
 
@@ -421,6 +424,81 @@ A change that stops being eligible — a finding, a wider boundary, an excluded
 area — leaves the lane for single-SR scope with its full packet and review. It
 is never forced through.
 
+### Autopilot
+
+Autopilot is for building larger scopes — greenfield systems, initiatives,
+many Epics — when stopping at every process check costs more than the check
+protects. It keeps the records and the tests. It moves the human checkpoint to
+the end of a sprint, and turns process refusals into logged work instead of
+stops.
+
+**The grant.** A human who may answer entry and completion gates for the scope
+grants autopilot once. The grant names:
+
+- the scope (Epics, an initiative, or a system);
+- the end of the sprint (a date);
+- any areas that stay out of it.
+
+It is recorded with its `USER:` source where the scope's decisions are
+recorded: in each Epic's decisions as it is selected, in a store-backed
+repository, and as `process/autopilot.md` in a file-backed one. The grant is
+the human's answer, given in advance, to every entry gate in its scope. The
+agent applies it by answering each such gate with the grant's `USER:` source.
+It is never the answer to a completion gate. A grant ends at its date, when the
+human withdraws it, or when its scope is done.
+
+**Under a current grant these rules change:**
+
+| Rule | Normal | Autopilot |
+|---|---|---|
+| Entry gate | The human answers | The agent answers, citing the grant |
+| Cold review | Up to two rounds, blocking | One pass, then at most one narrow confirmation. Material findings are folded into the packet as tests or boundary lines, and the rest are logged. If the confirmation still fails, the item is built ahead of its record and the failure is logged. |
+| Packet completeness | Items 1–6 and the brief complete before review | Write what the builder needs; a gap the review finds is folded in or logged, never a stop |
+| Preflight facts (suspended selections, stale snapshots, drift, open holds) | Stop selection | Clear each with its documented verb, or log it and continue |
+| A refusal at a phase boundary | Stop and report | Try the documented clearing verb once. If it still refuses, log it, move to the next item, and let the record catch up at sprint end. |
+| A product question | Asked; the loop waits | Asked, but the loop does not wait: see below |
+| After a gate answer or a pass | Wait for the human's word | Continue |
+
+**Product questions.** The agent still asks the questions only a human can
+answer: behavior, scope, user experience, meaning of data, priority. It asks
+each one when it arises, in plain words. Then it takes the most reasonable
+default and records it in the Epic's decisions as *assumed under autopilot,
+pending confirmation*, with the grant's `USER:` source. Then it continues.
+
+It waits for an answer only when a wrong guess is hard to undo:
+
+- deleting or migrating data that already exists;
+- security, authentication, or authorization;
+- money, billing, or legal terms;
+- a contract with an outside party.
+
+**What does not change:**
+
+- Requirements are written with sources, and assumptions are marked as such.
+- Red-first tests, with evidence recorded.
+- The store's server-side refusals are cleared through the sanctioned tool or
+  logged. They are never bypassed with hand-made writes.
+- Merging, deploying, and releasing stay with humans.
+- Destructive operations, secrets, and the grant's excluded areas stay out.
+
+**The log.** Each skipped check, uncleared refusal, advisory finding left
+open, and build ahead of its record is filed as a gap record naming the
+sprint. Nothing is dropped silently.
+
+**Sprint end.** One independent review reads everything the sprint built —
+the change, not the packets — against its requirements and tests. The human
+then gets one page:
+
+- what was built, with evidence;
+- the assumed decisions to confirm or change;
+- the log;
+- the review's findings.
+
+The human answers completion item by item, as in a lane batch. A rejected
+item stays `IN_REVIEW`. A changed assumption is triaged into the next sprint.
+Only then does normal gate discipline apply again to anything the grant did
+not cover.
+
 ## Planning and readiness
 
 Planning consists of packet authoring, independent cold review, and entry
@@ -531,7 +609,8 @@ records and sections whose fingerprints moved, the findings still open, and
 what those touch — and carries the unchanged remainder at that round's verdict;
 its trace still pins the full current aggregate. A current
 pass proceeds to entry review. After a second failed round, report the remaining
-material findings to the human; do not start a third round automatically.
+material findings to the human; do not start a third round automatically. Under an autopilot grant, one pass
+and at most one narrow confirmation replace the rounds (§Autopilot).
 A small change gets one narrow pass from an independent context — the
 boundary against the code, the RED plan, and the eligibility — and no second
 round: a blocking finding sends it out of the lane.

README.md

@@ -45,7 +45,7 @@ apply that model; `file-state/` serializes its records without redefining it.
 |---|---|
 | `AGENTS.md` | shared agent policy and canonical entry point |
 | `PROCESS.md` | complete canonical process |
-| `skills/` | delivery orchestration and focused passes; `rdd-verify` for entered verification work; `rdd-reverse-engineer` for baseline publication or DERIVED additions; `rdd-reverse-engineer-verify` and `rdd-reverse-engineer-accept` for eligible existing baselines; `rdd-audit` for documents and citations |
+| `skills/` | delivery orchestration, an autopilot sprint (`rdd-autopilot`), and focused passes; `rdd-verify` for entered verification work; `rdd-reverse-engineer` for baseline publication or DERIVED additions; `rdd-reverse-engineer-verify` and `rdd-reverse-engineer-accept` for eligible existing baselines; `rdd-audit` for documents and citations |
 | `file-state/` | canonical serialization shapes for Epic, requirement, gate, work-selection, and backlog/gap records |
 
 ## Distribution

skills/rdd-autopilot/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: rdd-autopilot
+description: Build a larger scope — Epics, an initiative, or a greenfield system — under a human's autopilot grant, keeping requirements, sources, and red-first tests while moving human approval to the end of the sprint. Use when a current autopilot grant covers the scope, or when the human asks to start one. Asks product questions without waiting on them, clears or logs process refusals instead of stopping, and ends the sprint with one independent review and one completion page.
+---
+
+# Run an autopilot sprint
+
+Read the project `AGENTS.md` and canonical `PROCESS.md`
+(`.modernpath/rdd/PROCESS.md` in a consuming repository), especially
+§Autopilot. `PROCESS.md` owns the rules; this skill owns the order. The phase
+skills still describe how each pass is done. Where their stops and round
+bounds differ from §Autopilot, §Autopilot applies.
+
+## Start
+
+1. **Find the grant.** Read the grant that covers the scope and check that it
+   is current. Without one, ask the human for it in one message that names:
+   - the scope;
+   - the sprint end date;
+   - any excluded areas;
+   - what the human gives up: per-Epic entry approval and waiting on
+     questions;
+   - what the human keeps: the completion answer at sprint end, and merges.
+
+   Record the answer as §Autopilot says.
+2. **Run `rdd-start`'s preflight, without stopping on it.** Clear each
+   preflight fact with its documented verb: reconcile, refresh, or release a
+   selection this sprint does not need. If a fact will not clear, log it and
+   go on. Only a missing or unreachable store stops the sprint.
+3. **Order the work.** List the scope's Epics and requirements in build order:
+   dependencies first, then what unblocks the most. Show the list in one
+   message and start.
+
+## Loop, per Epic or single SR
+
+1. **Plan.** Write or complete the requirements with their sources (`rdd-plan`),
+   including reconnaissance and a RED strategy.
+2. **Review.** Run one cold review from an independent context
+   (`rdd-cold-review`), and record its findings.
+   - Fold each material finding about the change into the packet as a test
+     or a boundary line, and resolve it as a packet edit.
+   - Log the rest.
+   - If the review failed, ask the same independent context for one narrow
+     confirmation that the folded findings close it, and record that verdict.
+   - If it still fails, log it and build the item ahead of its record.
+   - No further rounds.
+3. **Enter.** Answer the entry gate with the grant's `USER:` source, and apply
+   it.
+4. **Build.** Build red-first (`rdd-build`): RED evidence, GREEN, cleanup,
+   evidence recorded, and requirements advanced to `IN_REVIEW`.
+5. **Commit and push** the feature branch at each waypoint. Never merge.
+6. Go to the next item without waiting.
+
+## When something refuses
+
+1. Read the refusal. Run the verb it names, or the one `mp-process-cli` (or
+   the project's store guide) lists for it, **once**.
+2. If it still refuses:
+   - file a gap record naming the sprint, the item, the refusal text, and
+     what was tried;
+   - if the code is ready, keep building it on the branch ahead of its record;
+   - move to the next item.
+3. Never write the store by hand, never retry the same refused call in a
+   loop, and never widen a grant's scope to get past a refusal.
+
+## When a product question comes up
+
+1. Ask it in one plain sentence, with the options and what each changes.
+2. If a wrong guess is hard to undo (existing data, security, money, outside
+   contracts), park that item and build others until the human answers.
+3. Otherwise record the most reasonable default in the Epic's decisions as
+   *assumed under autopilot, pending confirmation*, and continue.
+4. When the human answers later, apply it. A changed assumption is triaged:
+   fix it now if the item is still being built, otherwise queue it for the
+   next sprint.
+
+## Sprint end
+
+Run it at the grant's end date, when the scope is built, or when the human
+asks.
+
+1. **Reconcile** every record the sprint touched. Try once more to clear the
+   logged refusals.
+2. **Review.** Run one independent review of everything the sprint built, from
+   the code at the branch head, against its requirements and tests
+   (`rdd-completion-review`'s audit). Record the findings.
+3. **Present one page:**
+   - built, with evidence;
+   - assumed decisions to confirm;
+   - the log;
+   - review findings;
+   - what is not built and why.
+
+   Give links to the working-set files.
+4. **Apply** the human's completion answers item by item. A rejected item
+   stays `IN_REVIEW`. A changed assumption goes to `rdd-triage`.
+5. **Report** whether the grant continues into another sprint, or ends.
+
+## Report
+
+During the sprint, one line per finished item: its id, RED and GREEN commits,
+and anything assumed or logged. At sprint end, the page above.

skills/rdd-cold-review/SKILL.md

@@ -69,7 +69,9 @@ review audits the change the packet proposes, not the packet as a document.
    for single-SR scope.
 9. Run at most two rounds on the selected planning scope. After a second
    failed round, report the remaining material findings to the human;
-   do not start a third round automatically.
+   do not start a third round automatically. Under an autopilot grant there is
+   one pass and at most one narrow confirmation that its folded findings close
+   it; either way the sprint continues (`PROCESS.md` §Autopilot).
 10. Return the cold-review trace gate `PASS` only when the material-finding rule
    in `PROCESS.md` is satisfied. Otherwise return `FAIL` with exact blockers.
 

skills/rdd-start/SKILL.md

@@ -45,7 +45,9 @@ background: date it against the store revision before relying on it, and
 refresh it when it cannot be dated. A projection whose currency is unknown is
 reported as unknown, never presented as current.
 
-An unmet preflight fact is the report. Do not select work past it.
+An unmet preflight fact is the report. Do not select work past it — unless a
+current autopilot grant covers the scope: then clear or log each fact and
+continue (`PROCESS.md` §Autopilot, `rdd-autopilot`).
 
 ## Take the scope
 
@@ -113,7 +115,9 @@ Select the earliest unmet prerequisite for the frozen scope and hand off to
 its skill; a change that meets the small-change lane's eligibility under a
 current lane authorization is planned, reviewed and entered through that lane: `rdd-discover`, `rdd-plan`, `rdd-cold-review`, `rdd-entry-review`,
 `rdd-build`, `rdd-verify`, `rdd-completion-review`, or `rdd-deliver` for the
-complete loop. Source-inventory onboarding uses `rdd-reverse-engineer`.
+complete loop. When a current autopilot grant covers the scope, or the human
+asks for one, hand off to `rdd-autopilot` instead. Source-inventory
+onboarding uses `rdd-reverse-engineer`.
 
 For genuine source-scoped baseline requirements still in PENDING_VERIFICATION,
 route to rdd-reverse-engineer-verify without development entry. When a dedicated