@clawplays/ospec-cli - npm Package Compare versions

Comparing version 1.8.23 to 1.9.0

assets/for-ai/ar/ai-guide.md

@@ -25,3 +25,3 @@ ---
 
-- حافظ على `proposal.md` و`tasks.md` و`state.json` و`verification.md` و`review.md` وكل goal-only artifacts باللغة المعتمدة للمشروع، بما في ذلك `design.md` و`implementation-plan.md` و`artifacts/agents/task-graph.json` و`artifacts/agents/bootstrap.md` و`artifacts/agents/handoff.md` و`artifacts/agents/document-review-dispatches/` و`artifacts/agents/workspace-status.md` و`artifacts/agents/worktree-plan.md` و`artifacts/agents/finish-plan.md` و`artifacts/agents/launch-plan.md` و`artifacts/agents/worker-runs/` و`artifacts/agents/review-runs/` و`artifacts/agents/retries/` و`artifacts/agents/blockers/` و`artifacts/agents/decisions/` و`artifacts/agents/review-feedback-plan.md` و`artifacts/reviews/design-review.md` و`artifacts/reviews/implementation-plan-review.md` و`artifacts/reviews/final-review.md` و`artifacts/agents/worker-status.md` و`artifacts/agents/debug-evidence.json` و`artifacts/agents/tdd-evidence.json` و`artifacts/agents/verification-evidence.json`
+- حافظ على `proposal.md` و`tasks.md` و`state.json` و`verification.md` و`review.md` وكل goal-only artifacts باللغة المعتمدة للمشروع، بما في ذلك `design.md` و`implementation-plan.md` و`artifacts/agents/task-graph.json` و`artifacts/agents/bootstrap.md` و`artifacts/agents/handoff.md` و`artifacts/agents/planning-preflights/` و`artifacts/agents/workspace-status.md` و`artifacts/agents/worktree-plan.md` و`artifacts/agents/finish-plan.md` و`artifacts/agents/launch-plan.md` و`artifacts/agents/worker-runs/` و`artifacts/agents/review-runs/` و`artifacts/agents/retries/` و`artifacts/agents/blockers/` و`artifacts/agents/decisions/` و`artifacts/agents/review-feedback-plan.md` و`artifacts/reviews/design-review.md` و`artifacts/reviews/implementation-plan-review.md` و`artifacts/reviews/final-review.md` و`artifacts/agents/worker-status.md` و`artifacts/agents/debug-evidence.json` و`artifacts/agents/tdd-evidence.json` و`artifacts/agents/verification-evidence.json`
 - لا تستنتج لغة وثائق change من لغة واجهة المنتج أو locale الموقع أو من متطلب "الإنجليزية أولاً" فقط
@@ -34,3 +34,3 @@ - إذا كان البروتوكول المعتمد للمشروع بالصينية أو كانت وثائق change الحالية بالصينية بالفعل، فاستمر بالصينية ما لم تغيّر قواعد المشروع ذلك صراحةً
 - استخدم `ospec goal` / `ospec-goal` فقط عندما يختار المستخدم Goal صراحة
-- طبقة التحكم `ospec execute …` (bootstrap وdoc-review وdispatch وlaunch وreview وworktree وfinish وcollect وretry وsync) وكل artifacts الخاصة بـ goal تنتمي إلى `workflow_profile_id: goal`. وبالنسبة لـ `workflow_profile_id: change`، التزم بالتدفق السريع الكلاسيكي — لا تقرأ ولا تشغّل طبقة execute أو artifacts الخاصة بـ goal؛ حرّر `proposal.md` و`tasks.md`، ونفّذ، وسجّل `verification.md` و`review.md`، ثم أغلق بـ `ospec verify` و`ospec finalize` — ما لم يطلب المستخدم صراحةً تنفيذ agent/worker على هذا الـ change
+- طبقة التحكم `ospec execute …` (bootstrap وpreflight وdispatch وlaunch وreview وworktree وfinish وcollect وretry وsync) وكل artifacts الخاصة بـ goal تنتمي إلى `workflow_profile_id: goal`. وبالنسبة لـ `workflow_profile_id: change`، التزم بالتدفق السريع الكلاسيكي — لا تقرأ ولا تشغّل طبقة execute أو artifacts الخاصة بـ goal؛ حرّر `proposal.md` و`tasks.md`، ونفّذ، وسجّل `verification.md` و`review.md`، ثم أغلق بـ `ospec verify` و`ospec finalize` — ما لم يطلب المستخدم صراحةً تنفيذ agent/worker على هذا الـ change
 - عند تنفيذ goal بمساعدة AI، لا تطلب من المستخدم كتابة `design.md` أو `implementation-plan.md` يدوياً؛ أنشئهما أو حدّثهما من المتطلب و`proposal.md` وسياق المشروع قبل اشتقاق `artifacts/agents/task-graph.json` أو تعديل `tasks.md` أو الكود
@@ -44,3 +44,3 @@ - عند تنفيذ classic change، لا تنشئ goal-only files ما لم يطلب المستخدم ترقية العمل صراحة إلى goal
 - عند نقل 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. يتجاوز continuous mode العتبات الافتراضية فقط لمجموعة structured finding-ID جديدة، ويتوقف عند findings المتكررة أو الدورية؛ يحتفظ strict mode بنافذة extra round التي يصرح بها المستخدم بدقة
+- قبل اشتقاق task graph، شغّل `ospec execute preflight [changes/active/<change>] --stage design` ثم `--stage plan`. ينفذ الأمران deterministic inline readiness preflight ويسجلان approval artifacts قابلة للتدقيق بدون تشغيل reviewer child. اشتق أو حدّث `task-graph.json` فقط بعد نجاح المرحلتين. اجمع red test العادي وproduction implementation ودليل green/refactor في atomic task واحدة إلا إذا كان test harness مخرجا مستقلا قابلا لإعادة الاستخدام
 - عندما تحتاج إلى عرض controller للمهام ready وblocked وrunning وcompleted والمرشحات التالية الآمنة، استخدم `ospec execute status [changes/active/<change>]` أو `ospec execute next [changes/active/<change>]`
@@ -59,3 +59,3 @@ - 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.
 - نفّذ `runtimeAdapter.selected.nativeSubagent` وشغّل safe batch فقط بالتوازي. عند غياب capability أو انتهاء صلاحيتها يجب block من دون agent CLI أو fallback إلى current controller
-- `IDE-CONTROLLER-AUTO-DISPATCH`: المستوى L1 للتقارير فقط. في L2/L3 يملك IDE AI دورة tick -> تنفيذ كل `actions[]` عبر `runtimeAdapter.selected.nativeSubagent` لكل action -> تسجيل heartbeat/result evidence -> tick فوري. إذا كانت `actions[]` فارغة مع وجود `pending` فهذه مراقبة فقط ولا يعاد التوزيع
+- `IDE-CONTROLLER-AUTO-DISPATCH`: تستخدم كل Goals مسار fast quality واحدا قابلا للتنفيذ. يملك IDE AI دورة tick -> تنفيذ كل `actions[]` عبر model-native subagents -> تسجيل 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
@@ -65,3 +65,3 @@ - عندما يكون debugging جزءا من change، استخدم `ospec execute debug [changes/active/<change>] --phase reproduce|isolate|hypothesize|fix|verify --symptom "..." --root-cause "..." --status FIXED` لتسجيل root-cause وfix evidence؛ هذا الأمر يسجل evidence فقط ولا يشغّل أوامر shell
 - بعد تشغيل project checks حديثة، استخدم `ospec execute verify [changes/active/<change>] --command "..." --status PASSED --exit-code 0` لتسجيل verification evidence؛ هذا الأمر يسجل evidence فقط ولا يشغّل أوامر shell
-- `ospec execute doc-review` يسجل artifacts فقط ولا يشغّل reviewers ولا أوامر shell ولا يزامن worker status ولا يعدّل source files
+- `ospec execute preflight` يسجل deterministic inline preflight artifacts فقط ولا يشغّل reviewer child أو shell command ولا يزامن worker status ولا يعدّل source files
 - في goal لا تؤرشف عندما يحتوي `artifacts/agents/task-graph.json` على حالات مهام غير محسومة أو اعتماديات غير صالحة أو ملفات مستهدفة ناقصة أو أوامر تحقق ناقصة أو عندما لا يكون `status` العلوي `completed`
@@ -101,3 +101,3 @@ - بعد التنفيذ، أكمل المراجعة الموحدة الواحدة لكل task (`artifacts/reviews/tasks/<task-id>/review.md`)، ثم أكمل `artifacts/reviews/final-review.md` النهائية الموحدة؛ قرارات task-level أو final review غير المحسومة تمنع الأرشفة
 
-- القيمة الافتراضية لـ `.skillrc.workflow.document_review_policy` هي `always`؛ لا يستخدم `adaptive` inline preflight إلا عندما تصرح الوثيقة المستهدفة بـ `risk_level: low` (أو `none`) ولا توجد إشارات مخاطر API أو security أو migration أو data أو architecture أو external integration أو scope. يؤدي غياب سياق المخاطر أو تعذر تحليله إلى توزيع reviewer مستقل.
+- شغّل deterministic preflight للتصميم والخطة، ثم اشتق task graph، ثم نفّذ combined planning review مستقلة واحدة. يسمح بإصلاح تخطيط مجمّع واحد وfresh re-review واحدة فقط، وتبقى task review وfinal combined review وverification مطلوبة.
 - يحل worker/reviewer logical model profile حسب dispatch target الفعلي، بما في ذلك launch override. افصل requested/configured model عن provider-observed model؛ بدون provider/usage evidence يبقى observed model غير معروف.
@@ -104,0 +104,0 @@ - يتلقى command runner المسار `OSPEC_USAGE_FILE` ويجمع sidecar تلقائيا؛ ويبقى `ospec execute complete ... --usage-file usage.json` للإدخال اليدوي. تسجل metrics المصدر والحقول المرصودة وتغطية complete/partial/missing، ولا تعرض القيمة غير المبلّغ عنها كصفر مقاس.

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

@@ -31,3 +31,3 @@ ---
 - استخدم `ospec goal` / `ospec-goal` فقط عندما يختار المستخدم Goal صراحة
-- طبقة التحكم `ospec execute …` (bootstrap وdoc-review وdispatch وlaunch وreview وworktree وfinish وcollect وretry وsync) وكل artifacts الخاصة بـ goal تنتمي إلى `workflow_profile_id: goal`. وبالنسبة لـ `workflow_profile_id: change`، التزم بالتدفق السريع الكلاسيكي — لا تقرأ ولا تشغّل طبقة execute أو artifacts الخاصة بـ goal؛ حرّر `proposal.md` و`tasks.md`، ونفّذ، وسجّل `verification.md` و`review.md`، ثم أغلق بـ `ospec verify` و`ospec finalize` — ما لم يطلب المستخدم صراحةً تنفيذ agent/worker على هذا الـ change
+- طبقة التحكم `ospec execute …` (bootstrap وpreflight وdispatch وlaunch وreview وworktree وfinish وcollect وretry وsync) وكل artifacts الخاصة بـ goal تنتمي إلى `workflow_profile_id: goal`. وبالنسبة لـ `workflow_profile_id: change`، التزم بالتدفق السريع الكلاسيكي — لا تقرأ ولا تشغّل طبقة execute أو artifacts الخاصة بـ goal؛ حرّر `proposal.md` و`tasks.md`، ونفّذ، وسجّل `verification.md` و`review.md`، ثم أغلق بـ `ospec verify` و`ospec finalize` — ما لم يطلب المستخدم صراحةً تنفيذ agent/worker على هذا الـ change
 - أثناء تنفيذ goal بمساعدة AI، أنشئ `design.md` أو حدّثه بعد `proposal.md` وقبل تعديل `implementation-plan.md` أو `tasks.md` أو الكود. في classic change لا تنشئ goal-only files ما لم يطلب المستخدم الترقية إلى goal صراحة
@@ -40,4 +40,4 @@ - `Announce-Before-Act`: لا تُشغّل سير العمل بصمت. أعلن OSpec skill والمرحلة، والأمر والـ artifact، وmodel-native subagent adapter المختار، وعدد workers، وcurrent session capability، وأي بوابة تحجب التقدم
 - في goal اشتق `artifacts/agents/task-graph.json` من `implementation-plan.md`؛ ويجب أن تتضمن كل مهمة id والحالة والاعتماديات وسلامة التوازي والتعارضات والملفات المستهدفة وأوامر التحقق والنتيجة المتوقعة ودور worker. اضبط `parallelizable: true` لكل مهمة لا تتداخل `target_files` الخاصة بها مع مهمة جاهزة أخرى ولا تعتمد عليها؛ واترك `parallelizable: false` فقط عند تعارض الملفات أو وجود اعتماد حقيقي، وسجل `serial_reason` و`conflicts_with`. لا تجعل المهام متسلسلة افتراضيا، وسجل `maxParallelReason` عند تقييد graph آمن إلى worker واحد. قسّم task التي تتجاوز ستة `target_files`، أو أضف `scope_reason` واضحاً عندما يتطلب نطاق تحقق ذري واحد هذا الاتساع
-- تستخدم L3 allowlist الاستبدال الآمن. فضّل `ospec loop allowlist derive/check/apply --from-task-graph`، وراجع الفرق المرتبط بـ CAS، ووافق صراحة فقط على توسيع الصلاحيات المقصود. لا تفترض أن أوامر `loop configure --allow-*` المتكررة تضيف القيم.
-- يجب أن تتقارب مراجعة المستندات المتخصصة. اقرأ findings sidecar السابق وأدلة الحل أولا، ثم راجع المستند الحالي كاملا. قيم round/time الافتراضية هي عتبات تقارب: يمكن لمجموعة structured finding-ID جديدة أن تستمر تلقائيا، بينما تتوقف المجموعات المتكررة أو الدورية. لا تستهلك cache/pending reuse أو استعادة dispatch نفسه جولة. تظل legacy imported completion التي لا تحمل durable decision محسوبة كجولة لكنها لا تقدم convergence decision؛ بعد تغير authoritative documents دع OSpec يرسل fresh review ولا تعدل ledger أو تعيد حساب hash chain يدويا. ولا يتجاوز `--force` حواجز Loop lifetime أو token أو STOP أو no-progress أو context أو executor provenance. يحتفظ strict mode بنافذة extra round التي يصرح بها المستخدم بدقة.
+- تستخدم allowlist الاختيارية الاستبدال الآمن. عند طلب حد إضافي استخدم `ospec loop allowlist derive/check/apply --from-task-graph`، وراجع فرق CAS، ووافق صراحة على توسيع الصلاحيات المقصود.
+- تستخدم مرحلة design/plan deterministic inline preflight ثم combined planning review مستقل واحد. يسمح بمحاولة grouped planning repair واحدة وfresh re-review واحدة، وبعد فشل متكرر يتوقف المسار بثبات.
 - يجب أن تتقارب عمليات review repair. ترث task downstream التي تعدل ملفات مشتركة التزامات regression من upstream المتعدية. تمثل الجولتان الافتراضيتان عتبة تقارب. يستمر التنفيذ عندما تتغير structured finding IDs، ولا يستمر المعرف الثابت إلا عند تغير structured finding fingerprint وcode snapshot المصرح بهما معا. في continuous mode تحصل مجموعة findings المتوقفة للـ task أو final review على strategy escalation دائمة واحدة مرتبطة بالـ scope والمعرفات نفسها؛ نفذ packet إعادة تحليل root cause وfocused regression مرة واحدة، ثم توقف إذا بقيت المجموعة نفسها متوقفة. يحتفظ strict mode بالحد المضبوط. عندما تكون final review بحالة `BLOCKED` يجب التوقف لحل blocker وعدم بدء grouped repair. لا ترفع الحدود لتكرار عمل لم يتغير.
