aimship 0.1.0-preview.20 → 0.1.0-preview.21

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

@@ -10,12 +10,12 @@ Find cross-batch consistency, shared-rule and integration defects that individua
 
 ## Actions
 
-Apply the [shared review method](../review-method.md) to the combined scope, including repair changes. Inspect requirement coverage, shared boundaries, omissions and unresolved findings. Reference local checks without claiming formal runtime verification. If a single-batch commission explicitly covers both review responsibilities, examine and record both scopes; do not infer that commission from batch count alone.
+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, overall:true and reviewOf covering all current implementation runs, including repairs. Preserve earlier review conclusions and name the exact reviewed basis.
+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 permits subsequent authorized formal verification; it does not execute it. A failing review retains its findings and awaits the actual repair work/decision, without inventing a test result.
+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

@@ -14,7 +14,7 @@ Apply the [shared review method](../review-method.md). Examine the repair and af
 
 ## 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 within the current failed batch updates that batch’s existing implementation checkpoint and execution evidence; the new recheck retains the failed REV. Separate repair work after completed batches uses workType:repair and the actual repairOf basis; it is not a new business batch.
+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
 

package/skills/aimship/references/routing.md

@@ -8,7 +8,7 @@ The user activates one Aimship entry. Read the bound core, this routing guide an
 | 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. Overall review alone does not commission full testing. |
+| 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.

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

@@ -2,7 +2,7 @@
 
 ## 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).
 
 ## Goal and scope
 
@@ -12,7 +12,7 @@ Make applicable interface and database changes unambiguous after the technical d
 
 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.
 
 ## Outputs and result
 

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

@@ -2,7 +2,7 @@
 
 ## 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).
 
 ## Goal and scope
 

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

@@ -2,7 +2,7 @@
 
 ## 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.
 
 ## Goal and scope
 
@@ -18,10 +18,10 @@ Expanded external behavior, data handling or authorization needs return to the r
 
 Use plan.md.
 
-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.
+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.
 
 ## Completion and stop
 
-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. For old work after an overall review, inspect the plan/review before assigning the purpose; never infer it from an ID.
+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 the batch review passes and the current plan status/references are saved, report the batch result and stop before the next batch or overall review. 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.
+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

@@ -16,7 +16,7 @@ A material change in scope/endpoint needs a decision; routine task splitting doe
 
 ## Outputs and result
 
-Use plan.md. Keep batch goals, dependencies and TASK definitions in the approved design sections. Maintain exactly one current batch progress table in the execution section, including implementation, review/repair status, B/TASK/result references and remaining work; it summarizes execution rather than redefining the plan.
+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.
 
 ## Completion and stop
 

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

@@ -2,7 +2,7 @@
 
 ## Inputs
 
-The saved current scope, reviewed object and relevant requirements/design/plan; read reviewOf, overall and any prior REV/repair relationship.
+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).
 
 ## Goal and scope
 

package/skills/aimship/references/stages/tech-design.md

@@ -2,7 +2,7 @@
 
 ## Inputs
 
