Release 1.8.19

Author: clawplays

SKILL.md

@@ -49,6 +49,7 @@ Use the full `ospec execute ...` layer only for goal work or when the user expli
 - Complete design review before plan review under the configured document review policy. The default `always` policy requires independent review; `adaptive` may use deterministic inline preflight only when the target document explicitly declares `risk_level: low` (or `none`) and no risk signal exists. Missing or unparseable risk context requires specialist review.
 - Resolve required decisions and workspace isolation before dispatch.
 - Dispatch scoped worker packets, use the launch plan with the current harness native agent mechanism, record completion, then perform one combined task review.
+- Treat each task's canonical `artifacts/agents/worker-reports/<task-id>.md` as review-bound evidence. A fresh task review snapshots it alongside declared targets; a repair may edit only that same task's exact report path. When a legacy review finding names an unsnapshotted canonical report, let Loop issue a fresh review before repair instead of editing history or widening artifact scope.
 - A worker profile is logical (`mechanical`, `standard`, `strong_reasoning`, `review`, `final_review`). Harness-specific model names come from `.skillrc`; absence is explicit and falls back to the harness default.
 - Record optional provider usage sidecars through the supported completion command. Metrics are evidence, not an archive gate unless project policy says otherwise.
 - When final review requires changes, group all findings into one repair wave and one repair task, run its covering verification once, then run one combined task review and one final re-review. In continuous mode, a stalled task or final finding set may receive one durable root-cause strategy escalation; execute that packet normally, but never reissue the same strategy key or raise a limit to repeat unchanged work.

assets/for-ai/ar/execution-protocol.md

@@ -61,6 +61,7 @@ tags: [ai, protocol, ospec]
 - `IDE-CONTROLLER-AUTO-DISPATCH`: المستوى L1 للتقارير فقط. في L2/L3 يملك IDE AI دورة tick -> تنفيذ كل `actions[]` عبر `runtimeAdapter.selected.nativeSubagent` لكل action -> تسجيل heartbeat/result evidence -> tick فوري. إذا كانت `actions[]` فارغة مع وجود `pending` فهذه مراقبة فقط ولا يعاد التوزيع
 - أزيل agent CLI execution. تفشل `execute orchestrate` و`launch --run --command` و`review --run --command` و`loop watch` قبل تشغيل process أو إنشاء run artifact. استخدم `ospec execute retry` لإعادة native work
 - في Goal مملوكة لـ controller، استخدم `ospec loop tick [changes/active/<change>]` بعد اكتمال كل worker task لإنشاء مراجعة موحدة مرتبطة بـ executor provenance الحقيقي وحزمة محدودة النطاق. استخدم `ospec execute review ... --task <task-id>` مباشرةً فقط خارج controller Loop
+- تربط task review المسار canonical الدقيق `artifacts/agents/worker-reports/<task-id>.md` لنفس المهمة داخل target snapshot. يمكن لـ repair تعديل هذا report الدقيق للمهمة نفسها فقط؛ تبقى تقارير المهام الأخرى وأي controller artifacts عشوائية محظورة. إذا أشارت legacy finding إلى canonical report غير موجود في snapshot القديم، نفّذ fresh task-review action التي يصدرها Loop قبل repair ولا تعدّل historical evidence يدوياً
 - عند تفعيل `documentation_updates` في task graph، يجب أن تحتوي كل مهمة على المصفوفة (`[]` عند عدم الحاجة)، وأن يظهر كل مسار docs معلن أيضا في `target_files` للمهمة نفسها، وأن يملك دليلا على تغير فعلي بين dispatch وcomplete. يعد الحذف الذي تمت مراجعته تغييرا صالحا عندما يثبت evidence أن baseline موجودا أصبح مفقودا عند الإكمال. عبر محاولات repair المتعددة يقارن finalize أول baseline بالحالة النهائية المكتملة، ويشترط أن تطابق workspace أحدث evidence لمالك المسار المعلن، لذلك لا يكفي تغيير قديم ولا يمر التراجع اللاحق. إذا غير controller closeout مسارا معلنا بعد آخر worker dispatch، فلا تعتمد الحالة النهائية إلا مراجعة task لاحقة بحالة APPROVED، وexecutor provenance صالح، وtarget snapshot يطابق الملف الحالي تماما؛ ولا تحل هذه المراجعة محل meaningful-change chain. تبقى التشغيلات القديمة بلا baseline متوافقة فقط عندما تظل الوثيقة المعلنة موجودة، وتعرض الدليل كغير متحقق.
 - بعد اعتماد task-level reviews واكتمال task graph، دع `ospec loop tick` التالي ينشئ final review في controller Loop؛ استخدم `ospec execute review` من دون `--task` فقط خارج controller Loop
 - بعد أن يحتوي review artifact على قرار غير `PENDING`، استخدم `ospec execute feedback [changes/active/<change>] [--stage spec|quality]` لكتابة `artifacts/agents/review-feedback-plan.json` و`artifacts/agents/review-feedback-plan.md`؛ حدد accept أو revise أو clarify أو blocked قبل dispatch عمل إضافي، وأنشئ required user decision عندما يغير feedback scope أو direction أو API أو UI أو risk أو accepted tradeoffs، وأنشئ required user decision gate عندما يغير feedback scope أو direction أو API أو UI أو risk أو accepted tradeoffs

