aimship 0.1.0-preview.13 → 0.1.0-preview.15

package/skills/aimship/references/core.md

@@ -2,7 +2,7 @@
 
 ## Start from the commission
 
-A delivery has one centralized material directory, a preserved original request, a state record, and current requirements or adopted sources plus Scope as they are formed. The final endpoint may initially be unknown. Code stays in its existing locations. A single repository and several repositories use the same model; there is no project registration step, repository count limit, or route classification.
+A delivery has one centralized material directory, a preserved original request, a state record, and a current PRD, authored or adopted as needed. The final endpoint may initially be unknown. Code stays in its existing locations. A single repository and several repositories use the same model; there is no project registration step, repository count limit, or route classification.
 
 The project workspace is the AI tool's working context, not necessarily a code repository. Initialization needs no code location or repository association. Work in that workspace and, using the tool's supported controls when needed, have the user add or grant access to the actual delivery directory in place; do not copy its documents into the workspace. Do not invent workspace membership when it is unknown or claim to add a folder automatically. The configured dataRoot remains the default, not a new Aimship folder relative to the working directory.
 
@@ -10,7 +10,7 @@ Understand the intended result, supplied evidence, authorized changes and endpoi
 
 Use the dataRoot returned by bind (default `~/Aimship`), with a separate identifiable folder for each new delivery; the root itself is not a delivery. A project, code checkout or prototype directory describes existing materials, not a request to store the delivery there. Check possible existing matches before creating anything; ambiguous candidates need selection, not a global “latest” pointer. Only an explicit user choice changes the new delivery location. If access fails, retain the request and intended location in the conversation, report what is unsaved and resume there when access is restored; never fall back to the current workspace. Installation does not create delivery materials.
 
-Read repository instructions and existing tools for the relevant work. Record relevant pre-existing modifications and distinguish them from the delivery's changes. Do not clean a working tree, initialize Git, modify an unrelated repository, or expand write access merely to simplify the workflow.
+Read repository instructions and existing tools for the relevant work. Record relevant pre-existing modifications in existing engineering state, design or plan records and distinguish them from the delivery's changes. Do not paste full Git dirty lists into a business PRD. Other requests' changes are not this delivery's scope; a dirty tree alone is not a blocker. Do not clean a working tree, initialize Git, modify an unrelated repository, or expand write access merely to simplify the workflow.
 
 <a id="initialization"></a>
 ## Initialize or resume the same delivery
@@ -20,11 +20,11 @@ This flow follows explicit Aimship activation in the first and every new session
 1. Preserve the user's relevant wording, sources, constraints and visible discussion. Distinguish user decisions, reported facts, Agent suggestions and unknowns. Do not re-ask known answers or treat discussion as approval. Before write access exists, keep this in the conversation and say it is not saved. If a session switch is necessary before saving, provide copyable context with the intended path, original input and pending operation; it is not a new approval.
 2. Bind the actual tool/core version and keep its returned dataRoot. Inspect the intended delivery folder or known candidates for existing state, partial creation or conflicting material. Read and resume existing state, checking deliveryId when known, including older deliveries outside today’s configured root. For a new location explicitly chosen by the user, preserve that actual decision in a nonempty local file within the delivery and supply `storage: {mode: "explicit", decisionRef: "<delivery-relative file>"}` to init; the reference is a file path without a fragment. Never invent the decision or override the tool’s dataRoot to make a path pass. Otherwise use a separate folder under the bound dataRoot. Ask only when identity/location is unresolved; do not create a replacement or infer ownership from a matching name.
 3. Reuse the current workspace’s access to the intended materials path without changing that path. If access is missing, follow [AI tool access](hosts.md) with the exact required path; the user adds the original directory or grants the needed access. If the target does not exist, use its accessible existing parent to create it as part of saving this delivery, or explain which directory the user must create/open. No silent fallback into the workspace, unrelated probe files or global settings changes. Workspace names and “I added it” are not proof: normal reads establish read access only; actual saves establish write access for that operation. Do not report saved work before the result confirms it.
-4. Save the original input in source/request.md without replacing existing material. Set `language` to `zh-CN` or `en`: an explicit user preference takes precedence, otherwise use the language of this conversation. The Agent saves this delivery setting in init; it is not an installation setting or a command the user must learn. Use init to create state and its generated status.md. Before PRD/Scope exists, use goalRef source/request.md, empty documents and null for unknown endpoint and documentPolicy conditions/authority (schema 4). A requirements/frame/scope run can be active without a draft; a done result still requires its formal artifact. Do not create empty templates or mark unknown conditions false/none/[] to pass init. Use next for the concrete pending questions/work; no parallel initialization ledger.
+4. Save the original input in source/request.md without replacing existing material. Set `language` to `zh-CN` or `en`: an explicit user preference takes precedence, otherwise use the language of this conversation. The Agent saves this delivery setting in init; it is not an installation setting or a command the user must learn. Use init to create state and its generated status.md. Before PRD exists, use goalRef source/request.md, empty documents and null for unknown endpoint and documentPolicy conditions/authority (schema 4). A requirements/frame run can be active without a draft; a done result still requires its formal artifact. Do not create empty templates or mark unknown conditions false/none/[] to pass init. Use next for the concrete pending questions/work; no parallel initialization ledger.
 5. Inspect stateSaved, revision and view from the actual result. Read back the saved state and status entry before reporting complete initialization. If the view failed, preserve the ID/revision and repair it with render; do not init again. If the response was lost, read before retrying. Source-only partial creation resumes at the same intended location after checking its ownership; stale locks require confirming the writer stopped.
 6. Give a concise receipt: initialized / resumed / incomplete, recognizable delivery, actual absolute directory and readable status link (only when available), saved materials, bound version, saved language, code association and checked access, current stage/work and next action. A repository registration alone does not prove access. Do not claim original initialization facts for an old delivery. Then continue authorized requirement clarification, unless the user requested a stop.
 
