@hassangameryt/freeflow 0.7.3 → 0.8.0

package/skills/design-for-depth/references/module-and-dependency-design.md

@@ -2,7 +2,7 @@
 
 Read this when module decomposition, cohesion, dependency direction, cycles, layering, policy-versus-infrastructure ownership, or change propagation materially affects the design.
 
-Do not use this reference merely because the codebase has many files or dependencies.
+This reference is judgment. Do not use it merely because the codebase has many files or dependencies.
 
 ## Decompose Around Coherent Decisions
 
@@ -112,36 +112,6 @@ Before extracting shared code, ask:
 
 Some duplication is cheaper than a shared abstraction with unclear ownership.
 
-## Test Through Module Contracts
-
-Module tests should protect:
-
-- coherent behavior;
-- invariants;
-- public failure semantics;
-- dependency contracts;
-- real seams.
-
-Question module shape when tests must:
-
-- construct many internals;
-- reproduce dependency ordering;
-- mock several owned collaborators;
-- inspect states callers should not know.
-
-Do not make production architecture imitate the test framework.
-
 ## Return
 
-Return:
-
-- affected modules and responsibilities;
-- policy, state, or failure ownership;
-- dependency direction;
-- cycle or layering pressure;
-- proposed boundary and caller contract;
-- variation or migration justifying seams;
-- evidence and unresolved decisions;
-- narrowest supported route.
-
-Stop when dependencies support the selected outcome without unnecessary coordination. Do not reorganize the entire codebase for conceptual purity.
+Test module shape through its contract, as Design for Depth's Check Through The Intended Interface describes; do not make production architecture imitate the test framework. Return the affected responsibilities, policy/state/failure ownership, dependency direction, any cycle or layering pressure, and the proposed boundary with the variation or migration that justifies its seams. Stop when dependencies support the outcome without unnecessary coordination; do not reorganize the codebase for conceptual purity.

package/skills/design-for-depth/references/state-and-failure-boundaries.md

@@ -2,7 +2,7 @@
 
 Read this when correctness materially depends on canonical state, partial effects, atomic visibility, concurrency, cancellation, retries, recovery, reconciliation, or evidence of the final outcome.
 
-Do not apply this reference to a simple local value change whose state owner and failure behavior are already sound.
+This reference is judgment. Do not apply it to a simple local value change whose state owner and failure behavior are already sound.
 
 ## Name Canonical State
 
@@ -122,15 +122,4 @@ A passing happy-path test does not prove partial-failure safety.
 
 ## Return
 
-Return:
-
-- canonical state and owner;
-- material invariants;
-- transition and visibility boundary;
-- failure unit;
-- forbidden partial outcomes;
-- retry, resume, replay, and recovery capabilities actually required;
-- evidence and remaining uncertainty;
-- narrowest supported route.
-
-Stop when state and failure ownership are sufficient for the current design decision. Do not design every theoretical failure mode.
+Return the canonical state and owner, material invariants, the failure unit and its forbidden partial outcomes, the retry, resume, replay, and recovery capabilities actually required, and remaining uncertainty. Stop when state and failure ownership are sufficient for the current decision; do not design every theoretical failure mode.

package/skills/diagnose-failure/SKILL.md

@@ -7,18 +7,33 @@ description: "Use when a bug, failure, regression, performance problem, or repea
 
 Establish what fails and why before selecting a correction. A supported cause distinguishes meaningful alternatives well enough to bound the next action; it does not require impossible certainty.
 