assets/for-ai/en-US/execution-protocol.md

@@ -63,6 +63,7 @@ tags: [ai, protocol, ospec]
 - Token economy (does not change any step): pass `--brief` on `ospec execute …` to read a lean summary instead of the full report, and drive each step from `ospec execute status --brief` instead of re-reading the full `task-graph.json`, `worker-status.md`, or `launch-plan.md` every turn — the artifacts are still written in full, so open them only when you need the detail
 - Agent CLI execution is removed: `execute orchestrate`, `launch --run --command`, `review --run --command`, and `loop watch` fail before process launch or run-artifact creation. Use `ospec execute retry` for corrected native work; completed tasks require explicit `--force`
 - After a worker records `DONE` or `DONE_WITH_CONCERNS`, use `ospec loop tick [changes/active/<change>]` in a controller-owned Goal to create the combined reviewer action with real executor provenance and a scoped `artifacts/agents/review-packages/*.diff`. Use `ospec execute review ... --task <task-id>` only outside a controller Loop
+- A task review binds the exact canonical `artifacts/agents/worker-reports/<task-id>.md` into its target snapshot. A repair may edit only that same task's exact report path; another task's report and arbitrary controller artifacts remain blocked. When a legacy finding names an unsnapshotted canonical report, execute the fresh task-review action emitted by Loop before repair instead of editing historical evidence
 - After all task-level reviews are approved and the task graph is completed, let the controller's next `ospec loop tick` create the combined final review. Use `ospec execute review` without `--task` only outside a controller Loop
 - Use `ospec execute feedback [changes/active/<change>] [--stage spec|quality]` after a review artifact has a non-`PENDING` decision to write `artifacts/agents/review-feedback-plan.json` and `artifacts/agents/review-feedback-plan.md`; handle review feedback through accept, revise, clarify, or blocked actions before dispatching more work, and create a required user decision gate when feedback changes scope, direction, API, UI, risk, or accepted tradeoffs
 - When debugging is part of the change, use `ospec execute debug [changes/active/<change>] --phase reproduce|isolate|hypothesize|fix|verify --symptom "..." --root-cause "..." --status FIXED` to record `artifacts/agents/debug-evidence.json`; `CONFIRMED` isolates root cause, `FIXED` verifies the fix, and `BLOCKED` fails verification

assets/for-ai/ja-JP/execution-protocol.md

@@ -60,6 +60,7 @@ tags: [ai, protocol, ospec]
 - `IDE-CONTROLLER-AUTO-DISPATCH`: L1 は report-only。L2/L3 では IDE AI が tick -> 各 action の `runtimeAdapter.selected.nativeSubagent` で全 `actions[]` を実行 -> heartbeat/result evidence -> 即時 tick を担当する。`actions[]` が空で `pending` がある場合は観察のみで再 dispatch しない
 - agent CLI execution は削除された。`execute orchestrate`、`launch --run --command`、`review --run --command`、`loop watch` は process 起動や run artifact 作成の前に失敗する。native work の再実行には `ospec execute retry` を使う
 - controller-owned Goal では、各 worker task 完了後に `ospec loop tick [changes/active/<change>]` で実 executor provenance に結び付いた統合 review と task-scoped package を作成する。`ospec execute review ... --task <task-id>` を直接使うのは non-controller workflow のみとする