-Register the first substantive PRD/Scope, select its authority and change goalRef in the same update when drafting it. This reference transition alone does not alter the user's goal or require a fabricated approval; an actual endpoint/scope change still needs its decision source. Formal requirements and each subsequent selected reviewable document keep their existing self-check/explicit-approval stops. Write new formal headings/body and next-action text in the saved delivery language while retaining business IDs, machine keys and paths. Preserve source text and existing documents without automatic translation. Unknown technical conditions can be investigated during design, but must be resolved before completing design or advancing work that depends on them. Omitting a stage record cannot bypass its input document approvals. Initialization/check/resume readiness permits only the recorded current work, not all future stages.
+Register the first substantive PRD, select its authority and change goalRef in the same update when drafting it. This reference transition alone does not alter the user's goal or require a fabricated approval; an actual endpoint/scope change still needs its decision source. Formal requirements and each subsequent selected reviewable document keep their existing self-check/explicit-approval stops. Write new formal headings/body and next-action text in the saved delivery language while retaining business IDs, machine keys and paths. Preserve source text and existing documents without automatic translation. Unknown technical conditions can be investigated during design, but must be resolved before completing design or advancing work that depends on them. Omitting a stage record cannot bypass its input document approvals. Initialization/check/resume readiness permits only the recorded current work, not all future stages.
 
 “Clarify requirements first” describes current work, not a requirements-only endpoint or full development permission. Use null until the actual endpoint is known, then save the real decision before dependent work. Keep known conditions when available; false/none/[] mean explicitly not applicable, not unknown. Later changes use existing impact/re-review rules.
 
@@ -40,8 +40,8 @@ Check when code scope is associated or changed, before entering implementation,
 
 1. Enumerate all delivery directories in the accessible configured material root and any other explicitly known/authorized material roots or delivery locations. Use `scan <known-root>` to read `.aimship/state.json` summaries; deduplicate deliveryId and report conflicting copies; do not limit the search to recent folders. Do not scan the whole disk, code trees, processes, PRDs or full histories. Do not discover unknown custom roots by searching the home directory. Report roots checked and inaccessible, invalid or unknown-format records; unseen custom roots and non-Aimship work remain outside the check.
 2. Exclude this delivery by `deliveryId`. Compare `repositories[].path` (the actual checkout/worktree root), role, `currentRun`, relevant `stageRuns` scope/progress, `outcome`, `next` and recorded update time. Repository IDs are local to each delivery and are not global repository identity. Use already recorded repository identity; when needed and accessible, read only local Git root/common-directory metadata for the associated paths to distinguish linked worktrees. Normalize existing paths to their actual location; nested paths in one checkout are not independent isolation. Distinct independent checkouts may share a recorded repository identity even with different Git directories. If identity/location cannot be established, report it as unknown rather than assuming separation.
-3. Include older active, blocked or uncertain deliveries. A `done` stage, completed handoff, old timestamp or declined acceptance alone does not close a delivery. A recorded met goal with no recorded remaining code work is ended; otherwise use the existing explicit closing conclusion if needed. `not-met` or `unknown` is not automatically ended. Read only the relevant Scope/plan/conclusion section when state summaries cannot establish writing intent or closure. Do not rewrite another delivery's state. Ended deliveries are not active writers, although their unmerged results or known dependencies can still matter.
-4. Compare actual writing intent and locations using the table below. A stage label alone is not permission to write code. Keep one brief result in the existing Scope/plan or results section, linked from the current delivery's existing references when needed: check occasion, roots/limits, relevant delivery IDs and recorded stages, actual directories, known dependencies and chosen arrangement. State stays authoritative; do not add a registry, index, second progress ledger or service.
+3. Include older active, blocked or uncertain deliveries. A `done` stage, completed handoff, old timestamp or declined acceptance alone does not close a delivery. A recorded met goal with no recorded remaining code work is ended; otherwise use the existing explicit closing conclusion if needed. `not-met` or `unknown` is not automatically ended. Read only the relevant engineering plan/conclusion section when state summaries cannot establish writing intent or closure. Do not rewrite another delivery's state. Ended deliveries are not active writers, although their unmerged results or known dependencies can still matter.
+4. Compare actual writing intent and locations using the table below. A stage label alone is not permission to write code. Keep one brief result in the existing engineering plan or results section, linked from the current delivery's existing references when needed: check occasion, roots/limits, relevant delivery IDs and recorded stages, actual directories, known dependencies and chosen arrangement. State stays authoritative; do not add a registry, index, second progress ledger or service.
 
 | Recorded situation | Action |
 | --- | --- |
@@ -55,32 +55,31 @@ Records can be stale and cannot detect all other work. Do not switch another ses
 
 ## Agree an ordered arrangement
 
-Use the standard delivery sequence for a developer responsible for a requirement: requirements and acceptance criteria → technical design with applicable interface/SQL/interaction artifacts → test cases → plan → implementation batches with batch review → overall review → verification → handoff and acceptance. Do not offer an arbitrary checklist of core stages or a pluggable workflow. Internal runs and batches organize this sequence. Requirements and scope alignment are always needed; use the fixed PRD/Scope conditions in [document patterns](document-patterns.md). Adopt adequate existing artifacts as inputs without claiming their stages were newly executed. Do not create empty stage runs or templates.
+Use the standard delivery sequence for a developer responsible for a requirement: requirements and acceptance criteria → technical design with applicable interface/SQL/interaction artifacts → test cases → plan → implementation batches with batch review → overall review → verification → handoff and acceptance. Do not offer an arbitrary checklist of core stages or a pluggable workflow. Internal runs and batches organize this sequence. Requirements and scope alignment are always needed; use the fixed PRD conditions in [document patterns](document-patterns.md). Adopt adequate existing artifacts as inputs without claiming their stages were newly executed. Do not create empty stage runs or templates.
 
