Release 1.8.11

Author: clawplays

README.md

@@ -141,12 +141,14 @@ ospec execute status changes/active/<goal-name>
 ospec execute dispatch changes/active/<goal-name> --limit 2
 ospec execute launch changes/active/<goal-name> --task <task-id> --target codex
 ospec execute complete <task-id> changes/active/<goal-name> --status DONE --summary "..."
-ospec execute review changes/active/<goal-name> --task <task-id>
+ospec loop tick changes/active/<goal-name> # issues task/final reviews with executor provenance
 ospec execute verify changes/active/<goal-name> --command "npm test" --status PASSED --exit-code 0
 ```
 
 `launch` writes `artifacts/agents/launch-plan.md`; it does not start workers by itself. Codex/GPT use `spawn_agent` plus bounded `wait_agent`, Claude Code uses bounded background Task polling when available, Gemini uses `@generalist`, and OpenCode uses `@mention`. Every native adapter returns from one wait within 60 seconds, refreshes heartbeats, persists each completed child immediately, and re-ticks. The 60-second boundary limits one controller poll, not the AI task runtime: a live child continues across polls up to its configurable absolute action deadline. OSpec never starts Orca, Codex, Claude, or another agent CLI as a fallback. If the current model harness cannot provide native subagents, executable dispatch blocks until a supported harness reports a fresh capability.
 
+For a controller-owned Goal, task and final reviews are always issued by `ospec loop tick` so the dispatch is atomically bound to the real reviewer executor. Use `ospec execute review` directly only in a non-controller workflow.
+
 ### 3. Archive After Acceptance
 
 After the requirement has passed deployment, testing, QA, or other acceptance checks, archive the validated change.
@@ -211,7 +213,7 @@ Choose how much the goal may do on its own with `--level L1|L2|L3` (default L1):
 
 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.
 
-To see progress, child executor ids, heartbeat due times, leases, review rounds, token sources, and concurrency/guard reasons, run `ospec loop status --brief` or `--json`. Use `ospec loop configure` for concurrency, budgets, action runtime limits, and evidence-result grace; allowlist flags replace the complete selected list and print a diff. For L3, prefer `ospec loop allowlist derive/check/apply --from-task-graph`, whose CAS-bound apply requires explicit approval for permission expansion. IDE controllers persist child ownership with `ospec loop heartbeat` and atomically commit successful evidence plus executor outcome with `ospec loop finalize`; legacy `ospec loop result` remains supported. After a confirmed session/child loss, `ospec loop recover --force` expires only unfinished items so they can be requeued without duplicating completed siblings. Task-review and grouped final-review repair use two rounds as convergence thresholds by default: changed structured finding IDs continue automatically, while repeated IDs stop before another ineffective repair. Use `--continue-while-progressing false` for the earlier strict lifetime ceilings. Durable worker blockers are not redispatched, technical executor failures remain retryable, and independent ready tasks run first. The 1.8.9 contract is documented in [docs/goal-1.8.9-interface.md](docs/goal-1.8.9-interface.md); the 1.8.6 runtime and 1.8.5 bounded native wait contracts remain in their versioned interface documents. Advanced loop and triage commands are documented in [docs/loop-engineering.md](docs/loop-engineering.md).
+To see progress, child executor ids, heartbeat due times, leases, review rounds, token sources, and concurrency/guard reasons, run `ospec loop status --brief` or `--json`. Use `ospec loop configure` for concurrency, budgets, action runtime limits, and evidence-result grace; allowlist flags replace the complete selected list and print a diff. For L3, prefer `ospec loop allowlist derive/check/apply --from-task-graph`, whose CAS-bound apply requires explicit approval for permission expansion. IDE controllers persist child ownership with `ospec loop heartbeat` and atomically commit successful evidence plus executor outcome with `ospec loop finalize`; legacy `ospec loop result` remains supported. After a confirmed session/child loss, `ospec loop recover --force` expires only unfinished items so they can be requeued without duplicating completed siblings. Task-review and grouped final-review repair use two rounds as convergence thresholds by default. Changed structured finding IDs continue automatically. From 1.8.11, a stable ID also continues when both its structured finding fingerprint and its authorized repair-scope code snapshot changed; wording-only or code-only churn still stops before another ineffective repair. Use `--continue-while-progressing false` for the earlier strict lifetime ceilings. Durable worker blockers are not redispatched, technical executor failures remain retryable, and independent ready tasks run first. The 1.8.11 refinement contract is documented in [docs/goal-1.8.11-interface.md](docs/goal-1.8.11-interface.md); older runtime contracts remain in their versioned interface documents. Advanced loop and triage commands are documented in [docs/loop-engineering.md](docs/loop-engineering.md).
 
 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.
 

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

@@ -48,7 +48,7 @@ tags: [ai, guide, ospec]
 - الإغلاق تلقائي عند الجاهزية: عندما ينجح `ospec verify [changes/active/<change>]` ولا توجد required pending decision أو بوابة إضافة (plugin gate) حاجبة، شغّل `ospec finalize [changes/active/<change>]` بنفسك——لا تتوقف بعد نجاح `ospec verify` أو `ospec archive ... --check` (الـ `--check` معاينة فقط) ولا تنتظر طلب المستخدم. لا توقف الإغلاق إلا حين تحتاج بوابة فعلاً إلى إنسان: required decision غير مُجابة، أو بوابة إضافة حاجبة غير معتمدة (مثل Stitch أو Checkpoint)، أو blockers حقيقية يبلّغ عنها verify أو archive، أو طلب صريح من المستخدم للمعاينة أو الموافقة قبل الأرشفة
 - بوابات القرار وخيارات brainstorm ملك للمستخدم: **لا تختر الخيار الموصى به تلقائياً ولا تحلّ بوابة بنفسك**——اعرض كل بوابة عبر سلّم القدرات (واجهة سؤال أصلية ← واجهة خطة/موافقة ← نص محادثة عادي) وانتظر اختيار المستخدم الفعلي؛ البوابات الإلزامية تحجب التنفيذ والإرسال حتى يجيب المستخدم، و`recommended` مجرد تلميح يُعرض على المستخدم
 - اكتب كل وثيقة change وbrainstorm تنشئها بلغة وثائق المشروع (`documentLanguage` في `.skillrc` / إرشادات `for-ai/` المُدارة)؛ لا تخلط العربية والإنجليزية داخل change واحد
-- عندما تحتاج إلى handoff artifacts دائمة على مستوى task، استخدم `ospec execute dispatch` لإنشاء batch آمن للتوازي من worker packets و`ospec execute complete` لتسجيل نتائج worker؛ يتضمن كل dispatch packet project session brief snapshot وworker profile يوضح capability tier وrecommended target وtarget tool mapping وrationale وrequired behavior؛ عندما تكون النتيجة `NEEDS_CONTEXT` أو `BLOCKED` يكتب `complete` ملفات `artifacts/agents/blockers/`؛ استخدم `--task` لمهمة واحدة صريحة و`--limit` لتحديد حجم dispatch batch؛ بعد اكتمال كل worker task استخدم `ospec execute review [changes/active/<change>] --task <task-id>` لإجراء مراجعة موحدة واحدة (spec compliance وcode quality في تمريرة واحدة)، وتبقى المهام التابعة محجوبة حتى اعتماد تلك المراجعة الموحدة الواحدة؛ وبعد اعتماد كل task-level reviews واكتمال task graph استخدم `ospec execute review` من دون `--task` لإنشاء حزمة code review نهائية موحدة واحدة؛ وبعد decision غير `PENDING` استخدم `ospec execute feedback` لكتابة `artifacts/agents/review-feedback-plan.md`؛ وبعد تعديل execution أو review artifacts يدويا استخدم `ospec execute sync` لإعادة بناء `worker-status.md`
+- استخدم `ospec execute dispatch` و`ospec execute complete` للـ handoff الدائم؛ تتضمن كل packet project session brief snapshot وworker profile وtarget tool mapping، ويحدد `--task` و`--limit` النطاق. في Goal مملوكة لـ controller، أصدر task/final reviews عبر `ospec loop tick [changes/active/<change>]` لربط `artifacts/agents/review-dispatches/` بـ executor provenance الحقيقي؛ استخدم `ospec execute review` فقط خارج controller Loop، ثم `ospec execute feedback` بعد القرار و`ospec execute sync` بعد التعديل اليدوي
 - توفير الـ tokens لا يغيّر أي gate: استخدم `--brief` مع `ospec execute …` و`ospec loop status`، وقُد العمل من الحالة المختصرة وpacket path. في إعادة المراجعة اقرأ prior findings sidecar وملخص الحل أولا، ولا تفتح task graph أو worker status أو launch plan أو مستندات goal كاملة إلا عند الحاجة
 - بعد dispatch، استخدم `ospec execute launch [changes/active/<change>] [--task task-id] [--target codex|gpt|claude|gemini|opencode|cursor|copilot] [--dry-run] [--json]` لكتابة launch plan؛ يقبل `runtimeAdapter` فقط model-native subagent capability حالية ومرتبطة بالـ target ويعرض native primitive
 - نفّذ `runtimeAdapter.selected.nativeSubagent` وشغّل safe batch فقط بالتوازي. عند غياب capability أو انتهاء صلاحيتها يجب block من دون agent CLI أو fallback إلى current controller
@@ -96,6 +96,7 @@ tags: [ai, guide, ospec]
 - يحل 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.
+- حافظ على finding ID ثابتا بينما يضيق العيب الجذري نفسه. بعد عتبة التقارب لا يواصل OSpec هذا المعرف إلا عندما يتغير كل من structured finding fingerprint وcode snapshot داخل repair scope المصرح به سابقا. لا تخترع معرفا جديدا ولا تعيد صياغة evidence فقط لفرض repair أخرى.
 - لكل مسار معلن في `documentation_updates` تحفظ سجلات dispatch وcomplete بصمة المحتوى المطبّع. يفشل documentation gate في التشغيل الجديد إذا لم يتغير المحتوى فعليا، ويُعلّم التشغيل القديم بلا baseline كغير متحقق. يربط archive index وثائق المشروع الدائمة المحدثة مباشرة بالميزة المكتملة.
 - عند كل finalize/archive ناجح ينشئ OSpec وثيقة محلية واحدة `docs/project/changes/<archive-path>.md` للـ change أو goal المؤرشف ويتحقق من ربطها في الفهرسين. قبل نقل change النشط، يرفض فحص archive المسبق الكتابة فوق وثيقة يملكها البشر في مسار التوليد ويتحقق من قابلية الكتابة في أدلة الإخراج المُدارة. لا يحل سجل change العام هذا محل وثائق architecture أو API أو module أو operation المطلوبة.
 - عندما يكون final review هو `NEEDS_CHANGES`، حل required decisions ثم استخدم `ospec execute repair` لجمع كل findings في repair task واحدة، ثم verification وtask review وfinal re-review مرة واحدة لكل منها.