@hassangameryt/freeflow 0.8.0 → 0.9.0

package/skills/action-selection/references/trajectory-stalls.md

@@ -1,73 +0,0 @@
-# Trajectory Stalls
-
-Read this when two or more recent environment interactions have not materially changed the current question, advanced the covered effect, or supported a new branch.
-
-This reference is judgment: use it to recover a useful interaction, not as a checklist.
-
-A stall is evidence that the current interaction policy is no longer producing useful progress. It does not prove that the task is difficult, the design is wrong, or another model is required.
-
-## Recognize A Stall
-
-Common stall patterns include:
-
-- repeating searches with synonymous terms;
-- rereading unchanged sources without a new question;
-- rerunning the same check against unchanged state;
-- widening search breadth without narrowing the hypothesis;
-- collecting new output that does not change any belief or decision;
-- revisiting a path already eliminated by supported evidence;
-- changing hypotheses without a new observation;
-- alternating edits, failures, and reversions without a supported cause;
-- following each newly mentioned symbol or file away from the accepted outcome;
-- continuing because interaction began rather than because evidence supports another step.
-
-The following are not automatically stalls:
-
-- several distinct mechanical interactions required by one exact covered effect;
-- rerunning evidence after relevant state changed;
-- a long-running operation that is still producing the selected result;
-- checking a broader boundary after a focused result when that boundary was already required;
-- returning through several files along one supported call or dependency path.
-
-Judge progress by changed understanding, produced effects, or a newly supported branch—not raw action count.
-
-## Stop Before Another Similar Interaction
-
-Before another environment action:
-
-1. restate the unresolved question or exact covered effect;
-2. identify what the recent interactions established;
-3. identify which paths or hypotheses they eliminated;
-4. state why the interactions failed to change the decision;
-5. determine whether another observer class could discriminate where the previous one could not.
-
-Different observer classes may include:
-
-- structural navigation instead of text search;
-- caller or dependency tracing instead of concept search;
-- runtime behavior instead of source inspection;
-- source inspection instead of another runtime rerun;
-- exact artifact comparison instead of summary output;
-- a minimized reproduction instead of another speculative edit.
-
-Changing syntax, keywords, directories, or tools without changing the evidence relationship is not a different observer class.
-
-## Recover With One Discriminating Action
-
-When a different covered observer can answer the unresolved question:
-
-1. name what result would support or contradict the leading path;
-2. bound one interaction;
-3. execute it once;
-4. return its observation to the current owner.
-
-Do not compensate for a stall by generating a long plan, exploring every remaining path, or broadening the task.
-
-When no covered interaction can discriminate:
-
-- return the smallest missing evidence to the current owner;
-- return a changed authority, scope, ownership, direction, or required observing boundary to [Workflow](../../workflow/SKILL.md);
-- use [Diagnose Failure](../../diagnose-failure/SKILL.md) when repeated failure lacks a supported cause;
-- stop when the active execution contract requires return.
-
-A stall recovery succeeds when the decision surface changes or the absence of a safe useful interaction becomes explicit. It does not require another tool call.

package/skills/bypass/SKILL.md

