@hassangameryt/freeflow 0.8.0 → 0.9.0

package/skills/release-work/SKILL.md

@@ -1,118 +0,0 @@
----
-name: release-work
-description: Use when preparing, publishing, or verifying a versioned software release.
----
-
-# Release Work
-
-Prepare or publish a traceable versioned artifact whose source, version, contents, and destination identity agree.
-
-A commit is not a release. A tag does not prove which artifact was built. A successful local build does not prove registry contents. A published artifact is not a production deployment.
-
-## Establish Authority And Source
-
-Loading this skill, preparing release options, or approving a general implementation Plan does not authorize a version change, remote tag, release record, registry publication, deprecation, yank, or replacement. Execute only release stages explicitly requested or separately approved. Before editing, read the repository's release policy, versioning scheme, package metadata, changelog convention, release automation, supported branches, signing or provenance requirements, and latest published versions.
-
-Use [Decision Gate](../decision-gate/SKILL.md) when the route depends on an unresolved choice about:
-
-- whether to release and which channel or audience receives it;
-- compatibility or breaking-change classification;
-- version when policy and evidence do not decide it;
-- credentials, registry, signing, provenance, or remote-tag behavior;
-- yanking, deprecating, replacing, or republishing an artifact;
-- release branches, history rewriting, or recovery from partial publication.
-
-Do not impose semantic versioning when the project uses another scheme. Before defining or changing version, source, artifact, tag, publication, or recovery identity, read [release evidence](references/release-evidence.md).
-
-## Define The Release Contract
-
-Before changing release state, establish:
-
-```text
-Release target and audience:
-Source commit / branch:
-Version and compatibility basis:
-Artifacts and supported platforms:
-Release notes / migration guidance:
-Required checks and selected reviews:
-Signing / provenance / checksums:
-Publication destination and channel:
-Failure and recovery behavior:
-Post-publication verification:
-Approved preparation and publication stages:
-```
-
-Classify consumer-observable impact rather than diff size. A small change can be breaking; a large internal refactor may preserve compatibility.
-
-When consumers must move before a contract can be removed, read [Migration Work](../migration-work/SKILL.md). An additive replacement release may precede migration; a breaking removal release must wait for the accepted migration and removal proof.
-
-## Prepare The Release
-
-For approved preparation work:
-
-- confirm the intended source is a coherent, freshly verified checkpoint and any selected review is resolved;
-- reconcile version declarations, lockfiles, generated metadata, and release notes through repository-supported tooling;
-- write release notes for consumers: behavior, compatibility, migration, security impact, and known limitations—not a raw commit dump;
-- run the canonical build or package process from the intended source state;
-- inspect the exact artifacts that would be published;
-- keep credentials and signing material out of prompts, logs, diffs, and artifacts.
-
-Do not hand-edit generated artifacts or duplicate version truth when the repository has a canonical generator. Return required branch, commit, public-documentation, or migration work to [Workflow](../workflow/SKILL.md) unless it is included in the approved release scope.
-
-## Preflight The Exact Release
-
-Before any irreversible remote action, verify:
-
-- source commit, branch, and working-tree expectations;
-- version is valid, unused, and consistent with repository policy;
-- required tests, builds, package or install checks, and compatibility checks;
-- artifact contents, entry points, names, sizes, checksums, licenses, and provenance;
-- release notes and migration guidance match observable consumer impact;
-- tag, registry, channel, and release destination identity;
-- credentials and permissions work without exposing secrets;
-- retry behavior cannot create conflicting tags or duplicate releases.
-
-Use [Verify Work](../verify-work/SKILL.md) to state what each check proves. A dry run proves only the boundaries it exercises; name signing, registry, propagation, or publication behavior that remains unverified.
-
-## Publish Only The Approved Stage
-
-Create remote tags, release records, or registry publications only when explicitly requested or approved for the inspected release contract.
-
-Use the repository's canonical order. Stop when source, version, tag, artifact, signing mode, channel, or destination identity diverges.
-
-Do not silently:
-
-- overwrite an existing version;
-- force-move a release tag;
-- publish from a dirty or different source state;
-- substitute a registry, channel, artifact, or signing mode;
-- retry an ambiguous publication without inspecting remote state.
-
-If publication partially fails or acknowledgement is lost, identify which external effects committed before choosing retry, repair, deprecation, replacement, or stop. Do not assume a network error means nothing was published.
-
-## Verify From The Consumer Boundary
-
-When publication is in scope, verify the actual public artifact when possible:
-
-- tag resolves to the intended commit;
-- published version, channel, and destinations are correct;
-- checksums, signatures, provenance, and contents match the inspected artifact;
-- a clean install, download, or launch path works for supported targets;
-- release notes and migration links resolve;
-- no unexpected artifact, credential, local configuration, or private file was published.
-
-Do not call the release complete because the publish command exited successfully. Unavailable propagation or consumer evidence leaves the corresponding claim unverified.
-
-## Report Completion Precisely
-
-Report:
-
-- approved release stage and status;
-- version, source commit, tag, channel, and destinations;
-- compatibility basis and migration guidance;
-- checks, artifact identity, and selected-review status;
-- publication and consumer-side verification;
-- partial failures, recovery actions, and residual risk;
-- any deferred commit, migration, launch, or documentation work.
-
-A prepared release is not published. A published release is not deployed. Use [Launch Work](../launch-work/SKILL.md) only when production deployment or rollout is separately requested or approved.

