Release 1.9.1

Author: clawplays

SKILL.md

@@ -43,7 +43,7 @@ In Claude Code, install the managed hook once with `ospec session hook --target
 
 ## Goal Controller Invariants
 
-Use the full `ospec execute ...` layer only for goal work or when the user explicitly requests agent/worker execution for a change.
+Use the full `ospec execute ...` task-graph/controller layer only for Goal work. A classic Change may use the shared `ospec execute decision` command for durable user choices, but it must not enter Goal bootstrap, workspace, dispatch, review, evidence, or Loop commands.
 
 - 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.

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

@@ -26,18 +26,18 @@ tags: [ai, guide, ospec]
 - لا تستنتج لغة وثائق change من لغة واجهة المنتج أو locale الموقع أو من متطلب "الإنجليزية أولاً" فقط
 - إذا كان البروتوكول المعتمد للمشروع بالصينية أو كانت وثائق change الحالية بالصينية بالفعل، فاستمر بالصينية ما لم تغيّر قواعد المشروع ذلك صراحةً
 - استخدم الفهرس لتحديد موقع المعرفة قبل قراءة الملفات الهدف
-- عند الدخول إلى مشروع OSpec موجود، شغّل `ospec session [path]` لكتابة `.ospec/session-brief.json` و`.ospec/session-brief.md` مع active change وqueued change وqueue run وcache fingerprint والأمر الآمن التالي؛ هذا project entry brief لا يستبدل `ospec execute bootstrap` للـ active change
+- عند الدخول إلى مشروع OSpec موجود، شغّل `ospec session [path]` لكتابة `.ospec/session-brief.json` و`.ospec/session-brief.md` مع profile ‏`change` أو `goal` للعمل النشط وqueued change وqueue run وcache fingerprint والأوامر التالية الموافقة للـ profile؛ يقرأ Change الكلاسيكي ملفاته الخمسة مباشرة ويستخدم Goal فقط `ospec execute bootstrap`
 - تعامل مع خطوات built-in quality policy المفعّلة مثل `tdd_cycle` و`root_cause_debug` و`verification_evidence` كـ `optional_steps` خاضعة لـ archive gate؛ غطّها في `tasks.md` و`verification.md` وملفات evidence المطابقة قبل closeout
 - استخدم `ospec change` / `ospec-change` عندما يختار المستخدم Change، ويبقى `ospec new` alias. أبقها على تدفق 1.0 السريع بغض النظر عن التعقيد أو flags أو عدد الملفات أو المخاطر أو حجم الدفعة: `proposal.md` و`tasks.md` والتنفيذ و`verification.md` و`review.md` و`state.json`
 - استخدم `ospec goal` / `ospec-goal` فقط عندما يختار المستخدم Goal صراحة
-- طبقة التحكم `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
+- طبقة التحكم `ospec execute …` (bootstrap وpreflight وdispatch وlaunch وreview وworktree وfinish وcollect وretry وsync) وكل artifacts الخاصة بـ goal تنتمي إلى `workflow_profile_id: goal`. وبالنسبة لـ `workflow_profile_id: change`، التزم بالتدفق السريع الكلاسيكي — لا تقرأ ولا تشغّل طبقة controller أو artifacts الخاصة بـ goal؛ حرّر `proposal.md` و`tasks.md`، ونفّذ، وسجّل `verification.md` و`review.md`، ثم أغلق بـ `ospec verify` على المستوى الأعلى و`ospec finalize`. يبقى أمر `ospec execute decision` المشترك متاحاً لاختيارات المستخدم الدائمة
 - عند تنفيذ goal بمساعدة AI، لا تطلب من المستخدم كتابة `design.md` أو `implementation-plan.md` يدوياً؛ أنشئهما أو حدّثهما من المتطلب و`proposal.md` وسياق المشروع قبل اشتقاق `artifacts/agents/task-graph.json` أو تعديل `tasks.md` أو الكود
 - عند تنفيذ classic change، لا تنشئ goal-only files ما لم يطلب المستخدم ترقية العمل صراحة إلى goal
 - `Announce-Before-Act`: لا تُشغّل سير العمل بصمت. أعلن OSpec skill والمرحلة، والأمر والـ artifact، وmodel-native subagent adapter المختار، وعدد workers، وcurrent session capability، وأي بوابة تحجب التقدم
 - `Brainstorm-First`: ابدأ كل goal بجولة عصف ذهني قصيرة قبل تثبيت التصميم. اعرض الأسئلة المفتوحة حول الاتجاه والبنية وAPI والبيانات وUI والمخاطر والنطاق، واسأل المستخدم سؤالاً واحداً في كل مرة بدلاً من الافتراض الصامت؛ واحفظ الاستكشاف عبر `ospec brainstorm [path] --topic "..."` عند الحاجة. وعندما يكون أي منها مفتوحاً فعلاً، فضّل رفع decision gate دائمة على التخمين؛ ولا تسجّل افتراضاً ذاتياً في `design.md` إلا عندما يفوّض المستخدم صراحةً أو يكون غير متاح، مع وسمه كافتراض بحاجة لتأكيد
 - عندما يجب أن ينتظر change اختيار المستخدم، سجّل durable decision gate عبر `ospec execute decision [changes/active/<change>] --id <id> --question "..." --option id:label:impact --option id:label:impact [--recommended id] [--required]`، واعرض `Chat Prompt` من decision report أو `artifacts/agents/decisions/index.md`، ثم سجّل الإجابة عبر `ospec execute decision [changes/active/<change>] --id <id> --select <option-id>`
 - في goal يجب أن يُشتق `implementation-plan.md` من `design.md`، وأن يُشتق `artifacts/agents/task-graph.json` من `implementation-plan.md`، وأن تُشتق `tasks.md` من task graph، وتُوائم المهام الموجودة بعد تحديث الوثائق السابقة. في classic change تُشتق `tasks.md` مباشرة من `proposal.md` ونطاق التنفيذ
