opencode-agent-skill 11.0.0 → 13.0.0-beta.0

package/docs/DETERMINISTIC-TOOLS.md

@@ -1,6 +1,6 @@
 # Deterministic evidence and execution tools
 
-UES 8 uses dependency-light Node helpers for work that should not rely on a model guessing or remembering it.
+V11 uses dependency-light Node helpers for work that should not rely on a model guessing or remembering it.
 
 ## Repository evidence
 

package/docs/ENGINEERING-DESIGN.md

@@ -1,6 +1,6 @@
 # UES engineering design
 
-UES 8 evolves the project from an engineering workflow harness into a **long-horizon execution engine** designed to reduce context pressure on coding models.
+V11 evolves the project from an engineering workflow harness into a **perception-aware adaptive execution engine** designed to reduce context pressure on coding models while keeping evidence needed for correctness.
 
 The selected model remains the selected model. UES improves orchestration, evidence, task boundaries, state persistence and verification; it does not claim model equivalence.
 
@@ -44,11 +44,11 @@ Models still reason about semantics and read affected code.
 
 ### Progressive disclosure
 
-The catalog remains 39 skills. UES prefers a small active skill set and loads deeper references only when needed.
+The catalog spans 48 skills. UES prefers a small active skill set and loads deeper references only when needed.
 
 ### Hard gates, not reminders
 
-V8 machine-enforces the important boundaries:
+V11 machine-enforces the important boundaries:
 
 1. long/high-risk plans are not executable until a structured plan-verification receipt matches the current plan hash;
 2. long/high-risk task completion requires a successful verification receipt for the active run and the current workspace fingerprint;
@@ -133,7 +133,7 @@ Only UES-managed resources are rewritten/removed.
 
 UES separates:
 
-1. **static skill contract** — 34 scenarios covering the 39-skill catalog;
+1. **static skill contract** — 43 scenarios covering the 48-skill catalog;
 2. **V2 router precision matrix** — 120 required-route/negative-guard cases;
 3. **standard live benchmark** — 20 executable hidden-graded tasks;
 4. **long-horizon benchmark** — 5 tasks, including one 15-source-file integration workload;

package/docs/EVALS.md

@@ -1,10 +1,10 @@
 # UES evaluations
 
-UES 8 separates catalog correctness, routing precision, benchmark integrity, final behavior, long-horizon orchestration and cross-stack coverage.
+V11 separates catalog correctness, routing precision, benchmark integrity, final behavior, long-horizon orchestration and cross-stack coverage.
 
 ## 1. Static skill-routing contract
 
-`evals/routing.json` keeps 34 representative scenarios and covers all installed skills.
+`evals/routing.json` keeps 43 representative scenarios and covers all installed skills.
 
 ```bash
 npm run evals
@@ -141,7 +141,7 @@ Compare the same model, variant, prompt, fixture, grader and environment. Report
 A benchmark result is evidence only for the measured workload. UES does not claim to turn one base model into another.
 
 
-## V8 live-run observability and evidence gate
+## V11 live-run observability and evidence gate
 
 Live runs accept:
 

package/docs/GITHUB-RULESET.md

@@ -0,0 +1,50 @@
+# GitHub Ruleset Readiness
+
+This document records the recommended GitHub repository ruleset configuration for the `main` branch, to be activated only after CI Gate and Security Gate have each achieved at least one successful run.
+
+## Recommended ruleset
+
+- **Ruleset name:** `main-protection`
+- **Target:** default branch / `main`
+- **Enforcement:** Active
+
+## Rules
+
+1. **Restrict deletions** — block deleting the default branch or force-pushing over it.
+2. **Block force pushes** — no `git push --force` or `git push -f` to `main`.
+3. **Require pull request before merge** — all changes must go through a PR.
+4. **Require conversation resolution** — PR reviewers must resolve all inline comments before merge.
+5. **Require status checks** — PRs must have passing CI Gate and Security Gate checks before merge.
+6. **Require branch up to date** — PR branches must be up to date with `main` before merge (applies when there are multiple contributors; can be relaxed for single-maintainer setups).
+7. **Required check: CI Gate** — the aggregate CI check from `.github/workflows/ci.yml`.
+8. **Required check: Security Gate** — the aggregate security check from `.github/workflows/security.yml`.
+
+## Approval policy for single-maintainer repo
+
+This repository currently has one maintainer. Setting `required approval = 1` would prevent the owner from merging their own PRs (they cannot approve their own PR). Therefore:
+
+- **Required approval = 0** for now.
+- When a collaborator or external reviewer is added, raise to `required approval = 1` to restore oversight.
+
+## Classic branch protection vs ruleset
+
+GitHub supports both classic branch protection rules and repository rulesets simultaneously. When both are configured:
+
+- They can apply independently to different aspects of branch protection.
+- Be cautious of duplicate or conflicting protections (e.g., two rules both requiring status checks but with different required lists).
+- If migrating from classic protection to ruleset, remove the classic rule after confirming the ruleset is active and working.
+
+## Activation prerequisite
+
+Do not enable the ruleset until:
+
+1. CI Gate has at least one successful run on `main`.
+2. Security Gate has at least one successful run on `main` or a PR.
+
+Without these prerequisites, the ruleset would block all merges immediately after activation, effectively locking the repository.
+
+## Current status
+
+- **CI Gate:** Added in `.github/workflows/ci.yml`. Awaiting first successful run.
+- **Security Gate:** Added in `.github/workflows/security.yml`. Awaiting first successful run.
+- **Ruleset:** NOT YET ACTIVATED. Will be configured via GitHub admin settings after both gates have successful runs.

package/docs/NPM-PUBLISH.md

@@ -17,7 +17,7 @@ opencode-agent-skill
 npm run ci
 ```
 