+- task review は、その task の正確な canonical `artifacts/agents/worker-reports/<task-id>.md` を target snapshot に結び付ける。repair が編集できるのは同じ task の正確な report path だけであり、別 task の report と任意の controller artifact は引き続き block する。legacy finding が snapshot 未登録の canonical report を指す場合は、history を手編集せず、Loop が発行する fresh task-review action を実行してから repair する
 - task graph で `documentation_updates` を有効にした場合、各 task に配列を持たせ（不要なら `[]`）、宣言した docs path を同じ task の `target_files` に含め、dispatch から complete までの有意な content change evidence を残す。既存 baseline が完了時に missing になったことを evidence が証明する reviewed deletion は有効な変更である。複数 repair attempt では finalize が最初の baseline と最後の完了状態を比較し、workspace がその path の最新 declared owner evidence と一致することを要求するため、古い変更や後続の reversion は通過しない。controller closeout が最後の worker dispatch 後に宣言 path を変更した場合、その最終状態を許可できるのは、より後に実行され、executor provenance が有効で、現在の target snapshot と完全一致する APPROVED task review だけであり、meaningful-change chain の代わりにはならない。baseline のない旧 run は宣言文書が現在も存在する場合だけ互換性を保ち、未検証と表示する。
 - task graph 完了後の final review も controller Loop の次の `ospec loop tick` で発行する。`--task` なしの `ospec execute review` を直接使うのは non-controller workflow のみとする
 - review artifact が non-`PENDING` decision を持つ場合は `ospec execute feedback [changes/active/<change>] [--stage spec|quality]` で `artifacts/agents/review-feedback-plan.json` と `artifacts/agents/review-feedback-plan.md` を書く。追加作業を dispatch する前に accept、revise、clarify、blocked の handling を明確にし、feedback が scope、direction、API、UI、risk、accepted tradeoffs を変える場合は required user decision gate を作成する

assets/for-ai/zh-CN/execution-protocol.md

@@ -63,6 +63,7 @@ tags: [ai, protocol, ospec]
 - `IDE-CONTROLLER-AUTO-DISPATCH`：L1 只报告；L2/L3 由 IDE 主 AI 负责 tick -> 通过每个 action 的 `runtimeAdapter.selected.nativeSubagent` 执行全部 `actions[]` -> 写 heartbeat/result evidence -> 立即再 tick。`actions[]` 为空但存在 `pending` 时只观察，绝不能重派
 - agent CLI 执行已移除：`execute orchestrate`、`launch --run --command`、`review --run --command` 和 `loop watch` 都会在启动进程或创建 run artifact 前失败。修复 native work 后使用 `ospec execute retry`；已完成任务需显式 `--force`
 - worker 记录 `DONE` 或 `DONE_WITH_CONCERNS` 后，controller-owned Goal 用 `ospec loop tick [changes/active/<change>]` 生成带真实 executor provenance 的合并 review action 和范围受控的 `artifacts/agents/review-packages/*.diff`；只有非 controller 流程才直接运行 `ospec execute review ... --task <task-id>`
+- task review 会把精确的本任务 canonical `artifacts/agents/worker-reports/<task-id>.md` 绑定进 target snapshot。repair 只能编辑同一任务的这个精确 report 路径；其他任务 report 和任意 controller artifact 仍然阻塞。旧 finding 若指向未被当时 dispatch 快照绑定的 canonical report，应执行 Loop 自动发出的 fresh task-review action 后再 repair，不得手改历史 evidence
 - task graph 启用 `documentation_updates` 后，每个 task 都必须包含该数组（没有则为 `[]`）；声明的 docs 路径必须同时出现在同一 task 的 `target_files` 中，并具有从 dispatch 到 complete 的有效内容变化证据。若 evidence 证明已有 baseline 在完成时变为不存在，则经过 review 的删除属于有效变化。多轮 repair 时，finalize 比较首个 baseline 与最终完成态，并要求当前工作区匹配该路径最后一个声明 owner 的 evidence，旧修改或后续回退不能通过。如果 controller closeout 在最后一次 worker dispatch 后修改了声明路径，只有更晚、executor provenance 有效且 target snapshot 精确匹配当前文件的 APPROVED task review 才能授权最终状态；它不能替代 meaningful-change 证据链。没有历史 baseline 的旧流程仅在声明文档仍存在时保持兼容，并必须把证据标记为无法验证。
 - 所有单任务 review 通过且 task graph 完成后，controller Loop 用下一次 `ospec loop tick` 生成最终整体 review；只有非 controller 流程才直接运行不带 `--task` 的 `ospec execute review`
 - review artifact 有非 `PENDING` 决策后，用 `ospec execute feedback [changes/active/<change>] [--stage spec|quality]` 写入 `artifacts/agents/review-feedback-plan.json` 和 `artifacts/agents/review-feedback-plan.md`；继续派发工作前，必须明确接受、修订、澄清或解除阻塞；当反馈影响范围、方向、API、UI、风险或已接受取舍时创建 required user decision gate