@@ -48,3 +48,3 @@ - يجب أن يكون انتظار 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 التوازي الافتراضي وهو ثلاث مهام من دون تقليل توازي review الآمن. إذا كان harness يعرف بثقة capacity حالية أكبر للـ child فيمكنه ربطها بجلسة controller النشطة ورفع `maxParallel` وفقاً لذلك؛ لا تخمّن capacity ولا تعِد استخدام قيمة قديمة.
 - عند نقل 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]` لإنشاء document reviewer packets تتضمن project session brief snapshot تحت `artifacts/agents/document-review-dispatches/` وتجهيز `artifacts/reviews/design-review.md` أو `artifacts/reviews/implementation-plan-review.md`؛ يجب اعتماد design review قبل dispatch لمراجعة implementation plan. هذا الأمر يسجل artifacts فقط ولا يشغّل reviewers ولا أوامر shell ولا يزامن worker status ولا يعدّل source files
+- قبل اشتقاق task graph، شغّل `ospec execute preflight [changes/active/<change>] --stage design` ثم `--stage plan` لإنشاء deterministic inline preflight packets وapproval artifacts تتضمن project session brief snapshot. اشتق أو حدّث task graph بعد نجاح المرحلتين فقط. لا تشغّل الأوامر reviewer child أو shell command ولا تزامن worker status ولا تعدّل source files، واجمع red test العادي وproduction implementation ودليل green/refactor في atomic task واحدة
 - قبل توزيع عمل المهام، استخدم `ospec execute status [changes/active/<change>]` أو `ospec execute next [changes/active/<change>]` لفحص حالة controller والمهام التالية الآمنة
@@ -65,3 +65,3 @@ - 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.
 - نفّذ `runtimeAdapter.selected.nativeSubagent` وشغّل safe batch فقط بالتوازي. عند غياب capability أو انتهاء صلاحيتها يجب block من دون agent CLI أو fallback إلى current controller
-- `IDE-CONTROLLER-AUTO-DISPATCH`: المستوى L1 للتقارير فقط. في L2/L3 يملك IDE AI دورة tick -> تنفيذ كل `actions[]` عبر `runtimeAdapter.selected.nativeSubagent` لكل action -> تسجيل heartbeat/result evidence -> tick فوري. إذا كانت `actions[]` فارغة مع وجود `pending` فهذه مراقبة فقط ولا يعاد التوزيع
+- `IDE-CONTROLLER-AUTO-DISPATCH`: تستخدم كل Goals مسار fast quality واحدا قابلا للتنفيذ. يملك IDE AI دورة tick -> تنفيذ كل `actions[]` عبر model-native subagents -> تسجيل 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
@@ -104,3 +104,3 @@ - في Goal مملوكة لـ controller، استخدم `ospec loop tick [changes/active/<change>]` بعد اكتمال كل worker task لإنشاء مراجعة موحدة مرتبطة بـ executor provenance الحقيقي وحزمة محدودة النطاق. استخدم `ospec execute review ... --task <task-id>` مباشرةً فقط خارج controller Loop
 
-- القيمة الافتراضية لـ `.skillrc.workflow.document_review_policy` هي `always`؛ ينفذ `adaptive` deterministic inline preflight فقط عندما تصرح الوثيقة المستهدفة بـ `risk_level: low` (أو `none`) ولا توجد risk signals. يؤدي غياب سياق المخاطر أو تعذر تحديد اللغة أو فشل التحليل إلى توزيع reviewer مستقل.
+- شغّل deterministic preflight للتصميم والخطة، ثم اشتق task graph، ثم نفّذ combined planning review مستقلة واحدة؛ يسمح بإصلاح تخطيط مجمّع واحد وfresh re-review واحدة فقط.
 - تربط `.skillrc.workflow.model_profiles` ملفات `mechanical` و`standard` و`strong_reasoning` و`review` و`final_review` المنطقية بنماذج target؛ وعند غياب الربط يستخدم harness default مع warning في packet.
@@ -107,0 +107,0 @@ - يستخدم command runner المتغير `OSPEC_USAGE_FILE` لجمع normalized usage تلقائيا، ويبقى `--usage-file` كتجاوز يدوي. يجمع `execution-metrics.json` حسب capability tier وmodel profile وworkflow stage ويعرض تغطية complete/partial/missing.

assets/for-ai/en-US/ai-guide.md

@@ -25,3 +25,3 @@ ---
 
-- Follow the project-adopted document language for `proposal.md`, `tasks.md`, `state.json`, `verification.md`, `review.md`, and any goal-only artifacts such as `design.md`, `implementation-plan.md`, `artifacts/agents/task-graph.json`, `artifacts/agents/bootstrap.md`, `artifacts/agents/handoff.md`, `artifacts/agents/document-review-dispatches/`, `artifacts/agents/workspace-status.md`, `artifacts/agents/worktree-plan.md`, `artifacts/agents/finish-plan.md`, `artifacts/agents/launch-plan.md`, `artifacts/agents/worker-runs/`, `artifacts/agents/review-runs/`, `artifacts/agents/retries/`, `artifacts/agents/blockers/`, `artifacts/agents/decisions/`, `artifacts/agents/review-feedback-plan.md`, `artifacts/reviews/design-review.md`, `artifacts/reviews/implementation-plan-review.md`, `artifacts/reviews/final-review.md`, `artifacts/agents/worker-status.md`, `artifacts/agents/debug-evidence.json`, `artifacts/agents/tdd-evidence.json`, and `artifacts/agents/verification-evidence.json`
+- Follow the project-adopted document language for `proposal.md`, `tasks.md`, `state.json`, `verification.md`, `review.md`, and any goal-only artifacts such as `design.md`, `implementation-plan.md`, `artifacts/agents/task-graph.json`, `artifacts/agents/bootstrap.md`, `artifacts/agents/handoff.md`, `artifacts/agents/planning-preflights/`, `artifacts/agents/workspace-status.md`, `artifacts/agents/worktree-plan.md`, `artifacts/agents/finish-plan.md`, `artifacts/agents/launch-plan.md`, `artifacts/agents/worker-runs/`, `artifacts/agents/review-runs/`, `artifacts/agents/retries/`, `artifacts/agents/blockers/`, `artifacts/agents/decisions/`, `artifacts/agents/review-feedback-plan.md`, `artifacts/reviews/design-review.md`, `artifacts/reviews/implementation-plan-review.md`, `artifacts/reviews/final-review.md`, `artifacts/agents/worker-status.md`, `artifacts/agents/debug-evidence.json`, `artifacts/agents/tdd-evidence.json`, and `artifacts/agents/verification-evidence.json`
 - Do not infer change-document language from product copy, default site locale, or an "English-first" business requirement alone
@@ -35,3 +35,3 @@ - If the project-adopted protocol is Chinese or the current change docs are already Chinese, keep the change docs in Chinese unless the project rules explicitly switch them to English
 - Use `ospec goal` / `ospec-goal` only when the user explicitly selects a Goal.
-- The `ospec execute …` controller layer (bootstrap, doc-review, dispatch, launch, review, worktree, finish, collect, retry, sync) and every goal-only artifact belong to `workflow_profile_id: goal`. For `workflow_profile_id: change`, keep the classic fast flow — do not read or run the execute layer or goal artifacts; edit `proposal.md` and `tasks.md`, implement, record `verification.md` and `review.md`, then close out with `ospec verify` and `ospec finalize` — unless the user explicitly asks for agent/worker execution on this change.
+- The `ospec execute …` controller layer (bootstrap, preflight, dispatch, launch, review, worktree, finish, collect, retry, sync) and every goal-only artifact belong to `workflow_profile_id: goal`. For `workflow_profile_id: change`, keep the classic fast flow — do not read or run the execute layer or goal artifacts; edit `proposal.md` and `tasks.md`, implement, record `verification.md` and `review.md`, then close out with `ospec verify` and `ospec finalize` — unless the user explicitly asks for agent/worker execution on this change.
 - In goal execution, do not ask the user to hand-write `design.md` or `implementation-plan.md`; draft or update them from the requirement, `proposal.md`, and project context before deriving `artifacts/agents/task-graph.json`, editing `tasks.md`, or editing code.
@@ -45,3 +45,3 @@ - In classic change execution, do not create goal-only files unless the user explicitly upgrades the work to a goal.
 - 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. 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.
+- Before deriving the task graph, run `ospec execute preflight [changes/active/<change>] --stage design`, then `--stage plan`. Both commands perform deterministic inline readiness preflight and record auditable approval artifacts without launching reviewer children. Derive or refresh `task-graph.json` only after both preflights pass. Keep red tests, production implementation, and green/refactor evidence in one atomic task unless the test harness is independently reusable.
 - 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
@@ -61,5 +61,5 @@ - 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.
 - For an integrated goal loop in controller mode, do not stop after initialization or ask the user to run Loop commands. Run `ospec loop run [change] --once --json`, execute every emitted action through its `runtimeAdapter.selected.nativeSubagent`, persist heartbeat/result evidence, and tick again without another user prompt; do not paste the whole goal into each worker
-- `IDE-CONTROLLER-AUTO-DISPATCH`: L1 is report-only. For L2/L3, the IDE AI owns tick -> execute all `actions[]` through each action's `runtimeAdapter.selected.nativeSubagent` -> persist heartbeat/result evidence -> immediate tick. An empty `actions[]` with `pending` is observation only and must never be relaunched
+- `IDE-CONTROLLER-AUTO-DISPATCH`: every Goal uses the same executable fast quality workflow. The IDE AI owns tick -> execute all `actions[]` through model-native subagents -> persist heartbeat/result evidence -> immediate tick. An empty `actions[]` with `pending` is observation only and must never be relaunched
 - Agent CLI execution is removed. `loop watch`, `execute orchestrate`, `launch --run --command`, and `review --run --command` fail before process launch or run-artifact creation
-- Required decisions block every loop level. L1 emits no executable action; L3 additionally requires non-empty path and command allowlists and blocks targets or verification commands outside them
+- Required decisions always block implementation. Optional configured path and command allowlists add an extra fail-closed boundary without creating another workflow level
 - Token economy (does not change any gate): pass `--brief` on `ospec execute …` and `ospec loop status`, drive each step from the brief status and emitted packet path, and read the prior findings sidecar/resolution summary before reopening full review history; do not re-read or embed the full task graph, worker status, launch plan, or goal documents every turn
@@ -70,3 +70,3 @@ - Use `ospec execute retry` to reopen corrected blocked, needs-context, or failed native work; completed tasks require explicit `--force`
 - After running fresh project checks, use `ospec execute verify [changes/active/<change>] --command "..." --status PASSED --exit-code 0` to record verification evidence; it records evidence only and does not run shell commands
-- `ospec execute doc-review` records artifacts only and does not launch reviewers or edit source files. Execute specialist reviews through `runtimeAdapter.selected.nativeSubagent` and bind the real child id with claim/heartbeat/complete commands
+- `ospec execute preflight` records deterministic inline preflight artifacts only; it does not launch reviewers, run shell commands, sync worker status, or edit source files
 - For goal execution, do not archive while `artifacts/agents/task-graph.json` has unresolved task statuses, invalid dependencies, missing target files, missing verification commands, or top-level `status` other than `completed`
@@ -122,3 +122,3 @@ - After implementation, each task's single combined review must complete, and the single final `artifacts/reviews/final-review.md` must complete; unresolved task-level or final review decisions block archive
 
-- `.skillrc.workflow.document_review_policy` defaults to `always`; `adaptive` uses deterministic inline preflight only when the target document explicitly declares `risk_level: low` (or `none`) and no API, security, migration, data, architecture, integration, or scope-risk signal exists. Missing or unparseable risk context dispatches an independent reviewer.
+- Run deterministic design and plan preflights, derive the task graph, then run one independent combined planning review. One grouped planning repair and one fresh re-review are the maximum; task review, final combined review, and verification remain required.
 - Workers and reviewers use logical model profiles resolved against the actual dispatch target, including launch overrides. Keep requested/configured model separate from provider-observed model; absent provider/usage evidence means observed model is unknown, not selected by assertion.
@@ -125,0 +125,0 @@ - Command runners receive `OSPEC_USAGE_FILE` and automatically ingest that sidecar; `ospec execute complete ... --usage-file usage.json` remains available for manual ingestion. Metrics record their source, observed fields, and complete/partial/missing coverage, so an unreported counter is not presented as a measured zero.

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

@@ -33,3 +33,3 @@ ---
 - Use `ospec goal` / `ospec-goal` only when the user explicitly selects a Goal.
-- The `ospec execute …` controller layer (bootstrap, doc-review, dispatch, launch, review, worktree, finish, collect, retry, sync) and every goal-only artifact belong to `workflow_profile_id: goal`. For `workflow_profile_id: change`, keep the classic fast flow — do not read or run the execute layer or goal artifacts; edit `proposal.md` and `tasks.md`, implement, record `verification.md` and `review.md`, then close out with `ospec verify` and `ospec finalize` — unless the user explicitly asks for agent/worker execution on this change.
+- The `ospec execute …` controller layer (bootstrap, preflight, dispatch, launch, review, worktree, finish, collect, retry, sync) and every goal-only artifact belong to `workflow_profile_id: goal`. For `workflow_profile_id: change`, keep the classic fast flow — do not read or run the execute layer or goal artifacts; edit `proposal.md` and `tasks.md`, implement, record `verification.md` and `review.md`, then close out with `ospec verify` and `ospec finalize` — unless the user explicitly asks for agent/worker execution on this change.
 - During AI-assisted goal execution, draft or update `design.md` after `proposal.md` and before editing `implementation-plan.md`, `tasks.md`, or code. Do not create goal-only files during a classic change unless the user explicitly upgrades it to a goal.
@@ -42,4 +42,4 @@ - `Announce-Before-Act`: never run the workflow silently. Announce the OSpec skill and stage, command and artifact, selected model-native subagent adapter, worker count, current session capability, and any blocking gate
 - For goals, derive `artifacts/agents/task-graph.json` from `implementation-plan.md`; each task must include id, status, dependencies, parallel safety, conflicts, target files, verification commands, expected result, and worker role. Set `parallelizable: true` for every task whose `target_files` do not overlap another ready task's and that has no dependency on it, so OSpec dispatches them as one parallel batch and the goal runs faster; only leave `parallelizable: false` when tasks share files or genuinely depend on each other, and record `serial_reason` plus `conflicts_with`. Do not default everything to `parallelizable: false`; record `maxParallelReason` when explicitly limiting a safe graph to one worker. Split tasks with more than six `target_files`, or add a concrete `scope_reason` when one atomic verification boundary requires that breadth.
-- 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 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. Legacy imported completions without a durable decision still count as rounds but provide no convergence decision; after authoritative documents change, let OSpec issue a fresh review and never edit or rehash the ledger. `--force` never bypasses Loop lifetime, token, STOP, no-progress, context, or executor-provenance guards. Strict mode retains the exact user-authorized extra-round window.
+- Optional configured allowlists use secure replacement semantics. When an extra boundary is requested, use `ospec loop allowlist derive/check/apply --from-task-graph`, review the CAS-bound diff, and explicitly approve intended expansions.
+- Design and plan use deterministic inline preflights, followed by one independent combined planning review. One grouped planning repair and one fresh re-review are allowed; a repeated failure blocks stably. `--force` never bypasses Loop lifetime, token, STOP, no-progress, context, or executor-provenance guards.
 - 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. In continuous mode, stalled task or final findings receive one durable strategy escalation for that exact scope and finding-ID set; execute its root-cause and focused-regression packet once, then stop if the same set remains stalled. Strict mode retains the configured limit. A blocked final review stops for blocker resolution; it never enters grouped repair. Do not raise a limit to repeat unchanged evidence.
@@ -50,3 +50,3 @@ - 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 uses the default implementation concurrency of three without reducing safe review parallelism. A harness that authoritatively knows a larger current child capacity may report it for the active controller session and raise `maxParallel` accordingly; never guess or reuse stale capacity.
 - 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]` to create document reviewer packets with the project session brief snapshot under `artifacts/agents/document-review-dispatches/` and review artifacts at `artifacts/reviews/design-review.md` or `artifacts/reviews/implementation-plan-review.md`; design review must be approved before implementation plan review. This command records artifacts only and does not launch reviewers, run shell commands, sync worker status, or edit source files
+- Before deriving the task graph, run `ospec execute preflight [changes/active/<change>] --stage design`, then `--stage plan`, to create deterministic inline preflight packets and approval artifacts. Both commands record artifacts only and never launch reviewer children, run shell commands, sync worker status, or edit source files. Derive or refresh the task graph only after both preflights pass; keep ordinary red tests with their production implementation and green/refactor evidence in one atomic task.
 - Use `ospec execute status [changes/active/<change>]` or `ospec execute next [changes/active/<change>]` to inspect controller state and safe next task candidates before assigning task work
@@ -66,3 +66,3 @@ - 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.
 - Execute `runtimeAdapter.selected.nativeSubagent`; parallelize only the safe batch. Missing or expired native capability blocks dispatch with no agent CLI or controller-context fallback
-- `IDE-CONTROLLER-AUTO-DISPATCH`: L1 is report-only. For L2/L3, the IDE AI owns tick -> execute all `actions[]` through each action's `runtimeAdapter.selected.nativeSubagent` -> persist heartbeat/result evidence -> immediate tick. An empty `actions[]` with `pending` is observation only and must never be relaunched
+- `IDE-CONTROLLER-AUTO-DISPATCH`: every Goal uses the same executable fast quality workflow. The IDE AI owns tick -> execute all `actions[]` through model-native subagents -> persist heartbeat/result evidence -> immediate tick. An empty `actions[]` with `pending` is observation only and must never be relaunched
 - 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
