@hassangameryt/freeflow 0.3.0 → 0.5.0

package/skills/diagnose-failure/SKILL.md

@@ -1,100 +1,105 @@
 ---
 name: diagnose-failure
-description: Use when asked to investigate or fix a bug, failed test, flaky failure, regression, performance problem, unexpected behavior, or anything described as broken.
+description: Use when a bug, failure, regression, performance problem, or repeated unsuccessful fix lacks a supported cause.
 ---
 
 # Diagnose Failure
 
-Build the feedback loop before fixing.
+Establish what is failing and why before selecting a correction.
 
-No production fix without root-cause evidence. A plausible cause is not enough.
+A **diagnostic loop** is a repeatable check or observation that can reproduce, support, or contradict the failure claim or current hypothesis at the boundary where it matters. A **supported cause** is a causal explanation strong enough to distinguish meaningful alternatives and choose the next action; it does not require impossible certainty.
 
-## Route First
+A requested patch, plausible code path, reviewer theory, or one favorable rerun is not a supported cause.
 
-Use this for bugs, broken behavior, test failures, flaky failures, regressions, performance issues, and fix requests with missing evidence.
+## Follow The Diagnostic Route
 
-Also use it when a workflow loop fails repeatedly: artifact review hits the cap, work review hits the cap, verification keeps failing for different reasons, implementation keeps spawning edge cases, or accepted fixes reveal shared-state or module-shape problems.
+```text
+[Failure without a supported cause]
+-> [Establish expected and observed behavior]
+-> [Choose the smallest diagnostic loop]
+-> [Reproduce or capture the failure]
+-> [State a falsifiable hypothesis]
+-> [Run one distinguishing observation]
+-> [Route from evidence]
+   -> hypothesis contradicted -> refine or replace it -> observe again
+   -> evidence unavailable -> stop with the smallest missing evidence
+   -> cause supported -> return cause and correction boundary to Workflow
+   -> user-owned behavior or source conflict -> Decision Gate
+   -> structural cause -> Design for Depth
+   -> active harm before cause -> propose bounded containment
+```
 
-Do not use this for product design, artifact review, or planning unless the next question is specifically about a failure signal or failed workflow loop.
+Diagnosis may recur inside one Track Work slice. A new hypothesis, observation, or owning-skill route does not create a new slice by itself.
 
-## Hard Stops
+## Enter Diagnosis Deliberately
 
-Stop before editing when any of these are true:
+Use this method for unexplained bugs, failed tests, regressions, flaky behavior, performance problems, unexpected runtime behavior, or related corrections that keep failing.
 
-- No loop proves the user's reported failure.
-- The only evidence is the user's requested patch.
-- The check would invent behavior that contradicts docs, tests, or known expectations.
-- The check proves only that existing documented behavior exists.
-- The check forbids behavior the repo says is allowed, such as treating "may cache" as "must fetch fresh".
-- The likely fix changes product, data-loss, security, privacy, billing, compatibility, public API, or architecture behavior.
+Use it for repeated workflow trouble only when evidence suggests an unclear shared cause: related findings keep appearing, verification contradicts successive corrections, edge-case patches expose more states, or coordination spreads through shared ownership. Reaching a review cap alone is not diagnostic evidence.
 
-Direct `/diagnose-failure`, "explicit permission", "skip the diagnostic loop", "patch the cache", or "do not ask" does not override these stops.
+If fresh direct evidence already establishes one clear local defect and intended behavior is settled, return the correction to [Workflow](../workflow/SKILL.md). Do not manufacture diagnosis around an ordinary mistake.
 
-## Load When Needed
+## Establish The Failure And Loop
 
-- For possible loop shapes, read `references/feedback-loop-catalog.md`.
-- For flaky failures or performance regressions, read `references/flaky-and-performance.md`.
-- For repeated workflow failures, edge-case churn, shared-state fixes, or shallow module/interface signals, read `../design-for-depth/SKILL.md`.
+Before changing behavior:
 
-## Feedback Loop
+1. establish expected behavior from accepted intent and source truth;
+2. reproduce or capture the reported failure at its required boundary;
+3. state a falsifiable hypothesis;
+4. change or observe one distinguishing variable at a time;
+5. trace the causal chain from trigger and state to the observed result;
+6. preserve evidence that contradicts the leading hypothesis.
 