-- عند بدء أو استئناف active change واحد، استخدم `ospec execute bootstrap [changes/active/<change>]` لكتابة `artifacts/agents/bootstrap.json` و`artifacts/agents/bootstrap.md` مع project session brief snapshot، ثم اتبع الإجراء الآمن التالي المسجل فيه؛ عند وجود active dispatch، يوصي bootstrap بأمر `ospec execute launch ... --task ...` المطابق
+- عند بدء أو استئناف active Goal واحد، استخدم `ospec execute bootstrap [changes/active/<goal>]` لكتابة `artifacts/agents/bootstrap.json` و`artifacts/agents/bootstrap.md` مع project session brief snapshot، ثم اتبع الإجراء الآمن التالي المسجل فيه؛ عند وجود active dispatch، يوصي bootstrap بأمر `ospec execute launch ... --task ...` المطابق. يستخدم Change الكلاسيكي `ospec progress` و`ospec verify` على المستوى الأعلى و`ospec finalize`
 - عند نقل 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
 - قبل اشتقاق 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>]`

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

@@ -28,7 +28,7 @@ tags: [ai, protocol, ospec]
 - تعامل مع خطوات built-in quality policy المفعّلة مثل `tdd_cycle` و`root_cause_debug` و`verification_evidence` كـ `optional_steps` خاضعة لـ archive gate؛ غطّها في `tasks.md` و`verification.md` وملفات evidence المطابقة قبل closeout
 - استخدم `ospec change` / `ospec-change` عندما يختار المستخدم Change، ويبقى `ospec new` alias. أبقها على تدفق 1.0 السريع بغض النظر عن التعقيد أو flags أو عدد الملفات أو المخاطر أو حجم الدفعة: `proposal.md` و`tasks.md` والتنفيذ و`verification.md` و`review.md` و`state.json`
 - استخدم `ospec goal` / `ospec-goal` فقط عندما يختار المستخدم Goal صراحة
-- طبقة التحكم `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
+- طبقة التحكم `ospec execute …` (bootstrap وpreflight وdispatch وlaunch وreview وworktree وfinish وcollect وretry وsync) وكل artifacts الخاصة بـ goal تنتمي إلى `workflow_profile_id: goal`. وبالنسبة لـ `workflow_profile_id: change`، التزم بالتدفق السريع الكلاسيكي — لا تقرأ ولا تشغّل طبقة controller أو artifacts الخاصة بـ goal؛ حرّر `proposal.md` و`tasks.md`، ونفّذ، وسجّل `verification.md` و`review.md`، ثم أغلق بـ `ospec verify` على المستوى الأعلى و`ospec finalize`. يبقى أمر `ospec execute decision` المشترك متاحاً لاختيارات المستخدم الدائمة
 - أثناء تنفيذ goal بمساعدة AI، أنشئ `design.md` أو حدّثه بعد `proposal.md` وقبل تعديل `implementation-plan.md` أو `tasks.md` أو الكود. في classic change لا تنشئ goal-only files ما لم يطلب المستخدم الترقية إلى goal صراحة
 - `Announce-Before-Act`: لا تُشغّل سير العمل بصمت. أعلن OSpec skill والمرحلة، والأمر والـ artifact، وmodel-native subagent adapter المختار، وعدد workers، وcurrent session capability، وأي بوابة تحجب التقدم
 - `Brainstorm-First`: ابدأ كل goal بجولة عصف ذهني قصيرة قبل تثبيت التصميم. اعرض الأسئلة المفتوحة حول الاتجاه والبنية وAPI والبيانات وUI والمخاطر والنطاق، واسأل المستخدم سؤالاً واحداً في كل مرة بدلاً من الافتراض الصامت؛ واحفظ الاستكشاف عبر `ospec brainstorm [path] --topic "..."` عند الحاجة. وعندما يكون أي منها مفتوحاً فعلاً، فضّل رفع decision gate دائمة على التخمين؛ ولا تسجّل افتراضاً ذاتياً في `design.md` إلا عندما يفوّض المستخدم صراحةً أو يكون غير متاح، مع وسمه كافتراض بحاجة لتأكيد
@@ -41,7 +41,7 @@ tags: [ai, protocol, ospec]
 - يجب أن تتقارب عمليات 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 للمشروع واستخدم أسماء خدمات صريحة عند وجود خدمات غير مرتبطة.
-- عند بدء أو استئناف active change واحد، استخدم `ospec execute bootstrap [changes/active/<change>]` لكتابة `artifacts/agents/bootstrap.json` و`artifacts/agents/bootstrap.md` مع project session brief snapshot، ثم اتبع الإجراء الآمن التالي المسجل فيه
+- عند بدء أو استئناف active Goal واحد، استخدم `ospec execute bootstrap [changes/active/<goal>]` لكتابة `artifacts/agents/bootstrap.json` و`artifacts/agents/bootstrap.md` مع project session brief snapshot، ثم اتبع الإجراء الآمن التالي المسجل فيه. يستخدم Change الكلاسيكي `ospec progress` و`ospec verify` على المستوى الأعلى و`ospec finalize`
 - عند نقل 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
 - قبل اشتقاق 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 والمهام التالية الآمنة