@@ -124,3 +124,3 @@ - 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`
 
-- `.skillrc.workflow.document_review_policy` defaults to `always`; `adaptive` performs deterministic inline preflight only when the target document explicitly declares `risk_level: low` (or `none`) and no risk signal is found. Missing, unsupported-language, or unparseable risk context dispatches an independent reviewer.
+- Run deterministic design and plan preflights, derive the task graph, then run one independent combined planning review. Allow at most one grouped planning repair and one fresh re-review.
 - `.skillrc.workflow.model_profiles` maps the `mechanical`, `standard`, `strong_reasoning`, `review`, and `final_review` logical profiles to target-specific models; missing mappings use the harness default and produce a packet warning.
@@ -127,0 +127,0 @@ - Command runners use `OSPEC_USAGE_FILE` for automatic normalized usage ingestion; `--usage-file` remains a manual override. `execution-metrics.json` aggregates by capability tier, model profile, and workflow stage and reports complete/partial/missing coverage.

assets/for-ai/ja-JP/ai-guide.md

@@ -25,3 +25,3 @@ ---
 
-- `proposal.md`、`tasks.md`、`state.json`、`verification.md`、`review.md` と、goal-only artifacts（`design.md`、`implementation-plan.md`、`artifacts/agents/task-graph.json`、`artifacts/agents/bootstrap.md`、`artifacts/agents/handoff.md`、`artifacts/agents/document-review-dispatches/`、`artifacts/agents/workspace-status.md`、`artifacts/agents/worktree-plan.md`、`artifacts/agents/finish-plan.md`、`artifacts/agents/launch-plan.md`、`artifacts/agents/worker-runs/`、`artifacts/agents/review-runs/`、`artifacts/agents/retries/`、`artifacts/agents/blockers/`、`artifacts/agents/decisions/`、`artifacts/agents/review-feedback-plan.md`、`artifacts/reviews/design-review.md`、`artifacts/reviews/implementation-plan-review.md`、`artifacts/reviews/final-review.md`、`artifacts/agents/worker-status.md`、`artifacts/agents/debug-evidence.json`、`artifacts/agents/tdd-evidence.json`、`artifacts/agents/verification-evidence.json`）はプロジェクト採用の文書言語で維持する
+- `proposal.md`、`tasks.md`、`state.json`、`verification.md`、`review.md` と、goal-only artifacts（`design.md`、`implementation-plan.md`、`artifacts/agents/task-graph.json`、`artifacts/agents/bootstrap.md`、`artifacts/agents/handoff.md`、`artifacts/agents/planning-preflights/`、`artifacts/agents/workspace-status.md`、`artifacts/agents/worktree-plan.md`、`artifacts/agents/finish-plan.md`、`artifacts/agents/launch-plan.md`、`artifacts/agents/worker-runs/`、`artifacts/agents/review-runs/`、`artifacts/agents/retries/`、`artifacts/agents/blockers/`、`artifacts/agents/decisions/`、`artifacts/agents/review-feedback-plan.md`、`artifacts/reviews/design-review.md`、`artifacts/reviews/implementation-plan-review.md`、`artifacts/reviews/final-review.md`、`artifacts/agents/worker-status.md`、`artifacts/agents/debug-evidence.json`、`artifacts/agents/tdd-evidence.json`、`artifacts/agents/verification-evidence.json`）はプロジェクト採用の文書言語で維持する
 - 製品 UI、サイト locale、または「英語優先」という要件だけから change 文書言語を推測しない
@@ -34,3 +34,3 @@ - プロジェクト採用プロトコルが中国語、または現在の change 文書がすでに中国語なら、明示的なルール変更がない限り change 文書は中国語のまま維持する
 - ユーザーが Goal を明示的に選択した場合だけ `ospec goal` / `ospec-goal` を使う
-- `ospec execute …` コントローラ層（bootstrap、doc-review、dispatch、launch、review、worktree、finish、collect、retry、sync）と goal 専用 artifacts はすべて `workflow_profile_id: goal` に属する。`workflow_profile_id: change` では、クラシックな高速フローを維持し、execute 層や goal artifacts を読まず・実行せず、`proposal.md` と `tasks.md` を編集し、実装し、`verification.md` と `review.md` を記録してから `ospec verify` と `ospec finalize` で閉じる——ユーザーがこの change での agent/worker 実行を明示的に求めない限り
+- `ospec execute …` コントローラ層（bootstrap、preflight、dispatch、launch、review、worktree、finish、collect、retry、sync）と goal 専用 artifacts はすべて `workflow_profile_id: goal` に属する。`workflow_profile_id: change` では、クラシックな高速フローを維持し、execute 層や goal artifacts を読まず・実行せず、`proposal.md` と `tasks.md` を編集し、実装し、`verification.md` と `review.md` を記録してから `ospec verify` と `ospec finalize` で閉じる——ユーザーがこの change での agent/worker 実行を明示的に求めない限り
 - AI 支援で goal を進める場合、ユーザーに `design.md` や `implementation-plan.md` の手書きを求めない。要件、`proposal.md`、プロジェクト文脈からそれらを作成または更新してから `artifacts/agents/task-graph.json` を導出し、`tasks.md` やコードを編集する
@@ -44,3 +44,3 @@ - classic change では、ユーザーが明示的に goal へ昇格させない限り goal-only files を作成しない
 - 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 する。continuous mode は新しい structured finding-ID set に限って既定しきい値を超えて続行し、反復または循環する findings は停止する。strict mode は exact user-authorized extra-round window を維持する
+- task graph を導出する前に、`ospec execute preflight [changes/active/<change>] --stage design`、続いて `--stage plan` を実行する。どちらも deterministic inline readiness preflight と監査可能な approval artifact の記録だけを行い、reviewer child は起動しない。両方が通過した後に `task-graph.json` を導出または更新する。通常の red test、production implementation、green/refactor evidence は、test harness 自体が独立して再利用可能な成果物でない限り、1 つの atomic task にまとめる
 - ready、blocked、running、completed と安全な次 task 候補を確認する必要がある場合は、`ospec execute status [changes/active/<change>]` または `ospec execute next [changes/active/<change>]` を使って controller view を確認する
@@ -59,3 +59,3 @@ - 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.
 - `runtimeAdapter.selected.nativeSubagent` を実行し、安全な batch だけを並列 dispatch する。capability がない、または期限切れの場合は block し、agent CLI や current controller に fallback しない
-- `IDE-CONTROLLER-AUTO-DISPATCH`: L1 は report-only。L2/L3 では IDE AI が tick -> 各 action の `runtimeAdapter.selected.nativeSubagent` で全 `actions[]` を実行 -> heartbeat/result evidence -> 即時 tick を担当する。`actions[]` が空で `pending` がある場合は観察のみで再 dispatch しない
+- `IDE-CONTROLLER-AUTO-DISPATCH`: すべての Goal は同じ実行可能な fast quality workflow を使う。IDE AI が tick -> model-native subagent で全 `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` を使う
@@ -65,3 +65,3 @@ - debugging が change の一部だった場合、`ospec execute debug [changes/active/<change>] --phase reproduce|isolate|hypothesize|fix|verify --symptom "..." --root-cause "..." --status FIXED` で root cause と fix evidence を記録する。このコマンドは evidence の記録のみを行い、shell command は実行しない
 - fresh project checks を実行した後、`ospec execute verify [changes/active/<change>] --command "..." --status PASSED --exit-code 0` で verification evidence を記録する。このコマンドは evidence の記録のみを行い、shell command は実行しない
-- `ospec execute doc-review` は artifacts のみを記録し、reviewer 起動、shell command 実行、worker status 同期、source file 編集は行わない
+- `ospec execute preflight` は artifacts のみを記録し、reviewer 起動、shell command 実行、worker status 同期、source file 編集は行わない
 - goal では `artifacts/agents/task-graph.json` に未解決の task 状態、無効な依存関係、対象ファイル不足、検証コマンド不足、またはトップレベル `status` が `completed` でない状態がある場合は archive しない
@@ -101,3 +101,3 @@ - 実装後は各 task の統合 review（`artifacts/reviews/tasks/<task-id>/review.md`）を完了し、単一の final `artifacts/reviews/final-review.md` を完了する。未解決の task-level または final review decision は archive をブロックする
 
-- `.skillrc.workflow.document_review_policy` の既定値は `always`。`adaptive` は対象文書が `risk_level: low`（または `none`）を明示し、API、security、migration、data、architecture、external integration、scope の risk signal がない場合だけ inline preflight を使う。risk context が欠落または解析不能なら独立 reviewer を dispatch する。
+- design/plan deterministic preflight、task graph 導出、独立 combined planning review の順に実行する。grouped planning repair と fresh re-review は各 1 回までとし、task review、final combined review、verification は引き続き必須。
 - worker/reviewer の logical model profile は launch override を含む実際の dispatch target に対して解決する。requested/configured model と provider-observed model を分離し、provider/usage evidence がなければ observed model は unknown とする。
@@ -104,0 +104,0 @@ - command runner は `OSPEC_USAGE_FILE` を受け取り sidecar を自動集計する。`ospec execute complete ... --usage-file usage.json` は手動入力として残す。metrics は source、observed fields、complete/partial/missing coverage を記録し、未報告値を測定済み 0 として扱わない。

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

@@ -31,3 +31,3 @@ ---
 - ユーザーが Goal を明示的に選択した場合だけ `ospec goal` / `ospec-goal` を使う
-- `ospec execute …` コントローラ層（bootstrap、doc-review、dispatch、launch、review、worktree、finish、collect、retry、sync）と goal 専用 artifacts はすべて `workflow_profile_id: goal` に属する。`workflow_profile_id: change` では、クラシックな高速フローを維持し、execute 層や goal artifacts を読まず・実行せず、`proposal.md` と `tasks.md` を編集し、実装し、`verification.md` と `review.md` を記録してから `ospec verify` と `ospec finalize` で閉じる——ユーザーがこの change での agent/worker 実行を明示的に求めない限り
+- `ospec execute …` コントローラ層（bootstrap、preflight、dispatch、launch、review、worktree、finish、collect、retry、sync）と goal 専用 artifacts はすべて `workflow_profile_id: goal` に属する。`workflow_profile_id: change` では、クラシックな高速フローを維持し、execute 層や goal artifacts を読まず・実行せず、`proposal.md` と `tasks.md` を編集し、実装し、`verification.md` と `review.md` を記録してから `ospec verify` と `ospec finalize` で閉じる——ユーザーがこの change での agent/worker 実行を明示的に求めない限り
 - AI 支援で goal を進める場合は、`proposal.md` の後、`implementation-plan.md`、`tasks.md`、コードを編集する前に `design.md` を作成または更新する。classic change では、ユーザーが明示的に goal へ昇格させない限り goal-only files を作成しない
@@ -40,4 +40,4 @@ - `Announce-Before-Act`: ワークフローを黙って実行しない。OSpec skill・段階、コマンドと生成物、選択された model-native subagent adapter、worker 数、current session capability、blocking gate を伝える
 - goal では `implementation-plan.md` から `artifacts/agents/task-graph.json` を導く。各 task には id、状態、依存関係、並行安全性、競合、対象ファイル、検証コマンド、期待結果、worker role を含める。`target_files` が他の ready task と重ならず、依存もない task はすべて `parallelizable: true` にする。task 同士がファイルを共有するか実際に依存する場合のみ `parallelizable: false` を残し、`serial_reason` と `conflicts_with` を記録する。すべてを既定で直列にせず、安全な graph を 1 worker に制限する場合は `maxParallelReason` を記録する。6 個を超える `target_files` は task を分割し、1 つの atomic verification boundary が必要な場合だけ具体的な `scope_reason` を記録する
-- L3 allowlist は安全な置換であり、暗黙の追加ではない。`ospec loop allowlist derive/check/apply --from-task-graph` を優先し、CAS に結び付いた差分を確認して、意図した権限拡張だけを明示的に承認する。
-- specialist document review は収束させる。前回の findings sidecar と resolution evidence を先に確認し、その後 current document 全体を review する。既定の round/time 値は収束しきい値であり、新しい structured finding-ID set は自動続行できるが、反復または循環する set は停止する。cache/pending reuse と同じ dispatch の recovery は round を消費しない。durable decision を持たない legacy imported completion は round として数えるが convergence decision は提供しないため、authoritative document の変更後は OSpec に fresh review を dispatch させ、ledger を手動編集または再ハッシュしない。`--force` は Loop lifetime、token、STOP、no-progress、context、executor provenance の guard を迂回しない。strict mode は exact user-authorized extra-round window を維持する。
+- optional allowlist は安全な置換であり、暗黙の追加ではない。追加境界が必要な場合だけ `ospec loop allowlist derive/check/apply --from-task-graph` を使い、CAS 差分と権限拡張を明示的に確認する。
+- design/plan stage は deterministic inline preflight を使い、その後に独立した combined planning review を 1 回実行する。grouped planning repair と fresh re-review は各 1 回だけ許可し、再失敗は安定して block する。
 - review repair は収束させる。共有ファイルを変更する downstream task は推移的 upstream の regression obligation を継承する。既定の 2 round は収束しきい値であり、structured finding ID が変化すれば自動続行する。同じ ID でも structured finding fingerprint と直前に許可された repair scope 内の code snapshot が両方変化した場合だけ続行できる。continuous mode では、停滞した task または final finding 集合に、その正確な scope と finding ID に対する durable strategy escalation を 1 回だけ発行する。root cause の再評価と focused regression を要求する packet を 1 回実行し、同じ集合が停滞したままなら停止する。strict mode は設定済み上限を維持する。final review が `BLOCKED` の場合は blocker の解決まで停止し、grouped repair に進めない。変化しない作業を繰り返すために上限を引き上げてはならない。
@@ -48,3 +48,3 @@ - すべての 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 は既定の並列数 3 を使用し、安全な review 並列性は維持する。harness が現在のより大きな child capacity を確実に把握できる場合は active controller session に結び付けて報告し、必要に応じて `maxParallel` を引き上げられるが、capacity を推測したり古い値を再利用してはならない。
 - 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]` で `artifacts/agents/document-review-dispatches/` 配下に project session brief snapshot を含む document reviewer packet を作成し、`artifacts/reviews/design-review.md` または `artifacts/reviews/implementation-plan-review.md` を用意する。design review 承認後に implementation plan review を dispatch する。このコマンドは artifacts のみを記録し、reviewer 起動、shell command 実行、worker status 同期、source file 編集は行わない
+- task graph 導出前に `ospec execute preflight [changes/active/<change>] --stage design`、続いて `--stage plan` を実行し、project session brief snapshot を含む deterministic inline preflight packet と approval artifact を作成する。両方の preflight 通過後に task graph を導出または更新する。コマンドは reviewer child、shell command、worker status 同期、source file 編集を実行しない。通常の red test、production implementation、green/refactor evidence は 1 つの atomic task にまとめる
 - task 作業を割り当てる前に、`ospec execute status [changes/active/<change>]` または `ospec execute next [changes/active/<change>]` で controller 状態と安全な次の task 候補を確認する
@@ -64,3 +64,3 @@ - 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.
 - `runtimeAdapter.selected.nativeSubagent` を実行し、安全な batch だけを並列 dispatch する。capability がない、または期限切れの場合は block し、agent CLI や current controller に fallback しない
-- `IDE-CONTROLLER-AUTO-DISPATCH`: L1 は report-only。L2/L3 では IDE AI が tick -> 各 action の `runtimeAdapter.selected.nativeSubagent` で全 `actions[]` を実行 -> heartbeat/result evidence -> 即時 tick を担当する。`actions[]` が空で `pending` がある場合は観察のみで再 dispatch しない
+- `IDE-CONTROLLER-AUTO-DISPATCH`: すべての Goal は同じ実行可能な fast quality workflow を使う。IDE AI が tick -> model-native subagent で全 `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` を使う
@@ -104,3 +104,3 @@ - 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 のみとする
 
-- `.skillrc.workflow.document_review_policy` の既定値は `always`。`adaptive` は対象文書が `risk_level: low`（または `none`）を明示し、risk signal がない場合だけ deterministic inline preflight を使う。risk context の欠落、言語判定不能、解析失敗では独立 reviewer を dispatch する。
+- design/plan deterministic preflight、task graph 導出、独立 combined planning review の順に実行し、grouped planning repair と fresh re-review は各 1 回までとする。
 - `.skillrc.workflow.model_profiles` は `mechanical`、`standard`、`strong_reasoning`、`review`、`final_review` logical profile を target-specific model に対応付ける。未設定時は harness default と packet warning を使う。
@@ -107,0 +107,0 @@ - command runner は `OSPEC_USAGE_FILE` で normalized usage を自動集計し、`--usage-file` は手動 override として残る。`execution-metrics.json` は capability tier、model profile、workflow stage 別に集計し、complete/partial/missing coverage を報告する。

assets/for-ai/zh-CN/ai-guide.md

@@ -25,3 +25,3 @@ ---
 
-- 文档语言按项目 adopted protocol 执行；如果项目采用中文协议，则 `proposal.md`、`tasks.md`、`state.json`、`verification.md`、`review.md` 和所有 goal-only artifacts 必须保持中文，包括 `design.md`、`implementation-plan.md`、`artifacts/agents/task-graph.json`、`artifacts/agents/bootstrap.md`、`artifacts/agents/handoff.md`、`artifacts/agents/document-review-dispatches/`、`artifacts/agents/workspace-status.md`、`artifacts/agents/worktree-plan.md`、`artifacts/agents/finish-plan.md`、`artifacts/agents/launch-plan.md`、`artifacts/agents/worker-runs/`、`artifacts/agents/review-runs/`、`artifacts/agents/retries/`、`artifacts/agents/blockers/`、`artifacts/agents/decisions/`、`artifacts/agents/review-feedback-plan.md`、`artifacts/reviews/design-review.md`、`artifacts/reviews/implementation-plan-review.md`、`artifacts/reviews/final-review.md`、`artifacts/agents/worker-status.md`、`artifacts/agents/debug-evidence.json`、`artifacts/agents/tdd-evidence.json` 和 `artifacts/agents/verification-evidence.json`
+- 文档语言按项目 adopted protocol 执行；如果项目采用中文协议，则 `proposal.md`、`tasks.md`、`state.json`、`verification.md`、`review.md` 和所有 goal-only artifacts 必须保持中文，包括 `design.md`、`implementation-plan.md`、`artifacts/agents/task-graph.json`、`artifacts/agents/bootstrap.md`、`artifacts/agents/handoff.md`、`artifacts/agents/planning-preflights/`、`artifacts/agents/workspace-status.md`、`artifacts/agents/worktree-plan.md`、`artifacts/agents/finish-plan.md`、`artifacts/agents/launch-plan.md`、`artifacts/agents/worker-runs/`、`artifacts/agents/review-runs/`、`artifacts/agents/retries/`、`artifacts/agents/blockers/`、`artifacts/agents/decisions/`、`artifacts/agents/review-feedback-plan.md`、`artifacts/reviews/design-review.md`、`artifacts/reviews/implementation-plan-review.md`、`artifacts/reviews/final-review.md`、`artifacts/agents/worker-status.md`、`artifacts/agents/debug-evidence.json`、`artifacts/agents/tdd-evidence.json` 和 `artifacts/agents/verification-evidence.json`
 - 产品界面文案、站点默认语言或 “English-first” 业务策略，不得自动推导为 change 文档应改成英文
@@ -35,3 +35,3 @@ - 若当前 change 已存在中文内容，后续更新必须延续中文，除非项目规则显式声明文档语言切换为英文
 - 只有用户明确选择 Goal 时才使用 `ospec goal` / `ospec-goal`
-- `ospec execute …` 控制层（bootstrap、doc-review、dispatch、launch、review、worktree、finish、collect、retry、sync）和所有 goal-only artifacts 都属于 `workflow_profile_id: goal`。对 `workflow_profile_id: change`，保持经典快速流程——不要读取或运行 execute 层或 goal artifacts；编辑 `proposal.md` 和 `tasks.md`、实现、记录 `verification.md` 和 `review.md`，再用 `ospec verify` 和 `ospec finalize` 收尾——除非用户明确要求对这个 change 做 agent/worker 执行
+- `ospec execute …` 控制层（bootstrap、preflight、dispatch、launch、review、worktree、finish、collect、retry、sync）和所有 goal-only artifacts 都属于 `workflow_profile_id: goal`。对 `workflow_profile_id: change`，保持经典快速流程——不要读取或运行 execute 层或 goal artifacts；编辑 `proposal.md` 和 `tasks.md`、实现、记录 `verification.md` 和 `review.md`，再用 `ospec verify` 和 `ospec finalize` 收尾——除非用户明确要求对这个 change 做 agent/worker 执行
 - AI 辅助执行 goal 时，不要求用户手写 `design.md` 或 `implementation-plan.md`；必须先基于需求、`proposal.md` 和项目上下文起草或更新它们，再推导 `artifacts/agents/task-graph.json`、编辑 `tasks.md` 或代码
@@ -45,3 +45,3 @@ - 执行经典 change 时，不要创建 goal-only 文件，除非用户明确把该工作升级为 goal
 - 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。连续模式只有遇到新的结构化 finding-ID 集合才会超过默认阈值继续，重复或循环 findings 会停止；严格模式保留精确用户授权的额外轮次窗口
+- 派生 task graph 前，依次运行 `ospec execute preflight [changes/active/<change>] --stage design` 和 `--stage plan`。两步都只执行确定性的 inline 就绪预检并记录可审计 approval artifacts，不启动 reviewer child；两步通过后才能派生或刷新 `task-graph.json`。普通 red test、对应生产实现和 green/refactor 证据必须放在同一个原子 task，除非测试基础设施本身是可独立复用的交付物
 - 需要查看 ready、blocked、running、completed 和下一批安全任务时，用 `ospec execute status [changes/active/<change>]` 或 `ospec execute next [changes/active/<change>]` 查看 controller 视图
