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

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

@@ -1,12 +1,16 @@
 # Design the implementation
 
-## Basis
+## 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).
 
-## Work and result
+## Goal and scope
 
-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.
+Explain an implementation-ready engineering approach for the approved requirement scope, with readable decisions and dependencies.
+
+## Actions
+
+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.
 
@@ -14,22 +18,16 @@ 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.
 
-## Continue when
-
-The design can guide the agreed next work and correctness-affecting issues have a clear disposition. Explain the approach and outstanding choices to the user.
-
-## Decisions and blockers
+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.
 
-Missing schema/dialect or material compatibility/data decisions block dependent design claims. An explicitly revised conceptual-design endpoint must retain these limitations.
+## 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.
-
-## Artifact contract
-
-Use tech-design.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 tech-design.md.
 
 Technical design does not require finished SQL before its review. After its approval, contract produces and presents database.sql for one target, or database-<id>.sql per independent target. No SQL for no database change.
 
-## Human document review
+## Completion and stop
+
+The design can guide the agreed next work and correctness-affecting issues have a clear disposition. Explain the approach and outstanding choices to the user.
 
-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/test-design.md

@@ -1,27 +1,25 @@
 # Design verification
 
-## Basis
+## Inputs
 
 Read current acceptance criteria, constraints, design/contracts, independent SQL and identified risks.
 
-## Work and result
+## Goal and scope
 
-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.
+Design appropriate checks for the current acceptance criteria and risks, without claiming execution.
 
-## Continue when
+## Actions
 
-The goal and material risks have appropriate checks and missing execution conditions are explicit. Complete and obtain approval of cases/coverage before the selected plan stage. Write them in testing.md; execution remains explicitly not run until verify.
-
-## Decisions and blockers
+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.
 
-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 testing.md.
 
-Use testing.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
+The goal and material risks have appropriate checks and missing execution conditions are explicit. Complete and obtain approval of cases/coverage before the selected plan stage. Write them in testing.md; execution remains explicitly not run until verify.
 
-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/verify.md

@@ -1,27 +1,27 @@
 # Execute verification
 
-## Basis
+## 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.
 
-## Work and result
+## Goal and scope
 
-Execute the agreed checks on identified objects. 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.
+Execute only the agreed formal verification scope after passing overall review, preserving failures and retests.
 
-## Continue when
+## Actions
 
-The agreed execution work is accounted for with traceable results. This run can end with failure or gaps; that does not make the development goal met.
+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.
 
-## Decisions and blockers
+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.
 