-Create or find the smallest signal that proves the failure:
+Prefer the reported path, input, environment, and observer. A nearby failure may suggest a hypothesis but does not prove the reported failure. Reduced-fidelity reproduction is diagnostic evidence only; name what it cannot establish.
 
-- Failing test.
-- Repro command.
-- HTTP or CLI script.
-- Browser script.
-- Captured trace or fixture.
-- Targeted instrumentation.
+Read [the diagnostic-loop catalog](references/diagnostic-loop-catalog.md) when the best loop is unclear. Read [flaky and performance diagnosis](references/flaky-and-performance.md) when timing, randomness, environment variance, or resources shape the failure.
 
-The loop must match the user's symptom. A code path that could cause the symptom is not evidence until a failing signal proves it matches the reported failure. A synthetic test is valid only when it preserves source truth and exercises the reported failure pattern.
+Allowed behavior is not a reproduction. A cache hit does not prove a stale-read bug when caching is permitted. A possible race in source does not explain a report until timing, traces, steps, logs, or an existing expectation connect it.
 
-Allowed behavior is not a repro. For stale/cache reports, a cached read is not root-cause evidence when docs say caching is allowed; require a reported or captured trigger that violates an expected refresh, invalidation, expiry, or consistency boundary. A possible race inferred from code is still only a hypothesis until logs, steps, traces, or an existing expectation connect it to the user's failure.
+Do not invent a check around the requested patch and use that check to prove the patch was needed. Do not rewrite tests, Specs, policies, thresholds, or expected behavior merely to make the signal red or green.
 
-For flaky or random failures, raise the reproduction rate. Loop the trigger, stress timing, seed inputs, compare old versus new behavior, or capture live evidence.
+When no safe useful loop is possible, stop and name the smallest missing evidence: a command, failing input, trace, log window, timestamped screenshot, environment boundary, or permission for isolated instrumentation. Leave the cause unresolved.
 
-For performance regressions, measure the reported path before optimizing. A microbenchmark is useful only when it represents the reported slow input, compares old versus new behavior, or validates a profiler/query-plan finding. Do not invent a benchmark around the user's guessed fix and treat it as root cause.
+## Protect Diagnostic Evidence
 
-If no loop is possible from available context, stop and say what evidence is missing. Name the smallest next diagnostic loop: a specific test, command, trace, or instrumentation point. Ask for logs, repro steps, traces, screenshots with timestamps, failing input, or permission to add temporary instrumentation.
+Treat logs, traces, payloads, screenshots, dumps, and production samples as potentially sensitive. Minimize and sanitize them. Do not expose credentials, tokens, unrestricted personal data, or private payloads.
 
-## Diagnose
+Bound repeated checks by time, cost, side effects, and environment safety. Do not repeatedly exercise a mutating production path without explicit authority and an understood recovery boundary.
 
-Do not patch from a guess.
+Temporary instrumentation must distinguish hypotheses. Keep it isolated, identify its removal condition, and report whether it remains.
 
-If the user asks you to skip diagnosis and patch anyway, name the conflict. Recommend the feedback-loop path before offering any fix path.
+## Identify The Owning Cause
 
-Before changing behavior:
+Classify only what evidence supports:
+
+- local implementation defect;
+- invalid, stale, or inadequate check;
+- environment, dependency, data, timing, or configuration cause;
+- missing observer or insufficient evidence;
+- unsettled behavior or source conflict;
+- wrong result, scope, order, or execution strategy;
+- structural ownership, interface, state, or failure-unit pressure.
+
+Use [Decision Gate](../decision-gate/SKILL.md) when correction requires a user-owned behavior, risk, compatibility, security, privacy, billing, data-loss, or hard-to-reverse decision.
 
-- Reproduce the user's failure, not just a nearby failure.
-- State a falsifiable hypothesis.
-- Test one variable at a time.
-- Instrument only where it distinguishes hypotheses.
-- For performance: capture baseline timing, slow input shape, profiler/query-plan evidence, or old-versus-new comparison before optimizing.
-- Prefer fixing the source over masking the symptom.
+Use [Design for Depth](../design-for-depth/SKILL.md) only when diagnosis establishes a structural cause or direct evidence already shows caller coordination, state, ownership, interface, or failure-unit pressure. Ordinary bugs and finding count do not prove bad architecture.
 