@@ -61,5 +61,5 @@ - 需要把下一条 OSpec 命令持久化给人或 AI 接手时，用 `ospec execute route [changes/active/<change>]` 写入 `artifacts/agents/workflow-route.json` 和 `artifacts/agents/workflow-route.md`；该命令只记录 workflow routing artifacts，不会编辑源码。
 - goal 集成循环使用 controller 模式时，不要停在初始化或让用户手工运行 Loop 命令。运行 `ospec loop run [change] --once --json`，通过每个 action 的 `runtimeAdapter.selected.nativeSubagent` 执行，持久化 heartbeat/result evidence，再无需用户提示地继续 tick；每个 worker 只读取引用的 packet
-- `IDE-CONTROLLER-AUTO-DISPATCH`：L1 只报告；L2/L3 由 IDE 主 AI 负责 tick -> 通过每个 action 的 `runtimeAdapter.selected.nativeSubagent` 执行全部 `actions[]` -> 写 heartbeat/result evidence -> 立即再 tick。`actions[]` 为空但存在 `pending` 时只观察，绝不能重派
+- `IDE-CONTROLLER-AUTO-DISPATCH`：所有 Goal 使用同一条可执行的快速质量流程；IDE 主 AI 负责 tick -> 通过模型原生 subagent 执行全部 `actions[]` -> 写 heartbeat/result evidence -> 立即再 tick。`actions[]` 为空但存在 `pending` 时只观察，绝不能重派
 - agent CLI 执行已移除；`loop watch`、`execute orchestrate`、`launch --run --command` 和 `review --run --command` 都会在启动进程或创建 run artifact 前失败
-- required decision 会阻断所有安全级。L1 不产生可执行 action；L3 还要求 path 和 command allowlist 都非空，并阻断越界目标文件或验证命令
+- required decision 始终阻断实现。可选的 path/command allowlist 只在明确配置时增加 fail-closed 边界，不形成另一套 Goal 级别
 - 省 token（不改变任何门禁）：`ospec execute …` 和 `ospec loop status` 使用 `--brief`，从简要状态和 action 的 packet path 驱动每一步；复审先读上轮 findings sidecar/解决摘要，再按需打开完整历史，不要每轮重读或内嵌完整任务图、worker status、launch plan 或全部 goal 文档
@@ -70,3 +70,3 @@ - 修复 blocked、needs-context 或 failed native work 后，用 `ospec execute retry` 重新派发；已完成任务默认不得 retry，除非显式 `--force`
 - 运行最新项目检查后，用 `ospec execute verify [changes/active/<change>] --command "..." --status PASSED --exit-code 0` 记录验证证据；该命令只记录 evidence，不会运行 shell 命令
-- `ospec execute doc-review` 只记录 artifacts，不会启动 reviewer、运行 shell 命令、同步 worker status 或编辑源码；specialist review 必须通过 `runtimeAdapter.selected.nativeSubagent` 执行并绑定真实 child id
+- `ospec execute preflight` 只记录确定性 inline preflight artifacts，不会启动 reviewer、运行 shell 命令、同步 worker status 或编辑源码
 - 对 goal，`artifacts/agents/task-graph.json` 中存在未解决 task 状态、无效依赖、缺失目标文件、缺失验证命令，或顶层 `status` 不是 `completed` 时，不得 archive
@@ -153,3 +153,3 @@ - 实现后每个任务必须完成该任务的一次合并 review（`artifacts/reviews/tasks/<task-id>/review.md`）；最终阶段必须完成单一的 `artifacts/reviews/final-review.md`；未解决的单任务或最终 review decision 会阻止 archive
 
-- `.skillrc.workflow.document_review_policy` 默认 `always`；`adaptive` 只有在目标文档显式声明 `risk_level: low`（或 `none`），且没有 API、安全、迁移、数据、架构、外部集成或范围风险信号时才使用确定性 inline preflight。风险上下文缺失或无法解析时必须派独立 reviewer。
+- 依次执行 design/plan 确定性预检，派生 task graph，再执行一次独立 combined planning review；最多允许一次整体规划修复和一次 fresh re-review。task review、最终 combined review 和验证仍然保留。
 - worker/reviewer 使用逻辑 model profile，并按实际 dispatch target（包括 launch override）解析。requested/configured model 与 provider observed model 必须分开；没有 provider/usage 证据时 observed model 是未知，不能宣称已选择。
@@ -156,0 +156,0 @@ - 命令执行器会收到 `OSPEC_USAGE_FILE` 并自动归集该 sidecar；`ospec execute complete ... --usage-file usage.json` 继续作为手工入口。指标必须记录来源、实际观测字段和 complete/partial/missing 覆盖率，未上报的计数不能显示成已测得的零。

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

@@ -33,3 +33,3 @@ ---
 - 只有用户明确选择 Goal 时才使用 `ospec goal` / `ospec-goal`
-- `ospec execute …` 控制层（bootstrap、doc-review、dispatch、launch、review、worktree、finish、collect、retry、sync）和所有 goal-only artifacts 都属于 `workflow_profile_id: goal`。对 `workflow_profile_id: change`，保持经典快速流程——不要读取或运行 execute 层或 goal artifacts；编辑 `proposal.md` 和 `tasks.md`、实现、记录 `verification.md` 和 `review.md`，再用 `ospec verify` 和 `ospec finalize` 收尾——除非用户明确要求对这个 change 做 agent/worker 执行
+- `ospec execute …` 控制层（bootstrap、preflight、dispatch、launch、review、worktree、finish、collect、retry、sync）和所有 goal-only artifacts 都属于 `workflow_profile_id: goal`。对 `workflow_profile_id: change`，保持经典快速流程——不要读取或运行 execute 层或 goal artifacts；编辑 `proposal.md` 和 `tasks.md`、实现、记录 `verification.md` 和 `review.md`，再用 `ospec verify` 和 `ospec finalize` 收尾——除非用户明确要求对这个 change 做 agent/worker 执行
 - AI 辅助执行 goal 时，必须在完成 `proposal.md` 后、编辑 `implementation-plan.md`、`tasks.md` 或代码前，先起草或更新 `design.md`。执行经典 change 时，不要创建 goal-only 文件，除非用户明确升级为 goal
@@ -42,4 +42,4 @@ - `Announce-Before-Act`：绝不静默执行流程。宣告 OSpec skill 与阶段、命令与产物、所选 model-native subagent adapter、worker 数量、当前 session capability，以及阻塞门禁和解锁条件
 - 对 goal，必须从 `implementation-plan.md` 推导 `artifacts/agents/task-graph.json`；每个 task 必须包含 id、状态、依赖、并行安全性、冲突、目标文件、验证命令、预期结果和 worker 角色。凡是 `target_files` 与其它就绪 task 不重叠、且彼此无依赖的 task，都要标 `parallelizable: true`，这样 OSpec 会把它们作为一个并行批次派发、goal 更快；只有当 task 之间共享文件或确有依赖时才保留 `parallelizable: false`，并填写 `serial_reason` 与 `conflicts_with`。不要把所有 task 都默认设成 `parallelizable: false`；把安全任务显式限制为单 worker 时必须记录 `maxParallelReason`。超过六个 `target_files` 的 task 应拆分；确实属于同一原子验证边界时必须填写具体的 `scope_reason`
-- L3 白名单采用安全替换语义。优先使用 `ospec loop allowlist derive/check/apply --from-task-graph`，检查 CAS 绑定的差异，并仅对预期的权限扩大显式确认。不要假设多次 `loop configure --allow-*` 会累加。
-- specialist 文档审查必须收敛。先读取上轮 findings sidecar 与解决证据，再完整审查当前文档；默认轮次和时间值是收敛阈值，新的结构化 finding-ID 集合可以自动继续，重复或循环集合会停止。缓存/待处理复用和同一 dispatch 恢复不计轮次。缺少持久 decision 的 legacy imported completion 仍计入轮次，但不提供收敛 decision；权威文档变化后应让 OSpec 派发 fresh review，绝不手改或重算 ledger hash chain。`--force` 不能绕过 Loop 总期限、token、STOP、no-progress、context 或 executor provenance 门禁。严格模式保留精确用户授权的额外轮次窗口。
+- 可选白名单采用安全替换语义。需要额外边界时使用 `ospec loop allowlist derive/check/apply --from-task-graph`，检查 CAS 绑定的差异，并仅对预期的权限扩大显式确认。
+- design/plan 阶段使用确定性 inline preflight，随后执行一次独立的合并规划复审。只允许一次 grouped planning repair 和一次 fresh re-review；重复失败后稳定阻断。
 - review repair 必须收敛。共享文件的下游任务要继承传递上游的回归义务；默认两轮是收敛阈值。结构化 finding ID 变化时自动继续；同一 ID 只有在结构化 finding 指纹与上一轮授权 repair scope 内的代码快照同时变化时也可继续。连续模式下，停滞的 task 或 final finding 集合会按精确 scope 与 finding ID 获得一次持久化策略升级；只执行一次要求重新定位根因并加强聚焦回归的 packet，同一集合仍停滞时必须停止。严格模式继续遵守配置上限。final review 为 `BLOCKED` 时必须停下解决 blocker，不得进入 grouped repair。不得提高上限重复未变化的工作。
@@ -50,3 +50,3 @@ - 所有 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 使用默认并发 3，且不降低安全 review 的并行度。harness 能可靠获知当前更大的 child 容量时，可以把它绑定到当前 controller session 并相应提高 `maxParallel`；绝不能猜测或复用过期容量。
 - 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]` 在 `artifacts/agents/document-review-dispatches/` 下生成带 project session brief snapshot 的文档 reviewer 交接包，并创建 `artifacts/reviews/design-review.md` 或 `artifacts/reviews/implementation-plan-review.md`；design review 通过后才能派发 implementation plan review。该命令只记录 artifacts，不会启动 reviewer、运行 shell 命令、同步 worker status 或编辑源码
+- 派生 task graph 前，依次运行 `ospec execute preflight [changes/active/<change>] --stage design` 和 `--stage plan`，生成带 project session brief snapshot 的确定性 inline preflight packet，并创建 `artifacts/reviews/design-review.md` 和 `artifacts/reviews/implementation-plan-review.md`。两步都通过后再派生或刷新 task graph；命令只记录 artifacts，不会启动 reviewer、运行 shell 命令、同步 worker status 或编辑源码。普通 red test、对应生产实现和 green/refactor 证据应合并为一个原子 task
 - 分派任务前，用 `ospec execute status [changes/active/<change>]` 或 `ospec execute next [changes/active/<change>]` 查看 controller 状态和下一批安全可分派任务
@@ -67,3 +67,3 @@ - 需要把下一条 OSpec 命令持久化给人或 AI 接手时，用 `ospec execute route [changes/active/<change>]` 写入 `artifacts/agents/workflow-route.json` 和 `artifacts/agents/workflow-route.md`；该命令只记录 workflow routing artifacts，不会编辑源码。
 - 执行 `runtimeAdapter.selected.nativeSubagent`，只并行派发安全 batch。capability 缺失或过期时阻断，不得启动 agent CLI 或退回 controller context
-- `IDE-CONTROLLER-AUTO-DISPATCH`：L1 只报告；L2/L3 由 IDE 主 AI 负责 tick -> 通过每个 action 的 `runtimeAdapter.selected.nativeSubagent` 执行全部 `actions[]` -> 写 heartbeat/result evidence -> 立即再 tick。`actions[]` 为空但存在 `pending` 时只观察，绝不能重派
+- `IDE-CONTROLLER-AUTO-DISPATCH`：所有 Goal 使用同一条可执行的快速质量流程；IDE 主 AI 负责 tick -> 通过模型原生 subagent 执行全部 `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`
@@ -130,3 +130,3 @@ - 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>`
 
-- `.skillrc.workflow.document_review_policy` 默认 `always`；`adaptive` 只有在目标文档显式声明 `risk_level: low`（或 `none`）且没有风险信号时才执行 deterministic inline preflight。风险上下文缺失、语言无法可靠识别或无法解析时必须派独立 reviewer。
+- 依次执行 design/plan 确定性预检，派生 task graph，再执行一次独立 combined planning review；最多允许一次整体规划修复和一次 fresh re-review。
 - `.skillrc.workflow.model_profiles` 将 `mechanical`、`standard`、`strong_reasoning`、`review`、`final_review` 逻辑 profile 映射到各 target 模型；未配置时使用 harness 默认并在 packet 中警告。
@@ -133,0 +133,0 @@ - 命令执行器通过 `OSPEC_USAGE_FILE` 自动归集标准化 usage；`--usage-file` 保留为手工覆盖入口。`execution-metrics.json` 按 capability tier、model profile 和 workflow stage 汇总，并报告 complete/partial/missing 覆盖率。

assets/global-skills/codex/ospec-goal/agents/openai.yaml

@@ -7,2 +7,2 @@ interface:
 
-  default_prompt: "Use $ospec-goal to run a full IDE-controlled workflow: ask for L1/L2/L3, create work with ospec goal <goal-name> [path] and explicit controller capability flags, then dispatch every Loop action through spawn_agent + wait, persist heartbeat/result evidence, and keep ticking until done or genuinely blocked."
+  default_prompt: "Use $ospec-goal to run the fast quality workflow: create work with ospec goal <goal-name> [path] and explicit controller capability flags, run deterministic preflights and one combined planning review, then dispatch every Loop action through spawn_agent + bounded waits, persist evidence, and keep ticking until done or genuinely blocked."

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

@@ -15,8 +15,7 @@ ---
 - **OSpec is the durable state-machine brain.** `ospec loop run --once` first observes the previous task, review, or verification evidence, then emits a bounded batch of action items from `task-graph.json`. Each action carries a target-bound `runtimeAdapter`; execute it only through the current model harness native subagent primitive, then record durable evidence.
-- **IDE controller auto-dispatch is mandatory for executable L2/L3 goals.** L1 is report-only and never starts implementation/review/verifier action batches; for implementation, present the safety-level decision first and wait for the user to choose L2 or L3. After creating or resuming an executable goal, do not stop at "Loop initialized", ask the user to run Loop commands, or wait for another prompt. Once actions are ready, run `ospec loop run <goal-path> --once --json`, immediately consume every returned action through `runtimeAdapter.selected`, record durable evidence as each executor finishes, and tick again. Stop only for an actual required user decision, unavailable independent/isolated executor, blocking safety/plugin gate, configured guard/STOP, terminal failure that needs user authority, explicit user pause, or `done`.
+- **IDE controller auto-dispatch is mandatory.** Every Goal uses the same executable fast quality workflow. After creating or resuming a goal, do not stop at "Loop initialized", ask the user to run Loop commands, or wait for another prompt. Once actions are ready, run `ospec loop run <goal-path> --once --compact-json`, immediately consume every returned action, record durable evidence as each executor finishes, and tick again. Stop only for an actual required user decision, unavailable independent or isolated executor, blocking safety/plugin gate, configured guard/STOP, terminal failure that needs user authority, explicit user pause, or `done`.
 - **Harness capability is explicit and target-bound.** In Codex create executable work with `--target codex --execution-model controller --harness-interactive true --native-subagents supported`; use the equivalent actual target in other IDEs. A target name alone never proves that native children exist. `runtimeAdapter.selected` exists only when the capability target matches, the session is current, and native subagents are supported. There is no Orca, target-CLI, or current-controller fallback.
 - **Executor lifecycle is durable and bounded.** After native subagent dispatch, record `ospec loop heartbeat <goal> --action-item <id> --executor <child-id>` and refresh every live child before its `heartbeatDueAt`. Never make one indefinite native wait: Codex/GPT use `wait_agent` for at most 60 seconds per poll, Claude uses bounded background Task polling when available, and every other native adapter follows its published `maxWaitMs`. Sixty seconds limits one controller poll, not the child runtime; a live child continues across polls up to its action deadline. Commit each finished child with its emitted `ospec loop finalize ...` command, persist completed siblings immediately, and re-run `loop run --once --json` after every poll. Each successful bounded controller poll renews the short lease for already-claimed live children without extending the absolute deadline. A poll may recover that same claim only within one bounded 60-second wait after the short-lease boundary; direct late results remain rejected, a controller that stops polling still lets orphan leases expire, and no renewal moves the absolute deadline. Successful finalize requires authoritative durable evidence; evidence-complete work receives a bounded result grace period. Legacy `loop result` remains supported. Use `ospec loop recover --force` only when the prior session/child is known to be gone. Expired items requeue; completed siblings do not.