-Show the selected order and endpoint. If the user already specified or accepted this arrangement, record the decision and proceed. An unanswered proposal remains a proposal. Once agreed, follow the order; adding, dropping or reordering work needs a reason and an updated record. Important changes follow [change flow](sources-and-changes.md). A stage may recur as distinct instances with stable IDs and explicit scopes.
+Start requirements intake using this standard sequence. Do not offer a default full-delivery/design-only/initialization-only choice. State the normal endpoint when presenting requirements and record the user’s actual requirement confirmation; explicit limitations or pauses take precedence. Starting Aimship does not approve later documents, code changes, merge, deployment or database execution. Once confirmed, follow the order; material changes follow [change flow](sources-and-changes.md). A stage may recur as distinct instances with stable IDs and explicit scopes.
 
 Explain each design's key decisions, why they fit the requirements, tradeoffs, artifact location and remaining questions. Ordinary internal implementation choices stay with the agent. Ask for material changes to goals, scope, external behavior, compatibility, significant cost, data handling or an explicit technical commitment. Follow [document review](document-review.md): present each selected reviewable document after self-check and pause for explicit approval. An approval releases the next authorized work; use the session boundary interaction below, without a second approval or start confirmation.
 
-Standard development order: PRD/Scope → technical design → interface/SQL → test cases → plan → implementation/review/verification → handoff. Generate only applicable artifacts. Inspect existing formal materials and register adoption without treating adoption as approval. Respect an explicitly limited commission without presenting it as standard complete delivery.
+Standard development order: PRD → technical design → interface/SQL → test cases → plan → implementation/review/verification → handoff. Generate only applicable artifacts. Inspect existing formal materials and register adoption without treating adoption as approval. Respect an explicitly limited commission without presenting it as standard complete delivery.
 
 ### Standard completeness and limited scope
 
 New deliveries use `deliveryPolicy: {version: 1}`. `outcome.goal` describes the agreed scope and `outcome.acceptance` the actual user decision; neither alone means standard complete delivery. The tool reports a separate derived completion assessment. Standard completion requires reviewed requirements/design/cases/plan and applicable artifacts, completed implementation with passing batch and overall review, passing independent verification, handoff and explicit final acceptance. Record review coverage with reviewOf implementation IDs and overall: true for the overall review. Records validate structure/evidence references, not truth or user identity; inspect actual results and coverage.
 
-If the user explicitly excludes cases and testing (or limits the commission to an earlier endpoint), explain the consequence once, preserve that scope decision in existing PRD/Scope/change records, and register `deliveryPolicy.partialRef`. Do not quietly add the excluded work or repeatedly persuade the user. Finish the authorized work and hand off the untested or otherwise limited result, recording omitted work and remaining limits. Its agreed scope can be met and accepted, but its completion assessment stays partial-scope, never standard-complete or verified. No special external-testing mode or extra documents are needed. Existing implementation/approval dependencies still apply. Scope changes preserve the earlier goal/decision/history; started runs are not erased to manufacture completion.
+If the user explicitly excludes cases and testing (or limits the commission to an earlier endpoint), explain the consequence once, preserve that scope decision in existing PRD/change records, and register `deliveryPolicy.partialRef`. Do not quietly add the excluded work or repeatedly persuade the user. Finish the authorized work and hand off the untested or otherwise limited result, recording omitted work and remaining limits. Its agreed scope can be met and accepted, but its completion assessment stays partial-scope, never standard-complete or verified. No special external-testing mode or extra documents are needed. Existing implementation/approval dependencies still apply. Scope changes preserve the earlier goal/decision/history; started runs are not erased to manufacture completion.
 
 Current completion claims require the recorded scope, approvals and actual results. Saved business history does not replace current evidence.
 
 ## Stage references
 
-Read the reference for the current responsibility, not all thirteen on every turn.
+Read the reference for the current responsibility, not all stage references on every turn.
 
 | Responsibility | Read when | Reference |
 | --- | --- | --- |
 | frame | Clarifying a problem or exploring a goal | [frame](stages/frame.md) |
 | requirements | Defining or refining requirements | [requirements](stages/requirements.md) |
 | prototype | Designing interaction and its states | [prototype](stages/prototype.md) |
-| scope | Adopting inputs and aligning this commission | [scope](stages/scope.md) |
 | diagnose | Investigating cause or feasibility | [diagnose](stages/diagnose.md) |
 | tech-design | Choosing an engineering approach | [tech-design](stages/tech-design.md) |
 | contract | Defining interfaces and exchanged data | [contract](stages/contract.md) |
@@ -111,13 +110,13 @@ Use the installed tool's documented state protocol. Read the current revision be
 
 Important semantic changes retain historical review and test facts, mark affected conclusions for review and update the current editable authority. Do not overwrite external adopted sources. See [sources and change flow](sources-and-changes.md).
 