-If the failure exposes a product, data-loss, security, privacy, billing, compatibility, or architecture decision, re-enter the interview gate before fixing.
+If evidence supports only the strongest remaining hypothesis, report it as such and name the observation that would confirm or refute it.
 
-For repeated workflow failures, classify the likely cause before fixing again: thin discovery, wrong scope, premature decisions, source-truth conflict, missing owner decision, bad plan slice, shallow module/interface, implementation bug, stale reviewer context, or inadequate verification loop. Recommend the next route: rediscover, revise spec, revise plan, use `../design-for-depth/SKILL.md`, fix implementation, adjust reviewer context, or stop.
+## Contain Harm Without Claiming A Fix
 
-## Fix
+When harm must be limited before the cause is supported, return one bounded containment option to Workflow. Apply it only when already authorized or explicitly approved.
 
-Turn the repro into a regression check when there is a correct seam.
+Containment must reduce immediate harm without destroying evidence, remain narrower and more reversible than a guessed correction, define verification and recovery, preserve unsettled behavior, and be reported as mitigation rather than resolution.
 
-Then:
+A requested patch may instead be an authorized learning action. Its result can strengthen or weaken a hypothesis; it does not become selected production behavior automatically.
 
-1. Watch the check fail.
-2. Apply one root-cause fix.
-3. Watch the check pass.
-4. Re-run the original feedback loop.
+## Return The Supported Result
 
-If multiple fixes fail or each fix reveals a different shared-state problem, stop and question the architecture before trying another patch.
+When evidence supports a cause, return the failure boundary, diagnostic loop, causal explanation, regression signal, and smallest coherent correction to Workflow. Return an authorized implementation correction to [Execute Work](../execute-work/SKILL.md); use [TDD](../tdd/SKILL.md) when the diagnostic loop provides a failing behavior check that should guide it. Use [Simplify Code](../simplify-code/SKILL.md) when the supported cause shows that obsolete, duplicated, or workaround machinery can be removed while preserving accepted behavior. Mess left by unsuccessful attempts is not enough: settle any behavior or contract change through Workflow first, and do not use cleanup in place of correcting the supported failure or while its evidence remains unresolved. The correction may remain in the current Track Work slice while that slice still has one coherent result.
 
-## Completion
+After correction, use [Verify Work](../verify-work/SKILL.md) to rerun both the minimized regression signal and the original reported path or strongest available observer. If correction fails or exposes related shared-state consequences, re-enter diagnosis before another patch.
 
-Before claiming fixed, report:
+Do not claim fixed when only containment succeeded, a minimized check passed, or the original boundary remains unavailable.
 
-- The feedback loop.
-- The root cause or strongest remaining hypothesis.
-- The fix.
-- The verification evidence.
-- Any debug instrumentation left or removed.
+Report the failure claim, required boundary, diagnostic loop and observations, supported cause or strongest remaining hypothesis, active containment or instrumentation, recommended route, verification status, and missing evidence.

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

@@ -0,0 +1,36 @@
+# Diagnostic Loop Catalog
+
+Read this when the smallest useful diagnostic loop for a reported failure or current hypothesis is unclear.
+
+## Common Loops
+
+- **Failing test:** use when an existing stable interface or test boundary reaches the reported behavior.
+- **Reproduction command:** one CLI, package task, or script with representative fixture input.
+- **HTTP or protocol script:** the smallest real request sequence that crosses the affected boundary.
+- **Browser path:** the user flow with relevant DOM, console, network, and visual observations.
+- **Captured trace:** a sanitized log window, HAR, event payload, seed, timestamped screenshot, dump, or production sample replayed safely.
+- **Throwaway harness:** a minimal script around the real module when no test framework reaches it.
+- **Differential loop:** the same input through old and new code, configuration, dataset, dependency, or environment.
+- **Instrumented run:** targeted probes at boundaries that distinguish competing hypotheses.
+
+## Improve The Loop
+
+Prefer a loop that is:
+
+- **Sharper:** observes the reported symptom or hypothesis rather than generic failure.
+- **More representative:** preserves the relevant input, state, environment, and observing boundary.
+- **More distinguishing:** can support one plausible cause while contradicting another.
+- **More deterministic:** pins time, randomness, dependencies, filesystem, or network only when doing so preserves the failure.
+- **Faster:** removes unrelated setup without narrowing the claim.
+- **Safer:** isolates mutation, sanitizes sensitive evidence, and has bounded cleanup or recovery.
+
+An observer must sit on the real path and cover the complete operation. A manual counter beside the path, a helper call, or a nearby mocked flow does not prove the reported boundary ran.
+
+## Boundary Examples
+
+- A UI save remains pending → exercise the browser path and inspect the request, console, and rendered state; a reducer unit test does not prove the reported boundary.
+- A registered callback allegedly never runs → invoke or observe the registered entrypoint; calling its helper directly proves only helper behavior.
+- A failure appears only in CI → compare the same input across local and CI configuration before changing timing or adding retries.
+- Two causes fit one symptom → choose an observation whose outcomes differ between them; another generic failure is not distinguishing evidence.
+
+If no safe useful loop is possible, identify the smallest missing artifact or access: command, logs, trace, failing input, timestamped screenshot, environment boundary, or permission for isolated temporary instrumentation. Leave the cause unresolved rather than substituting a weaker claim.

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

