@hassangameryt/freeflow 0.7.1 → 0.7.2

package/skills/verify-work/SKILL.md

@@ -1,105 +1,100 @@
 ---
 name: verify-work
-description: Use when verifying work or a claim after implementation, tests, builds, runtime checks, failures, conflicting evidence, or incomplete evidence.
+description: "Use when verifying work or a claim after implementation, tests, builds, runtime checks, failures, conflicting evidence, or incomplete evidence."
 ---
 
 # Verify Work
 
-Determine whether fresh evidence supports a specific claim at the required observing boundary.
+Determine what fresh direct evidence establishes about a specific claim at the boundary where it must hold.
 
-Verification is factual: what ran, what happened, and what that result proves. The active agent owns verification and routes from its result. Reading or invoking this skill changes neither role nor authority and creates no review judgment or permission to continue.
+Verification establishes facts, not review judgment, authority, or permission to continue. A passing command is not automatically a supported outcome. Test order is not evidence of test validity or implementation correctness.
 
-## Name The Claim
+## Establish The Claim And Its Source
 
-State the claim before choosing the check. Include the behavior or property and the boundary where it must hold. Keep this compact when both are obvious; do not let an available check silently narrow a broader claim.
+Before choosing a check, identify the behavior or property, the required observing boundary, and the source of its expectation. Keep this compact when obvious; do not let an available test silently narrow a broader claim.
 
-Claims may concern:
+Claims may concern behavior, a reported failure, structural validity, interfaces, integration, host lifecycle, installed artifacts, failure or recovery semantics, performance, or repository state.
 
-- observable behavior or a reported failure;
-- build, type, lint, format, schema, or structural validity;
-- public interfaces, integration, host lifecycle, or installed artifacts;
-- failure, retry, recovery, degradation, or fail-closed behavior;
-- performance or resource bounds;
-- artifact completeness or repository state.
+Distinguish required acceptance from an optional stronger assertion. If evidence for an optional claim is unavailable, qualify or withdraw that claim rather than automatically add implementation. A required guarantee remains unresolved until supported or explicitly changed by its owner.
 
-## Choose Evidence That Can Disagree
+When expected behavior is unsettled or sources conflict, return the issue through [Workflow](../../skills/workflow/SKILL.md) or [Decision Gate](../../skills/decision-gate/SKILL.md). Do not encode a guess as an expected result.
 
-Use the smallest direct evidence that can falsify the claim. Evidence must be fresh for the code, configuration, environment, and artifact being assessed.
+## Choose Sufficient Evidence
 
-Verification inherits the current authority envelope. Existing evidence may be inspected without a new run. Run a new active check only when that envelope covers it directly or as contained verification; otherwise return its purpose, expected evidence, and stop condition to [Workflow](../../skills/workflow/SKILL.md) and wait.
+Use the smallest direct observation that can disagree with the claim. Before relying on an unfamiliar fixture for substantial dependent work, establish that it reaches the required observing stage and distinguishes the relevant wrong behavior. Reuse an adequate existing fixture; observer preparation is not a mandatory separate prototype.
 
-Verify Work owns the claim and required evidence boundary. When several covered observers can falsify the same claim, or the likely check is broad, use [Action Selection](../../skills/action-selection/SKILL.md) to choose and bound one environment interaction. It returns the observation; Verify Work interprets and classifies support. Skip it when one exact check is already selected.
+For saved evidence, identify what code/artifact, check, configuration, and environment it examined, using existing outputs and source identities where available. Compare relevant subsequent changes, including new files and generated output. HEAD alone does not identify an uncommitted candidate. Reuse results whose applicability remains supported; rerun only affected evidence when authorized. Do not repeat checks merely because another activity or context began.
 
-Before running covered checks concurrently, compare what each may write or remove. Run checks serially when they share generated directories, caches, build outputs, package roots, fixture state, ports, databases, or intentional stale-artifact files. A concurrency-induced red signal is orchestration evidence, not automatically an implementation defect; reproduce it under a non-overlapping or serial schedule before changing production code.
+Keep two facts separate: the observation occurred, and it applies to the current state. A later edit does not erase an earlier pass; uncertain applicability does not certify the new candidate. Report missing identity or output rather than inventing a receipt or building a new evidence store.
 
-Passing tests do not prove behavior they do not exercise. A happy path does not prove failure handling. Source inspection does not prove runtime execution. A helper call does not prove registration, host dispatch, or installed-package behavior.
+Run active checks only when covered by the current agreement, including contained verification. Otherwise return the purpose, observer, expected evidence, and stop condition to Workflow and wait. A test, reproduction, benchmark, or instrumentation is active evidence generation even before production edits.
 
-Before selecting or running evidence:
+Use [Action Selection](../../skills/action-selection/SKILL.md) when several observers are plausible or the likely interaction is broad. It selects and bounds the interaction; Verify Work retains the claim and interprets support. An already-selected focused check needs no extra tool-selection ceremony.
 
-- read [integration evidence](references/integration-evidence.md) when a claim depends on a registered callback or executor, host lifecycle, producer invocation, fallback protocol, installed package, or absence counter;
-- read [browser runtime evidence](references/browser-runtime-evidence.md) when a claim depends on rendered UI, browser behavior, accessibility, client networking, console state, visual output, or browser runtime performance;
-- read [performance evidence](references/performance-evidence.md) when verifying latency, throughput, memory, CPU, bundle, query, rendering, capacity, or resource-regression claims.
+Read the relevant reference before designing or selecting evidence:
 