@@ -1,153 +0,0 @@
----
-name: bypass
-description: "Use when the user explicitly asks to skip or reduce optional workflow pressure for the next authorized activity or the current task."
----
-
-# Bypass
-
-Reduce explicitly selected optional workflow pressure without changing authority, accepted intent, the current owner, execution method, evidence semantics, selected checkpoints, mode, active capability protocols, or host controls.
-
-Bypass is a user-controlled pressure modifier. It does not authorize the underlying work and does not perform that work itself.
-
-**Optional pressure** is a workflow step whose removal does not weaken accepted intent, material risk control, required evidence, a selected checkpoint, or safe continuation.
-
-## Interpret The Request Narrowly
-
-Use Bypass only when the user explicitly asks to skip or reduce workflow pressure. Do not infer bypass from urgency, frustration, brevity, “just do it,” or a preference for concise responses.
-
-Establish:
-
-- the already-authorized activity;
-- the specific pressure the user wants removed;
-- whether the requested scope is `next` or `task`;
-- the authority, evidence, checkpoints, and stop conditions that remain;
-- when the bypass expires.
-
-A bare `/bypass` means `/bypass next`.
-
-If the same user turn both authorizes an activity and explicitly requests reduced pressure, interpret the whole turn through [Workflow](../workflow/SKILL.md). Bypass may modify that authorized activity; it does not supply its authority.
-
-If no authorized activity exists, return to Workflow and wait. Do not treat bypass as permission to implement, inspect actively, mutate, deliver, commit, or continue.
-
-## Skip Only Optional Pressure
-
-A valid bypass may remove:
-
-- an unnecessary Spec, Plan, or Working Record;
-- extended questioning whose answer would not change the accepted activity;
-- an artifact created only for ceremony;
-- duplicate explanation or status reporting;
-- a proposed but unselected review or checkpoint with no remaining risk purpose;
-- another optional step whose removal does not weaken the supported outcome.
-
-Do not infer that a named artifact, review, check, or checkpoint is optional. Inspect what it protects before removing it.
-
-Freeflow should already avoid unnecessary ceremony. Bypass is an explicit user override when optional pressure was proposed or recommended but was not selected as a required boundary, or would otherwise remain in the route.
-
-## Preserve Non-Bypassable Boundaries
-
-Bypass does not remove or override:
-
-- the user’s authority over product behavior, scope, priorities, public interfaces, compatibility, permissions, security, privacy, billing, data loss, migration direction, deployment, or another hard-to-reverse outcome;
-- conflicts among the request, code, tests, docs, policies, requirements, accepted behavior, or another source of truth;
-- the authority the user granted or separately controlled effects;
-- host safety, sandbox, permission, approval, or tool controls;
-- mode boundaries or active capability protocols;
-- the distinction between available evidence and supported claims;
-- required self-review before accepting or reusing a supported result;
-- an accepted Spec, Plan, selected checkpoint, required artifact review, or selected independent review;
-- a stop condition, blocker, or evidence that invalidates the current route.
-
-Material risk still requires the decisions and evidence that address it. A domain label alone does not require ceremony, but bypass cannot erase an observed risk.
-
-Bypass cannot allow an active compute profile to act outside its execution protocol. Use the capability’s own user controls when the user wants to change manual or automatic control, profile behavior, or another capability setting.
-
-## Respect Declined Evidence Without Inventing Support
-
-A user may explicitly decline a test, build, runtime probe, review, or other evidence generation. Respect that instruction unless a higher-priority repository, host, or safety requirement prevents it.
-
-Declining evidence does not make the corresponding claim supported.
-
-When evidence is declined:
-
-- perform only the remaining authorized work that can continue safely;
-- leave the affected claim explicitly unverified;
-- do not accept or reuse the result beyond the remaining evidence boundary;
-- do not cross a checkpoint or dependent boundary that requires the missing evidence;
-- return to Workflow when the expected exit, checkpoint, or safe continuation must change.
-
-A request to skip evidence generation changes what may be claimed. It does not change what the available evidence proves.
-
-## Route Changes Are Not Bypass
-
-Treat the request as a Workflow route change when the user wants to:
-
-- change accepted behavior, scope, effects, or stop conditions;
-- weaken or replace an accepted evidence requirement;
-- cancel or replace a selected checkpoint;
-- revise an accepted Spec or Plan;
-- change mode or an active capability protocol;
-- continue despite contradictory evidence or a source conflict.
-
-An explicit user instruction may authorize the changed route, but Workflow must reconcile its consequences before dependent work continues.
-
-Use [Decision Gate](../decision-gate/SKILL.md) only when one user-owned choice or source conflict remains unresolved.
-
-## Apply The Selected Scope
-
-### Next
-
-`/bypass next` removes one identified optional pressure from the current authorized activity.
-
-The bypass is spent when:
-
-- the selected pressure is skipped;
-- the activity changes;
-- another gate or stop condition appears;
-- the route ends.
-
-Re-check the route immediately after applying it. Do not carry the bypass into another activity by implication.
-
-### Task
-
-`/bypass task` reduces identified optional pressure for the current accepted task.
-
-The task is the accepted request or active Working Record scope—not the repository, session, branch, or future related work.
-
-Name the pressure being reduced when possible. Do not interpret task scope as “ignore all workflow for this task.”
-
-Task scope ends when:
-
-- the task completes or is abandoned;
-- its accepted outcome changes materially;
-- the user withdraws or replaces the bypass;
-- a new task begins.
-
-Reassess new risks, conflicts, evidence requirements, checkpoints, and separately controlled effects inside the task. Task scope does not make them optional.
-
-When an existing Working Record is already authorized for maintenance and the task-scoped bypass must survive context loss, use [Track Work](../track-work/SKILL.md) to preserve its source, exact pressure, scope, and expiry.
-
-The record preserves the user instruction; it does not broaden it. Without durable task memory, do not claim task-scoped bypass survives context loss.
-
-Never convert `next` or `task` scope into permanent, repository-wide, session-wide, or cross-task behavior.
-
-## Return The Modified Route
-
-When the bypass is valid:
-
-1. identify the optional pressure being removed;
-2. apply only the selected scope;
-3. return the reduced-pressure route to the unchanged current owner;
-4. let that owner perform the separately authorized activity;
-5. preserve the same evidence honesty, self-review, and stop conditions;
-6. report what was skipped only when it materially clarifies the result or remaining scope.
-
-Do not narrate internal bypass state on every turn. Speak in ordinary engineering language unless the scope or expiry matters to the user.
-
-When a boundary remains:
-
-1. do not perform the blocked action;
-2. state the boundary the bypass cannot remove;
-3. return to Workflow, Decision Gate, or the relevant current owner.
-
-Bypass ends when the selected optional pressure has been removed, its scope expires, or a non-bypassable boundary requires another route.

