🎩 You're Invited:Meet the Socket team at Black Hat in Las Vegas, August 3-6.RSVP →
Sign In

@clawplays/ospec-cli

Package Overview
Dependencies
Maintainers
1
Versions
43
Alerts
File Explorer

Advanced tools

License
Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@clawplays/ospec-cli - npm Package Compare versions

Comparing version
1.8.9
 to
1.8.11
+2
-1
assets/for-ai/ar/ai-guide.md

@@ -51,3 +51,3 @@ ---

- اكتب كل وثيقة change وbrainstorm تنشئها بلغة وثائق المشروع (`documentLanguage` في `.skillrc` / إرشادات `for-ai/` المُدارة)؛ لا تخلط العربية والإنجليزية داخل change واحد
- عندما تحتاج إلى handoff artifacts دائمة على مستوى task، استخدم `ospec execute dispatch` لإنشاء batch آمن للتوازي من worker packets و`ospec execute complete` لتسجيل نتائج worker؛ يتضمن كل dispatch packet project session brief snapshot وworker profile يوضح capability tier وrecommended target وtarget tool mapping وrationale وrequired behavior؛ عندما تكون النتيجة `NEEDS_CONTEXT` أو `BLOCKED` يكتب `complete` ملفات `artifacts/agents/blockers/`؛ استخدم `--task` لمهمة واحدة صريحة و`--limit` لتحديد حجم dispatch batch؛ بعد اكتمال كل worker task استخدم `ospec execute review [changes/active/<change>] --task <task-id>` لإجراء مراجعة موحدة واحدة (spec compliance وcode quality في تمريرة واحدة)، وتبقى المهام التابعة محجوبة حتى اعتماد تلك المراجعة الموحدة الواحدة؛ وبعد اعتماد كل task-level reviews واكتمال task graph استخدم `ospec execute review` من دون `--task` لإنشاء حزمة code review نهائية موحدة واحدة؛ وبعد decision غير `PENDING` استخدم `ospec execute feedback` لكتابة `artifacts/agents/review-feedback-plan.md`؛ وبعد تعديل execution أو review artifacts يدويا استخدم `ospec execute sync` لإعادة بناء `worker-status.md`
- استخدم `ospec execute dispatch` و`ospec execute complete` للـ handoff الدائم؛ تتضمن كل packet project session brief snapshot وworker profile وtarget tool mapping، ويحدد `--task` و`--limit` النطاق. في Goal مملوكة لـ controller، أصدر task/final reviews عبر `ospec loop tick [changes/active/<change>]` لربط `artifacts/agents/review-dispatches/` بـ executor provenance الحقيقي؛ استخدم `ospec execute review` فقط خارج controller Loop، ثم `ospec execute feedback` بعد القرار و`ospec execute sync` بعد التعديل اليدوي
- توفير الـ tokens لا يغيّر أي gate: استخدم `--brief` مع `ospec execute …` و`ospec loop status`، وقُد العمل من الحالة المختصرة وpacket path. في إعادة المراجعة اقرأ prior findings sidecar وملخص الحل أولا، ولا تفتح task graph أو worker status أو launch plan أو مستندات goal كاملة إلا عند الحاجة

@@ -100,4 +100,5 @@ - بعد dispatch، استخدم `ospec execute launch [changes/active/<change>] [--task task-id] [--target codex|gpt|claude|gemini|opencode|cursor|copilot] [--dry-run] [--json]` لكتابة launch plan؛ يقبل `runtimeAdapter` فقط model-native subagent capability حالية ومرتبطة بالـ target ويعرض native primitive

- يكتب reviewer ملف Markdown للبشر وملف `*.findings.json` مجاورا بمعرفات ثابتة وseverity وcategory وmessage ودليل file/line ومراجع المتطلبات ونطاق الإصلاح. يحوّل Markdown القديم إلى sidecar متوافق قبل repair.
- حافظ على finding ID ثابتا بينما يضيق العيب الجذري نفسه. بعد عتبة التقارب لا يواصل OSpec هذا المعرف إلا عندما يتغير كل من structured finding fingerprint وcode snapshot داخل repair scope المصرح به سابقا. لا تخترع معرفا جديدا ولا تعيد صياغة evidence فقط لفرض repair أخرى.
- لكل مسار معلن في `documentation_updates` تحفظ سجلات dispatch وcomplete بصمة المحتوى المطبّع. يفشل documentation gate في التشغيل الجديد إذا لم يتغير المحتوى فعليا، ويُعلّم التشغيل القديم بلا baseline كغير متحقق. يربط archive index وثائق المشروع الدائمة المحدثة مباشرة بالميزة المكتملة.
- عند كل finalize/archive ناجح ينشئ OSpec وثيقة محلية واحدة `docs/project/changes/<archive-path>.md` للـ change أو goal المؤرشف ويتحقق من ربطها في الفهرسين. قبل نقل change النشط، يرفض فحص archive المسبق الكتابة فوق وثيقة يملكها البشر في مسار التوليد ويتحقق من قابلية الكتابة في أدلة الإخراج المُدارة. لا يحل سجل change العام هذا محل وثائق architecture أو API أو module أو operation المطلوبة.
- عندما يكون final review هو `NEEDS_CHANGES`، حل required decisions ثم استخدم `ospec execute repair` لجمع كل findings في repair task واحدة، ثم verification وtask review وfinal re-review مرة واحدة لكل منها.
+3
-3
assets/for-ai/ar/execution-protocol.md

@@ -41,3 +41,3 @@ ---

- يجب أن تتقارب مراجعة المستندات المتخصصة. اقرأ findings sidecar السابق وأدلة الحل أولا، ثم راجع المستند الحالي كاملا. قيم round/time الافتراضية هي عتبات تقارب: يمكن لمجموعة structured finding-ID جديدة أن تستمر تلقائيا، بينما تتوقف المجموعات المتكررة أو الدورية. لا تستهلك cache/pending reuse أو استعادة dispatch نفسه جولة، ولا يتجاوز `--force` حواجز Loop lifetime أو token أو STOP أو no-progress أو context أو executor provenance. يحتفظ strict mode بنافذة extra round التي يصرح بها المستخدم بدقة.
- يجب أن تتقارب عمليات review repair. ترث task downstream التي تعدل ملفات مشتركة التزامات regression من upstream المتعدية. تمثل الجولتان الافتراضيتان عتبة تقارب: يستمر التنفيذ تلقائيا عندما تتغير معرفات findings المنظمة، ويتوقف قبل repair آخر عندما تتكرر المعرفات نفسها. عندما تكون final review بحالة `BLOCKED` يجب التوقف لحل blocker وعدم بدء grouped repair. لا ترفع الحدود لتجاوز findings غير المتغيرة.
- يجب أن تتقارب عمليات review repair. ترث task downstream التي تعدل ملفات مشتركة التزامات regression من upstream المتعدية. تمثل الجولتان الافتراضيتان عتبة تقارب. يستمر التنفيذ عندما تتغير structured finding IDs. ويمكن أن يستمر المعرف نفسه فقط عندما يتغير كل من structured finding fingerprint وcode snapshot داخل repair scope المصرح به سابقا؛ أما تغيير الصياغة فقط أو الكود فقط أو التكرار الدقيق أو الدورة فيتوقف. عندما تكون final review بحالة `BLOCKED` يجب التوقف لحل blocker وعدم بدء grouped repair. لا ترفع الحدود لتجاوز evidence غير المتغيرة.
- يجب أن يكون انتظار native child محدوداً في كل harness. يعيد `wait_agent` في Codex/GPT وpolling لـ Claude Task وأي native wait آخر التحكم خلال 60 ثانية؛ هذا حد poll واحدة للـ controller وليس حد تشغيل child. حدّث كل child حي قبل `heartbeatDueAt`، وعند الاكتمال استخدم `loop finalize` الصادر مع action لحفظ evidence وresult ذرياً، ثم أعد tick بعد كل poll. يمكن للـ child الاستمرار عبر عدة polls حتى action deadline، وتوجد result grace محدودة بعد اكتمال evidence. عند غياب capacity يقتصر implementation batch على مهمتين من دون تقليل توازي review الآمن.