-For browser-performance claims, read both Browser Runtime Evidence for runtime fidelity and Performance Evidence for workload, baseline, variance, and metrics.
+- [Test Design](references/test-design.md) before designing or materially changing a behavior check, including regression or characterization coverage.
+- [Integration Evidence](references/integration-evidence.md) when a claim depends on a registered callback or executor, host lifecycle, producer invocation, fallback protocol, installed package, or absence counter.
+- [Browser Runtime Evidence](references/browser-runtime-evidence.md) for rendered UI, browser behavior, accessibility, networking, console state, visual output, or browser runtime performance.
+- [Performance Evidence](references/performance-evidence.md) for latency, throughput, memory, CPU, bundle, query, rendering, capacity, or resource-regression claims.
 
-Review may judge whether evidence is sufficient, but review does not prove that behavior occurred.
+Browser-performance claims need both browser fidelity and performance methodology. Loading a reference does not expand the required claim.
 
-## Run And Interpret
+Passing tests do not prove behavior they do not exercise. Source inspection does not prove runtime execution; a helper call does not prove registration, native dispatch, or installed-package behavior. A happy path does not establish failure handling.
 
-Once the selected check is authorized:
+## Run Without Manufacturing A Signal
 
-1. Run the complete selected check.
-2. Read the relevant output, exit status, and lower-level evidence that can contradict a summary.
-3. Confirm the defined assertion and intended success or failure path were exercised.
-4. Confirm the observing boundary actually matched the claim.
-5. Compare the observation with the exact claim and source requirement.
-6. Preserve contradictory evidence; do not rerun until an unfavorable result disappears.
-7. State unavailable, stale, partial, or reduced-fidelity evidence honestly.
+Before parallel checks, compare what each may write or remove. Serialize checks that share generated directories, caches, outputs, package roots, fixture state, ports, databases, or intentionally stale artifacts. Reproduce a concurrency-induced failure under a non-overlapping schedule before attributing it to production code.
 
-Do not convert missing evidence into zero, safe, passed, or probably correct. If the user skips a check, respect that choice and leave the corresponding claim unverified.
+For each covered check:
 
-Do not change implementation, tests, checks, Specs, policies, or acceptance merely to make the signal green. When the cause of a contradiction is unclear, report the contradiction rather than inventing one.
+1. Run the complete selected observation.
+2. Inspect output, exit status, assertions, and lower-level evidence that could contradict its summary.
+3. Confirm that the intended path ran and the observer matched the claim.
+4. Compare the observation with the independent expectation and its source.
+5. Preserve failures, contradictions, and partial or reduced-fidelity results.
 
-## Classify The Result
+Do not rerun until unfavorable evidence disappears or change valid tests, implementation, Specs, policy, or acceptance merely to make a signal green. Before revising a material assertion after failure, use Test Design to compare what the old and new checks establish. Repair source-backed observer or expectation errors; a weaker replacement leaves the original claim Inconclusive unless other evidence establishes it. Expose that limitation before acceptance rather than carry the stronger claim into the report.
 
-Keep check execution separate from claim support.
+Tests may be written before or after implementation as the task warrants. No formal test-first sequence is required. If using a failure to support diagnosis or regression claims, actually observe it at the relevant boundary; do not invent an earlier failing run from a later passing test.
 
-**Check result** is relative to the check's defined assertion—not whether the target operation happened to succeed or fail:
+## Classify Execution And Support Separately
 
-- **Passed:** the check executed validly and its defined assertion held.
-- **Failed:** the check executed validly and its defined assertion did not hold.
-- **Error:** the observing mechanism or check execution was invalid.
-- **Unavailable:** the required check could not be attempted safely or reliably.
+**Check result** describes the selected check's defined assertion:
 
-A check can Pass while intentionally observing rejection, failure, rollback, or fail-closed behavior.
+- **Passed:** it executed validly and the assertion held.
+- **Failed:** it executed validly and the assertion did not hold.
+- **Error:** the observing mechanism or execution was invalid.
+- **Unavailable:** the check could not be attempted safely or reliably.
 
-**Claim result:**
+A check may Pass by observing an expected rejection or failure.
 
-- **Supported:** direct fresh evidence establishes the claim at its stated boundary.
+**Claim result** describes what the evidence establishes:
+
+- **Supported:** direct fresh evidence establishes the claim at its required boundary.
 - **Contradicted:** evidence shows the claim is false.
-- **Inconclusive:** evidence exists but cannot establish or refute the claim at the required boundary.
-- **Unavailable:** the required evidence cannot currently be obtained safely or reliably.
+- **Inconclusive:** available evidence cannot establish or refute it at that boundary.
+- **Unavailable:** required evidence cannot currently be obtained safely or reliably.
 
-A Passed check may still leave the claim Inconclusive. A Failed check may expose an implementation defect, an invalid expectation, an environment problem, or a source conflict; classify only what evidence supports.
+A Passed check can leave the claim Inconclusive. A Failed check can expose a defect, invalid expectation, environment problem, or source conflict. Classify only the supported conclusion. Missing evidence is not zero, safe, passed, or probably correct.
 