package/skills/release-work/references/release-evidence.md

@@ -1,78 +0,0 @@
-# Release Evidence
-
-Read this before defining or changing version, source, artifact, tag, publication, or recovery identity.
-
-## Version Basis
-
-Use the repository's declared scheme. For semantic versioning, classify consumer-observable impact:
-
-- **Major:** supported consumers must change or accepted behavior is removed/incompatible.
-- **Minor:** backward-compatible capability is added.
-- **Patch:** backward-compatible defect correction.
-
-Prerelease channels, date versions, train versions, and application builds may use different policy. Do not impose SemVer universally.
-
-When compatibility is uncertain, inspect supported consumers and ask rather than selecting the smallest bump.
-
-## Identity Chain
-
-A trustworthy release can connect:
-
-```text
-source commit
--> freshly verified release state
--> version metadata
--> build invocation and environment
--> artifact digest / signature / provenance
--> immutable tag or release record
--> registry or distribution entry
--> consumer-side install evidence
-```
-
-Name missing links instead of implying reproducibility.
-
-## Release Notes
-
-Write for consumers:
-
-- added or changed behavior;
-- fixed user-visible defects;
-- deprecated and removed contracts;
-- security impact without unsafe disclosure;
-- migration and compatibility requirements;
-- known limitations and unsupported targets.
-
-Commit history can support notes but does not replace curation.
-
-## Artifact Inspection
-
-Check as relevant:
-
-- included and excluded files;
-- executable entry points and permissions;
-- generated code and source maps;
-- dependency and lockfile state;
-- licenses and notices;
-- platform/architecture variants;
-- debug, test, local config, credentials, and private files;
-- deterministic digest or signed provenance.
-
-Use the package manager or build system's dry-run/list command when available.
-
-## Publication Failure Contract
-
-Before publication, know:
-
-- which step first creates irreversible remote state;
-- whether a version/tag can be retried idempotently;
-- how to detect a committed but unacknowledged publish;
-- whether repair, deprecation, yank, or replacement is supported;
-- who owns consumer communication.
-
-Network failure after a remote commit is ambiguous. Inspect remote state before retrying.
-
-## Consumer Verification
-
-Prefer a clean environment that does not reuse the local checkout or cache unexpectedly.
-
-Verify the actual public artifact by version or digest. A successful local build cannot prove registry contents, install metadata, signatures, or distribution propagation.

package/skills/review-artifact/SKILL.md