@@ -62,5 +62,5 @@ - عند بدء أو استئناف active change واحد، استخدم `ospec execute bootstrap [changes/active/<change>]` لكتابة `artifacts/agents/bootstrap.json` و`artifacts/agents/bootstrap.md` مع project session brief snapshot، ثم اتبع الإجراء الآمن التالي المسجل فيه

- أزيل agent CLI execution. تفشل `execute orchestrate` و`launch --run --command` و`review --run --command` و`loop watch` قبل تشغيل process أو إنشاء run artifact. استخدم `ospec execute retry` لإعادة native work
- بعد اكتمال كل worker task، استخدم `ospec execute review [changes/active/<change>] --task <task-id>` لإنشاء مراجعة موحدة وملف `artifacts/agents/review-packages/*.diff` محدود بنطاق المهمة. يقرأ reviewer الحزمة مرة واحدة، وتُسجل الأحجام والمدة في `artifacts/agents/execution-metrics.json`
- في Goal مملوكة لـ controller، استخدم `ospec loop tick [changes/active/<change>]` بعد اكتمال كل worker task لإنشاء مراجعة موحدة مرتبطة بـ executor provenance الحقيقي وحزمة محدودة النطاق. استخدم `ospec execute review ... --task <task-id>` مباشرةً فقط خارج controller Loop
- عند تفعيل `documentation_updates` في task graph، يجب أن تحتوي كل مهمة على المصفوفة (`[]` عند عدم الحاجة)، وأن يظهر كل مسار docs معلن أيضا في `target_files` للمهمة نفسها، وأن يكون موجودا قبل الأرشفة، وأن يملك دليلا على تغير محتوى فعلي بين dispatch وcomplete. تبقى التشغيلات القديمة بلا baseline متوافقة لكنها تعرض الدليل كغير متحقق.
- بعد اعتماد كل task-level reviews واكتمال task graph، استخدم `ospec execute review [changes/active/<change>]` من دون `--task` لإنشاء حزمة code review نهائية موحدة واحدة داخل `artifacts/agents/review-dispatches/`؛ وهي مراجعة واحدة تكتب قرار `artifacts/reviews/final-review.md` واحد
- بعد اعتماد 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

@@ -67,0 +67,0 @@ - عندما يكون debugging جزءا من change، استخدم `ospec execute debug [changes/active/<change>] --phase reproduce|isolate|hypothesize|fix|verify --symptom "..." --root-cause "..." --status FIXED` لتسجيل `artifacts/agents/debug-evidence.json`؛ تعني `CONFIRMED` عزل root cause، وتعني `FIXED` إصلاحا متحققا، وتؤدي `BLOCKED` إلى فشل verify

+2
-1
assets/for-ai/en-US/ai-guide.md

@@ -53,3 +53,3 @@ ---

- Write every change document and brainstorm you author in the project's document language (`.skillrc` `documentLanguage` / managed `for-ai/` guidance); do not mix Chinese and English within a change
- Use `ospec execute dispatch` to create a parallel-safe batch of worker packets and `ospec execute complete` to record worker results when task-level execution needs durable handoff artifacts; each dispatch packet includes the project session brief snapshot and a worker profile with capability tier, recommended target, target tool mapping, rationale, and required behavior; required pending user decisions block dispatch; `complete` writes `artifacts/agents/blockers/` when the result is `NEEDS_CONTEXT` or `BLOCKED`; use `--task` for one explicit task and `--limit` to cap dispatch batch size; after each `DONE` or `DONE_WITH_CONCERNS` worker result, run the task's single combined review with `ospec execute review [changes/active/<change>] --task <task-id>` (spec compliance and code quality in one pass) before dispatching dependent work; after all task-level reviews complete, use `ospec execute review` without `--task` for the single combined final whole-change code review packet; use `ospec execute feedback` after non-`PENDING` final review decisions to write `artifacts/agents/review-feedback-plan.md`; use `ospec execute sync` to rebuild `worker-status.md` after manual execution or review artifact edits
- Use `ospec execute dispatch` to create a parallel-safe batch of worker packets and `ospec execute complete` to record worker results; each packet includes the project session brief snapshot and a worker profile with capability tier, recommended target, target tool mapping, rationale, and required behavior. Use `--task` for one task and `--limit` to cap a batch; required decisions block dispatch and `complete` writes blocker evidence for `NEEDS_CONTEXT` or `BLOCKED`. In a controller-owned Goal, use `ospec loop tick [changes/active/<change>]` for every task and final review so `artifacts/agents/review-dispatches/` is bound to real executor provenance; use `ospec execute review` directly only outside a controller Loop. Use `ospec execute feedback` after review decisions and `ospec execute sync` after manual artifact edits
- Use `ospec execute launch [changes/active/<change>] [--task task-id] [--target codex|gpt|claude|gemini|opencode|cursor|copilot] [--dry-run] [--json]` after dispatch to write the launch plan. Its `runtimeAdapter` accepts only a current, target-bound model-native subagent capability and exposes the native primitive

@@ -121,4 +121,5 @@ - Execute `runtimeAdapter.selected.nativeSubagent`; parallelize only the safe batch. If capability is missing or expired, block and refresh the current model session instead of starting an agent CLI or using the controller context

- Reviewers write human-readable Markdown and a sibling `*.findings.json` with stable IDs, severity, category, message, file/line evidence, requirement references, and repair scope. Legacy Markdown is converted to a compatibility sidecar before repair.
- Keep a finding ID stable while the same root defect narrows. After the convergence threshold, OSpec continues that ID only when both its structured fingerprint and the prior authorized repair-scope code snapshot changed. Do not invent a new ID or merely reword evidence to force another repair.
- For each declared `documentation_updates` path, dispatch and completion records capture normalized content hashes. A new run fails the documentation gate when the file exists but did not change meaningfully; legacy runs without baseline evidence are marked unverified. Archive indexes link the updated durable project documents directly from the completed feature.
- Every successful finalize/archive generates one localized `docs/project/changes/<archive-path>.md` for the archived change or goal and verifies that both indexes link it. Before moving the active change, archive preflight refuses to overwrite a human-owned file at that path and verifies the managed output directories are writable. This universal change record does not replace required human-maintained architecture, API, module, or operational docs.
- When final review is `NEEDS_CHANGES`, resolve required decisions and use `ospec execute repair` to group all findings into one repair task, followed by one covering verification, one task review, and one final re-review.
+3
-3
assets/for-ai/en-US/execution-protocol.md

@@ -43,3 +43,3 @@ ---

