From ed7078deaca161fce96e1fa4f1c194f41c6465a8 Mon Sep 17 00:00:00 2001 From: Jussi Rajala Date: Wed, 16 Sep 2026 22:18:26 +0300 Subject: [PATCH] process: sourced intent is born PROPOSED not routed through DERIVED, and the candidate packet is a completeness precondition, not a trace DERIVED is for what a model inferred; anything an attributable human or document source states is born PROPOSED. rdd-discover step 4 stated the rule in one line without the reason, which is easy to misread as "confirm the proposal into existence." Say that sourced intent does not pass through DERIVED, and why DERIVED exists. The candidate-packet prerequisite for DERIVED -> PROPOSED is the packet's own completeness, bound to the confirmation gate; it is not a separately recorded trace gate. Both rdd-discover step 6 ("Evaluate the candidate-packet trace. Only after it passes...") and the strict-transitions table's "Required trace PASS" column read as if a recorded trace exists, sending a reader hunting a trace purpose that has none. Say the completeness is bound to the gate and the confirmation gate names no prerequisite trace, unlike entry and completion. Co-Authored-By: Claude Opus 4.8 --- PROCESS.md | 6 ++++++ skills/rdd-discover/SKILL.md | 25 +++++++++++++++++-------- 2 files changed, 23 insertions(+), 8 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index b368019..52c5770 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -180,6 +180,12 @@ not a gate answer. | Requirement `IN_REVIEW -> DONE` | Its completion predicate is satisfied at the delivered fingerprint | | Epic `IN_REVIEW -> DONE` | Every member is already `DONE` or named and completion-eligible in the same gate; the Epic completion predicate is satisfied | +The first row's prerequisite is the candidate packet's own completeness, bound +to the confirmation gate when it opens; unlike the entry and completion rows it +is not a separately recorded trace gate, and a candidate-confirmation gate names +no prerequisite trace. The remaining rows are backed by recorded trace gates the +human gate names. + One human answer may cover an exact Epic and named requirements. Apply member requirement transitions before the Epic and record a `USER:` source for each. diff --git a/skills/rdd-discover/SKILL.md b/skills/rdd-discover/SKILL.md index 02a1bca..a435a01 100644 --- a/skills/rdd-discover/SKILL.md +++ b/skills/rdd-discover/SKILL.md @@ -18,17 +18,26 @@ Derived requirement hold, Gates, and Discoveries/releases/conflicts. decisions, conflicts, and unanswered questions. 3. Update sourced product/domain documentation, vocabulary, rules, boundaries, contracts, and open questions without resolving ambiguity by assumption. -4. Create a directly sourced requirement as `PROPOSED`. Route a merely inferred - possible requirement to `DERIVED` and record its candidate statement, - sources, proposed relations, consequences, and confirmation brief. +4. Create a directly sourced requirement as `PROPOSED`. A requirement is + directly sourced when an attributable human or document source states the + intent — a proposal, an interview, a decision, an existing spec — so if a + human already asked for it, it is `PROPOSED`, not a candidate. Route only a + *merely inferred* possible requirement — behavior no human has stated, such + as behavior read off a codebase — to `DERIVED`, and record its candidate + statement, sources, proposed relations, consequences, and confirmation brief. + `DERIVED` exists to hold what a model inferred until a human confirms it + exists; sourced intent does not pass through it. 5. Treat feedback as a source, not an automatic implementation order. Classify it as a fact, decision, defect report, new outcome, change request, or ambiguity and route it to planning or triage. -6. Evaluate the candidate-packet trace. Only after it passes, open the exact - human confirmation gate and present its brief. Apply an attributable answer - as `PROPOSED`, `PENDING_VERIFICATION`, or `OBSOLETE`; otherwise stop at the - open gate. Proposed relations remain candidate-only until separately - authorized. +6. Confirm the candidate packet is complete — statement, sources, proposed + relations, consequences, and brief all present. That completeness is the + confirmation gate's prerequisite, bound to the gate itself; it is not a + separately recorded trace gate, so the confirmation gate names no + prerequisite trace (unlike entry and completion). Then open the exact human + confirmation gate and present its brief. Apply an attributable answer as + `PROPOSED`, `PENDING_VERIFICATION`, or `OBSOLETE`; otherwise stop at the open + gate. Proposed relations remain candidate-only until separately authorized. 7. Reconcile the source and candidate records. Do not create tests, implementation records, or release commitments in this pass.