@hassangameryt/freeflow 0.6.0 → 0.7.1

package/skills/commit-work/SKILL.md

@@ -1,106 +1,145 @@
 ---
-name: commit-work
-description: Use when committing work, including selecting and staging the intended changes, creating and verifying the commit, or explicitly pushing committed work.
+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
 
-Commit an intended, coherent checkpoint. A commit preserves rollback and provenance; it does not prove correctness or approve the next route.
+Preserve one supported repository state as a coherent local Git checkpoint.
 
-This skill covers commits and simple pushes, not branch integration, release, or deployment orchestration. Use [Finish Branch](../finish-branch/SKILL.md), [Release Work](../release-work/SKILL.md), or [Launch Work](../launch-work/SKILL.md) for those later jobs.
+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 local commit is authorized by an explicit user request, a checkpoint whose local-commit authority was explicitly granted through a user-approved Plan, or a checkpoint explicitly approved during discussion. A Working Record may preserve that authorization but cannot create it. Plan acceptance does not authorize push, integration, migration, deprecation, release, or launch.
+A commit is not mandatory merely because work finished. Enter only when the user explicitly requests a local commit or [Workflow](../workflow/SKILL.md) selects an authorized Local commit checkpoint.
 
-A planned checkpoint remains conditional on live state. Do not force it when its intended outcome, evidence, review status, or change boundary no longer holds; return the deviation to [Workflow](../workflow/SKILL.md).
+An explicitly requested preservation checkpoint may capture incomplete, failing, or inconclusive work. Describe that state honestly and do not treat the commit as permission to cross the unresolved boundary.
 
-A commit does not select or trigger independent review. Complete only review selected by Workflow, an approved Plan, or repository policy. Commit Work does not adjudicate findings or authorize corrections or follow-up review. Fresh verification is required for the claim the commit represents.
-
-Read [staging decisions](references/staging-decisions.md) when changes or staged state are mixed, generated files or durable docs appear, existing staged ownership is unclear, broad commit/push language conflicts with diff evidence, or producing a narrow checkpoint may touch user-owned work.
-
-## Route Check
+## Enter At The Commit Boundary
 
 Before staging, confirm:
 
-- the slice or work package has one coherent outcome;
-- source truth and owner decisions still support it;
-- fresh evidence supports the claim represented by the commit, or an explicitly requested preservation checkpoint names its incomplete claim honestly;
-- any selected review has ended, its adjudicated status is known, and Workflow supports the checkpoint route;
-- no unresolved blocker, required evidence gap, or route-changing assumption is hidden by the checkpoint claim;
-- the checkpoint remains authorized and useful for rollback, integration, handoff, or repository workflow.
+- local commit authority is explicit and still valid;
+- the checkpoint has one coherent claim;
+- the request, accepted decisions, and live changes still describe the same outcome;
+- fresh evidence supports the exact state being preserved, or this is an explicitly requested preservation checkpoint;
+- any selected independent review is complete and its material findings are adjudicated;
+- no unresolved decision, source conflict, or required evidence gap is hidden by the checkpoint claim.
+
+A Working Record may preserve checkpoint selection and authority but cannot create them. Approval to implement does not imply approval to commit.
 
-When review or evidence leaves unresolved work, return it to Workflow rather than deciding readiness here. If the user explicitly requests a preservation checkpoint of incomplete, unverified, blocked, or inconclusive work, label that state honestly and include only what is safe and useful to preserve. The commit does not authorize crossing the unresolved boundary.
+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
+## Inspect The Candidate State
 
-Inspect before staging or committing:
+Inspect before changing the index:
 
 ```bash
-git status --short
+git status --short --branch
+git status
 git diff
 git diff --cached
 git ls-files --others --exclude-standard
 ```
 
-Diff evidence beats “staged,” “commit everything,” “push all,” “exactly as-is,” or “do not leave leftovers.” Treat unrelated changes as user-owned until proven otherwise.
+Inspect submodule state when status reports a changed submodule.
 
-## Stage Narrowly
+Read [Staging Decisions](references/staging-decisions.md) when:
 
-Stage explicit paths or hunks that implement the coherent checkpoint.
+- 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;
+- narrowing the checkpoint may require changing existing staged state.
 
-Avoid `git add .` and `git add -A` when unrelated, unreviewed, generated, sensitive, or user-owned changes are present.
+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.
 
-Verify existing staged changes rather than inheriting them blindly. Do not unstage, rearrange, discard, or overwrite user-owned changes merely to manufacture a clean commit without permission.
+Treat staged state as evidence of index contents, not evidence of ownership, intent, verification, or readiness.
 
-## Stop
+## Build The Exact Checkpoint
+
+Stage only paths or hunks required to make the checkpoint claim true.
 
-Stop before commit or push when:
+Broad staging commands are acceptable only when every changed path has been inspected and belongs to the same checkpoint. Otherwise stage explicit paths or hunks.
 