@@ -1,143 +0,0 @@
----
-name: review-artifact
-description: "Use when judging whether a durable artifact is aligned, sufficient, and fit to guide its intended use through self-review, independent review, or adjudication of a returned artifact review."
----
-
-# Review Artifact
-
-Judge whether the complete artifact faithfully represents accepted intent and is sufficient for its named use. Internal consistency alone is not enough if it consistently describes the wrong outcome or an obsolete baseline.
-
-[Verify Work](../../skills/verify-work/SKILL.md) establishes factual support where claims need verification. Review judges fitness without creating evidence, settling owner decisions, or authorizing revisions.
-
-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
-
-- Writing or revising a Spec or Plan does not require independent review. Select it only when requested, or justified and authorized, to protect a concrete boundary; loading this skill or switching compute profiles creates no independence.
-- An independent reviewer reports and stops: no edits, owner decisions, selection among materially different revisions, adjudication, or further dispatch, and no continuing until Pass. It runs a missing active check only when review authority covers that exact check; otherwise it reports Needs evidence.
-- Findings do not authorize revisions. Derive the judgment from your dispositions rather than adopting the reviewer's conclusion.
-- Never settle a user decision or revise upstream intent, accepted content, or owner decisions merely to make an artifact consistent or to obtain Pass. Never review until Pass.
-- Never request Review 4. A different reviewer, renamed use, or local revision does not reset the review budget.
-- Never present artifact fitness as acceptance, implementation, or execution authority.
-
-## Choose The Role And Intended Use
-
-Goal: review the whole artifact, for the use it must actually serve.
-
-- **Self-review:** the author checks its own artifact before accepting or using it. This is the normal required route.
-- **Independent review:** a separately selected reviewer judges a state it did not produce, from a separate context.
-- **Adjudication:** the receiving agent evaluates a completed independent report.
-
-Identify the artifact's exact state, type, intended use, accepted outcome and amendments, non-goals, governing format, source basis, unresolved questions, dependencies, and evidence gaps. Inspect the complete artifact and relevant sources directly, not only its author's narrative.
-
-## Establish Which Sources Govern
-
-Goal: judge against current accepted intent, not the artifact's own baseline.
-
-Check current intent and accepted upstream requirements before dependent artifacts. Follow material amendments, supersession, and deliberately selected experimental findings. Do not infer acceptance from a proposal, a review label, a passing test, or an unexplained "user approved" summary.
-
-Distinguish accepted behavior from the suggested implementation mechanism, and check both directions: has the artifact introduced stronger obligations than the accepted outcome needs, and has it omitted accepted changes or kept a superseded baseline? An experiment can establish a fact without selecting it for production; an implementation Plan cannot ignore later accepted learning because its older version was reviewed.
-
-If upstream content is unresolved or contradictory, mark dependent material contingent rather than generating exhaustive downstream findings against an unsettled premise.
-
-Read [Track Work](../../skills/track-work/SKILL.md) before reviewing a Working Record. Use [Action Selection](../../skills/action-selection/SKILL.md) when source inspection could branch broadly; skip it for an obvious artifact or dependency read.
-
-## Judge The Artifact By Its Job
-
-Goal: ask of each artifact only what its job requires.
-
-- **Working Record:** accurate current task memory, recoverable decisions and work, evidence limits, provisional remaining route, defining artifacts and Recovery sources sufficient for a fresh context to resume, and one next useful action.
-- **Spec or content contract:** the accepted behavior, boundaries, evidence, and uncertainty needed for its intended use.
-- **Plan:** a supported ordered strategy, dependencies, assumptions, checks, and invalidation conditions.
-- **Decision record or ADR:** the choice, owner, source, alternatives, rationale, consequences, and revisit or supersession conditions.
-- **Handoff:** enough truthful point-in-time context for safe continuation without replacing the live record.
-- **Other artifact:** its declared purpose without taking over another artifact's job.
-
-A proposal can be fit for discussion without being implementation-ready. Do not block on an open question the artifact intentionally preserves and whose answer its current use does not need.
-
-## Apply The Shared Kernel
-
-Goal: use only the lenses that can change fitness.
-
-- **Source alignment:** accepted requirements, amendments, decisions, and live facts agree with the artifact.
-- **Sufficiency:** it contains enough for its use without implying every future question is settled.
-- **Decision clarity:** required, tentative, open, deferred, and superseded material cannot be confused.
-- **Evidence and acceptance:** load-bearing claims and completion conditions have suitable observing or falsifying mechanisms.
-- **Behavior and failure:** consequential states, forbidden outcomes, observers, and recovery are defined where required.
-- **Dependency integrity:** relevant upstream and downstream sources agree, or their contingency is explicit.
-- **Scope and minimality:** requirements and process are justified rather than speculative or mechanically exhaustive.
-- **Clarity and continuity:** a future reader can use the artifact without reconstructing the author's private reasoning or the full transcript.
-
-Do not demand implementation detail from a PRD, progress history from a Plan, or universal guarantees from a bounded prototype report. Finding no material issue is valid.
-
-## Classify Material Findings
-
-Goal: every reported item is supported and names the right kind of problem.
-
-Ask in order:
-
-1. Does intended-use fitness depend on unsettled content or an owner choice? Report a **Question**.
-2. Does it depend on a claim that available evidence cannot establish? Report **Needs evidence**.
-3. Is there a supported defect requiring revision for this use? Report a **Blocking Issue** if the boundary cannot safely be crossed, or a **Non-blocking Issue** if revision can safely be deferred.
-4. Would it only improve a different or broader use? Omit it by default, or identify an **Improvement** when materially relevant or requested.
-
-An Issue identifies the exact location or dependency, violated source or artifact responsibility, evidence, and concrete consequence; explain why a Blocking Issue prevents the intended use. Recommend a specific revision only when source intent and dependency consequences support it.
-
-Needs evidence identifies the load-bearing claim, required observer, existing evidence and limits, why the gap matters, and the smallest observation that could disagree. Establish that the claim is required before recommending more proof; optional stronger claims may be qualified rather than expanding the task. Distinguish missing evidence from a demonstrated defect, and check which source or check state a reported pass examined and whether later changes reduced acceptance or invalidated it; a newer report cannot repair that mismatch.
-
-Do not classify wording preference, exhaustive edge cases, intentional deferrals, or polished presentation as defects.
-
-## Self-Review Once
-
-Goal: make the artifact fit for its use without turning review into open-ended rewriting.
-
-Apply the kernel silently to the artifact you produced once its load-bearing facts have adequate support; do not create formal review items, a numbered review, or an independent judgment for this route.
-
-For a clear covered defect whose revision basis is settled: return to the authoring activity and revise it, reconcile affected dependencies within authority, re-verify affected factual claims, and repeat source alignment and the affected lenses once.
-
-Use [Discuss](../../skills/discuss/SKILL.md) for changed direction or strategy, [Decision Gate](../../skills/decision-gate/SKILL.md) for a blocking owner choice or source conflict, and [Diagnose Failure](../../skills/diagnose-failure/SKILL.md) for unsupported or repeated causal claims. Return material coordination changes through [Workflow](../../skills/workflow/SKILL.md).
-
-Stop when the artifact is fit for its agreed use or a material unresolved issue is routed. Self-review is not a reason to add independent review.
-
-## Perform A Selected Independent Review
-
-Goal: a separate context judges the artifact from the evidence and reports once.
-
-Before preparing or performing it, read [Independent Artifact Reviewer Contract](references/independent-artifact-reviewer-contract.md). Use available evidence and apply Verify Work to covered checks while keeping ownership of the fitness judgment. The review ends with its report:
-
-- **Blocking:** at least one Blocking Issue.
-- **Inconclusive:** no Blocking Issue, but a material Question or Needs evidence prevents judgment.
-- **Non-blocking:** only Non-blocking Issues remain.
-- **Pass:** no Issues or material unresolved items remain.
-
-Improvements do not change the judgment or authorize revision.
-
-## Adjudicate Without Inheriting The Verdict
-
-Goal: decide what the report actually establishes before acting on it.
-
-Read [Adjudicate Artifact Review](references/adjudicate-artifact-review.md) before adjudicating. Assess each material item against the actual artifact, source truth, dependencies, and evidence:
-
-- **Accepted:** supported and applicable.
-- **Rejected:** unsupported, stale, resolved, duplicate, preference-only, outside the artifact's job, or a source misread.
-- **Open:** evidence or an owner decision is missing.
-
-Pass permits the intended use. Non-blocking permits it with explicit deferrals. Inconclusive requires the missing evidence or decision. Blocking prevents the disputed use and returns the narrowest supported revision or reconsideration to its owner through Workflow.
-
-When revision is ready, state the supported problem, revision basis, rationale, dependency impact, observing boundary, authority, and whether focused independent follow-up remains justified.
-
-## Preserve The Independent Review Budget
-
-Goal: independent judgment is spent where it changes the outcome.
-
-For one reviewed state and intended-use boundary:
-
-- **Review 1:** first selected independent review, broad by default.
-- **Review 2:** separately selected focused follow-up when accepted revisions, affected dependencies, new evidence, or remaining risk warrant it.
-- **Review 3:** exceptional, separately authorized, and final, after the revision basis and dependency boundary are understood.
-
-A revision does not authorize another review. If Review 2 remains Blocking, diagnose repeated or unclear causes; return an independent clear local defect to its owner when diagnosis adds no value, rather than revise and dispatch Review 3 automatically. Workflow may start a new cycle only for a materially new artifact state and intended-use boundary. Self-review does not consume the budget.
-
-## Stop
-
-Self-review ends with supported fitness or a routed issue. Independent review ends with its report. Adjudication ends with material dispositions and an explicit next route. Do not turn optional improvement into unfinished work.

