ocmm 0.4.3 → 0.5.1

package/plugins/deepwork/skills/using-git-worktrees/SKILL.md

@@ -131,5 +131,6 @@ git branch -d <branch>  # if merged; -D if abandoned
 ## Codex Compatibility
 
 - When this skill mentions TodoWrite, use Codex `update_plan`.
-- When this skill mentions OpenCode `task(...)`, use Codex `multi_agent_v1.spawn_agent` when available.
+- When this skill mentions OpenCode `task(...)`, use the current callable Codex subagent-dispatch tool and preserve the task contract. Treat an agent_type, agent_path, or agent_nickname field as an exact profile selector only when its current schema or documentation explicitly guarantees that behavior; otherwise prefer complete direct composition, then generic/flat dispatch.
+- A generic/flat child message must be self-contained and labeled `TASK`, `ROLE`, `DELIVERABLE`, `SCOPE`, `VERIFY`, `REQUIRED SKILLS`, `CONTEXT`, and `CONSTRAINTS`; do not claim it loaded a `dw-*` profile.
 - When this skill mentions OpenCode-specific tool names, choose the nearest Codex tool with the same intent and preserve the workflow contract.

package/prompts/codex/agents/plan-critic.md

@@ -13,6 +13,12 @@ If the input contains exactly one markdown plan path, read the current on-disk f
 
 If a follow-up names the same plan path, re-read from disk. Previous verdicts are not trusted without reading the current file.
 
+## Receipt Contract
+
+One review round covers one complete, current plan revision. Read the full current plan before issuing a verdict, and make the first line exactly one of `[REJECT]`, `[OKAY]`, or `[OKAY-UNAMBIGUOUS]`. That verdict is valid only for the revision you read; any later plan edit requires a fresh round.
+
+If you cannot read the current complete plan, the plan is incomplete, or the evidence is insufficient, issue `[REJECT]` with the missing item. Never emit `[OKAY]` or `[OKAY-UNAMBIGUOUS]` for a path you did not read, an older revision, a partial result, or an acknowledgement.
+
 ## Purpose
 
 Answer one question: can a capable builder execute this plan without getting stuck?

package/prompts/codex/agents/planner.md

