process: discovery births sourced intent as PROPOSED; candidate packet is a precondition, not a trace - #23
Draft
jussi-modernpath wants to merge 1 commit into
Conversation
…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 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two wording clarifications to the discovery phase — no behavior change. Prompted by a downstream session where a UX proposal (user-sourced intent) was mis-routed to
DERIVED, and theDERIVED → PROPOSEDconfirmation was then hunted for a "candidate-packet trace" that does not exist as a recorded trace gate.1. Birth rule —
rdd-discoverstep 4The rule "directly sourced →
PROPOSED; merely inferred →DERIVED" was one line with no rationale, easy to misread as "confirm the proposal into existence." Added the reason:DERIVEDholds what a model inferred until a human confirms it exists; anything an attributable human or document source states is bornPROPOSEDand does not pass throughDERIVED.2. The candidate packet is a precondition, not a trace —
rdd-discoverstep 6 +PROCESS.mdstrict-transitionsStep 6 said "Evaluate the candidate-packet trace. Only after it passes…", and the strict-transitions table's column is "Required trace
PASSbefore human input" — both read as if a recorded trace gate backsDERIVED → PROPOSED. It does not: the candidate-packet completeness is bound to the confirmation gate itself, and a candidate-confirmation gate names no prerequisite trace (unlike entry and completion, which are backed by recorded trace gates). Clarified in both places.Prompted downstream by the
modernpathCLI'smp-process-cliskill, which now documents the CLI form of this discovery/birth/confirm flow (ModernPath/modernpath-v1#540).🤖 Generated with Claude Code