Release 1.9.2

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: clawplays

README.md

@@ -328,7 +328,7 @@ If you want to convert an older classic project to the new layout, run `ospec la
 - **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 `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.
+- **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. A `NEEDS_CHANGES` decision permits one grouped planning repair and at most one delta-scoped re-review; a repair executor failure with no planning edits re-arms instead of consuming the allowance, and all-medium-or-lower findings settle deterministically as `APPROVED_WITH_CONCERNS` after the repair. Planning approvals are invalidated only by semantic planning changes, never by execution progress; repeated semantic failure is 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.
 - **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.
 - **Queue helpers**: `queue` and `run` support explicit multi-change execution when one active change is not enough.

SKILL.md

@@ -47,7 +47,7 @@ Use the full `ospec execute ...` task-graph/controller layer only for Goal work.
 
 - Start or resume with `ospec session` and `ospec execute bootstrap`.
 - 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.
+- 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 at most one delta-scoped re-review; a repair executor failure with no planning edits re-arms instead of consuming the allowance, all-medium-or-lower findings settle deterministically as `APPROVED_WITH_CONCERNS` after the repair, and another semantic 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. If a finding names an unsnapshotted canonical report, let Loop issue a fresh review before repair instead of editing history or widening artifact scope.

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

@@ -93,7 +93,7 @@ tags: [ai, guide, ospec]
 
 ## سياسات كفاءة التنفيذ
 
-- شغّل deterministic preflight للتصميم والخطة، ثم اشتق task graph، ثم نفّذ combined planning review مستقلة واحدة. يسمح بإصلاح تخطيط مجمّع واحد وfresh re-review واحدة فقط، وتبقى task review وfinal combined review وverification مطلوبة.
+- شغّل deterministic preflight للتصميم والخطة، ثم اشتق task graph، ثم نفّذ combined planning review مستقلة واحدة. يسمح بإصلاح تخطيط مجمّع واحد وإعادة مراجعة تفاضلية واحدة كحد أقصى؛ يعيد فشل المنفّذ دون تعديل التخطيط تسليح الحصة، وتُقبل النتائج التي لا تتجاوز medium حتمياً كـ `APPROVED_WITH_CONCERNS` بعد الإصلاح، وتبقى 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 غير معروف.
 - يتلقى command runner المسار `OSPEC_USAGE_FILE` ويجمع sidecar تلقائيا؛ ويبقى `ospec execute complete ... --usage-file usage.json` للإدخال اليدوي. تسجل metrics المصدر والحقول المرصودة وتغطية complete/partial/missing، ولا تعرض القيمة غير المبلّغ عنها كصفر مقاس.
 - يكتب reviewer ملف Markdown للبشر وملف `*.findings.json` مجاورا بمعرفات ثابتة وseverity وcategory وmessage ودليل file/line ومراجع المتطلبات ونطاق الإصلاح. يحوّل Markdown القديم إلى sidecar متوافق قبل repair.

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