- Specialist document review must converge. Consume the prior findings sidecar and resolution evidence, then review the complete current document. The default round/time values are convergence thresholds: a new structured finding-ID set may continue automatically, while a repeated or cycling set stops. Cache/pending reuse and recovery of the same dispatch do not consume a round; `--force` never bypasses Loop lifetime, token, STOP, no-progress, context, or executor-provenance guards. Strict mode retains the exact user-authorized extra-round window.
- Review repair must converge. A downstream task that shares files inherits transitive upstream regression obligations. The default two-round values are convergence thresholds: continue automatically when structured finding IDs change, and stop before another repair when the same IDs repeat. A blocked final review stops for blocker resolution; it never enters grouped repair. Do not raise a limit to bypass unchanged findings.
- Review repair must converge. A downstream task that shares files inherits transitive upstream regression obligations. The default two-round values are convergence thresholds. Continue when structured finding IDs change. A stable ID may also continue only when both its structured finding fingerprint and its prior authorized repair-scope code snapshot changed; wording-only or code-only churn, exact repeats, and cycles stop. A blocked final review stops for blocker resolution; it never enters grouped repair. Do not raise a limit to bypass unchanged evidence.
- Native child waiting is bounded on every harness. Codex/GPT `wait_agent`, Claude Task polling, and other native waits return within 60 seconds; this limits one controller poll, not the child runtime. Refresh every live child before `heartbeatDueAt`, persist each completed result with its emitted `loop finalize` command, and re-tick after every poll. A live child may continue across polls up to its action deadline, and evidence-complete work receives a bounded result grace period. Unknown capacity caps implementation batches at two but does not reduce safe review parallelism.

@@ -64,4 +64,4 @@ - When starting or resuming one active change, use `ospec execute bootstrap [changes/active/<change>]` to write `artifacts/agents/bootstrap.json` and `artifacts/agents/bootstrap.md` with the project session brief snapshot, then follow its next safe action