-A plausible path, requested patch, reviewer theory, or favorable rerun is not a supported cause. Diagnosis owns the causal question, interpretation, and correction boundary—not authority to run experiments or change production.
+A plausible path, requested patch, reviewer theory, or favorable rerun is not a supported cause. Diagnosis owns the causal question, interpretation, and correction boundary, not authority to run experiments or change production.
+
+The **Rules** below are binding; if one cannot be met, stop and say why. Everything else is **judgment**: follow its stated goal, and adapt when a different choice serves that goal better.
+
+## Rules
+
+- Never invent the expected behavior. When accepted behavior or source truth is unsettled, use [Decision Gate](../../skills/decision-gate/SKILL.md) before diagnosing against it.
+- Before active evidence generation, confirm that the work agreement covers the path, environment, repetition, instrumentation, cost, sensitive-data handling, and cleanup or recovery. Covered bug investigation needs no extra permission solely because it is diagnosis. Otherwise return the proposed observation and stop condition to [Workflow](../../skills/workflow/SKILL.md) and wait.
+- Preserve unfavorable evidence. Never rerun until a failure disappears, and never drop a contradicting observation.
+- Minimize and sanitize logs, traces, payloads, dumps, screenshots, and browser state; never expose credentials or unnecessary private data.
+- Report a mitigation as containment, not resolution. Never claim fixed when only mitigation succeeded or the reported boundary remains unverified.
+- If a remedy changes scope, compatibility, public behavior, failure semantics, or another user-owned boundary, return its concrete consequence and alternatives through Workflow before adopting it.
 
 ## Enter For An Unsettled Cause
 
+Goal: diagnose when the cause is genuinely unknown, and not otherwise.
+
 Use diagnosis for unexplained bugs, failed checks, regressions, flaky or environmental behavior, contradictory observations, and corrections that repeatedly fail or expose related coordination.
 
-Do not investigate an ordinary mistake when fresh evidence already establishes a clear local defect and the accepted remedy. Return that correction to [Workflow](../../skills/workflow/SKILL.md). Finding count or several bugs in one area does not establish a shared structural cause.
+Do not investigate an ordinary mistake when fresh evidence already establishes a clear local defect and the accepted remedy; return that correction to Workflow. Finding count, or several bugs in one area, does not establish a shared structural cause.
 
 Keep diagnosis within the same coherent Slice. Use [Track Work](../../skills/track-work/SKILL.md) when continuity requires preserving the hypothesis, discriminating evidence, rejected approaches, blocker, and next useful action. Do not record every trial.
 
 ## Establish The Failure, Not The Proposed Fix
 
+Goal: know exactly what fails, against what expectation, at what boundary.
+
 Identify only what the investigation needs:
 
 - accepted expected behavior and its source;
@@ -27,14 +42,14 @@ Identify only what the investigation needs:
 - the strongest boundary actually observed;
 - any difference between that boundary and the reported failure.
 
-Prefer the reported path and environment. A nearby symptom may suggest a hypothesis but does not reproduce the reported defect. State reduced-fidelity limits explicitly.
-
-Allowed behavior is not a bug: a cache hit does not establish stale-read failure when caching is permitted. A possible race in source is not the cause without evidence connecting its timing and state to the symptom.
+Prefer the reported path and environment. A nearby symptom may suggest a hypothesis but does not reproduce the reported defect; state reduced-fidelity limits explicitly.
 
-Use [Decision Gate](../../skills/decision-gate/SKILL.md) when accepted behavior or source truth is unsettled. Do not invent an expectation and then diagnose why the implementation violates it.
+Allowed behavior is not a bug: a cache hit does not establish a stale-read failure when caching is permitted. A possible race in source is not the cause without evidence connecting its timing and state to the symptom.
 
 ## Choose A Distinguishing Observation
 
