aimship 0.1.0-preview.19 → 0.1.0-preview.21

package/skills/aimship/references/recovery.md

@@ -9,24 +9,24 @@ A path move requires the provided new location and identity evidence, not a disk
 A tool/session/active-installation mismatch stops new stage advancement. Run bind through the stable installation launcher and read the returned fixed-version core and CLI help. Use that bound tool and protocol, not cached metadata from another executable. Preserve unfinished work and actual decisions; do not change state versions by hand or invent approvals. If the conversation cannot reliably refresh, provide a manual continuation prompt; do not open a new conversation automatically.
 
 
-Compatible delivery protocols can continue under the current bound software. Legacy 17/18 states map precisely to protocol 1; unknown legacy versions or unsupported protocols stay blocked. Read/check/resume and render do not adopt state metadata; a normal revision-checked save records the current tool/protocol without rewriting documents or invalidating approvals of unchanged content. Do not downgrade assuming the old tool can read newer saved metadata. An installer risk confirmation permits only the software switch, never an unsupported delivery write.
+This release uses schema 5 / delivery protocol 2. Schema 4 / protocol 1 deliveries cannot continue under its new domain rules; legacy 17/18 remain identified as protocol 1, not silently remapped. Preserve those materials and use their supported tool to finish before upgrading, or start a new delivery when appropriate. There is no automatic document/state migration or parallel legacy execution path. Within a supported protocol, software updates preserve unchanged content approvals. Do not edit version fields to bypass compatibility or assume a downgrade can read newer records. An installer risk confirmation permits only the software switch, never an unsupported delivery write.
 
 Installation and data are separate. Explicit install manages product-owned files and AI-tool entries. Preserve user customizations and unrelated same-name skills; report the exact conflict. Uninstall retains delivery materials, customization and necessary configuration. Recovery retains a bounded previous installation, not every runtime forever. Consult the CLI help for implemented operations; do not bypass checks with raw state edits to obtain a success result.
 
 ## State and view recovery
 
 
-State is authoritative for stages; status is generated. JSON may have saved while view generation failed: use returned revision and render, never repeat update. Read/check/resume never repair implicitly. Inspect changed registered documents even when view revision matches. render --preserve-edits retains a modified status before replacing it; interpret intent and update the formal authority separately.
+State is authoritative for control facts; status and the finite plan/testing/review sections are generated views. JSON may have saved while view generation failed: use returned revision and render, never repeat update. Read/check/resume never repair implicitly. Inspect changed registered documents even when view revision matches. render --preserve-edits retains modified generated content before replacing it; interpret intent and update the formal authority separately. Missing/duplicate generated sections or a conflict with immutable approval evidence require the reported repair, not an automatic old-document conversion.
 
 Follow [document review](document-review.md) for saved review stops, approval history, exact content versions, affected dependency re-review and current document checks. Read/resume never infer approval from done or create a new user decision.
 
 ## Session boundary and completion
 
-Use the core’s session interaction. Locate the actual delivery before reading; an explicit path or trustworthy unique binding is necessary. Check deliveryId when supplied, current approval fingerprints, current inputs and unfinished side effects; never treat an old continuation prompt as authority. Pending review remains pending. A session suggestion is not a blocker; a request to continue here uses the same saved work without a new approval. No automatic sessions or clipboard actions.
+Use the core’s session interaction. Locate the actual delivery before reading; an explicit path or trustworthy unique binding is necessary. Check deliveryId when supplied, current approval fingerprints, current inputs and unfinished side effects; never treat an old continuation prompt as authority. Pending review remains pending. A session suggestion is not a blocker; ordinary continuation uses the same saved work without a new approval. After the last implementation batch, however, starting overall review in that session requires explicit authorization for that responsibility, as described in the core. No automatic sessions or clipboard actions.
 
 Current deliveries require the document approval and delivery policies. Their recorded outcomes, actual decisions and execution history remain separate from ordinary business numbering.
 
-## Early initialization and schema 4
+## Early initialization and schema 5
 
 New initialization saves the selected language and location basis and may have only .aimship/init.md, .aimship/state.json and status.md; technical conditions may be unknown, while the endpoint defaults to standard delivery unless explicitly limited. Missing PRD at this point is normal. Read/check/resume use the same early-state rules; do not fill placeholders or infer non-applicability to clear warnings. Register the real draft when formed and retain the existing approval stops.
 

package/skills/aimship/references/review-method.md