-When contradictory evidence is unexplained or failure repeats, read [Diagnose Failure](../../skills/diagnose-failure/SKILL.md). When evidence exposes a user-owned decision or source conflict, read [Decision Gate](../../skills/decision-gate/SKILL.md).
+If the user skips a check, respect that choice and leave the corresponding claim unverified. Use [Diagnose Failure](../../skills/diagnose-failure/SKILL.md) when contradictions are unexplained or failure repeats.
 
-## Return Evidence To Review
+## Return Evidence To Its Owner
 
-When verification answers a review **Needs evidence** item, preserve the original review-item pointer, claim, required observing boundary, available evidence and prior limit, and why the gap affects review judgment.
+Return the observation and its limits to the activity using the claim. Base the report on actual assertions, outputs, and the state examined—not test names or the requested work phrased as accomplishments. Distinguish implemented behavior, exercised checks, and supported claims; list missing material cases even when the suite passes. Supported verification permits judgment of the result; it does not itself establish review Pass, close a Slice, or authorize delivery.
 
-Return the verification result to the receiving agent for adjudication:
+When answering a review Needs evidence item, preserve its pointer, claim, required observing boundary, previous evidence limit, and why the gap mattered. Return the result to the receiving agent for adjudication:
 
-- **Supported:** the factual gap may be resolved; do not infer review Pass.
-- **Contradicted:** the finding may be established, invalidated, or expose a source conflict; do not classify the review item here.
-- **Inconclusive:** the review item remains Open when the gap is material.
-- **Unavailable:** the review item remains Open and the observing limitation must remain explicit.
+- Supported may settle the factual gap without settling the review.
+- Contradicted may establish or invalidate a finding or expose a source conflict.
+- Inconclusive or Unavailable leaves a material gap open.
 
-Verification does not revise the independent review report, adjudicate findings, authorize correction, or select follow-up review.
+Do not revise the independent report, adjudicate its findings, authorize correction, or select another review from verification.
 
-## Report Proportionately
+## Report And Stop
 
-For one straightforward Supported claim with an obvious check and boundary, use the compact form:
+For one straightforward Supported claim, report briefly:
 
 ```text
 Claim @ required boundary: Supported ([check result]) by [evidence].
@@ -107,9 +102,10 @@ Proves:
 Does not prove:
 ```
 
-Use the full form when the result is Contradicted, Inconclusive, or Unavailable; several claims or boundaries are involved; evidence conflicts; the claim is consequential; or the result returns to review adjudication:
+Use fuller reporting when evidence is adverse, conflicting, consequential, multi-boundary, or returning to adjudication:
 
 ```text
+Review item: [when applicable]
 Claim:
 Required boundary:
 Evidence:
@@ -117,7 +113,7 @@ Check result:
 Claim result:
 Proves:
 Does not prove:
-Required next evidence:
+Required next evidence: [only when unresolved]
 ```
 
-When returning evidence for adjudication, prepend `Review item:` with the original item pointer. Omit `Required next evidence` when the claim is fully Supported or Contradicted. When the result changes or ends the current path, return it to [Workflow](../../skills/workflow/SKILL.md) to choose what follows.
+Do not manufacture empty fields or proof beyond the observation. When the result changes the work's direction or reaches its boundary, return to Workflow. Stop once the claim is classified and the supported next route or missing evidence is explicit.

package/skills/verify-work/references/integration-evidence.md

@@ -15,6 +15,8 @@ Evidence proves only the boundary it directly observes.
 
 Name the strongest level actually observed. Do not collapse source inspection, helper execution, registered entrypoint invocation, fallback replay, native dispatch, and installed execution into one "integration passed" claim.
 
+Before substantial work depends on an unfamiliar fixture, establish its actual entrypoint, observing stage, and how it captures the required result. A fixture named "integration" is not evidence of native dispatch. Keep a useful lower-boundary check, but do not substitute it for the required observer. Return an unavailable observer as a limitation rather than redesign production to suit the fixture.
+
 ## Observe Real Work
 
 A counter, trace, spy, or event proves execution only when it observes inside or wraps the actual invoked boundary. Manually updating evidence beside test setup proves only that the test updated it.
@@ -26,7 +28,7 @@ A zero value proves absence only when:
 - the observation window covered the complete operation;
 - failure did not bypass or disable observation.
 
-Prefer an adversarial disproof: bypass the producer, forge or replay the event, call the helper directly, or resolve code from the checkout instead of the installed root. The proof should fail before downstream work when the claimed boundary was not crossed.
+Identify a relevant adversarial disproof: bypass the producer, replay an event, call the helper directly, or resolve checkout code instead of the installed root. When inspection cannot establish the observer's sensitivity, exercise one such counterexample within covered effects; the intended assertion must detect the missing boundary, not merely fail in setup. No universal fault-injection matrix is required.
 
 ## Claim Map
 
