aimship 0.1.0-preview.14 → 0.1.0-preview.15
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CONTRIBUTING.md +3 -3
- package/README.md +3 -3
- package/README.zh-CN.md +3 -3
- package/docs/cli.md +11 -7
- package/docs/guide.md +15 -13
- package/docs/guide.zh-CN.md +15 -13
- package/lib/approvals.mjs +13 -7
- package/lib/cli.mjs +2 -2
- package/lib/delivery.mjs +20 -9
- package/lib/documents.mjs +12 -13
- package/lib/language.mjs +5 -4
- package/lib/state.mjs +3 -3
- package/lib/view.mjs +64 -30
- package/package.json +1 -1
- package/skills/aimship/SKILL.md +4 -3
- package/skills/aimship/references/artifact-map.json +1 -46
- package/skills/aimship/references/core.md +13 -14
- package/skills/aimship/references/document-patterns.md +7 -7
- package/skills/aimship/references/document-review.md +3 -3
- package/skills/aimship/references/hosts.md +1 -1
- package/skills/aimship/references/recovery.md +2 -2
- package/skills/aimship/references/sources-and-changes.md +6 -6
- package/skills/aimship/references/stages/contract.md +1 -1
- package/skills/aimship/references/stages/diagnose.md +1 -1
- package/skills/aimship/references/stages/frame.md +3 -1
- package/skills/aimship/references/stages/handoff.md +3 -1
- package/skills/aimship/references/stages/implement.md +3 -1
- package/skills/aimship/references/stages/plan.md +2 -2
- package/skills/aimship/references/stages/prototype.md +2 -2
- package/skills/aimship/references/stages/requirements.md +3 -3
- package/skills/aimship/references/stages/review.md +3 -1
- package/skills/aimship/references/stages/tech-design.md +2 -2
- package/skills/aimship/references/stages/test-design.md +1 -1
- package/skills/aimship/references/stages/verify.md +2 -0
- package/skills/aimship/references/templates/prd.md +4 -4
- package/skills/aimship/references/stages/scope.md +0 -27
- package/skills/aimship/references/templates/scope.md +0 -34
package/CONTRIBUTING.md
CHANGED
|
@@ -21,7 +21,7 @@ Validate public links and the shared stage/template mapping with `npm run check:
|
|
|
21
21
|
<a id="local-source-trial"></a>
|
|
22
22
|
## Local source trial without installation
|
|
23
23
|
|
|
24
|
-
To try unreleased initialization changes, open a session with access to the checkout and a separate disposable materials directory. Explicitly ask to use the checkout's `skills/aimship/SKILL.md`, read its core, and run `node bin/aimship.mjs bind` from this package root. Verify the returned releaseRoot/corePath/cliPath all point into that checkout and schemaVersion is
|
|
24
|
+
To try unreleased initialization changes, open a session with access to the checkout and a separate disposable materials directory. Explicitly ask to use the checkout's `skills/aimship/SKILL.md`, read its core, and run `node bin/aimship.mjs bind` from this package root. Verify the returned releaseRoot/corePath/cliPath all point into that checkout and schemaVersion is 4; a version string alone is insufficient when local code retains the published version. Then provide a concrete synthetic request, the trial materials path, and the desired stop. Do not load the installed launcher or run install.
|
|
25
25
|
|
|
26
26
|
In the next session, explicitly request that same source Skill and bind again, then provide the original delivery directory and ask to resume. Check its saved deliveryId, revision, review status and next action. This exercises source rules and local tooling without replacing global entries. Whether a specific host automatically discovers a checkout Skill is separate and must be tested rather than promised. Check `test/initialization.test.mjs` for deterministic initialization, interruption and approval-bypass regressions; their synthetic decisions are not real AI-host evidence.
|
|
27
27
|
|
|
@@ -63,7 +63,7 @@ Inspect the JSON results: installation should activate the package version; the
|
|
|
63
63
|
<a id="executable-examples"></a>
|
|
64
64
|
## Executable examples
|
|
65
65
|
|
|
66
|
-
The harness records explicitly labeled synthetic self-checks and approvals, exercises review stops
|
|
66
|
+
The harness records explicitly labeled synthetic self-checks and approvals, exercises review stops and explicitly requested continuation, and preserves CHG/reapproval history. These are deterministic tool checks, not real user decisions or host E2E evidence.
|
|
67
67
|
|
|
68
68
|
From a source checkout, run:
|
|
69
69
|
|
|
@@ -74,7 +74,7 @@ node scripts/run-examples.mjs <new-output-directory>
|
|
|
74
74
|
The output directory must not exist. The harness creates isolated code and delivery folders, exercises real functions with Node assertions, and saves readable documents, state and evidence. It does not install Aimship, touch user deliveries, access the network or publish anything. Do not use a real delivery as the output. The scripts are source-checkout tools, not installed user commands.
|
|
75
75
|
|
|
76
76
|
- **Authored, single batch:** a line-normalization PRD, plan before implementation, one review covering batch/overall scope, and independent normal/empty/error assertions. Execution updates the same plan; cases and RUN results share the testing document.
|
|
77
|
-
- **Adopted, multiple batches:** preserved catalog PRD/prototype inputs,
|
|
77
|
+
- **Adopted, multiple batches:** preserved catalog PRD/prototype inputs, an iteration PRD with source references, shared price validation and quoting with each batch reviewed. A discount change updates the testing document while keeping stable case IDs, records document reapproval and earlier review applicability, and binds exact code hashes. A known rounding fault fails overall review; the example asserts that starting verification is rejected without changing state. A separate maintainer probe preserves six real assertions (five pass, rounding fails) in `negative-probe.json`; it is not a formal verification stage or RUN. After fixing the code and recording a matching passing repair review, formal verification runs all six assertions successfully. Failed review and probe evidence remain available. Shared business rules, role restrictions and performance requirements have independent identities and acceptance.
|
|
78
78
|
|
|
79
79
|
These examples check local document/state behavior. They do not establish automatic Skill discovery, real cross-host continuation, UI interaction or HTTP acceptance. Run output records assertions and limitations. Results from older schemas do not establish current behavior.
|
|
80
80
|
|
package/README.md
CHANGED
|
@@ -36,14 +36,14 @@ Choose `codex`, `cursor` or `claude-code`. To connect several tools, repeat the
|
|
|
36
36
|
npx aimship@preview install --host codex --host claude-code
|
|
37
37
|
```
|
|
38
38
|
|
|
39
|
-
The npx package prompt confirms downloading and running the package; `install` performs the Aimship installation or upgrade. `@preview` selects the published preview channel; an exact published version, such as `@0.1.0-preview.
|
|
39
|
+
The npx package prompt confirms downloading and running the package; `install` performs the Aimship installation or upgrade. `@preview` selects the published preview channel; an exact published version, such as `@0.1.0-preview.15`, can be used instead. The preview channel is experimental and does not imply a stable release.
|
|
40
40
|
|
|
41
41
|
### A specific version or local package
|
|
42
42
|
|
|
43
43
|
To install an exact published version, for example:
|
|
44
44
|
|
|
45
45
|
```sh
|
|
46
|
-
npx aimship@0.1.0-preview.
|
|
46
|
+
npx aimship@0.1.0-preview.15 install --host codex
|
|
47
47
|
```
|
|
48
48
|
|
|
49
49
|
If you already have an Aimship `.tgz` package, replace `VERSION` with its actual version and run from the directory containing it:
|
|
@@ -82,7 +82,7 @@ npx aimship@preview install
|
|
|
82
82
|
|
|
83
83
|
After upgrading, we recommend restarting your AI tool and opening a new session, then activating Aimship to reload the updated rules. Existing sessions may still retain older rules.
|
|
84
84
|
|
|
85
|
-
Installation and upgrades use the same `install` command. Existing tool registrations, configuration, custom content and deliveries are retained. The installer reports previous/target versions, results and conflicts; no background updater or resident process runs. To upgrade to a specific version, for example, run `npx aimship@0.1.0-preview.
|
|
85
|
+
Installation and upgrades use the same `install` command. Existing tool registrations, configuration, custom content and deliveries are retained. The installer reports previous/target versions, results and conflicts; no background updater or resident process runs. To upgrade to a specific version, for example, run `npx aimship@0.1.0-preview.15 install`. Existing installations do not need `--host` or `--data-root` repeated.
|
|
86
86
|
|
|
87
87
|
<a id="add-a-host"></a>
|
|
88
88
|
<a id="add-an-ai-development-tool"></a>
|
package/README.zh-CN.md
CHANGED
|
@@ -36,14 +36,14 @@ AI 工具可选 `codex`、`cursor` 或 `claude-code`。连接多个 AI 工具时
|
|
|
36
36
|
npx aimship@preview install --host codex --host claude-code
|
|
37
37
|
```
|
|
38
38
|
|
|
39
|
-
npx 的获取包提示只确认下载并运行该包;执行 `install` 才会安装或升级 Aimship。`@preview` 表示已发布的预览通道,也可以替换为明确版本号,例如 `@0.1.0-preview.
|
|
39
|
+
npx 的获取包提示只确认下载并运行该包;执行 `install` 才会安装或升级 Aimship。`@preview` 表示已发布的预览通道,也可以替换为明确版本号,例如 `@0.1.0-preview.15`。预览通道用于实验性版本,不代表稳定版。
|
|
40
40
|
|
|
41
41
|
### 指定版本或本地包
|
|
42
42
|
|
|
43
43
|
安装指定的已发布版本,例如:
|
|
44
44
|
|
|
45
45
|
```sh
|
|
46
|
-
npx aimship@0.1.0-preview.
|
|
46
|
+
npx aimship@0.1.0-preview.15 install --host codex
|
|
47
47
|
```
|
|
48
48
|
|
|
49
49
|
如果已有 Aimship 的 `.tgz` 安装包,将 `VERSION` 替换为实际版本号,在包所在目录执行:
|
|
@@ -82,7 +82,7 @@ npx aimship@preview install
|
|
|
82
82
|
|
|
83
83
|
升级完成后,建议重启 AI 工具并新建会话,再启用 Aimship,以便重新加载更新后的规则。已有会话可能仍保留旧规则。
|
|
84
84
|
|
|
85
|
-
安装和升级使用同一个 `install` 命令。已有 AI 工具登记、配置、自定义内容和交付资料都会保留。安装器报告旧/目标版本、结果及冲突;没有后台自动升级或常驻进程。更新到指定版本时,例如运行 `npx aimship@0.1.0-preview.
|
|
85
|
+
安装和升级使用同一个 `install` 命令。已有 AI 工具登记、配置、自定义内容和交付资料都会保留。安装器报告旧/目标版本、结果及冲突;没有后台自动升级或常驻进程。更新到指定版本时,例如运行 `npx aimship@0.1.0-preview.15 install`。已有安装无需重复填写 `--host` 或 `--data-root`。
|
|
86
86
|
|
|
87
87
|
<a id="添加宿主"></a>
|
|
88
88
|
<a id="添加-ai-开发工具"></a>
|
package/docs/cli.md
CHANGED
|
@@ -32,9 +32,9 @@ node '<fixed-cli>' init '<delivery-dir>' --rules-version '<bound-version>' --inp
|
|
|
32
32
|
|
|
33
33
|
init uses schema 4, allocates deliveryId and revision 0, creates `.aimship/state.json`, and generates `status.md`. Add that ID to the document information at the next save point. Identity/version/timestamps, documentDigests are managed; never supply them in a patch. `writeResult` is return metadata, not state input. Its receipt contains actual identity, directory/state/status paths, bound version, current stage and next action; statusPath is null when view repair is needed. Verify the saved files before presenting the user receipt. Repeated init returns ALREADY_EXISTS; read/resume the same delivery and render a missing view instead of replaying creation.
|
|
34
34
|
|
|
35
|
-
`documentPolicy.authority`: null while the requirement authority is undecided; authored → prd.md; adopted →
|
|
35
|
+
`documentPolicy.authority`: null while the requirement authority is undecided; authored → prd.md; adopted → the registered retained PRD file in source/ (mode reused); editable → an explicitly authorized existing PRD. All three use kind prd and goalRef points to its actual path. `interaction`, `prototypeCovered`, `interface` (none/http/other) and target `databases` IDs record artifact conditions. They do not select a preset route. Prototype coverage is descriptive; a prototype is optional unless selected in stageRuns, in which case its completion and approval remain required. Register the first real PRD and switch goalRef in the same update; this reference-only transition does not need a fabricated goal decision. Actual goal/endpoint changes still require goal.decisionRef. Early frame/requirements work can be active without the draft; done requires it. Design requires approved requirements and an agreed endpoint, but may analyze unknown technical conditions. Resolve those conditions before completing design or starting dependent contract/cases/plan/implementation. Required document approvals remain checked even when producer runs are absent; existing stage ordering and review semantics are unchanged.
|
|
36
36
|
|
|
37
|
-
Register documents as `{kind,path,mode,version,assetRefs?}`. List local/repository prototype images, scripts and other review-relevant assets in assetRefs so their bytes participate in the document fingerprint; the Agent must identify the complete asset set. Kinds: prd,
|
|
37
|
+
Register documents as `{kind,path,mode,version,assetRefs?}`. List local/repository prototype images, scripts and other review-relevant assets in assetRefs so their bytes participate in the document fingerprint; the Agent must identify the complete asset set. Kinds: prd, tech-design, plan, testing, review, diagnosis, handoff, change-log, prototype, contract, sql, source. New formal Markdown follows the artifact map's root filename and ordered ordinary Markdown headings. Reused files additionally need `basisRef` recording location/version/coverage/gaps and editability; unsupported content is explicitly not checked. New HTML prototype is prototype/index.html; register other agreed formats. HTTP contracts use openapi.yaml unless reused. SQL filenames follow database count. Source files are immutable adopted versions by workflow, not OS access controls.
|
|
38
38
|
|
|
39
39
|
## Update and inspect
|
|
40
40
|
|
|
@@ -51,7 +51,7 @@ Stage runs are ordered `{id,stage,scope,progress,inputRefs,outputRefs}`. current
|
|
|
51
51
|
|
|
52
52
|
New Markdown uses the ordinary headings in the artifact map and searchable business IDs. Checks reject missing or duplicate definitions and unresolved ID references. Results use section keys or unique record IDs as search locators; no HTML anchors, embedded definition metadata, item versions or hidden traceability index are required. These structural checks do not establish semantic completeness.
|
|
53
53
|
|
|
54
|
-
Bare IDs resolve against current local definitions, including readable IDs in an explicitly registered
|
|
54
|
+
Bare IDs resolve against current local definitions, including readable IDs in an explicitly registered reused Markdown requirement authority. File-qualified Markdown record citations check the actual source file and a unique substantive record; missing, duplicate or unreadable sources fail. Reused documents retain their outline and separately reported unchecked content. B/TASK/TC definitions belong in batch/task/case design sections; execution sections may cite those IDs without defining new obligations. Delivery `language` is required for all current states.
|
|
55
55
|
|
|
56
56
|
References stay delivery-root-relative despite state being internal, or use `repo:<id>/<path>` / HTTP(S). Repository records `{id,path,role}` name actual absolute checkout/worktree roots. A branch is not a code version. Paths cannot escape roots through traversal or symlinks. check defaults to current inputs; --all adds registered history/decisions/outcomes. Exact fragments in registered new Markdown are checked; reused/remote/unsupported ones return not-checked. That does not establish semantics or passing verification.
|
|
57
57
|
|
|
@@ -87,27 +87,31 @@ Each record has `{id, kind, document, version, digest, sourceRef, summary}`. Kin
|
|
|
87
87
|
|
|
88
88
|
`read`, `check`, and `resume` return `review.documents` with current `path`, `version`, `digest`, `selfCheck`, `approval` and status. First append a self-check of those exact bytes; after presenting the document and receiving explicit approval, append an approved record binding the same version/digest and the actual user message. Questions, silence, and “show the result” cannot be recorded as approval. A hash/source reference validates the record's content basis, **not user identity or authenticity**. Never synthesize a real approval to make an update pass.
|
|
89
89
|
|
|
90
|
-
Production `progress: done` may be saved while approval is pending. Starting/completing dependent runs is blocked until prerequisite completion and document approval are current. Runs default to depending on their predecessor; explicit `dependsOn: [preceding-run-ids]` supports recorded independent branches, while input/output producers and earlier selected development prerequisites also apply. The initial applicable development order is requirements
|
|
90
|
+
Production `progress: done` may be saved while approval is pending. Starting/completing dependent runs is blocked until prerequisite completion and document approval are current. Runs default to depending on their predecessor; explicit `dependsOn: [preceding-run-ids]` supports recorded independent branches, while input/output producers and earlier selected development prerequisites also apply. The initial applicable development order is requirements, technical design, interface/SQL, test-design, plan, implement. Unselected stages are not created. Contract can produce only SQL when no interface change applies; technical design no longer requires SQL files before completion.
|
|
91
91
|
|
|
92
92
|
For new `plan.md` and `testing.md`, fingerprints cover the content before the ordinary headings mapped to `execution` and `runs` respectively. Append implementation and RUN/conclusion evidence after those boundaries. Reused formats and other documents use whole-file content; remote/binary or linked-asset semantic inspection still belongs to the host/Agent. `done`, matching hashes and structural checks do not prove semantic quality.
|
|
93
93
|
|
|
94
|
+
When the PRD authority path changes, retain the prior registered file as kind source (mode reused), register one current prd, and preserve the old result reference in the requirement run. Use the real goal decision and an open CHG for an approved requirement change; affected requirements/dependencies return to review. This changes current material, not historical approval records.
|
|
95
|
+
|
|
94
96
|
A material change needs an open CHG with impact/decision evidence, a revised document version, a new self-check and explicit reapproval. Old review records remain. Affected producer/dependent runs become `needs-review`; update currentRun/next to the re-review stop and restore applicability after evidence-backed rechecking in dependency order. Independent branches are preserved. An `editorial` record carries a prior approval only after a same-version self-check explains a formatting/typo change and references its previous digest; it is not a new user approval. Do not hide changed design in excluded result sections. Final `outcome.acceptance` stays independent.
|
|
95
97
|
|
|
96
|
-
See the [Agent review workflow](../skills/aimship/references/document-review.md) for presentation,
|
|
98
|
+
See the [Agent review workflow](../skills/aimship/references/document-review.md) for presentation, stage stops and approval responsibilities.
|
|
97
99
|
|
|
98
100
|
## Standard completeness and session suggestions
|
|
99
101
|
|
|
100
102
|
New state defaults to `deliveryPolicy: {version: 1}`. The standard main sequence is requirements/acceptance, technical and applicable contract/interaction artifacts, cases, plan, implementation with batch review, overall review, verification, handoff/acceptance. Do not present stageRuns as an arbitrary menu of core stages. Preserve existing materials and inspect them before adoption; reuse does not imply approval.
|
|
101
103
|
|
|
102
|
-
An explicit limited-scope decision (including no cases and testing) is referenced by `deliveryPolicy.partialRef` in existing PRD/
|
|
104
|
+
An explicit limited-scope decision (including no cases and testing) is referenced by `deliveryPolicy.partialRef` in existing PRD/change material. Such a scope may reach `outcome.goal: met` and have a real acceptance decision, but derived `completion.status` remains `partial-scope`, never `standard-complete`. Adding/changing/removing this basis needs a new goal.decisionRef, preserving goal history; set partialRef to null to restore standard scope. Standard goal completion checks recorded stages/approvals, passing batch and overall review, passing independent verification, handoff and resolvable evidence; standard-complete additionally requires recorded acceptance. These checks cannot prove actual execution or semantic quality. Failed or omitted checks must never be labeled passed.
|
|
103
105
|
|
|
104
106
|
Independent review, verify-only work or limited handoff can omit standard upstream work only with a nonempty readable local partialRef (including a resolvable ordinary heading or record if supplied). The tool checks the evidence reference, not whether a user actually authorized its contents. Declared dependencies and applicable document approvals remain in force. Planned future work and draft materials may be saved before entry conditions are met; active/done transitions are checked. Existing records remain readable and report unresolved entry conditions rather than automatically acquiring a scope exception.
|
|
105
107
|
|
|
106
108
|
Reviews identify their actual implementation coverage with `reviewOf: [implementationRunId, ...]`; overall review has `overall: true`. For a single batch one review may explicitly cover both. An unresolved failed review prevents standard completion even if an earlier overall review passed. A passing repair review or retest may list the superseded review/RUN result references in its existing `historyResultRefs`, preserving old failures; the Agent must verify that it actually resolves or covers them on current objects. Verification must follow the applicable overall review. Merely setting a link is not semantic evidence.
|
|
107
109
|
|
|
108
|
-
`run.sessionGroup`
|
|
110
|
+
`run.sessionGroup` remains advisory context, not permission to cross stages. Each stage finishes its work/self-check, saves artifacts and stops: `session.action` is await-review for required approval or await-continue for a completed stage awaiting continuation; `stop` and `suggestNewSession` make that advice explicit. A new session is recommended, not mandatory. Approval and continuation may be expressed together. This is agent interaction guidance, not interception of general-purpose tools or a new approval for non-review stages. `read/check/resume` and `writeResult.session` use the same rule. Unconfirmed saves return reconcile-save with no continuation; repair the view at the saved revision without replaying approval. Pending review never becomes approval through resume or “continue”.
|
|
109
111
|
|
|
110
112
|
`read` and `resume` accept optional `--delivery-id <known-id>` to reject a wrong directory binding. A directory remains required; no implicit latest-delivery lookup exists. Resume is read-only and inspects actual state, approval/content versions, references and view diagnostics; old prompts grant no approval. The Agent must additionally inspect relevant complete formal documents, actual artifacts and unfinished effects before acting.
|
|
111
113
|
|
|
112
114
|
|
|
113
115
|
Review run `ready` describes a completed, current record; `releaseReady` additionally requires a usable passing review before releasing dependent work. Failed review records remain saved. A later passing repair review must preserve the old result reference and cover the affected implementation scope; unrelated passing reviews do not clear the failure. Session suggestions distinguish exhausting registered work from completing the agreed goal: an unfinished goal with no next run requires arranging the next authorized work, not declaring finished.
|
|
116
|
+
|
|
117
|
+
The generated status page prioritizes current work, self-check and approval, user action, actual directory and continuation stop. Future standard stages are not started, not current defects; unknown contract applicability remains pending design. Final completion diagnostics remain enforced and are shown at handoff. Engineering details and generation metadata follow the user summary.
|
package/docs/guide.md
CHANGED
|
@@ -59,7 +59,7 @@ The delivery directory contains these materials:
|
|
|
59
59
|
└── handoff.md # Results and handoff instructions
|
|
60
60
|
```
|
|
61
61
|
|
|
62
|
-
Materials develop gradually and are kept as needed. Search readable REQ, AC and TC numbers across documents; corresponding numbers stay consistent without requiring anchor links.
|
|
62
|
+
Materials develop gradually and are kept as needed. Search readable REQ, AC and TC numbers across documents; corresponding numbers stay consistent without requiring anchor links. A complete applicable PRD is adopted directly; partial adoption produces this iteration’s `prd.md`. `change-log.md` records important changes, and `diagnosis.md` is for standalone investigations. Open `status.md` for progress; tell the AI directly about requirement changes or acceptance decisions.
|
|
63
63
|
|
|
64
64
|
<a id="1-start-and-proceed"></a>
|
|
65
65
|
<a id="start"></a>
|
|
@@ -76,7 +76,7 @@ Materials develop gradually and are kept as needed. Search readable REQ, AC and
|
|
|
76
76
|
|
|
77
77
|
Follow sign-up and login from requirements to acceptance. **This is fictional practice; wording and business choices need not be copied.** The example later supplies a project and isolated test database, with prototype review after requirements and before technical design. Actual prototype placement follows the delivery's needs.
|
|
78
78
|
|
|
79
|
-
Use one Aimship entry within a session
|
|
79
|
+
Use one Aimship entry within a session; no invocation is needed at every stage. After completing and self-checking a stage, the AI saves its results, reports the stop and pauses. A new session is recommended, not required. Reviewable documents await explicit approval; other stages await continuation. You may say “approved, continue” once. Work within a stage stays continuous.
|
|
80
80
|
|
|
81
81
|
<a id="11-prepare-a-workspace"></a>
|
|
82
82
|
<a id="12-activate-aimship-and-describe-the-request"></a>
|
|
@@ -98,9 +98,9 @@ Use one Aimship entry within a session, then continue after approval as arranged
|
|
|
98
98
|
|
|
99
99
|
> Use Aimship for username/password sign-up, login, logout and a home page requiring login. Complete development and local verification, without deployment; I will supply code later.
|
|
100
100
|
|
|
101
|
-
For existing prototypes, PRDs or other documents, supply their original locations; originals stay in place and you need not copy them manually. Following the source rules, the AI retains copies of the formally adopted versions and necessary dependencies under this delivery's `source/` and records the adoption basis. Materials consulted only as background need not be copied in full. Before later revisions, identify the editable artifact; new versions do not overwrite earlier evidence.
|
|
101
|
+
For existing prototypes, PRDs or other documents, supply their original locations; originals stay in place and you need not copy them manually. Following the source rules, the AI retains copies of the formally adopted versions and necessary dependencies under this delivery's `source/` and records the adoption basis in the existing source record. Materials consulted only as background need not be copied in full. Before later revisions, identify the editable artifact; new versions do not overwrite earlier evidence.
|
|
102
102
|
|
|
103
|
-
**AI processing:** Determines the delivery directory and checks access, preserves the request, creates or resumes the delivery, and reports the actual saved directory, current work and next action. If access is unavailable, it asks you to add that directory or grant access; it does not relocate the delivery into the workspace.
|
|
103
|
+
**AI processing:** Determines the delivery directory and checks access, preserves the request, creates or resumes the delivery, and reports the actual saved directory, current work and next action. It starts requirement intake on the standard sequence without a full-delivery/design-only/init-only choice; explicit limits or pauses are respected. If access is unavailable, it asks you to add that directory or grant access; it does not relocate the delivery into the workspace.
|
|
104
104
|
|
|
105
105
|
**Outputs:** `source/request.md` preserves your words; `status.md` shows progress. For a new delivery, the AI saves your preferred language, or otherwise the language of the current conversation. Status and new documents use that language; filenames, IDs, original sources and existing documents remain unchanged.
|
|
106
106
|
|
|
@@ -124,11 +124,11 @@ For existing prototypes, PRDs or other documents, supply their original location
|
|
|
124
124
|
- No PRD/prototype: describe features and expected behavior, such as “Usernames must be unique; after logout, the home page must require login again.”
|
|
125
125
|
- Existing materials: provide the PRD/prototype location, version and adopted scope. Say what is available even if it is incomplete.
|
|
126
126
|
|
|
127
|
-
Open the
|
|
127
|
+
Open the current requirements and any selected prototype. Check scope, acceptance criteria and page behavior; approve or give feedback. An evidenced existing approval of the current content is reused without asking again.
|
|
128
128
|
|
|
129
|
-
**AI processing:**
|
|
129
|
+
**AI processing:** Adopts a complete applicable PRD without rewriting or renumbering. For partial adoption, it writes this iteration’s PRD with sources, inclusions, exclusions and acceptance, retaining source IDs where possible. Without a PRD, discussion produces one. Prototypes are optional; adequate existing ones are reused. It self-checks, confirms and saves each selected document, preserving originals.
|
|
130
130
|
|
|
131
|
-
**Outputs:** `prd.md`
|
|
131
|
+
**Outputs:** The newly authored `prd.md` or retained PRD in `source/` is the requirement authority, without a separate Scope. This example selects `prototype/index.html` for pages and feedback states. A prototype is not implemented authentication; interaction checks not performed remain unverified.
|
|
132
132
|
|
|
133
133
|
<a id="guide-session-example"></a>
|
|
134
134
|
|
|
@@ -187,9 +187,9 @@ The AI rechecks access to the same delivery directory, reads its state and confi
|
|
|
187
187
|
|
|
188
188
|
### 1.7 Implement batches and review each batch
|
|
189
189
|
|
|
190
|
-
**User actions:** Inspect changes and progress; point out deviations, such as “The post-sign-up redirect differs from the prototype.” No line-by-line approval of execution logs is needed.
|
|
190
|
+
**User actions:** Inspect changes and progress; point out deviations, such as “The post-sign-up redirect differs from the prototype.” No line-by-line approval of execution logs is needed; inspect the saved stage result and ask to continue.
|
|
191
191
|
|
|
192
|
-
**AI processing:** Implements the plan
|
|
192
|
+
**AI processing:** Implements the plan and reviews each batch, saving and stopping after implementation and after review. Continuation advances only after blocking issues are resolved. All batches are followed by overall review, then verification. Requirement changes return to the relevant review.
|
|
193
193
|
|
|
194
194
|
**Outputs:** Project code, execution progress appended to `plan.md`, and batch findings and repairs in `review.md`.
|
|
195
195
|
|
|
@@ -198,9 +198,9 @@ The AI rechecks access to the same delivery directory, reads its state and confi
|
|
|
198
198
|
|
|
199
199
|
### 1.8 Review the complete change
|
|
200
200
|
|
|
201
|
-
**User actions:** Read the overall findings and remaining issues, pointing out omissions if needed.
|
|
201
|
+
**User actions:** Read the overall findings and remaining issues, pointing out omissions if needed. Review records do not need a separate document approval; inspect the conclusion and ask to continue.
|
|
202
202
|
|
|
203
|
-
**AI processing:** Checks all actual changes and connections across sign-up, login, logout and home-page access. It resolves issues blocking independent verification. A single-batch review can explicitly cover both batch and overall scope.
|
|
203
|
+
**AI processing:** Checks all actual changes and connections across sign-up, login, logout and home-page access. It resolves issues blocking independent verification, saves the conclusion and stops before continuing to verification. A single-batch review can explicitly cover both batch and overall scope.
|
|
204
204
|
|
|
205
205
|
**Outputs:** Overall conclusions appended to `review.md`. Code review does not replace running tests.
|
|
206
206
|
|
|
@@ -254,7 +254,7 @@ The AI rechecks access to the same delivery directory, reads its state and confi
|
|
|
254
254
|
|
|
255
255
|
### 2.1 When to switch sessions
|
|
256
256
|
|
|
257
|
-
|
|
257
|
+
At each completed stage, follow the stop in `status.md`: approve or give feedback on pending documents, or ask to continue completed work. A new session is recommended but optional; “continue” does not approve a pending document. The page prioritizes current actions and shows future stages as not started, not current defects.
|
|
258
258
|
|
|
259
259
|
See the [new-session example](#guide-session-example). Keep one writing session per delivery. Trusted records can locate it directly; missing or ambiguous matches prompt clarification. The saved delivery language carries over. If switching before the first save, carry the unsaved request, intended location and pending operations.
|
|
260
260
|
|
|
@@ -289,7 +289,7 @@ Manual progress-page edits are preserved first; conflicts need coordination. Do
|
|
|
289
289
|
|
|
290
290
|
### 3.1 Existing materials or discussion
|
|
291
291
|
|
|
292
|
-
Provide the PRD, prototype or screenshot locations, versions and scope to use. The AI checks them as described in [Confirm requirements](#guide-requirements).
|
|
292
|
+
Provide the PRD, prototype or screenshot locations, versions and scope to use. The AI checks them as described in [Confirm requirements](#guide-requirements). A complete applicable PRD is adopted directly; partial adoption produces an iteration PRD without changing the original. Explicitly request edits to the original if needed. Existing files are not approval; evidenced current approvals are reused.
|
|
293
293
|
|
|
294
294
|
For prior discussion, say “Use Aimship to continue the requirements we just discussed.” The AI organizes visible requests, decisions and open questions. Supply history it cannot see; suggestions are not approvals.
|
|
295
295
|
|
|
@@ -347,6 +347,8 @@ For defects, provide expected behavior, the problem and reproduction steps or lo
|
|
|
347
347
|
|
|
348
348
|
Keep each delivery separate and identify shared code, interfaces, databases or environments. Analysis can run concurrently; sequence edits to the same code, or use separate working directories and plan the merge.
|
|
349
349
|
|
|
350
|
+
Pre-existing edits from other requests are not added to this requirement or cleaned merely because the working tree is dirty. Engineering baselines stay in engineering records, not the business PRD.
|
|
351
|
+
|
|
350
352
|
The AI checks only known, accessible deliveries; it does not lock or schedule other sessions. Describe other ongoing changes and check the merged result afterward.
|
|
351
353
|
|
|
352
354
|
<a id="4-problems-and-references"></a>
|
package/docs/guide.zh-CN.md
CHANGED
|
@@ -59,7 +59,7 @@ AI 工具项目空间
|
|
|
59
59
|
└── handoff.md # 成果与交接说明
|
|
60
60
|
```
|
|
61
61
|
|
|
62
|
-
这些材料逐步形成,按需保留。正文中的 REQ、AC、TC
|
|
62
|
+
这些材料逐步形成,按需保留。正文中的 REQ、AC、TC 等编号可直接搜索,跨文档沿用对应编号,不要求锚点跳转。完整适用的已有 PRD 直接采用,部分采用时编写本次 `prd.md`,重要变更记入 `change-log.md`,独立调查才使用 `diagnosis.md`。查看进度先打开 `status.md`;需求修改或验收意见直接告诉 AI。
|
|
63
63
|
|
|
64
64
|
<a id="1-开始与推进"></a>
|
|
65
65
|
<a id="start"></a>
|
|
@@ -76,7 +76,7 @@ AI 工具项目空间
|
|
|
76
76
|
|
|
77
77
|
以登录注册功能演示从需求到验收。**这是虚构实践参考,措辞和业务方案无需照抄。** 本例稍后提供工程和隔离测试数据库,约定需求后确认原型,再做技术设计;实际原型安排按交付需要确定。
|
|
78
78
|
|
|
79
|
-
同一会话沿用一个 Aimship
|
|
79
|
+
同一会话沿用一个 Aimship 入口,无需逐阶段调用。每阶段完成并自检后,AI 保存成果、说明停点并停下,建议新会话,也可原会话继续。需审核的材料等待明确批准,其他阶段等待继续;可以一次说“通过并继续”。阶段内部不逐小步暂停。
|
|
80
80
|
|
|
81
81
|
<a id="11-准备工作位置"></a>
|
|
82
82
|
<a id="12-启用-aimship-并说明需求"></a>
|
|
@@ -98,9 +98,9 @@ AI 工具项目空间
|
|
|
98
98
|
|
|
99
99
|
> 使用 Aimship,做用户名密码注册、登录、退出和登录后首页。完成开发与本地验证,不部署;代码稍后提供。
|
|
100
100
|
|
|
101
|
-
已有原型、PRD 或其他文档时,提供原位置即可,原件保留,用户无需手动复制。AI 按来源规则将正式采用的版本及必要依赖资源留存为本次交付 `source/`
|
|
101
|
+
已有原型、PRD 或其他文档时,提供原位置即可,原件保留,用户无需手动复制。AI 按来源规则将正式采用的版本及必要依赖资源留存为本次交付 `source/` 中的副本,并在已有来源记录中注明采用依据;仅作背景参考的材料无需全量复制。后续修改先明确编辑对象,新版不覆盖旧依据。
|
|
102
102
|
|
|
103
|
-
**AI
|
|
103
|
+
**AI 处理**:确定交付目录并核对访问,保留诉求,建立或续接交付,告知实际保存目录、当前工作和下一步;默认按主流程承接需求,不先让你选择完整交付、仅设计或仅初始化。你主动要求暂停或限定范围时按要求处理。若无法访问,提示你添加该原目录或授权;不会改存到项目空间。
|
|
104
104
|
|
|
105
105
|
**输出产物**:`source/request.md` 保存原话;`status.md` 显示进度。新建交付时,AI 优先按明确偏好,否则按当前交流语言保存本次交付语言;状态和新文档沿用,文件名、编号、来源原文及已有文档不变。
|
|
106
106
|
|
|
@@ -124,11 +124,11 @@ AI 工具项目空间
|
|
|
124
124
|
- 没有 PRD/原型:说明功能和预期行为,如“用户名不能重复,退出后再进首页必须登录”。
|
|
125
125
|
- 已有材料:给出 PRD/原型的位置、版本和本次采用范围;只有部分材料也直接说明。
|
|
126
126
|
|
|
127
|
-
|
|
127
|
+
打开当前需求材料及本次选用的原型,核对范围、验收标准和页面行为,明确通过或反馈。有可核实且对应当前内容的已有批准时直接沿用,不重复审批。
|
|
128
128
|
|
|
129
|
-
**AI
|
|
129
|
+
**AI 处理**:完整适用的 PRD 直接采用,不重写或重新编号;仅采用部分时编写本次 PRD,写清来源、纳入、排除及验收,尽量沿用原编号;没有 PRD 时讨论后生成。原型可选,已有原型充分则复用。逐份自检、确认并保存,原件保留。
|
|
130
130
|
|
|
131
|
-
|
|
131
|
+
**输出产物**:新写的 `prd.md` 或 `source/` 中正式采用的已有 PRD 作为需求依据,不另建 Scope。本例选择新建 `prototype/index.html` 展示页面与反馈状态。原型不代表认证已实现,未实际检查的交互仍标明未验证。
|
|
132
132
|
|
|
133
133
|
<a id="guide-session-example"></a>
|
|
134
134
|
|
|
@@ -187,9 +187,9 @@ AI 重新核对同一交付目录的访问,读取状态并确认下一步技
|
|
|
187
187
|
|
|
188
188
|
### 1.7 分批实施与批内 review
|
|
189
189
|
|
|
190
|
-
|
|
190
|
+
**用户操作**:查看改动和进度,有偏离及时指出,如“注册成功后的跳转与原型不一致”。无需逐条批准执行日志;阶段结束查看结果后可要求继续。
|
|
191
191
|
|
|
192
|
-
**AI
|
|
192
|
+
**AI 处理**:按计划写代码,每批实施、批内审查分别完成后保存并停下,收到继续指令再推进;存在阻碍时先修复。全部批次完成后安排整体审查,再统一验证;需求变化回到相应审核。
|
|
193
193
|
|
|
194
194
|
**输出产物**:工程代码;`plan.md` 追加执行进度,`review.md` 记录本批问题与修复。
|
|
195
195
|
|
|
@@ -198,9 +198,9 @@ AI 重新核对同一交付目录的访问,读取状态并确认下一步技
|
|
|
198
198
|
|
|
199
199
|
### 1.8 整体 review
|
|
200
200
|
|
|
201
|
-
|
|
201
|
+
**用户操作**:查看整体结论和遗留问题,必要时指出遗漏;不需要为审查记录另做文档批准,查看结论后可要求继续。
|
|
202
202
|
|
|
203
|
-
**AI
|
|
203
|
+
**AI 处理**:检查全部实际改动及注册、登录、退出、首页访问的跨批衔接,处理阻碍验证的问题后保存结论并停下,收到继续指令再进入独立验证。单批可用一份 review 明确覆盖批内及整体范围。
|
|
204
204
|
|
|
205
205
|
**输出产物**:`review.md` 追加整体审查结论。代码审查不能代替运行测试。
|
|
206
206
|
|
|
@@ -254,7 +254,7 @@ AI 重新核对同一交付目录的访问,读取状态并确认下一步技
|
|
|
254
254
|
|
|
255
255
|
### 2.1 何时换会话
|
|
256
256
|
|
|
257
|
-
|
|
257
|
+
每阶段完成后按 `status.md` 的停点处理:待审则批准或反馈,已完成则要求继续。建议此时换会话,也可继续当前会话;“继续”不替代待审材料的批准。进度页先展示当前操作,尚未开始的后续阶段不会当作当前缺项。
|
|
258
258
|
|
|
259
259
|
新会话操作见[演示中的续接示例](#guide-session-example)。同一交付只保留一个写入会话;可信记录可直接定位,找不到或有多个候选才询问。交付语言沿用已保存设置。首次保存前就要切换时,携带未保存诉求、计划位置及未完成操作。
|
|
260
260
|
|
|
@@ -289,7 +289,7 @@ AI 重新核对同一交付目录的访问,读取状态并确认下一步技
|
|
|
289
289
|
|
|
290
290
|
### 3.1 已有资料或讨论
|
|
291
291
|
|
|
292
|
-
提供 PRD、原型或截图的位置、版本和本次使用范围,AI 按[确认需求](#guide-requirements)
|
|
292
|
+
提供 PRD、原型或截图的位置、版本和本次使用范围,AI 按[确认需求](#guide-requirements)核对。完整适用的 PRD 直接采用;部分采用形成迭代 PRD,原件不改。若要修改原件,请明确说明。已有文件不等于已批准,已有有效批准则不重复索要。
|
|
293
293
|
|
|
294
294
|
已有讨论可说:“使用 Aimship 继续刚才讨论的需求。”AI 整理可见的诉求、决定和待确认问题;看不到的历史请补充,建议不算批准。
|
|
295
295
|
|
|
@@ -347,6 +347,8 @@ AI 重新核对同一交付目录的访问,读取状态并确认下一步技
|
|
|
347
347
|
|
|
348
348
|
每个需求使用独立交付目录,并说明共用的代码、接口、数据库或环境。可以同时分析;修改同一份代码时安排先后,或使用独立工作目录并安排合并。
|
|
349
349
|
|
|
350
|
+
其他需求的未提交改动不会自动纳入本次需求,也不因工作树不干净而要求清理;工程基线保存在工程记录中,不粘贴到业务 PRD。
|
|
351
|
+
|
|
350
352
|
AI 只能核对已知且可访问的交付,不会自动锁定或调度其他会话。请说明其他正在进行的修改,各自完成后仍需检查合并结果。
|
|
351
353
|
|
|
352
354
|
<a id="4-常见问题与参考"></a>
|
package/lib/approvals.mjs
CHANGED
|
@@ -110,7 +110,7 @@ export async function reviewStatus(directory, state) {
|
|
|
110
110
|
try { await evidence(directory,state,state.deliveryPolicy.partialRef); limitedScope=true; }
|
|
111
111
|
catch { /* Report an unavailable scope basis; never silently grant an exception. */ }
|
|
112
112
|
}
|
|
113
|
-
const runs = [], requirement =
|
|
113
|
+
const runs = [], requirement = 'prd';
|
|
114
114
|
for (const [i, run] of state.stageRuns.entries()) {
|
|
115
115
|
const spec = map.stages[run.stage];
|
|
116
116
|
let required = [];
|
|
@@ -120,7 +120,7 @@ export async function reviewStatus(directory, state) {
|
|
|
120
120
|
}
|
|
121
121
|
const declared = run.dependsOn ?? (i ? [state.stageRuns[i - 1].id] : []);
|
|
122
122
|
const producers = state.stageRuns.slice(0, i).filter(r => r.outputRefs.some(out => run.inputRefs.some(input => out.split('#')[0] === input.split('#')[0]))).map(r => r.id);
|
|
123
|
-
const development = ['requirements','
|
|
123
|
+
const development = ['requirements','tech-design','contract','test-design','plan','implement'];
|
|
124
124
|
const prerequisites = development.includes(run.stage) ? state.stageRuns.slice(0,i).filter(r=>development.includes(r.stage) && development.indexOf(r.stage)<development.indexOf(run.stage)).map(r=>r.id) : [];
|
|
125
125
|
const gated=state.deliveryPolicy?.version===1 && ['review','verify','handoff'].includes(run.stage);
|
|
126
126
|
const entrance=gated && !limitedScope ? standardEntry(state,run,i,runs) : {dependsOn:[],issues:[]};
|
|
@@ -144,7 +144,7 @@ export async function reviewStatus(directory, state) {
|
|
|
144
144
|
if (state.documentPolicy.interface !== null && state.documentPolicy.interface !== 'none') needs.push('contract');
|
|
145
145
|
if (state.documentPolicy.databases?.length) needs.push('sql');
|
|
146
146
|
}
|
|
147
|
-
if (run.stage === 'implement' && state.
|
|
147
|
+
if (run.stage === 'implement' && state.stageRuns.some(r=>r.stage==='prototype')) needs.push('prototype');
|
|
148
148
|
for (const kind of needs) {
|
|
149
149
|
const inputs = (state.documents ?? []).filter(d=>d.kind === kind);
|
|
150
150
|
if (!inputs.length || inputs.some(d=>documents.find(r=>r.path===d.path)?.status !== 'approved')) blockedBy.push(`approval:${kind}`);
|
|
@@ -182,7 +182,14 @@ export async function enforceReviews(directory, state, previous) {
|
|
|
182
182
|
validateReviewState(state);
|
|
183
183
|
if (state.reviewPolicy !== 1) reject('Invalid review policy.');
|
|
184
184
|
const oldHistory = previous?.reviewHistory ?? [];
|
|
185
|
-
|
|
185
|
+
const previousPrd=previous?.documents.find(d=>d.kind==='prd'), currentPrd=state.documents.find(d=>d.kind==='prd');
|
|
186
|
+
const replacedPrd=previousPrd && currentPrd && previousPrd.path!==currentPrd.path;
|
|
187
|
+
for (const old of previous?.documents ?? []) {
|
|
188
|
+
const retained=state.documents.some(d=>d.path===old.path && (d.kind===old.kind || (replacedPrd && old===previousPrd && d.kind==='source' && d.mode==='reused')));
|
|
189
|
+
if(oldHistory.some(r=>r.document===old.path) && !retained)reject(`Preserve reviewed document registration ${old.path}.`);
|
|
190
|
+
}
|
|
191
|
+
const revisedApprovedPrd=replacedPrd && oldHistory.some(r=>r.document===previousPrd.path && ['approved','editorial'].includes(r.kind));
|
|
192
|
+
if(revisedApprovedPrd && !state.openChanges.some(c=>c.status==='open'))reject('Record the requirement authority change and impact in an open CHG.');
|
|
186
193
|
if (state.reviewHistory.length < oldHistory.length || !oldHistory.every((r, i) => isDeepStrictEqual(r, state.reviewHistory[i]))) reject('Preserve review history unchanged and in order.');
|
|
187
194
|
const prefix = { ...state, reviewHistory: [...oldHistory] };
|
|
188
195
|
for (const r of state.reviewHistory.slice(oldHistory.length)) {
|
|
@@ -195,17 +202,16 @@ export async function enforceReviews(directory, state, previous) {
|
|
|
195
202
|
prefix.reviewHistory.push(r);
|
|
196
203
|
}
|
|
197
204
|
// Only the initial selected development sequence is ordered; later rework can recur.
|
|
198
|
-
const order = ['requirements','
|
|
205
|
+
const order = ['requirements','tech-design','contract','test-design','plan','implement'];
|
|
199
206
|
const first = stage => state.stageRuns.findIndex(r => r.stage === stage);
|
|
200
207
|
for (let i = 0; i < order.length; i++) for (let j = i + 1; j < order.length; j++) {
|
|
201
208
|
const a = first(order[i]), b = first(order[j]);
|
|
202
|
-
if (order[i] === 'requirements' && order[j] === 'scope') continue;
|
|
203
209
|
if (a >= 0 && b >= 0 && a > b && !previous?.stageRuns.some(r => r.id === state.stageRuns[b].id && r.progress !== 'planned')) reject(`${order[i]} must precede ${order[j]} in the initial development arrangement.`);
|
|
204
210
|
}
|
|
205
211
|
const restoring = new Set(state.stageRuns.filter(r=>r.applicability === 'current' && previous?.stageRuns.some(old=>old.id===r.id && old.applicability==='needs-review')).map(r=>r.id));
|
|
206
212
|
let status = await reviewStatus(directory, state);
|
|
207
213
|
// Invalidate only registered producer/dependency paths. Independent branches retain their facts.
|
|
208
|
-
const affected = new Set();
|
|
214
|
+
const affected = new Set(revisedApprovedPrd ? status.runs.filter(r=>r.stage==='requirements' && r.progress!=='planned').map(r=>r.id) : []);
|
|
209
215
|
for (const doc of state.documents) {
|
|
210
216
|
const oldDoc = previous?.documents?.find(d => d.path === doc.path);
|
|
211
217
|
const latest = oldHistory.filter(r => r.document === doc.path && ['approved','editorial'].includes(r.kind)).at(-1);
|
package/lib/cli.mjs
CHANGED
|
@@ -30,7 +30,7 @@ const HELP = {
|
|
|
30
30
|
schemaVersion: SCHEMA_VERSION,
|
|
31
31
|
documentReview: {reviewPolicy:1, reviewHistory:'Append-only {id,kind,document,version,digest,sourceRef,summary}. self-check requires result: passed|failed; approved requires decision: explicit-approval; editorial requires previousDigest. Read review.documents for current digests. Tools validate records, not user identity. See docs/cli.md#document-review-protocol.'},
|
|
32
32
|
deliveryPolicy: 'New states default to {version:1}; partialRef identifies an explicitly limited scope, null restores standard scope with a new goal decision. Completion is derived separately from goal/acceptance.',
|
|
33
|
-
sessions: 'run.sessionGroup is an advisory context group, auto-filled for new runs; reviewOf names implementation runs and overall:true identifies overall review. read/check/resume expose session/completion;
|
|
33
|
+
sessions: 'run.sessionGroup is an advisory context group, auto-filled for new runs; reviewOf names implementation runs and overall:true identifies overall review. read/check/resume expose session/completion. Completed stages return stop with await-review or await-continue, even within one group; suggestNewSession is advisory. Failed view saving returns reconcile-save. No new approval or automatic execution.',
|
|
34
34
|
stages: STAGES,
|
|
35
35
|
progress: ['planned', 'active', 'blocked', 'done'],
|
|
36
36
|
result: ['passed', 'failed', 'not-run', 'unknown', 'mixed'],
|
|
@@ -40,7 +40,7 @@ const HELP = {
|
|
|
40
40
|
references: 'delivery-relative/path#optional-fragment, repo:<registered-id>/<repo-relative-path>#fragment, or HTTP(S) URL. Local paths cannot escape their root. Repository registration: {id, path: absolute-path, role}.',
|
|
41
41
|
topLevel: {
|
|
42
42
|
managed: 'schemaVersion, revision, deliveryId, rulesVersion, createdAt, updatedAt, goalHistory, documentDigests, writeResult. Do not supply these in init/update.',
|
|
43
|
-
requiredInit: 'language: en|zh-CN and goal: {summary, endpoint?}; save a nonempty source/request.md before init. Defaults: endpoint null, goalRef source/request.md, empty documents, and null documentPolicy conditions/authority. Register PRD
|
|
43
|
+
requiredInit: 'language: en|zh-CN and goal: {summary, endpoint?}; save a nonempty source/request.md before init. Defaults: endpoint null, goalRef source/request.md, empty documents, and null documentPolicy conditions/authority. Register PRD and switch goalRef when drafted; no empty templates.',
|
|
44
44
|
language: 'en or zh-CN from explicit user preference, otherwise this delivery conversation. Required in current state; retained on update/render/resume.',
|
|
45
45
|
storage: 'Init-only {mode: explicit, decisionRef: delivery-relative-readable-file} for a user-selected location. Otherwise a strict child of configured dataRoot. Returned dataRoot is managed; ordinary workspace/material location is not a choice.',
|
|
46
46
|
stageRuns: 'Ordered array of stageInstance objects, default []. Every ID is unique; currentRun must match one of these IDs or be null. Stage types may repeat with distinct IDs.',
|
package/lib/delivery.mjs
CHANGED
|
@@ -18,21 +18,22 @@ export function arrangeSessions(state) {
|
|
|
18
18
|
if (state.deliveryPolicy?.version !== 1) return;
|
|
19
19
|
for (const r of state.stageRuns) {
|
|
20
20
|
if (r.sessionGroup) continue;
|
|
21
|
-
const category = ['frame','requirements'
|
|
21
|
+
const category = ['frame','requirements'].includes(r.stage) ? 'requirements' : ['tech-design','contract','prototype'].includes(r.stage) ? 'technical' : r.stage;
|
|
22
22
|
const batch = r.stage === 'review' && !r.overall && r.reviewOf?.length === 1 ? state.stageRuns.find(x=>x.id===r.reviewOf[0]) : null;
|
|
23
23
|
r.sessionGroup = batch ? (batch.sessionGroup ?? `implement:${batch.id}`) : ['requirements','technical','test-design','plan'].includes(category) ? category : `${category}:${r.id}`;
|
|
24
24
|
}
|
|
25
25
|
}
|
|
26
26
|
export function completionStatus(state, review, {changed=[]}={}) {
|
|
27
27
|
const runs=state.stageRuns, gaps=[];
|
|
28
|
-
if (state.
|
|
28
|
+
if (state.goal.endpoint === null) gaps.push('Delivery endpoint remains unknown.');
|
|
29
|
+
if (state.documentPolicy.authority === null || unknownConditions(state.documentPolicy).length) gaps.push('Artifact conditions remain unknown.');
|
|
29
30
|
if(changed.length) gaps.push('Changed or missing registered documents require reconciliation.');
|
|
30
31
|
const ready=r=>review.runs.find(x=>x.id===r.id)?.ready;
|
|
31
32
|
const has=stage=>runs.some(r=>r.stage===stage && ready(r));
|
|
32
33
|
for (const stage of ['tech-design','test-design','plan','implement','verify','handoff']) if (!has(stage)) gaps.push(`Missing current completed ${stage}.`);
|
|
33
|
-
if (!runs.some(r=>
|
|
34
|
-
if ((state.documentPolicy?.interface!=='none' || state.documentPolicy?.databases?.length) && !has('contract')) gaps.push('Missing applicable interface/SQL contract.');
|
|
35
|
-
if (
|
|
34
|
+
if (!runs.some(r=>r.stage==='requirements' && ready(r))) gaps.push('Missing reviewed requirements.');
|
|
35
|
+
if (((state.documentPolicy?.interface!=null && state.documentPolicy.interface!=='none') || state.documentPolicy?.databases?.length) && !has('contract')) gaps.push('Missing applicable interface/SQL contract.');
|
|
36
|
+
if (runs.some(r=>r.stage==='prototype') && !has('prototype')) gaps.push('Missing applicable interaction prototype.');
|
|
36
37
|
if (review.runs.some(r=>!r.ready)) gaps.push('Selected work or document approvals remain unresolved.');
|
|
37
38
|
const implementations=runs.filter(r=>r.stage==='implement');
|
|
38
39
|
if (implementations.some(r=>['failed','mixed','unknown','not-run'].includes(r.result))) gaps.push('Implementation results remain unresolved.');
|
|
@@ -55,6 +56,16 @@ export function completionStatus(state, review, {changed=[]}={}) {
|
|
|
55
56
|
const readyForAcceptance=!partial && !gaps.length;
|
|
56
57
|
return {status:partial?'partial-scope':readyForAcceptance && state.outcome.goal==='met' && state.outcome.acceptance==='accepted'?'standard-complete':readyForAcceptance?'ready-for-acceptance':'incomplete',standardComplete:readyForAcceptance && state.outcome.goal==='met' && state.outcome.acceptance==='accepted',readyForAcceptance,gaps:gaps.map(g=>completionMessage(state,g)),partialRef:state.deliveryPolicy.partialRef??null,scope:text(state,'Recorded structure, approvals and results only; not independent proof of test execution or semantic quality.','仅评估已记录的结构、审批和结果;不独立证明测试已执行或内容语义正确。')};
|
|
57
58
|
}
|
|
59
|
+
// A display suggestion, never a scheduled run or authorization.
|
|
60
|
+
export function suggestedNextStage(state) {
|
|
61
|
+
const current=state.stageRuns.find(r=>r.id===state.currentRun) ?? state.stageRuns.at(-1);
|
|
62
|
+
const scheduled=current?state.stageRuns[state.stageRuns.indexOf(current)+1]:state.stageRuns[0];
|
|
63
|
+
if(scheduled)return scheduled.stage;
|
|
64
|
+
if(state.deliveryPolicy.partialRef)return null;
|
|
65
|
+
if(!current)return 'requirements';
|
|
66
|
+
const contracts=(state.documentPolicy.interface!=null && state.documentPolicy.interface!=='none') || state.documentPolicy.databases?.length;
|
|
67
|
+
return ({frame:'requirements',requirements:'tech-design',prototype:'tech-design','tech-design':contracts?'contract':'test-design',contract:'test-design','test-design':'plan',plan:'implement',implement:'review',review:current.overall?'verify':'review',verify:'handoff'})[current.stage]??null;
|
|
68
|
+
}
|
|
58
69
|
export function sessionAdvice(directory,state,review,{saved=true}={}) {
|
|
59
70
|
const groups=[];
|
|
60
71
|
for (const r of state.stageRuns) {
|
|
@@ -67,15 +78,15 @@ export function sessionAdvice(directory,state,review,{saved=true}={}) {
|
|
|
67
78
|
const concluded=state.outcome.goal==='met' && review.runs.every(r=>r.ready)
|
|
68
79
|
&& (!!state.deliveryPolicy?.partialRef || completionStatus(state,review).readyForAcceptance);
|
|
69
80
|
const last=state.stageRuns.at(-1);
|
|
70
|
-
const endAction=concluded?'finished':(current??last)?.stage==='handoff'?'assess-outcome':'
|
|
81
|
+
const endAction=concluded?'finished':(current??last)?.stage==='handoff'?'assess-outcome':'await-continue';
|
|
71
82
|
let action='continue-current';
|
|
72
83
|
if (!saved) action='reconcile-save';
|
|
73
84
|
else if(pending) action='await-review';
|
|
74
85
|
else if(!current && state.stageRuns.length && review.runs.every(r=>r.ready)) action=concluded?endAction:review.runs.some(r=>r.releaseReady===false)?'resolve-current':endAction;
|
|
75
86
|
else if(current && ((!status?.resolvedBy && (['failed','mixed','unknown','not-run'].includes(current.result) || (current.stage==='review' && current.progress==='done' && !status?.releaseReady))) || current.progress==='blocked' || ['needs-review','unknown'].includes(current.applicability))) action=concluded && !next?'finished':'resolve-current';
|
|
76
|
-
else if(status?.ready) action=!next?endAction:next.progress!=='planned'?'inspect-existing-work':
|
|
87
|
+
else if(status?.ready) action=!next?endAction:next.progress!=='planned'?'inspect-existing-work':'await-continue';
|
|
77
88
|
if (saved && !pending && state.deliveryPolicy?.version === 1 && status?.ready && next && review.runs.find(r=>r.id===next.id)?.blockedBy.length) action='resolve-current';
|
|
78
|
-
const instruction=action==='
|
|
89
|
+
const instruction=action==='await-continue'?text(state,'This stage is saved. Stop here and wait for the user to continue; a new session is recommended, not required. Approval and continuation may be expressed together.','本阶段已保存。请在此停下,等待用户继续;建议新会话,也可在当前会话继续。批准和继续可以一次表达。'):action==='assess-outcome'?text(state,'Review the handoff against the agreed goal and record the actual goal conclusion and acceptance; completed handoff alone does not end the delivery.','请对照约定目标审阅交付材料,记录实际目标结论和用户接受结果;完成交付文档不等于交付已结束。'):null;
|
|
79
90
|
const continuation=['reconcile-save','await-review','assess-outcome','finished'].includes(action)?null:text(state,`Use Aimship to continue delivery ${JSON.stringify(path.resolve(directory))}; first read its current state and relevant formal documents, then continue the recorded work.${instruction?' '+instruction:''}`,`使用 Aimship 继续交付「${path.resolve(directory)}」,先读取当前状态和相关正式文档再接续。${instruction??''}`);
|
|
80
|
-
return {action,currentRun:current?.id??null,nextRun:next?.id??null,groups,continuation,instruction,advisory:true,note:text(state,'A session boundary is not a blocker or approval. Continue here when requested. Resolve the delivery identity, current approvals and unfinished effects on every resume; this text grants no approval.','会话边界不是阻塞或批准。用户要求时可在当前会话继续。每次续接都需核对交付身份、当前审批和未完成事项;本提示不授予权限。')};
|
|
91
|
+
return {action,stop:!['continue-current','inspect-existing-work'].includes(action),suggestNewSession:['await-review','await-continue'].includes(action),currentRun:current?.id??null,nextRun:next?.id??null,groups,continuation,instruction,advisory:true,note:text(state,'A session boundary is not a blocker or approval. Continue here when requested. Resolve the delivery identity, current approvals and unfinished effects on every resume; this text grants no approval.','会话边界不是阻塞或批准。用户要求时可在当前会话继续。每次续接都需核对交付身份、当前审批和未完成事项;本提示不授予权限。')};
|
|
81
92
|
}
|