assets/global-skills/codex/ospec-goal/SKILL.md

@@ -21,6 +21,7 @@ Use this skill for complex work that needs the full OSpec workflow. A goal is in
 - **`/goal` is capability-probed, not inferred from a target name.** `ospec execute launch --primitive goal` produces a native-`/goal` instruction only when the current harness explicitly reports support; otherwise the same controller runs the verify-driven loop through native subagents.
 - **Scheduling is session-bound.** Controller mode re-runs `loop run --once` and consumes the emitted action batch through `runtimeAdapter.selected.nativeSubagent`. Unknown native capacity uses the default implementation concurrency of three while leaving conflict-safe review batches under the configured limit. When the current harness can authoritatively report a larger positive child capacity, bind it to the active controller session and raise `maxParallel` as appropriate; reported capacities such as 5-10 replace the fallback but never override dependencies, file conflicts, token funding, or the configured maximum. Never guess capacity from a provider name or stale session. If the session capability expires, OSpec blocks instead of starting an agent CLI.
 - **Progress and feedback are artifact-backed.** Task status, task/final review decisions, grouped repair waves, verification evidence, `state.json`, and `run-log.jsonl` carry progress between fresh contexts. Process exit alone does not complete an action. Dispatch only items returned in `actions`; a durable `pending` record with an empty action list is observation state and must not be relaunched.
+- **Worker reports are task-owned review evidence.** Every fresh task review binds the exact canonical `artifacts/agents/worker-reports/<task-id>.md` into its target snapshot. A structured repair may name only that same task's exact report path; another task's report, a parent artifact directory, review history, and arbitrary controller evidence remain out of scope. If an older review finding names a canonical report that its dispatch did not snapshot, execute the fresh task-review action emitted by Loop before repair; do not hand-edit or delete the old finding.
 - **Guards are enforced before new work.** Pause/STOP, iteration/deadline/token/time budgets, no-progress limits, comprehension-review checkpoints, required decisions, approved document reviews, ready workspace evidence, and L3 allowlists can stop or pause the loop.
 - **Document review is convergent.** Specialist design/plan review uses two rounds and 30 minutes as default convergence thresholds. In continuous mode, a new structured finding-ID set may continue automatically; a repeated or cycling set stops. Cache/pending reuse, heartbeat, lease recovery, and deterministic preflight do not consume rounds. Never use `--force` to bypass a guard. Strict mode retains the exact user-authorized extra-round window. Read the prior findings sidecar and resolution evidence before the full document when revising. Every structured finding must have a non-empty unique ID.
 - **Review repair is convergent and regression-aware.** A downstream task that shares target files inherits transitive upstream regression obligations. Retryable dependent work waits for every missing prerequisite review to receive Loop executor provenance. A finding may cross the current task boundary only when every extra path belongs to a declared completed task; OSpec freezes the complete scope and re-reviews changed owners. While any recorded cross-task owner remains unapproved, its review or repair precedes new implementation and retryable worker work; other conflict-safe reviewers may stay parallel. Unknown or unfinished scope owners remain blocked. The default two-round values are convergence thresholds. Changed structured finding IDs continue automatically. A stable ID may also continue only when both its structured finding fingerprint and its authorized repair-scope code snapshot changed. In continuous mode, stalled task or final findings receive one durable strategy escalation for that exact scope and finding-ID set; follow its root-cause and regression instructions, then stop if the same set remains stalled because the same strategy key cannot be issued twice. Strict mode retains its configured limit. A blocked final review requires blocker resolution and must not enter grouped repair. Never raise a limit to repeat unchanged work.

dist/cli.js

@@ -62,7 +62,7 @@ const VerifyCommand_1 = require("./commands/VerifyCommand");
 const WorkflowCommand_1 = require("./commands/WorkflowCommand");
 const LayoutCommand_1 = require("./commands/LayoutCommand");
 const services_1 = require("./services");
-const CLI_VERSION = '1.8.18';
+const CLI_VERSION = '1.8.19';
 function showInitUsage() {
     console.log('Usage: ospec init [root-dir] [--summary "..."] [--tech-stack node,react] [--architecture "..."] [--document-language en-US|zh-CN|ja-JP|ar]');
 }