@@ -37,7 +37,7 @@ tags: [ai, protocol, ospec]
 - في goal أنشئ `implementation-plan.md` أو حدّثه من `design.md`، مع الملفات المستهدفة والنتائج المتوقعة وأوامر التحقق والاعتماديات والعمل القابل للتوازي والتعارضات
 - في 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` واضحاً عندما يتطلب نطاق تحقق ذري واحد هذا الاتساع
 - تستخدم 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 واحدة، وبعد فشل متكرر يتوقف المسار بثبات.
+- تستخدم مرحلة design/plan deterministic inline preflight ثم combined planning review مستقل واحد. يسمح بمحاولة grouped planning repair واحدة وإعادة مراجعة تفاضلية واحدة كحد أقصى؛ فشل المنفّذ دون تعديل محتوى التخطيط يعيد تسليح الإصلاح دون استهلاك الحصة، وبعد اكتمال الإصلاح تُقبل النتائج التي لا تتجاوز medium حتمياً كـ `APPROVED_WITH_CONCERNS`، وبعد فشل دلالي متكرر يتوقف المسار بثبات.
 - يجب أن تتقارب عمليات 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. لا ترفع الحدود لتكرار عمل لم يتغير.
 - يجب أن يكون انتظار 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 ولا تعِد استخدام قيمة قديمة.
 - تجدد كل controller poll ناجحة ومحدودة lease القصيرة لـ child حي ومطالب به من دون تمديد absolute deadline. ويمكن لـ poll تصل خلال نافذة wait محدودة قدرها 60 ثانية بعد حد lease القصيرة أن تجدد نفس item المطالب به؛ تبقى النتائج المتأخرة المباشرة مرفوضة، وتنتهي items المفقودة فعلا، ولا يتحرك absolute deadline. يجب تنفيذ prerequisite review المفقودة قبل إعادة محاولة dependent work القابل للإعادة. لا يقبل cross-task finding paths إضافية إلا إذا كانت مملوكة لمهام مكتملة ومعلنة في task graph؛ جمّد scope الكامل وأعد review للمالكين المتغيرين. ما دام أي cross-task owner مسجل غير معتمد، تسبق review أو repair الخاصة به أي implementation جديد أو retryable worker، مع بقاء reviewers الآخرين غير المتعارضين متوازيين. قبل full Docker Compose rebuild من دون أسماء خدمات، اقرأ release guidance للمشروع واستخدم أسماء خدمات صريحة عند وجود خدمات غير مرتبطة.
@@ -97,7 +97,7 @@ tags: [ai, protocol, ospec]
 
 ## سياسات السياق والإصلاح
 
-- شغّل deterministic preflight للتصميم والخطة، ثم اشتق task graph، ثم نفّذ combined planning review مستقلة واحدة؛ يسمح بإصلاح تخطيط مجمّع واحد وfresh re-review واحدة فقط.
+- شغّل deterministic preflight للتصميم والخطة، ثم اشتق task graph، ثم نفّذ combined planning review مستقلة واحدة؛ يسمح بإصلاح تخطيط مجمّع واحد وإعادة مراجعة تفاضلية واحدة كحد أقصى. يعيد فشل المنفّذ دون تعديل التخطيط تسليح الحصة، وتُقبل النتائج التي لا تتجاوز medium حتمياً كـ `APPROVED_WITH_CONCERNS` بعد الإصلاح؛ لا يبطل اعتماد التخطيط إلا تغيير دلالي في محتواه، ولا يبطله تقدم التنفيذ.
 - تربط `.skillrc.workflow.model_profiles` ملفات `mechanical` و`standard` و`strong_reasoning` و`review` و`final_review` المنطقية بنماذج target؛ وعند غياب الربط يستخدم harness default مع warning في packet.
 - يستخدم command runner المتغير `OSPEC_USAGE_FILE` لجمع normalized usage تلقائيا، ويبقى `--usage-file` كتجاوز يدوي. يجمع `execution-metrics.json` حسب capability tier وmodel profile وworkflow stage ويعرض تغطية complete/partial/missing.
 - يجب تسجيل كل review finding قابل للتنفيذ أيضا في `*.findings.json` المجاور بمعرف ثابت وseverity وcategory وmessage ودليل file/line ومراجع المتطلبات ونطاق الإصلاح. تعد structured findings التالفة حالة blocking ولا يسمح بالتراجع الصامت.

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

@@ -114,7 +114,7 @@ This document is the project-adopted AI guide copied from the OSpec mother spec.
 
 ## Execution Efficiency Policies
 
-- 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.
+- Run deterministic design and plan preflights, derive the task graph, then run one independent combined planning review. One grouped planning repair and at most one delta-scoped re-review are the maximum; no-edit executor failures re-arm the repair, all-medium-or-lower findings settle deterministically as `APPROVED_WITH_CONCERNS`, and 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.
 - 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.
 - Reviewers write human-readable Markdown and a sibling `*.findings.json` with stable IDs, severity, category, message, file/line evidence, requirement references, and repair scope. Legacy Markdown is converted to a compatibility sidecar before repair.