@hassangameryt/freeflow 0.7.3 → 0.9.0

package/skills/launch-work/references/launch-readiness.md

@@ -1,85 +0,0 @@
-# Launch Readiness
-
-Read this before selecting risk lenses, operational evidence, rollout stages, or recovery checks. Use only the lenses relevant to the production change; this is not a universal checklist.
-
-## Identity And Ownership
-
-- Exact artifact, commit, image, configuration, migration, and target environment are known.
-- Deployment, rollout, rollback, incident, and communication owners are known where risk requires them.
-- Production permissions and credentials are available through approved channels without entering prompts, logs, or source.
-
-## Behavior And Compatibility
-
-- Accepted requirements and critical user paths have fresh evidence.
-- Public APIs, clients, schemas, feature states, and supported versions remain compatible or have an approved migration.
-- Failure, retry, idempotency, duplicate, ordering, and recovery behavior are settled for consequential operations.
-
-## Data And Migration
-
-- Authoritative source and migration ordering are explicit.
-- Backups, reconciliation, partial failure, restart, rollback, and forward-recovery behavior are proved to the required level.
-- Privacy, retention, deletion, audit, and permission obligations remain satisfied.
-
-## Security And Access
-
-- Threat-relevant changes received the required specialist or policy review.
-- Authentication, authorization, secret handling, untrusted input, dependency, network, and privilege boundaries are verified where affected.
-- Telemetry and support tooling do not expose secrets or unnecessary personal data.
-
-When Workflow selects a security-focused review, read the [security risk lens](../../review-work/references/security-risk-lens.md).
-
-## Performance And Capacity
-
-- Representative baseline and expected load are known where capacity can change.
-- Critical latency, throughput, saturation, queue, storage, and dependency limits have evidence.
-- Advance and abort criteria are relative to accepted SLOs, historical baseline, or owner-approved thresholds.
-
-Read [performance evidence](../../verify-work/references/performance-evidence.md) for readiness and improvement claims. Read [Flaky and Performance Diagnosis](../../diagnose-failure/references/flaky-and-performance-diagnosis.md) only when a regression lacks a supported cause.
-
-## Accessibility And User Experience
-
-When user interfaces change, verify the affected critical paths using the repo's design/accessibility authority and available domain tooling. Consider keyboard, focus, semantics, assistive technology, responsive behavior, loading, empty, error, and degraded states only where relevant.
-
-## Observability
-
-Start from questions operators must answer:
-
-- Is the new path being used?
-- Is it succeeding and within accepted latency/capacity bounds?
-- Why is a specific request, job, or migration failing?
-- Are data, queues, retries, and dependencies healthy?
-- Can one affected operation be correlated across components?
-
-Choose structured logs for event detail, metrics for aggregate rate/error/duration or resource saturation, and traces for cross-component paths. Keep metric dimensions bounded. Do not log secrets, tokens, full sensitive payloads, or unrestricted personal identifiers.
-
-Verify telemetry itself by inducing or observing a safe known event, finding the signal, checking fields/labels, and confirming alert/runbook routing where required.
-
-## CI/CD And Environment
-
-- The pipeline and target environment execute the checks required by this change.
-- Generated artifacts are promoted consistently rather than rebuilt differently without approval.
-- Environment drift, secrets, migrations, and deployment ordering are inspected.
-- A failed or ambiguous pipeline step has a known retry/reconciliation contract.
-
-Provider-specific workflow syntax belongs to the repo or platform skill.
-
-## Rollout And Recovery
-
-Define:
-
-```text
-Stage / cohort:
-Action:
-Expected signals:
-Advance if:
-Hold if:
-Abort or recover if:
-Verification:
-Owner:
-```
-
-Rollback must account for code, data, schema, messages, clients, caches, and external side effects. Test or rehearse the recovery path to the level warranted by risk.
-
-## Temporary Machinery
-
-Flags, adapters, dual writes, elevated logging, launch dashboards, temporary permissions, and support procedures need an owner and cleanup checkpoint. Route compatibility removal through [Migration Work](../../migration-work/SKILL.md).

package/skills/migration-work/SKILL.md