@@ -42,4 +44,4 @@ Proves:
 Does not prove:
 ```
 
-Downgrade or split the claim when one mechanism cannot observe every asserted boundary.
+Qualify or split the reported claim when one mechanism cannot observe every asserted boundary. Required acceptance remains unresolved; do not silently downgrade it or treat another green lower-boundary run as its resolution.

package/skills/verify-work/references/test-design.md

@@ -0,0 +1,89 @@
+# Test Design
+
+Read this before designing or materially changing a behavior check, including regression or characterization coverage.
+
+Choose a real observing boundary and an independent expected result. This guidance does not prescribe test-first sequencing, a fixed unit/integration/end-to-end ratio, or a test-count target.
+
+## Start From Accepted Behavior
+
+Name the caller-visible result, its governing source, and the behavior a wrong implementation would exhibit. Do not derive requirements from the code or preserve accidental machinery because it already has tests.
+
+Expected results should come from accepted source truth, a worked example, a protocol contract, or an independently calculated value. Do not compute the expected value with the same algorithm being tested; that creates agreement by construction.
+
+For a consequential or repeatedly misunderstood property, make the distinction concrete: required behavior, one relevant wrong behavior, and the observation that separates them. Ask whether that wrong implementation could still pass; if so, strengthen the seam or assertion.
+
+When sensitivity remains uncertain, exercise one relevant counterexample or temporary isolated defect only within covered effects. Confirm the intended assertion detects the behavioral mistake; a compilation error or fixture crash proves no such sensitivity. Restore or discard the temporary change and check the actual candidate. Adequate inspection needs no extra run, and ordinary tests need no mandatory mutation-testing cycle.
+
+## Choose The Confidence Boundary
+
+Start from the highest stable interface used by callers, then choose the smallest environment that still exercises the required behavior and failure path:
+
+- **Focused behavior test:** deterministic logic or one stable public operation.
+- **Integration test:** collaborating components, persistence, serialization, process boundaries, or a real adapter contract.
+- **End-to-end or user-path check:** an assembled flow whose value depends on the system working together.
+- **Characterization:** observed existing behavior that must remain unchanged during a selected refactor.
+
+Characterization records what exists, not what should exist. Protect only accepted behavior or behavior required to remain stable for the selected transformation. Return conflicting or undefined expectations before fossilizing them as tests.
+
+A smaller environment is not better when it mocks away the claim. A larger one is not better when extra machinery adds noise without proving more.
+
+Prefer state, outputs, errors, persisted effects, and caller-visible behavior. Assert an internal interaction only when that interaction is itself contractual or the real effect cannot be observed safely. Keep one behavior concept per test; multiple assertions may describe one complete outcome.
+
+## Preserve The Property When Revising A Check
+
+When changing a material assertion or observer after failure, compare the old and new behavioral predicates: what could each accept incorrectly? Correct a wrong expectation from its governing source or repair the observer while preserving the required property. Explain a material change where the result is assessed; do not narrate routine assertion edits.
+
+Exact position equality replaced by a non-negative-number check loses exactness. Inspecting a registration object instead of the next native request changes the observing boundary. Neither is an equivalent fixture repair.
+
+If the replacement establishes less, leave the original claim unresolved unless other adequate evidence still establishes it at the required boundary. Return any remaining evidence limitation before acceptance. Under delegation, return it to the directing participant; changing user-owned acceptance still requires the user's decision. Do not freeze a demonstrably wrong test, or weaken a correct property because it is difficult to observe.
+
+## Check Required Failures And Forbidden Effects
+
+For accepted rejection, persistence, authorization, retry, cancellation, or recovery behavior, identify the dimensions that materially change the result:
+
+```text
+entry point
+× valid or invalid input
+× empty or existing accepted state
+× pre-commit or post-commit failure
+× first call or retry/replay
+```
+
+Select only rows that can disprove the required contract. Do not expand a matrix for hypothetical completeness. For the relevant rows, check returned results, allowed and forbidden effects, prior-state preservation, and required diagnostic or recovery evidence.
+
+When accepted conditions can coincide and interact materially, check their composition rather than assuming isolated tests commute. For example, an invalid replacement must not destroy prior accepted state merely because the rejection return value is correct.
+
+Undefined consequential failure behavior is a decision to resolve, not a test expectation to invent.
+
+## Use Faithful Dependencies
+
+Prefer, where practical:
+
+1. the real implementation when safe, controllable, and sufficiently deterministic;
+2. a lightweight fake preserving the relevant contract;
+3. a stub supplying fixed data needed to reach the path;
+4. a mock or spy when the interaction itself matters.
+
+Before replacing a dependency, identify the behavior and effects it owns, which the claim depends on, and how the double preserves them. Replace the slow, external, destructive, privileged, or nondeterministic boundary—not the higher-level behavior the test claims to prove.
+
+External APIs, email/payment delivery, uncontrollable time or randomness, destructive infrastructure, and unavailable remote services can justify doubles. A real filesystem or database may be simpler and more faithful than imitating it.
+
+Preserve relevant fields, invariants, errors, and downstream effects. Check a double against an existing schema, recorded contract, or shared contract tests when drift could produce false confidence. Do not build a second production implementation inside the fixture.
+
+Keep fixture construction and cleanup in test utilities. Do not add public production methods, flags, branches, or lifecycle operations used only by tests.
+
+## Control Time And Concurrency Honestly
+
+Prefer existing seams for clocks, randomness, scheduling, and external events. Do not expose new public test hooks merely for convenient assertions.
+
+Use observable synchronization, deterministic inputs, bounded eventual assertions, or the real diagnostic loop instead of arbitrary sleeps as proof. When timing or flakiness remains unexplained, use [Diagnose Failure](../../diagnose-failure/SKILL.md) before selecting a production correction.
+
+Test order does not establish correctness. A test written after code can be valid; an earlier test can still exercise the wrong path. Preserve evidence of which observations actually ran and never claim an unobserved earlier failure.
+
+## Question Test Machinery Before Expanding It
+
+Reconsider the seam when setup becomes more conditional than the behavior, doubles reproduce internal orchestration, private states must be exposed, or integration fails despite isolated tests passing.
+
+A real integration check may be simpler than many mocks. When direct evidence shows caller coordination or unclear ownership, use [Design for Depth](../../design-for-depth/SKILL.md) to assess that boundary. Do not redesign production solely to satisfy a test framework or retain machinery that only its tests require.
+
+Stop designing checks when the required behavior has an adequate independent observer. More green tests do not justify broader requirements or stronger completion claims.

package/skills/workflow/SKILL.md

@@ -1,173 +1,127 @@
 ---
 name: "workflow"
-description: "Use when authority, current ownership, route changes, continuity, selected checkpoints, or Supported Exit must be coordinated across Freeflow activities."
+description: "Use when authority, current ownership, readiness to act, route changes, continuity, selected checkpoints, or Supported Exit must be coordinated across Freeflow activities."
 ---
 
 # Workflow
 
-Own the outer Interaction Lifecycle. Interpret and enforce authority, keep one current owner for each bounded activity, route only when evidence changes responsibility, select checkpoints deliberately, and determine when a Supported Exit is justified.
+Own the outer Interaction Lifecycle. Establish what work is agreed, keep one current owner, require enough understanding for the next action, and continue or return at the agreed boundary.
 
-Workflow does not create authority or supervise every action. It coordinates owners and methods without replacing their detailed jobs.
+Workflow coordinates the agent's work; it does not supervise every tool call or require the user to plan the implementation. Skills, artifacts, evidence, and compute profiles never create authority or change ownership merely by being selected.
 
-Selecting a skill, method, lens, tool, artifact, review, checkpoint, domain guide, or compute profile never widens authority or changes the current owner automatically.
+## Establish The Work Agreement
 
-## Enter Through Authority
+Interpret the whole turn through the Interaction Contract. Distinguish discussion from a request to act.
 
-Interpret the whole user turn, current runtime state, and still-valid prior approval before consequential action.
+- For discussion or a question, collaborate and inspect relevant existing evidence as needed. Do not turn shared understanding into implementation authority.
+- For execution, establish the intended outcome, permitted scope, and user-facing return condition. The agreement may cover a plan, one correction, one Slice, or a whole task.
+- If the request already establishes those boundaries, acknowledge them briefly and proceed. Otherwise ask only the missing material question and wait before the unsettled execution.
 
-Classify effects cumulatively when one activity contains more than one kind, using the Shared Terms definitions for passive observation, active evidence generation, and mutation or delivery.
+For example, after discussing several possible Slices, an ambiguous "proceed" may need: "Implement the next Slice and return, or finish the described task?" Do not ask this when the user already requested the whole task with a clear endpoint.
 
-A direct request authorizes its bounded outcome and entailed tools, checks, and reversible local choices. It does not authorize unrelated cleanup, another outcome, a separately controlled effect, or an action whose consequence could materially change the user’s choice.
+The agreement may authorize investigation and approach selection as part of accomplishing the result. It need not prescribe files, tools, or implementation details. Keep it in conversation unless continuity requires task memory; it is not a mandatory artifact or separate autonomy mode.
 
-A Spec, Plan, Working Record, Handoff, review, recommendation, checkpoint, useful evidence, or silence may constrain or preserve work. None creates authority.
+Interpret authority from the request and still-valid approval. A direct request covers its bounded outcome and entailed tools, checks, and reversible local choices. Classify passive observation, active evidence generation, and mutation or delivery cumulatively. Planning an experiment does not make its effects passive.
 
-Before active evidence generation, mutation, delivery, or another separately controlled action not covered by current authority, tell the user why it is needed, exactly what will happen, what evidence or result it should produce, and where it will stop. Ask one direct authorization question and wait. Do not perform the proposed action or dependent work while waiting.
+Before an uncovered effect, explain its purpose, exact action, expected result, and stop condition; ask once and wait. Specs, Plans, Working Records, reviews, proposals, and useful evidence may constrain work but cannot authorize it.
 
-When authority, accepted intent, or the effect boundary is unclear, resolve that boundary before selecting an execution owner.
+## Establish Readiness For The Next Result
 
-## Choose And Keep One Current Owner
-
-Choose the narrowest discoverable owner whose job matches the current bounded activity. The categories below are common owners, not an exhaustive list.
-
-### Understand or decide
-
-- [Discuss](../discuss/SKILL.md) for materially open direction, alternatives, assumptions, or tradeoffs.
-- [Decision Gate](../decision-gate/SKILL.md) for one blocking user-owned choice or source conflict.
-
-Use [Design for Depth](../design-for-depth/SKILL.md) as a lens when direction is design-bearing. A lens does not become the current owner.
-
-### Produce, preserve, or judge durable state
-
-- [Track Work](../track-work/SKILL.md) for Working Record creation, recovery, reconciliation, and lifecycle.
-- [Write Spec](../write-spec/SKILL.md) for stable accepted content or contracts.
-- [Write Plan](../write-plan/SKILL.md) for stable ordered execution strategy.
-- [Review Artifact](../review-artifact/SKILL.md) for judgment of a durable guiding artifact.
-
-### Execute, investigate, verify, or judge work
-
-- [Execute Work](../execute-work/SKILL.md) for concrete implementation, documentation, configuration, learning, or maintenance.
-- [Migration Work](../migration-work/SKILL.md) for moving consumers, state, or traffic between paths.
-- [Diagnose Failure](../diagnose-failure/SKILL.md) for unexplained or repeated failure.
-- [Verify Work](../verify-work/SKILL.md) for determining what direct evidence proves.
-- [Review Work](../review-work/SKILL.md) for implementation judgment, independent review, or adjudication.
+Use the Feedback Loop to establish the next action's basis, not to perform a fixed sequence of ceremonies:
 
-[TDD](../tdd/SKILL.md), [Simplify Code](../simplify-code/SKILL.md), domain guidance, references, and tools may supply the current owner’s method without becoming another owner.
+```text
+Orient or reconstruct current state
+-> WHAT: establish the required outcome and constraints
+-> HOW: establish a supported approach for the next coherent unit
+-> act through the current owner
+-> verify what happened
+-> self-review the supported result
+-> continue, re-enter, ask, stop, or complete
+```
 
-### Preserve, checkpoint, integrate, or deliver
+These are questions to resolve, not mandatory separate reads, documents, or user turns. Reuse understanding that remains supported. One observation can answer both what and how. A factual answer or discussion can exit without implementation.
 
-- [Commit Work](../commit-work/SKILL.md) for an authorized local commit or simple push.
-- [Handoff](../handoff/SKILL.md) for point-in-time continuation transfer.
-- [Finish Branch](../finish-branch/SKILL.md) for integration, preservation, discard, or branch closeout.
-- [Release Work](../release-work/SKILL.md) for versioned publication.
-- [Launch Work](../launch-work/SKILL.md) for production exposure, rollback, or recovery.
+Before production changes, the agent must understand the required result and have a source-backed approach, affected boundary, and check capable of disagreeing. Do not demand every future file or detail before the next unit. Do not start substantial dependent work while a premise capable of invalidating it remains unresolved.
 
-### Apply modifiers and interaction control
+Use bounded learning when exercising behavior is needed to settle that premise. Its endpoint is the question answered or the observation limit reached—not a production-ready prototype. Existing authority must cover its effects.
 
-[Bypass](../bypass/SKILL.md) modifies explicitly selected optional Workflow pressure. It does not become the owner of the underlying activity.
-
-When the owner needs an environment interaction and the action or tool choice is not already obvious, use [Action Selection](../action-selection/SKILL.md). It returns the observation and state change to the same current owner.
+## Choose And Keep One Current Owner
 
-When specialized engineering guidance must support the current owner, read [Domain Skill Composition](references/domain-skill-composition.md).
+Choose the narrowest activity whose responsibility matches the current question or result.
 
-Keep the current owner while its question, intended result, authority, and required observing boundary remain coherent. Methods, tools, feedback, profile transitions, and environment interactions do not create owner changes by themselves.
+- [Discuss](../discuss/SKILL.md) owns open direction, alternatives, assumptions, and collaborative outcome or approach decisions.
+- [Decision Gate](../decision-gate/SKILL.md) resolves one known user-owned choice or material source conflict.
+- [Execute Work](../execute-work/SKILL.md) owns concrete work, including bounded implementation preparation, execution, and in-Slice continuation.
+- [Diagnose Failure](../diagnose-failure/SKILL.md) establishes unsupported or repeatedly failing causes before correction.
+- [Verify Work](../verify-work/SKILL.md) establishes factual support; [Review Work](../review-work/SKILL.md) and [Review Artifact](../review-artifact/SKILL.md) judge resulting work and guiding artifacts.
+- [Track Work](../track-work/SKILL.md) owns Working Record creation, reconstruction, reconciliation, and lifecycle.
+- [Write Spec](../write-spec/SKILL.md) owns durable accepted content; [Write Plan](../write-plan/SKILL.md) owns a sufficiently settled ordered strategy.
+- [Migration Work](../migration-work/SKILL.md) owns movement of consumers, state, or traffic.
+- [Commit Work](../commit-work/SKILL.md), [Handoff](../handoff/SKILL.md), [Finish Branch](../finish-branch/SKILL.md), [Release Work](../release-work/SKILL.md), and [Launch Work](../launch-work/SKILL.md) own their selected preservation or delivery boundaries.
 
-Recommend Discuss before authorized work only when user input could materially change the outcome, boundary, tradeoff, approach, or acceptance. Inspect available facts and choose reversible local details without unnecessary questions.
+[Design for Depth](../design-for-depth/SKILL.md) supplies a lens where design matters. [Simplify Code](../simplify-code/SKILL.md) and domain guidance may supply an execution method without becoming another owner. Verify Work supplies test-design guidance when checks must be designed; a formal test-first sequence is not required. [Bypass](../bypass/SKILL.md) reduces explicitly selected optional pressure, not authority or evidence requirements.
 
-## Route From The Result
+When the owner needs an environment interaction and the action or tool choice is not already obvious, use [Action Selection](../action-selection/SKILL.md). It returns the observation and state change to the same owner. Read [Domain Skill Composition](references/domain-skill-composition.md) when specialized guidance is needed.
 
-Run the guaranteed Feedback Loop through the current owner. Re-enter Workflow only when authority, ownership, required evidence, checkpoints, or the supported exit changes.
+Keep the owner while its question, outcome, authority, and observing boundary remain coherent. Local implementation preparation does not require another discussion merely because a file or signature must be inspected. Cognitive Routing controls compute placement, not these responsibilities.
 
-Route from what the result now supports:
+## Size Work By Context And Dependencies
 
-- **Continue:** the current owner, intended result, authority, and required observing boundary remain coherent.
-- **Correct locally:** one clear defect preserves accepted intent and effects; return it to the producing owner, re-verify the affected boundary, and self-review the corrected state.
-- **Broaden evidence:** the claim exceeds the current observer; use Verify Work or return the missing evidence requirement to the current owner.
-- **Diagnose:** the cause is unclear, evidence conflicts, or correction repeats.
-- **Discuss:** assumptions, alternatives, strategy, or direction materially changed.
-- **Decision Gate:** one user-owned choice or source conflict blocks safe continuation.
-- **Track:** durable task state must be created, recovered, reconciled, or changed materially.
-- **Revise an artifact:** accepted content, strategy, decision, or transfer state changed; return to that artifact’s owner.
-- **Review:** selected judgment is needed after factual support.
-- **Checkpoint:** a selected boundary is due before dependent work.
-- **Stop or defer:** no safe, authorized, and worthwhile continuation remains.
+Use a whole-task attempt when its necessary working set, execution, checking, and likely correction remain manageable. Otherwise choose coherent outcomes in dependency order. A Slice may contain several bounded activities and delegation units; none is a tool-call quota or file batch.
 
-Preserve unaffected decisions, artifacts, work, and evidence. New evidence changes the route only where its consequence applies.
+Keep the task horizon directional: outcome, major dependencies, and proposed remaining Slices. Make the current unit concrete enough to execute. Do not research all later work now or promise an exact token forecast.
 
-Do not continue because implementation began, review unsupported work as ready, restart the task because one responsibility changed, or let a useful next action become implied authority.
+Split when distinct dependencies, uncertainty, outcome boundaries, or context requirements make one attempt unreliable. Do not split every bug, test, review, or implementation stage mechanically. A context cycle can contain several Slices, and one Slice can span context cycles.
 
-## Preserve Continuity Deliberately
+When continuity matters, use Track Work to preserve the current understanding and useful provisional Future Work. Proposed order is revisable and not authority. Before the next Slice, check that prerequisites actually hold and choose only the additional context it needs.
 
-Decide whether losing current task state could cause later misalignment.
+## Re-enter Only What Changed
 
-Use Track Work when decisions, evidence, authority, current work, blockers, checkpoints, or the next useful action need durable recovery. Do not create a Working Record for a short disposable activity merely because work occurred.
+Route from the consequence of evidence:
 
-When a Working Record exists after compaction, summarization, session navigation, or ownership transfer:
+- Clear defect with a supported remedy -> return to its producer, correct within authority, then recheck the affected result.
+- Outcome settled, implementation approach invalidated -> re-establish how through Execute Work, or Discuss when material alternatives require reconsideration.
+- Cause unsupported, contradictory, or repeatedly failing -> Diagnose Failure.
+- Outcome, expected behavior, or acceptance unsettled -> Discuss or Decision Gate.
+- Required claim exceeds its evidence -> distinguish unavailable/stale evidence, an inadequate observer, and a demonstrated defect. Recover or establish the missing observation through Verify Work before commissioning a guessed fix; do not silently narrow acceptance.
+- Optional stronger claim lacks evidence -> qualify or withdraw that claim rather than automatically expand implementation.
+- Accepted content or strategy changed -> reconcile affected task memory and return affected artifacts to their owners before dependent use.
+- No useful covered continuation -> stop, defer, or ask.
 
-1. route record recovery and reconciliation through Track Work;
-2. compare recovered memory with the current user turn and relevant live state;
-3. return to the owner whose activity actually continues.
+Before adding a prerequisite, ask: does it serve an accepted requirement, or only preserve the chosen approach or add an optional guarantee? Seek the smallest supported remedy that preserves the outcome. One failed mechanism is not proof that every in-scope approach is impossible.
 
-After recovery, re-read the current owner’s skill when its exact method is absent, reopen only the sources or history needed for the next decision, and re-establish authority from valid current-session sources.
+If a remedy changes behavior, compatibility, host ownership, scope, or another user-owned boundary, explain the concrete consequence and realistic alternatives before adopting it. Do not make an expansive recommendation appear necessary by describing only its technical mechanism.
 
-Track Work owns record views, schemas, mutations, and lifecycle mechanics. Workflow does not reproduce them.
+Preserve valid work and contrary evidence. Before requiring more correction or proof, identify the accepted requirement it protects; supervisory preference must not become a stronger obligation. When a mismatch repeats, isolate what remains unresolved and identify a changed basis for the next attempt rather than repeat the same assignment more forcefully.
 
-A summary, historical skill body, Working Record, Plan, or Handoff preserves context. It does not create current authority, prove live state, or become profile-routing state.
+A new question does not authorize another prototype; a successful prototype does not authorize production promotion. Ordinary local adaptation remains covered when the agreement is unchanged.
 
-## Select And Route Checkpoints
+## Preserve Continuity Without Restarting
 
-Select a checkpoint only when crossing it unresolved could materially endanger dependent work, rollback, provenance, transfer, integration, or delivery.
+Use Track Work when losing decisions, the current result, dependencies, evidence, blockers, or the next action could misalign continuation. Do not create a record for a short disposable result merely because work occurred.
 
-A checkpoint may require:
+Before a known context boundary, preserve material changed understanding, partial effects, relevant failed approaches, remaining dependencies, and the next useful action through Track Work. Keep the intended outcome and user-facing return condition distinct from the current implementation approach. Do not wait for artificial completion or write a command log.
 
-- a user decision;
-- selected independent review;
-- a local commit;
-- continuity transfer;
-- branch integration;
-- release;
-- launch.
+After context loss or uncertain continuity, follow core recovery guidance and read the complete Working Record through Track Work's `full` view. Reconcile its current sections and relevant History with current user direction, defining artifacts, and live state; confirm that the recovered agreement still authorizes the next action and its prerequisites hold. If full recovery is unavailable or incomplete, report the limit before task work. Reload the owner's exact method if absent. Inspect additional sources only where they change the next action, rather than replaying the investigation.
 
-A pause, status update, bounded activity ending, completed implementation, passing check, or self-review does not create a checkpoint automatically.
+With intact context, use `resume` or targeted record reads when current-state readback is useful. Do not trigger full reconstruction merely because another turn or ordinary pause occurred.
 
-Workflow selects the checkpoint and the boundary it protects. Its owner performs it. Track Work preserves its selection and result when durable memory exists.
+A record, summary, or other conversation branch can preserve approval evidence but cannot create current authority or settle compute-routing state.
 
-Self-review remains part of the ordinary Feedback Loop and is never a checkpoint.
+## Continue To The Agreed Return Boundary
 
-Review Work owns review roles, findings, adjudication, judgments, and cycle limits. Workflow consumes the returned result and decides what responsibility follows. A review report, finding, judgment, or suggested remedy does not authorize correction or another review.
+Continue across covered actions and Slices without asking for another "continue" when the agreement covers the remaining task. Starting a new Slice still requires Track Work's lifecycle operation when a record exists; closure alone does not select it.
 
-When checkpoint evidence or conditions no longer hold, return the deviation rather than forcing the checkpoint. Cancel, replace, defer, or revise a selected checkpoint only through an explicit supported route, then reconcile durable state when present.
+A method change, Standard handback, passing check, or context reconstruction is not automatically a user-facing return. Resume covered work after required recovery. Respect fresh user direction and stop when the agreed endpoint, a genuine blocker, or an uncovered consequential choice is reached.
 
-Do not create an automatic review–fix–review loop. Do not keep editing merely to obtain Pass.
+Select checkpoints only when they protect a meaningful dependency, decision, rollback, transfer, integration, or delivery boundary. Their owners perform them; Track Work preserves them when needed. Self-review is ordinary feedback, not a checkpoint.
 
-A commit, handoff, integration, push, release, or launch remains separately controlled unless the authority envelope explicitly covers it.
+Independent review must be selected and covered. Findings do not authorize correction or another review. Reuse adequate evidence and affected self-review; do not create an automatic review-fix-review loop. Commit, push, integration, release, launch, and other separately controlled effects remain excluded unless explicitly covered.
 
 ## Reach A Supported Exit
 
-A Supported Exit may answer, wait, pause, hand off, defer, preserve a controlled boundary, stop, or complete.
-
-Claim completion only when:
-
-- fresh evidence supports the accepted outcome at the required boundary;
-- every completed bounded activity received required self-review with no unresolved material issue;
-- selected reviews and checkpoints are resolved;
-- task memory and required artifacts accurately describe the supported state;
-- no material contradiction, source conflict, blocker, or user-owned decision remains hidden;
-- no separately controlled action is being implied as complete.
-
-Report proportionately:
-
-- the supported outcome;
-- strongest evidence and proof limits;
-- material unresolved or deferred state;
-- the current route when work continues or waits.
-
-A recommendation for a next action does not authorize it.
-
-## Stop
-
-Stop Workflow when:
+Claim completion only when the agreed outcome is supported by fresh evidence, required self-review is complete, selected independent reviews are adjudicated, selected checkpoints are resolved, and required task memory and artifacts describe the result accurately. No material contradiction, source conflict, blocker, or user-owned decision may be hidden.
 
-- a Supported Exit is reached; or
-- one current owner can continue without an unresolved authority, ownership, checkpoint, continuity, or route question.
+Report the result, strongest evidence and limits, unresolved or deferred work, and the return boundary reached. Do not imply that an unperformed delivery action occurred or that optional improvements are unfinished obligations.
 
-Resume Workflow only when feedback or evidence changes one of those boundaries.
+Stop Workflow when a Supported Exit is reached or one current owner can continue without an unresolved coordination question. Re-enter only when evidence or direction changes that responsibility.