aimship 0.1.0-preview.21 → 0.1.0-preview.22

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "aimship",
-  "version": "0.1.0-preview.21",
+  "version": "0.1.0-preview.22",
   "description": "Explicit, goal-driven delivery workflow for coding agents",
   "license": "MIT",
   "type": "module",

package/skills/aimship/references/core.md

@@ -30,7 +30,7 @@ This flow follows explicit Aimship activation in the first and every new session
 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. Separate existing materials retained or copied from documents newly authored or revised and delivery records newly created. Report “unchanged” only when supported by the actual operations and source evidence. For a complete unchanged supplied PRD with clear intent to deliver from it, report input adoption without requesting repeated source approval; clarify only actual uncertainties. On first initialization, add one neutral reminder with the actual directory: add it to the current project/workspace, ignoring this if already added. No tool-specific instructions or membership check are needed. Then continue authorized requirement clarification, unless the user requested a stop.
 
-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. AI-authored or substantively revised requirements and subsequent selected reviewable outputs keep their self-check/explicit-approval stops. An unchanged supplied PRD/prototype uses mode input and its actual adoption-request basis; self-check makes it usable input, not human-approved AI output. Internal management records are not separately reviewed. 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. AI-authored or substantively revised requirements and subsequent selected reviewable outputs keep their self-check/explicit-approval stops. An unchanged supplied PRD/prototype uses mode input and its actual adoption-request basis; self-check makes it usable input, not human-approved AI output. Internal management records are not separately reviewed. 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.
 
 “Clarify requirements first” describes current work, not a requirements-only endpoint or full development permission. The standard stage sequence is the default, not a choice to ask again in the receipt or next action. Clarify only a concrete unresolved scope or endpoint condition that affects the work; do not ask whether to follow the standard sequence. Use the standard endpoint for normal delivery; record an explicit limitation when one is actually given. Keep known conditions when available; false/none/[] mean explicitly not applicable, not unknown. Later changes use existing impact/re-review rules.
 
@@ -96,7 +96,13 @@ Use [routing](routing.md) to select the current work unit, then read its stage c
 | verify | Executing the agreed checks and recording evidence | [verify](stages/verify.md) |
 | handoff | Delivering against the current goal or handing over incomplete work | [handoff](stages/handoff.md) |
 
-Each run records its scope, required inputs, results and progress. A result may be a section in a shared document. A `done` run records completed work, not human approval. Adopted user input is distinct from reviewed AI output. Proceed when required AI-output approvals or adopted-input checks match current content, this run's requirements are met, the next inputs exist, authorization covers it and no relevant unresolved issue blocks it. An issue blocks only dependent work; changing the order to continue other work is still an explicit plan change.
+### Begin or resume the selected work
+
+Use the current state, relevant formal documents and selected stage contract to establish the work being continued or started. Each run records scope, inputs, results and progress; `done` is completed production, not human approval. At a new stage or batch, check its actual prerequisites, current-content approvals or adopted-input checks and the existing authorization. Use its ordinary run-start save (`record-run` with progress `active`) before substantive execution, especially before implementation code changes, and inspect the save result. Resolve an actual prerequisite or save problem within its affected scope; do not perform the work first and register its start afterward.
+
+Reuse an already active run for the same work. Read-only preparation, discussion and document revisions within the current stage do not require a new run or another start check on every action. If the work or its inputs change materially, use the existing change/review rules. Do not ask again for approval or continuation already given.
+
+Read/check/resume describe the recorded work: current-run `canProceed` is not permission to start the next stage, and successful `check` is not document approval. While design awaits review, discussion of implementation details and requests to refine the design stay in design; they do not by themselves authorize code implementation. An issue holds only dependent work; an actual change to the arrangement follows the existing plan/decision flow.
 
 ## Project context and decisions
 

package/skills/aimship/references/routing.md

@@ -5,7 +5,7 @@ The user activates one Aimship entry. Read the bound core, this routing guide an
 | Intent/current stop | Route and scope |
 | --- | --- |
 | New concrete request | Preserve the commission and locate/create the intended delivery using core initialization; begin requirement work. |
-| Continue a known delivery | Read its identity/state/current materials. Resume pending approval, clarification or unfinished effects before selecting subsequent work. |
+| Continue a known delivery | Use the [shared start/continuation sequence](core.md#begin-or-resume-the-selected-work) with its identity/state/current materials. Continue the same active work; pending design discussion stays in design. Resolve actual approval, clarification or unfinished effects before entering subsequent work. |
 | A specified stage | Match the request to the saved arrangement and actual scope. Check prerequisites and current-content approvals; record a changed/limited commission where actually requested. A stage name is not permission to bypass its inputs. |
 | Implement the next authorized batch | Load [implement](stages/implement.md). Its work unit includes local checks, batch review and authorized repair/recheck; save separate internal runs, then stop at batch completion. |
 | Review | Load the [review dispatcher](stages/review.md) and its batch/overall/recheck module. The last batch stops with an overall-review handoff; recommend a new session, or continue overall review here only when explicitly authorized. Overall review alone does not commission full testing. |

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

@@ -10,7 +10,7 @@ Complete one authorized business batch or repair, including necessary local chec
 
 ## Actions
 
-Before entering implementation, or when a code working directory changes, apply the [recorded-overlap check](../core.md#independent-deliveries-and-recorded-overlap). Reuse an existing user-selected sequence or isolated checkout; unresolved same-checkout writing overlap holds the affected code writes, not independent design work. Complete this batch using the existing engineering stack. Write planned test code where appropriate. Preserve user work and external sources. Record deviations and route semantic changes through the current authority, including SQL when affected. Engineering commands use the repository working directory.
+Use the [shared start/continuation sequence](../core.md#begin-or-resume-the-selected-work): save the batch’s ordinary active start and inspect its result before code changes; reuse that record when continuing the same active batch. Before entering implementation, or when a code working directory changes, apply the [recorded-overlap check](../core.md#independent-deliveries-and-recorded-overlap). Reuse an existing user-selected sequence or isolated checkout; unresolved same-checkout writing overlap holds the affected code writes, not independent design work. Complete this batch using the existing engineering stack. Write planned test code where appropriate. Preserve user work and external sources. Record deviations and route semantic changes through the current authority, including SQL when affected. Engineering commands use the repository working directory.
 
 Expanded external behavior, data handling or authorization needs return to the relevant decision. A rejected permission remains blocked and is not retried through another host.