@@ -1,115 +0,0 @@
----
-name: migration-work
-description: Use when replacing an existing software or data path and moving its consumers, state, or traffic safely.
----
-
-# Migration Work
-
-Move consumers, state, or traffic to an accepted replacement without losing compatibility, evidence, or recovery options.
-
-A replacement existing does not prove that consumers moved. A migration unit may be complete while the old path remains under an accepted support contract. Removal is a separate claim with separate evidence and authority.
-
-## Establish Authority And Scope
-
-Loading this skill, discussing a migration, or approving a general implementation Plan does not authorize migration, deprecation, cutover, destructive cleanup, or removal. Execute only the stages and units explicitly requested or separately approved.
-
-Use [Decision Gate](../decision-gate/SKILL.md) when any of these remain unresolved:
-
-- whether the old behavior should be maintained, deprecated, or removed;
-- advisory versus compulsory migration, deadlines, or support windows;
-- compatibility, public API, data conversion, downtime, permissions, billing, security, privacy, or data-loss behavior;
-- irreversible cutover, destructive cleanup, or rollback limits.
-
-Do not manufacture a migration because code looks old. Inspect ownership, supported consumers, runtime use, source truth, incidents, maintenance cost, and current value.
-
-When replacement behavior, interfaces, ownership, or failure semantics remain unsettled, return that evidence to [Workflow](../workflow/SKILL.md). Use [Discuss](../discuss/SKILL.md) for open direction, [Design for Depth](../design-for-depth/SKILL.md) for design-bearing boundaries, and [Write Spec](../write-spec/SKILL.md) when accepted migration behavior needs a durable contract.
-
-## Define The Migration Contract
-
-Before choosing migration shape or units, compatibility, cutover evidence, rollback or forward recovery, or removal proof, read [the migration lifecycle](references/migration-lifecycle.md). Use only the stages required by the accepted migration; do not force every migration through one sequence.
-
-Before moving anything, establish:
-
-```text
-Old contract and current value:
-Replacement contract and known differences:
-Consumers / callers / data / traffic:
-Compatibility promise and support window:
-Migration unit and ordering:
-State written during transition:
-Verification for each unit:
-Rollback or forward-recovery path:
-Removal proof:
-Owner decisions and stop conditions:
-Approved stages and scope:
-```
-
-Treat undocumented observable behavior as a possible consumer dependency until evidence says otherwise. Do not preserve every quirk automatically; surface consequential differences for decision.
-
-## Prepare The Replacement
-
-When an additive or replacement stage is approved:
-
-- prove the replacement through the real caller path or interface;
-- keep old and new ownership explicit;
-- add adapters, flags, aliases, translation, or dual reads/writes only when the migration contract requires them;
-- give temporary compatibility machinery an owner, purpose, failure behavior, exit condition, and removal evidence;
-- do not add features to the old path unless required for safety or an explicit support decision.
-
-If compatibility machinery starts spreading caller knowledge, public states, or exceptions, return the structural evidence to Workflow rather than building a second permanent system.
-
-An emergency migration without a viable replacement may be necessary for security or data safety, but it requires explicit owner direction, bounded impact, and a documented failure and recovery contract.
-
-## Move Bounded Units
-
-Move one accepted consumer, cohort, traffic segment, configuration set, or data partition at a time.
-
-For each unit:
-
-1. capture the relevant pre-migration state or baseline;
-2. apply the migration through the intended path;
-3. verify behavior, data, errors, permissions, and operational signals at the required boundary;
-4. confirm rollback or forward recovery remains possible;
-5. preserve evidence and account for remaining units.
-
-Code search alone cannot prove completion when runtime, external, dormant, generated, offline, or independently deployed consumers may exist.
-
-Stop and return evidence to Workflow when replacement behavior diverges, unknown consumers appear, a new owner decision is required, data cannot be reconciled, recovery assumptions fail, compatibility machinery spreads, or the next safe unit is unclear. Preserve completed units; do not restart the whole migration automatically.
-
-## Remove The Old Path
-
-Remove or disable the old path only when that stage is explicitly authorized and the accepted removal proof is satisfied.
-
-Check, as relevant:
-
-- supported active and dormant consumers are accounted for;
-- runtime, telemetry, dependency, or owner evidence supports the absence claim;
-- data and configuration are reconciled;
-- compatibility, support-window, observation, and recovery obligations have ended;
-- old code, adapters, flags, tests, docs, alerts, dashboards, secrets, jobs, and configuration are classified for removal or retention;
-- the replacement remains verified with the old path disabled or absent.
-
-Do not delete source truth or historical migration evidence merely to make searches clean. If current docs or contracts would become false, return them to Workflow and update them only when they are included in the approved migration or removal scope. Preserve durable history where repository policy requires it.
-
-## Verification And Review
-
-Read [Verify Work](../verify-work/SKILL.md) for each migration-unit, compatibility, reconciliation, and absence claim. “The new path passes” does not prove “the old path is unused.” Missing telemetry is unavailable evidence, not zero use.
-
-Return the need for broader judgment to Workflow when the migration changes public contracts, moves consequential data, crosses security or privacy boundaries, affects many consumers, or performs irreversible cutover or cleanup. Workflow selects any independent review; this skill supplies the migration boundary and evidence.
-
-Use [Release Work](../release-work/SKILL.md) when the replacement must be published as a versioned artifact. Use [Launch Work](../launch-work/SKILL.md) when migration stages change production traffic, data, configuration, or exposure.
-
-## Report Completion Precisely
-
-Report:
-
-- approved migration scope and completed units;
-- replacement and compatibility status;
-- remaining consumers, state, traffic, or observation windows;
-- verification and operational evidence;
-- rollback or forward-recovery status;
-- legacy components removed and deliberately retained;
-- unresolved decisions, uncertainty, and residual risk;
-- next approved unit, removal boundary, deferment, or stop route.
-
-A migration unit is complete when its accepted consumers or state moved and its required evidence holds. A scoped migration may complete while the legacy path remains under an accepted support contract. Removal is complete only when its separate authorization and proof are satisfied.