- 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 execute review [changes/active/<change>] --task <task-id>` to create one combined code reviewer packet and a scoped `artifacts/agents/review-packages/*.diff`; read that package once instead of repeating broad Git discovery. Packet, report, package, and duration metrics are recorded in `artifacts/agents/execution-metrics.json`
- After all task-level reviews are approved and the task graph is completed, use `ospec execute review [changes/active/<change>]` without `--task` to create one combined final whole-change code reviewer packet with the project session brief snapshot under `artifacts/agents/review-dispatches/`; it is a single review that writes one `artifacts/reviews/final-review.md` decision
- 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
- 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

@@ -68,0 +68,0 @@ - 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

+2
-1
assets/for-ai/ja-JP/ai-guide.md

@@ -51,3 +51,3 @@ ---

- あなたが作成するすべての change ドキュメントと brainstorm は、プロジェクトのドキュメント言語（`.skillrc` の `documentLanguage` / 管理対象の `for-ai/` ガイダンス）で書く。1 つの change 内で中国語と英語を混在させない
- task-level の永続 handoff artifacts が必要な場合は、`ospec execute dispatch` で parallel-safe な worker packet batch を作成し、`ospec execute complete` で worker 結果を記録する。各 dispatch packet には project session brief snapshot と、capability tier、recommended target、target tool mapping、rationale、required behavior を示す worker profile が含まれる。結果が `NEEDS_CONTEXT` または `BLOCKED` の場合、`complete` は `artifacts/agents/blockers/` を書く。`--task` は明示的な単一 task、`--limit` は dispatch batch size の上限に使う。各 worker task 完了後は `ospec execute review [changes/active/<change>] --task <task-id>` で統合 review（spec compliance と code quality を一度に確認）を行い、dependent task はその 1 回の統合 review が承認されるまで dispatch されない。すべての task-level review が承認され task graph が完了した後は、`--task` なしの `ospec execute review` で 1 つの統合 final whole-change code reviewer handoff packet を作成する。review decision が non-`PENDING` の場合は `ospec execute feedback` で `artifacts/agents/review-feedback-plan.md` を書く。実行または review artifacts を手動編集した後は `ospec execute sync` で `worker-status.md` を再構築する
- task-level の永続 handoff には `ospec execute dispatch` と `ospec execute complete` を使う。packet には project session brief snapshot、worker profile、target tool mapping を含め、`--task` と `--limit` で範囲を指定する。controller-owned Goal の task/final review は `ospec loop tick [changes/active/<change>]` で発行し、`artifacts/agents/review-dispatches/` を実 executor provenance に関連付ける。`ospec execute review` は non-controller workflow のみとし、review 後は `ospec execute feedback`、手動変更後は `ospec execute sync` を使う
- トークン節約（gate は変えない）：`ospec execute …` と `ospec loop status` に `--brief` を付け、brief status と action の packet path から進める。再 review では prior findings sidecar/resolution summary を先に読み、task graph、worker status、launch plan、goal documents 全体は必要時だけ開く

@@ -100,4 +100,5 @@ - dispatch 後は `ospec execute launch [changes/active/<change>] [--task task-id] [--target codex|gpt|claude|gemini|opencode|cursor|copilot] [--dry-run] [--json]` で launch plan を書く。`runtimeAdapter` は current かつ target-bound な model-native subagent capability のみを受け入れ、native primitive を示す

- reviewer は人向け Markdown と、stable ID、severity、category、message、file/line evidence、requirement refs、repair scope を持つ隣接 `*.findings.json` を書く。旧 Markdown は repair 前に互換 sidecar へ変換する。
- 同じ root defect が狭まる間は finding ID を維持する。収束しきい値を超えた後、OSpec は structured finding fingerprint と直前に許可された repair scope 内の code snapshot が両方変化した場合だけ同じ ID を続行する。新しい ID の捏造や evidence の言い換えだけで repair を強制しない。
- 宣言された各 `documentation_updates` path について dispatch と complete が正規化 content hash を保存する。新規 run で有意な変更がなければ documentation gate は失敗し、baseline のない旧 run は未検証と表示する。archive index は完了 feature から更新済みの永続 project document を直接リンクする。
- finalize/archive が成功するたびに、archive 済み change または goal 用のローカライズされた `docs/project/changes/<archive-path>.md` を 1 つ生成し、両方の index がリンクすることを検証する。active change を移動する前に、archive preflight は生成先にある人所有の文書の上書きを拒否し、管理対象の出力ディレクトリが書き込み可能であることを確認する。この共通 change record は必要な architecture、API、module、operation 文書の代わりにはならない。
- final review が `NEEDS_CHANGES` の場合、required decisions 解決後に `ospec execute repair` で全 findings を 1 repair task にまとめ、covering verification、task review、final re-review を各 1 回行う。
+3
-3
assets/for-ai/ja-JP/execution-protocol.md

@@ -41,3 +41,3 @@ ---

- specialist document review は収束させる。前回の findings sidecar と resolution evidence を先に確認し、その後 current document 全体を review する。既定の round/time 値は収束しきい値であり、新しい structured finding-ID set は自動続行できるが、反復または循環する set は停止する。cache/pending reuse と同じ dispatch の recovery は round を消費せず、`--force` は Loop lifetime、token、STOP、no-progress、context、executor provenance の guard を迂回しない。strict mode は exact user-authorized extra-round window を維持する。
- review repair は収束させる。共有ファイルを変更する downstream task は推移的 upstream の regression obligation を継承する。既定の 2 round は収束しきい値であり、構造化 finding ID が変化している間は自動続行し、同じ ID が繰り返された場合は次の repair の前に停止する。final review が `BLOCKED` の場合は blocker の解決まで停止し、grouped repair に進めない。変化しない findings を回避するために上限を引き上げてはならない。
- review repair は収束させる。共有ファイルを変更する downstream task は推移的 upstream の regression obligation を継承する。既定の 2 round は収束しきい値であり、structured finding ID が変化すれば自動続行する。同じ ID でも structured finding fingerprint と直前に許可された repair scope 内の code snapshot が両方変化した場合だけ続行できる。文言だけ、code だけの churn、完全な反復、cycle は停止する。final review が `BLOCKED` の場合は blocker の解決まで停止し、grouped repair に進めない。変化しない evidence を回避するために上限を引き上げてはならない。
- すべての harness で native child の待機を bounded にする。Codex/GPT の `wait_agent`、Claude Task polling、その他の native wait は 60 秒以内に戻る。この 60 秒は controller poll 1 回の上限であり、child runtime の上限ではない。各 live child を `heartbeatDueAt` 前に更新し、完了時は action の `loop finalize` で evidence と result を atomic に保存して poll ごとに再 tick する。child は action deadline まで複数 poll にまたがって実行でき、evidence 完了後には bounded result grace がある。capacity 不明時は implementation batch を 2 件までに制限するが、安全な review 並列性は維持する。

@@ -61,5 +61,5 @@ - one active change を開始または再開するときは、`ospec execute bootstrap [changes/active/<change>]` で project session brief snapshot を含む `artifacts/agents/bootstrap.json` と `artifacts/agents/bootstrap.md` を書き、そこにある次の安全な action に従う

- agent CLI execution は削除された。`execute orchestrate`、`launch --run --command`、`review --run --command`、`loop watch` は process 起動や run artifact 作成の前に失敗する。native work の再実行には `ospec execute retry` を使う
- 各 worker task 完了後、`ospec execute review [changes/active/<change>] --task <task-id>` で統合 review と task-scoped `artifacts/agents/review-packages/*.diff` を作成する。reviewer は package を一度読み、広範な Git 探索を繰り返さない。サイズと所要時間は `artifacts/agents/execution-metrics.json` に記録される
- 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 graph で `documentation_updates` を有効にした場合、各 task に配列を持たせ（不要なら `[]`）、宣言した docs path を同じ task の `target_files` に含め、archive 前に存在させ、dispatch から complete までの有意な content change evidence を残す。baseline のない旧 run は互換性を保つが未検証と表示する。
- すべての task-level review が承認され task graph が完了した後、`--task` なしの `ospec execute review [changes/active/<change>]` で 1 つの統合 final whole-change code reviewer handoff packet を `artifacts/agents/review-dispatches/` に作成する。これは単一 `artifacts/reviews/final-review.md`・1 つの decision
- 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 を作成する

@@ -66,0 +66,0 @@ - debugging が change の一部だった場合、`ospec execute debug [changes/active/<change>] --phase reproduce|isolate|hypothesize|fix|verify --symptom "..." --root-cause "..." --status FIXED` で `artifacts/agents/debug-evidence.json` を記録する。`CONFIRMED` は root cause の隔離、`FIXED` は verified fix、`BLOCKED` は verify failure を意味する

+2
-1
assets/for-ai/zh-CN/ai-guide.md

@@ -53,3 +53,3 @@ ---

- 你产出的每个 change 文档和 brainstorm 都要用项目的文档语言（`.skillrc` 的 `documentLanguage` / 托管 `for-ai/` 指引）书写；同一个 change 内不要中英文混用
- 需要 task 级持久交接时，用 `ospec execute dispatch` 生成并行安全的 worker 任务包批次，用 `ospec execute complete` 记录 worker 结果；每个 dispatch packet 都包含 project session brief snapshot 和 worker profile，说明 capability tier、recommended target、target tool mapping、rationale 和 required behavior；required pending user decision 会阻止 dispatch；当结果是 `NEEDS_CONTEXT` 或 `BLOCKED` 时，`complete` 会写入 `artifacts/agents/blockers/`；用 `--task` 指定单个任务，用 `--limit` 限制派发批次大小；每个 worker 返回 `DONE` 或 `DONE_WITH_CONCERNS` 后，用 `ospec execute review [changes/active/<change>] --task <task-id>` 做一次合并 review（一次同时审 spec 符合性与代码质量），依赖任务会等这一次合并 review 通过后才可派发；所有单任务 review 通过且 task graph 完成后，再用不带 `--task` 的 `ospec execute review` 生成一个合并的最终整体 code review 交接包；最终 review 决策不是 `PENDING` 后，用 `ospec execute feedback` 写入 `artifacts/agents/review-feedback-plan.md`；人工改过执行或 review artifacts 后，用 `ospec execute sync` 重建 `worker-status.md`
- 需要 task 级持久交接时，用 `ospec execute dispatch` 生成并行安全的 worker 包，用 `ospec execute complete` 记录结果；每个 packet 包含 project session brief snapshot 和带 capability tier、recommended target、target tool mapping、rationale、required behavior 的 worker profile。用 `--task` 指定任务、`--limit` 限制批次。controller-owned Goal 的 task/final review 由 `ospec loop tick [changes/active/<change>]` 派发，使 `artifacts/agents/review-dispatches/` 绑定真实 executor provenance；只有非 controller 流程才直接运行 `ospec execute review`。review 后用 `ospec execute feedback`，人工修改 artifact 后用 `ospec execute sync`
- dispatch 后用 `ospec execute launch [changes/active/<change>] [--task task-id] [--target codex|gpt|claude|gemini|opencode|cursor|copilot] [--dry-run] [--json]` 写入启动计划；`runtimeAdapter` 只接受当前、target 匹配的模型原生 subagent capability，并给出 native primitive

@@ -152,4 +152,5 @@ - 执行 `runtimeAdapter.selected.nativeSubagent`，只并行派发安全 batch。capability 缺失或过期时必须阻断并刷新当前模型会话，不得启动 agent CLI 或退回 controller context

- reviewer 同时写人类可读 Markdown 和相邻的 `*.findings.json`，其中包含稳定 ID、严重度、类别、问题说明、文件/行证据、需求引用和修复范围。旧 Markdown 在 repair 前会生成兼容 sidecar。
- 同一根因逐步缩小时保持 finding ID 稳定。超过收敛阈值后，OSpec 只有在结构化 finding 指纹和上一轮授权 repair scope 内的代码快照同时变化时才继续该 ID；不得新造 ID 或只改证据措辞来强行触发 repair。
- 对每个声明的 `documentation_updates` 路径，dispatch 与 complete 记录规范化内容 hash。新流程中文件存在但没有有效内容变化时，文档门禁失败；没有历史基线的旧流程标记为无法验证。归档索引会从已完成功能直接链接本次更新的长期项目文档。
- 每次成功 finalize/archive 都会为归档的 change 或 goal 生成一份本地化的 `docs/project/changes/<归档路径>.md`，并验证两个索引都链接它。移动 active change 前，归档预检会拒绝覆盖该路径上的人工文档，并验证托管输出目录可写。这份通用 change 记录不能代替必须维护的架构、API、模块或运行文档。
- 最终 review 为 `NEEDS_CHANGES` 时，解决 required decisions 后用 `ospec execute repair` 把全部 findings 合成一个 repair task，再各运行一次 covering verification、task review 和 final re-review。
+3
-3
assets/for-ai/zh-CN/execution-protocol.md

@@ -43,3 +43,3 @@ ---

- specialist 文档审查必须收敛。先读取上轮 findings sidecar 与解决证据，再完整审查当前文档；默认轮次和时间值是收敛阈值，新的结构化 finding-ID 集合可以自动继续，重复或循环集合会停止。缓存/待处理复用和同一 dispatch 恢复不计轮次，`--force` 不能绕过 Loop 总期限、token、STOP、no-progress、context 或 executor provenance 门禁。严格模式保留精确用户授权的额外轮次窗口。
- review repair 必须收敛。共享文件的下游任务要继承传递上游的回归义务；默认两轮是收敛阈值：结构化 finding ID 变化时自动继续，同一组 ID 重复时在下一次 repair 前停止。final review 为 `BLOCKED` 时必须停下解决 blocker，不得进入 grouped repair。不得通过提高上限来绕过未变化的 findings。
- review repair 必须收敛。共享文件的下游任务要继承传递上游的回归义务；默认两轮是收敛阈值。结构化 finding ID 变化时自动继续；同一 ID 只有在结构化 finding 指纹与上一轮授权 repair scope 内的代码快照同时变化时也可继续。只改措辞、只改代码、精确重复或循环都要停止。final review 为 `BLOCKED` 时必须停下解决 blocker，不得进入 grouped repair。不得通过提高上限来绕过未变化的证据。
- 所有 harness 的 native child 等待都必须有界。Codex/GPT 的 `wait_agent`、Claude Task 轮询以及其它原生等待必须在 60 秒内返回；60 秒只限制一次 controller poll，不是 child 的执行上限。每个 live child 都要在 `heartbeatDueAt` 前续租，完成后用 action 给出的 `loop finalize` 原子提交证据和结果，并在每轮 poll 后重新 tick。child 可跨多个 poll 运行到 action 的绝对期限，证据完成后还有有界的结果宽限期。capacity 未知时 implementation 批次最多两个，但不降低安全 review 的并行度。

@@ -64,5 +64,5 @@ - 开始或恢复单个 active change 时，用 `ospec execute bootstrap [changes/active/<change>]` 写入带 project session brief snapshot 的 `artifacts/agents/bootstrap.json` 和 `artifacts/agents/bootstrap.md`，然后按其中的下一步安全动作继续

- 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` 后，用 `ospec execute review [changes/active/<change>] --task <task-id>` 生成一次合并 review 和范围受控的 `artifacts/agents/review-packages/*.diff`；reviewer 一次读取该 package，不重复做宽范围 Git 探索。packet、report、package 字节数和 task 耗时记录在 `artifacts/agents/execution-metrics.json`
- 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 graph 启用 `documentation_updates` 后，每个 task 都必须包含该数组（没有则为 `[]`）；声明的 docs 路径必须同时出现在同一 task 的 `target_files` 中、在归档前存在，并具有从 dispatch 到 complete 的有效内容变化证据。没有历史基线的旧流程保持兼容，但必须把证据标记为无法验证。
- 所有单任务 review 通过且 task graph 完成后，用不带 `--task` 的 `ospec execute review [changes/active/<change>]` 在 `artifacts/agents/review-dispatches/` 下生成一个合并的最终整体 code review 交接包；它产出单一 `artifacts/reviews/final-review.md`、一道决策
- 所有单任务 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

@@ -69,0 +69,0 @@ - 调试是 change 的一部分时，用 `ospec execute debug [changes/active/<change>] --phase reproduce|isolate|hypothesize|fix|verify --symptom "..." --root-cause "..." --status FIXED` 记录 `artifacts/agents/debug-evidence.json`；`CONFIRMED` 表示隔离根因，`FIXED` 表示修复已验证，`BLOCKED` 会让 verify 失败

+4
-3
assets/global-skills/codex/ospec-goal/SKILL.md

@@ -26,3 +26,3 @@ ---

- **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. The default two-round values are convergence thresholds: changed structured finding IDs continue automatically, while repeated IDs stop before another repair. A blocked final review requires blocker resolution and must not enter grouped repair. Never raise a limit to bypass unchanged findings.
- **Review repair is convergent and regression-aware.** A downstream task that shares target files inherits transitive upstream regression obligations. 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; wording-only or code-only churn, exact repeats, and cycles stop. A blocked final review requires blocker resolution and must not enter grouped repair. Never raise a limit to bypass unchanged evidence.
- **Allowlist updates are replacement or explicit CAS.** Repeated `loop configure --allow-*` calls replace the complete selected list and print a diff; they never append. For L3 derive/check/apply the exact task-graph permissions, review the diff, and pass `--approve-expansion` only for an intended expansion.

@@ -135,4 +135,5 @@ - **Stop condition is three-stage:** run the project's real tests, record evidence with `ospec execute verify --status`, then confirm with `ospec verify`.

ospec execute complete <task-id> [changes/active/<goal>] --status DONE --usage-file usage.json
ospec execute review [changes/active/<goal>] --task task-id # per-task: one combined code review (spec compliance + code quality)
ospec execute review [changes/active/<goal>] # whole-change: one combined final code review (after all task reviews approved)
ospec loop tick [changes/active/<goal>] # controller-owned task/final review with real executor provenance
ospec execute review [changes/active/<goal>] --task task-id # non-controller workflow only
ospec execute review [changes/active/<goal>] # non-controller final review only
ospec execute repair [changes/active/<goal>] # one task for the complete NEEDS_CHANGES findings list

@@ -139,0 +140,0 @@ ospec execute tdd [changes/active/<goal>] --phase red|green|refactor --command "..." --status ...

+2
-2
assets/project-conventions/ar/workflow-conventions.md

@@ -68,4 +68,4 @@ ---

- يزامن `ospec execute dispatch` و`complete` أيضا `artifacts/agents/worker-status.md`؛ وبعد تعديل task graph أو execution session أو review artifacts أو debug evidence أو verification checklist يدويا استخدم `ospec execute sync` لإعادة بناء حالة worker
- بعد اكتمال كل worker task، استخدم `ospec execute review [changes/active/<change>] --task <task-id>` لإنشاء حزمة code reviewer موحدة واحدة تغطي spec compliance وcode quality في تمريرة واحدة. يحفظ قرار task-level review داخل `artifacts/reviews/tasks/<task-id>/review.md` وتبقى المهام التابعة محجوبة حتى اعتماد تلك المراجعة الموحدة الواحدة
- بعد اعتماد كل task-level reviews واكتمال task graph، استخدم `ospec execute review [changes/active/<change>]` من دون `--task` لإنشاء حزمة code review نهائية موحدة واحدة تتضمن project session brief snapshot داخل `artifacts/agents/review-dispatches/`؛ وهي مراجعة واحدة تكتب قرار `artifacts/reviews/final-review.md` واحد
- عندما تكون الـ Goal مملوكة لـ controller Loop، استخدم `ospec loop tick [changes/active/<change>]` بعد اكتمال كل worker task لإنشاء مراجعة موحدة مرتبطة ذرياً بـ executor provenance الحقيقي. استخدم `ospec execute review ... --task <task-id>` مباشرةً فقط في workflow بلا controller. يحفظ القرار داخل `artifacts/reviews/tasks/<task-id>/review.md` وتبقى المهام التابعة محجوبة حتى اعتماده
- بعد اعتماد task-level reviews واكتمال task graph، دع `ospec loop tick` التالي ينشئ final review في controller Loop. استخدم `ospec execute review` من دون `--task` فقط خارج controller Loop
- أرسل review packet إلى fresh model-native reviewer subagent؛ لا يشغّل OSpec local reviewer CLI. بعد اكتمال reviewer سجّل matching decision وevidence

@@ -72,0 +72,0 @@ - بعد أن يحتوي 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

+2
-2
assets/project-conventions/en-US/workflow-conventions.md

@@ -68,4 +68,4 @@ ---

- `ospec execute dispatch` and `complete` also sync `artifacts/agents/worker-status.md`; use `ospec execute sync` after manual task graph, execution-session, review artifact, debug evidence, or verification checklist edits
- After each worker task completes, use `ospec execute review [changes/active/<change>] --task <task-id>` to create one combined code reviewer packet covering spec compliance and code quality in a single pass. The task-level decision lives at `artifacts/reviews/tasks/<task-id>/review.md`, and dependent tasks stay blocked until that one combined review is approved
- After all task-level reviews are approved and the task graph is complete, use `ospec execute review [changes/active/<change>]` without `--task` to create one combined final whole-change code reviewer packet with the project session brief snapshot under `artifacts/agents/review-dispatches/`; it is a single review that writes one `artifacts/reviews/final-review.md` decision
- After each worker task completes, let `ospec loop tick [changes/active/<change>]` create the combined code reviewer action when a controller Loop owns the Goal; this atomically binds the packet to real executor provenance. Use `ospec execute review ... --task <task-id>` only in a non-controller workflow. The task-level decision lives at `artifacts/reviews/tasks/<task-id>/review.md`, and dependent tasks stay blocked until that one combined review is approved
- After all task-level reviews are approved and the task graph is complete, let the controller's next `ospec loop tick` create the combined final whole-change review. Use `ospec execute review [changes/active/<change>]` without `--task` only outside a controller Loop
- Dispatch each review packet to a fresh model-native reviewer subagent; OSpec never runs a local reviewer CLI. Record the matching review decision and evidence after completion

@@ -72,0 +72,0 @@ - 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 feedback as accept, revise, clarify, or blocked before dispatching more work, and create a required user decision when feedback changes scope, direction, API, UI, risk, or accepted tradeoffs

+2
-2
assets/project-conventions/ja-JP/workflow-conventions.md

@@ -68,4 +68,4 @@ ---

- `ospec execute dispatch` と `complete` は `artifacts/agents/worker-status.md` も同期する。task graph、execution session、review artifacts、debug evidence、verification checklist を手動編集した後は `ospec execute sync` で worker 状態を再構築する
- 各 worker task 完了後、`ospec execute review [changes/active/<change>] --task <task-id>` を使い、spec compliance と code quality を一度に確認する統合 code reviewer handoff packet を 1 つ作成する。task-level review decision は `artifacts/reviews/tasks/<task-id>/review.md` に保存され、その 1 回の統合 review が承認されるまで dependent task は dispatch されない
- すべての task-level review が承認され task graph が完了した後、`--task` なしの `ospec execute review [changes/active/<change>]` で project session brief snapshot を含む 1 つの統合 final whole-change code reviewer handoff packet を `artifacts/agents/review-dispatches/` に作成する。これは単一 `artifacts/reviews/final-review.md`・1 つの decision
- controller Loop が Goal を所有する場合、各 worker task 完了後の統合 review は `ospec loop tick [changes/active/<change>]` で発行し、実際の executor provenance に原子的に関連付ける。`ospec execute review ... --task <task-id>` を直接使うのは non-controller workflow のみとする。task-level review decision は `artifacts/reviews/tasks/<task-id>/review.md` に保存され、承認まで dependent task は dispatch されない
- task graph 完了後の final review も controller Loop の次の `ospec loop tick` で発行する。`--task` なしの `ospec execute review` を直接使うのは non-controller workflow のみとする
- review packet は fresh model-native reviewer subagent に dispatch する。OSpec は local reviewer CLI を実行しない。reviewer 完了後に matching decision と evidence を記録する

@@ -72,0 +72,0 @@ - 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 を作成する

+2
-2
assets/project-conventions/zh-CN/workflow-conventions.md

@@ -68,4 +68,4 @@ ---

- `ospec execute dispatch` 与 `complete` 也会同步 `artifacts/agents/worker-status.md`；人工修改 task graph、execution session、review artifacts、debug evidence 或 verification checklist 后，用 `ospec execute sync` 重建 worker 状态
- 每个 worker task 完成后，用 `ospec execute review [changes/active/<change>] --task <task-id>` 生成一个合并的 code reviewer 交接包（一次同时审 spec 符合性与代码质量）。task 级 review 决策写入 `artifacts/reviews/tasks/<task-id>/review.md`，依赖任务会等这一次合并 review 通过后才可派发
- 所有 task 级 review 通过且 task graph 完成后，用不带 `--task` 的 `ospec execute review [changes/active/<change>]` 在 `artifacts/agents/review-dispatches/` 下生成一个合并的最终整体 code review 交接包；它产出单一 `artifacts/reviews/final-review.md`、一道决策
- 每个 worker task 完成后，如果 Goal 由 controller Loop 管理，用 `ospec loop tick [changes/active/<change>]` 生成合并 code reviewer action，并原子绑定真实 executor provenance；只有非 controller 流程才直接运行 `ospec execute review ... --task <task-id>`。task 级 review 决策写入 `artifacts/reviews/tasks/<task-id>/review.md`，依赖任务会等这一次合并 review 通过后才可派发
- 所有 task 级 review 通过且 task graph 完成后，controller Loop 用下一次 `ospec loop tick` 生成最终整体 review；只有非 controller 流程才直接运行不带 `--task` 的 `ospec execute review`
- review packet 必须交给新的 model-native reviewer subagent；OSpec 不运行本地 reviewer CLI。reviewer 完成后写回对应 decision 与 evidence

@@ -72,0 +72,0 @@ - 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

+1
-1
dist/cli.js

@@ -65,3 +65,3 @@ #!/usr/bin/env node

const services_1 = require("./services");
const CLI_VERSION = '1.8.9';
const CLI_VERSION = '1.8.11';
function showInitUsage() {

@@ -68,0 +68,0 @@ console.log('Usage: ospec init [root-dir] [--summary "..."] [--tech-stack node,react] [--architecture "..."] [--document-language en-US|zh-CN|ja-JP|ar]');

+79
-18
dist/commands/UpdateCommand.js

@@ -52,2 +52,5 @@ "use strict";

...refreshedFiles,
...protocolResult.verifiedFiles,
...toolingResult.verifiedFiles,
...pluginResult.verifiedFiles,
...legacyRepair.createdPaths,

@@ -145,20 +148,62 @@ ...legacyRepair.refreshedPaths,

const candidatePaths = new Set();
const normalizeCandidate = (rawPath) => {
const trimmed = rawPath.trim();
if (!trimmed)
return null;
const absolutePath = (0, path_1.resolve)(normalizedRoot, trimmed);
const relativePath = (0, path_1.relative)(normalizedRoot, absolutePath).replace(/\\/g, '/');
if (!relativePath
|| relativePath === provenanceRelativePath
|| relativePath === '.git'
|| relativePath.startsWith('.git/')
|| relativePath === '..'
|| relativePath.startsWith('../')) {
return null;
}
return relativePath;
};
for (const rawPath of input.paths) {
for (const pathPart of String(rawPath || '').split(/\s+->\s+/)) {
const trimmed = pathPart.trim();
if (!trimmed)
const relativePath = normalizeCandidate(pathPart);
if (!relativePath)
continue;
const absolutePath = (0, path_1.resolve)(normalizedRoot, trimmed);
const relativePath = (0, path_1.relative)(normalizedRoot, absolutePath).replace(/\\/g, '/');
if (!relativePath
|| relativePath === provenanceRelativePath
|| relativePath === '.git'
|| relativePath.startsWith('.git/')
|| relativePath === '..'
|| relativePath.startsWith('../')) {
continue;
}
candidatePaths.add(relativePath);
}
}
// A repeated update must not discard ownership proof for a file that
// this same CLI version already wrote and whose exact state is intact.
if (input.cliVersion && await services_1.services.fileService.exists(provenancePath)) {
try {
const previous = await services_1.services.fileService.readJSON(provenancePath);
const previousFiles = Array.isArray(previous.files) ? previous.files : [];
if (previous.version === '1.0'
&& previous.source === 'ospec update'
&& previous.ospecCliVersion === input.cliVersion) {
for (const rawRecord of previousFiles) {
const record = rawRecord && typeof rawRecord === 'object'
? rawRecord
: null;
const relativePath = normalizeCandidate(String(record?.path || ''));
if (!relativePath || (record?.kind !== 'file' && record?.kind !== 'missing'))
continue;
const absolutePath = (0, path_1.join)(normalizedRoot, ...relativePath.split('/'));
const stat = await fs_1.promises.stat(absolutePath).catch(() => null);
if (record.kind === 'missing') {
if (!stat && record.contentHash === null)
candidatePaths.add(relativePath);
continue;
}
if (!stat?.isFile() || !/^[a-f0-9]{64}$/.test(String(record.contentHash || '')))
continue;
const currentHash = (0, crypto_1.createHash)('sha256').update(await fs_1.promises.readFile(absolutePath)).digest('hex');
if (currentHash === record.contentHash)
candidatePaths.add(relativePath);
}
}
}
catch {
// Invalid prior provenance is ignored and replaced by the
// paths independently verified during this update.
}
}
const files = [];

@@ -283,2 +328,7 @@ const capture = async (relativePath) => {

skippedFiles: [...directCopyResult.skipped],
verifiedFiles: [
...directCopyResult.created,
...directCopyResult.refreshed,
...directCopyResult.skipped,
],
hookInstalledFiles: [...hookInstallResult.installed],

@@ -574,2 +624,3 @@ migratedFiles: migrationResult.migratedFiles,

const skippedFiles = [];
const verifiedFiles = [];
const enabledPlugins = [];

@@ -594,4 +645,7 @@ const packageUpdates = [];

configChanged = this.refreshExternalPluginInstalledMetadata(nextConfig.plugins.stitch, installedStitch, stitchDefaultConfig) || configChanged;
const stitchAssets = await this.getPluginRegistryService().syncProjectPluginAssets('stitch', rootDir, stitchWorkspaceRoot);
createdFiles.push(...stitchAssets);
const stitchAssets = await this.getPluginRegistryService().syncProjectPluginAssetsDetailed('stitch', rootDir, stitchWorkspaceRoot);
createdFiles.push(...stitchAssets.created);
refreshedFiles.push(...stitchAssets.refreshed);
skippedFiles.push(...stitchAssets.skipped);
verifiedFiles.push(...stitchAssets.verified);
}

@@ -617,4 +671,7 @@ else {

configChanged = this.refreshExternalPluginInstalledMetadata(nextConfig.plugins.checkpoint, installedCheckpoint, checkpointDefaultConfig) || configChanged;
const checkpointAssets = await this.getPluginRegistryService().syncProjectPluginAssets('checkpoint', rootDir, checkpointWorkspaceRoot);
createdFiles.push(...checkpointAssets);
const checkpointAssets = await this.getPluginRegistryService().syncProjectPluginAssetsDetailed('checkpoint', rootDir, checkpointWorkspaceRoot);
createdFiles.push(...checkpointAssets.created);
refreshedFiles.push(...checkpointAssets.refreshed);
skippedFiles.push(...checkpointAssets.skipped);
verifiedFiles.push(...checkpointAssets.verified);
}

@@ -648,4 +705,7 @@ else {

: `.ospec/plugins/${pluginName}`;
const externalCreatedFiles = await this.getPluginRegistryService().syncProjectPluginAssets(pluginName, rootDir, workspaceRoot);
createdFiles.push(...externalCreatedFiles);
const externalAssets = await this.getPluginRegistryService().syncProjectPluginAssetsDetailed(pluginName, rootDir, workspaceRoot);
createdFiles.push(...externalAssets.created);
refreshedFiles.push(...externalAssets.refreshed);
skippedFiles.push(...externalAssets.skipped);
verifiedFiles.push(...externalAssets.verified);
}

@@ -660,2 +720,3 @@ if (enabledPlugins.length > 0 && (hasLegacyPluginKeys || configChanged)) {

skippedFiles,
verifiedFiles: Array.from(new Set(verifiedFiles)),
enabledPlugins,

@@ -662,0 +723,0 @@ configSaved: refreshedFiles.includes('.skillrc'),

+6
-0
dist/services/PluginRegistryService.d.ts

@@ -152,2 +152,8 @@ import { FileService } from './FileService';

syncProjectPluginAssets(pluginId: string, projectPath: string, workspaceRoot: string): Promise<string[]>;
syncProjectPluginAssetsDetailed(pluginId: string, projectPath: string, workspaceRoot: string): Promise<{
created: string[];
refreshed: string[];
skipped: string[];
verified: string[];
}>;
createExternalPluginProjectConfig(packageName: string, version: string, manifest: NormalizedPluginManifest): Record<string, unknown>;

@@ -154,0 +160,0 @@ private getOfficialRegistryEntries;

+39
-12
dist/services/PluginRegistryService.js

@@ -489,7 +489,36 @@ "use strict";

async syncProjectPluginAssets(pluginId, projectPath, workspaceRoot) {
const result = await this.syncProjectPluginAssetsDetailed(pluginId, projectPath, workspaceRoot);
return [...result.created, ...result.refreshed].sort((left, right) => left.localeCompare(right));
}
async syncProjectPluginAssetsDetailed(pluginId, projectPath, workspaceRoot) {
const installed = await this.getInstalledPluginManifest(pluginId);
if (!installed) {
return [];
return { created: [], refreshed: [], skipped: [], verified: [] };
}
const createdPaths = [];
const refreshedPaths = [];
const skippedPaths = [];
const verifiedPaths = [];
const syncAsset = async (sourcePath, targetPath) => {
const relativePath = path.relative(projectPath, targetPath).replace(/\\/g, '/');
const targetExists = await this.fileService.exists(targetPath);
if (!targetExists) {
await this.fileService.copy(sourcePath, targetPath);
createdPaths.push(relativePath);
verifiedPaths.push(relativePath);
return;
}
const [sourceContent, targetContent] = await Promise.all([
fs.promises.readFile(sourcePath),
fs.promises.readFile(targetPath),
]);
if (sourceContent.equals(targetContent)) {
skippedPaths.push(relativePath);
verifiedPaths.push(relativePath);
return;
}
await this.fileService.copy(sourcePath, targetPath);
refreshedPaths.push(relativePath);
verifiedPaths.push(relativePath);
};
await this.fileService.ensureDir(path.join(projectPath, workspaceRoot));

@@ -508,7 +537,3 @@ await this.fileService.ensureDir(path.join(projectPath, workspaceRoot, 'docs'));

const targetPath = path.join(projectPath, workspaceRoot, 'docs', `plugin.${locale}${extension}`);
const created = !(await this.fileService.exists(targetPath));
await this.fileService.copy(sourcePath, targetPath);
if (created) {
createdPaths.push(path.relative(projectPath, targetPath).replace(/\\/g, '/'));
}
await syncAsset(sourcePath, targetPath);
}

@@ -532,9 +557,11 @@ for (const entry of installed.manifest.scaffold.projectFiles || []) {

const targetPath = path.join(projectPath, ...normalizedEntry.to.split('/'));
const created = !(await this.fileService.exists(targetPath));
await this.fileService.copy(sourcePath, targetPath);
if (created) {
createdPaths.push(path.relative(projectPath, targetPath).replace(/\\/g, '/'));
}
await syncAsset(sourcePath, targetPath);
}
return createdPaths.sort((left, right) => left.localeCompare(right));
const sortUnique = (values) => [...new Set(values)].sort((left, right) => left.localeCompare(right));
return {
created: sortUnique(createdPaths),
refreshed: sortUnique(refreshedPaths),
skipped: sortUnique(skippedPaths),
verified: sortUnique(verifiedPaths),
};
}

@@ -541,0 +568,0 @@ createExternalPluginProjectConfig(packageName, version, manifest) {

+1
-0
dist/services/ProjectService.d.ts

@@ -154,2 +154,3 @@ import { ActiveChangeStatusItem, ActiveChangeStatusReport, DocsStatus, ExecutionStatus, KnowledgeDocInfo, ModuleInfo, ProjectMode, ProjectStructureStatus, ProjectSummary, SkillsStatus } from '../core/types';

skippedFiles: string[];
verifiedFiles: string[];
}

@@ -156,0 +157,0 @@ export declare class ProjectService {

+1
-1
dist/utils/subcommandHelp.js

@@ -148,3 +148,3 @@ "use strict";

ospec execute sync [change-path|project-path] - sync worker status, bootstrap/state.json, and the project session brief
ospec execute review [change-path|project-path] [--task task-id] [--stage spec|quality] - create the next safe task-level or final review dispatch packet with project session context
ospec execute review [change-path|project-path] [--task task-id] [--stage spec|quality] - create a non-controller task-level or final review packet; controller Goals use ospec loop tick
ospec execute feedback [change-path|project-path] [--stage spec|quality] [--summary "..."] - write a review feedback handling plan without editing source files

@@ -151,0 +151,0 @@ ospec execute repair [change-path|project-path] - convert all NEEDS_CHANGES final-review findings into one grouped repair task and dispatch

+1
-1
package.json
{
"name": "@clawplays/ospec-cli",
"version": "1.8.9",
"version": "1.8.11",
"description": "Official OSpec CLI package for spec-driven development (SDD) and document-driven development in AI coding agent and CLI workflows.",

@@ -5,0 +5,0 @@ "main": "dist/index.js",

+4
-2
README.md

@@ -144,3 +144,3 @@ <h1><a href="https://ospec.ai/" target="_blank" rel="noopener noreferrer">OSpec.ai</a></h1>

ospec execute complete <task-id> changes/active/<goal-name> --status DONE --summary "..."
ospec execute review changes/active/<goal-name> --task <task-id>
ospec loop tick changes/active/<goal-name> # issues task/final reviews with executor provenance
ospec execute verify changes/active/<goal-name> --command "npm test" --status PASSED --exit-code 0

@@ -151,2 +151,4 @@ ```

For a controller-owned Goal, task and final reviews are always issued by `ospec loop tick` so the dispatch is atomically bound to the real reviewer executor. Use `ospec execute review` directly only in a non-controller workflow.
### 3. Archive After Acceptance

@@ -216,3 +218,3 @@

To see progress, child executor ids, heartbeat due times, leases, review rounds, token sources, and concurrency/guard reasons, run `ospec loop status --brief` or `--json`. Use `ospec loop configure` for concurrency, budgets, action runtime limits, and evidence-result grace; allowlist flags replace the complete selected list and print a diff. For L3, prefer `ospec loop allowlist derive/check/apply --from-task-graph`, whose CAS-bound apply requires explicit approval for permission expansion. IDE controllers persist child ownership with `ospec loop heartbeat` and atomically commit successful evidence plus executor outcome with `ospec loop finalize`; legacy `ospec loop result` remains supported. After a confirmed session/child loss, `ospec loop recover --force` expires only unfinished items so they can be requeued without duplicating completed siblings. Task-review and grouped final-review repair use two rounds as convergence thresholds by default: changed structured finding IDs continue automatically, while repeated IDs stop before another ineffective repair. Use `--continue-while-progressing false` for the earlier strict lifetime ceilings. Durable worker blockers are not redispatched, technical executor failures remain retryable, and independent ready tasks run first. The 1.8.9 contract is documented in [docs/goal-1.8.9-interface.md](docs/goal-1.8.9-interface.md); the 1.8.6 runtime and 1.8.5 bounded native wait contracts remain in their versioned interface documents. Advanced loop and triage commands are documented in [docs/loop-engineering.md](docs/loop-engineering.md).
To see progress, child executor ids, heartbeat due times, leases, review rounds, token sources, and concurrency/guard reasons, run `ospec loop status --brief` or `--json`. Use `ospec loop configure` for concurrency, budgets, action runtime limits, and evidence-result grace; allowlist flags replace the complete selected list and print a diff. For L3, prefer `ospec loop allowlist derive/check/apply --from-task-graph`, whose CAS-bound apply requires explicit approval for permission expansion. IDE controllers persist child ownership with `ospec loop heartbeat` and atomically commit successful evidence plus executor outcome with `ospec loop finalize`; legacy `ospec loop result` remains supported. After a confirmed session/child loss, `ospec loop recover --force` expires only unfinished items so they can be requeued without duplicating completed siblings. Task-review and grouped final-review repair use two rounds as convergence thresholds by default. Changed structured finding IDs continue automatically. From 1.8.11, a stable ID also continues when both its structured finding fingerprint and its authorized repair-scope code snapshot changed; wording-only or code-only churn still stops before another ineffective repair. Use `--continue-while-progressing false` for the earlier strict lifetime ceilings. Durable worker blockers are not redispatched, technical executor failures remain retryable, and independent ready tasks run first. The 1.8.11 refinement contract is documented in [docs/goal-1.8.11-interface.md](docs/goal-1.8.11-interface.md); older runtime contracts remain in their versioned interface documents. Advanced loop and triage commands are documented in [docs/loop-engineering.md](docs/loop-engineering.md).

@@ -219,0 +221,0 @@ Internally, OSpec keeps implementation and independent review separate, bounds specialist document review by round/time/no-progress guards, preserves immutable convergence history, feeds blocked work and review findings into transactional retry or grouped repair, and requires current test evidence before the goal is considered complete.

dist/commands/ExecuteCommand.js

Sorry, the diff of this file is too big to display

dist/services/LoopService.js

Sorry, the diff of this file is too big to display

dist/services/ProjectService.js

Sorry, the diff of this file is too big to display

dist/services/TaskGraphExecutionService.d.ts

Sorry, the diff of this file is too big to display

dist/services/TaskGraphExecutionService.js

Sorry, the diff of this file is too big to display

dist/services/templates/ProjectTemplateBuilder.js

Sorry, the diff of this file is too big to display