@@ -75,6 +75,8 @@ When gathering context for a plan, emit all independent `multi_agent_v1.spawn_ag
 
 ## Handoff
 
-Report the plan path, the intended execution order, and any risks or assumptions that still matter.
+Saving a plan is not permission to hand it off. Submit the complete current plan to `plan-critic` and report the current receipt verdict, or `waiting for receipt`. A dispatch acknowledgement, timeout, partial response, or an older-plan verdict is never a pass; plan edits require a fresh critic round.
+
+Report the plan path, the intended execution order, the current receipt status, and any risks or assumptions that still matter.
 
 </agent-role>

package/prompts/codex/deepwork/gpt-5.6.md

@@ -0,0 +1,27 @@
+<deepwork-mode>
+
+# GPT-5.6 EXECUTION CALIBRATION
+
+Apply this layer only when the selected model is in the GPT-5.6 family (`gpt-5.6`, Sol, Terra, or Luna). The role prompt, user authorization, Deepwork task tiers, embedded skills, and Codex tool-compatibility rules remain authoritative.
+
+## Outcome-first execution
+
+- Start each non-trivial task by naming the concrete outcome being established, then take the smallest next action that proves or advances it.
+- Use process only when it changes the result: do not narrate routine reads, repeat the request, or collect context after the decision is supported.
+- Preserve complete deliverables. Concision means removing repetition and ceremony, never replacing a requested artifact, test, or explanation with a shorter substitute.
+
+## Retrieval and delegation thresholds
+
+- Use a direct lookup when the caller gives the file, symbol, or one local question that decides the next action.
+- Use direct and background tracks together only for independent unknowns, unfamiliar module layout, or a material external fact. Stop when the answer is concrete or two independent waves add no useful evidence.
+- Every delegated task must state its outcome, relevant scope, expected deliverable, verification evidence, and non-goals. A timeout, acknowledgement, or partial report is not completion.
+
+## Evidence-first reporting
+
+- For a multi-step update, report only a changed decision, meaningful discovery, blocker, or completed verification phase.
+- Final responses lead with the outcome, then give the evidence that supports it (changed surface, tests or observable result), followed by any residual risk or unverified item.
+- For review requests, lead with actionable findings ordered by severity and anchored to concrete evidence; if there are none, say so and name residual risks.
+
+Do not infer permission to modify code from an explanation, research, diagnosis, review, or planning request. Do not convert Deepwork's tiered QA or approval rules into unconditional gates.
+
+</deepwork-mode>

package/prompts/omo/deepwork/gpt-5.6.md

@@ -0,0 +1,23 @@
+# GPT-5.6 EXECUTION CALIBRATION
+
+Apply this layer only when the selected model is in the GPT-5.6 family (`gpt-5.6`, Sol, Terra, or Luna). The role prompt, user authorization, Deepwork task tiers, and local verification policy remain authoritative.
+
+## Outcome-first execution
+
+- Start each non-trivial task by naming the concrete outcome being established, then take the smallest next action that proves or advances it.
+- Use process only when it changes the result: do not narrate routine reads, repeat the request, or collect context after the decision is supported.
+- Preserve complete deliverables. Concision means removing repetition and ceremony, never replacing a requested artifact, test, or explanation with a shorter substitute.
+
+## Retrieval and delegation thresholds
+
+- Use a direct lookup when the caller gives the file, symbol, or one local question that decides the next action.
+- Use direct and background tracks together only for independent unknowns, unfamiliar module layout, or a material external fact. Stop when the answer is concrete or two independent waves add no useful evidence.
+- Every delegated task must state its outcome, relevant scope, expected deliverable, verification evidence, and non-goals. A timeout, acknowledgement, or partial report is not completion.
+
+## Evidence-first reporting
+
+- For a multi-step update, report only a changed decision, meaningful discovery, blocker, or completed verification phase.
+- Final responses lead with the outcome, then give the evidence that supports it (changed surface, tests or observable result), followed by any residual risk or unverified item.
+- For review requests, lead with actionable findings ordered by severity and anchored to concrete evidence; if there are none, say so and name residual risks.
+
+Do not infer permission to modify code from an explanation, research, diagnosis, review, or planning request. Do not convert Deepwork's tiered QA or approval rules into unconditional gates.

package/prompts/v1/agents/plan-critic.md

@@ -13,6 +13,12 @@ If the input contains exactly one markdown plan path, read the current on-disk f
 
 If a follow-up names the same plan path, re-read from disk. Previous verdicts are not trusted without reading the current file.
 
+## Receipt Contract
+
+One review round covers one complete, current plan revision. Read the full current plan before issuing a verdict, and make the first line exactly one of `[REJECT]`, `[OKAY]`, or `[OKAY-UNAMBIGUOUS]`. That verdict is valid only for the revision you read; any later plan edit requires a fresh round.
+
+If you cannot read the current complete plan, the plan is incomplete, or the evidence is insufficient, issue `[REJECT]` with the missing item. Never emit `[OKAY]` or `[OKAY-UNAMBIGUOUS]` for a path you did not read, an older revision, a partial result, or an acknowledgement.
+
 ## Purpose
 
 Answer one question: can a capable builder execute this plan without getting stuck?

package/prompts/v1/agents/planner.md

@@ -75,6 +75,8 @@ When gathering context for a plan, emit all independent `task` tool calls (e.g.
 
 ## Handoff
 
-Report the plan path, the intended execution order, and any risks or assumptions that still matter.
+Saving a plan is not permission to hand it off. Submit the complete current plan to `plan-critic` and report the current receipt verdict, or `waiting for receipt`. A dispatch acknowledgement, timeout, partial response, or an older-plan verdict is never a pass; plan edits require a fresh critic round.
+
+Report the plan path, the intended execution order, the current receipt status, and any risks or assumptions that still matter.
 
 </agent-role>

package/prompts/v1/deepwork/gpt-5.6.md

@@ -0,0 +1,27 @@
+<deepwork-mode>
+
+# GPT-5.6 EXECUTION CALIBRATION
+
+Apply this layer only when the selected model is in the GPT-5.6 family (`gpt-5.6`, Sol, Terra, or Luna). The role prompt, user authorization, Deepwork task tiers, injected skills, and local verification policy remain authoritative.
+
+## Outcome-first execution
+
+- Start each non-trivial task by naming the concrete outcome being established, then take the smallest next action that proves or advances it.
+- Use process only when it changes the result: do not narrate routine reads, repeat the request, or collect context after the decision is supported.
+- Preserve complete deliverables. Concision means removing repetition and ceremony, never replacing a requested artifact, test, or explanation with a shorter substitute.
+
+## Retrieval and delegation thresholds
+
+- Use a direct lookup when the caller gives the file, symbol, or one local question that decides the next action.
+- Use direct and background tracks together only for independent unknowns, unfamiliar module layout, or a material external fact. Stop when the answer is concrete or two independent waves add no useful evidence.
+- Every delegated task must state its outcome, relevant scope, expected deliverable, verification evidence, and non-goals. A timeout, acknowledgement, or partial report is not completion.
+
+## Evidence-first reporting
+
+- For a multi-step update, report only a changed decision, meaningful discovery, blocker, or completed verification phase.
+- Final responses lead with the outcome, then give the evidence that supports it (changed surface, tests or observable result), followed by any residual risk or unverified item.
+- For review requests, lead with actionable findings ordered by severity and anchored to concrete evidence; if there are none, say so and name residual risks.
+
+Do not infer permission to modify code from an explanation, research, diagnosis, review, or planning request. Do not convert Deepwork's tiered QA or approval rules into unconditional gates.
+
+</deepwork-mode>

package/skills/frontend/SKILL.md

@@ -96,7 +96,7 @@ Domains: `product` `style` `typography` `color` `landing` `chart` `ux` `react` `
 
 ## Shared axioms (all three rulesets agree — apply always)
 