package/skills/migration-work/references/migration-lifecycle.md

@@ -1,82 +0,0 @@
-# Migration Lifecycle
-
-Read this before choosing migration shape or units, compatibility, cutover evidence, rollback or forward recovery, or removal proof.
-
-## Migration Shapes
-
-- **Code or API:** add the new contract, migrate callers in bounded groups, remove the old contract.
-- **Configuration:** support old and new forms temporarily, migrate stored and generated config, reject the old form only after compatibility obligations end.
-- **Traffic:** route bounded cohorts to the new path, compare behavior and operational signals, expand only when advance criteria hold.
-- **Data:** expand schema, backfill or transform, move reads/writes, reconcile, then contract the old representation.
-- **Dependency:** introduce the replacement, verify compatibility at owning seams, migrate packages or consumers, remove the old dependency and transitive assumptions.
-- **Feature:** define replacement or removal behavior, migrate users and documentation, observe usage, then remove code and operational surfaces.
-
-Do not force every migration into the same sequence. Choose the smallest shape that preserves accepted compatibility, safety, and evidence. A scoped migration may stop after its accepted units move while the old contract remains under a support window; removal remains a separate stage and claim.
-
-## Consumer Inventory
-
-Possible evidence includes:
-
-- static references and dependency graphs;
-- runtime traffic, logs, metrics, traces, or audit records;
-- generated clients, plugins, scripts, jobs, and configuration;
-- external teams, independently deployed services, offline clients, and dormant accounts;
-- package download or version-support data;
-- explicit owner attestations where observation is impossible.
-
-Classify unknowns. Missing telemetry is unavailable evidence, not zero usage.
-
-## Compatibility Machinery
-
-Adapters, aliases, dual reads/writes, translation, flags, and shims are migration tools, not automatically permanent architecture.
-
-For each temporary mechanism, record:
-
-```text
-Purpose:
-Consumers protected:
-Observable differences:
-Owner:
-Exit condition:
-Removal evidence:
-Failure behavior:
-```
-
-If the shim becomes harder to remove with each consumer, reconsider the compatibility boundary and ownership before adding another exception.
-
-## Data Movement
-
-Before moving data, settle:
-
-- authoritative source during each phase;
-- idempotency and restart behavior;
-- duplicate, partial, invalid, and late-arriving records;
-- read/write ordering and reconciliation;
-- privacy, retention, permissions, and audit requirements;
-- rollback versus forward-only recovery;
-- backup, restore, and destructive-cleanup proof.
-
-A reversible schema change does not imply reversible data semantics.
-
-## Advance, Hold, Roll Back
-
-Define evidence-relative criteria rather than universal percentages or time windows:
-
-- **Advance:** required behavior and operational signals remain within accepted bounds.
-- **Hold:** evidence is incomplete, variance is unresolved, or a bounded investigation is needed.
-- **Roll back or recover forward:** data safety, security, compatibility, or accepted service behavior is violated.
-
-The owner decides consequential thresholds and acceptable degradation.
-
-## Removal Proof
-
-A removal claim should combine the strongest available evidence:
-
-1. no supported consumer still requires the old contract;
-2. runtime or owner evidence covers consumers static analysis cannot see;
-3. state and configuration have been reconciled;
-4. compatibility and rollback obligations have ended;
-5. the replacement remains verified with the old path disabled or absent;
-6. removal does not erase required history, audit evidence, or recovery material.
-
-If a consumer class cannot be observed, state the uncertainty and obtain the owning decision before destructive removal.

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,142 +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.
-
-## Choose The Role And Intended Use
-
-- **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.
-
-Writing or revising a Spec or Plan does not automatically require independent review. Select that route 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; it cannot adjudicate its own findings or become the revising agent within that role.
-
-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
-
-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. Check both directions:
-
-- Has the artifact introduced stronger obligations than the accepted outcome needs?
-- Has it omitted accepted changes or retained a superseded implementation baseline?
-
-An experiment can establish a fact without selecting it for production. Conversely, an implementation Plan cannot ignore later accepted learning merely because its older version was reviewed.
-
-If upstream content is unresolved or contradictory, mark dependent material contingent. Do not generate exhaustive downstream findings against an unsettled premise or rewrite the upstream requirement to match the artifact.
-
-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
-
-- **Working Record:** accurate current task memory, recoverable decisions and work, evidence limits, provisional remaining route, 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 that the artifact intentionally preserves and whose answer is unnecessary for its current use.
-
-## Apply The Shared Kernel
-
-Use only lenses capable of changing 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 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
-
-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 artifact defect. Check which source/check state a reported pass examined and whether later changes reduced acceptance or invalidated its applicability; 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
-
-Apply the kernel silently to the artifact you produced after 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:
-
-1. return to the authoring activity and revise it;
-2. reconcile affected dependencies within authority;
-3. re-verify affected factual claims;
-4. repeat source alignment and affected review lenses once.
-
-Do not settle a user decision or revise upstream intent merely to make the artifact consistent. 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 automatically.
-
-## Perform A Selected Independent Review
-
-Before preparing or performing it, read [Independent Artifact Reviewer Contract](references/independent-artifact-reviewer-contract.md).
-
-Use available evidence. Run a missing active check only when review authority covers that exact check; otherwise report Needs evidence. Apply Verify Work to covered checks while retaining ownership of the fitness judgment.
-
-Inspect and report without edits, owner decisions, selection among materially different revisions, adjudication, or another review dispatch. The independent 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. Do not continue merely to obtain Pass.
-
-## Adjudicate Without Inheriting The Verdict
-
-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.
-
-Derive the overall judgment from those dispositions rather than separately accepting the reviewer's conclusion. Findings do not authorize revisions.
-
-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
-
-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 automatically authorize another review. If Review 2 remains Blocking, diagnose repeated or unclear causes; return an independent clear local artifact defect to its owner when diagnosis adds no value. Do not automatically revise and dispatch Review 3.
-
-Do not request Review 4. A different reviewer, renamed use, or local revision does not reset the budget. Workflow may establish 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 review until Pass, turn optional improvement into unfinished work, or present artifact fitness as acceptance, implementation, or execution authority.