+Goal: the next observation can tell the viable explanations apart.
+
 State a falsifiable leading explanation and only the viable alternatives the next observation must distinguish:
 
 ```text
@@ -50,13 +65,13 @@ Read [Diagnostic Loop Catalog](references/diagnostic-loop-catalog.md) when the e
 
 Use [Action Selection](../../skills/action-selection/SKILL.md) when tools, targets, or observers for the selected causal question remain uncertain or broad. Stop reading when adequate context supports the experiment; the objective is not exhaustive understanding of the subsystem.
 
-Before active evidence generation, confirm that the agreement covers the path, environment, repetition, instrumentation, cost, sensitive-data handling, and cleanup or recovery. Covered bug investigation needs no extra permission solely because it is diagnosis. Otherwise return the proposed observation and stop condition to Workflow and wait.
-
 If no safe useful observer is available, report the smallest missing input, trace, environment, permission, or instrumentation rather than patching a guess.
 
 ## Interpret One Iteration
 
-Run one covered observation, changing one distinguishing variable at a time. Use [Verify Work](../../skills/verify-work/SKILL.md) for its claim-and-boundary method when needed. Diagnosis retains ownership of causal inference.
+Goal: each observation moves the causal question, and its meaning is not overstated.
+
+Run one covered observation, changing one distinguishing variable at a time. Use [Verify Work](../../skills/verify-work/SKILL.md) for its claim-and-boundary method when needed; diagnosis keeps ownership of causal inference.
 
 Keep three results separate:
 
@@ -64,9 +79,7 @@ Keep three results separate:
 - **Hypothesis result:** Supported, Contradicted, Inconclusive, or Unavailable at the stated observing boundary.
 - **Cause status:** Supported or Unresolved.
 
-A supported hypothesis need not establish the cause. A useful supported cause connects trigger and state through mechanism to the symptom, predicts the observations, materially weakens viable alternatives, and is sufficient to bound a correction without guessing.
-
-If only the strongest remaining hypothesis is supported, say so and identify its missing causal link. Do not claim certainty from one consistent observation.
+A supported hypothesis need not establish the cause. A useful supported cause connects trigger and state through mechanism to the symptom, predicts the observations, materially weakens viable alternatives, and is sufficient to bound a correction without guessing. If only the strongest remaining hypothesis is supported, say so and name its missing causal link; one consistent observation is not certainty.
 
 Route from the result:
 
@@ -81,11 +94,11 @@ Stop when the cause is sufficiently supported or no covered observation can mate
 
 ## Keep The Investigation Inside The Task
 
-Before following another prerequisite, distinguish a limitation of the current observer or approach from a requirement of the accepted outcome. A failed reproduction method is not proof that production needs new infrastructure, stronger guarantees, or a host change.
+Goal: the correction serves the accepted outcome, not the investigation's momentum.
 
-Choose the smallest supported correction preserving accepted behavior. If the remedy changes scope, compatibility, public behavior, failure semantics, or another user-owned boundary, return the concrete consequence and alternatives through Workflow before adopting it.
+Before following another prerequisite, distinguish a limitation of the current observer or approach from a requirement of the accepted outcome. A failed reproduction method is not proof that production needs new infrastructure, stronger guarantees, or a host change.
 
-Classify only the owning cause supported by evidence:
+Choose the smallest supported correction that preserves accepted behavior. Classify only the owning cause the evidence supports:
 
 - local implementation defect;
 - invalid, stale, or inadequate check;
@@ -97,29 +110,31 @@ Classify only the owning cause supported by evidence:
 
 Use [Design for Depth](../../skills/design-for-depth/SKILL.md) when causal or direct design evidence establishes structural pressure. It shapes the boundary without re-proving the cause. If design reveals an unsupported causal premise, return to diagnosis with that exact uncertainty.
 
-## Protect Evidence And Contain Harm
+## Contain Harm And Keep Instrumentation Honest
 
-Logs, traces, payloads, dumps, screenshots, and browser state may be sensitive. Minimize and sanitize them; do not expose credentials or unnecessary private data. Bound repetitions by time, cost, effects, and environment safety. Preserve unfavorable evidence rather than rerunning until it disappears.
+Goal: the investigation causes no damage and leaves no hidden residue.
 
-Temporary instrumentation must distinguish hypotheses. Keep it isolated and state its observer, mutation/performance impact, removal condition, and whether it remains afterward.
+Bound repetitions by time, cost, effects, and environment safety. Temporary instrumentation must distinguish hypotheses; keep it isolated and state its observer, its mutation or performance impact, its removal condition, and whether it remains afterward.
 
-When immediate harm needs containment before diagnosis is settled, return one narrower, reversible mitigation to Workflow. It must preserve evidence, define checking and recovery, and avoid settling undefined behavior. Report mitigation as containment, not resolution.
+When immediate harm needs containment before diagnosis is settled, return one narrower, reversible mitigation to Workflow. It must preserve evidence, define checking and recovery, and avoid settling undefined behavior.
 
-A requested experimental patch can generate evidence when authorized as learning. It does not automatically select production behavior or authorize continuing beyond its question.
+A requested experimental patch can generate evidence when authorized as learning. It does not select production behavior or authorize continuing beyond its question.
 
 ## Return A Supported Correction Boundary
 
+Goal: the next owner can correct the failure without re-diagnosing it.
+
 Return proportionately:
 
 - failure and accepted expectation at the required boundary;
 - observed diagnostic loop, check result, and hypothesis result;
 - causal chain, alternatives weakened, and remaining uncertainty;
 - owning cause and smallest coherent correction;
-- minimized regression signal and original reported path or strongest available observer;
+- minimized regression signal and the original reported path or strongest available observer;
 - instrumentation, containment, residual effects, and authority limits.
 
-An already-covered correction can return to [Execute Work](../../skills/execute-work/SKILL.md). Preserve the diagnostic evidence and use suitable regression checks without prescribing a formal test-first sequence. Use [Verify Work](../../skills/verify-work/SKILL.md) to design or classify those checks. Use [Simplify Code](../../skills/simplify-code/SKILL.md) only for an accepted behavior-preserving removal of obsolete or workaround machinery, not as a substitute for the fix.
+An already-covered correction can return to [Execute Work](../../skills/execute-work/SKILL.md). Preserve the diagnostic evidence and use suitable regression checks without prescribing a formal test-first sequence; use Verify Work to design or classify those checks. Use [Simplify Code](../../skills/simplify-code/SKILL.md) only for an accepted behavior-preserving removal of obsolete or workaround machinery, not as a substitute for the fix.
 
-After correction, verify the minimized regression signal and the original reported path or strongest available observer. A nearby passing test is insufficient. If the fix fails or reveals related shared-state consequences, re-enter the affected causal question before another patch.
+After correction, verify the minimized regression signal and the original reported path or strongest available observer; a nearby passing test is insufficient. If the fix fails or reveals related shared-state consequences, re-enter the affected causal question before another patch.
 
-Stop with the supported correction, missing evidence, containment boundary, or unresolved decision explicit. Do not claim fixed when only mitigation succeeded or the reported boundary remains unverified.
+Stop with the supported correction, missing evidence, containment boundary, or unresolved decision explicit.

package/skills/diagnose-failure/references/diagnostic-loop-catalog.md

@@ -2,6 +2,8 @@
 
 Read this when the exact distinguishing loop is not obvious or several loop shapes remain plausible.
 
+This reference is judgment: adapt it to the failure in front of you.
+
 Use it to select the smallest observation whose possible outcomes differ between meaningful hypotheses at the required boundary.
 
 ## Common Loops

package/skills/diagnose-failure/references/flaky-and-performance-diagnosis.md

@@ -2,6 +2,8 @@
 
 Read this before selecting or running a diagnostic observation when timing, randomness, environmental variance, concurrency, or resource behavior shapes the failure.
 
+This reference is judgment, with one Rule of its own: never stabilize a flaky failure with sleeps, retries, wider timeouts, swallowed errors, or disabled checks unless evidence shows that mechanism addresses the causal timing or availability contract. Suppressing observation is not correction.
+
 Diagnostic measurement explains why variance or resource behavior occurs. After correction, Verify Work establishes whether the representative behavior or performance claim is supported.
 
 ## Flaky Failures
@@ -22,8 +24,6 @@ One green rerun does not contradict an intermittent-failure hypothesis. One red
 
 Do not loop mutating production behavior merely to improve reproduction.
 
-Do not stabilize a flake with arbitrary sleeps, retries, wider timeouts, swallowed errors, or disabled checks unless evidence shows that mechanism addresses the causal timing or availability contract. Suppressing observation is not correction.
-
 ## Performance Problems
 
 Measure the reported path before optimizing it.

package/skills/discuss/SKILL.md

@@ -7,20 +7,34 @@ description: "Use when exploring, clarifying, or revisiting what to accomplish o
 
 Build enough shared understanding to choose the next sound action. Discussion can establish both what to accomplish and how to approach it; it need not end at requirements or continue until every implementation detail is known.
 
-Discuss owns exploration, alternatives, assumptions, and direction. It does not turn conversation, a recommendation, or a recorded proposal into execution authority.
+Discuss owns exploration, alternatives, assumptions, and direction.
+
+The **Rules** below are binding; if one cannot be met, stop and say why. Everything else is **judgment**: follow its stated goal, and adapt when a different choice serves that goal better.
+
+## Rules
+
+- Conversation, convergence, a recommendation, or a recorded proposal never authorizes execution. Begin implementation only under an execution agreement established through [Workflow](../workflow/SKILL.md).
+- Keep supported facts and explicit decisions distinct from hypotheses, proposed mechanisms, and unresolved choices. An assistant recommendation never becomes a requirement because it is repeated or recorded.
+- Leave priorities, behavior, constraints, and tradeoffs the user owns to the user; ask rather than decide them.
+- Never weaken required behavior to make an approach look simpler.
+- A successful demonstration is not production acceptance; promotion must be deliberately selected and its effects authorized.
 
 ## Start From The User's Intent
 
+Goal: the conversation serves what the user is actually trying to do, at the depth they asked for.
+
 Respond to the substance before steering the process.
 
-A request to discuss keeps the user involved as understanding develops. Gather relevant existing facts when needed, explain what they imply, and return at the next meaningful question or supported conclusion. Do not treat convergence as permission to implement.
+A request to discuss keeps the user involved as understanding develops. Gather relevant existing facts when needed, explain what they imply, and return at the next meaningful question or supported conclusion.
 
-A direct action request may already settle the outcome and delegate approach selection. Do not force a discussion phase when existing evidence can resolve the remaining facts and reversible local choices. Return clear covered work to [Workflow](../workflow/SKILL.md).
+A direct action request may already settle the outcome and delegate approach selection. Do not force a discussion phase when existing evidence can resolve the remaining facts and reversible local choices. Return clear covered work to Workflow.
 
 Use [Decision Gate](../decision-gate/SKILL.md) for one known blocking user-owned choice or source conflict. Use [Diagnose Failure](../diagnose-failure/SKILL.md) when a reported or recurring failure needs a supported cause rather than broader option discussion.
 
 ## Separate Outcome From Approach
 
+Goal: know which understanding is missing, what or how, and establish only that.
+
 Identify which understanding is missing:
 
 - **What:** the problem or opportunity, desired result, accepted behavior, constraints, non-goals, and what would count as success.
@@ -30,12 +44,12 @@ Use [Design for Depth](../design-for-depth/SKILL.md) when representation, identi
 
 These questions can be answered together. Reuse what remains supported instead of running two compulsory discovery passes. A detailed request may settle what while leaving how open; an investigation may reveal that the initial problem description was wrong.
 
-Keep supported facts and explicit decisions distinct from hypotheses, proposed mechanisms, and unresolved choices. Do not turn an assistant recommendation into a requirement because it is repeated or recorded.
-
 When reopening discussion, name what changed and preserve unaffected understanding. A new local obstacle does not reopen the whole task.
 
 ## Gather Context To Answer A Question
 
+Goal: answer the question the discussion needs with the smallest observation that can answer it.
+
 Before inspecting the environment, identify the missing fact and how its answer could change the discussion. Check whether current evidence already supplies it.
 
 Use [Action Selection](../action-selection/SKILL.md) for uncertain or broad inspection. Prefer a focused source, caller, contract, or observation over a repository survey. Read more only when the result leaves a material question unresolved.
@@ -46,6 +60,8 @@ Stop gathering when sufficient evidence supports the next decision. Do not colle
 
 ## Collaborate And Recommend Proportionately
 
+Goal: the user gets your real judgment, with the tradeoffs that matter, and keeps the choices they own.
+
 Carry your share of the thinking:
 
 - explain what the evidence and intent imply;
@@ -55,12 +71,14 @@ Carry your share of the thinking:
 - recommend the best-supported direction and what would change it;
 - revise your position when evidence changes.
 
-Ask about priorities, behavior, constraints, and tradeoffs the user owns. Keep one consequential uncertainty in focus; do not conduct a questionnaire or manufacture alternatives for ordinary choices.
+Keep one consequential uncertainty in focus; do not conduct a questionnaire or manufacture alternatives for ordinary choices.
 
-Before recommending a new obligation, distinguish a requirement from a limitation of the current approach. Explain consequences in user terms: "requires changing and distributing a patched host," not merely "needs a provenance interface." Include a simpler in-scope alternative when one is supported. Do not weaken required behavior to make an approach look simpler.
+Before recommending a new obligation, distinguish a requirement from a limitation of the current approach. Explain consequences in user terms: "requires changing and distributing a patched host," not merely "needs a provenance interface." Include a simpler in-scope alternative when one is supported.
 
 ## Frame And Assess A Learning Action
 
+Goal: when evidence cannot settle a question, the smallest experiment that can settle it, and an honest reading of what it showed.
+
 Use an experiment or prototype when existing evidence cannot settle a material question and exercising behavior can distinguish the remaining answers. A separate prototype should isolate the uncertainty more safely or economically than changing production; unfamiliarity alone does not require one.
 
 If the work is an accepted useful outcome regardless of what it teaches, treat it as Delivery or Deepening rather than disguise implementation as Learning. Incidental learning does not change its authority or acceptance boundary.
@@ -80,29 +98,35 @@ Return the framed action to Workflow for authority and, when needed, [Track Work
 
 Assess returned evidence against the original question. Negative or inconclusive evidence is a valid result; one failed technique does not prove every alternative impossible. If a new prerequisite is reported, distinguish a limitation of the observer or chosen approach from a requirement of the intended outcome before recommending more work.
 
-Revise only the affected understanding. Preserve the consequence for the task, remaining uncertainty, and exploratory-artifact disposition when continuity matters. A successful demonstration is not production acceptance; promotion must be deliberately selected and its effects authorized. Stop assessment when the supported next direction or unresolved decision is clear.
+Revise only the affected understanding. Preserve the consequence for the task, remaining uncertainty, and exploratory-artifact disposition when continuity matters. Stop assessment when the supported next direction or unresolved decision is clear.
 
 ## Preserve A Useful Route When Needed
 
+Goal: when the likely work becomes clear, the route and the understanding behind it survive for whoever continues.
+
 When the likely work becomes clear enough, propose coherent outcomes and their dependencies. Keep near-term work concrete and later work directional. A rough route need not wait for a formal Plan; its order may change as evidence arrives.
 
 Ask whether losing the current understanding, decisions, evidence, proposals, or next action would risk misalignment. If not, keep it in conversation.
 
 If continuity matters, read [Discussion Continuity](references/discussion-continuity.md), then Track Work before record operations. Preserve the state that made memory necessary, not an empty shell or transcript. Keep the outcome separate from the current approach and retain material uncertainty instead of describing proposals as settled work.
 
+Once a record exists, use it as working memory during the discussion, updating it at meaningful boundaries: accepted choices, open questions, options still under consideration, material the user supplies, and the route as it emerges. Track Work describes how.
+
 ```text
 Discuss establishes supported meaning
 -> Track Work preserves material state
 -> Discuss continues or returns the direction to Workflow
 ```
 
-The record does not select work or grant authority. Propose independent review, a local commit, a user decision, or a continuity checkpoint only when it protects a material boundary; Workflow selects it.
+The record does not select work or grant authority. When the route includes a commit, a publication, a review, a user decision, or a planned handoff, propose it as a Checkpoint on the route rather than as a separate Slice; Workflow selects it.
 
 ## Converge And Return
 
+Goal: end the discussion when the next sound action no longer depends on it, and hand over only what that action needs.
+
 End the current discussion when the next sound action no longer depends on unresolved direction, or when a bounded learning action, missing user decision, wait, or stop is clear. Do not continue merely because more detail could be explored.
 
-When the user requests execution, return to Workflow to establish its outcome, scope, and user-facing return condition. If the user delegates the remaining investigation and implementation, do not require them to finish planning it.
+When the user requests execution, return to Workflow to establish its outcome, scope, and user-facing return condition. If the user delegates the remaining investigation and implementation, do not require them to finish planning it. Context gathered during discussion counts toward preparing the route; do not repeat it, and gather what the route still needs before the first production change.
 
 Return only what the next route needs: supported understanding, tentative approach, material open questions, relevant evidence, recommended or accepted next action, continuity, and authority state.
 
@@ -113,4 +137,4 @@ Return only what the next route needs: supported understanding, tentative approa
 - Unsupported failure cause -> Diagnose Failure.
 - No action needed -> answer or stop.
 
-Neither an artifact nor a planning milestone is mandatory. Stop recommending or preserving once the agreed discussion result is supported; do not begin implementation without the execution agreement.
+Neither an artifact nor a planning milestone is mandatory. Stop recommending or preserving once the agreed discussion result is supported.

package/skills/discuss/references/discussion-continuity.md

@@ -2,6 +2,8 @@
 
 Read this before preserving discussion across context loss, creating or updating durable task memory from discussion, or carrying a proposed or selected checkpoint beyond the current conversational context.
 
+This reference is judgment: adapt it to the discussion. Its binding statements restate [Discuss](../SKILL.md), Workflow, or Track Work Rules.
+
 Discussion state is not automatically a Working Record, Spec, Plan, checkpoint, or authority. Preserve the required outcome separately from the current approach, and distinguish the user's execution agreement from proposals that have not been selected.
 
 ## Keep It In Conversation When Possible
@@ -62,39 +64,17 @@ Preserve only supported state that could affect later interpretation or action.
 
 When the initial record need arises from discussion, preserve the state that justified the record in the first authorized atomic update. Do not create an empty shell and lose the decisions, proposals, or uncertainty that made continuity necessary.
 
-When a rough route is useful, preserve provisional Slices and their actual dependencies without pretending the later implementation is settled. Keep the current unit concrete and later work directional. Use the existing Current Context, Current Work, Future Work, and History fields; do not add a second phase or context-cycle ledger.
+When a rough route is useful, preserve provisional Slices, the Checkpoints between them, and their actual dependencies without pretending the later implementation is settled. Keep the current unit concrete and later work directional. Use the existing Current Context, Current Work, Future Work, and History fields; do not add a second phase or context-cycle ledger.
 
 Preserve the agreed outcome, scope, and user-facing return condition when losing them could interrupt covered work or permit drift. Authorization to investigate or propose a design is not acceptance of its production consequences. When learning changes the approach, retain the question, strongest evidence and limits, remaining uncertainty, artifact disposition, and affected later work—not the prototype's construction history.
 
 After preservation, return to Discuss unless Workflow established another route. Record mutation does not transfer ownership or authorize execution.
 
-## Carry Proposed And Selected Checkpoints
-
-A possible checkpoint remains proposed in the current discussion until Workflow selects it.
-
-For a proposed checkpoint, preserve only:
+## Carry Checkpoints On The Route
 
-```text
-Status: Proposed
-Type:
-Purpose:
-Boundary it could protect:
-Authority or selection still needed:
-```
-
-For a selected checkpoint, preserve:
-
-```text
-Status: Selected
-Type:
-Purpose:
-Due boundary:
-Condition:
-Selection source:
-Authority scope:
-```
+A commit, publication, review, user decision, or planned handoff that the discussion anticipates is a Checkpoint on the route, not a Slice. With a record, propose it in Future Work using Track Work's Checkpoint types and states: `proposed` while only anticipated, `pending` once Workflow selects it. Without a record, keep it in the conversation.
 
-Persist checkpoint state through Track Work only when durable memory is needed. Keep local commit authority separate from push or integration, and keep migration, release, and launch separately controlled.
+Keep local commit authority separate from push or publication, and keep migration, release, and launch separately controlled.
 
 ## Preserve Re-entry State
 
@@ -111,7 +91,7 @@ Authority or user decision needed:
 
 Do not restart from zero, rewrite unaffected decisions, or narrate completed work.
 
-After context loss, recover the complete record through Track Work's `full` view before relying on it. Compare current sections and relevant History with current user direction, accepted artifacts, and live evidence. Reconcile affected meaning and dependent future work; do not repeat a disproved approach or preserve a stale plan merely because the record contains it. With intact context, use `resume` or targeted reads only when needed.
+After context loss, recover through Track Work's recovery order before relying on the record: the complete record, its defining artifacts, then its Recovery sources. Compare current sections and relevant History with current user direction, accepted artifacts, and live evidence. Reconcile affected meaning and dependent future work; do not repeat a disproved approach or preserve a stale plan merely because the record contains it. With intact context, use `resume` or targeted reads only when needed.
 
 ## Stop