package/skills/commit-work/SKILL.md

@@ -1,93 +0,0 @@
----
-name: "commit-work"
-description: "Use when creating an explicitly requested or selected local Git commit, including staging its exact contents, verifying the resulting checkpoint, or performing a separately authorized simple push."
----
-
-# Commit Work
-
-Preserve one supported repository state as a coherent local Git checkpoint.
-
-Commit Work normally follows execution, verification, self-review, and any selected independent review. It preserves that supported state; it does not establish correctness, close the Slice, authorize another Slice, or imply push, integration, release, or launch. A commit is not mandatory merely because work finished.
-
-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
-
-- Commit only when the user explicitly requests a local commit or [Workflow](../workflow/SKILL.md) selects an authorized `preserve` Checkpoint. Approval to implement does not imply approval to commit, and a Working Record may preserve checkpoint selection and authority but cannot create them.
-- Never silently unstage, reset, rearrange, discard, overwrite, or absorb user-owned or pre-existing staged work to manufacture a clean commit.
-- Never stage Working Records (`.freeflow/tasks/**`), secrets, credentials, private keys, local environment files, or unexplained sensitive content.
-- Never use `--amend`, `--allow-empty`, or `--no-verify` by implication, and never bypass or blindly retry a failing hook.
-- The commit claim never exceeds the available verification and review evidence. An explicitly requested preservation checkpoint may capture incomplete, failing, or inconclusive work; describe it honestly and do not treat the commit as permission to cross the unresolved boundary.
-- A local commit does not authorize push. A commit is never a Slice of its own. Do not stage leftovers, begin another Slice, push, integrate, release, or clean up merely because the commit succeeded.
-
-## Enter At The Commit Boundary
-
-Goal: commit one supported state that the request, decisions, and live changes all describe.
-
-Before staging, confirm that local commit authority is explicit and still valid; the checkpoint has one coherent claim; the request, accepted decisions, and live changes describe the same outcome; fresh evidence supports the exact state, or this is an explicitly requested preservation checkpoint; any selected independent review is complete and its material findings adjudicated; and no unresolved decision, source conflict, or required evidence gap is hidden by the claim.
-
-Commit Work verifies fidelity between the supported state and the Git checkpoint. It does not dispatch missing review, repair implementation, or generate missing behavioral evidence; return those needs to Workflow.
-
-## Inspect The Candidate State
-
-Goal: know every changed path and who owns it before touching the index.
-
-Inspect before changing the index:
-
-```bash
-git status --short --branch
-git status
-git diff
-git diff --cached
-git ls-files --others --exclude-standard
-```
-
-Inspect submodule state when status reports a changed submodule. Staged state is evidence of index contents, not of ownership, intent, verification, or readiness.
-
-Read [Staging Decisions](references/staging-decisions.md) when staged, unstaged, or untracked changes have mixed ownership or concerns; a path contains both intended and excluded changes; existing staged ownership is uncertain; generated, durable, sensitive, or suspicious files appear; or narrowing may require changing existing staged state.
-
-Read [Git State Edges](references/git-state-edges.md) when Git reports an in-progress operation, unmerged paths, detached `HEAD`, submodule ambiguity, or an empty candidate; a requested commit would amend, be empty, or bypass hooks; or any commit or hook fails.
-
-## Build The Exact Checkpoint
-
-Goal: the index contains exactly the checkpoint, and nothing is left behind unexplained.
-
-Stage only paths or hunks required to make the checkpoint claim true. Broad staging is acceptable only when every changed path has been inspected and belongs to the same checkpoint; otherwise stage explicit paths or hunks.
-
-After staging, inspect the exact candidate with `git diff --cached` and `git diff --cached --check`, and confirm that every staged path and hunk belongs; required tests, documentation, generated outputs, or metadata are present; no unrelated, sensitive, unexplained, or user-owned content is included; the staged diff is non-empty unless an empty commit was explicitly requested; and excluded working-tree changes do not invalidate the evidence for the staged checkpoint.
-
-Interpret `git diff --cached --check` against repository conventions. Unresolved conflict markers or unintended whitespace damage stop the commit; do not edit content merely to silence the command. If producing the exact checkpoint requires source changes, more evidence, or a user-owned staging decision, return to Workflow.
-
-## Create The Commit
-
-Goal: a message that describes the actual checkpoint.
-
-Use the repository's established commit-message style; otherwise a short imperative subject describing the actual checkpoint, not the wider task ambition. Add a body only when the diff does not explain material context, tradeoffs, residual risk, or why incomplete state is being preserved. Reference issues, Specs, Plans, or decisions only when they materially explain the checkpoint, and do not invent trailers or metadata conventions.
-
-Create an ordinary local commit from the inspected index. If a hook fails, changes files or the index, or makes prior evidence stale, inspect the resulting state through Git State Edges.
-
-## Verify And Report The Checkpoint
-
-Goal: the created commit is the checkpoint that was claimed, and nothing else changed.
-
-After Git reports success, inspect:
-
-```bash
-git show --stat --oneline --decorate HEAD
-git show --format= --name-status HEAD
-git status --short --branch
-```
-
-Confirm that the intended commit was created, its subject and contents represent the claim, no unexpected staged, unstaged, or untracked state resulted, and remaining changes are known.
-
-Report the commit SHA and subject; the checkpoint claim and included scope; verification and selected-review evidence; whether it is complete or an honest preservation checkpoint; remaining staged, unstaged, untracked, unverified, or unpushed work; and any hook, signing, identity, or repository limitation.
-
-Return the result to Workflow. When a Working Record exists, Workflow may route [Track Work](../track-work/SKILL.md) to record `commit:<sha>` in the Current Slice's Material updates, close the selected `preserve` Checkpoint, and reconcile the Current Slice.
-
-## Push Only When Separately Authorized
-
-Before any push, read [Simple Push](references/simple-push.md). Use [Finish Branch](../finish-branch/SKILL.md) instead when the request involves integration, pull-request strategy, branch cleanup, history rewriting, or choosing among branch-closeout routes.
-
-## Stop
-
-Stop and return the smallest blocking fact when commit authority or the checkpoint claim is unclear; live changes no longer match the supported outcome; selected review or required evidence remains unresolved; the exact checkpoint cannot be staged without manipulating ambiguous user-owned state; sensitive or unexplained content may be included; Git is in a non-ordinary state whose intended outcome is unsettled; creating the commit would require implementation changes, evidence generation, hook bypass, amendment, or history rewriting outside explicit authority; or a push destination, upstream, or remote-history effect is unclear.