@@ -0,0 +1,7 @@
+# Shared review method
+
+Fix the reviewed object first: requirements/design/plan basis, repositories, commit plus relevant differences/untracked files, or document sections/digests. Use the [shared project context](core.md#project-context-and-decisions) and inspect only the commissioned scope and its dependencies. Review actual correctness against requirements/design/contracts, relevant conventions, logic, state, transaction/consistency and failure paths as applicable. Neither copying the design nor compiling proves correctness; review is separate from executing the testing plan.
+
+Record a REV in review.md with scope/object, assessment and findings. A finding gives impact/severity, file/section/symbol, concrete problem, disposition and repair/recheck reference. If there are no findings, say so briefly; do not emit an empty issue table or implementation/test-command transcript. Reference existing evidence where it supports the conclusion.
+
+Keep historical REV conclusions for their original objects. A passing recheck names the repaired object and explicitly references the conclusion it replaces; a failed or unexecuted check stays failed or unknown. Submit the review facts and coverage through the state tool; its generated current section identifies the effective result and outstanding review references. Keep the finding explanations, repair dispositions and historical REV conclusions in AI-maintained sections, rather than hand-maintaining a second current-result table or competing old instructions. Existing document-content approvals remain separate from code-review records.

package/skills/aimship/references/reviews/batch.md

@@ -0,0 +1,21 @@
+# Review the current batch
+
+## Inputs
+
+The current B/TASK definitions, implemented run/object, applicable requirements/design/contracts and any repair/check evidence.
+
+## Goal and scope
+
+Examine this batch and its necessary interfaces before another business batch begins. This is part of the authorized implementation work unit.
+
+## Actions
+
+Apply the [shared review method](../review-method.md). Keep repairs inside the current business batch: record a new repair run with the same batchId and prior result basis, preserve completed implementation checkpoints, and save a separate review/recheck. A failed batch is not a new implementation batch. Repair findings within the existing commission and recheck the changed object; route requirement/design changes or missing permission to their actual decision. Do not expand a batch review into full formal verification or a repository-wide rewrite.
+
+## Outputs and result
+
+A batch REV with reviewScope: batch, the stable batchId, reviewOf naming the actual implementation/repair runs and the exact objectKey. Submit its result through the state tool. The generated plan/review sections show the current result; keep findings and repair/recheck details in this REV, not copied into plan/testing.
+
+## Completion and stop
+
+Keep implementation and review facts separate. Continue authorized repair/recheck inside this batch; report and stop after its passing review, or at an actual unresolved dependency. Next-batch continuation remains a user boundary. Merely having one batch does not silently replace an overall review.

package/skills/aimship/references/reviews/overall.md

@@ -0,0 +1,21 @@
+# Review the whole change
+
+## Inputs
+
+The current requirement/design/contract/plan, all completed batches and repairs, their passing reviews, and the actual combined object.
+
+## Goal and scope
+
+Find cross-batch consistency, shared-rule and integration defects that individual batch reviews cannot establish. An explicit overall-review request commissions review, not automatic full testing or deployment.
+
+## Actions
+
+Apply the [shared review method](../review-method.md) to the combined scope, including repair changes. Examine cross-batch connections, requirement/design/contract consistency and actual logic, transactions/data consistency, state transitions and failure/exception paths where relevant. Check whether the approach is correct in the actual project, not only whether code copied the design. Route a material design defect back to its real decision and review affected changes; do not expand into unrelated historical cleanup. Reference local checks without claiming formal runtime verification.
+
+## Outputs and result
+
+An independent overall REV with reviewScope: overall, reviewOf covering all current implementation/repair runs and the combined objectKey. Preserve earlier REV facts and name the exact reviewed basis. This is the existing overall-review stage, not another main stage.
+
+## Completion and stop
+
+Save the overall conclusion and concrete next action, then stop. A passing overall review hands over the reviewed object, actual test-environment preparation and formal verification scope for subsequent authorized execution; it does not deploy or run the tests. A failing review retains its findings and awaits the actual repair work/decision, without inventing a test result.

package/skills/aimship/references/reviews/recheck.md

@@ -0,0 +1,21 @@
+# Recheck repaired work
+
+## Inputs
+
+The original REV/findings, actual repair basis, changed implementation object and applicable previous review coverage.
+
+## Goal and scope
+
+Determine whether those findings are resolved and whether the repair creates related defects; preserve the original batch or overall review responsibility.
+
+## Actions
+
+Apply the [shared review method](../review-method.md). Examine the repair and affected dependencies, not an uncommissioned full verification suite. Record open/deferred issues honestly. If the original review was overall, retain overall scope and cover the complete current implementation object.
+
+## Outputs and result
+
+A new REV with the actual reviewOf coverage and historyResultRefs pointing to the superseded review result. Keep old findings and attach the disposition/rechecked object. A correction records a new implementation run with workType: repair, the same batchId where applicable and the actual repairOf/history result basis; completed checkpoints and the failed REV stay intact. Independent overall repair may have no batchId, but must retain the overall responsibility and be covered by the overall recheck. Repair is not a new business batch.
+
+## Completion and stop
+
+A batch recheck completes the batch work unit and stops there. An overall recheck saves its conclusion and stops before formal verification. Unresolved dependencies remain explicit; a new REV without actual examination cannot resolve a failure.

package/skills/aimship/references/routing.md

@@ -0,0 +1,16 @@
+# Route the current request
+
+The user activates one Aimship entry. Read the bound core, this routing guide and only the selected stage contract; modules organize instructions, not agents or isolated execution contexts. No host-specific nested Skill-call API is assumed.
+
+| Intent/current stop | Route and scope |
+| --- | --- |
+| New concrete request | Preserve the commission and locate/create the intended delivery using core initialization; begin requirement work. |
+| Continue a known delivery | Read its identity/state/current materials. Resume pending approval, clarification or unfinished effects before selecting subsequent work. |
+| A specified stage | Match the request to the saved arrangement and actual scope. Check prerequisites and current-content approvals; record a changed/limited commission where actually requested. A stage name is not permission to bypass its inputs. |
+| Implement the next authorized batch | Load [implement](stages/implement.md). Its work unit includes local checks, batch review and authorized repair/recheck; save separate internal runs, then stop at batch completion. |
+| Review | Load the [review dispatcher](stages/review.md) and its batch/overall/recheck module. The last batch stops with an overall-review handoff; recommend a new session, or continue overall review here only when explicitly authorized. Overall review alone does not commission full testing. |
+| Verify | Load [verify](stages/verify.md) after passing overall review; use the agreed coverage/groups and actual execution conditions. |
+
+Each stage contract has inputs, goal/scope, actions, outputs/result and completion/stop. Core owns the shared lifecycle; [document review](document-review.md), [source/change flow](sources-and-changes.md), [recovery](recovery.md) and [document patterns](document-patterns.md) own their respective shared rules. Do not copy the whole core into each module or load every stage on every turn.
+
+At a genuine ambiguous goal/location/scope, clarify only that gap. Module routing grants no new engineering permission, automation, deployment or approval.

package/skills/aimship/references/sources-and-changes.md

@@ -34,7 +34,7 @@ The agent preserves the necessary formally adopted versions under `source/`; the
 - Retain the adopted PRD, prototype, handover notes or images, plus HTML/Markdown images, styles, scripts and other resources needed to read or operate that adopted version. Do not copy unrelated workspace files. Background material that is only consulted need not be imported as a whole.
 - In the existing adoption evidence referenced by basisRef, or the current PRD when authoring it, identify the original location, retained version/path and version or digest, adopted scope, and any missing resources or reading limits. An unpinned mutable URL is insufficient evidence. If access or tools prevent retention, report the precise gap and hold conclusions that require it; never claim the adopted set is complete.
 - Keep `source/` versions read-only as adopted evidence. Name the actual editable document or prototype before revising it. New formal requirements use `prd.md`; a newly authored HTML prototype uses `prototype/index.html`. An external original is editable only when explicitly authorized; a retained source copy does not become that editable authority by default.
-- When adopting a new PRD version or replacing it with an editable iteration PRD, retain the previous file as kind source, register the new current kind prd and update goalRef with the actual decision. Keep prior result references in the existing requirement run, record the CHG impact and re-review affected work; the previous approval does not approve the new content. Do not overwrite the earlier adopted version or silently synchronize either direction. Preserve the origin-to-version mapping so there is one clear current basis.
+- When adopting a new PRD version or replacing it with an editable iteration PRD, retain the previous file as kind source, register the new current kind prd and update goalRef with the actual decision. Preserve the previous requirement run and result references, record the new work and CHG impact, and re-review affected work; the previous approval does not approve the new content. Do not overwrite the earlier adopted version or silently synchronize either direction. Preserve the origin-to-version mapping so there is one clear current basis.
 
 The CLI checks registered paths, artifacts and review evidence; it does not import materials, discover every asset dependency or prove a snapshot is complete. Normal business evidence belongs in .aimship/evidence/; installation diagnostics and repeated state returns belong in product-maintainer validation, not the delivery.
 

package/skills/aimship/references/stages/contract.md

@@ -1,27 +1,25 @@
 # Define interfaces and independent SQL
 
-## Basis
+## Inputs
 
-Read the current requirements, technical design and existing engineering contracts.
+Read the current requirements, technical design, relevant current interfaces/database structures and applicable engineering contracts/conventions, using the [shared project context](../core.md#project-context-and-decisions).
 
-## Work and result
+## Goal and scope
 
-Update/reuse the authoritative HTTP OpenAPI when applicable; create a delivery-local OpenAPI only if the engineering authority is absent. Specify operations, schemas, errors, compatibility and consumer expectations. Use appropriate formats for messages/non-HTTP interfaces. Link design and test requirements.
-
-## Continue when
+Make applicable interface and database changes unambiguous after the technical design, without inventing an interface for SQL-only work.
 
-The cooperating parties have an unambiguous applicable contract consistent with the current requirements/design. Select this responsibility for interface or database changes; omit it only when neither applies. SQL-only work does not invent an interface artifact.
+## Actions
 
-## Decisions and blockers
+Update/reuse the authoritative HTTP OpenAPI when applicable; create a delivery-local OpenAPI only if the engineering authority is absent. Specify operations, schemas, errors, compatibility and consumer expectations. Use appropriate formats for messages/non-HTTP interfaces. Link design and test requirements.
 
-A breaking interface/compatibility decision needs its proper authority. Missing consumers or schemas remain stated gaps, not fabricated agreements.
+Investigate accessible consumer/schema facts and reconcile this change with the current contract and applicable conventions. A breaking interface/compatibility decision needs its proper authority. Unknowns that affect the actual agreement remain stated gaps; unrelated old contract problems do not become this delivery’s cleanup scope.
 
-Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.
+## Outputs and result
 
-## Artifact contract
+Use openapi.yaml or the registered authoritative contract when interfaces apply. Database changes produce independent database.sql for one target, or database-<id>.sql per target, with target/dialect/version/schema basis/conditions and ordered requirement/design references. Review each file individually after technical design approval and before test cases. Do not execute SQL or modify engineering migrations without explicit authorization.
 
-Use openapi.yaml or the registered authoritative contract when interfaces apply. Database changes produce independent database.sql for one target, or database-<id>.sql per target, with target/dialect/version/schema basis/conditions and ordered requirement/design references. Review each file individually after technical design approval and before test cases. Do not execute SQL or modify engineering migrations without explicit authorization. Follow [document patterns](../document-patterns.md) and the single [artifact map](../artifact-map.json). Keep this run independent even when its document is shared. New runs need a precise result location; adopted work is not a newly executed stage.
+## Completion and stop
 
-## Human document review
+The cooperating parties have an unambiguous applicable contract consistent with the current requirements/design. Select this responsibility for interface or database changes; omit it only when neither applies. SQL-only work does not invent an interface artifact.
 
-Apply [document review](../document-review.md): generate → self-check → present the concrete document entry, current review status and focus → wait. Record explicit user approval of this version/content, then follow the core session interaction: stop at this stage boundary; suggest a new session only at a major work boundary, and continue here when requested. Approval and continuation may be expressed together. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.
+Self-check the selected outputs and stop for their [current-content review](../document-review.md); unchanged supplied inputs follow the shared adoption rules. Production done is separate from approval.

package/skills/aimship/references/stages/diagnose.md

@@ -1,29 +1,27 @@
 # Investigate cause or feasibility
 
-## Basis
+## Inputs
 
-Read reported symptoms, expected behavior, relevant code/material and reproducible evidence.
+Read reported symptoms, expected behavior, relevant code/material and reproducible evidence, using the [shared project context and decisions](../core.md#project-context-and-decisions).
 
-## Work and result
+## Goal and scope
 
-Investigate within authorized objects. Record observations, reproduction or supporting evidence, probable/established causes and remaining uncertainty. Keep incidental behavior changes out of a refactor.
-
-## Continue when
+Investigate the commissioned uncertainty and distinguish confirmed causes, hypotheses and missing evidence.
 
-The investigation goal is met, or the inability to determine a cause and a concrete next step are accurately stated. A hypothesis is not a confirmed root cause.
+## Actions
 
-## Decisions and blockers
+Investigate within authorized objects. Record observations, reproduction or supporting evidence, probable/established causes and remaining uncertainty. Keep incidental behavior changes out of a refactor.
 
 If the apparent small fix expands into behavior or scope changes, explain the impact before dependent implementation.
 
-Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.
+## Outputs and result
 
-## Artifact contract
-
-Use diagnosis.md. Preserve the ordinary template headings and section order. Follow [document patterns](../document-patterns.md) and the single [artifact map](../artifact-map.json). Keep this run independent even when its document is shared. New runs need a precise result location; adopted work is not a newly executed stage.
+Use diagnosis.md.
 
 Only a commissioned independent investigation produces diagnosis.md. Known-cause bugs and normal development debugging stay within their current stage. Record an arrangement change before adding a mid-delivery investigation.
 
-## Human document review
+## Completion and stop
+
+The investigation goal is met, or the inability to determine a cause and a concrete next step are accurately stated. A hypothesis is not a confirmed root cause.
 
-Apply [document review](../document-review.md): generate → self-check → present the concrete document entry, current review status and focus → wait. Record explicit user approval of this version/content, then follow the core session interaction: stop at this stage boundary; suggest a new session only at a major work boundary, and continue here when requested. Approval and continuation may be expressed together. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.
+Self-check the selected outputs and stop for their [current-content review](../document-review.md); unchanged supplied inputs follow the shared adoption rules. Production done is separate from approval.

package/skills/aimship/references/stages/frame.md

@@ -1,25 +1,25 @@
 # Clarify the problem
 
-## Basis
+## Inputs
 
 Read the original request, background, constraints and available evidence.
 
-## Work and result
+## Goal and scope
 
-Establish the problem, intended outcome, non-goals and assumptions worth checking. Separate known facts from hypotheses; a short section in requirements is enough.
-
-## Continue when
+Clarify the concrete problem, intended endpoint and the next requirement work without inventing an implementation commission.
 
-The commissioned exploration has a clear objective and its uncertainty is visible. Do not force this stage when the goal is already clear.
+## Actions
 
-## Decisions and blockers
+Establish the problem, intended outcome, non-goals and assumptions worth checking. Separate known facts from hypotheses; a short section in requirements is enough.
 
 A missing business objective or incompatible expected outcomes needs a user decision; independent evidence gathering may continue.
 
-Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.
+## Outputs and result
+
+Use the selected PRD requirement entry. For a new PRD preserve the ordinary template headings and section order; a complete adopted PRD retains its own outline.
 
-## Artifact contract
+## Completion and stop
 
-Use the selected PRD requirement entry. For a new PRD preserve the ordinary template headings and section order; a complete adopted PRD retains its own outline. Follow [document patterns](../document-patterns.md) and the single [artifact map](../artifact-map.json). Keep this run independent even when its document is shared. New runs need a precise result location; adopted work is not a newly executed stage.
+The commissioned exploration has a clear objective and its uncertainty is visible. Do not force this stage when the goal is already clear.
 
-After completing and self-checking this stage, save its result and current stop. Report the artifacts and next action, then stop. Wait for continuation without adding a document approval; final handoff instead awaits the actual acceptance decision. Failures remain unresolved until repaired and checked.
+Save the actual result, then stop at this stage boundary. Use the [shared lifecycle](../core.md#state-and-stopping) for continuation.

package/skills/aimship/references/stages/handoff.md

@@ -1,27 +1,27 @@
 # Deliver against the goal
 
-## Basis
+## Inputs
 
 Read the current goal/PRD, explicit goal revisions, deliverables, applicable review/verification and unresolved work.
 
-## Work and result
+## Goal and scope
 
-Provide deliverable links, use/check instructions, actual validation scope and limits, goal changes and unfinished items. Identify each actual code checkout/worktree, branch and commit when available, relevant uncommitted changes, and whether integration/merge is still pending (including target/dependencies if known). A completed branch is not a merged change. Independently record goal achievement, user acceptance, merge and deployment. Save next-step context when incomplete.
-
-## Continue when
+Compare actual delivered and verified results to the agreed goal and obtain the real acceptance decision.
 
-The report honestly matches the current commissioned endpoint. Complete the delivery only when its actual completion criteria are satisfied. A user-authorized partial endpoint preserves the old goal and remaining work.
+## Actions
 
-## Decisions and blockers
+Provide deliverable links, use/check instructions, actual validation scope and limits, goal changes and unfinished items. Identify each actual code checkout/worktree, branch and commit when available, relevant uncommitted changes, and whether integration/merge is still pending (including target/dependencies if known). A completed branch is not a merged change. Independently record goal achievement, user acceptance, merge and deployment. Save next-step context when incomplete.
 
 Showing results does not revise the endpoint. Required blocked verification means incomplete acceptance, even when code is ready. Small later corrections reopen with preserved closure; independent goals create related deliveries.
 
-Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.
+## Outputs and result
 
-## Artifact contract
-
-Use handoff.md. Preserve the ordinary template headings and section order. Follow [document patterns](../document-patterns.md) and the single [artifact map](../artifact-map.json). Keep this run independent even when its document is shared. New runs need a precise result location; adopted work is not a newly executed stage.
+Use handoff.md.
 
 Use the derived completion assessment alongside goal and acceptance. A user-authorized scope without cases/verification may be finished as an explicitly untested partial handoff, never standard complete delivery. No next-session prompt is needed at the final endpoint.
 
-After completing and self-checking this stage, save its result and current stop. Report the artifacts and next action, then stop. Wait for continuation without adding a document approval; final handoff instead awaits the actual acceptance decision. Failures remain unresolved until repaired and checked.
+## Completion and stop
+
+The report honestly matches the current commissioned endpoint. Complete the delivery only when its actual completion criteria are satisfied. A user-authorized partial endpoint preserves the old goal and remaining work.
+
+Save the actual goal comparison and stop for the acceptance decision; a handoff document alone is not acceptance.

package/skills/aimship/references/stages/implement.md

@@ -1,27 +1,27 @@
-# Implement one batch
+# Implement the current work unit
 
-## Basis
+## Inputs
 
-Read this run’s scope, current requirements/design/contracts, relevant repository instructions and pre-existing changes.
+Read this run’s scope, current approved requirements/design/contracts, its registered B/TASK definitions and pre-existing changes. Use the [shared project context](../core.md#project-context-and-decisions) and applicable repository instructions.
 
-## Work and result
+## Goal and scope
 
-Before entering implementation, or when a code working directory changes, apply the [recorded-overlap check](../core.md#independent-deliveries-and-recorded-overlap). Reuse an existing user-selected sequence or isolated checkout; unresolved same-checkout writing overlap holds the affected code writes, not independent design work. Complete this batch using the existing engineering stack. Write planned test code where appropriate. Preserve user work and external sources. Record deviations and route semantic changes through the current authority, including SQL when affected. Engineering commands use the repository working directory.
-
-## Continue when
+Complete one authorized business batch or repair, including necessary local checks and the matching review/recheck; do not begin another batch.
 
-The planned batch is implemented and known deviations are resolved or explicitly routed. After saving and the user’s continuation, move to this batch’s review; running a complete test suite is not a new batch gate.
+## Actions
 
-## Decisions and blockers
+Before entering implementation, or when a code working directory changes, apply the [recorded-overlap check](../core.md#independent-deliveries-and-recorded-overlap). Reuse an existing user-selected sequence or isolated checkout; unresolved same-checkout writing overlap holds the affected code writes, not independent design work. Complete this batch using the existing engineering stack. Write planned test code where appropriate. Preserve user work and external sources. Record deviations and route semantic changes through the current authority, including SQL when affected. Engineering commands use the repository working directory.
 
 Expanded external behavior, data handling or authorization needs return to the relevant decision. A rejected permission remains blocked and is not retried through another host.
 
-Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.
+## Outputs and result
+
+Use plan.md.
 
-## Artifact contract
+Record actual implementation facts through domain operations with workType, the stable batchId when applicable, objectKey and result references. plan.md’s generated batch table reflects that state; keep brief development checks, necessary execution notes and existing evidence references in its AI-maintained execution section. Keep approved B/TASK definitions unchanged unless the plan itself changes; preserve planned versus actual and code versions. Do not generate implementation.md or a second task-status ledger.
 
-Use plan.md. Preserve the ordinary template headings and section order. Follow [document patterns](../document-patterns.md) and the single [artifact map](../artifact-map.json). Keep this run independent even when its document is shared. New runs need a precise result location; adopted work is not a newly executed stage.
+## Completion and stop
 
-Update TASK/B status and actual execution in plan.md's execution section, citing the existing task/batch numbers. Keep approved task definitions unchanged unless the plan itself changes; preserve planned versus actual and code versions. Do not generate implementation.md.
+Save the implementation checkpoint, then continue directly to [batch review](../reviews/batch.md) for business work, or [repair recheck](../reviews/recheck.md) preserving the original batch/overall scope for repair work. Keep separate implement/review runs; the checkpoint is not another user continuation request. Mark implementation workType as batch for planned business work, or repair with repairOf pointing to its actual preceding basis. Record each repair as new work with the applicable batchId and actual repairOf/history result basis; preserve completed records. Do not infer its responsibility from an ID. Use [conditional host delegation](../core.md#conditional-host-delegation) only where it helps; the main agent remains responsible for integration and batch review.
 
-After completing and self-checking this stage, save its result and current stop. Report the artifacts and next action, then stop. Wait for continuation without adding a document approval; final handoff instead awaits the actual acceptance decision. Failures remain unresolved until repaired and checked.
+After the batch review passes and the facts/projections are saved, report the batch result and stop before the next batch. If it was the last batch, summarize the implementation and remaining work, then recommend a new session for overall review. Only explicit authorization permits that overall review in the current session; do not start it automatically. On a real scope, permission, approval or unresolved technical dependency, stop at that issue rather than claiming the batch passed. Local checks remain brief execution notes and evidence references; formal RUNs belong to post-overall-review verification.

package/skills/aimship/references/stages/plan.md

@@ -1,27 +1,25 @@
 # Plan implementation batches
 
-## Basis
+## Inputs
 
 Read approved current PRD, test cases/coverage for standard delivery (or the explicit limited-scope basis), applicable design/contracts and relevant repository boundaries.
 
-## Work and result
+## Goal and scope
 
-Define executable batches, each goal and requirement coverage, dependencies, authorized file/repository scope and interfaces. Arrange batch implementation/review, overall review, then independent verification within the agreed scope; explicitly excluded testing remains an untested partial handoff. Include known cross-delivery interface, database, test-data/service and integration dependencies in this same plan, with necessary sequencing or use arrangements. Keep test-code development in appropriate batches; do not add per-batch full testing gates.
-
-## Continue when
+Define approved implementation batches and tasks with their boundaries, dependencies and completion criteria.
 
-Batches can be executed in order and together cover the delivery goal. Every implementation, including a single small batch, requires a completed plan and plan.md before it begins.
+## Actions
 
-## Decisions and blockers
+Define executable batches, each goal and requirement coverage, dependencies, authorized file/repository scope and interfaces. Arrange batch implementation/review, overall review, then independent verification within the agreed scope; explicitly excluded testing remains an untested partial handoff. Include known cross-delivery interface, database, test-data/service and integration dependencies in this same plan, with necessary sequencing or use arrangements. Keep test-code development in appropriate batches; do not add per-batch full testing gates.
 
 A material change in scope/endpoint needs a decision; routine task splitting does not. Record the reason if changing the existing order.
 
-Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.
+## Outputs and result
 
-## Artifact contract
+Use plan.md. Keep batch goals, dependencies and TASK definitions in the approved design sections. After approval, register stable B definitions, TASK references and dependencies through the state tool. Its finite generated execution section supplies the one current batch progress table, including implementation/review results and references. Keep detailed notes and blockers outside that generated section; do not hand-maintain another status table or redefine approved work in the execution area.
 
-Use plan.md. Preserve the ordinary template headings and section order. Follow [document patterns](../document-patterns.md) and the single [artifact map](../artifact-map.json). Keep this run independent even when its document is shared. New runs need a precise result location; adopted work is not a newly executed stage.
+## Completion and stop
 
-## Human document review
+Batches can be executed in order and together cover the delivery goal. Every implementation, including a single small batch, requires a completed plan and plan.md before it begins.
 
-Apply [document review](../document-review.md): generate → self-check → present the concrete document entry, current review status and focus → wait. Record explicit user approval of this version/content, then follow the core session interaction: stop at this stage boundary; suggest a new session only at a major work boundary, and continue here when requested. Approval and continuation may be expressed together. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.
+Self-check the selected outputs and stop for their [current-content review](../document-review.md); unchanged supplied inputs follow the shared adoption rules. Production done is separate from approval.

package/skills/aimship/references/stages/prototype.md

@@ -1,29 +1,25 @@
 # Design interaction
 
-## Basis
+## Inputs
 
 Read current requirements, applicable design conventions and any supplied prototype or UI images.
 
-## Work and result
+## Goal and scope
 
-Describe or build the relevant flow, screens, key loading/empty/error/success and permission states, feedback and responsive behavior where relevant. Link each part to its requirement. Visually inspect/operate actual HTML when claiming layout or interaction validation, with available tools.
-
-## Continue when
+Clarify the selected interaction scope; preserve adequate supplied material and avoid an unnecessary prototype.
 
-The relevant interactions and states are clear and consistent with current requirements. A saved image or HTML source is not evidence of visual inspection.
+## Actions
 
-## Decisions and blockers
+Describe or build the relevant flow, screens, key loading/empty/error/success and permission states, feedback and responsive behavior where relevant. Link each part to its requirement. Visually inspect/operate actual HTML when claiming layout or interaction validation, with available tools.
 
 Missing visual/browser tools require an explicit unverified scope. Resolve contradictory behavior through requirements; do not silently alter external prototypes.
 
-Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.
-
-## Artifact contract
+## Outputs and result
 
-Use the registered prototype entry (new HTML: prototype/index.html). Follow [document patterns](../document-patterns.md) and the single [artifact map](../artifact-map.json). Keep this run independent even when its document is shared. New runs need a precise result location; adopted work is not a newly executed stage.
+Use the registered prototype entry (new HTML: prototype/index.html).
 
-## Human document review
+## Completion and stop
 
-For an unchanged supplied prototype with clear adoption intent, register mode input with the actual request basis, check the applicable content, then save and stop for continuation without a source approval. Report any unverified visual/interaction scope; a copied file is not newly designed or tested. Ask only concrete unresolved questions through next.questionRef.
+The relevant interactions and states are clear and consistent with current requirements. A saved image or HTML source is not evidence of visual inspection.
 
-For AI-authored or substantively changed prototypes, apply [document review](../document-review.md): generate → self-check → present the concrete document entry, current review status and focus → wait. Record explicit user approval of this version/content, then follow the core session interaction: stop at this stage boundary; suggest a new session only at a major work boundary, and continue here when requested. Approval and continuation may be expressed together. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.
+Self-check the selected outputs and stop for their [current-content review](../document-review.md); unchanged supplied inputs follow the shared adoption rules. Production done is separate from approval.

package/skills/aimship/references/stages/requirements.md

@@ -1,29 +1,25 @@
 # Define requirements
 
-## Basis
+## Inputs
 
 Read the preserved original input, problem findings, adopted material and current decisions.
 
-## Work and result
+## Goal and scope
 
-Write the current requirements, important rules, normal/error/boundary behavior, constraints and observable acceptance criteria. Include context and scope, not just a checklist. Link sources; a complete applicable existing PRD is adopted directly without rewriting or renumbering. For partial adoption, write this iteration’s PRD with source, inclusions, exclusions and acceptance. For unchanged supplied input, use the actual delivery request as the adoption basis; no repeated source approval is required. Review AI-authored or substantively revised requirements, reusing evidenced current-content approval when available. Ask only concrete unresolved questions.
-
-## Continue when
+Establish the one current requirement authority, its acceptance criteria and the actual adopted or authored scope.
 
-The requirements are adequate for the commissioned next work and material ambiguities affecting it are resolved. Reuse adequate requirements without claiming they were newly produced.
+## Actions
 
-## Decisions and blockers
+Write the current requirements, important rules, normal/error/boundary behavior, constraints and observable acceptance criteria. Include context and scope, not just a checklist. Link sources; a complete applicable existing PRD is adopted directly without rewriting or renumbering. For partial adoption, write this iteration’s PRD with source, inclusions, exclusions and acceptance. For unchanged supplied input, use the actual delivery request as the adoption basis; no repeated source approval is required. Review AI-authored or substantively revised requirements, reusing evidenced current-content approval when available. Ask only concrete unresolved questions.
 
 Ask for business behavior, compatibility or endpoint choices that cannot be inferred. Do not invent user acceptance.
 
-Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.
-
-## Artifact contract
+## Outputs and result
 
-Use the selected PRD requirement entry. For a new PRD preserve the ordinary template headings and section order; a complete adopted PRD retains its own outline. Follow [document patterns](../document-patterns.md) and the single [artifact map](../artifact-map.json). Keep this run independent even when its document is shared. New runs need a precise result location; adopted work is not a newly executed stage.
+Use the selected PRD requirement entry. For a new PRD preserve the ordinary template headings and section order; a complete adopted PRD retains its own outline.
 
-## Human document review
+## Completion and stop
 
-Apply [document review](../document-review.md). For unchanged user-supplied requirements with clear adoption intent, register mode input with the real request basis and self-check; report the retained input and newly created records, save and stop for continuation. Do not call it a newly authored PRD, ask for source approval or ask whether to use the standard flow. If a specific uncertainty affects progress, name the question, options and impact, retain a blocked stage and next.questionRef, and stop for clarification.
+The requirements are adequate for the commissioned next work and material ambiguities affecting it are resolved. Reuse adequate requirements without claiming they were newly produced.
 
-AI-authored, partially adopted or substantively revised PRDs follow self-check and human review. Present what changed and wait for explicit approval; reuse actual current-content approval where applicable. Approval and continuation may be expressed together. Questions or edit requests retain the review stop. Production done, input adoption, self-check, human approval and final acceptance are distinct.
+Self-check the selected outputs and stop for their [current-content review](../document-review.md); unchanged supplied inputs follow the shared adoption rules. Production done is separate from approval.

package/skills/aimship/references/stages/review.md

@@ -1,27 +1,25 @@
-# Review actual changes
+# Select the review responsibility
 
-## Basis
+## Inputs
 
-Read the applicable requirements, design/contract, batch or overall scope and exact change objects.
+The saved current scope, reviewed object and relevant approved requirements/design/contracts/plan; read reviewScope, reviewOf, batchId and any prior REV/repair relationship. Use the [shared project context](../core.md#project-context-and-decisions).
 
-## Work and result
+## Goal and scope
 
-Fix the object basis before review: commit plus relevant working differences/untracked paths, or document sections and digests/old excerpts. Check consistency, defects, omissions and scope. Record findings, dispositions and reviewer source. Batch review precedes next batch; overall review checks integration after all batches. Single-batch review may cover both explicitly.
+Choose one clear review contract. Stage remains review; these are internal execution modules, not separate user commands or registered Skills.
 
-## Continue when
+## Actions
 
-The agreed scope has actually been examined and issues blocking progression are resolved or handled by an explicit change. Keep old conclusions for their old objects.
+- Current implementation batch: use [batch review](../reviews/batch.md).
+- Explicit overall review after all batches: use [overall review](../reviews/overall.md).
+- Repaired prior findings: use [recheck](../reviews/recheck.md), retaining the original batch/overall scope.
 
-## Decisions and blockers
+If the scope is not recorded, inspect the existing plan/review and actual request before acting. Do not infer permission for a full test suite from a review request.
 
-Do not replace an agreed human review with agent review. Review cannot be reported as a running test; unrelated work need not be re-reviewed.
+## Outputs and result
 
-Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.
+The selected module's actual REV and state references in review.md. Common assessment/finding rules live in the [shared method](../review-method.md).
 
-## Artifact contract
+## Completion and stop
 
-Use review.md. Preserve the ordinary template headings and section order. Follow [document patterns](../document-patterns.md) and the single [artifact map](../artifact-map.json). Keep this run independent even when its document is shared. New runs need a precise result location; adopted work is not a newly executed stage.
-
-Record reviewOf with the actual implementation-run IDs; mark overall: true only for an overall review. Batch review and overall review each save their own stage stop, even when their context group is shared. Resolve findings before continuation; a suggestion never substitutes for a passing review.
-
-After completing and self-checking this stage, save its result and current stop. Report the artifacts and next action, then stop. Wait for continuation without adding a document approval; final handoff instead awaits the actual acceptance decision. Failures remain unresolved until repaired and checked.
+Follow that module's work-unit boundary: batch review/authorized repair closes the batch; overall/recheck conclusions stop before formal verify. Document approvals remain governed by [document review](../document-review.md).