-- included changes are unrelated, unreviewed when review is required, or outside the accepted outcome;
-- staged and unstaged edits make commit ownership ambiguous;
-- logs, debug output, secrets, generated artifacts, lockfiles, or formatter churn lack evidence they belong;
-- durable docs and implementation describe different behavior or authority;
-- verification failed or proves less than the commit message would claim;
-- the commit mixes separable concerns in a way that harms review, diagnosis, or rollback;
-- product, security, privacy, billing, permissions, data-loss, compatibility, public API, migration, or architecture behavior changed without an explicit decision.
+Do not silently unstage, rearrange, discard, overwrite, or absorb user-owned work to manufacture a clean commit.
+
+After staging, inspect the exact candidate:
+
+```bash
+git diff --cached
+git diff --cached --check
+```
 
-Use [Decision Gate](../decision-gate/SKILL.md) when the safe commit path depends on an owner or source-truth decision. If a clean narrow commit is possible without touching unrelated work, prefer it and report what remains.
+Confirm:
 
-## Commit Shape
+- 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;
+- the commit claim does not exceed available verification and review evidence;
+- excluded working-tree changes do not invalidate evidence for the staged checkpoint.
 
-Keep the checkpoint independently understandable and revertible.
+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.
 
-Use the repo's established message style. Otherwise use a short imperative subject. Add a body only when source context, tradeoffs, residual risk, or the reason for the checkpoint would not be clear from the diff.
+If producing the exact checkpoint requires source changes, additional evidence, or a user-owned staging decision, return to Workflow rather than performing that work here.
 
-Reference specs, plans, ADRs, issues, or decisions only when they materially explain the change. Do not invent metadata conventions.
+## Create The Commit
 
-A learning-slice commit must distinguish diagnostic or exploratory output from production behavior. A deepening commit should not silently change behavior. A delivery commit should name the behavior it adds or changes.
+Use the repository's established commit-message style. Otherwise use a short imperative subject describing the actual checkpoint, not the wider task ambition.
 
-## Push
+Add a body only when the diff does not adequately explain material context, tradeoffs, residual risk, or why incomplete state is being preserved. Reference existing issues, Specs, Plans, or decisions only when they materially explain the checkpoint. Do not invent trailers or metadata conventions.
 
-Push only inspected commits when the user request and branch state make the route clear.
+Create an ordinary local commit from the inspected index.
 
-Before pushing, inspect branch, upstream, remote, and ahead/behind state. Stop before protected/shared branches, upstream changes, force pushes, remote-history rewrites, divergence, or release/PR decisions that were not explicitly requested.
+Do not use `--amend`, `--allow-empty`, or `--no-verify` by implication. Read Git State Edges when one is explicitly requested or becomes relevant.
 
-Use `--force-with-lease` only for an intended rewrite of the user's own branch with explicit approval and supporting branch evidence.
+If a hook fails, changes files or the index, or makes prior evidence stale, do not bypass or blindly retry it. Inspect the resulting state through Git State Edges.
 
 ## Verify The Checkpoint
 