package/skills/commit-work/references/git-state-edges.md

@@ -1,94 +0,0 @@
-# Git State Edges
-
-Read this when Git reports an in-progress operation, unmerged paths, detached `HEAD`, submodule ambiguity, or an empty candidate; a requested commit would amend, be empty, or bypass hooks; or any commit or hook fails.
-
-These states can change the meaning or recoverability of a commit. Inspect before choosing a recovery action. Each "do not" below is binding; the inspection steps are judgment.
-
-## In-Progress Operations
-
-A commit during merge, rebase, cherry-pick, or revert may complete or advance that operation rather than create an ordinary checkpoint.
-
-Stop and establish:
-
-- which operation is active;
-- whether the current checkpoint is intended to conclude it;
-- whether all conflicts and behavior decisions are settled;
-- which owner should continue the operation;
-- what verification is required on the resulting state.
-
-Do not use Commit Work to finish an operation merely because Git currently permits `commit`.
-
-Unmerged paths always stop an ordinary commit.
-
-## Detached HEAD
-
-A detached-`HEAD` commit may be valid but can become difficult to recover or push.
-
-Before committing, require an explicit preservation route naming how the resulting commit will remain reachable. Use [Finish Branch](../../finish-branch/SKILL.md) when branch creation, integration, or checkout ownership must be decided.
-
-Do not silently create or switch branches.
-
-## Amend And Empty Commits
-
-`git commit --amend` rewrites an existing checkpoint. Use it only when the user explicitly requests amendment and the exact target commit, included changes, authorship effects, and remote-history state are known.
-
-If the target may already be shared or pushed, return to [Workflow](../../workflow/SKILL.md) or Finish Branch before rewriting it.
-
-Use `--allow-empty` only for an explicitly requested empty checkpoint with a named repository purpose. An accidentally empty index is not authorization for an empty commit.
-
-## Hooks
-
-Do not bypass hooks merely because they block the commit.
-
-When a hook fails:
-
-1. preserve its complete result;
-2. inspect `HEAD`, the index, and working tree;
-3. determine whether a commit was created despite the reported failure;
-4. determine whether the hook changed files or staged content;
-5. return implementation, verification, policy, or environment failures to their owning route.
-
-When a hook changes repository content, the previously supported state may no longer be the state being committed. Reinspect the complete diff and obtain affected verification before retrying.
-
-Use `--no-verify` only when the user explicitly requests that exact bypass and repository policy permits it. Report which checks were skipped and which claims therefore remain unsupported.
-
-## Commit Command Failures
-
-After any failed or interrupted commit attempt, inspect:
-
-```bash
-git status
-git diff
-git diff --cached
-git log -1 --oneline --decorate
-```
-
-Do not assume failure means no commit was created or no state changed.
-
-For identity, signing, credential-helper, editor, lock, filesystem, or permission failures:
-
-- do not change global or repository Git configuration without authority;
-- do not delete lock files while process ownership is unclear;
-- do not retry through a materially different command without a supported cause;
-- report the exact blocker and preserved state.
-
-Use [Diagnose Failure](../../diagnose-failure/SKILL.md) when the cause remains unclear or a retry repeats the failure.
-
-## Submodules
-
-A parent commit records a submodule pointer, not the submodule's uncommitted contents.
-
-Inspect:
-
-- the recorded pointer change;
-- whether the nested worktree is dirty;
-- whether the intended checkpoint includes the pointer update;
-- whether nested changes have their own preservation route.
-
-Do not claim nested changes are preserved by committing only the parent repository.
-
-## Return Safely
-
-Return to Commit Work only when the repository has one supported, recoverable checkpoint candidate.
-
-Otherwise preserve the exact Git state and return to Workflow, Finish Branch, Diagnose Failure, or the producing activity whose responsibility changed.

