process: discovery births sourced intent as PROPOSED; candidate packet is a precondition, not a trace

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.
 

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.