-- **Independent document reviewers are bound to a native child.** Read `dispatch.runtimeAdapter.selected.nativeSubagent`, start one fresh model-native reviewer, immediately claim its real child id, refresh long reviews with `--heartbeat-executor`, and finish with `--complete-executor`. Reviews bind the target, controller session, child, timestamp, document hash, and findings provenance.
-- **Safety level chosen at creation via a decision gate.** Prefer presenting an `AskUserQuestion` for L1/L2/L3 as the first decision; otherwise pass `ospec goal <name> --level L1|L2|L3` (default L1). L1 = report-only (findings go to triage, no code changes); L2 = assisted (real changes but required-decision gates hard-block); L3 = unattended within an allowlist.
-- **Required decisions block every level.** Present each required decision to the user, never auto-select the recommendation, and record the answer with `ospec execute decision ... --select ... --answered-by user` before the loop proceeds. New brainstorm resolutions require the same `--answered-by user` provenance. L3 additionally requires non-empty path and command allowlists; it does not bypass human decision gates.
+- **Planning quality is fast and bounded.** Run design preflight, then implementation-plan preflight, derive the task graph, and let Loop issue one independent combined planning review. The two preflights use no reviewer child. A `NEEDS_CHANGES` planning review permits one grouped repair and one fresh re-review; another failure is a stable blocker, never an open-ended loop.
+- **Required decisions always block.** Present each required decision to the user, never auto-select the recommendation, and record the answer with `ospec execute decision ... --select ... --answered-by user` before the loop proceeds. New brainstorm resolutions require the same `--answered-by user` provenance.
 - **`/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.
@@ -26,8 +25,7 @@ - **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.
 - **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. Legacy imported completions without a durable decision still count as rounds but expose unavailable convergence context, so changed authoritative documents receive a fresh review without rewriting the append-only ledger. 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.
+- **Guards are enforced before new work.** Pause/STOP, iteration/deadline/token/time budgets, no-progress limits, comprehension-review checkpoints, required decisions, passed planning preflights and combined planning review, ready workspace evidence, and optional configured allowlists can stop or pause the loop.
 - **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.
 - **Verification scope must be proportional.** Treat an unscoped `docker compose up --build` or `docker-compose up --build` warning as a required preflight: inspect repository release guidance and prefer explicit service names unless the task genuinely requires rebuilding every service. Do not download or rebuild unrelated optional runtimes merely to verify a scoped application change.
 - **External acceptance may be deferred, never waived.** Keep device, credential, manual, and third-party acceptance out of unrelated implementation critical paths. When durable implementation exists and the user explicitly authorizes moving only external acceptance to the final gate, use `ospec execute defer-blocker`; the task stays `BLOCKED` and unchecked, while dependency-safe implementation may continue. Final review, verification, finalization, and archive remain hard-blocked until the real evidence exists.
-- **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.
+- **Allowlist updates are optional, replacement-based, or explicit CAS.** Repeated `loop configure --allow-*` calls replace the complete selected list and print a diff; they never append. When an extra boundary is needed, derive/check/apply exact task-graph permissions, review the diff, and pass `--approve-expansion` only for an intended expansion.
 - **Stop condition is three-stage:** run the project's real tests, record evidence with `ospec execute verify --status`, then confirm with `ospec verify`.
@@ -42,4 +40,4 @@
 - proposal, design, implementation-plan, task graph, and task refinement
-- document review for design and implementation plan
-- independent approval artifacts at `artifacts/reviews/design-review.md` and `artifacts/reviews/implementation-plan-review.md`
+- deterministic preflight for design and implementation plan
+- inline approval artifacts at `artifacts/reviews/design-review.md` and `artifacts/reviews/implementation-plan-review.md`
 - worker dispatch, launch, collection, retry, and review packets
@@ -83,11 +81,11 @@ - user decision gates
 2. If the repo is not initialized, stop at initialization guidance instead of forcing a goal.
-3. If the request is new complex work, derive a concise kebab-case goal name and create it with `ospec goal <goal-name> [path]`; for executable Codex work pass `--level L2|L3 --target codex --execution-model controller --harness-interactive true --native-subagents supported` so the persisted capability snapshot represents this IDE session.
+3. If the request is new complex work, derive a concise kebab-case goal name and create it with `ospec goal <goal-name> [path]`; in Codex pass `--target codex --execution-model controller --harness-interactive true --native-subagents supported` so the persisted capability snapshot represents this IDE session.
 4. If the matching active goal already exists, continue it instead of duplicating it.
 5. Draft or update `design.md` from the requirement, `proposal.md`, and project context before editing `implementation-plan.md`, deriving `artifacts/agents/task-graph.json`, editing `tasks.md`, or editing code.
 6. Draft or update `implementation-plan.md` from `design.md`; identify target files, expected results, verification commands, dependencies, parallelizable work, and conflicts.
-7. Derive `artifacts/agents/task-graph.json` from `implementation-plan.md`; give every task a `documentation_updates` array (`[]` when none), include every declared docs path in the same task's `target_files`, and require meaningful-change evidence from dispatch to completion; derive `tasks.md` from the task graph. Reviewed deletion is valid when completion evidence proves an existing baseline became missing. Across repair attempts, finalize compares the first baseline with the final completed state and requires the workspace to match the latest declared-owner evidence; do not restore a legitimately deleted document or rewrite history to satisfy archive. If controller closeout changes a declared path after the last worker dispatch, a later APPROVED task review may authorize the final state only when its executor provenance is valid and its target snapshot exactly matches the current path; it never replaces the meaningful-change chain. Run `ospec execute sync` after closeout so localized worker-status sections and checklists derive from authoritative review and verification state instead of manual edits. Mark every dependency/file-safe task `parallelizable: true`; every generated `parallelizable: false` task must include `serial_reason`, and `maxParallel=1` must include `maxParallelReason`. Split tasks with more than six `target_files`; when one atomic verification boundary genuinely requires that breadth, record a concrete `scope_reason`. Split implementation/automatic checks from external device, credential, third-party, or manual acceptance so an unavailable external gate cannot block unrelated implementation; downstream work may depend on the implementation slice, while the external acceptance remains a final hard gate. For L3 use `ospec loop allowlist derive/check/apply --from-task-graph` so exact paths and commands fail before expensive document reviewers run; never assume repeated configure calls append. Finalize also generates one indexed `docs/project/changes/<archive-path>.md` for this goal; its preflight refuses to overwrite a human-owned file at that path, and the generated summary does not replace required architecture, API, module, or operational documentation.
-8. Run `ospec execute doc-review [changes/active/<goal>] --stage design`. When it reports `Reused approval: yes`, do not launch another reviewer. Otherwise execute one fresh independent design reviewer through `dispatch.runtimeAdapter`, immediately claim its real executor id, wait for Markdown plus structured findings, then complete that executor. Approval must validate before plan review.
-9. Run `ospec execute doc-review [changes/active/<goal>] --stage plan`. Reuse a valid approval; otherwise execute one fresh independent plan reviewer through `dispatch.runtimeAdapter`, claim its real executor id, wait for findings, then complete it before worker dispatch. The controlling AI must not self-approve either review.
+7. Run `ospec execute preflight [changes/active/<goal>] --stage design`. It deterministically validates the current proposal/design context and records inline approval evidence. Resolve reported readiness errors in the authoritative documents; never launch a reviewer child for this stage.
+8. Run `ospec execute preflight [changes/active/<goal>] --stage plan`. It validates proposal/design/plan readiness plus the current design preflight and records inline approval evidence. Resolve reported readiness errors; never launch a reviewer child for this stage.
+9. After both preflights pass, derive `artifacts/agents/task-graph.json` from `implementation-plan.md`, then let Loop run the combined planning review before workspace or implementation dispatch. Give every task a `documentation_updates` array (`[]` when none), include every declared docs path in the same task's `target_files`, and require meaningful-change evidence from dispatch to completion; derive `tasks.md` from the task graph. Reviewed deletion is valid when completion evidence proves an existing baseline became missing. Across repair attempts, finalize compares the first baseline with the final completed state and requires the workspace to match the latest declared-owner evidence. Run `ospec execute sync` after closeout so status and checklists derive from authoritative state. Mark dependency/file-safe tasks `parallelizable: true`; a serial task must include `serial_reason`, and `maxParallel=1` must include `maxParallelReason`. Split broad tasks unless one atomic verification boundary requires the scope. Keep a red test with the implementation it validates. Separate implementation/automatic checks from external device, credential, third-party, or manual acceptance. Optional allowlists can be derived from the task graph when an extra boundary is requested. Finalize also generates one indexed `docs/project/changes/<archive-path>.md` for this goal.
 10. Use `ospec execute decision` for direction, architecture, API, UI, risk, or scope choices that need explicit user selection, and always include `--answered-by user` when persisting the user's answer. Persist every named browser/E2E/manual verification requirement before implementation.
-11. Use `ospec execute workspace`, `dispatch`, `launch`, `complete`, `review`, `feedback`, `repair`, `sync`, `tdd`, `debug`, and `verify` as needed for the full workflow. Run `ospec loop run <goal-path> --once --json`, dispatch every emitted packet through `runtimeAdapter.selected.nativeSubagent`, record completion/review evidence as each child finishes, and tick again without waiting for another user prompt. Never start Orca, Codex, Claude, or another agent CLI as a fallback. Model profiles are logical and resolve through `.skillrc.workflow.model_profiles`; `complete --usage-file` may record provider usage. Require reviewers to write Markdown plus sibling structured `*.findings.json`. If final review is `NEEDS_CHANGES`, create one grouped repair task instead of one worker per finding.
+11. Use `ospec execute workspace`, `dispatch`, `launch`, `complete`, `review`, `feedback`, `repair`, `sync`, `tdd`, `debug`, and `verify` as needed. Run `ospec loop run <goal-path> --once --compact-json`, dispatch every emitted packet through the selected model-native subagent, record evidence as each child finishes, and tick again without another user prompt. Never start another agent CLI as a fallback. Model profiles resolve through `.skillrc.workflow.model_profiles`; `complete --usage-file` may record provider usage. Require reviewers to write Markdown plus sibling structured `*.findings.json`. If final review is `NEEDS_CHANGES`, create one grouped repair task instead of one worker per finding.
 12. Do not archive while task graph status, task-level reviews, final reviews, worker status, required user decisions, document reviews, or verification evidence are incomplete during normal closeout.
@@ -104,9 +102,8 @@ 13. Use `ospec execute finish` before finalize when the goal used task graph execution or worktree planning.
 ospec status [path]
-ospec goal <goal-name> [path] [--flags flag1,flag2] [--level L1|L2|L3] [--target ...] [--execution-model controller] [--harness-interactive true|false] [--native-subagents supported|unknown|unsupported]
+ospec goal <goal-name> [path] [--flags flag1,flag2] [--target ...] [--execution-model controller] [--harness-interactive true|false] [--native-subagents supported|unknown|unsupported]
 ospec execute status [changes/active/<goal>] --brief
 ospec loop status [changes/active/<goal>]
 ospec loop status [changes/active/<goal>] --brief|--json
-ospec loop run [changes/active/<goal>] [--once] [--json]  # prefer JSON for runtime-adapter dispatch
+ospec loop run [changes/active/<goal>] [--once] [--compact-json]
 ospec loop tick-plan [changes/active/<goal>]
-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 --continue-while-progressing true --fresh-context true
@@ -130,10 +127,6 @@ ospec loop configure [changes/active/<goal>] --max-iterations N --budget-tokens N --budget-minutes N --expires-at <ISO-8601>
 ospec execute bootstrap [changes/active/<goal>]
-ospec execute doc-review [changes/active/<goal>] --stage design
-ospec execute doc-review [changes/active/<goal>] --stage plan
-ospec execute doc-review [changes/active/<goal>] --stage design|plan --claim-executor <executor-id>
-ospec execute doc-review [changes/active/<goal>] --stage design|plan --heartbeat-executor <child-id>
-ospec execute doc-review [changes/active/<goal>] --stage design|plan --complete-executor <child-id>
+ospec execute preflight [changes/active/<goal>] --stage design
+ospec execute preflight [changes/active/<goal>] --stage plan
 ospec execute decision [changes/active/<goal>] --id <id> --question "..." --option id:label:impact --required
 ospec execute decision [changes/active/<goal>] --id <id> --select <option-id> --answered-by user
-ospec execute decision [changes/active/<goal>] --id <id> --question "Allow one extra review round?" --option allow:Allow:impact --option stop:Stop:impact --required --document-review-stage design|plan --review-context-hash <sha256> --review-round <number> --review-approval-option allow
 ospec execute workspace [changes/active/<goal>]
@@ -140,0 +133,0 @@ ospec execute dispatch [changes/active/<goal>] [--task task-id] [--limit N]

assets/global-skills/codex/ospec-goal/skill.yaml

@@ -17,2 +17,2 @@ name: ospec-goal
 
-  default_prompt: "Use $ospec-goal to run a full IDE-controlled workflow: ask for L1/L2/L3, create work with ospec goal <goal-name> [path] and explicit controller capability flags, then dispatch every Loop action through spawn_agent + wait, persist heartbeat/result evidence, and keep ticking until done or genuinely blocked."
+  default_prompt: "Use $ospec-goal to run the fast quality workflow: create work with ospec goal <goal-name> [path] and explicit controller capability flags, run deterministic preflights and one combined planning review, then dispatch every Loop action through spawn_agent + bounded waits, persist evidence, and keep ticking until done or genuinely blocked."

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

@@ -44,3 +44,3 @@ ---
 - يجب اشتقاق `artifacts/agents/task-graph.json` من `implementation-plan.md`؛ ويجب أن تتضمن كل مهمة id والحالة والاعتماديات وسلامة التوازي والتعارضات والملفات المستهدفة وأوامر التحقق والنتيجة المتوقعة ودور worker. تتطلب المهام المتسلسلة المولدة `serial_reason`، وسجل `maxParallelReason` لحد worker واحد الصريح. قسّم task التي تتجاوز ستة targets أو سجّل `scope_reason` واضحاً لحد ذري واحد
-- في L3 اشتق وافحص وطبق allowlist الدقيقة من task graph باستخدام CAS وموافقة صريحة على التوسيع؛ خيارات configure المتكررة تستبدل ولا تضيف
+- allowlist الاختيارية حد إضافي؛ اشتق وافحص وطبق الصلاحيات الدقيقة من task graph باستخدام CAS وموافقة صريحة على التوسيع، وخيارات configure المتكررة تستبدل ولا تضيف
 - يجب اشتقاق `tasks.md` من `artifacts/agents/task-graph.json`؛ وإذا كانت `tasks.md` موجودة بينما الوثائق السابقة ما زالت قوالب، فحدّث الوثائق السابقة أولاً ثم وائم المهام
@@ -58,3 +58,4 @@ - في classic change تُشتق `tasks.md` مباشرة من `proposal.md` ونطاق التنفيذ
 - عند نقل change بين agents أو tools أو worktrees أو shells أو operators بشريين، استخدم `ospec execute handoff [changes/active/<change>] [--target codex|gpt|claude|gemini|opencode|cursor|copilot|shell|generic]` لكتابة `handoff.json` و`handoff.md`؛ يسجل هذا الأمر project session brief snapshot وtool mapping وقواعد السلامة فقط
-- قبل اشتقاق implementation tasks أو dispatch لها، استخدم `ospec execute doc-review [changes/active/<change>] [--stage design|plan]` لإنشاء packets تتضمن project session brief snapshot داخل `artifacts/agents/document-review-dispatches/` وتجهيز `artifacts/reviews/design-review.md` أو `artifacts/reviews/implementation-plan-review.md`؛ يجب اعتماد design review قبل dispatch لمراجعة implementation plan
+- قبل اشتقاق task graph، شغّل `ospec execute preflight [changes/active/<change>] --stage design` ثم `--stage plan` لإنشاء deterministic inline preflight packets وapproval artifacts. اشتق أو حدّث task graph بعد نجاح المرحلتين فقط، ولا تشغّل أي مرحلة reviewer child. اجمع red test العادي وproduction implementation ودليل green/refactor في atomic task واحدة
+- بعد اشتقاق task graph يجب أن يصدر Loop combined planning review مستقلة واحدة قبل workspace أو worker dispatch. يسمح بإصلاح تخطيط مجمّع واحد وfresh re-review واحدة فقط، ثم يتوقف بثبات عند تكرار الفشل
 - قبل handoff إلى worker استخدم `ospec execute workspace [changes/active/<change>]` لتسجيل سلامة git workspace في `artifacts/agents/workspace-status.json` (`workspace-status.json`)؛ يسمح Goal قائم فقط بالمسارات التابعة لأهداف task غير `PENDING`، أو ملف `tsconfig.tsbuildinfo` الدقيق داخل حزمة task بدأ فعلا وصرح بأمر build/typecheck، أو لإثبات `ospec update` حالي متحقق من الهاش، وتظهر أي مسارات أخرى بالحالة `needs_isolation`
@@ -77,3 +78,3 @@ - Use `ospec execute route [changes/active/<change>]` to write `workflow-route.json` and `workflow-route.md` with the next recommended OSpec command; this records workflow routing artifacts only and does not edit source files
 - بعد تشغيل project checks حديثة، استخدم `ospec execute verify [changes/active/<change>] --command "..." --status PASSED --exit-code 0` لتسجيل verification evidence داخل `artifacts/agents/verification-evidence.json`
-- `ospec session` و`ospec execute bootstrap` و`handoff` و`doc-review` و`workspace` وplan-mode `worktree` و`finish` و`dispatch` و`launch` و`collect` و`retry` و`complete` و`review` و`debug` و`tdd` و`verify` و`sync` تحدّث OSpec artifacts فقط؛ وباستثناء قراءة `workspace` و`worktree` و`finish` لحالة git، لا تحرر ملفات source في المشروع مباشرة. يوزّع controller الـ workers فقط عبر model-native subagent adapter المختار
+- `ospec session` و`ospec execute bootstrap` و`handoff` و`preflight` و`workspace` وplan-mode `worktree` و`finish` و`dispatch` و`launch` و`collect` و`retry` و`complete` و`review` و`debug` و`tdd` و`verify` و`sync` تحدّث OSpec artifacts فقط؛ وباستثناء قراءة `workspace` و`worktree` و`finish` لحالة git، لا تحرر ملفات source في المشروع مباشرة. يوزّع controller الـ workers فقط عبر model-native subagent adapter المختار
 - في goal لا تؤرشف عندما يحتوي task graph على حالات غير محسومة أو اعتماديات غير صالحة أو تفاصيل تنفيذ ناقصة أو عندما لا يكون `status` العلوي `completed`
@@ -89,3 +90,3 @@ - في goal يسجل `artifacts/agents/worker-status.md` حالات implementer وspec reviewer وquality reviewer وcontroller
 
-- حافظ على `proposal.md` و`design.md` و`implementation-plan.md` و`artifacts/agents/task-graph.json` و`artifacts/agents/bootstrap.md` و`artifacts/agents/handoff.md` و`artifacts/agents/document-review-dispatches/` و`artifacts/agents/launch-plan.md` و`artifacts/agents/worker-runs/` و`artifacts/agents/review-runs/` و`artifacts/agents/retries/` و`artifacts/agents/review-feedback-plan.md` و`tasks.md` و`artifacts/reviews/design-review.md` و`artifacts/reviews/implementation-plan-review.md` و`artifacts/reviews/final-review.md` و`artifacts/agents/worker-status.md` و`artifacts/agents/debug-evidence.json` و`verification.md` و`review.md` باللغة المعتمدة للمشروع
+- حافظ على `proposal.md` و`design.md` و`implementation-plan.md` و`artifacts/agents/task-graph.json` و`artifacts/agents/bootstrap.md` و`artifacts/agents/handoff.md` و`artifacts/agents/planning-preflights/` و`artifacts/agents/launch-plan.md` و`artifacts/agents/worker-runs/` و`artifacts/agents/review-runs/` و`artifacts/agents/retries/` و`artifacts/agents/review-feedback-plan.md` و`tasks.md` و`artifacts/reviews/design-review.md` و`artifacts/reviews/implementation-plan-review.md` و`artifacts/reviews/final-review.md` و`artifacts/agents/worker-status.md` و`artifacts/agents/debug-evidence.json` و`verification.md` و`review.md` باللغة المعتمدة للمشروع
 - قد تختلف لغة واجهة المنتج عن لغة وثائق OSpec الخاصة بالchange؛ لا تستنتج إحداهما من الأخرى
@@ -92,0 +93,0 @@ - إذا أُنشىء change بالصينية، فاستمر بالصينية ما لم تتطلب قواعد المشروع التحويل إلى الإنجليزية صراحةً

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

@@ -44,3 +44,3 @@ ---
 - Derive `artifacts/agents/task-graph.json` from `implementation-plan.md`; each task must include id, status, dependencies, parallel safety, conflicts, target files, verification commands, expected result, and worker role. Generated serial tasks also require `serial_reason`; record `maxParallelReason` for an explicit single-worker limit. Split tasks with more than six targets or record a concrete `scope_reason` for one atomic boundary
-- For L3 derive/check/apply the exact task-graph allowlist with CAS and explicit expansion approval; repeated configure flags replace rather than append
+- Optional configured allowlists are an extra boundary: derive/check/apply exact task-graph permissions with CAS and explicit expansion approval; repeated configure flags replace rather than append
 - Derive `tasks.md` from `artifacts/agents/task-graph.json`; if `tasks.md` exists while upstream docs are still templates, update upstream docs first and then reconcile tasks
@@ -58,3 +58,4 @@ - For classic changes, derive `tasks.md` directly from `proposal.md` and the implementation scope
 - When a change moves between agents, tools, worktrees, shells, or human operators, use `ospec execute handoff [changes/active/<change>] [--target codex|gpt|claude|gemini|opencode|cursor|copilot|shell|generic]` to write `handoff.json` and `handoff.md`; this records the project session brief snapshot, target tool mapping, and safety rules only
-- Before deriving or dispatching implementation tasks, use `ospec execute doc-review [changes/active/<change>] [--stage design|plan]` to create `artifacts/agents/document-review-dispatches/` packets with the project session brief snapshot plus `artifacts/reviews/design-review.md` or `artifacts/reviews/implementation-plan-review.md`; design review must be approved before implementation plan review
+- Before deriving the task graph, run `ospec execute preflight [changes/active/<change>] --stage design`, then `--stage plan`, to create deterministic inline preflight packets and approval artifacts. Derive or refresh the task graph only after both pass; neither stage launches a reviewer child. Keep ordinary red tests with their production implementation and green/refactor evidence in one atomic task
+- After task graph derivation, Loop must issue one independent combined planning review before workspace or worker dispatch. One grouped planning repair and one fresh re-review are the maximum; repeated failure stops stably
 - Before worker handoff, use `ospec execute workspace [changes/active/<change>]` to record git workspace safety in `artifacts/agents/workspace-status.json` (`workspace-status.json`); existing Goals may retain only dirty paths owned by non-`PENDING` task targets, exact package-local `tsconfig.tsbuildinfo` derived from a started task's declared build/typecheck verification, or current hash-verified `ospec update` provenance, and every other dirty path reports `needs_isolation`
@@ -77,3 +78,3 @@ - Use `ospec execute route [changes/active/<change>]` to write `workflow-route.json` and `workflow-route.md` with the next recommended OSpec command; this records workflow routing artifacts only and does not edit source files
 - Use `ospec execute verify [changes/active/<change>] --command "..." --status PASSED --exit-code 0` after fresh project checks to record verification evidence under `artifacts/agents/verification-evidence.json`
-- `ospec session` and `ospec execute bootstrap`, `handoff`, `doc-review`, `workspace`, plan-mode `worktree`, `finish`, `dispatch`, `launch`, `collect`, `retry`, `complete`, `review`, `debug`, `tdd`, `verify`, and `sync` update OSpec artifacts only; except for `workspace`, `worktree`, and `finish` reading git state, they do not edit project source files directly. The controller dispatches workers only through the selected model-native subagent adapter
+- `ospec session` and `ospec execute bootstrap`, `handoff`, `preflight`, `workspace`, plan-mode `worktree`, `finish`, `dispatch`, `launch`, `collect`, `retry`, `complete`, `review`, `debug`, `tdd`, `verify`, and `sync` update OSpec artifacts only; except for `workspace`, `worktree`, and `finish` reading git state, they do not edit project source files directly. The controller dispatches workers only through the selected model-native subagent adapter
 - Do not archive while task graph statuses are unresolved, dependencies are invalid, execution details are missing, or top-level `status` is not `completed`
@@ -87,3 +88,3 @@ - `artifacts/agents/worker-status.md` records implementer, spec reviewer, quality reviewer, and controller statuses
 
-- Keep `proposal.md`, `design.md`, `implementation-plan.md`, `artifacts/agents/task-graph.json`, `artifacts/agents/bootstrap.md`, `artifacts/agents/handoff.md`, `artifacts/agents/document-review-dispatches/`, `artifacts/agents/launch-plan.md`, `artifacts/agents/worker-runs/`, `artifacts/agents/review-runs/`, `artifacts/agents/retries/`, `artifacts/agents/review-feedback-plan.md`, `tasks.md`, `artifacts/reviews/design-review.md`, `artifacts/reviews/implementation-plan-review.md`, `artifacts/reviews/final-review.md`, `artifacts/agents/worker-status.md`, `artifacts/agents/debug-evidence.json`, `verification.md`, and `review.md` in the project-adopted document language
+- Keep `proposal.md`, `design.md`, `implementation-plan.md`, `artifacts/agents/task-graph.json`, `artifacts/agents/bootstrap.md`, `artifacts/agents/handoff.md`, `artifacts/agents/planning-preflights/`, `artifacts/agents/launch-plan.md`, `artifacts/agents/worker-runs/`, `artifacts/agents/review-runs/`, `artifacts/agents/retries/`, `artifacts/agents/review-feedback-plan.md`, `tasks.md`, `artifacts/reviews/design-review.md`, `artifacts/reviews/implementation-plan-review.md`, `artifacts/reviews/final-review.md`, `artifacts/agents/worker-status.md`, `artifacts/agents/debug-evidence.json`, `verification.md`, and `review.md` in the project-adopted document language
 - Product UI language may differ from the OSpec change-document language; do not infer one from the other
@@ -90,0 +91,0 @@ - If a change was created in Chinese, continue updating it in Chinese unless project rules explicitly require a switch to English

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

@@ -44,3 +44,3 @@ ---
 - `artifacts/agents/task-graph.json` は `implementation-plan.md` から導く。各 task には id、状態、依存関係、並行安全性、競合、対象ファイル、検証コマンド、期待結果、worker role を含める。生成した serial task には `serial_reason` も必要で、明示的な single-worker limit には `maxParallelReason` を記録する。6 個を超える target を持つ task は分割するか、atomic boundary の具体的な `scope_reason` を記録する
-- L3 では task graph から exact allowlist を CAS と明示的な expansion approval で derive/check/apply する。configure flag の反復は append ではなく replace である
+- optional allowlist は追加境界であり、task graph から exact permissions を CAS と明示的な expansion approval で derive/check/apply する。configure flag の反復は append ではなく replace である
 - `tasks.md` は `artifacts/agents/task-graph.json` から導く。`tasks.md` が既にあり上流文書がテンプレートのままなら、先に上流文書を更新してから tasks を整合させる
@@ -58,3 +58,4 @@ - classic change では `tasks.md` を `proposal.md` と実装範囲から直接導く
 - change を agent、tool、worktree、shell、human operator の間で引き渡すときは、`ospec execute handoff [changes/active/<change>] [--target codex|gpt|claude|gemini|opencode|cursor|copilot|shell|generic]` で `handoff.json` と `handoff.md` を書く。このコマンドは project session brief snapshot、target tool mapping、safety rules のみを記録する
-- implementation tasks を導出または dispatch する前に、`ospec execute doc-review [changes/active/<change>] [--stage design|plan]` で project session brief snapshot を含む `artifacts/agents/document-review-dispatches/` packet と `artifacts/reviews/design-review.md` または `artifacts/reviews/implementation-plan-review.md` を作成する。design review 承認後に implementation plan review を dispatch する
+- task graph 導出前に `ospec execute preflight [changes/active/<change>] --stage design`、続いて `--stage plan` を実行し、deterministic inline preflight packet と approval artifact を作成する。両方の通過後に task graph を導出または更新し、どちらの stage も reviewer child を起動しない。通常の red test、production implementation、green/refactor evidence は 1 つの atomic task にまとめる
+- task graph 導出後、workspace または worker dispatch より前に Loop が独立 combined planning review を 1 回発行する。grouped planning repair と fresh re-review は各 1 回までで、再失敗は安定して停止する
 - worker handoff の前に `ospec execute workspace [changes/active/<change>]` で git workspace safety を `artifacts/agents/workspace-status.json`（`workspace-status.json`）に記録する。既存 Goal では、非 `PENDING` task の target file、開始済み task の宣言済み build/typecheck 検証から導出される package-local の exact `tsconfig.tsbuildinfo`、または現在のハッシュ検証済み `ospec update` provenance に属する dirty path だけを許可し、それ以外は `needs_isolation` を示す
@@ -77,3 +78,3 @@ - Use `ospec execute route [changes/active/<change>]` to write `workflow-route.json` and `workflow-route.md` with the next recommended OSpec command; this records workflow routing artifacts only and does not edit source files
 - fresh project checks を実行した後、`ospec execute verify [changes/active/<change>] --command "..." --status PASSED --exit-code 0` で `artifacts/agents/verification-evidence.json` に verification evidence を記録する
-- `ospec session` と `ospec execute bootstrap`、`handoff`、`doc-review`、`workspace`、plan-mode `worktree`、`finish`、`dispatch`、`launch`、`collect`、`retry`、`complete`、`review`、`debug`、`tdd`、`verify`、`sync` は OSpec artifacts のみを更新する。`workspace`、`worktree`、`finish` が git state を読む場合を除き、project source file は直接編集しない。controller は選択された model-native subagent adapter だけで worker を dispatch する
+- `ospec session` と `ospec execute bootstrap`、`handoff`、`preflight`、`workspace`、plan-mode `worktree`、`finish`、`dispatch`、`launch`、`collect`、`retry`、`complete`、`review`、`debug`、`tdd`、`verify`、`sync` は OSpec artifacts のみを更新する。`workspace`、`worktree`、`finish` が git state を読む場合を除き、project source file は直接編集しない。controller は選択された model-native subagent adapter だけで worker を dispatch する
 - goal では task graph に未解決状態、無効な依存関係、不足した実行詳細、またはトップレベル `status` が `completed` でない状態がある場合は archive しない
@@ -89,3 +90,3 @@ - goal では `artifacts/agents/worker-status.md` が implementer、spec reviewer、quality reviewer、controller の状態を記録する
 
-- `proposal.md`、`design.md`、`implementation-plan.md`、`artifacts/agents/task-graph.json`、`artifacts/agents/bootstrap.md`、`artifacts/agents/handoff.md`、`artifacts/agents/document-review-dispatches/`、`artifacts/agents/launch-plan.md`、`artifacts/agents/worker-runs/`、`artifacts/agents/review-runs/`、`artifacts/agents/retries/`、`artifacts/agents/review-feedback-plan.md`、`tasks.md`、`artifacts/reviews/design-review.md`、`artifacts/reviews/implementation-plan-review.md`、`artifacts/reviews/final-review.md`、`artifacts/agents/worker-status.md`、`artifacts/agents/debug-evidence.json`、`verification.md`、`review.md` はプロジェクト採用文書言語で維持する
+- `proposal.md`、`design.md`、`implementation-plan.md`、`artifacts/agents/task-graph.json`、`artifacts/agents/bootstrap.md`、`artifacts/agents/handoff.md`、`artifacts/agents/planning-preflights/`、`artifacts/agents/launch-plan.md`、`artifacts/agents/worker-runs/`、`artifacts/agents/review-runs/`、`artifacts/agents/retries/`、`artifacts/agents/review-feedback-plan.md`、`tasks.md`、`artifacts/reviews/design-review.md`、`artifacts/reviews/implementation-plan-review.md`、`artifacts/reviews/final-review.md`、`artifacts/agents/worker-status.md`、`artifacts/agents/debug-evidence.json`、`verification.md`、`review.md` はプロジェクト採用文書言語で維持する
 - 製品 UI 言語と OSpec change 文書言語は異なってよく、片方からもう片方を推測しない
@@ -92,0 +93,0 @@ - change が中国語で作成されている場合は、プロジェクトルールが明示的に英語切り替えを要求しない限り中国語で継続する

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

@@ -44,3 +44,3 @@ ---
 - `artifacts/agents/task-graph.json` 必须从 `implementation-plan.md` 推导；每个 task 必须包含 id、状态、依赖、并行安全性、冲突、目标文件、验证命令、预期结果和 worker 角色。生成的串行 task 还必须包含 `serial_reason`；显式限制为单 worker 时记录 `maxParallelReason`。超过六个目标的 task 必须拆分，或用具体的 `scope_reason` 说明其原子边界
-- L3 使用 CAS 和显式扩权确认从任务图 derive/check/apply 精确白名单；重复 configure 参数是替换而非追加
+- 可选白名单是额外边界：使用 CAS 和显式扩权确认从任务图 derive/check/apply 精确权限；重复 configure 参数是替换而非追加
 - `tasks.md` 必须从 `artifacts/agents/task-graph.json` 推导；若 `tasks.md` 已存在但上游文档仍是模板，先补上游文档再对齐任务
@@ -58,3 +58,4 @@ - 执行经典 change 时，`tasks.md` 直接从 `proposal.md` 和实现范围推导
 - change 需要在 agent、工具、worktree、shell 或人工操作者之间交接时，用 `ospec execute handoff [changes/active/<change>] [--target codex|gpt|claude|gemini|opencode|cursor|copilot|shell|generic]` 写入 `handoff.json` 和 `handoff.md`；该命令只记录 project session brief snapshot、目标工具映射和安全规则
-- 推导或派发实现任务前，用 `ospec execute doc-review [changes/active/<change>] [--stage design|plan]` 生成带 project session brief snapshot 的 `artifacts/agents/document-review-dispatches/` 交接包，并创建 `artifacts/reviews/design-review.md` 或 `artifacts/reviews/implementation-plan-review.md`；design review 通过后才能派发 implementation plan review
+- 派生 task graph 前，依次运行 `ospec execute preflight [changes/active/<change>] --stage design` 和 `--stage plan`，生成确定性 inline preflight packet 与 approval artifacts；两步通过后再派生或刷新 task graph，任何阶段都不启动 reviewer child。普通 red test、对应生产实现和 green/refactor 证据应放在同一个原子 task
+- task graph 派生后，Loop 必须在 workspace 或 worker 派发前执行一次独立 combined planning review。最多允许一次整体规划修复和一次 fresh re-review；重复失败必须稳定停止
 - 派发 worker 前，用 `ospec execute workspace [changes/active/<change>]` 在 `artifacts/agents/workspace-status.json`（`workspace-status.json`）中记录 git 工作区安全状态；已有 Goal 只允许非 `PENDING` 任务目标文件、由已启动任务声明的 build/typecheck 验证精确派生且位于其包内的 `tsconfig.tsbuildinfo`，或当前哈希校验通过的 `ospec update` 证明所归属的脏路径，其余脏路径显示 `needs_isolation`
@@ -77,3 +78,3 @@ - 需要把下一条 OSpec 命令持久化给人或 AI 接手时，用 `ospec execute route [changes/active/<change>]` 写入 `workflow-route.json` 和 `workflow-route.md`；该命令只记录 workflow routing artifacts，不会编辑源码
 - 运行最新项目检查后，用 `ospec execute verify [changes/active/<change>] --command "..." --status PASSED --exit-code 0` 在 `artifacts/agents/verification-evidence.json` 下记录验证证据
-- `ospec session` 以及 `ospec execute bootstrap`、`handoff`、`doc-review`、`workspace`、plan 模式 `worktree`、`finish`、`dispatch`、`launch`、`collect`、`retry`、`complete`、`review`、`debug`、`tdd`、`verify` 与 `sync` 只更新 OSpec artifacts；除 `workspace`、`worktree` 与 `finish` 会读取 git 状态外，不直接编辑项目源码。controller 只通过所选 model-native subagent adapter 派发 worker
+- `ospec session` 以及 `ospec execute bootstrap`、`handoff`、`preflight`、`workspace`、plan 模式 `worktree`、`finish`、`dispatch`、`launch`、`collect`、`retry`、`complete`、`review`、`debug`、`tdd`、`verify` 与 `sync` 只更新 OSpec artifacts；除 `workspace`、`worktree` 与 `finish` 会读取 git 状态外，不直接编辑项目源码。controller 只通过所选 model-native subagent adapter 派发 worker
 - task graph 存在未解决状态、无效依赖、缺失执行细节，或顶层 `status` 不是 `completed` 时不得归档
@@ -87,3 +88,3 @@ - `artifacts/agents/worker-status.md` 记录 implementer、spec reviewer、quality reviewer 和 controller 状态
 
-- 项目采用中文 protocol 时，`proposal.md`、`design.md`、`implementation-plan.md`、`artifacts/agents/task-graph.json`、`artifacts/agents/bootstrap.md`、`artifacts/agents/handoff.md`、`artifacts/agents/document-review-dispatches/`、`artifacts/agents/launch-plan.md`、`artifacts/agents/worker-runs/`、`artifacts/agents/review-runs/`、`artifacts/agents/retries/`、`artifacts/agents/review-feedback-plan.md`、`tasks.md`、`artifacts/reviews/design-review.md`、`artifacts/reviews/implementation-plan-review.md`、`artifacts/reviews/final-review.md`、`artifacts/agents/worker-status.md`、`artifacts/agents/debug-evidence.json`、`verification.md`、`review.md` 必须保持中文
+- 项目采用中文 protocol 时，`proposal.md`、`design.md`、`implementation-plan.md`、`artifacts/agents/task-graph.json`、`artifacts/agents/bootstrap.md`、`artifacts/agents/handoff.md`、`artifacts/agents/planning-preflights/`、`artifacts/agents/launch-plan.md`、`artifacts/agents/worker-runs/`、`artifacts/agents/review-runs/`、`artifacts/agents/retries/`、`artifacts/agents/review-feedback-plan.md`、`tasks.md`、`artifacts/reviews/design-review.md`、`artifacts/reviews/implementation-plan-review.md`、`artifacts/reviews/final-review.md`、`artifacts/agents/worker-status.md`、`artifacts/agents/debug-evidence.json`、`verification.md`、`review.md` 必须保持中文
 - 产品界面语言可以按业务使用英文，但不得把产品语言自动映射为 OSpec change 文档语言
@@ -90,0 +91,0 @@ - 若当前 change 文档已用中文创建，后续更新必须延续中文，除非项目规则显式要求切换为英文

dist/cli.js

@@ -65,3 +65,3 @@ #!/usr/bin/env node
 const services_1 = require("./services");
-const CLI_VERSION = '1.8.23';
+const CLI_VERSION = '1.9.0';
 function showInitUsage() {
@@ -230,3 +230,3 @@ console.log('Usage: ospec init [root-dir] [--summary "..."] [--tech-stack node,react] [--architecture "..."] [--document-language en-US|zh-CN|ja-JP|ar]');
     return commandName === 'goal'
-        ? 'Usage: ospec goal <goal-name> [root-dir] [--flags flag1,flag2] [--level L1|L2|L3] [--target codex|gpt|claude|gemini|opencode|cursor|copilot] [--execution-model controller] [--harness-interactive true|false] [--native-subagents supported|unknown|unsupported] [--native-goal supported|unknown|unsupported]'
+        ? 'Usage: ospec goal <goal-name> [root-dir] [--flags flag1,flag2] [--target codex|gpt|claude|gemini|opencode|cursor|copilot] [--execution-model controller] [--harness-interactive true|false] [--native-subagents supported|unknown|unsupported] [--native-goal supported|unknown|unsupported]'
         : `Usage: ospec ${commandName} <change-name> [root-dir] [--flags flag1,flag2]`;
@@ -238,3 +238,2 @@ }
     const flags = [];
-    let level;
     let target;
@@ -261,24 +260,2 @@ let executionModel;
         }
-        const levelValue = arg === '--level'
-            ? commandArgs[index + 1]
-            : arg.startsWith('--level=')
-                ? arg.slice('--level='.length)
-                : undefined;
-        if (levelValue !== undefined) {
-            if (commandName !== 'goal') {
-                console.error(`Unknown option for ${commandName}: --level (only valid for ospec goal)`);
-                console.error(getNewLikeUsage(commandName));
-                process.exit(1);
-            }
-            const normalizedLevel = String(levelValue || '').trim().toUpperCase();
-            if (normalizedLevel !== 'L1' && normalizedLevel !== 'L2' && normalizedLevel !== 'L3') {
-                console.error(`Invalid --level value for goal: ${levelValue || '(empty)'} (expected L1, L2, or L3)`);
-                process.exit(1);
-            }
-            level = normalizedLevel;
-            if (arg === '--level') {
-                index += 1;
-            }
-            continue;
-        }
         const goalOnlyValue = (flag) => arg === flag
@@ -371,3 +348,2 @@ ? commandArgs[index + 1]
         flags: Array.from(new Set(flags)),
-        level,
         target,
@@ -417,7 +393,6 @@ executionModel,
                 }
-                const { featureName, rootDir, flags, level, target, executionModel, harnessInteractive, nativeSubagentCapability, nativeGoalCapability, } = parseNewCommandArgs(commandArgs, 'goal');
+                const { featureName, rootDir, flags, target, executionModel, harnessInteractive, nativeSubagentCapability, nativeGoalCapability, } = parseNewCommandArgs(commandArgs, 'goal');
                 const goalCmd = new GoalCommand_1.GoalCommand();
                 await goalCmd.execute(featureName, rootDir, {
                     flags,
-                    level,
                     target,
@@ -598,3 +573,3 @@ executionModel,
   run [action] [path]       Explicit queue runner helpers (start, status, step, resume, stop)
-  execute [action] [path]   Task graph controller helpers (bootstrap, handoff, doc-review, status, next, workspace, worktree, finish, dispatch, launch, complete, repair)
+  execute [action] [path]   Task graph controller helpers (bootstrap, handoff, preflight, status, next, workspace, worktree, finish, dispatch, launch, complete, repair)
   loop [action] [path]      Goal loop controller (run/tick, status, heartbeat, result, recover, configure, pause, resume)
@@ -619,3 +594,3 @@ triage [action] [path]    Triage inbox helpers (list, claim, promote)
   ospec goal billing-refactor . --flags complex_feature,multi_file_change
-  ospec goal billing-refactor . --level L2 --target codex --execution-model controller --harness-interactive true --native-subagents supported
+  ospec goal billing-refactor . --target codex --execution-model controller --harness-interactive true --native-subagents supported
   ospec brainstorm . --topic "Improve onboarding conversion" --change onboarding-flow
@@ -642,3 +617,3 @@ ospec brainstorm . --topic "Explore dashboard UX" --visual
   ospec execute handoff ./changes/active/onboarding-flow --target codex
-  ospec execute doc-review ./changes/active/onboarding-flow --stage design
+  ospec execute preflight ./changes/active/onboarding-flow --stage design
   ospec execute next ./changes/active/onboarding-flow
@@ -645,0 +620,0 @@ ospec execute workspace ./changes/active/onboarding-flow

dist/commands/ExecuteCommand.d.ts

@@ -10,3 +10,3 @@ import { TaskDocumentReviewStage, TaskHandoffTarget, TaskWorkerToolTarget, TaskUserDecisionOption } from '../services/TaskGraphExecutionService';
     private handoff;
-    private docReview;
+    private preflight;
     private next;
@@ -93,6 +93,2 @@ private route;
         stage?: TaskDocumentReviewStage;
-        claimExecutor?: string;
-        heartbeatExecutor?: string;
-        completeExecutor?: string;
-        usageFile?: string;
         force?: boolean;
@@ -119,9 +115,2 @@ };
         answeredBy?: 'user';
-        documentReviewOverride?: {
-            stage: TaskDocumentReviewStage;
-            reviewContextHash: string;
-            round: number;
-            extraRounds: 1;
-            approvalOptionId: string;
-        };
     };
@@ -128,0 +117,0 @@ private parseDecisionOption;

dist/commands/LoopCommand.d.ts

@@ -5,2 +5,3 @@ import { BaseCommand } from './BaseCommand';
     private run;
+    private compactTickResult;
     private tickPlan;
@@ -14,3 +15,2 @@ private watch;
     private resume;
-    private level;
     private configure;
@@ -17,0 +17,0 @@ private allowlist;

dist/commands/LoopCommand.js

@@ -42,3 +42,3 @@ "use strict";
 const BaseCommand_1 = require("./BaseCommand");
-const LOOP_ACTIONS = ['run', 'tick', 'watch', 'status', 'pause', 'resume', 'level', 'configure', 'allowlist', 'tick-plan', 'heartbeat', 'result', 'finalize', 'recover'];
+const LOOP_ACTIONS = ['run', 'tick', 'watch', 'status', 'pause', 'resume', 'configure', 'allowlist', 'tick-plan', 'heartbeat', 'result', 'finalize', 'recover'];
 class LoopCommand extends BaseCommand_1.BaseCommand {
@@ -68,5 +68,2 @@ async execute(action = 'status', ...args) {
                     return;
-                case 'level':
-                    await this.level(args);
-                    return;
                 case 'configure':
@@ -91,3 +88,3 @@ await this.configure(args);
                 default:
-                    this.info(`Usage: ospec loop <${LOOP_ACTIONS.join('|')}> [path] [--level L1|L2|L3]`);
+                    this.info(`Usage: ospec loop <${LOOP_ACTIONS.join('|')}> [path]`);
             }
@@ -101,3 +98,3 @@ }
     async run(args) {
-        const inputPath = this.parseOptionalPath(args, [], ['--once', '--json']);
+        const inputPath = this.parseOptionalPath(args, [], ['--once', '--json', '--compact-json']);
         const changePath = await this.resolveChangePath(inputPath);
@@ -110,4 +107,4 @@ const project = await this.resolveProjectRoot(changePath);
         });
-        if (args.includes('--json')) {
-            console.log(JSON.stringify(result, null, 2));
+        if (args.includes('--json') || args.includes('--compact-json')) {
+            console.log(JSON.stringify(args.includes('--compact-json') ? this.compactTickResult(result) : result, null, 2));
             return;
@@ -152,2 +149,49 @@ }
     }
+    compactTickResult(result) {
+        const pending = result.pending
+            ? {
+                actionId: result.pending.actionId,
+                kind: result.pending.kind,
+                status: result.pending.status,
+                issuedAt: result.pending.issuedAt,
+                executorCompletedAt: result.pending.executorCompletedAt || null,
+                executorSucceeded: result.pending.executorSucceeded ?? null,
+                itemStates: result.pending.itemStates || [],
+            }
+            : null;
+        const actions = (result.actions || []).map((action) => ({
+            id: action.id,
+            kind: action.kind,
+            taskId: action.taskId,
+            role: action.role,
+            target: action.target,
+            packetPath: action.packetPath,
+            prompt: action.prompt,
+            completionCommand: action.completionCommand,
+            heartbeatCommand: action.heartbeatCommand,
+            resultCommand: action.resultCommand,
+            expectedEvidencePath: action.expectedEvidencePath,
+            usageKey: action.usageKey || null,
+            tokenAllowance: action.tokenAllowance ?? null,
+            heartbeatDueAt: action.heartbeatDueAt || null,
+            absoluteExpiresAt: action.absoluteExpiresAt || null,
+            runtimeAdapterId: action.runtimeAdapter?.selectedAdapterId || null,
+        }));
+        return {
+            version: '1.9.0',
+            changePath: result.changePath,
+            iteration: result.iteration,
+            status: result.status,
+            currentStep: result.currentStep,
+            verifyPassed: result.verifyPassed,
+            stopped: result.stopped,
+            stopReason: result.stopReason,
+            feedback: result.feedback,
+            nextInstruction: result.nextInstruction,
+            metrics: result.metrics,
+            pending,
+            actions,
+            batchDiagnostics: result.batchDiagnostics,
+        };
+    }
     async tickPlan(inputPath) {
@@ -229,5 +273,5 @@ const changePath = await this.resolveChangePath(inputPath);
         const state = await services_1.services.loopService.readState(changePath);
-        const reviewGovernance = await services_1.services.taskGraphExecutionService.readDocumentReviewGovernanceSummary(changePath);
+        const planningDecision = await services_1.services.taskGraphExecutionService.readValidatedPlanningReviewDecision(changePath);
         if (args.includes('--json')) {
-            console.log(JSON.stringify({ version: '1.8.6', changePath, config, state, reviewGovernance }, null, 2));
+            console.log(JSON.stringify({ version: '1.9.0', changePath, config, state, planningDecision }, null, 2));
             return;
@@ -243,7 +287,3 @@ }
             const batch = state.lastBatchDiagnostics;
-            const review = ['design', 'plan'].map(stage => {
-                const summary = reviewGovernance.stages[stage];
-                return `${stage}=${summary.completedRounds}/${summary.continueWhileProgressing ? 'progress' : summary.guardLimits.maxCompletedRounds}${summary.activeRound ? `+active:${summary.activeRound}` : ''}`;
-            }).join(' ');
-            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(`Loop ${state.status}: workflow=fast-quality 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'} planning=${planningDecision} pending=${pending?.items?.length || 0} heartbeat-due=${nextHeartbeat || 'none'}`);
             return;