package/skills/commit-work/references/simple-push.md

@@ -1,94 +0,0 @@
-# Simple Push
-
-Read this before performing any push through Commit Work.
-
-The stop conditions and prohibitions below are binding; the inspection commands are judgment.
-
-A **simple push** sends inspected local commits from the current named branch to one explicit or established remote branch without force, deletion, tag publication, integration, pull-request creation, release, or deployment.
-
-Use [Finish Branch](../../finish-branch/SKILL.md) when the route requires choosing how to integrate, share, preserve, rewrite, or clean up branch state.
-
-## Confirm Push Authority
-
-Push requires authority separate from local commit.
-
-Confirm:
-
-- which commits are intended;
-- the local branch;
-- the destination remote and branch;
-- whether setting a new upstream is included;
-- that no force, deletion, tag, or history rewrite is implied.
-
-Do not infer a remote, destination branch, pull-request target, or shared-branch policy when the wrong choice could affect collaborators.
-
-## Inspect The Route
-
-Inspect:
-
-```bash
-git branch --show-current
-git status --short --branch
-git branch -vv
-git remote -v
-git log -1 --oneline --decorate
-```
-
-When an upstream exists, inspect:
-
-```bash
-git rev-parse --abbrev-ref --symbolic-full-name @{upstream}
-git rev-list --left-right --count @{upstream}...HEAD
-```
-
-Ahead/behind state is only as fresh as the local remote-tracking reference. Do not claim current remote state unless it was freshly observed.
-
-Stop before pushing when:
-
-- `HEAD` is detached;
-- destination or upstream is unclear;
-- unexpected commits or dirty state change the route;
-- protected or shared-branch policy disallows the push or leaves its route unclear;
-- local and observed upstream history diverge;
-- the push would require force, deletion, tag publication, or another separately controlled action.
-
-## Push The Exact Branch
-
-Use the established upstream when it clearly matches the approved route.
-
-When no upstream exists, set one only when the remote and branch destination are explicit and the configuration change is included in the accepted route.
-
-Do not push additional branches or tags.
-
-A force push is not a simple push. Return an explicitly requested history rewrite to Workflow or Finish Branch.
-
-## Handle Rejection Without Escalation
-
-If the push is rejected or fails:
-
-- preserve the complete result;
-- do not automatically pull, merge, rebase, force, change remotes, or change destination;
-- inspect whether any remote update occurred;
-- return authentication, divergence, policy, or destination decisions to [Workflow](../../workflow/SKILL.md) or Finish Branch.
-
-A failed push does not invalidate the local commit.
-
-## Verify And Report
-
-After a successful push, inspect:
-
-```bash
-git status --short --branch
-git branch -vv
-```
-
-Report:
-
-- pushed commit range;
-- remote and destination branch;
-- whether an upstream was created or changed;
-- command result and strongest observed remote-state evidence;
-- remaining unpushed commits or dirty state;
-- CI, review, integration, release, or deployment work not established by the push.
-
-A successful push proves transfer to the observed destination. It does not prove pull-request creation, merge, release, deployment, or remote CI success.