-V9 CI includes syntax validation, resource validation, static skill routing, the 120-case V2 router matrix, standard/long/polyglot hidden-grader integrity checks, unit/integration tests, package dry-run, packed global-install smoke, and a plain global-install compatibility smoke.
+CI includes syntax validation, resource validation, static skill routing, the 129-case V2 router matrix, 13 V11 contract tasks, standard/long/polyglot hidden-grader integrity checks, unit/integration tests, package dry-run, packed global-install smoke, and a plain one-command install/resource sync smoke.
 
 ## Manual release-like test
 
@@ -27,36 +27,50 @@ Use:
 
 ```cmd
 npm pack
-npm install -g .\opencode-agent-skill-9.0.0.tgz --allow-scripts=opencode-agent-skill
+npm install -g .\opencode-agent-skill-13.0.0-beta.0.tgz --allow-scripts=opencode-agent-skill
+ocskill install
 ocskill status
 ocskill doctor
 ```
 
+For the current V13 beta, also open a fresh OpenCode V2 session, check `/plugins`, and call `ues.capabilities`. Native parallel should only be exercised when `freshDispatch` is `true`.
+
 For routine development, the automated `smoke:pack` test uses an isolated npm prefix/OpenCode config so it does not replace the developer's currently installed UES.
 
 ## Manual publish
 
+Before publishing, verify the exact prerelease version is not already present:
+
+```cmd
+npm view opencode-agent-skill@13.0.0-beta.0 version --registry=https://registry.npmjs.org/
+```
+
+If it is not present, a manual prerelease publish uses `next`, not `latest`:
+
 ```cmd
 npm login
 npm whoami
 npm run ci
-npm publish --access public
+npm publish --access public --provenance --tag next
 ```
 
 After publication verify:
 
 ```cmd
 npm view opencode-agent-skill versions --json
-npm view opencode-agent-skill@9.0.0 version
+npm view opencode-agent-skill@13.0.0-beta.0 version
 npm dist-tag ls opencode-agent-skill
 ```
 
-The expected release tag is:
+For V13 beta the expected dist-tags are:
 
 ```text
-latest: 9.0.0
+latest: 11.0.0
+next: 13.0.0-beta.0
 ```
 
+Do not move `latest` to V13 until the prerelease is intentionally promoted stable.
+
 ## GitHub Actions publishing
 
 The repository's publish workflow is OIDC/provenance-ready and runs the same package validation before `npm publish`.
@@ -71,7 +85,7 @@ Workflow: publish.yml
 
 Then the GitHub-hosted workflow can authenticate through OIDC instead of a long-lived npm publish token. npm Trusted Publishing requires the corresponding publisher relationship to be configured on npm; repository code alone cannot create that account-side trust relationship.
 
