[mattias-modernpath]

Consuming PR alignment

This branch already includes current req-driven-dev main 1f9e2a3 (merged PR59), so its process and skills describe both return to implementation and return to planning. Its current head is 3807119.

modernpath-v1 PR970 is rebased onto v1 main and retains the merged return-to-implementation process. modernpath-v1 PR996 includes that code and installs this combined snapshot; both return commands appear in its CLI guidance. Recommended order: v1 PR970, this process PR, then v1 PR996 after replacing its temporary source pin with this PR's merged revision and rebuilding/installing. No further rebase of this process branch is needed against current main.

Active Epics can return to planning when the human changes scope, acceptance or the plan. IN_PROGRESS and IN_REVIEW return to PROPOSED; DONE stays closed and changed work uses a follow-up Epic.

• The current implementation approver supplies the exact approved plan and explicit human decision. The atomic operation withdraws approval and releases ownership while preserving published content, accepted versions and history.
• The Audit Trail retains actor, time, reason, previous state, exact plan and withdrawn approval. Refused or failed operations leave state unchanged.
• Fresh decisions, independent plan review, human approval, registered verification and implementation review are required. Earlier reviews, candidates and executions cannot satisfy the new planning cycle. RED/GREEN obligations remain unchanged.
• PROCESS.md and seven delivery skills use the same lifecycle rule. Command syntax remains in the consuming CLI reference.

This is process documentation maintenance; it creates no product delivery records.

Relation to #59: A return to implementation keeps the approved plan, implementation approval and requirement ownership. A return to planning withdraws approval and releases ownership before revising the draft. The two transitions coexist.

Rebase and validation: Head 3807119f193e578866bc5760b89345f34f0c91fb is based on main 1f9e2a3cac59fcd2656a081a8aa94c5a71a7f415, including merged #54 and #59. git range-diff confirms the #58 patch is unchanged. All 18 internal Markdown links and heading anchors across 20 files resolve. The whitespace hook and git diff --check pass. #59's completion-review skill is preserved byte for byte, and its lifecycle transitions remain in PROCESS.md. All eight changed files were reviewed for competing lifecycle instructions; no blocking findings were demonstrated.

Downstream integration: modernpath-v1 #996 previously embedded 64a9a322ed02f99a38ba6ce82faf43096c03b1a9. Its pin needs refreshing for this rebased revision; no downstream runtime tests were rerun for this documentation rebase.

[mattias-modernpath]

The return-to-planning path in this PR needs one clarification alongside merged #59.

#59 says that a human's “not yet” at completion review returns the Epic and its requirements to IN_PROGRESS while retaining the approved plan, implementation approval and ownership. This PR also allows IN_REVIEW to return to PROPOSED, withdrawing approval and releasing ownership so the plan can change.

The transitions are compatible, but “not yet—we need different acceptance criteria” could appear to trigger either instruction. The completion-review wording currently treats every “not yet” as a return to implementation.

Suggested clarification in PROCESS.md and skills/rdd-completion-review/SKILL.md:

• When the human requests fixes within the approved scope, return to implementation and retain the plan, approval and ownership.
• When the human requests changes to the approved scope, acceptance criteria or plan, obtain an explicit decision to return to planning under §Returning to planning. Withdraw approval and release ownership before revising the draft; require fresh review and implementation approval before resuming changed work.
• If the answer does not establish which route the human intends, clarify it before applying a transition.

This clarification fits in #58 because it introduces the second route and can explain how it interacts with #59. It does not change either transition's intended behavior.

[jussi-modernpath]