package/skills/commit-work/references/staging-decisions.md

@@ -1,106 +0,0 @@
-# Staging Decisions
-
-Read this when staged, unstaged, or untracked changes have mixed ownership or concerns; a path contains both included and excluded work; existing staged ownership is uncertain; generated, durable, sensitive, or suspicious files appear; or narrowing may require changing existing staged state.
-
-This reference is judgment about classification, with binding stops for sensitive content, Working Records, and user-owned staged work. It determines what may enter the checkpoint. It does not establish commit authority, verification, review readiness, or permission to alter user-owned work.
-
-## Classify The Changed Units
-
-Classify at the path level only when the whole path has one role. Otherwise classify individual hunks.
-
-- **Checkpoint content:** directly implements or proves the checkpoint claim.
-- **Required companion:** tests, documentation, schema, metadata, or generated output required for that same claim.
-- **Related but separable:** useful work that does not need to be preserved in this checkpoint.
-- **Unrelated or user-owned:** work outside the accepted outcome or whose ownership is not established.
-- **Sensitive or unsafe:** secrets, credentials, personal data, environment files, debug output, destructive state, or unexplained artifacts.
-- **Unclear:** content whose purpose, generator, ownership, or evidence relationship is not yet supported.
-
-Only checkpoint content and required companions belong.
-
-A broad request such as "commit everything" may authorize broad inclusion, but it does not remove the obligation to inspect unsafe, unclear, or unexpectedly unrelated content.
-
-## Protect Existing Staged State
-
-Existing staged changes may belong to another workflow.
-
-Inspect them, but do not infer that they are intended merely because they are staged. Do not silently:
-
-- absorb them into the checkpoint;
-- unstage or reset them;
-- amend them into another commit;
-- move them through a stash or temporary commit;
-- replace the index or use index tricks to bypass ownership ambiguity.
-
-When intended and pre-existing staged work cannot be separated without manipulating ambiguous state, present the smallest safe options and ask which checkpoint the user wants.
-
-## Handle Partial Files Carefully
-
-A file may contain both checkpoint and excluded hunks. Stage only the intended hunks when their behavior and evidence remain independently coherent.
-
-Stop when:
-
-- included and excluded hunks depend on each other;
-- partial staging would produce an invalid intermediate state;
-- verification ran against the combined working tree and excluded changes may have affected the result;
-- the staged version differs materially from the state that was reviewed or verified.
-
-Do not claim an isolated staged checkpoint is supported merely because the combined dirty worktree passed.
-
-## Include Generated Files Deliberately
-
-Include generated files, snapshots, lockfiles, formatter output, or build artifacts only when repository convention or the accepted outcome requires them.
-
-Establish:
-
-- which command or generator produced them;
-- whether their changes are expected from the accepted source change;
-- whether they are deterministic enough to review;
-- whether hand edits are prohibited;
-- whether their verification belongs to the checkpoint evidence.
-
-Do not include generated output merely because it changed. Do not hand-edit it unless the repository explicitly expects that workflow.
-
-## Preserve Durable Artifacts Honestly
-
-A Spec, Plan, ADR, policy, public documentation file, or release artifact may have authority and maintenance rules independent of implementation.
-
-Include it only when:
-
-- its change is explicitly covered;
-- it belongs to the same coherent checkpoint;
-- it describes the same accepted behavior;
-- its own maintenance policy permits the update.
-
-Do not edit a durable artifact merely to make implementation appear coherent. Return contradictions to [Workflow](../../workflow/SKILL.md).
-
-Working Records under `.freeflow/tasks/**` are ignored local memory and must never be staged or committed.
-
-## Reject Sensitive Or Suspicious Content
-
-Stop before staging:
-
-- secrets, tokens, credentials, private keys, or local environment files;
-- databases, dumps, recordings, or personal data;
-- unexplained binaries or generated archives;
-- logs, traces, screenshots, or debug output not explicitly required;
-- destructive state or files whose inclusion could expose or lose user data.
-
-Do not "clean up" suspicious files by deleting or discarding them. Preserve their state and report the exact paths.
-
-## Verify The Candidate
-
-After staging, compare all three states:
-
-```bash
-git diff --cached
-git diff
-git status --short --branch
-```
-
-The checkpoint is narrow only when:
-
-- the index contains exactly the intended checkpoint;
-- excluded work remains untouched;
-- remaining dirty state is understood;
-- verification still supports the staged version rather than only the combined worktree;
-- the final report can name everything left behind.