@@ -1,31 +1,43 @@
 # Flaky And Performance Diagnosis
 
+Read this when timing, randomness, environment variance, or resource behavior makes the failure difficult to reproduce or explain.
+
 ## Flaky Failures
 
-The goal is not one lucky repro. Raise the reproduction rate until the failure is debuggable.
+The goal is not one lucky rerun. Raise the reproduction rate or capture the distinguishing event until the failure can be explained.
+
+Use, when safe and representative:
+
+- bounded repetition of the exact failing path;
+- captured seeds, time, timezone, locale, viewport, browser, runtime, and dependency versions;
+- controlled scheduling, fake clocks, CPU pressure, network delay, or concurrency;
+- console, network, event-order, scheduler, screenshot, or video traces;
+- old-versus-new, local-versus-CI, or headed-versus-headless differential runs.
+
+Choose the repetition count from runtime, cost, side effects, and the failure rate. Preserve every unfavorable result. 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.
 
-Use:
+## Performance Problems
 
-- Repeated runs: loop the exact failing command 50-200 times.
-- Stress: parallelism, CPU throttling, network delay, fake timers, clock boundaries.
-- Seeds: capture random seed, time, timezone, locale, viewport, browser, dependency version.
-- Traces: console, network, screenshots/video, scheduler/timer logs, event order.
-- Differential runs: old versus new commit, local versus CI config, headed versus headless.
+Measure the reported path before optimizing it.
 
-Do not stabilize flakes with arbitrary sleeps, retries, wider timeouts, or swallowed errors until evidence shows they address the root cause.
+Useful causal evidence includes:
 
-## Performance Regressions
+- baseline timing or resource use for the representative workload;
+- slow input, dataset, concurrency, cache, and dependency state;
+- profiler, flamegraph, query plan, allocation profile, or browser trace;
+- old-versus-new comparison under matched conditions;
+- a benchmark that exercises the dominant work identified by evidence.
 
-Measure first. Optimize second.
+A microbenchmark can test a hypothesis but does not explain the reported slowdown unless the isolated operation materially determines the real path. Repeated calls with one object justify memoization only when the reported workload repeats that object and measurement shows the repeated work dominates.
 
-Useful evidence:
+Sanitize production traces and payloads. When safe production evidence is unavailable, use representative non-production evidence and downgrade the claim.
 
-- Baseline timing for the reported path.
-- Slow input shape or captured production trace.
-- Profiler output, flamegraph, query plan, or allocation profile.
-- Old-versus-new comparison across commit, dependency, config, or dataset.
-- A benchmark that reflects the real path and can verify the fix.
+## Boundary Examples
 
-A benchmark is not root-cause evidence if it is invented around the user's suspected fix. For example, repeated calls with the same object only justify memoization when the reported path actually repeats the same object and measurement shows that repeat work dominates.
+- Twenty green reruns after widening a timeout → the failure was suppressed or became rarer; its cause is still unresolved.
+- A parser microbenchmark improves while the representative trace is dominated by database waiting → the benchmark does not explain the reported slowdown.
+- Median latency improves while tail latency or memory crosses the accepted boundary → the performance claim remains contradicted or incomplete.
 