-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 [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.
+Use testing.md.
 
-## Artifact contract
+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.
 
-Use testing.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
 
-Append RUN records in testing.md, 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.
+The agreed execution work is accounted for with traceable results. This run can end with failure or gaps; that does not make the development goal met.
 
-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/templates/change-log.md

@@ -2,11 +2,11 @@
 
 Delivery: <deliveryId from init>; document revision: <revision>.
 
-## Important changes
+## 1. Important changes
 
 CHG, reason/decision source, before/after, affected IDs/objects, actions/results and remaining work. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Unfinished impact handling
+## 2. Unfinished impact handling
 
 One decision stays one record; no edit audit. Replace guidance with actual content; explain inapplicability, never prefill a result.
 

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

@@ -2,31 +2,31 @@
 
 Delivery: <deliveryId from init>; document revision: <revision>.
 
-## Investigation goal and scope
+## 1. Investigation goal and scope
 
 Commission and authorized scope. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Observed and expected behavior
+## 2. Observed and expected behavior
 
 Facts versus hypotheses. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Environment and reproduction
+## 3. Environment and reproduction
 
 Exact versions and reproducible conditions. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Checks and evidence
+## 4. Checks and evidence
 
 Operations, observations and source refs. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Cause assessment
+## 5. Cause assessment
 
 Confirmed causes versus unverified hypotheses. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Impact and unknowns
+## 6. Impact and unknowns
 
 Dependent work and recovery conditions. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Conclusion and next action
+## 7. Conclusion and next action
 
 Investigation endpoint is not automatically repair completion. Replace guidance with actual content; explain inapplicability, never prefill a result.
 

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

@@ -2,27 +2,27 @@
 
 Delivery: <deliveryId from init>; document revision: <revision>.
 
-## Current goal comparison
+## 1. Current goal comparison
 
 REQ/AC and actual results, including explicit goal changes. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Artifacts, repositories and versions
+## 2. Artifacts, repositories and versions
 
 Links, actual checkout/worktree, branch/commit and uncommitted paths; no Git uses file digests. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Usage
+## 3. Usage
 
 Actual commands and entry points. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Review and verification
+## 4. Review and verification
 
 Scopes, versions, results and evidence. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Limitations and remaining work
+## 5. Limitations and remaining work
 
 Unverified work and recovery conditions. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Acceptance, integration, release and continuation
+## 6. Acceptance, integration, release and continuation
 
 Independent facts; prepared version is not a release. Replace guidance with actual content; explain inapplicability, never prefill a result.
 

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

@@ -2,27 +2,33 @@
 
 Delivery: <deliveryId from init>; document revision: <revision>.
 
-## Implementation basis and scope
+## 1. Implementation basis and scope
 
 Current requirements, design, contracts and actual repositories. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Batches and dependencies
+## 2. Batches and dependencies
 
 B ID, goal, dependencies and integration arrangement. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Tasks and completion criteria
+## 3. Tasks and completion criteria
 
 TASK, batch, REQ/AC or risk, repository ID, file/module, planned change and completion criteria. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Review and independent verification arrangement
+## 4. Review and independent verification arrangement
 
 Each batch review, overall review then independent verification; no per-batch full test gates. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Task status and execution records
+## 5. Task status and execution records
 
-Lead with the current batch/task status using existing B/TASK IDs: Batch/task | Status | Actual result or remaining work | Review/result reference. Distinguish code complete from batch review complete. 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)
 
-## Deviations, blockers and remaining work
+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
 
 Unfinished effects and recovery, not a second stage ledger. Replace guidance with actual content; explain inapplicability, never prefill a result.
 

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

@@ -2,31 +2,31 @@
 
 Delivery: <deliveryId from init>; document revision: <revision>.
 
-## Document information and sources
+## 1. Document information and sources
 
 Identify this delivery, revision and adopted inputs. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Background, goals and non-goals
+## 2. Background, goals and non-goals
 
 Separate known facts, requirements and assumptions. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Scope and delivery endpoint
+## 3. Scope and delivery endpoint
 
 Included/excluded business work, source correspondence, authorization and endpoint. Keep engineering dirty lists in existing engineering records, not this PRD. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Requirements and behavior
+## 4. Requirements and behavior
 
 REQ (or retained source business ID), type, actor/object, trigger/precondition, behavior, observable result, boundaries/errors, source and AC. Shared business rules, access control (even one role), performance and reliability need independent identity when independently testable. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## States, interaction and recovery
+## 5. States, interaction and recovery
 
 Allowed transitions, terminal states, errors and recovery; say why inapplicable. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Acceptance criteria
+## 6. Acceptance criteria
 
 AC, requirement reference, condition, operation, decidable expected result. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Dependencies, questions and stage arrangement
+## 7. Dependencies, questions and stage arrangement
 
 Selected order, artifact locations/reuse, dependencies, Q with impact/status/decision source. Replace guidance with actual content; explain inapplicability, never prefill a result.
 

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

@@ -2,22 +2,27 @@
 
 Delivery: <deliveryId from init>; document revision: <revision>.
 
-## Review basis and scope
+## 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.
 
-## Review records
+## 2. Review records
 
 Use a separate REV subsection for each batch, overall or repair review. Within it write:
 
 - Scope and object: B/TASK and relevant REQ/AC, repositories/baseline/differences, reviewer and date.
 - Assessment: requirements/contract consistency and code quality in this scope; reference relevant checks without repeating implementation or test-command logs.