package/skills/review-artifact/references/adjudicate-artifact-review.md

@@ -1,101 +0,0 @@
-# Adjudicate Artifact Review
-
-Read this after an independent artifact review returns and before selecting what follows from its report.
-
-This reference is judgment; Review Artifact's Rules still bind. Adjudication belongs to the receiving active agent. It tests the report against the artifact, source truth, dependencies, and evidence. It is not independent review and does not inherit the reviewer's authority or judgment.
-
-## Dispose Each Material Item
-
-For every material item, choose one disposition.
-
-### Accepted
-
-State:
-
-- the supported artifact problem;
-- its consequence for the intended use;
-- whether it is Blocking or Non-blocking;
-- whether the revision basis is supported or uncertain;
-- which dependencies or contingent material it affects.
-
-### Rejected
-
-State the concrete reason: unsupported, stale, resolved, duplicate, preference-only, outside the artifact's job, or based on a source or dependency misread.
-
-### Open
-
-State:
-
-- the unresolved content, claim, or dependency concern;
-- its potential consequence for the intended use;
-- the missing evidence or owner decision.
-
-When factual evidence is missing, restate the item as a Verify Work input: load-bearing claim or condition, required observing boundary, available evidence and its limit, and the smallest evidence that could disagree.
-
-A suggested revision may help explain a finding, but it does not settle source intent, select among material alternatives, or authorize revision.
-
-After disposing the items, derive the adjudicated judgment. Do not separately accept the reviewer's overall judgment.
-
-- **Pass:** no accepted Issues or material Open items remain.
-- **Non-blocking:** only accepted Non-blocking Issues remain.
-- **Inconclusive:** a material Open item prevents judgment.
-- **Blocking:** at least one accepted Blocking Issue remains.
-
-## Use Verification Results
-
-Route a known material evidence gap through [Workflow](../../../skills/workflow/SKILL.md) to [Verify Work](../../../skills/verify-work/SKILL.md). Verification produces factual evidence; it does not revise the reviewer's report or determine the review judgment.
-
-- **Supported:** re-adjudicate the evidence gap. Do not infer Pass.
-- **Contradicted:** re-adjudicate against source truth; the result may establish an Issue, invalidate one, or expose a source conflict.
-- **Inconclusive:** keep the item Open. The adjudicated review remains Inconclusive when the gap is material.
-- **Unavailable:** keep the item Open and state why the required boundary cannot currently be observed.
-
-Select focused independent follow-up only when the new evidence still requires judgment from a separate context.
-
-## Decide Whether Revision Is Ready
-
-Revision is ready when:
-
-- the artifact's job and intended use are settled;
-- the artifact problem and consequence are supported;
-- sufficient source or decision basis exists to bound the revision;
-- affected upstream and downstream dependencies are known sufficiently;
-- the revision will not silently alter accepted content or an owner decision;
-- no material alternative or user-owned choice remains.
-
-When revision is ready, state:
-
-- the proposed revision and rationale;
-- affected locations and dependencies;
-- required reconciliation or ordering;
-- evidence or acceptance checks;
-- whether focused independent follow-up remains justified;
-- the authority state.
-
-Use existing revision authority only when it covers that result and dependency impact. Otherwise propose the revision and any warranted follow-up once, then wait. A finding, adjudication, or selected review does not authorize mutation.
-
-Actual revision returns through [Workflow](../../../skills/workflow/SKILL.md) to the artifact's owning skill. Use [Track Work](../../../skills/track-work/SKILL.md) for a Working Record, [Write Spec](../../../skills/write-spec/SKILL.md) for stable content or decision artifacts, [Write Plan](../../../skills/write-plan/SKILL.md) for a Plan, and [Handoff](../../../skills/handoff/SKILL.md) for a Handoff.
-
-Do not revise upstream authority, accepted intent, or owner decisions merely to satisfy a reviewer or obtain Pass.
-
-## Route When Revision Is Not Ready
-
-- unsettled content, strategy, or materially different revisions: [Discuss](../../../skills/discuss/SKILL.md);
-- user-owned choice or source conflict: [Decision Gate](../../../skills/decision-gate/SKILL.md);
-- unsupported or repeated failure cause: [Diagnose Failure](../../../skills/diagnose-failure/SKILL.md);
-- missing factual support: route the named claim through [Workflow](../../../skills/workflow/SKILL.md) to [Verify Work](../../../skills/verify-work/SKILL.md);
-- uncovered revision or dependency update: propose the bounded change and wait.
-
-When findings interact, upstream authority is challenged, dependency effects remain uncertain, or user input could change the revision, report a problem checkpoint and stop before selecting or executing it.
-
-## After Authorized Revision
-
-Re-verify affected load-bearing factual claims at their required observing boundaries. Then re-check source alignment, intended-use fitness, and every affected dependency before performing ordinary self-review with Review Artifact's shared kernel.
-
-Select focused independent follow-up only when accepted revisions, affected dependencies, new evidence, or remaining risk still require judgment from a separate context. Do not dispatch follow-up merely because Review 1 found an Issue or because revision occurred.
-
-If Review 2 remains Blocking, adjudicate it before acting again. Diagnose a repeated, extending, invalidating, or basis-uncertain blocker. Return an independent clear local artifact defect to its owner when diagnosis would add no useful understanding. Review 3 remains exceptional, separately authorized, and final.
-
-## Stop
-
-Stop when every material item is Accepted, Rejected, or Open; the adjudicated judgment is supported; affected dependencies and contingent material are explicit; and the next route and authority state are clear.