-Until the npm-side Trusted Publisher relationship is configured, the workflow can fall back to a valid `NPM_TOKEN`. After OIDC publishing is verified, remove long-lived publish-token access where practical.
+The current `publish.yml` is tag-only. A matching prerelease tag such as `v13.0.0-beta.0` runs the full package gate and publishes with npm dist-tag `next`; a stable version publishes to `latest`. The workflow first checks whether that exact version already exists and skips duplicate publication.
 
 ## Release checklist
 
@@ -84,7 +98,7 @@ Until the npm-side Trusted Publisher relationship is configured, the workflow ca
 7. Commit and push the release branch.
 8. Merge only after review/local validation is clean.
 9. Create/push the matching `vX.Y.Z` tag or run the publish workflow.
-10. Verify registry version and `latest` dist-tag.
+10. Verify registry version and dist-tags (`next` for prerelease, `latest` for stable).
 11. Install the published package on a clean environment before announcing it.
 
 ## One-command user install

package/docs/OPENCODE-COMPAT.md

@@ -1,6 +1,6 @@
 # OpenCode compatibility
 
-UES 8 ships one npm package for OpenCode 1.x and 2.x, while only enabling V2-native runtime features when V2 is detected.
+V13 ships one npm package for OpenCode 1.x and 2.x. CLI/state/verification features remain available on both lines, while V2-native fresh-session and parallel runtime features are enabled only when the required V2 capabilities are detected.
 
 ## Detection
 
@@ -23,14 +23,14 @@ The detected major is recorded in the managed state.
 
 UES installs:
 
-- 39 namespaced skills
+- 48 namespaced skills
 - 11 namespaced commands
-- 10 namespaced subagents using compatible V1 `permission` frontmatter
+- 12 namespaced subagents using compatible V1 `permission` frontmatter
 - managed global `AGENTS.md` block
 
 The V2 runtime plugin is not installed.
 
-Durable CLI state, task DAG, plan/integration gates and model-policy configuration remain available. V2-specific automatic fresh-session dispatch is unavailable.
+Durable CLI state, task DAG, plan/integration gates, Windows UTF text recovery and model-policy configuration remain available. `ues.dispatch_task` and `ues.dispatch_parallel` are unavailable because those tools live in the V2 router plugin.
 
 ## OpenCode 2.x
 
