@clawplays/ospec-cli
Advanced tools
@@ -42,3 +42,3 @@ --- | ||
| - عند نقل change بين agents أو tools أو worktrees أو shells أو operators بشريين، استخدم `ospec execute handoff [changes/active/<change>] [--target codex|gpt|claude|gemini|opencode|cursor|copilot|shell|generic]` لكتابة `artifacts/agents/handoff.json` و`artifacts/agents/handoff.md`؛ يسجل هذا الأمر project session brief snapshot وtool mapping وقواعد السلامة فقط ولا يشغّل workers أو يعدّل source files | ||
| - قبل اشتقاق implementation tasks أو dispatch لها، استخدم `ospec execute doc-review [changes/active/<change>] [--stage design|plan]`. في specialist mode نفّذ packet عبر `runtimeAdapter` مستقل، ثم claim للـ executor id الحقيقي، وانتظر Markdown وstructured findings قبل complete؛ يجب التحقق من design review قبل dispatch لمراجعة implementation plan. يفتح تصريح المستخدم المطابق لجولة إضافية نافذة dispatch واحدة محدودة من `selectedAt`، وبعد انتهائها يلزم تصريح جديد ولا يمكن تجاوز حواجز Loop الأخرى | ||
| - قبل اشتقاق implementation tasks أو dispatch لها، استخدم `ospec execute doc-review [changes/active/<change>] [--stage design|plan]`. في specialist mode نفّذ packet عبر `runtimeAdapter` مستقل، ثم claim للـ executor id الحقيقي، وانتظر Markdown وstructured findings قبل complete؛ يجب التحقق من design review قبل dispatch لمراجعة implementation plan. يتجاوز continuous mode العتبات الافتراضية فقط لمجموعة structured finding-ID جديدة، ويتوقف عند findings المتكررة أو الدورية؛ يحتفظ strict mode بنافذة extra round التي يصرح بها المستخدم بدقة | ||
| - عندما تحتاج إلى عرض controller للمهام ready وblocked وrunning وcompleted والمرشحات التالية الآمنة، استخدم `ospec execute status [changes/active/<change>]` أو `ospec execute next [changes/active/<change>]` | ||
@@ -45,0 +45,0 @@ - Use `ospec execute route [changes/active/<change>]` to write `artifacts/agents/workflow-route.json` and `artifacts/agents/workflow-route.md` with the next recommended OSpec command; this records workflow routing artifacts only and does not edit source files. |
@@ -40,4 +40,4 @@ --- | ||
| - تستخدم L3 allowlist الاستبدال الآمن. فضّل `ospec loop allowlist derive/check/apply --from-task-graph`، وراجع الفرق المرتبط بـ CAS، ووافق صراحة فقط على توسيع الصلاحيات المقصود. لا تفترض أن أوامر `loop configure --allow-*` المتكررة تضيف القيم. | ||
| - مراجعة المستندات المتخصصة محدودة بالجولات والوقت. اقرأ findings sidecar السابق وأدلة الحل أولا، ثم راجع المستند الحالي كاملا. لا تستهلك cache/pending reuse أو استعادة dispatch نفسه جولة، ولا يتجاوز `--force` الحواجز. عندما يصرح المستخدم بجولة إضافية مطابقة، تفتح نافذة dispatch واحدة محدودة من وقت `selectedAt` حتى لو انتهى عمر المرحلة الأساسي؛ يستهلك التصريح مرة واحدة ولا يتجاوز حواجز Loop lifetime أو token أو STOP أو no-progress أو context أو executor provenance. | ||
| - يجب أن تتقارب عمليات review repair. ترث task downstream التي تعدل ملفات مشتركة التزامات regression من upstream المتعدية، وتقتصر كل من task-review repair وgrouped final-review repair على جولتين افتراضيا. عندما تكون final review بحالة `BLOCKED` يجب التوقف لحل blocker وعدم بدء grouped repair. لا ترفع `--max-task-repair-rounds` أو `--max-final-repair-rounds` قبل عرض findings غير المحلولة والحصول على تفويض صريح من المستخدم. | ||
| - يجب أن تتقارب مراجعة المستندات المتخصصة. اقرأ 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 غير المتغيرة. | ||
| - يجب أن يكون انتظار 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 الآمن. | ||
@@ -44,0 +44,0 @@ - عند بدء أو استئناف active change واحد، استخدم `ospec execute bootstrap [changes/active/<change>]` لكتابة `artifacts/agents/bootstrap.json` و`artifacts/agents/bootstrap.md` مع project session brief snapshot، ثم اتبع الإجراء الآمن التالي المسجل فيه |
@@ -43,3 +43,3 @@ --- | ||
| - Use `ospec execute handoff [changes/active/<change>] [--target codex|gpt|claude|gemini|opencode|cursor|copilot|shell|generic]` when moving a change between agents, tools, worktrees, shells, or human operators; it writes `artifacts/agents/handoff.json` and `artifacts/agents/handoff.md` with the project session brief snapshot, target tool mapping, and safety rules without launching workers or editing source files | ||
| - Before deriving or dispatching implementation tasks, use `ospec execute doc-review [changes/active/<change>] [--stage design|plan]`. For specialist mode, execute the packet through its independent `runtimeAdapter`, immediately claim the real executor id, wait for Markdown and structured findings, then complete that executor; design review must validate before implementation plan review. An exact user-approved extra round has one bounded dispatch window from `selectedAt`; expiry requires fresh authorization and never permits bypassing other Loop guards. | ||
| - Before deriving or dispatching implementation tasks, use `ospec execute doc-review [changes/active/<change>] [--stage design|plan]`. For specialist mode, execute the packet through its independent `runtimeAdapter`, immediately claim the real executor id, wait for Markdown and structured findings, then complete that executor; design review must validate before implementation plan review. Continuous mode advances beyond the default thresholds only for a new structured finding-ID set and stops repeated or cycling findings; strict mode retains the exact user-authorized extra-round window. | ||
| - Use `ospec execute status [changes/active/<change>]` or `ospec execute next [changes/active/<change>]` when you need a controller view of ready, blocked, running, completed, and safe next task candidates | ||
@@ -46,0 +46,0 @@ - Use `ospec execute route [changes/active/<change>]` to write `artifacts/agents/workflow-route.json` and `artifacts/agents/workflow-route.md` with the next recommended OSpec command; this records workflow routing artifacts only and does not edit source files. |
@@ -42,4 +42,4 @@ --- | ||
| - L3 allowlists use secure replacement semantics. Prefer `ospec loop allowlist derive/check/apply --from-task-graph`; review the CAS-bound diff and explicitly approve intended expansions. Never assume repeated `loop configure --allow-*` calls append. | ||
| - Specialist document review is bounded. Consume the prior findings sidecar and resolution evidence, then review the complete current document. Cache/pending reuse and recovery of the same dispatch do not consume a round; `--force` never bypasses review guards. An exact user-authorized extra round receives one dispatch window from the decision's `selectedAt` time even when the base stage lifetime is exhausted; the grant is consumed once and does not bypass Loop lifetime, token, STOP, no-progress, context, or executor-provenance guards. | ||
| - Review repair is convergent. A downstream task that shares files inherits transitive upstream regression obligations. Automatic task-review repair and grouped final-review repair each default to two rounds. A blocked final review stops for blocker resolution; it never enters grouped repair. Never raise `--max-task-repair-rounds` or `--max-final-repair-rounds` without explicit user authorization after showing the unresolved findings. | ||
| - 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. | ||
| - 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. | ||
@@ -46,0 +46,0 @@ - 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 |
@@ -42,3 +42,3 @@ --- | ||
| - change を agent、tool、worktree、shell、human operator の間で引き渡すときは、`ospec execute handoff [changes/active/<change>] [--target codex|gpt|claude|gemini|opencode|cursor|copilot|shell|generic]` で `artifacts/agents/handoff.json` と `artifacts/agents/handoff.md` を書く。このコマンドは project session brief snapshot、target tool mapping、safety rules のみを記録し、worker 起動や source file 編集は行わない | ||
| - implementation tasks を導出または dispatch する前に、`ospec execute doc-review [changes/active/<change>] [--stage design|plan]` を使う。specialist mode は independent `runtimeAdapter` で実行し、実 executor id を直ちに claim、Markdown と structured findings の後に complete する。design review の検証後に implementation plan review を dispatch する。ユーザーが exact extra round を承認すると `selectedAt` から 1 回の bounded dispatch window が開き、期限切れ後は再承認が必要で、他の Loop guard は迂回できない | ||
| - implementation tasks を導出または dispatch する前に、`ospec execute doc-review [changes/active/<change>] [--stage design|plan]` を使う。specialist mode は independent `runtimeAdapter` で実行し、実 executor id を直ちに claim、Markdown と structured findings の後に complete する。design review の検証後に implementation plan review を dispatch する。continuous mode は新しい structured finding-ID set に限って既定しきい値を超えて続行し、反復または循環する findings は停止する。strict mode は exact user-authorized extra-round window を維持する | ||
| - ready、blocked、running、completed と安全な次 task 候補を確認する必要がある場合は、`ospec execute status [changes/active/<change>]` または `ospec execute next [changes/active/<change>]` を使って controller view を確認する | ||
@@ -45,0 +45,0 @@ - Use `ospec execute route [changes/active/<change>]` to write `artifacts/agents/workflow-route.json` and `artifacts/agents/workflow-route.md` with the next recommended OSpec command; this records workflow routing artifacts only and does not edit source files. |
@@ -40,4 +40,4 @@ --- | ||
| - L3 allowlist は安全な置換であり、暗黙の追加ではない。`ospec loop allowlist derive/check/apply --from-task-graph` を優先し、CAS に結び付いた差分を確認して、意図した権限拡張だけを明示的に承認する。 | ||
| - specialist document review には round/time guard がある。前回の findings sidecar と resolution evidence を先に確認し、その後 current document 全体を review する。cache/pending reuse と同じ dispatch の recovery は round を消費せず、`--force` は guard を迂回しない。ユーザーが exact extra round を承認すると、base stage lifetime が尽きていても decision の `selectedAt` から 1 回の bounded dispatch window が開く。この grant は 1 回だけ消費され、Loop lifetime、token、STOP、no-progress、context、executor provenance の guard は迂回しない。 | ||
| - review repair は収束させる。共有ファイルを変更する downstream task は推移的 upstream の regression obligation を継承し、task review と grouped final review の自動 repair はそれぞれ既定で 2 round までとする。final review が `BLOCKED` の場合は blocker の解決まで停止し、grouped repair に進めない。未解決 findings を示してユーザーの明示的承認を得るまで `--max-task-repair-rounds` または `--max-final-repair-rounds` を引き上げない。 | ||
| - 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 を回避するために上限を引き上げてはならない。 | ||
| - すべての 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 並列性は維持する。 | ||
@@ -44,0 +44,0 @@ - one active change を開始または再開するときは、`ospec execute bootstrap [changes/active/<change>]` で project session brief snapshot を含む `artifacts/agents/bootstrap.json` と `artifacts/agents/bootstrap.md` を書き、そこにある次の安全な action に従う |
@@ -43,3 +43,3 @@ --- | ||
| - change 需要在 agent、工具、worktree、shell 或人工操作者之间交接时,用 `ospec execute handoff [changes/active/<change>] [--target codex|gpt|claude|gemini|opencode|cursor|copilot|shell|generic]` 写入 `artifacts/agents/handoff.json` 和 `artifacts/agents/handoff.md`;它只记录 project session brief snapshot、目标工具映射和安全规则,不会启动 worker 或编辑源码 | ||
| - 推导或派发实现任务前,用 `ospec execute doc-review [changes/active/<change>] [--stage design|plan]` 生成文档 reviewer 交接包。specialist 模式按独立 `runtimeAdapter` 执行,立即 claim 真实 executor id,等待 Markdown 和结构化 findings 后 complete;design review 验证通过后才能派发 implementation plan review。用户精确授权的额外一轮只从 `selectedAt` 起获得一次有限派发窗口;过期后必须重新授权,且不能绕过其它 Loop 门禁 | ||
| - 推导或派发实现任务前,用 `ospec execute doc-review [changes/active/<change>] [--stage design|plan]` 生成文档 reviewer 交接包。specialist 模式按独立 `runtimeAdapter` 执行,立即 claim 真实 executor id,等待 Markdown 和结构化 findings 后 complete;design review 验证通过后才能派发 implementation plan review。连续模式只有遇到新的结构化 finding-ID 集合才会超过默认阈值继续,重复或循环 findings 会停止;严格模式保留精确用户授权的额外轮次窗口 | ||
| - 需要查看 ready、blocked、running、completed 和下一批安全任务时,用 `ospec execute status [changes/active/<change>]` 或 `ospec execute next [changes/active/<change>]` 查看 controller 视图 | ||
@@ -46,0 +46,0 @@ - 需要把下一条 OSpec 命令持久化给人或 AI 接手时,用 `ospec execute route [changes/active/<change>]` 写入 `artifacts/agents/workflow-route.json` 和 `artifacts/agents/workflow-route.md`;该命令只记录 workflow routing artifacts,不会编辑源码。 |
@@ -42,4 +42,4 @@ --- | ||
| - L3 白名单采用安全替换语义。优先使用 `ospec loop allowlist derive/check/apply --from-task-graph`,检查 CAS 绑定的差异,并仅对预期的权限扩大显式确认。不要假设多次 `loop configure --allow-*` 会累加。 | ||
| - specialist 文档审查有轮次和时间边界。先读取上轮 findings sidecar 与解决证据,再完整审查当前文档;缓存/待处理复用和同一 dispatch 恢复不计轮次,`--force` 不能绕过审查 guard。用户对精确额外轮次授权后,即使基础阶段寿命已经耗尽,也从 decision 的 `selectedAt` 起获得一次有限派发窗口;授权只消费一次,且不绕过 Loop 总期限、token、STOP、no-progress、context 或 executor provenance 门禁。 | ||
| - review repair 必须收敛。共享文件的下游任务要继承传递上游的回归义务;每个 task 的自动 review-repair 和 grouped final-review repair 都默认最多两轮。final review 为 `BLOCKED` 时必须停下解决 blocker,不得进入 grouped repair。展示未解决 findings 并获得用户明确授权前,不得提高 `--max-task-repair-rounds` 或 `--max-final-repair-rounds`。 | ||
| - 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。 | ||
| - 所有 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 的并行度。 | ||
@@ -46,0 +46,0 @@ - 开始或恢复单个 active change 时,用 `ospec execute bootstrap [changes/active/<change>]` 写入带 project session brief snapshot 的 `artifacts/agents/bootstrap.json` 和 `artifacts/agents/bootstrap.md`,然后按其中的下一步安全动作继续 |
@@ -25,4 +25,4 @@ --- | ||
| - **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 bounded and convergent.** Specialist design/plan review defaults to two completed rounds and 30 minutes per stage. Cache/pending reuse, heartbeat, lease recovery, and deterministic preflight do not consume rounds. Never use `--force` to bypass a guard; one extra round requires an existing required user decision created with `--document-review-stage`, `--review-context-hash`, `--review-round`, and `--review-approval-option`, then that exact approval option must be selected by the user. 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 bounded and regression-aware.** A downstream task that shares target files inherits transitive upstream regression obligations. Automatic task-review repair and grouped final-review repair each default to two rounds. A blocked final review requires blocker resolution and must not enter grouped repair. Show unresolved findings and obtain explicit user authorization before raising `--max-task-repair-rounds` or `--max-final-repair-rounds`; never raise either as an autonomous retry. | ||
| - **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. | ||
| - **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. | ||
@@ -104,3 +104,3 @@ - **Stop condition is three-stage:** run the project's real tests, record evidence with `ospec execute verify --status`, then confirm with `ospec verify`. | ||
| ospec loop level [changes/active/<goal>] <L1|L2|L3> | ||
| ospec loop configure [changes/active/<goal>] --execution-model controller --max-parallel N --max-parallel-reason "..." --max-task-repair-rounds N --max-final-repair-rounds N --fresh-context true | ||
| ospec loop configure [changes/active/<goal>] --execution-model controller --max-parallel N --max-parallel-reason "..." --max-task-repair-rounds N --max-final-repair-rounds N --continue-while-progressing true --fresh-context true | ||
| ospec loop configure [changes/active/<goal>] --max-iterations N --budget-tokens N --budget-minutes N --expires-at <ISO-8601> | ||
@@ -107,0 +107,0 @@ ospec loop configure [changes/active/<goal>] --allow-path <path> --allow-command <prefix> --test-command <command> |
+1
-1
@@ -65,3 +65,3 @@ #!/usr/bin/env node | ||
| const services_1 = require("./services"); | ||
| const CLI_VERSION = '1.8.8'; | ||
| const CLI_VERSION = '1.8.9'; | ||
| 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]'); |
@@ -237,3 +237,3 @@ "use strict"; | ||
| const summary = reviewGovernance.stages[stage]; | ||
| return `${stage}=${summary.completedRounds}/${summary.guardLimits.maxCompletedRounds}${summary.activeRound ? `+active:${summary.activeRound}` : ''}`; | ||
| return `${stage}=${summary.completedRounds}/${summary.continueWhileProgressing ? 'progress' : summary.guardLimits.maxCompletedRounds}${summary.activeRound ? `+active:${summary.activeRound}` : ''}`; | ||
| }).join(' '); | ||
@@ -252,3 +252,3 @@ console.log(`Loop ${state.status}: level=${config.level} step=${state.currentStep} iteration=${state.iteration} parallel=${config.efficiency.maxParallel} reason=${config.efficiency.maxParallelReason || 'not-recorded'} emitted=${batch?.effectiveEmitted ?? 0}/${batch?.graphSafeCandidates ?? 0} deferred=${batch?.deferredReasons?.join(',') || 'none'} reviews=${review} pending=${pending?.items?.length || 0} heartbeat-due=${nextHeartbeat || 'none'}`); | ||
| console.log(`Concurrency: ${config.efficiency.maxParallel} reason=${config.efficiency.maxParallelReason || 'not recorded'} fresh-context=${config.efficiency.freshContext ? 'yes' : 'no'}`); | ||
| console.log(`Guards: no-progress=${config.efficiency.noProgressLimit} review-every=${config.efficiency.comprehensionReviewEvery}`); | ||
| console.log(`Guards: no-progress=${config.efficiency.noProgressLimit} review-every=${config.efficiency.comprehensionReviewEvery} continue-while-progressing=${config.efficiency.continueWhileProgressing ? 'yes' : 'no'}`); | ||
| console.log(`Budgets: iterations=${config.stopConditions.maxIterations ?? 'unbounded'} tokens=${config.stopConditions.budgetTokens ?? 'unbounded'} minutes=${config.stopConditions.budgetMinutes ?? 'unbounded'} expires=${config.stopConditions.expiresAt || 'never'}`); | ||
@@ -271,3 +271,3 @@ console.log(`Status: ${state.status}`); | ||
| const review = reviewGovernance.stages[stage]; | ||
| console.log(`Review ${stage}: rounds=${review.completedRounds}/${review.guardLimits.maxCompletedRounds} active=${review.activeRound ?? 'none'} minutes-left=${review.guardRemaining.minutes} tokens-left=${review.guardRemaining.tokens ?? 'unbounded'} cache-hits=${review.cacheHits} no-progress=${review.noProgressCount}/${review.guardLimits.noProgressLimit} heartbeat-due=${review.currentDispatch?.heartbeatDueAt || 'none'} override-round=${review.overrideDispatchWindow?.round ?? 'none'} override-deadline=${review.overrideDispatchWindow?.deadline || 'none'} override-expired=${review.overrideDispatchWindow?.expired ?? 'none'}`); | ||
| console.log(`Review ${stage}: rounds=${review.completedRounds}/${review.continueWhileProgressing ? 'continue-while-progressing' : review.guardLimits.maxCompletedRounds} active=${review.activeRound ?? 'none'} minutes-left=${review.guardRemaining.minutes ?? 'unbounded'} tokens-left=${review.guardRemaining.tokens ?? 'unbounded'} cache-hits=${review.cacheHits} no-progress=${review.noProgressCount}/${review.guardLimits.noProgressLimit} heartbeat-due=${review.currentDispatch?.heartbeatDueAt || 'none'} override-round=${review.overrideDispatchWindow?.round ?? 'none'} override-deadline=${review.overrideDispatchWindow?.deadline || 'none'} override-expired=${review.overrideDispatchWindow?.expired ?? 'none'}`); | ||
| } | ||
@@ -441,2 +441,9 @@ if (state.lastFeedback) | ||
| options.maxFinalRepairRounds = nullableNumber('--max-final-repair-rounds') ?? undefined; | ||
| const continueWhileProgressing = scalar('--continue-while-progressing'); | ||
| if (continueWhileProgressing !== undefined) { | ||
| if (continueWhileProgressing !== 'true' && continueWhileProgressing !== 'false') { | ||
| throw new Error('--continue-while-progressing must be true or false.'); | ||
| } | ||
| options.continueWhileProgressing = continueWhileProgressing === 'true'; | ||
| } | ||
| const reviewEvery = scalar('--review-every'); | ||
@@ -471,3 +478,3 @@ if (reviewEvery !== undefined) { | ||
| const config = await services_1.services.loopService.configure(changePath, options); | ||
| this.success(`Loop configured: target=${config.target}, model=${config.executionModel}, parallel=${config.efficiency.maxParallel}, taskRepairRounds=${config.efficiency.maxTaskRepairRounds}, finalRepairRounds=${config.efficiency.maxFinalRepairRounds}, interval=${config.schedule.interval}.`); | ||
| this.success(`Loop configured: target=${config.target}, model=${config.executionModel}, parallel=${config.efficiency.maxParallel}, taskRepairRounds=${config.efficiency.maxTaskRepairRounds}, finalRepairRounds=${config.efficiency.maxFinalRepairRounds}, continueWhileProgressing=${config.efficiency.continueWhileProgressing}, interval=${config.schedule.interval}.`); | ||
| if (replacesPaths || replacesCommands) { | ||
@@ -474,0 +481,0 @@ this.warn(`Allowlist replacement applied: paths=${replacesPaths ? 'replaced' : 'unchanged'}, commands=${replacesCommands ? 'replaced' : 'unchanged'}. Repeated configure flags replace the complete selected list; they do not append.`); |
@@ -76,2 +76,3 @@ import { FileService } from './FileService'; | ||
| maxFinalRepairRounds: number; | ||
| continueWhileProgressing: boolean; | ||
| comprehensionReviewEvery: number; | ||
@@ -281,2 +282,3 @@ freshContext: boolean; | ||
| maxFinalRepairRounds?: number; | ||
| continueWhileProgressing?: boolean; | ||
| comprehensionReviewEvery?: number; | ||
@@ -283,0 +285,0 @@ freshContext?: boolean; |
+1
-1
| { | ||
| "name": "@clawplays/ospec-cli", | ||
| "version": "1.8.8", | ||
| "version": "1.8.9", | ||
| "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", |
+1
-1
@@ -214,3 +214,3 @@ <h1><a href="https://ospec.ai/" target="_blank" rel="noopener noreferrer">OSpec.ai</a></h1> | ||
| 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 each default to two automatic rounds, configurable with `--max-task-repair-rounds` and `--max-final-repair-rounds`; a blocked final review stops for blocker resolution rather than dispatching an invalid repair wave. Dependent downstream reviews inherit shared-file regression obligations instead of repeatedly invalidating approved upstream reviews. The 1.8.6 runtime, finalize, directory snapshot, approval-cache, and scheduling changes are documented in [docs/goal-1.8.6-interface.md](docs/goal-1.8.6-interface.md); the 1.8.5 bounded native wait contract remains in [docs/goal-1.8.5-interface.md](docs/goal-1.8.5-interface.md). 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, 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). | ||
@@ -217,0 +217,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. |
Sorry, the diff of this file is too big to display
Sorry, the diff of this file is too big to display
Sorry, the diff of this file is too big to display
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
3259586
1.12%57551
1.04%