package/skills/review-artifact/references/independent-artifact-reviewer-contract.md

@@ -1,159 +0,0 @@
-# Independent Artifact Reviewer Contract
-
-Read this before preparing or performing a separately selected independent review of a durable artifact.
-
-This reference is a contract: the required context and the reviewer prompt are binding as written. The reviewer did not produce the reviewed artifact state. Give them the complete artifact, source truth, dependencies, and evidence needed to judge it directly. Do not provide only the producer's summary, reasoning, or change description.
-
-## Required Context
-
-Provide:
-
-- artifact path, type, exact reviewed state, and intended use;
-- accepted outcome, requirements, non-goals, and owner decisions;
-- unresolved questions and known evidence gaps;
-- the artifact-specific schema or format contract when one exists;
-- relevant code, tests, policies, ADRs, and established behavior;
-- upstream and downstream artifacts in dependency order;
-- only the review lenses material to the intended use;
-- active evidence authority: none, or each exact covered check with its expected evidence and stop condition;
-- review number and, for follow-up, prior items, adjudication, revisions, and new evidence.
-
-For an artifact package, identify upstream authority and which material remains provisional or contingent.
-
-## Reviewer Prompt
-
-```md
-# Independent Artifact Review
-
-Review an artifact state you did not produce. Inspect the complete artifact, source truth, dependencies, and evidence directly. Report without editing. The review ends with this report; do not adjudicate findings, settle owner decisions, revise anything, dispatch follow-up, or continue merely to obtain Pass.
-
-A pass is valid. Use a high evidence bar, not a high item count. Do not broaden the artifact's job or treat possible improvement as unfinished work.
-
-Use supplied and already available evidence. Do not start a missing active check unless the review contract explicitly authorizes that exact check. Otherwise report **Needs evidence** with the load-bearing claim and required observing boundary. When an exact check is covered, apply Verify Work's check-result and claim-result semantics; active evidence does not authorize revision or broaden the review.
-
-## Artifact And Intended Use
-
-- Artifact: [path]
-- Type: [working record | spec | PRD | issue | API contract | technical design | migration contract | plan | decision record | ADR | handoff | other]
-- Reviewed state: [revision, hash, or other exact identity]
-- Intended use: [decision or future action this artifact must support]
-- Dependency order: [upstream -> downstream, or standalone]
-
-## Accepted Outcome And Non-Goals
-
-- Outcome: [accepted outcome]
-- Requirements: [accepted requirements]
-- Non-goals: [intentional exclusions]
-- Owner decisions: [settled decisions or none]
-- Unresolved questions: [questions or none]
-
-## Source Truth
-
-- [code, tests, policies, ADRs, established behavior, upstream artifacts]
-
-## Evidence And Known Gaps
-
-- Supporting evidence: [evidence or none]
-- Known gaps: [gaps or none]
-
-## Review Scope
-
-- Review number: [1 | 2 | 3]
-- Material lenses: [source alignment | fitness and sufficiency | decision clarity | evidence and acceptance | behavior and failure contract | dependency integrity | scope and minimality | clarity and continuity]
-- Active evidence authority: [none | exact covered check, expected evidence, and stop condition]
-
-For Review 2 or 3:
-
-- Prior items and adjudication: [Accepted | Rejected | Open]
-- Revisions and new evidence: [bounded changes and evidence]
-- Affected dependencies: [dependencies or none]
-- Remaining risk: [narrow unresolved scope]
-
-## Judge The Artifact By Its Job
-
-- **Working Record:** accurate living task memory with recoverable slices and decisions, compact evidence pointers, and one next useful action.
-- **Spec or durable content artifact:** accepted content, behavior, boundaries, evidence, and uncertainty needed for its stated use.
-- **Plan:** an inspectable ordered strategy with scope, dependencies, assumptions, checks, and stop conditions.
-- **Decision record or ADR:** the decision, owner, alternatives, rationale, consequences, and revisit or supersession conditions.
-- **Handoff:** a point-in-time continuation package that preserves what its recipient needs without replacing live task memory.
-- **Other artifact:** its stated purpose without taking over another artifact's job.
-
-Do not require one artifact to perform another artifact's job.
-
-## Check
-
-Apply only the selected lenses:
-
-- the artifact agrees with accepted requirements, owner decisions, and live facts;
-- it contains enough for its intended use without pretending every future question is settled;
-- required, tentative, open, deferred, and superseded information cannot be confused;
-- load-bearing claims and acceptance conditions have suitable supporting or falsifying mechanisms;
-- consequential behavior, failure states, forbidden outcomes, observers, and recovery are explicit where required;
-- upstream and downstream artifacts remain consistent and provisional material is identified honestly;
-- it avoids speculative scope, unnecessary process, and duplicated information owned elsewhere;
-- a future reader can use it without transcript memory or volatile copied context.
-
-Review upstream authority before dependent artifacts. When an upstream problem invalidates downstream assumptions, mark affected material contingent rather than generating exhaustive downstream findings against an unsettled basis.
-
-Before calling something an Issue, ask:
-
-1. Does fitness for the intended use depend on content, source truth, or an owner decision that remains unsettled? If yes, use **Question**.
-2. Does fitness depend on a load-bearing claim or condition that available evidence cannot establish? If yes, use **Needs evidence**.
-3. Is there a supported artifact defect requiring revision for the intended use? Use **Blocking Issue** when the artifact cannot safely guide that use, otherwise **Non-blocking Issue** when revision can be deferred safely.
-4. Is the change merely useful beyond the intended use? Omit it by default; use **Improvement** only when materially relevant or requested.
-
-A **Needs evidence** item must identify the load-bearing claim or condition, required observing boundary, available evidence and its limit, why the gap affects intended-use fitness, and the smallest evidence that could disagree. Establish that the claim is required. Distinguish a missing observation from a supported artifact defect; check whether evidence applies to the current artifact and accepted requirement rather than a superseded version. Do not prescribe broader implementation merely to fill an evidence gap.
-
-A Blocking Issue must identify the exact location or dependency, violated source truth or artifact responsibility, evidence, concrete consequence for intended use, and revision constraints or owning activity to re-enter. Recommend a specific revision only when source intent and dependency effects support it.
-
-For Review 2 or 3, inspect only accepted revisions, affected dependencies, new evidence, and remaining risk. Do not reopen Rejected items without contradictory evidence. For each new Blocking Issue, state whether it repeats, extends, invalidates, or exposes another consequence of a prior revision; is independent; or cannot yet be related from the evidence. Report a related pattern rather than proposing another revision. Review 3 is final; do not recommend Review 4.
-
-## Determine The Judgment
-
-1. **Blocking:** at least one Blocking Issue exists.
-2. **Inconclusive:** no Blocking Issue exists, but a material Question or Needs evidence item prevents judgment.
-3. **Non-blocking:** only Non-blocking Issues remain.
-4. **Pass:** no Issues or material unresolved items remain.
-
-Improvements do not change the judgment.
-
-## Output
-
-Omit empty groups. Do not include Improvements unless they are materially relevant or explicitly requested.
-
-Review type: independent
-Review number: [1 | 2 | 3]
-Artifact: [reviewed artifact]
-Intended use: [reviewed boundary]
-Reviewed state: [state identity]
-Judgment: Pass | Non-blocking | Inconclusive | Blocking
-Reasoning: [concise evidence-backed judgment]
-Relationship to prior items (Review 2 or 3 only): [related consequence | independent defect | unclear, with evidence]
-
-### Review Items
-
-#### Issues — Blocking
-- [location or dependency, issue, violated source or responsibility, evidence, consequence, revision constraints or owning activity]
-
-#### Issues — Non-blocking
-- [location or dependency, issue, evidence, why it can be deferred]
-
-#### Unresolved — Questions
-- [question, effect on judgment, required answer]
-
-#### Unresolved — Needs evidence
-- [load-bearing claim or condition, required observing boundary, available evidence and limit, effect on intended-use fitness, smallest evidence that could disagree]
-
-#### Improvements
-- [only when materially relevant or requested: improvement, benefit, evidence]
-
-Dependencies affected: [dependencies or none]
-Contingent material: [material and upstream condition, or none]
-Evidence gaps: [unproved claims or none]
-```
-
-## Calibration
-
-Lead with the few items that can change fitness for the intended use. Prior review, artifact length, polished language, or producer confidence does not establish fitness.
-
-The report is evidence for adjudication. It is not authority over source truth, owner decisions, revisions, dependencies, or another independent dispatch. Pass, Non-blocking, Inconclusive, and Blocking are all valid exits.