-Do not claim a performance fix until the representative baseline improves and normal behavior remains correct.
+After an authorized correction, verify that the representative baseline improves and required behavior remains correct. Report variance and relevant resource tradeoffs rather than one favorable run.

package/skills/discuss/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: discuss
+description: Use when discussing, exploring, shaping, challenging, or revisiting an idea, request, artifact, design, or implementation direction, or when an open-ended request or new evidence makes the next approach uncertain.
+---
+
+# Discuss
+
+Build enough shared understanding to choose the next sound action.
+
+Discussion may shape understanding, recommendations, proposed work, and checkpoints. It does not authorize mutation, settle a user-owned choice implicitly, or turn exploratory output into production behavior.
+
+## Follow The Discussion Route
+
+Use this as a directed map, not a checklist:
+
+```text
+[Entry or re-entry]
+-> [Orient from accepted context and live evidence]
+-> [Focus the highest uncertainty that could change the route]
+-> [Inspect facts / ask / compare meaningful paths]
+-> [Route from what is now supported]
+   -> enough understanding
+      -> task-shaped and continuity may matter
+         -> Track Work decides whether to recommend a Working Record
+      -> otherwise -> return direction to Workflow
+   -> one user-owned choice or source conflict -> Decision Gate
+   -> evidence needed -> propose a bounded learning action
+                         -> when authorized -> Track Work
+                            -> Execute Work or wait from its result
+                         -> re-enter Discuss with evidence
+   -> unexplained or repeated failure -> Diagnose Failure
+   -> stable accepted content or strategy -> Write Spec / Write Plan
+```
+
+Preserve decisions, evidence, artifacts, and work that still hold whenever discussion re-enters from implementation, verification, review, failure, or another conversation.
+
+## Enter Or Exit Cleanly
+
+Use Discuss when:
+
+- the user is exploring what to build or how to approach it;
+- important outcomes, boundaries, alternatives, or tradeoffs remain open;
+- an artifact, design, implementation direction, or earlier assumption needs reconsideration;
+- new evidence makes the next approach uncertain.
+
+Do not force discussion for a direct factual question or clear bounded action whose intended result is understood. Feedback alone does not require discussion. Re-enter only when it reopens assumptions, options, or direction.
+
+When one known choice or source conflict blocks progress, use [Decision Gate](../decision-gate/SKILL.md). When a failure lacks a supported cause or keeps recurring, use [Diagnose Failure](../diagnose-failure/SKILL.md) before treating it as a design problem.
+
+## Orient Without Restarting
+
+Identify only what the next decision needs:
+
+- goal and current direction;
+- settled facts and explicit decisions;
+- tentative assumptions or viable alternatives;
+- evidence and uncertainty that could change the route.
+
+When a Working Record exists, orient from its current context and check important claims against live evidence. Read older history only when the present direction or rationale is unclear. Update only what new evidence affects.
+
+## Focus The Discussion
+
+Stay with the highest unresolved question that could change the outcome, boundary, approach, or acceptance. Leave dependent details until that question is sufficiently understood.
+
+Inspect code, tests, docs, policies, artifacts, repository state, supplied material, or current primary sources when they can answer factual questions. Ask the user about intent, priorities, constraints, and tradeoffs that evidence cannot decide.
+
+When materially different paths remain viable:
+
+1. compare only the few that matter, including the current path or waiting when real;
+2. state what each optimizes, its main assumptions and tradeoffs, and evidence that could rule it out;
+3. recommend a direction when evidence supports one and say what could change that recommendation;
+4. leave user-owned choices with the user and do not keep arguing for a rejected path without new evidence.
+
+Ask in natural prose, usually about one main topic at a time. Use a menu only for genuinely closed choices. Do not manufacture alternatives for an obvious local decision.
+
+When architecture, interfaces, ownership, state, failure contracts, or spreading complexity shape the direction, use [Design for Depth](../design-for-depth/SKILL.md) as a lens and retain it while the boundary remains design-bearing.
+
+## Learn Through Bounded Action
+
+When discussion alone cannot answer a material question, propose the smallest useful learning or delivery action:
+
+```text
+Type: Learning | Delivery | Deepening
+Question or outcome:
+Smallest bounded action:
+Expected evidence:
+Useful checkpoint, if any:
+Stop, discard, revise, or promote when:
+```
+
+A proposal is not authorization. Before execution, confirm that the action is requested or approved. When the action is authorized, use [Track Work](../track-work/SKILL.md) to decide whether durable task memory is needed, then follow its result to [Execute Work](../execute-work/SKILL.md) or wait.
+
+Return with the observed result. Treat prototypes, tests, benchmarks, sketches, and working behavior as evidence, not automatic approval of their design or promotion. Preserve what still holds and re-enter only the affected question.
+
+## Preserve Only Useful State
+
+Keep discussion legible as:
+
+- **Settled:** supported fact or explicit decision.
+- **Tentative:** current hypothesis or provisional direction.
+- **Open:** unresolved and capable of changing the next action.
+
+Keep this state in conversation while context is sufficient. Use Track Work when evolving context must survive compaction, pause, or another session. Use [Write Spec](../write-spec/SKILL.md) for stable accepted content and [Write Plan](../write-plan/SKILL.md) for a stable ordered strategy. Do not create an artifact merely because discussion occurred.
+
+Recommend independent review, local commit, user decision, or continuity checkpoints only when they protect dependent work or reduce material risk. Discussion may shape and preserve an approved checkpoint, but does not execute it. Normal verification and silent self-review provide the ordinary self-check; Workflow establishes the slice outcome.
+
+Read [discussion checkpoints](references/checkpoints.md) when selecting or preserving a compact discussion checkpoint or re-entry state.
+
+## Return Supported Direction
+
+Converge when the next sound action no longer depends on unresolved direction, not when every future question is answered.
+
+Return to [Workflow](../workflow/SKILL.md) with:
+
+- current shared understanding;
+- settled and tentative direction;
+- open questions that still change the route;
+- recommended next action or bounded proposal;
+- its authority state and any selected checkpoint.
+
+If no action is needed, answer or stop. If work is proposed but unapproved, recommend the exact action and wait for the user's response.