@@ -254,3 +294,3 @@ }
         console.log(`Change path: ${changePath}`);
-        console.log(`Level: ${config.level}`);
+        console.log('Workflow: fast quality');
         console.log(`Primitive: ${config.primitive}`);
@@ -277,6 +317,3 @@ console.log(`Target: ${config.target}`);
         }
-        for (const stage of ['design', 'plan']) {
-            const review = reviewGovernance.stages[stage];
-            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'}`);
-        }
+        console.log(`Combined planning review: ${planningDecision}`);
         if (state.lastFeedback)
@@ -300,33 +337,2 @@ console.log(`Last feedback: ${state.lastFeedback}`);
     }
-    async level(args) {
-        let inputPath;
-        let level;
-        for (let index = 0; index < args.length; index += 1) {
-            const arg = args[index];
-            if (arg === '--level') {
-                level = args[index + 1];
-                index += 1;
-                continue;
-            }
-            if (arg.startsWith('--level=')) {
-                level = arg.slice('--level='.length);
-                continue;
-            }
-            if (!arg.startsWith('--') && /^L[123]$/i.test(arg) && !level) {
-                level = arg;
-                continue;
-            }
-            if (!arg.startsWith('--') && !inputPath) {
-                inputPath = arg;
-                continue;
-            }
-        }
-        const normalized = String(level || '').trim().toUpperCase();
-        if (normalized !== 'L1' && normalized !== 'L2' && normalized !== 'L3') {
-            throw new Error(`Loop level must be L1, L2, or L3 (received ${level || '(empty)'}).`);
-        }
-        const changePath = await this.resolveChangePath(inputPath);
-        const config = await services_1.services.loopService.setLevel(changePath, normalized);
-        this.success(`Loop level set to ${config.level}.`);
-    }
     async configure(args) {
@@ -333,0 +339,0 @@ const inputPath = args[0] && !args[0].startsWith('--') ? args[0] : undefined;

dist/commands/NewCommand.d.ts

@@ -6,3 +6,2 @@ import { BaseCommand } from './BaseCommand';
 import type { TaskWorkerToolTarget } from '../services/TaskGraphExecutionService';
-export type LoopSafetyLevel = 'L1' | 'L2' | 'L3';
 export interface NewCommandOptions {
@@ -13,4 +12,2 @@ flags?: string[];
     workflowProfile?: WorkflowProfileId;
-    /** Loop safety level for goal-profile changes (Stage B writes it into loop.json). */
-    level?: LoopSafetyLevel;
     /** Current IDE/harness target. This identifies an adapter; it does not imply capabilities. */
@@ -17,0 +14,0 @@ target?: TaskWorkerToolTarget;

dist/commands/NewCommand.js

@@ -159,3 +159,2 @@ "use strict";
                 const loopConfig = await services_1.services.loopService.scaffold(featureDir, {
-                    level: options.level,
                     primitive: 'goal',
@@ -168,9 +167,6 @@ target: options.target,
                 });
-                this.info(`  Loop initialized: level ${loopConfig.level}, primitive ${loopConfig.primitive}, ${loopConfig.executionModel} (${loopConfig.schedule.lifecycle})`);
-                if (loopConfig.level === 'L1') {
-                    this.info('  L1 is report-only and will not launch implementation, review, or verification subagents. For executable work, the controlling AI must present the safety-level decision and the user must choose L2 or L3.');
-                }
-                else if (loopConfig.executionModel === 'controller' && loopConfig.capability?.controllerAvailable) {
+                this.info(`  Loop initialized: fast quality workflow, primitive ${loopConfig.primitive}, ${loopConfig.executionModel} (${loopConfig.schedule.lifecycle})`);
+                if (loopConfig.executionModel === 'controller' && loopConfig.capability?.controllerAvailable) {
                     const controllerCommand = (0, helpers_1.formatCliCommand)('ospec', 'loop', 'run', featureDir, '--once', '--json');
-                    this.info(`  IDE controller handoff: keep this AI session active. After required decisions, independent document reviews, and workspace gates are ready, run "${controllerCommand}"; for every non-empty actions[] batch launch one fresh IDE-native subagent per item, wait for all results, record each completionCommand/evidence, and tick again immediately. When actions[] is empty and pending is present, observe only and never relaunch it. Return only on a real gate, paused/stopped/done, or explicit user pause.`);
+                    this.info(`  IDE controller handoff: keep this AI session active. After required decisions, inline planning preflights, task graph derivation, and workspace gates are ready, run "${controllerCommand}"; for every non-empty actions[] batch launch one fresh IDE-native subagent per item, wait for all results, record each completionCommand/evidence, and tick again immediately. When actions[] is empty and pending is present, observe only and never relaunch it. Return only on a real gate, paused/stopped/done, or explicit user pause.`);
                 }
@@ -177,0 +173,0 @@ else {

dist/core/types.d.ts

@@ -5,3 +5,2 @@ export type ProjectMode = 'lite' | 'standard' | 'full';
 export type HookCheckPolicy = 'off' | 'warn' | 'error';
-export type DocumentReviewPolicy = 'always' | 'adaptive';
 export type AgentModelProfileId = 'mechanical' | 'standard' | 'strong_reasoning' | 'review' | 'final_review';
@@ -143,3 +142,2 @@ export interface AgentModelProfileConfig {
         };
-        document_review_policy?: DocumentReviewPolicy;
         model_profiles?: Partial<Record<AgentModelProfileId, AgentModelProfileConfig>>;
@@ -146,0 +144,0 @@ };

dist/services/ConfigManager.js

@@ -70,3 +70,2 @@ "use strict";
         ...value,
-        document_review_policy: workflow.document_review_policy === 'adaptive' ? 'adaptive' : 'always',
         model_profiles: modelProfiles,
@@ -73,0 +72,0 @@ });

dist/services/LoopService.d.ts

@@ -7,7 +7,6 @@ import { FileService } from './FileService';
 import { TaskGraphExecutionService, TaskVerificationLoopBinding, TaskWorkerToolTarget } from './TaskGraphExecutionService';
-export type LoopSafetyLevel = 'L1' | 'L2' | 'L3';
 export type LoopStatus = 'idle' | 'running' | 'blocked' | 'paused' | 'stopped' | 'done';
 /** `cli-driven` is retained only so callers can receive a migration error. */
 export type LoopExecutionModel = 'controller' | 'cli-driven';
-export type LoopActionKind = 'implementation' | 'task-review' | 'final-review' | 'verification' | 'legacy';
+export type LoopActionKind = 'implementation' | 'planning-review' | 'planning-repair' | 'task-review' | 'final-review' | 'verification';
 export interface LoopStopConditions {
@@ -155,3 +154,2 @@ testCommands: string[];
     primitive: TaskAgentPrimitive;
-    level: LoopSafetyLevel;
     executionModel: LoopExecutionModel;
@@ -163,3 +161,2 @@ target: TaskWorkerToolTarget;
     efficiency: LoopEfficiency;
-    documentReviewGovernance?: LoopDocumentReviewGovernance;
     capability: HarnessCapability | null;
@@ -169,15 +166,2 @@ nativeHarnessMetadata?: RuntimeNativeHarnessExecutionMetadata | null;
 }
-export interface LoopDocumentReviewGovernanceStage {
-    maxCompletedRounds: number;
-    maxMinutes: number;
-    budgetTokens: number | null;
-}
-export interface LoopDocumentReviewGovernance {
-    stages: {
-        design: LoopDocumentReviewGovernanceStage;
-        plan: LoopDocumentReviewGovernanceStage;
-    };
-    noProgressLimit: number;
-    tokenReservation: number;
-}
 export interface LoopState {
@@ -321,3 +305,2 @@ version: string;
     scaffold(changePath: string, options?: {
-        level?: LoopSafetyLevel;
         primitive?: TaskAgentPrimitive;
@@ -336,4 +319,2 @@ pattern?: string;
     private assertExists;
-    setLevel(changePath: string, level: LoopSafetyLevel): Promise<LoopConfig>;
-    private setLevelUnlocked;
     configure(changePath: string, options: LoopConfigureOptions): Promise<LoopConfig>;
@@ -365,2 +346,3 @@ private configureUnlocked;
     private actionMaxRuntimeMs;
+    private isReviewActionKind;
     private extendControllerCapabilitySession;
@@ -388,7 +370,7 @@ private isTerminalItemStatus;
     private reviewAction;
+    private planningRepairAction;
     private verificationAction;
-    private validateTaskSafety;
+    private validateConfiguredTaskSafety;
     private getImmediateStop;
     private getHardStop;
-    private runLegacyTick;
     buildControllerTickPlan(changePath: string): Promise<{
@@ -408,4 +390,2 @@ interval: string;
     private defaultEfficiency;
-    private defaultDocumentReviewGovernance;
-    private normalizeDocumentReviewGovernance;
     private isControllerCapabilityCurrent;
@@ -412,0 +392,0 @@ private assertActionNativeSession;

dist/services/templates/ExecutionTemplateBuilder.js

@@ -338,4 +338,2 @@ "use strict";
                 status: context.placement === 'queued' ? 'queued' : 'draft',
-                risk_level: 'pending',
-                risk_flags: [],
                 optional_steps: context.optionalSteps,
@@ -655,4 +653,2 @@ }, this.copy(context.documentLanguage, zh, en, ja, ar));
                 status: context.placement === 'queued' ? 'queued' : 'draft',
-                risk_level: 'pending',
-                risk_flags: [],
                 optional_steps: context.optionalSteps,
@@ -843,3 +839,3 @@ }, this.copy(context.documentLanguage, zh, en, ja, ar));
             version: '1.0',
-            contract_version: '1.8.6',
+            contract_version: '1.9.0',
             feature: context.feature,
@@ -846,0 +842,0 @@ status: 'pending',

dist/services/TriageService.d.ts

@@ -16,4 +16,4 @@ import { FileService } from './FileService';
 /**
- * Manages the cross-change triage inbox (`<managed>/triage/inbox.jsonl`). Loop ticks (L1, or
- * out-of-allowlist findings at higher levels) append here; `ospec triage` lists/claims/promotes.
+ * Manages the cross-change triage inbox (`<managed>/triage/inbox.jsonl`). Workflow controllers
+ * append findings here; `ospec triage` lists, claims, and promotes them.
  * Paths always go through `resolveManagedPath` so classic and nested layouts both work (Contract 4).
@@ -20,0 +20,0 @@ */

dist/services/TriageService.js

 "use strict";
 /**
- * Manages the cross-change triage inbox (`<managed>/triage/inbox.jsonl`). Loop ticks (L1, or
- * out-of-allowlist findings at higher levels) append here; `ospec triage` lists/claims/promotes.
+ * Manages the cross-change triage inbox (`<managed>/triage/inbox.jsonl`). Workflow controllers
+ * append findings here; `ospec triage` lists, claims, and promotes them.
  * Paths always go through `resolveManagedPath` so classic and nested layouts both work (Contract 4).
@@ -6,0 +6,0 @@ */

dist/utils/subcommandHelp.js

@@ -133,3 +133,3 @@ "use strict";
   ospec execute handoff [change-path|project-path] [--target codex|gpt|claude|gemini|opencode|cursor|copilot|shell|generic] - write a cross-harness worker handoff guide with native agent mapping and project session context
-  ospec execute doc-review [change-path|project-path] [--stage design|plan] [--force] [--claim-executor id|--heartbeat-executor id|--complete-executor id] [--usage-file usage.json] - dispatch/reuse a bounded document review or record its native executor lifecycle; --force cannot bypass review guards
+  ospec execute preflight [change-path|project-path] [--stage design|plan] [--force] - run or reuse a zero-token deterministic planning preflight
   ospec execute status [change-path|project-path] [--brief] - show task graph controller state; prefer --brief and the emitted packet path for controller loops
@@ -154,3 +154,2 @@ ospec execute next [change-path|project-path]   - show dispatchable next task(s)
   ospec execute decision [change-path|project-path] --id id --question "..." --option id:label:impact --option id:label:impact [--recommended id] [--required|--optional] - record a durable user choice gate that can block dispatch until selected
-  ospec execute decision [change-path|project-path] --id id --question "Allow one extra review round?" --option allow:Allow:impact --option stop:Stop:impact --required --document-review-stage design|plan --review-context-hash H --review-round N --review-approval-option allow - create a decision bound to one explicit approval option and exactly one extra document-review round
   ospec execute decision [change-path|project-path] --id id --select option-id --answered-by user [--summary "..."] - record the user's selected option with explicit provenance and unblock required decision gates
@@ -157,0 +156,0 @@ ospec execute debug [change-path|project-path] --phase reproduce|isolate|hypothesize|fix|verify --symptom "..." --root-cause "..." [--status CONFIRMED|FIXED|BLOCKED|SKIPPED] [--hypothesis "..."] [--command "..."] [--summary "..."] - record staged debugging evidence

dist/workflow/ConfigurableWorkflow.d.ts

@@ -24,3 +24,2 @@ /**
     };
-    document_review_policy: 'always' | 'adaptive';
     model_profiles: Partial<Record<'mechanical' | 'standard' | 'strong_reasoning' | 'review' | 'final_review', {
@@ -27,0 +26,0 @@ default?: string;

dist/workflow/ConfigurableWorkflow.js

@@ -36,3 +36,2 @@ "use strict";
         },
-        document_review_policy: 'always',
         model_profiles: {},
@@ -67,3 +66,2 @@ },
         },
-        document_review_policy: 'always',
         model_profiles: {},
@@ -100,3 +98,2 @@ },
         },
-        document_review_policy: 'always',
         model_profiles: {},
@@ -103,0 +100,0 @@ },

package.json

 {
   "name": "@clawplays/ospec-cli",
-  "version": "1.8.23",
+  "version": "1.9.0",
   "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",

README.md

@@ -43,3 +43,3 @@ <h1><a href="https://ospec.ai/" target="_blank" rel="noopener noreferrer">OSpec.ai</a></h1>
 - **`ospec goal` for larger or riskier work** — describe the result you need; the AI asks important questions, writes an inspectable plan, implements the work, runs tests, requests an independent review, updates project docs, and continues until the result is proven.
-- **You choose how much it may do automatically** — `L1` only checks, `L2` may edit but pauses for important choices, and `L3` may continue within limits you set. Progress is saved in the repository, so a later session can resume it.
+- **One predictable Goal workflow** — every Goal uses the same fast quality path, pauses for material user decisions, and saves progress in the repository so a later session can resume it.
 
@@ -142,3 +142,3 @@ ## Install With npm
 ospec execute status changes/active/<goal-name>
-ospec execute dispatch changes/active/<goal-name> --limit 2
+ospec execute dispatch changes/active/<goal-name> --limit 3
 ospec execute launch changes/active/<goal-name> --task <task-id> --target codex
@@ -199,6 +199,8 @@ ospec execute complete <task-id> changes/active/<goal-name> --status DONE --summary "..."
 
+A Change uses compact stage-aware guidance, one lightweight current-AI review, and derived closeout state. When verification, documentation, plugin, and review gates pass, `APPROVED` or `APPROVED_WITH_CONCERNS` may finalize and archive automatically; explicit batches stay sequential in the queue.
+
 Start from a terminal:
 
 ```bash
-ospec goal improve-checkout --level L2 --target codex --execution-model controller --harness-interactive true --native-subagents supported
+ospec goal improve-checkout --target codex --execution-model controller --harness-interactive true --native-subagents supported
 ```
@@ -211,21 +213,15 @@
 1. Ask only the choices that materially change the result.
-2. Write down the agreed approach so you can inspect it before code changes begin.
-3. Split the work into safe pieces, mark independent tasks parallel, and record why any task or configured limit is intentionally serial.
-4. Test the implementation, ask a separate reviewer to check it, and fix the findings.
-5. Update the relevant project documentation and indexes before archiving the completed work.
+2. Write the proposal, design, and implementation plan, then run deterministic design and plan preflights without launching reviewer children.
+3. Derive the task graph and run one independent combined planning review across requirements, architecture, task boundaries, dependencies, and verification coverage.
+4. If that review finds issues, repair the planning set once as a group and run one fresh combined planning review. A repeated failure stops instead of looping.
+5. Run conflict-safe implementation workers, independent task reviews, an integration-focused final review, verification, documentation sync, and archive.
 
 You remain in control. The AI explains what it is about to do, pauses when it needs a decision, and records task, review, repair, verification, and loop progress in the repository so a fresh worker or later session can continue without replaying the conversation. You do not need to run the internal `ospec execute` commands yourself.
 
-Choose how much the goal may do on its own with `--level L1|L2|L3` (default L1):
+Every 1.9 Goal uses the same fast quality workflow. Required user decisions always block implementation. The integrated goal loop reads `task-graph.json`, emits a bounded conflict-safe parallel batch, and explains whether configured limits, graph conflicts, token funding, an optional configured allowlist, or known harness capacity reduced it. Unknown native capacity uses an implementation fallback of three; a larger positive session-bound capacity can support configured batches such as 5-10 when the graph, shared resources, token budget, and `maxParallel` allow. The current IDE AI launches one fresh native subagent per referenced packet, polls with bounded waits, refreshes heartbeats, persists each finished result immediately, and continues ticking without another user prompt. If the IDE lacks native subagents, controller dispatch fails clearly.
 
-- **L1** checks and reports, but does not change project files.
-- **L2** may make changes and pauses for important decisions.
-- **L3** may continue without waiting for routine steps, but only inside non-empty path and command allowlists.
+To see progress, child executor ids, heartbeat due times, leases, token sources, and concurrency reasons, run `ospec loop status --brief`; controller agents should use `ospec loop run --once --compact-json` to avoid repeating large runtime-adapter objects. Use `ospec loop configure` for concurrency, budgets, action runtime limits, evidence-result grace, and optional allowlists. IDE controllers persist child ownership with `ospec loop heartbeat` and atomically commit successful evidence plus executor outcome with `ospec loop finalize`. After a confirmed session or child loss, `ospec loop recover --force` expires only unfinished items. Task and final repair convergence guards prevent repeated finding sets from cycling indefinitely. Durable worker blockers are not redispatched, technical executor failures remain retryable, and independent ready tasks run first. Advanced loop and triage commands are documented in [docs/loop-engineering.md](docs/loop-engineering.md).
 
-Required user decisions block every level. The integrated goal loop reads `task-graph.json`, emits a bounded conflict-safe parallel batch, and explains whether configured limits, graph conflicts, token funding, or known harness capacity reduced it. When the `ospec-goal` skill is active and the IDE exposes a native subagent API, controller mode requires the current IDE AI to launch one fresh native subagent per referenced packet, poll with bounded native waits, refresh heartbeats, persist each finished result immediately, and continue ticking without another user prompt; it does not stop at Loop initialization or require `loop watch`. L1 remains report-only, so executable work requires the user to select L2 or L3. If the IDE lacks native subagents, controller auto-dispatch fails clearly instead of silently pretending the CLI started an IDE agent.
+Internally, OSpec validates design and implementation-plan readiness inline before task graph derivation, keeps implementation and code review separate, feeds blocked work and review findings into transactional retry or grouped repair, and requires current test evidence before the goal is considered complete.
 
-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. 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 strict lifetime ceilings. Durable worker blockers are not redispatched, technical executor failures remain retryable, and independent ready tasks run first. Advanced loop and triage commands are documented in [docs/loop-engineering.md](docs/loop-engineering.md).
-
-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.
-
 Claude Code hard enforcement (one-time; the AI runs this for you automatically in a Claude Code harness):
@@ -291,3 +287,3 @@
 │     ospec progress                                             │
-│     ospec execute bootstrap / handoff / doc-review / status    │
+│     ospec execute bootstrap / handoff / preflight / status     │
 │     ospec execute next                                         │
@@ -338,5 +334,5 @@ │     ospec execute workspace / worktree / worktree --create     │
 - **Session brief and hooks**: `ospec session` writes `.ospec/session-brief.json` and `.ospec/session-brief.md` so agents or humans entering an existing project can see active changes, queued changes, queue-run state, indexed document and archived-feature counts, a cache fingerprint, and the next safe command before touching a change; `ospec session hook --target claude` writes opt-in harness startup artifacts plus a Claude Code hook bundle under `.ospec/hooks/`, and `--apply` idempotently merges it into `.claude/settings.json`.
-- **Integrated goal loop**: `ospec loop run --once` (or the single-iteration `ospec loop tick` alias) emits token-bounded task/review/verification action batches for fresh model-native subagents. It uses packet paths instead of duplicating the whole goal, persists pending actions and feedback, routes stalled review findings through one durable root-cause strategy escalation before stopping repeats, and enforces required decisions, L3 allowlists, budgets, no-progress stops, and comprehension-review pauses. The removed `loop watch` path now returns migration guidance without starting an agent process.
-- **Task graph controller**: `ospec execute bootstrap` writes a one-change startup/resume snapshot with the project session brief snapshot and next safe action; `handoff` writes a cross-tool worker handoff guide; `doc-review` creates design and implementation-plan reviewer packets; `status` and `next` report controller state; `workspace` records git workspace safety; `worktree` manages explicit git worktree plans/runs; `dispatch`, `launch`, `complete`, and `review` create and settle native-subagent packets; `retry` reopens blocked or needs-context work; `debug`, `tdd`, and `verify` record durable evidence; `sync` rebuilds `worker-status.md`. `orchestrate`, `launch --run --command`, and `review --run --command` are retained only as migration errors and never launch agent CLIs.
-- **Adaptive review and model routing**: `.skillrc.workflow.document_review_policy` keeps independent document review by default. With `adaptive`, inline preflight still requires an explicit `risk_level: low` (or `none`) declaration and no detected risk signal; `.skillrc.workflow.model_profiles` maps logical roles without provider model names in OSpec defaults.
+- **Integrated goal loop**: `ospec loop run --once` (or `ospec loop tick`) emits token-bounded planning, task, review, and verification actions for fresh model-native subagents. It uses packet paths instead of duplicating the whole goal, persists pending actions, and stops repeated repair findings instead of cycling. Optional configured allowlists add an explicit path and command boundary without creating another workflow level.
+- **Task graph controller**: `ospec execute bootstrap` writes a one-change startup/resume snapshot; `preflight` records deterministic design and implementation-plan evidence under `artifacts/agents/planning-preflights/`; `workspace` records git safety; `dispatch`, `launch`, `complete`, and `review` settle native-subagent packets; `debug`, `tdd`, and `verify` record durable evidence; `sync` rebuilds derived status.
+- **Fast planning quality**: deterministic preflights cost no model round trip, while one independent combined planning reviewer checks requirement, architecture, task-graph, dependency, and verification semantics. At most one grouped planning repair and one re-review are allowed before a stable blocker.
 - **Measured execution and grouped repair**: command runners can write authoritative usage to `OSPEC_USAGE_FILE` for automatic ingestion, while `--usage-file` remains a manual input. Metrics distinguish complete, partial, and missing coverage. `ospec execute repair` turns all structured `NEEDS_CHANGES` findings into one repair task.
@@ -343,0 +339,0 @@ - **Verified durable documentation**: declared documentation targets capture before/after normalized content hashes, so an unchanged file cannot satisfy a new run. Feature indexes link completed work directly to the durable project documents it updated.

SKILL.md

@@ -28,3 +28,3 @@ ---
 
-1. `.skillrc` for layout, language, workflow policy, plugins, adaptive review policy, and model profiles.
+1. `.skillrc` for layout, language, workflow policy, plugins, and model profiles.
 2. `SKILL.index.json` and `docs/project/feature-index.md` as routers.
@@ -50,7 +50,7 @@ 3. The current session brief, bootstrap, dispatch, review, or repair packet.
 - Start or resume with `ospec session` and `ospec execute bootstrap`.
-- 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.
-- Legacy imported document-review completions without a durable decision still count as completed rounds but provide no convergence decision. After authoritative documents change, let OSpec issue a fresh review; never hand-edit or rehash the append-only ledger.
+- Run `ospec execute preflight ... --stage design`, then `--stage plan`, before deriving the task graph. These zero-token checks validate document readiness, required decisions, ordering, and provenance inline and never launch reviewer children.
+- After task graph derivation, let Loop issue one independent combined planning review across proposal, design, plan, tasks, graph, and acceptance-to-verification coverage. `NEEDS_CHANGES` permits one grouped planning repair and one fresh re-review; another failure is a stable blocker.
 - 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.
+- 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. If a 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.
@@ -87,3 +87,3 @@ - Record optional provider usage sidecars through the supported completion command. Metrics are evidence, not an archive gate unless project policy says otherwise.
 Change:      ospec change <name> -> implement -> ospec verify -> ospec finalize
-Goal:        ospec goal <name> -> session/bootstrap -> design/plan reviews -> dispatch/review -> verify/finalize
+Goal:        ospec goal <name> -> preflights -> task graph -> combined planning review -> workers/task reviews -> final review -> verify/finalize
 Docs:        ospec docs generate [path] -> ospec docs status -> ospec index check
@@ -90,0 +90,0 @@ Resume:      ospec session [path] -> read brief/index -> run the persisted next safe command

New alerts

Long strings

Supply chain risk

Contains long string literals, which may be a sign of obfuscated or packed code.

URL strings

Supply chain risk

Package contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.

Fixed alerts

Long strings

Supply chain risk

Contains long string literals, which may be a sign of obfuscated or packed code.

URL strings

Supply chain risk

Package contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.

Worsened metrics

Total package byte prevSize

3297658

-3.58%

Lines of code

57911

-3.14%

Number of lines in readme file

395

-1%

No dependency changes