Skip to content

docs(process): record a human's not-yet at completion review as a return to implementation #59

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jussi-modernpath merged 1 commit into from
Oct 23, 2026
Merged

docs(process): record a human's not-yet at completion review as a return to implementation #59

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion PROCESS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,9 @@ UR acceptance scenario -- may require --> SR
SR -> CODE -> TEST_CASE -> TEST_RESULT

EPIC: PROPOSED -> IN_PROGRESS -> IN_REVIEW -> DONE
IN_REVIEW -> IN_PROGRESS (a human's not-yet at completion review)
UR/SR: PROPOSED -> IN_PROGRESS -> IN_REVIEW -> DONE
IN_REVIEW -> IN_PROGRESS (returned with their Epic)
PROPOSED -> DONE (verified existing behavior, explicit acceptance)
BLOCKED | DEFERRED | OBSOLETE when applicable

Expand Down Expand Up @@ -106,7 +108,11 @@ than revising it in place.

`IN_REVIEW` means implementation is complete and awaits human completion
approval. The ownership lock, approved proposal and prior published requirement
content remain unchanged. `DONE` follows human completion approval: atomically
content remain unchanged. A human's not-yet at completion review returns the
Epic and its owned requirements to `IN_PROGRESS` with the plan, the
implementation approval and the ownership kept; record it with the
presentation the human declined, continue the build and submit for review
again. `DONE` follows human completion approval: atomically
publish the approved content, increment each requirement revision once, retain
an immutable accepted version with criteria and trace meaning, record the
actor, time, reason and originating Epic, and release ownership. A failed write
Expand Down
5 changes: 5 additions & 0 deletions skills/rdd-completion-review/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,11 @@ still-published requirements, ownership, implementation, traces and evidence.
per requirement, immutable accepted versions with criteria and trace meaning,
attributable Epic/requirement audit and released ownership. A failed action
must leave all effects unchanged; a repeated completion must not republish.
If the human answers not yet, 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.
6. After that publication is read back, use the CLI to mark each backlog, gap
or tooling record routed to the Epic as closed by the Epic, and read each
record back. If the human wants a record left open, leave it open and add
Expand Down