-After commit or push, inspect:
+After Git reports a successful commit, inspect:
 
 ```bash
-git show --stat --oneline --name-only HEAD
-git status --branch --short
+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 checkpoint claim;
+- no unexpected staged, unstaged, or untracked state resulted;
+- remaining changes are known and were not silently absorbed.
+
 Report:
 
 - commit SHA and subject;
-- what the checkpoint contains;
-- verification and review evidence;
-- push result when applicable;
-- remaining staged, unstaged, untracked, unpushed, or unverified work;
-- recommended next route.
+- the checkpoint claim and included scope;
+- verification and selected-review evidence;
+- whether the commit is complete or an honest preservation checkpoint;
+- remaining staged, unstaged, untracked, unverified, or unpushed work;
+- any hook, signing, identity, or repository limitation;
+- the route returned to Workflow.
+
+Return the checkpoint result to Workflow. When a Working Record exists, Workflow may route [Track Work](../track-work/SKILL.md) to record `commit:<sha>`, settle the selected checkpoint, and reconcile the Current Slice.
+
+Do not stage leftovers, begin another Slice, push, integrate, release, or clean up merely because the commit succeeded.
+
+## Push Only When Separately Authorized
+
+A local commit does not authorize push.
+
+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
 
-When a Working Record exists, use [Track Work](../track-work/SKILL.md) to record the commit SHA, checkpoint result, remaining state, and next useful action.
+Stop and return the smallest blocking fact when:
 
-Do not continue to the next slice, push, or integrate merely because the commit succeeded. Return the result to [Workflow](../workflow/SKILL.md), or use [Finish Branch](../finish-branch/SKILL.md) when branch closeout is selected.
+- 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;
+- push destination, upstream, or remote-history effect is unclear.

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

@@ -0,0 +1,94 @@
+# 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.
+
+## 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

@@ -0,0 +1,92 @@
+# Simple Push
+
+Read this before performing any push through Commit Work.
+
+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,73 +1,106 @@
 # Staging Decisions
 
-Read this when changes or staged state are mixed, generated files or durable docs appear, existing staged ownership is unclear, broad commit/push language conflicts with diff evidence, or producing a narrow checkpoint may touch user-owned work.
+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.
 
-## Evidence First
+This reference determines what may enter the checkpoint. It does not establish commit authority, verification, review readiness, or permission to alter user-owned work.
 
-Inspect:
+## Classify The Changed Units
 
-- `git status --short`
-- `git diff --cached`
-- `git diff`
-- `git ls-files --others --exclude-standard`
+Classify at the path level only when the whole path has one role. Otherwise classify individual hunks.
 
-Diff evidence beats “staged means ready,” “commit everything,” “push all changes,” and “include every leftover.”
+- **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.
 
-## Classify Paths
+Only checkpoint content and required companions belong.
 
-For each changed path, classify:
+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.
 
-- **Checkpoint:** directly implements or proves the intended slice.
-- **Required generated output:** repo convention or task requires it and its generator is known.
-- **Durable artifact:** Spec, policy, ADR, or Plan that belongs to the same accepted checkpoint while retaining its own authority and lifecycle.
-- **Durable continuation memory:** Working Record or Handoff describing the same checkpoint without becoming authority over live evidence.
-- **Related but separable:** useful work that should remain outside this checkpoint.
-- **Unrelated or user-owned:** not part of the current outcome.
-- **Sensitive or unsafe:** secrets, private data, debug output, destructive state, or unclear generated content.
+## Protect Existing Staged State
 
-Do not infer ownership from staging state.
+Existing staged changes may belong to another workflow.
 
-## Narrow Checkpoint
+Inspect them, but do not infer that they are intended merely because they are staged. Do not silently:
 
-A narrow commit is safe when:
+- 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.
 
-- an explicit request, user-approved Plan, or explicitly approved discussion authorizes the local checkpoint;
-- its outcome and source requirement are clear;
-- every included path belongs to that outcome;
-- verification supports the claim represented by the commit;
-- selected review status is known and [Workflow](../../workflow/SKILL.md) supports the checkpoint route;
-- excluded changes can remain untouched without loss;
-- the final report names remaining dirty state.
+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.
 
-Plan approval does not prove that every current path belongs. Stage explicit paths or hunks. If narrowing requires unstaging, rearranging, regenerating, or modifying user-owned work, stop unless the user or repo workflow already authorized that operation.
+## Handle Partial Files Carefully
 
-## Mixed Concerns
+A file may contain both checkpoint and excluded hunks. Stage only the intended hunks when their behavior and evidence remain independently coherent.
 
-Separate changes when combining them harms review, diagnosis, or rollback, especially:
+Stop when:
 
-- behavior plus unrelated refactoring;
-- source code plus local debug output;
-- generated artifacts plus unexplained hand edits;
-- durable source-truth changes plus implementation that has not been confirmed;
-- security, privacy, billing, permissions, migration, data-loss, compatibility, or public API behavior plus unrelated work;
-- learning-slice evidence plus production changes that have not passed promotion criteria.
+- 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.
 
-A single coherent behavior with its tests and matching docs may belong together.
+Do not claim an isolated staged checkpoint is supported merely because the combined dirty worktree passed.
 
-## Generated Files
+## Include Generated Files Deliberately
 
-Commit generated files, snapshots, lockfiles, build outputs, or formatter changes only when the task or repo convention makes them part of the checkpoint.
+Include generated files, snapshots, lockfiles, formatter output, or build artifacts only when repository convention or the accepted outcome requires them.
 
-Name the generator or command that produced required output. Do not hand-edit generated files unless the repo explicitly expects it.
+Establish:
 
-## Durable Artifacts
+- 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.
 
-Specs, policies, and ADRs may govern behavior. Plans preserve approved strategy; Working Records and Handoffs preserve memory. Include any of them with code only when they belong to the same coherent checkpoint and their own maintenance rules support the change.
+Do not include generated output merely because it changed. Do not hand-edit it unless the repository explicitly expects that workflow.
 
-Do not revise a durable artifact merely to make the commit appear coherent. Return a material inconsistency to [Workflow](../../workflow/SKILL.md); use [Decision Gate](../../decision-gate/SKILL.md) when one user-owned choice or source conflict blocks the checkpoint.
+## Preserve Durable Artifacts Honestly
 
-## Existing Staged State
+A Spec, Plan, ADR, policy, public documentation file, or release artifact may have authority and maintenance rules independent of implementation.
 
-Existing staged changes may belong to another workflow. Inspect them, but do not silently unstage, amend, discard, or absorb them.
+Include it only when:
 
-When ownership remains ambiguous, present the smallest safe staging options and ask which checkpoint the user wants.
+- 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.