-At delivery creation / requirements confirmation, record the default session suggestions in existing state: requirements; technical design plus applicable interface/SQL/prototype; cases; plan; each implementation batch including its review/repairs; overall review; each verification batch. `sessionGroup` is advisory and shown in status.md. Adjust it to actual applicable work and context without reapproving unchanged content. Overall review remains a separate suggested session; a single review may cover both batch and whole scope when explicitly recorded. Never introduce a session approval stage, a blocked state for not switching, or a requirement to prove that the session ID changed.
+At each stage boundary, save the completed work and self-check, show its artifacts, current stop and next suggestion, then stop. Recommend a new session without requiring one. Work continuously inside a stage; do not pause after each small step. Existing sessionGroup is only contextual grouping, never permission to cross stages. Each implementation batch and its batch review retain their own results; overall review remains distinct. Do not create a session approval record or require proof of a changed session ID.
 
 For a reviewable draft, show only its current stage/status, document entry and review focus; ask for explicit approval or questions. Do not issue the next stage's continuation prompt before approval. Discussion and edits retain the stop; self-check and present revisions again.
 
 After explicit approval, in one handling of the message: preserve the actual decision source and exact reviewed version; update approval, current run and next work together as appropriate; inspect the returned saved revision and view result (reread when uncertain); then report the saved outcome and next suggestion. Do not ask the user separately to approve saving or the prompt. If state saving failed, do not claim success; if state saved but the view failed, repair the view at that revision without replaying the approval. Only give the handoff entry once the save is confirmed.
 
-Within the same suggested group, continue the next authorized item immediately. At a group boundary, report completed work and next work, suggest a new session and give the concise continuation entry; do not execute the next group in the same response. If the user says to continue here, do so without another approval or mandatory switch; advance currentRun to the actual work. Review or verification failures first lead to repair/re-review through the existing change flow, not mechanical advancement. At final handoff there is no pointless next-session entry.
+After a stage is saved, wait for explicit approval where document review is required, or for continuation where it is not. An approval may include “continue”; record it and proceed without a second confirmation. Approval without a continuation request leaves a saved boundary. Never treat “continue” alone as document approval. Continuing in this session needs no session permission. Stage-internal work and authorized repair remain continuous; failures lead to repair/re-review rather than mechanical advancement. At final handoff do not invent a next-session task.
 
 Default handoff output is current status, artifact and next suggestion, followed by one line in the saved delivery language using the actual absolute directory: “Use Aimship to continue delivery <actual directory>; first read the current state and relevant formal documents, then continue the recorded work.” In Chinese: “使用 Aimship 继续交付「实际目录」，先读取当前状态和相关正式文档再接续。” Do not output placeholders or long prompts at every stage. Full tasks, inputs, deliverable requirements, review stops and unresolved matters stay in existing state/formal documents/rules, not a new prompt or handoff file. A complete prompt may be generated when requested, without an arbitrary length limit.
 

package/skills/aimship/references/document-patterns.md

@@ -6,23 +6,23 @@ One request has one directory. New deliveries default to separate folders under
 
 ## Input and output conditions
 
-Initialization may start with preserved source/request.md before a PRD/Scope is formed. Do not generate an empty template for init. Register the substantive requirement draft and switch goalRef when ready; before completing requirements or dependent work, use the existing formal artifact and approval rules below. Unknown artifact conditions stay null until determined, distinct from false/none/[] (not applicable).
+Initialization may start with preserved source/request.md before a PRD is formed. Do not generate an empty template for init. Register the substantive requirement draft and switch goalRef when ready; before completing requirements or dependent work, use the existing formal artifact and approval rules below. Unknown artifact conditions stay null until determined, distinct from false/none/[] (not applicable).
 
-Author current requirements in `prd.md`, including scope. Adopt an authoritative PRD/prototype through `scope.md`, preserving source/version/original IDs and gaps. Prior authorship does not make an adopted source editable. Only explicit maintenance of an editable authoritative PRD that completely expresses this commission's scope/authorization/endpoint permits registered reuse without another PRD/Scope. Scattered ideas/screenshots/reference cases are inputs to a PRD, not automatically authoritative requirements.
+Use one registered PRD as the requirement authority. If an existing PRD fully fits this commission, retain its adopted version in source/ and register that file as kind prd, mode reused, authority adopted; keep its text, numbering and outline unchanged. If only part applies, author prd.md for this iteration with source/version, included and excluded work and acceptance; retain corresponding original business IDs. Without a PRD, clarify the request and write prd.md. There is no separate Scope document or approval. Existing approval is reusable only with actual evidence for the current content; otherwise confirm requirements. Adoption alone is not approval.
 
-Interaction changes require a prototype when existing adopted material does not cover them and that work lies within the commissioned endpoint. New HTML uses `prototype/index.html`; register other agreed formats or reused entries. No interaction change means no invented prototype. Investigation/clarification-only requirements describe that commission and leave future development undefined.
+A prototype is optional according to the work. Reuse adequate supplied material; create a prototype only when it helps clarify the agreed interaction and is selected for this delivery. Otherwise describe behavior in the PRD/design. A selected prototype keeps its document approval before implementation. New HTML uses `prototype/index.html`; other agreed formats may be registered.
 
 `test-design` precedes `plan` in standard delivery; both reviewable documents need explicit approval. If the user explicitly excludes cases/testing, record the limited scope once and do not generate empty testing artifacts or call the result standard complete delivery. `plan` must finish before first implementation, even one small batch. `plan.md` holds both planned TASK/B records and actual execution, distinctly; state holds stage progress. `testing.md` holds cases/coverage and appended RUN records; verification follows overall review. Verify-only may register existing cases with version/coverage, without claiming test-design occurred. Review-only does not require implementation/tests. No arbitrary small-task merging, `implementation.md`, `test-plan.md`, `verification.md`, or `results.md` for new work.
 
 Use `tech-design.md`. HTTP changes use `openapi.yaml` or the registered engineering authority; no extra contract wrapper. Non-HTTP formats are explicitly registered. Database changes require independent `database.sql` (one target) or `database-<id>.sql` per target in contract, after technical-design approval and before test cases. Technical design records the data approach and SQL plan without requiring finished SQL. SQL headers identify target/dialect/version/schema basis/conditions; ordered sections cite requirements/design. Never substitute a Markdown block or migration reference, or execute/change migration mechanisms without authorization.
 