@@ -40,6 +40,8 @@ UES converts managed agent permission frontmatter to V2 ordered `permissions` an
 <global-config>/plugins/ues-router/
 ```
 
+V13 also installs the 11 UES slash-command templates inside the managed router as V2 **prompt aliases** instead of registering them as native global custom commands. Typing `/ues-run ...`, `/ues-fix ...`, and the other `/ues-*` aliases therefore travels through `session.prompt`; the router expands the same bundled command contract before routing skills. This is a compatibility workaround for V2 custom-command transport failures such as `UnsupportedContentType` from the `session.command` path. Re-syncing with `ocskill install` removes stale UES-managed native command files from older installs.
+
 The plugin provides:
 
 - prompt-admission skill routing
@@ -48,6 +50,7 @@ The plugin provides:
 - durable-state/task-graph/context-pack tools
 - `ues.dispatch_task` bounded fresh executor runtime
 - `ues.cancel_task` and `ues.recover_task` when session interruption is supported
+- `ues.dispatch_parallel` when the full fresh-dispatch surface is present; it runs independent approved tasks in isolated same-model sessions, verifies each task independently, and serializes integration
 
 `ues.dispatch_task` uses V2 session APIs to create a fresh session rooted at the selected execution directory, bind its session ID to the task lease, select `ues-executor`, optionally switch model tier, prompt one approved task, heartbeat while waiting, and interrupt on timeout. Concurrent writing tasks can be isolated in Git worktrees.
 
@@ -110,3 +113,10 @@ The managed V2 plugin probes for:
 - permission hooks
 
 `ues.capabilities` exposes the observed surface. Fresh dispatch fails closed when the minimum create/prompt/wait/interrupt/context/switch-agent surface is unavailable. Optional context/prompt/permission hooks degrade safely instead of preventing the plugin from loading.
+
+
+## V13 parallel compatibility
+
+`ues.dispatch_parallel` is capability-gated, not version-string-gated. It requires the complete fresh-dispatch surface reported by `ues.capabilities`: session create, prompt, wait, interrupt, context retrieval and agent switching. If any required API is missing, V13 fails closed and the durable CLI workflow remains usable in serial mode.
+
+OpenCode 1.x users can still use V13 CLI hardening, durable `.ues-work/<slug>/` state, receipts, task graphs and Windows text normalization. To use native multi-session parallel execution, use a runtime that exposes the V2 fresh-session APIs.

package/docs/TRACE-SCHEMA.md

@@ -75,7 +75,7 @@ Keep constant:
 Compare observable success, regressions, elapsed time, tool behavior and cost rather than narrative confidence.
 
 
-## V8 runtime and evidence fields
+## V11 runtime and evidence fields
 
 Each live result may additionally contain:
 

package/docs/V11-PERCEPTION-ADAPTIVE.md

@@ -1,6 +1,6 @@
 # UES V11 — Perception & Adaptive Execution
 
-Status: development (`11.0.0-dev.1`). V10 remains npm `latest` until the V11 release gates pass.
+Status: stable (`11.0.0`). V11 is npm `latest`.
 
 ## Goal
 
@@ -211,7 +211,7 @@ Do not promote V11 to stable until all are satisfied:
 7. Packed and plain npm-install smoke tests pass.
 8. Real weak-model evaluation shows no suite regression.
 9. Any configured cache/evidence target has sufficient telemetry and passes.
-10. npm `latest` remains V10 until the V11 candidate completes these gates.
+10. npm `latest` is V11 stable; no release gate prevents promotion.
 
 ## Compatibility
 

package/docs/V12-WEAK-MODEL-INTELLIGENCE.md

@@ -0,0 +1,27 @@
+# V12 Weak-Model Intelligence Foundation
+
+Status: beta prerelease (`12.0.0-beta.0`, npm dist-tag `next`). V11 (`11.0.0`) remains the stable `latest` release until V12 earns stable-release evidence.
+
+## Goal
+
+V12 focuses on making weaker coding models more reliable on large repositories by improving measured context quality, empirical model routing, plan identity, bounded autonomous decisions, and repo-scale evaluation. It does not claim that orchestration makes one base model equivalent to a stronger model.
+
+## Foundations
+
+- Empirical model performance: observed pass rate, retries, token use and latency can rerank capability-eligible models by task class.
+- Context quality receipts: adaptive context reports required-file recall and irrelevant-context ratio.
+- Plan-scoped snapshots: every imported plan gets a SHA-256 keyed snapshot and active-plan fence before execution.
+- Decision policy: reversible local engineering choices can be auto-resolvable; publish/deploy/destructive/product decisions remain human-gated.
+- Repo-scale contract suite: deterministic generation of a 300-module monorepo fixture for larger-repository validation.
+
+## Release policy
+
+V12 is not stable merely because unit tests pass. Promotion requires healthy GitHub CI/Security gates, repo-scale validation, real weak-model baseline-vs-UES trials, no regression in existing suites, measured context recall, sufficient empirical routing samples, and Windows/Linux package/install smoke evidence.
+
+## Beta install
+
+```cmd
+npm install -g opencode-agent-skill@next
+ocskill install
+ocskill doctor
+```

package/docs/V13-PARALLEL-WEAK-MODEL-RUNTIME.md

@@ -0,0 +1,75 @@
+# V13 Parallel Weak-Model Runtime
+
+Status: beta prerelease (`13.0.0-beta.0`).
+
+## Goal
+
+V13 reduces wall-clock time for large engineering work by letting multiple fresh sessions of the **same configured model** execute independent approved tasks concurrently without sharing mutable context.
+
+## Runtime contract
+
+- `ues.dispatch_parallel` defaults to one shared model for every worker and verifier.
+- The root must be a Git repository. A pre-existing dirty working tree is allowed: V13 snapshots that baseline into each sandbox and integrates only the task delta, so valid inherited/user changes are preserved.
+- Writers execute in isolated Git worktrees.
+- Resource leases serialize overlapping files, unknown scope and shared configuration surfaces.
+- The scheduler is event-driven: when one task is independently verified, transactionally integrated and completed, newly unblocked dependencies may start immediately.
+- Initial and downstream sandboxes inherit the current dirty root through an internal snapshot commit on the sandbox branch; the user's root branch is never auto-committed.
+- A fresh `ues-verifier` session using the same model must return PASS before integration.
+- Integration is serialized. If receipt/completion fails after patch application, V13 reverses that task patch before marking the run failed.
+- No parallel worker pushes, publishes or deploys.
+
+## Same-model execution
+
+One model is sufficient. Parallelism means multiple isolated sessions, not multiple model families:
+
+```text
+provider/weak-model
+  ├─ fresh session A
+  ├─ fresh session B
+  ├─ fresh session C
+  └─ fresh verifier sessions
+```
+
+If no explicit model is supplied, the configured executor model is shared. If no configured model is selected, all sessions keep the OpenCode default model.
+
+## Runtime compatibility
+
+V13 keeps CLI, durable state, receipts, task graphs and Windows text hardening available on OpenCode 1.x. Native `ues.dispatch_task` and `ues.dispatch_parallel` require the V2 router plugin plus the fresh-session capability surface. The router checks capabilities at runtime and fails closed if create/prompt/wait/interrupt/context/switch-agent are incomplete.
+
+When npm blocks lifecycle scripts (common with stricter npm 11+ `allowScripts` policy), install still leaves the CLI available; run `ocskill install` to perform the documented resource sync explicitly.
+
+## CLI hardening
+
+V13 parses `--help` before positional arguments, so commands such as these are safe:
+
+```cmd
+ocskill work init --help
+ocskill work status --help
+ocskill work gate-receipt --help
+```
+
+`ocskill work status .` now lists durable workspaces instead of treating `.` as a slug.
+
+For machine callers, append `--json` to receive structured errors.
+
+On Windows, prefer:
+
+```cmd
+ocskill diff . --out dirty.diff
+```
+
+This writes UTF-8 directly and avoids PowerShell 5 redirection producing UTF-16 text that generic readers may classify as binary. On OpenCode 1.x, where the V2 `ues.text_read` tool is unavailable, read known text safely without creating a converted copy:
+
+```cmd
+ocskill text-read .ues-work/<slug>/PLAN.json --json
+```
+
+Existing UTF-8/UTF-16 text can be normalized with:
+
+```cmd
+ocskill normalize-text dirty.diff
+```
+
+## Release evidence
+
+V13 remains beta until parallel execution demonstrates measurable wall-clock improvement without reducing correctness, and Windows/Linux CI proves help parsing, encoding, dirty-baseline worktree inheritance, rollback, verifier receipts and package installation.

package/evals/repo-scale/tasks.json

@@ -0,0 +1,62 @@
+{
+  "version": 1,
+  "kind": "repo-scale-contract-suite",
+  "description": "Deterministic large-repository contract tasks used to validate V12 weak-model context/routing foundations before live model runs.",
+  "minimumGeneratedModules": 300,
+  "tasks": [
+    {
+      "id": "cross-package-regression",
+      "category": "repo-scale",
+      "objective": "Trace a regression across package boundaries without loading the entire generated monorepo into context.",
+      "requiredFiles": [
+        "packages/pkg-0/src/mod049.mjs",
+        "packages/pkg-1/src/mod049.mjs"
+      ],
+      "acceptance": [
+        "Required-file context recall is measurable",
+        "Unrelated packages stay bounded"
+      ]
+    },
+    {
+      "id": "public-contract-ripple",
+      "category": "contract",
+      "objective": "Change a public API field and identify the API producer and web consumer that must move together.",
+      "requiredFiles": [
+        "contracts/public-api.json",
+        "apps/api/src/service.mjs",
+        "apps/web/src/consumer.mjs"
+      ],
+      "acceptance": [
+        "Contract producer and consumer are both discovered",
+        "Change-impact evidence is explicit"
+      ]
+    },
+    {
+      "id": "deep-chain-debug",
+      "category": "debugging",
+      "objective": "Diagnose a defect near the end of a fifty-module import chain using bounded evidence expansion.",
+      "requiredFiles": [
+        "packages/pkg-2/src/mod048.mjs",
+        "packages/pkg-2/src/mod049.mjs"
+      ],
+      "acceptance": [
+        "Initial context remains bounded",
+        "Recovery can expand around the failing chain"
+      ]
+    },
+    {
+      "id": "multi-package-refactor",
+      "category": "refactor",
+      "objective": "Coordinate a refactor touching several package endpoints while serializing shared contract writes.",
+      "requiredFiles": [
+        "packages/pkg-3/src/index.mjs",
+        "packages/pkg-4/src/index.mjs",
+        "contracts/public-api.json"
+      ],
+      "acceptance": [
+        "Cross-package scope is explicit",
+        "Shared contract changes are treated as a write-conflict surface"
+      ]
+    }
+  ]
+}

package/global-config/AGENTS.md

@@ -34,8 +34,10 @@ Useful deterministic helpers include:
 
 - `ocskill inspect [dir]`
 - `ocskill impact <symbol-or-term> [dir]`
+- `ocskill repo-graph [dir] --compact` for an initial hotspot summary; request the full graph only when exact edge detail is needed
 - `ocskill aci search|refs|view|text ...`
 - `ocskill working-tree [dir]`
+- `ocskill text-read <file> --json` when OpenCode/generic readers classify known UTF text as binary
 - `ocskill verification-plan [dir]`
 - `ocskill context-pack <slug> <task> [dir]`
 - `ocskill work verify-command ... -- <command>`
@@ -111,6 +113,8 @@ Never claim a test, build, migration, deployment, push or release succeeded unle
 
 For interruption-prone or dependent multi-task work, use durable `.ues-work/<slug>/` state instead of relying on conversation memory.
 
+`.ues-work/<slug>/` is the only UES durable-state location. Never create or treat a top-level `ues-work/` directory (without the leading dot) as official UES state, even if an older/manual run left files there. On resume, prefer the initialized `.ues-work/<slug>/` item plus current Git evidence.
+
 The required sequence is:
 
 `SPEC -> PLAN -> plan check/receipt -> approved tasks -> fresh executor per task -> task verification receipts -> integration verification/receipt -> finalize`

package/global-config/commands/resume.md

@@ -7,10 +7,13 @@ Resume this UES work item: $ARGUMENTS
 
 Read the matching `.ues-work/<slug>/SPEC.md`, `PLAN.json`, `STATE.json`, `EVIDENCE.json`, task reports and current Git status. Run `ocskill work resume <slug> .` and revalidate assumptions that may have gone stale.
 
+Ignore a top-level `ues-work/` directory as official workflow state. Only `.ues-work/<slug>/` created/managed by `ocskill work` is canonical durable state.
+
 Trust durable task state and Git evidence over conversational recollection. Respect the machine gates:
 - if the plan is awaiting approval, run `ues-plan-checker` and record PASS with `ocskill work approve-plan`;
 - resume failed/pending work from the last verified boundary;
-- on OpenCode V2 prefer `ues.dispatch_task` for a fresh executor and configured model escalation;
+- on OpenCode V2, prefer `ues.dispatch_parallel` when two or more dependency-ready tasks have independent declared write/resource scopes; otherwise use `ues.dispatch_task` for a fresh executor. Keep one shared model for parallel worker/verifier sessions unless the user explicitly changes the design;
+- do not force-clean inherited user changes just to enable parallel resume; V13 snapshots an existing dirty Git baseline into isolated worktrees and integrates only each task delta;
 - do not repeat completed tasks unless fresh evidence invalidates them;
 - after all tasks complete, run `ues-integration-verifier`, record its verdict with `ocskill work verify-integration`, then finalize only after PASS and an unchanged workspace fingerprint.
 

package/global-config/commands/run.md

@@ -7,20 +7,22 @@ Run this task using the UES long-horizon workflow: $ARGUMENTS
 
 Treat this command as permission to create a repository-local, git-ignored `.ues-work/<slug>/` execution workspace for durable non-secret planning state.
 
+Never create or use `ues-work/` (without the leading dot) as durable UES state. If such a directory exists from an older/manual run, treat it as ordinary repository content unless the user explicitly asks to migrate it; official state must come from `ocskill work init` under `.ues-work/<slug>/`.
+
 Required workflow:
-1. Classify the request with `ocskill task-policy "$ARGUMENTS"`. Use the returned risk/mode/context guidance rather than assuming every non-trivial task needs the same workflow.
-2. Inspect repository instructions and deterministic evidence with `ocskill inspect`, `ocskill repo-graph`, and targeted impact searches.
+1. Classify the request with `ocskill task-policy "<concise task summary>"`. Do not duplicate the full user prompt into shell arguments; use the returned risk/mode/context guidance rather than assuming every non-trivial task needs the same workflow.
+2. Inspect repository instructions and deterministic evidence with `ocskill inspect`, `ocskill repo-graph . --compact`, and targeted impact searches. Expand to the full graph only when exact edge detail is needed.
 3. Create a concise SPEC with observable acceptance criteria.
 4. Initialize persistent state with `ocskill work init`.
 5. Produce a file-aware `PLAN.json` using the UES plan schema, then import it with `ocskill work plan`.
 6. Dispatch `ues-plan-checker` in fresh context. For long/high-risk work, bind the PASS to the current plan with a structured receipt, then approve it:
    `ocskill work gate-receipt <slug> plan . --verifier ues-plan-checker --evidence "<summary>" --out .ues-work/<slug>/reports/plan-receipt.json`
    followed by `ocskill work approve-plan <slug> . --evidence "<summary>" --receipt-file .ues-work/<slug>/reports/plan-receipt.json`.
-7. Use `ocskill task-graph` and execute only ready dependency-safe tasks. On OpenCode V2 prefer `ues.dispatch_task`: it starts the task, creates a fresh `ues-executor` session, applies configured attempt-based model escalation, waits for that executor, and returns its report. Inspect the diff and evidence, then record `ocskill work complete` or `ocskill work fail`.
-8. Independent tasks may run concurrently only when safe-wave analysis reports no write/read conflict. V8 can isolate concurrent writers in Git worktrees and integrate them with conflict detection; manual fallback is `ocskill sandbox create ...` followed by `ocskill sandbox integrate <worktree> .`. Never integrate over overlapping dirty root files.
-9. During long execution keep the task lease alive with `ocskill work heartbeat` (the V2 dispatcher does this automatically). On resume, `ocskill work recover` or `ocskill work resume` recovers expired leases instead of leaving tasks stuck in `running`.
-10. Run declared checks through `ocskill work verify-command <slug> <task> . --run-id <run-id> -- <command> [args...]`. For long/high-risk plans, a successful receipt for the active run is mandatory before `work complete`; narrative-only completion is rejected.
-11. On executor failure, diagnose from fresh evidence and retry in a fresh executor. Adaptive model policy may raise the model tier based on risk/complexity plus attempt count; do not escalate blindly.
+7. Use `ocskill task-graph` and execute only dependency-ready tasks. On OpenCode V2, when two or more independent tasks are ready, prefer `ues.dispatch_parallel`. V13 uses multiple fresh sessions of one shared model, not multiple model families. For a single task or a deliberately serial path, use `ues.dispatch_task`.
+8. `ues.dispatch_parallel` is event-driven rather than wave-barrier driven: as soon as a task is independently verified, transactionally integrated and durably completed, newly unblocked dependencies may start in the next free worker slot. Resource leases serialize overlapping writers, unknown scopes and shared configuration surfaces.
+9. Each parallel writer gets an isolated Git worktree. A pre-existing dirty root is treated as an inherited baseline, and downstream worktrees also inherit already integrated root changes through an internal sandbox snapshot; only task-local deltas are integrated and the user's root branch is not auto-committed. Integration is serialized and rolled back if post-integration verification/receipt/completion fails.
+10. For machine-checkable verification, add `verificationCommands` to the approved task, for example `{"command":"node","args":["--test","test/foo.test.mjs"]}`. V13 runs these exact commands after integration via `ocskill work verify-command`, records deterministic receipts, then also records the fresh independent verifier verdict. For long/high-risk plans, current-fingerprint receipt evidence remains mandatory.
+11. During long execution keep task leases alive (the V2 dispatcher does this automatically). On resume, `ocskill work recover` or `ocskill work resume` recovers expired leases instead of leaving tasks stuck in `running`. In parallel mode, keep one shared model for all worker/verifier sessions unless the user explicitly changes the run design.
 12. After all tasks complete, dispatch `ues-integration-verifier`. For PASS on long/high-risk work, create an integration receipt bound to the current workspace fingerprint:
    `ocskill work gate-receipt <slug> integration . --verifier ues-integration-verifier --verdict PASS --evidence "<summary>" --out .ues-work/<slug>/reports/integration-receipt.json`
    then record it with `ocskill work verify-integration <slug> . --verdict PASS --evidence "<summary>" --receipt-file .ues-work/<slug>/reports/integration-receipt.json`.

package/global-config/plugins/ues-router/capabilities.js

@@ -11,6 +11,7 @@ export function runtimeCapabilities(ctx) {
     sessionSwitchModel: typeof session.switchModel === "function",
     sessionHook: typeof session.hook === "function",
     permissionHook: typeof permission.hook === "function",
+    permissionRules: typeof permission.rules === "function",
   }
   capabilities.freshDispatch =
     capabilities.sessionCreate &&

package/global-config/plugins/ues-router/command-runtime.js

@@ -0,0 +1,79 @@
+import { existsSync, readFileSync } from "node:fs"
+import path from "node:path"
+
+export const UES_PROMPT_ALIASES = Object.freeze([
+  "ues-audit",
+  "ues-critique",
+  "ues-debug",
+  "ues-feature",
+  "ues-fix",
+  "ues-plan",
+  "ues-research",
+  "ues-resume",
+  "ues-review",
+  "ues-run",
+  "ues-verify",
+])
+
+const ALIAS_SET = new Set(UES_PROMPT_ALIASES)
+
+function parseFrontmatter(source) {
+  const text = String(source || "")
+  if (!text.startsWith("---")) return { metadata: {}, body: text }
+  const end = text.indexOf("\n---", 3)
+  if (end < 0) return { metadata: {}, body: text }
+
+  const block = text.slice(3, end).trim()
+  const metadata = {}
+  for (const line of block.split(/\r?\n/)) {
+    const match = line.match(/^([A-Za-z0-9_-]+):\s*(.*)$/)
+    if (!match) continue
+    metadata[match[1]] = match[2].trim()
+  }
+
+  return {
+    metadata,
+    body: text.slice(end + 4).replace(/^\r?\n/, ""),
+  }
+}
+
+function splitArgs(input) {
+  const value = String(input || "")
+  const matches = value.match(/"[^"]*"|'[^']*'|\S+/g) || []
+  return matches.map((item) => item.replace(/^(['"])([\s\S]*)\1$/, "$2"))
+}
+
+export function expandUesPromptAlias(text, templateDir) {
+  const raw = String(text || "")
+  const match = raw.match(/^\s*\/(ues-[a-z0-9]+(?:-[a-z0-9]+)*)(?:\s+([\s\S]*?))?\s*$/i)
+  if (!match) return null
+
+  const alias = match[1].toLowerCase()
+  if (!ALIAS_SET.has(alias)) return null
+
+  const args = String(match[2] || "").trim()
+  const sourceName = alias.slice("ues-".length) + ".md"
+  const file = path.join(templateDir, sourceName)
+  if (!existsSync(file)) return null
+
+  const { metadata, body } = parseFrontmatter(readFileSync(file, "utf8"))
+  const positional = splitArgs(args)
+  let expanded = body.replaceAll("$ARGUMENTS", args)
+  expanded = expanded.replace(/\$(\d+)/g, (_, value) => positional[Number(value) - 1] || "")
+
+  const agent = metadata.agent || null
+  const prelude = [
+    `UES V2 prompt alias: /${alias}. Preserve the command contract below while using the normal session.prompt path.`,
+    agent && agent !== "build"
+      ? `Preferred specialist: ${agent}. When fresh subagent dispatch is available, delegate to that specialist and preserve the command's read/write restrictions.`
+      : null,
+  ].filter(Boolean).join("\n")
+
+  return {
+    alias,
+    arguments: args,
+    agent,
+    sourceName,
+    text: `${prelude}\n\n${expanded.trim()}`,
+  }
+}