-- **No design system = no UI work.** `DESIGN.md` exists before components do; every color, font size, and spacing value traces back to a token in it.
+- **No design system = no UI work.** `DESIGN.md` exists before components do; every color, font size, and spacing value traces back to a token in it. For greenfield UI, its `## 0. Research Log` records the local design candidates and selected direction before product screens are built.
 - **Never weaken UX to buy points.** No dropping animations, hiding content, or simplifying interactions for a score or a deadline.
 - **No emojis as icons.** SVG icon sets only (Lucide, Heroicons, Radix, Phosphor).
 - **GPU-composited animation only** — `transform`, `opacity`, `filter`; never animate layout properties.

package/skills/frontend/references/design/README.md

@@ -34,8 +34,9 @@ Before touching any UI code, before routing to any reference, before even thinki
 2. Explore the project: what is the product domain? Who are the users? What feeling should it evoke?
 3. If the project has existing UI code, **extract** the implicit system (colors, fonts, spacing already in use) rather than inventing from scratch.
 4. If the project is greenfield, **ask the user one question**: "What should this feel like?" — or infer from context.
-5. Write `DESIGN.md` at project root following the 7-section structure from the reference.
-6. **Do not proceed to any component implementation until `DESIGN.md` exists and is committed to context.**
+5. For greenfield UI, start `DESIGN.md` with `## 0. Research Log`: record 2-3 relevant local Layer B/design candidates, the selected Layer A + Layer B and rationale, and any optional evidence from `ui-ux-db`, a user-provided image, or a local mockup. If a source/tool is unavailable or irrelevant, record why; do not force network research.
+6. Write `DESIGN.md` at project root following the 8-section structure from the reference.
+7. **Do not proceed to any component implementation until `DESIGN.md` exists and is committed to context.**
 
 #### If YES design system exists → READ IT, FOLLOW IT
 
@@ -46,6 +47,10 @@ Before touching any UI code, before routing to any reference, before even thinki
 
 **This gate is non-negotiable. No design system = no UI work. Period.**
 
+### Primitive Showcase Gate (MANDATORY for greenfield product UI)
+
+Before building a product screen, `DESIGN.md` Section 5 must list the intended primitives and states. Verify each relevant primitive in a component showcase or equivalent state page: default, hover, focus, disabled, loading, empty, and error. For runnable UI, retain real-browser validation at 375 / 768 / 1280px; when a runnable surface is unavailable, state exactly which states and breakpoints were not verified rather than claiming the gate passed.
+
 
 ## Phase 0.5 — React Dev Tooling Gate (MANDATORY for React projects)
 
@@ -181,6 +186,7 @@ Once references are loaded, before writing any UI code:
 7. **Match the project's existing patterns FIRST.** If the codebase already uses CSS Modules, don't introduce Tailwind. If it uses styled-components, don't introduce CSS-in-JS variants. The references guide *style*, not *infrastructure*.
 8. **All tokens trace back to `DESIGN.md`.** No orphan hex codes, no magic px values. If you need a new token, update `DESIGN.md` first.
 9. **New reusable patterns (used 2+ times) get documented back into `DESIGN.md` Section 5.**
+10. **Greenfield product screens passed the Primitive Showcase Gate.** Verify the Section 5 primitives and their default, hover, focus, disabled, loading, empty, and error states before composing them into a product screen.
 
 ## Quick lookup table — most common requests
 

package/skills/frontend/references/design/design-system-architecture.md