-`diagnosis.md` belongs only to an explicitly selected independent investigation. Known-cause bugs and ordinary development debugging do not add diagnose. Major unknowns require a recorded stage adjustment; hold dependent work. Implementation defects go to implementation, design errors to design, requirement gaps to PRD/Scope, incorrect expectations to the testing document.
+`diagnosis.md` belongs only to an explicitly selected independent investigation. Known-cause bugs and ordinary development debugging do not add diagnose. Major unknowns require a recorded stage adjustment; hold dependent work. Implementation defects go to implementation, design errors to design, requirement gaps to PRD, incorrect expectations to the testing document.
 
 ## Identities and references
 
 Use readable IDs for different entities: REQ for requirements, AC for acceptance, TASK/B for implementation, TC for cases, REV/RUN for review/execution records, and CHG/Q/PAGE where useful. Start each kind at 001. Keep the same obligation's ID across documents; do not give different entities the same ID. Users should be able to search an ID in ordinary Markdown. Do not require hyperlinks or any reader's HTML support.
 
-Define each ID once in its owning document, in a table's first column, a heading or a bullet, with substantive content: REQ/AC and optional PAGE mappings in PRD or Scope, TASK/B in plan, TC/RUN in testing, REV in review, CHG in change log. Put requirements, acceptance, batches, tasks and cases in their existing corresponding sections. The same document's coverage, summaries and execution records, as well as other documents, may cite those numbers in prose or tables without redefining them. Q records may be defined where the question is resolved. For example:
+Define each ID once in its owning document, in a table's first column, a heading or a bullet, with substantive content: REQ/AC and optional PAGE mappings in PRD, TASK/B in plan, TC/RUN in testing, REV in review, CHG in change log. Put requirements, acceptance, batches, tasks and cases in their existing corresponding sections. The same document's coverage, summaries and execution records, as well as other documents, may cite those numbers in prose or tables without redefining them. Q records may be defined where the question is resolved. For example:
 
 ```markdown
 | ID | Requirement | Acceptance |
@@ -36,9 +36,9 @@ Define each ID once in its owning document, in a table's first column, a heading
 
 A case can define TC-001 and cite AC-001; its later RUN record cites TC-001. Use a distinct REV/RUN number for each actual review/execution and retain failed records. State identifies which implementation a review covers; ordinary record text identifies tested code, commands, results and evidence. Document versions and content-bound approval remain required; there is no per-item version/namespace/retirement protocol.
 
-Bare IDs refer to the current local authority. To cite an external number, use that ID as the visible label of a link to its Markdown source file; the reader opens the file and searches the number. A file-qualified record locator is also checked without requiring a working browser anchor. The file must be readable and the numbered record unique and substantive; a path alone is not proof. An explicitly registered editable Markdown PRD may supply readable REQ/AC definitions without being copied or forced into this outline; unparsed source content remains unchecked. Preserve originals and source-retention boundaries.
+Bare IDs refer to the current local authority. To cite an external number, use that ID as the visible label of a link to its Markdown source file; the reader opens the file and searches the number. A file-qualified record locator is also checked without requiring a working browser anchor. The file must be readable and the numbered record unique and substantive; a path alone is not proof. An explicitly registered reused Markdown PRD may supply readable business IDs and acceptance definitions without being copied or forced into this outline; unparsed source content remains unchecked. Preserve originals and source-retention boundaries.
 
-Do not insert HTML anchor tags, machine JSON comments, an index, sidecar or traceability matrix. Do not automatically renumber unchanged requirements. Keep external source IDs in their original material; describe adopted obligations and their source correspondence in the ordinary Scope. Basic checks recognize local IDs in definitions and citations, reject duplicates, missing references and empty records, and require REQ/AC, TC or TASK records when completing their respective work or recording a passing document self-check. Define B records in the batch section, TASK records in the task section and TC records in the case section, never below the execution boundary. Execution text may cite existing batches, tasks and cases. These checks do not prove that every business obligation or test assertion is covered; the Agent and document review must check meaning.
+Do not insert HTML anchor tags, machine JSON comments, an index, sidecar or traceability matrix. Do not automatically renumber unchanged requirements. Keep adopted business IDs (for example FR-001 and AC-001); a partial-iteration PRD describes their source correspondence without new numbering. Basic checks recognize local IDs in definitions and citations, reject duplicates, missing references and empty records, and require substantive requirement/AC, TC or TASK records in newly authored documents when completing their respective work or recording a passing document self-check. Define B records in the batch section, TASK records in the task section and TC records in the case section, never below the execution boundary. Execution text may cite existing batches, tasks and cases. These checks do not prove that every business obligation or test assertion is covered; the Agent and document review must check meaning.
 
 ## Saving and checking
 

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

@@ -1,12 +1,12 @@
 # Review one document, then continue
 
-The selected development order is requirements intake / PRD or Scope → technical design → interface contract and independent SQL when applicable → test cases → implementation plan → implementation with batch and overall review → independent verification → handoff and acceptance. Test design precedes planning in the standard delivery. An explicitly limited scope can omit cases/verification, but is a partial handoff, not standard complete delivery. Keep the agreed endpoint: prototype and investigation have their own reviewable outputs; design-only stops at the commissioned design. Review-only and verify-only use their existing object/case basis without inventing implementation or uncommissioned upstream stages. Frame clarifies inputs; requirements/Scope provides the reviewed requirement authority. Do not generate empty stages or templates. When two responsibilities share the same already-approved current document, reuse that exact approval without asking twice.
+The selected development order is requirements intake / PRD → technical design → interface contract and independent SQL when applicable → test cases → implementation plan → implementation with batch and overall review → independent verification → handoff and acceptance. Test design precedes planning in the standard delivery. An explicitly limited scope can omit cases/verification, but is a partial handoff, not standard complete delivery. Keep the agreed endpoint: prototype and investigation have their own reviewable outputs; design-only stops at the commissioned design. Review-only and verify-only use their existing object/case basis without inventing implementation or uncommissioned upstream stages. Frame clarifies inputs; requirements provides the reviewed requirement authority. Do not generate empty stages or templates. When two responsibilities share the same already-approved current document, reuse that exact approval without asking twice.
 
-For requirements/Scope, prototype, independent diagnosis, technical design, each interface/SQL document, test cases and implementation plan:
+For requirements, prototype, independent diagnosis, technical design, each interface/SQL document, test cases and implementation plan:
 
 1. Generate or revise the concrete document, preserving its fixed outline, identities and references. Self-check its content, coverage, consistency and actual entry. Mark production complete separately from this self-check.
 2. Save the self-check record for that version/content. Give the user the document link, a short summary of decisions and unresolved questions, current stage/review status and review focus. Do not give the next-stage continuation prompt while review is pending. Stop for human review. For several interface/SQL files, name and present each document individually; do not ask approval of an unspecified supporting package or introduce a scope-selection interface.
-3. An explicit user approval of the presented document is sufficient. Record the actual message/decision source and exact document version/content, save and inspect the result, then follow the core session interaction: begin the next item within the current group (including the next applicable interface/SQL document); at a group boundary give the saved result and concise continuation entry, without executing the next group in that response. A request to continue here proceeds directly. Do not ask again whether to start, and do not assess how carefully the user read it. A question, silence or “show me the results” is not approval.
+3. Record an explicit approval with its actual decision source and exact current document version/content. Existing approval of that same content may be recorded without asking again; check it rather than inferring from a file's presence. Save and inspect the result. Stop at the stage boundary; if the message also asks to continue, proceed without another confirmation. Within a multi-document stage, continue preparing the next applicable document after its prerequisite approval. Questions, silence, “continue” alone or “show me the results” are not approval.
 4. Answer questions while retaining the stop. For requested edits, record `changes-requested`, revise, self-check and present again. Neither `done`, an existing file, nor an Agent review substitutes for user approval. A prior explicit decision may be recorded if it really identifies this exact content; never manufacture one from general implementation permission.
 
 Do not ask human approval for every execution log, batch review or test result. Once the plan and required documents are approved, authorized implementation, Agent review, defect repairs within those requirements and retests can continue, showing results. New material decisions and production actions still need their own authorization. Final `outcome.acceptance` is a separate user decision; document approval does not accept the delivery, merge, deploy or execute SQL.

package/skills/aimship/references/hosts.md

@@ -14,7 +14,7 @@ Installation discovery, actual selection, model behavior, directory access and c
 
 After compaction or manual switching, reload the fixed-version core, state and current-stage inputs if missing. Do not rely on an AI tool retaining all Skill text. If even the binding location is absent, request the delivery path. Re-invoking an entry to restore context continues the existing delivery; it does not create another one.
 
-When changing AI tools, use the same delivery directory and state; do not duplicate requirements, Scope or design to establish a new session. Permissions must be granted separately in each AI tool. Keep one writing tool/session for the delivery. User-facing entry/reload and lifecycle instructions are in [the user guide](../../../docs/guide.md#hosts).
+When changing AI tools, use the same delivery directory and state; do not duplicate requirements or design to establish a new session. Permissions must be granted separately in each AI tool. Keep one writing tool/session for the delivery. User-facing entry/reload and lifecycle instructions are in [the user guide](../../../docs/guide.md#hosts).
 
 Do not move or replace a user-owned workspace. Check the actual directory identity and access before continuing.
 

package/skills/aimship/references/recovery.md

@@ -1,6 +1,6 @@
 # Resume, recover and update
 
-Start by locating the same delivery. Read state, current goal/Scope and next-step references. Verify actual artifacts or related changes only when needed to act or reuse a conclusion. Restoring context is not a new test result. If the directory is ambiguous, ask for the missing location, not already recorded goals and decisions.
+Start by locating the same delivery. Read state, current goal/PRD and next-step references. Verify actual artifacts or related changes only when needed to act or reuse a conclusion. Restoring context is not a new test result. If the directory is ambiguous, ask for the missing location, not already recorded goals and decisions.
 
 A revision conflict means another writer or manual change intervened. Read and reconcile; do not force overwrite. One writing session per delivery remains the supported workflow. On malformed state, preserve the damaged file, inspect the last recovery copy and actual subsequent artifacts, then explicitly recover only the trustworthy facts. If no reliable copy exists, reconstruct from readable requirements/change/results, marking uncertain authorization and results unknown. Never rerun a side effect just because state is incomplete.
 
@@ -26,7 +26,7 @@ Current deliveries require the document approval and delivery policies. Their re
 
 ## Early initialization and schema 4
 
-New initialization saves the selected language and location basis and may have only source/request.md, .aimship/state.json and status.md; technical conditions and endpoint may be null. Missing PRD/Scope 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.
+New initialization saves the selected language and location basis and may have only source/request.md, .aimship/state.json and status.md; technical conditions and endpoint may be null. 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.
 
 If source exists but state does not, inspect the original input and ownership before completing init at that location. If state exists, resume its ID instead; init deliberately rejects duplicates. A failed view or interrupted receipt never requires a second init. Inspect state then repair only the view at the saved revision, preserving manual status edits. Do not remove locks without checking that the writer stopped.
 

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

@@ -2,9 +2,9 @@
 
 ## Adopt without rewriting the source
 
-Preserve the original request once. If source/request.md changes after initialization, restore its original bytes before continuing state writes; an unrelated update must not adopt a new source digest. Record subsequent intent in the editable PRD/Scope and a CHG when meaning changes. If the original cannot be recovered reliably, preserve the conflicting material and report the blocker instead of replacing the recorded basis. Preserve external PRD, prototype, handover-note and image originals at their supplied locations. Retain the adopted versions as described under [location and version discipline](#location-and-version-discipline); neither storing files nor extracting text establishes visual or interaction validation.
+Preserve the original request once. If source/request.md changes after initialization, restore its original bytes before continuing state writes; an unrelated update must not adopt a new source digest. Record subsequent intent in the editable PRD and a CHG when meaning changes. If the original cannot be recovered reliably, preserve the conflicting material and report the blocker instead of replacing the recorded basis. Preserve external PRD, prototype, handover-note and image originals at their supplied locations. Retain the adopted versions as described under [location and version discipline](#location-and-version-discipline); neither storing files nor extracting text establishes visual or interaction validation.
 
-Use existing requirement IDs. If none exist, assign local IDs mapped to source sections, pages, prototype screens or short excerpts. Scope records the current goal, inclusion/exclusion, source mappings, acceptance, constraints, conflicts and adopted decisions. Do not transcribe an entire adequate PRD or create a second one merely to fit a template. Self-owned requirements may also carry Scope.
+Use existing requirement IDs. If none exist, assign local IDs mapped to source sections, pages, prototype screens or short excerpts. A partial-iteration PRD records the current goal, inclusion/exclusion, sources, acceptance, constraints and decisions. A complete applicable PRD is adopted directly. Do not transcribe an entire adequate PRD or create a second one merely to fit a template.
 
 A prototype and PRD can disagree; neither file type nor modification date automatically wins. Record the conflict and decision authority. Pause dependent work when a material answer is missing, while continuing independent authorized work. Do not contact the external author automatically. If a new version arrives, adopt it separately, assess relevant differences and retain the old basis. Indicate any external document still awaiting its author's correction.
 
@@ -21,7 +21,7 @@ Markdown/HTML are principal carriers, not a format whitelist. Images, screenshot
 ## One record for an important change
 
 1. Persist the reason, old/new intent, decision/source or open question, affected artifacts/runs and uncertainties in one change record.
-2. Update editable requirements/Scope, design, contracts, independent SQL, plan and test cases where affected. Preserve external sources and necessary old excerpts.
+2. Update editable requirements, design, contracts, independent SQL, plan and test cases where affected. Preserve external sources and necessary old excerpts.
 3. Mark affected conclusions as needing review; historical records keep their original object and outcome. Leave unrelated results intact.
 4. Review affected work and execute affected verification as required by the goal, then close the same change with its result and remaining issues.
 
@@ -32,9 +32,9 @@ Formatting/typo corrections do not require semantic re-review. Implementation bu
 The agent preserves the necessary formally adopted versions under `source/`, alongside `source/request.md`; the user need not move or manually copy originals. This is source evidence retention, not a second editable delivery or automatic synchronization.
 
 - 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 current PRD/Scope, 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` or `scope.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.
-- Adopt an original's new version as a separate record, assess its impact and re-review affected work. 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.
+- 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.
 
 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

@@ -24,4 +24,4 @@ Use openapi.yaml or the registered authoritative contract when interfaces apply.
 
 ## Human document review
 
-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: continue within the group, or suggest a new session at its boundary; continue here if requested. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.
+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 and suggest a new session; 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.

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

@@ -26,4 +26,4 @@ Only a commissioned independent investigation produces diagnosis.md. Known-cause
 
 ## Human document review
 
-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: continue within the group, or suggest a new session at its boundary; continue here if requested. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.
+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 and suggest a new session; 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.

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

@@ -20,4 +20,6 @@ Use [the shared core](../core.md) for state, evidence and continuation rules. Re
 
 ## Artifact contract
 
-Use the selected PRD/Scope requirement entry. 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 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.
+
+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.

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

@@ -2,7 +2,7 @@
 
 ## Basis
 
-Read the current goal/Scope, explicit goal revisions, deliverables, applicable review/verification and unresolved work.
+Read the current goal/PRD, explicit goal revisions, deliverables, applicable review/verification and unresolved work.
 
 ## Work and result
 
@@ -23,3 +23,5 @@ Use [the shared core](../core.md) for state, evidence and continuation rules. Re
 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 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.

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

@@ -10,7 +10,7 @@ Before entering implementation, or when a code working directory changes, apply
 
 ## Continue when
 
-The planned batch is implemented and known deviations are resolved or explicitly routed. Move to this batch’s review; running a complete test suite is not a new batch gate.
+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.
 
 ## Decisions and blockers
 
@@ -23,3 +23,5 @@ Use [the shared core](../core.md) for state, evidence and continuation rules. Re
 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.
 
 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.
+
+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.

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

@@ -2,7 +2,7 @@
 
 ## Basis
 
-Read approved current PRD/Scope, test cases/coverage for standard delivery (or the explicit limited-scope basis), applicable design/contracts and relevant repository boundaries.
+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
 
@@ -24,4 +24,4 @@ Use plan.md. Preserve the ordinary template headings and section order. Follow [
 
 ## Human document review
 
-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: continue within the group, or suggest a new session at its boundary; continue here if requested. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.
+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 and suggest a new session; 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.

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

@@ -14,7 +14,7 @@ The relevant interactions and states are clear and consistent with current requi
 
 ## Decisions and blockers
 
-Missing visual/browser tools require an explicit unverified scope. Resolve contradictory behavior through requirements/Scope; do not silently alter external prototypes.
+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.
 
@@ -24,4 +24,4 @@ Use the registered prototype entry (new HTML: prototype/index.html). Follow [doc
 
 ## Human document review
 
-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: continue within the group, or suggest a new session at its boundary; continue here if requested. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.
+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 and suggest a new session; 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.

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

@@ -6,7 +6,7 @@ Read the preserved original input, problem findings, adopted material and curren
 
 ## Work and result
 
-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; external material is adopted through Scope rather than rewritten.
+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. Reuse an evidenced approval of the current content; otherwise ask for requirement confirmation.
 
 ## Continue when
 
@@ -20,8 +20,8 @@ Use [the shared core](../core.md) for state, evidence and continuation rules. Re
 
 ## Artifact contract
 
-Use the selected PRD/Scope requirement entry. 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 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.
 
 ## Human document review
 
-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: continue within the group, or suggest a new session at its boundary; continue here if requested. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.
+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 and suggest a new session; 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.

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

@@ -22,4 +22,6 @@ Use [the shared core](../core.md) for state, evidence and continuation rules. Re
 
 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. The batch review shares that batch’s suggested session, while overall review has its own suggestion. Resolve findings before continuation; a suggestion never substitutes for a passing review.
+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.

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

@@ -2,7 +2,7 @@
 
 ## Basis
 
-Read current requirements/Scope, relevant engineering instructions, architecture, schema and diagnosis.
+Read current requirements, relevant engineering instructions, architecture, schema and diagnosis.
 
 ## Work and result
 
@@ -26,4 +26,4 @@ Technical design does not require finished SQL before its review. After its appr
 
 ## Human document review
 
-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: continue within the group, or suggest a new session at its boundary; continue here if requested. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.
+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 and suggest a new session; 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.

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

@@ -24,4 +24,4 @@ Use testing.md. Preserve the ordinary template headings and section order. Follo
 
 ## Human document review
 
-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: continue within the group, or suggest a new session at its boundary; continue here if requested. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.
+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 and suggest a new session; 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.

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

@@ -23,3 +23,5 @@ Use [the shared core](../core.md) for state, evidence and continuation rules. Re
 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.
 
 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.
+
+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.

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

@@ -10,13 +10,13 @@ Identify this delivery, revision and adopted inputs. Replace guidance with actua
 
 Separate known facts, requirements and assumptions. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
-## Scope, engineering objects and endpoint
+## Scope and delivery endpoint
 
-Included/excluded work, repository IDs, authorization and endpoint. Replace guidance with actual content; explain inapplicability, never prefill a result.
+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
 
-REQ, 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.
+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
 
@@ -31,4 +31,4 @@ AC, requirement reference, condition, operation, decidable expected result. Repl
 Selected order, artifact locations/reuse, dependencies, Q with impact/status/decision source. Replace guidance with actual content; explain inapplicability, never prefill a result.
 
 
-<!-- Arrangement guidance: standard delivery sequence and applicable artifacts; preserve an explicit limited-scope decision without claiming standard completeness. Suggested session groups live in state, are shown in status, and are not approval conditions. -->
+<!-- Arrangement guidance: standard delivery sequence and applicable artifacts; preserve an explicit limited-scope decision without claiming standard completeness. Save and stop at each completed stage; session suggestions are not approval conditions. -->

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

@@ -1,27 +0,0 @@
-# Align this delivery
-
-## Basis
-
-Read the user commission, current/adopted requirements, source versions and proposed engineering objects.
-
-## Work and result
-
-Record this goal, included/excluded requirements, source mappings, endpoint, authorization boundaries and acceptance. Explain external conflicts and adoption decisions. After associating or changing code scope, use the [recorded-overlap check](../core.md#independent-deliveries-and-recorded-overlap). Record actual checkout locations and read-only versus intended write scope. Agree the ordered stages based on gaps; keep stage progress only in state. Self-owned requirements may carry this information.
-
-## Continue when
-
-The goal, authority and scope are clear enough for the selected next work, with relevant decisions resolved or dependent work held.
-
-## Decisions and blockers
-
-Material conflicting sources or uncertain authority needs clarification; format differences alone do not. Never choose source priority by filename or date.
-
-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 the selected PRD/Scope requirement entry. 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.
-
-## Human document review
-
-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: continue within the group, or suggest a new session at its boundary; continue here if requested. Questions or edit requests retain the stop; edits require self-check and re-review. Production `done` is separate from approval and final acceptance.

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

@@ -1,34 +0,0 @@
-# scope
-
-Delivery: <deliveryId from init>; document revision: <revision>.
-
-## Document information and source versions
-
-Delivery identity and adopted versions. Replace guidance with actual content; explain inapplicability, never prefill a result.
-
-## Goal, engineering objects and endpoint
-
-Actual repository IDs, authorized objects and endpoint. Replace guidance with actual content; explain inapplicability, never prefill a result.
-
-## Source mapping and adopted scope
-
-Source/version/original ID or section, adoption decision, requirement reference, AC and gaps; do not copy the full PRD. Replace guidance with actual content; explain inapplicability, never prefill a result.
-
-## Exclusions and constraints
-
-Explicitly delimit this commission. Replace guidance with actual content; explain inapplicability, never prefill a result.
-
-## Conflicts, gaps and supplementary decisions
-
-Preserve sources; identify decision authority and pending source updates. Replace guidance with actual content; explain inapplicability, never prefill a result.
-
-## Acceptance basis
-
-AC, requirement/source identity, conditions, actions and expected results. Replace guidance with actual content; explain inapplicability, never prefill a result.
-
-## Authorization, questions and stage arrangement
-
-Selected order, artifact locations/reuse, permissions and open Q. Replace guidance with actual content; explain inapplicability, never prefill a result.
-
-
-<!-- Arrangement guidance: standard delivery sequence and applicable artifacts; preserve an explicit limited-scope decision without claiming standard completeness. Suggested session groups live in state, are shown in status, and are not approval conditions. -->