-Read current requirements, relevant engineering instructions, architecture, schema and diagnosis.
+Read current requirements, the relevant implementation/interfaces/schema, applicable engineering instructions and any commissioned diagnosis. Apply the [shared project context and decisions](../core.md#project-context-and-decisions).
 
 ## Goal and scope
 
@@ -10,7 +10,7 @@ Explain an implementation-ready engineering approach for the approved requiremen
 
 ## Actions
 
-Choose an approach with concrete components, dependencies, errors/recovery, compatibility and tradeoffs. Link authoritative contracts instead of duplicating them. For database changes design the data change and the subsequent independent SQL deliverable; explain dialect/version, existing schema basis, conditions and sequence. Do not edit migration files or execute SQL without that commission.
+Choose an approach grounded in the relevant current implementation and applicable conventions, explaining reuse and necessary differences without expanding into unrelated legacy cleanup. Describe concrete components, dependencies, errors/recovery, compatibility and tradeoffs. Link authoritative contracts instead of duplicating them. For database changes design the data change and the subsequent independent SQL deliverable; explain dialect/version, existing schema basis, conditions and sequence. Do not edit migration files or execute SQL without that commission.
 
 For applicable concurrency and state changes, explain when the business constraint is checked, what enforces it and any remaining window. Keep that guarantee distinct from excluded product interactions; if the requirements leave its meaning unresolved, include the concrete question in the document with its impact, recommendation and the work that needs an answer. For example, a stock reservation may check and decrement within one transaction; an earlier availability display alone does not guarantee stock at commit.
 
@@ -18,7 +18,7 @@ For a material new database/RPC call on the critical path, describe its location
 
 Use an ordered explanation for simple flows. Where cross-system calls are hard to follow, a concise architecture or sequence diagram can show transaction boundaries and cache/response order. Organize affected components into readable subsections; full-stack work benefits from backend responsibilities and frontend pages/routes, reuse, interaction states and data flow. Other work uses its actual components. Explain the design and real tradeoffs in the document, using source evidence where it helps judgment; routine investigation/self-check logs are not review prerequisites. API schemas, executable SQL and full test cases remain in their later deliverables.
 
-Missing schema/dialect or material compatibility/data decisions block dependent design claims. An explicitly revised conceptual-design endpoint must retain these limitations.
+Investigate available schema/dialect facts directly. Missing correctness-affecting facts or material compatibility/data decisions hold the dependent design claims; nonblocking execution details may stay explicit for later work. An explicitly revised conceptual-design endpoint must retain these limitations.
 
 ## Outputs and result
 

package/skills/aimship/references/stages/test-design.md

@@ -10,7 +10,7 @@ Design appropriate checks for the current acceptance criteria and risks, without
 
 ## Actions
 
-Map requirements, acceptance and risks to observable normal, boundary/error and regression checks. Reuse the project's test tools and choose methods where useful: units for logic/state, interface/integration checks for service/data collaboration, component/browser/E2E for interaction paths, targeted performance or security checks for relevant requirements/risks. Explain the choices and execution conditions; no fixed category count or coverage target. Identify tools/commands, isolated data and authorization needs. Preserve checks whose conditions are absent; distinguish what must be verified from what can run now. Implementation checks, batch/overall code review and final independent verification have distinct scopes; a mock result is not real integration evidence.
+Map requirements, acceptance and risks to observable normal, boundary/error and regression checks. Reuse the project's test tools and choose methods where useful: units for logic/state, interface/integration checks for service/data collaboration, component/browser/E2E for interaction paths, targeted performance or security checks for relevant requirements/risks. Explain the choices and execution conditions; no fixed category count or coverage target. Identify tools/commands, isolated data and authorization needs. Preserve checks whose conditions are absent; distinguish what must be verified from what can run now. Implementation checks, batch/overall code review and final formal verification have distinct scopes; a mock result is not real integration evidence. State the actual project execution conditions, including a deployed test environment where needed, without inventing a universal deployment prerequisite or an Aimship deployment stage.
 
 Missing tools or execution authority do not justify deleting a valid case. Clarify acceptance omissions through current requirements rather than measuring only test count.
 

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

@@ -2,7 +2,7 @@
 
 ## Inputs
 
-Read current acceptance criteria, the verification plan, actual reviewed results and execution conditions.
+Read current acceptance criteria and case/coverage definitions, the passing overall review of the current object, any later repair reviews and the agreed execution conditions.
 
 ## Goal and scope
 
@@ -12,13 +12,13 @@ Execute only the agreed formal verification scope after passing overall review,
 
 Execute the agreed checks on identified objects. Optional verification groups follow actual coverage and conditions, not implementation batches; a retest is another RUN in the same scope, not a new development batch. Local unit checks need no deployment. Preserve commands/operations, environment/data, expected assertions, actual results and sufficient evidence. Separate pass/fail/not-run/unknown. On defects repair the affected implementation, review the repair, then retest affected cases; append the new result and retain the old failure.
 
-Unavailable environment or authority stays explicit with a recovery action. Do not lower criteria, skip assertions or mark a case passed because a command exited successfully.
+Use the agreed real environment: if this project’s formal tests require deployment to a test environment, hand over that preparation and wait until it is ready. Do not initiate deployment, add a deployment stage or impose deployment on checks that need none. Unavailable environment or authority stays explicit with a recovery action. Do not lower criteria, skip assertions or mark a case passed because a command exited successfully.
 
 ## Outputs and result
 
 Use testing.md.
 
-Append formal RUN records only in testing.md's execution section, citing TC numbers, the tested document version and exact objects. Evidence goes in .aimship/evidence/; no installation diagnostics or repeated state output in ordinary deliveries.
+Append formal RUN records only in testing.md’s AI-maintained execution section, citing TC numbers or adopted coverage references, the tested document version and exact objects. Submit each execution through record-run with its coverageRefs and objectKey, using per-coverage results when they differ. The generated current summary derives from those facts; do not hand-write a competing pass/fail table. A partial retest resolves only the matching prior coverage; retain failed RUNs and cite them through historyResultRefs. Reusing a previous object’s result requires an assessment of its applicability to the specific current object, not a renamed old result. Evidence goes in .aimship/evidence/; no installation diagnostics or repeated state output in ordinary deliveries.
 
 ## Completion and stop
 

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

@@ -20,7 +20,13 @@ Each batch review, overall review then independent verification; no per-batch fu
 
 ## 5. Task status and execution records
 
-Maintain one current batch progress table using existing B/TASK references: Batch / TASK scope | Implementation status | Batch review / repair status | Result references | Remaining work or blocker. Do not duplicate it as a second task-status ledger. Distinguish code complete from batch review complete. Brief development checks cite existing evidence; do not write a formal report for every batch. Follow with necessary dated execution records, deviations and object versions; retain prior results for their objects. Preserve approved task definitions above and distinguish pre-existing changes. Update this summary as work proceeds; save main-stage facts in state for status.md. Replace guidance with actual content; never prefill a result.
+### 5.1 Current batch progress (generated)
+
+Pending state generation.
+
+### 5.2 Execution notes and history
+
+Keep necessary dated implementation/development-check notes, exact object versions, deviations and existing evidence references here. The state-generated table above is the only current batch progress table; submit implementation, review and repair facts through the state tool instead of editing its cells. Preserve approved B/TASK definitions in the design sections above and distinguish pre-existing changes. Do not write a formal self-test report for every batch or copy review findings and formal RUN results here. Replace guidance with actual content; never prefill a result.
 
 ## 6. Deviations, blockers and remaining work
 

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

@@ -4,6 +4,12 @@ Delivery: <deliveryId from init>; document revision: <revision>.
 
 ## 1. Review basis and scope
 
+### 1.1 Current review (generated)
+
+Pending state generation.
+
+### 1.2 Review basis
+
 State the requirements/design/plan references and review scope. Put each review's actual repositories, baseline plus differences, reviewer and date with its REV record. Keep object details readable and link the exact manifest when useful. Replace guidance with actual content; never prefill a result.
 
 ## 2. Review records
@@ -19,5 +25,4 @@ Keep overall review separate from batch records. Replace guidance with actual co
 
 ## 3. Open findings and current conclusion
 
-Maintain one latest effective conclusion and update the saved next action to match: reviewed scope/object, remaining findings and whether they block continuation. Distinguish review findings from unexecuted validation, linking testing.md for runtime coverage and missing conditions. Historical conclusions remain inside their REV records for the old objects; do not accumulate obsolete “next batch” instructions here. Review is not runtime validation or user acceptance. Replace guidance with actual content; never prefill a result.
-
+Explain remaining findings and whether they block continuation, citing their REV records and disposition. The generated current review section above owns the effective result summary; do not create a second current-status table or accumulate obsolete “next batch” instructions here. Distinguish review findings from unexecuted validation and link testing.md for runtime coverage and missing conditions. Historical conclusions remain inside their REV records for the old objects. Review is not runtime validation or user acceptance. Replace guidance with actual content; never prefill a result.

package/skills/aimship/references/templates/testing.md

@@ -20,10 +20,16 @@ AC, requirements, TC, gaps and execution group/order. Explain the selected test
 
 ## 5. Execution and retest records
 
-Keep formal verification RUNs and retests here, grouped by actual coverage/conditions rather than development batch: TC, testing document version, exact code/build object, environment, command/operation, assertions, result and evidence. Optionally lead with one verification-group table: Group / covered AC-TC or risk | Current state | RUN references | Uncovered work. A retest stays in the same scope with a new RUN, not a new development batch. Retain failures and later rechecks. Development checks are brief plan execution notes/evidence references; they do not replace post-overall-review verification or fill this section as formal execution. Replace guidance with actual content; never prefill a result.
+### 5.1 Current verification (generated)
+
+Pending state generation.
+
+### 5.2 Formal runs and retests
+
+Keep formal verification RUNs and retests here, grouped by actual coverage/conditions rather than development batch: TC or adopted coverage reference, testing document version, exact code/build object, environment, command/operation, assertions, result and evidence. A retest stays in the same scope with a new RUN; retain failures and later rechecks. Submit actual coverage/results and the tested object to the state tool; the generated summary above shows the effective results and remaining coverage. Development checks are brief plan execution notes/evidence references; they do not replace post-overall-review verification or fill this section as formal execution. Replace guidance with actual content; never prefill a result.
 
 ## 6. Defects, current conclusion and remaining work
 
-Maintain a latest-result summary for the current object: AC/TC or risk | Verified scope | Result | Evidence/RUN | Remaining coverage. Separate passed, failed, blocked and unexecuted; state defects, their disposition and the next necessary work. Keep historical RUNs in the execution section above, not underneath an old current conclusion. Replace guidance with actual content; never prefill a result.
+Explain defects, their disposition, unavailable conditions and remaining work, citing the actual RUNs or review findings. The generated current verification section above owns the current coverage/result table; do not duplicate it here. Keep historical RUNs in the execution section and tie their conclusions to their tested objects. Replace guidance with actual content; never prefill a result.
 
 <!-- Review guidance: retain the fixed outline. Technical design precedes interface/SQL production; test cases precede planning. Self-check and explicit document approval are separate from stage done. For plan/testing, keep execution records after execution/runs respectively. -->