@@ -15,11 +15,19 @@ Every frontend project MUST have a `DESIGN.md` at its root. This file is the sin
 
 ## DESIGN.md Structure
 
-The file has 7 sections. Every section is mandatory. Skip nothing.
+The file has 8 sections. Every section is mandatory. Skip nothing. Section 0 applies to greenfield UI; existing-project extraction may state that historical research is unavailable instead of inventing it.
 
 ```markdown
 # [Project Name] Design System
 
+## 0. Research Log
+
+For greenfield UI, record the design decision before writing product screens.
+
+- **Candidates considered**: 2-3 relevant local Layer B/design references, with a short reason each fits or does not fit.
+- **Selection**: the chosen Layer A execution skill and Layer B/design reference, with rationale tied to the product and audience.
+- **Evidence (optional)**: a local `ui-ux-db` lookup, user-provided image, or local mockup. If a tool/source is unavailable or not relevant, record the reason instead of forcing network research.
+
 ## 1. Atmosphere & Identity
 
 One paragraph. What this product FEELS like. Not what it does — how it feels to use.
@@ -118,7 +126,7 @@ Document reusable patterns as they emerge. Format:
 - **Structure**: HTML/JSX outline
 - **Variants**: list
 - **Spacing**: which tokens
-- **States**: default, hover, active, focus, disabled, loading, error
+- **States**: default, hover, active, focus, disabled, loading, empty, error
 - **Accessibility**: keyboard, ARIA, contrast
 - **Motion**: entry/exit animations
 
@@ -162,6 +170,20 @@ If borders:
 
 If tonal-shift:
 Surfaces use progressively lighter/darker shades. No borders, no shadows.
+
+## 8. Accessibility Constraints & Accepted Debt
+
+### Constraints
+
+- **WCAG goal**: state the target level and the testable scope.
+- **Contrast**: document text, control, and focus-indicator contrast requirements.
+- **Keyboard and focus**: every interactive primitive has a keyboard path and visible focus treatment.
+- **ARIA**: semantic HTML first; document required names, roles, and live-region behavior for custom controls.
+- **Reduced motion**: respect `prefers-reduced-motion` and identify any essential motion.
+
+### Accepted Debt
+
+Each exception records its location, reason, owner, and exit criteria. An agent may not accept accessibility debt or a constraint exception silently: it requires explicit user authorization.
 ```
 
 ## Creation Workflow
@@ -169,13 +191,15 @@ Surfaces use progressively lighter/darker shades. No borders, no shadows.
 ### For New Projects
 
 1. **Ask or infer the product domain** — SaaS dashboard? Marketing site? Dev tool?
-2. **Write the Atmosphere paragraph** — one chance to establish identity.
-3. **Define palette** — derive from atmosphere. Not random. Not generic.
-4. **Set typography** — match the atmosphere. Editorial = serif. Technical = mono-heavy. Clean = geometric sans.
-5. **Lock spacing** — base-4 system. Customize only the section-level values.
-6. **Document initial components** — only those you are about to build.
-7. **Choose depth strategy** — one. Not "a mix."
-8. **Write it to `DESIGN.md`** at project root.
+2. **Write the Research Log** — consider 2-3 relevant local design candidates, select Layer A + Layer B, and record optional local evidence or why it was unavailable.
+3. **Write the Atmosphere paragraph** — one chance to establish identity.
+4. **Define palette** — derive from atmosphere. Not random. Not generic.
+5. **Set typography** — match the atmosphere. Editorial = serif. Technical = mono-heavy. Clean = geometric sans.
+6. **Lock spacing** — base-4 system. Customize only the section-level values.
+7. **Document initial primitives and their states** — enough to pass the Primitive Showcase Gate before composing a product screen.
+8. **Choose depth strategy** — one. Not "a mix."
+9. **Set accessibility constraints and record no debt without user authorization.**
+10. **Write it to `DESIGN.md`** at project root.
 
 ### For Existing Projects (Extraction)
 
@@ -196,6 +220,8 @@ After every component implementation, check:
 - [ ] Depth treatment matches the chosen strategy from Section 7.
 - [ ] Component reused 2+ times? Documented in Section 5.
 - [ ] Motion follows the timing table. No arbitrary durations.
+- [ ] Greenfield primitives have a showcase (or equivalent state page) covering default, hover, focus, disabled, loading, empty, and error before product-screen composition.
+- [ ] Section 8 constraints were checked; any accepted debt has location, reason, owner, exit criteria, and explicit user authorization.
 
 ## Memory Management
 