Review of how this pull request meets the return to implementation (#59), which is already on main. This pull request is now rebased onto it, with its own text unchanged. Each return is clear on its own, but the combined text never relates them:

• Nothing tells the agent or the human which return fits a situation.
• The two returns are named in different ways. One is named after the human's answer ("a human's not-yet"), the other after where the Epic goes. A human who wants the plan changed also says "not yet", so that name does not tell the two apart.
• Completion review describes only the return to implementation. A human who wants a different outcome at completion review has no described route.
• The lifecycle diagram shows the return to implementation but not the return to planning.
• Completion has an explicit list of things that are not a human answer, such as an autopilot grant or silence. The return to planning has no such list, and rdd-autopilot mentions neither return.
• Triage and the discoveries table describe the return to planning but not the return to implementation, so a defect found while the Epic is IN_REVIEW has no route.

How the two returns differ, from the process text and the proposed CLI changes (ModernPath/modernpath-v1#970 and ModernPath/modernpath-v1#996, both open):

	Return to implementation	Return to planning
Allowed from	IN_REVIEW	IN_PROGRESS or IN_REVIEW
The Epic and its owned requirements move to	IN_PROGRESS	PROPOSED
Implementation approval and ownership	Kept	Withdrawn and released
Earlier reviews and test runs	Still count; renew what changes	Kept as history; none counts again
Who records it	Any workspace member, as for completion approval	Only the implementation approver
What the CLI checks	The completion presentation the human declined	The exact approved plan

Suggestions on the changed lines are inline. These touch text outside them:

Completion review: an answer that changes the plan (rdd-completion-review, step 5). The sentences on the return to implementation become:

If the human answers not yet and the approved plan still describes what they want, record that answer with the unchanged retained presentation as a return to implementation through the CLI. Read back the Epic and its owned requirements IN_PROGRESS with the plan, the implementation approval and the ownership unchanged, continue the build, and renew whatever changed before submitting for review again. If the answer changes the scope, acceptance or plan, do not record it as a return to implementation. Present the two routes in PROCESS.md §Returning to planning: approve completion of the approved plan and record the change as a backlog record, or have the implementation approver return the Epic to planning. Record only the route the human chooses.

Lifecycle diagram (PROCESS.md, top):

EPIC: PROPOSED -> IN_PROGRESS -> IN_REVIEW -> DONE
      IN_REVIEW -> IN_PROGRESS (a human's return to implementation)
      IN_PROGRESS | IN_REVIEW -> PROPOSED (a human's return to planning)
UR/SR: PROPOSED -> IN_PROGRESS -> IN_REVIEW -> DONE
      IN_REVIEW -> IN_PROGRESS (returned to implementation with their Epic)
      IN_PROGRESS | IN_REVIEW -> PROPOSED (returned to planning with their Epic)
      PROPOSED -> DONE (verified existing behavior, explicit acceptance)
        BLOCKED | DEFERRED | OBSOLETE when applicable

Human decisions: implementation approval -> completion approval
                 return to implementation (implementation approval kept)
                 return to planning (implementation approval withdrawn)
                 or explicit acceptance of verified existing behavior

The requirement line depends on a question still open on the return to planning in modernpath-v1 (ModernPath/modernpath-v1#996): what a return does to requirements that were DONE before the Epic took them. If a return restores their earlier status, the line says so.

What is not a return decision (PROCESS.md "Human approvals"; rdd-autopilot, step 6). After "Implementation approval, review, an autopilot grant, a commit, merge or silence is not a completion answer.", add:

None of these, and no failing gate, is a return to implementation or a return to planning either. Both need the human's explicit answer.

In rdd-autopilot step 6, "The grant is never that answer." becomes "The grant is never that answer, and never a return to implementation or to planning."

The phase table's triage row (PROCESS.md, "Development loop") says "active approvals preserved", which a return to planning makes untrue. Suggested: "active approvals preserved unless the human returns the Epic to planning".

How the two modernpath-v1 pull requests that implement the returns fit together is in comments on ModernPath/modernpath-v1#996 and ModernPath/modernpath-v1#970.

[jussi-modernpath]

Add a rule for choosing between the two returns, at the top of this section.

Nothing in the combined text tells the agent or the human whether a change calls for the return to implementation, this return, or new work in another Epic. Suggested text:

When the human asks for a change to an active Epic, or answers not yet at completion review, first establish whether the approved plan still describes what they want.

• If it does, the implementation approval stays. During IN_PROGRESS the build continues within the plan. At completion review, the human returns the Epic to implementation, as described under IN_REVIEW above.
• If it does not, the human chooses one of two routes. They can finish the approved plan and record the change as a backlog record for another Epic; every review and test run of this Epic still counts. Or the implementation approver returns the Epic to planning as described below; the implementation approval is withdrawn, and the plan review, the implementation approval and all evidence are done again. Return to planning when completing the approved plan would publish requirement content the human no longer wants.

Present both routes with what each keeps and what each repeats. Never use a return to implementation to change the scope, acceptance or plan: after it, the plan is still read-only.

[jussi-modernpath]

Name both returns by where the Epic goes.

"Not yet" describes what the human says, but it is a weak name for the decision: it is also true when the human wants the plan changed, and it does not say what happens next. The CLI command that records it is already named after its effect (return-to-implementation).

• In the lifecycle diagram, "(a human's not-yet at completion review)" becomes "(a human's return to implementation)".

• In this paragraph, the sentence that starts "A human's not-yet at completion review returns the Epic" becomes:

  At completion review, a human can return the Epic to implementation when the work does not yet meet the approved plan. The Epic and its owned requirements go back to IN_PROGRESS with the plan, the implementation approval and the ownership kept. Record the return with the presentation the human declined, continue the build and submit for review again.

Keep "not yet" as the human's answer in rdd-completion-review step 5, and keep that step's words "with the unchanged retained presentation as a return to implementation". A modernpath-v1 test of the installed process checks those words, and the approved criteria of the Epic behind the return to implementation depend on them (ModernPath/modernpath-v1#970, Epic 292).

[jussi-modernpath]

Keep this rule, and say what happens when someone else asks for the return.

The return to planning withdraws the approver's implementation approval and releases their ownership, which stops their build: their next candidate or test run is refused. So it should stay with the approver. The return to implementation can stay open to any workspace member, because it keeps the implementation approval and the ownership.

The human who wants this return can be someone else, such as the human answering at completion review. Suggested addition:

If the human who asks for the return did not approve implementation, ask the approver to record it. Until they do, the Epic stays in its current state and the plan does not change. If the approver is not available, report a blocker.

[jussi-modernpath]

"selected requirements" should be "owned requirements", the term the paragraph on the return to implementation uses. The operation returns every requirement the Epic owns, but a reader can take "selected" to mean a choice made at the time of the return.

[jussi-modernpath]

Name what this return checks. The return to planning checks the approved plan; a presentation is what the return to implementation checks. Suggested: "A plan that differs from the approved one, an actor other than the implementation approver, an ownership conflict or a failed write leaves all effects unchanged."

[jussi-modernpath]

Name the states: "either active state" becomes "an IN_PROGRESS or IN_REVIEW Epic", so the sentence is clear when read on its own.

[jussi-modernpath]

Route a defect found while the Epic is IN_REVIEW, and offer both routes for a changed outcome.

The table and rdd-triage describe the return to planning but not the return to implementation.

• This row becomes:

  Revise a PROPOSED plan and obtain human implementation approval. For an active Epic, the human chooses: finish the approved plan and record the change as a backlog record, or return the Epic to planning, then fresh review and approval. DONE uses a follow-up Epic.

• "Technical failure inside approved behavior", two rows down: add "; for an IN_REVIEW Epic, after the human returns it to implementation".

• rdd-triage step 2:

  Continue red-first work for a defect within approved behavior. If the Epic is IN_REVIEW, report the defect to the human at completion review, and fix it only after they return the Epic to implementation.

[jussi-modernpath]

Point the skills at the choice, not only at the return to planning.

After approval, the skills now offer only the return to planning. rdd-deliver, rdd-discover, rdd-start, rdd-triage and rdd-verify keep the plan read-only "until an explicit human return to planning ... is applied", and rdd-build and rdd-plan send the agent straight to §Returning to planning. Finishing the approved plan and recording the change separately, which keeps every review and test run, is no longer offered.

Suggested in all seven: "keep the active plan and owned requirements read-only, and present the routes in PROCESS.md §Returning to planning". In rdd-build and rdd-plan, follow the return to planning only after the human chooses it.

[jussi-modernpath]

Say where the loop goes after each return. Step 6 sends the work to completion review but not back from it. Suggested addition to step 6:

If the human returns the Epic to implementation, go back to step 5 and then repeat this step. If the human chooses a return to planning, go back to step 2.