-- Findings: Finding | Severity/impact | File/section/symbol | Problem and basis | Disposition/status. Use a readable local finding label when a repair/recheck needs to refer back to it. If no findings, say so without an empty table.
+- Findings: Finding | Severity/impact | File/section/symbol | Problem and basis | Disposition/status. Use a readable local finding label when a repair/recheck needs to refer back to it. If no findings, state the reviewed scope/object and brief passing conclusion without an empty table or a command transcript.
 - Repairs and recheck: associate each finding with the actual change, rechecked object and conclusion; distinguish resolved, open and explicitly deferred work.
 
 Keep overall review separate from batch records. Replace guidance with actual content; never prefill a result.
 
-## Open findings and current conclusion
-
-Maintain the latest effective conclusion: 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.
+## 3. Open findings and current conclusion
 
+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/tech-design.md

@@ -2,31 +2,31 @@
 
 Delivery: <deliveryId from init>; document revision: <revision>.
 
-## Basis and engineering context
+## 1. Basis and engineering context
 
 Current requirements and actual engineering constraints. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Architecture and key flows
+## 2. Architecture and key flows
 
 Ordered explanation, with a concise diagram when useful to show cross-system calls, transaction boundaries and cache/response order. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Modules and interaction implementation
+## 3. Modules and interaction implementation
 
 Repository ID, responsibility, actual path, new/change and requirement refs. For a full-stack change use readable backend/frontend subsections: affected service/data responsibilities; client pages/routes, reused/new components, interaction states and data flow. For other tasks organize by the actual components; do not invent unused frontend/backend sections. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Data, interfaces and SQL
+## 4. Data, interfaces and SQL
 
 Structures, indexes, consistency constraints and their decision time/enforcement boundary/remaining windows, contract authority, database type/version/schema basis, SQL order and execution boundary. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Errors and nonfunctional design
+## 5. Errors and nonfunctional design
 
 Recovery, access, performance, observability, cache/messages when relevant. For critical-path changes, show call placement/count, timeout/failure behavior, cost basis and a suitable verification method; distinguish facts, estimates and unknowns. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Tradeoffs and risks
+## 6. Tradeoffs and risks
 
 Reasons, meaningful alternatives, compatibility and remaining risks. Keep business guarantees distinct from product exclusions; explain any unresolved meaning as a concrete question. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Requirement coverage and questions
+## 7. Requirement coverage and questions
 
 REQ/AC to module/operation/SQL section. For unresolved business or technical questions, state the impact, recommendation and latest point needing an answer. Review these with the document; carry forward questions that do not affect the next work. Replace guidance with actual content; explain inapplicability, never prefill a result.
 

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

@@ -2,28 +2,34 @@
 
 Delivery: <deliveryId from init>; document revision: <revision>.
 
-## Basis and scope
+## 1. Basis and scope
 
 Current AC and risks; adopted cases location/version if verify-only. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Environment, data and execution conditions
+## 2. Environment, data and execution conditions
 
 Planned tools/entry commands, isolated data, permissions and unavailable execution conditions. Actual versions/environment belong with each RUN. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Test cases
+## 3. Test cases
 
 TC, REQ/AC or risk, type/level, preconditions, operations, concrete expected result, method/entry. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Coverage and verification arrangement
+## 4. Coverage and verification arrangement
 
 AC, requirements, TC, gaps and execution group/order. Explain the selected test methods from requirements and risk, reusing project checks; do not require every test category. Replace guidance with actual content; never prefill a result.
 
-## Execution and retest records
+## 5. Execution and retest records
 
-Keep every RUN and retest here, grouped by actual batch or verification round: TC, testing document version, exact code/build object, environment, command/operation, assertions, result and evidence. Retain failures and the later recheck; local implementation checks do not replace post-overall-review independent verification. Replace guidance with actual content; never prefill a result.
+### 5.1 Current verification (generated)
 
-## Defects, current conclusion and remaining work
+Pending state generation.
 
-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.
+### 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
+
+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. -->