package/skills/v1/requesting-code-review/SKILL.md

@@ -77,6 +77,8 @@ Two reviewer agents are available, with distinct semantics:
 
 **Default:** `oracle` for simple tasks. Upgrade to both when the orchestrator judges the task complex or large.
 
+`oracle` can also be an optional independent consultation for a high-risk implementation plan. It does not replace the `plan-critic` receipt, does not make dual plan review mandatory, and a timeout or partial response is not a conclusion.
+
 ## Example
 
 ```

package/skills/v1/writing-plans/SKILL.md

@@ -154,24 +154,26 @@ If you find issues, fix them inline. No need to re-review — just fix and move
 
 ## plan-critic Review Loop
 
-After self-review passes, submit the plan to the `plan-critic` agent for a mandatory review loop. The plan-critic agent reads the plan path or inline plan and returns a three-state verdict.
+After self-review passes, submit the plan to the `plan-critic` agent for a mandatory review loop. A review round covers exactly one saved, complete, current plan revision. A current receipt is valid only when that round returns an explicit `[OKAY]` or `[OKAY-UNAMBIGUOUS]`; any plan edit invalidates every earlier receipt.
+
+Timeouts, `WORKING`, acknowledgements, partial output, a missing verdict, or a review of an older/incomplete plan are not approval. Wait for a complete verdict, follow up, or re-dispatch the critic for the current full plan. Dispatch success is not a receipt.
 
 **Loop procedure:**
 
-1. Submit the plan to the `plan-critic` agent (pass the plan file path, or the inline plan if not yet saved).
-2. Dispatch the plan-critic agent and wait for its verdict.
+1. Save the complete plan, then submit that exact plan path to the `plan-critic` agent.
+2. Dispatch the plan-critic agent and wait for one explicit verdict for the current revision.
 3. Branch on the verdict:
 
    | Verdict | Meaning | Action |
    |---|---|---|
-   | `[REJECT]` | Critical blockers exist; plan not executable as-is | Apply the blocker fixes (max 3), re-run self-review, resubmit. Loop. |
+   | `[REJECT]` | Critical blockers exist; plan not executable as-is | Apply the blocker fixes (max 3), re-run self-review, save the updated complete plan, then begin a fresh critic round. |
    | `[OKAY]` | Plan is executable; residual uncertainty/ambiguity remains | Exit the loop. Proceed to user approval (unless delegation applies). |
    | `[OKAY-UNAMBIGUOUS]` | Plan is executable AND logically clear with no ambiguity | Exit the loop. Skip user approval. Proceed to Execution Handoff. |
 
 **Loop cap (user delegation "review N 次就下一步"):**
 
 If the user has delegated with "review N 次就下一步" / "review N times then proceed", cap the loop at N iterations. After N iterations:
-- If still `[REJECT]`: record the unresolved blockers in the plan (as a "Known Unresolved Blockers" section) and proceed anyway. Do not block the workflow.
+- If still `[REJECT]`, or no current receipt exists: record unresolved blockers in the plan (as a "Known Unresolved Blockers" section) and proceed only under the explicit status `delegated-without-plan-approval`. Do not call this approved, passed, or receipted.
 - If `[OKAY]` or `[OKAY-UNAMBIGUOUS]` reached before N: exit early.
 
 **Plan approval conditionality:**
@@ -185,11 +187,13 @@ After the loop exits, determine whether user approval is required:
 
   > "Plan written to `<path>`. plan-critic verdict: `[OKAY]` (executable, residual uncertainty). Please review and approve before execution, or delegate with '你自己决定' / '无需批准自行继续' to proceed."
 
-  Wait for the user's response. If they request changes, make them, re-run self-review, and re-run the plan-critic loop. Only proceed once the user approves or delegates.
+  Wait for the user's response. If they request changes, make them, re-run self-review, and re-run the plan-critic loop for the changed plan. Only proceed once the user approves or delegates.
+
+`oracle` may provide an optional, independent consultation for a high-risk plan, but it never replaces the current `plan-critic` receipt and does not create a mandatory dual-review gate.
 
 ## Execution Handoff
 
-After saving the plan, proceed to the subagent-driven-development skill to execute it.
+Proceed to the subagent-driven-development skill only with a current plan-critic receipt, user approval where required, or an explicitly labeled `delegated-without-plan-approval` exception. Report the current receipt verdict or `waiting for receipt`; never treat a dispatch timeout or acknowledgement as pass.
 
 **Execution:**
 - Fresh subagent per task + completion/integration check after each returned agent + final acceptance review once after all tasks