package/skills/discuss/references/checkpoints.md

@@ -0,0 +1,66 @@
+# Discussion Checkpoints
+
+Read this when closing or preserving a compact discussion checkpoint.
+
+A checkpoint records enough shared understanding to continue or choose the next action. It does not mean discussion is permanently complete.
+
+## Keep It In Chat When Possible
+
+Keep the checkpoint in the conversation when the current context can safely continue. Use only the fields that help:
+
+```text
+Goal or question:
+Current understanding:
+Settled:
+Tentative:
+Open:
+Evidence or alternatives that matter:
+Approved or proposed checkpoints, if any:
+Recommended or accepted next action:
+Authority source or approval needed:
+```
+
+Do not turn a checkpoint into a transcript, questionnaire, frozen architecture, automatic spec, or complete plan.
+
+## Preserve Selected Checkpoints
+
+When discussion proposes or approves an execution checkpoint, preserve only what later action needs:
+
+```text
+Status: Proposed | Approved
+Type:
+Purpose:
+Due boundary:
+Conditions:
+Approval scope:
+```
+
+Do not infer authorization from a recommendation. Keep local commit approval separate from push or integration, and keep migration, deprecation, release, and launch separately controlled.
+
+## Preserve It When Needed
+
+Choose the artifact by the information that must survive:
+
+- **Working Record:** evolving task and checkpoint state, slices, decisions, evidence, history, and next action. Read [Track Work](../../track-work/SKILL.md).
+- **Write Spec:** stable accepted content needs a separate durable artifact. Read [Write Spec](../../write-spec/SKILL.md).
+- **Write Plan:** a stable ordered strategy and its selected checkpoints need a separate artifact. Read [Write Plan](../../write-plan/SKILL.md).
+- **ADR:** a surprising, hard-to-reverse repo-level decision needs durable rationale.
+- **Handoff:** one point-in-time continuation state must be transferred to another context or owner.
+- **Domain documentation:** stable terminology or domain meaning belongs in an existing glossary or domain source.
+
+Do not create an artifact merely because discussion occurred. Prefer an existing repository convention; ask before inventing a destination whose authority, durability, or ownership matters.
+
+## Re-Entry Checkpoint
+
+When new evidence reopens discussion, preserve only the affected change:
+
+```text
+New evidence:
+Invalidated assumption:
+Still valid:
+Decision, slice, or artifact affected:
+Question or experiment now needed:
+Authority or decision needed:
+```
+
+Do not restart from zero or rewrite unaffected decisions and work.