oh-my-opencode 5.1.4 → 5.1.6

package/dist/plugin-config/omo-config-chain.d.ts

@@ -1,14 +1,12 @@
-import { type OmoConfigEnv } from "@oh-my-opencode/omo-config-core";
+import { type OmoConfigDiagnostic, type OmoConfigEnv, type OmoModelReferenceDiagnostic } from "@oh-my-opencode/omo-config-core";
 export type OmoOpenCodeConfigView = {
     readonly config: Record<string, unknown>;
+    /** Where the view sits in its file (`[opencode].`, `profiles.<P>.`), so a diagnostic names the full key. */
+    readonly keyPrefix: string;
     readonly path: string;
 };
 export type OmoOpenCodeConfigChain = {
-    readonly diagnostics: readonly {
-        readonly kind?: string;
-        readonly message: string;
-        readonly path: string;
-    }[];
+    readonly diagnostics: readonly (OmoConfigDiagnostic | OmoModelReferenceDiagnostic)[];
     readonly protectedUserView: Record<string, unknown>;
     readonly views: readonly OmoOpenCodeConfigView[];
 };

package/dist/skills/browser/runtime/omowright/manifest.json

@@ -5,5 +5,5 @@
     "index.js": "b6b064fab277031c6c51f5a58b84b31040f9960bf767bf646adc0540c1d25c1b",
     "page-bundle.js": "bfd51e8383cf47200d57387bbbed258bce5a3a3d00c38fc108034d2888e23f0c"
   },
-  "stagedAtUtc": "2026-09-29T22:24:49.560Z"
+  "stagedAtUtc": "2026-09-30T18:48:09.721Z"
 }

package/dist/skills/ulw-execute/SKILL.md

@@ -53,7 +53,7 @@ Do ALL of this immediately after the plan is selected, BEFORE the first implemen
 
 1. **Set the goal, in detail.** When a goal tool is available (`create_goal`), call it with a DETAILED objective: the plan name and path, the concrete end state, the phase and task counts, the delivery mode (direct, `--make-pr`, or `--ship`), and how completion will be verified. One work session = one registered goal (the goal tool holds one active goal); each phase then carries its own concrete goal — the ledger entry Phase 2 records before the wave's first dispatch, defined from the previous phase's landed and verified evidence. No goal tool -> record the same objective as the first ledger entry.
 2. **Register every phase and task as todos.** Mirror the plan into the todo/plan tool of your harness: one phase per plan wave, one todo per column-zero checkbox (including the final verification wave). Register ALL of them up front - never keep tasks in memory only.
-3. **Keep them current at every moment.** Mark a todo in_progress when its work dispatches and done immediately after its verification passes. Never batch-complete at the end, never execute work that is not a registered todo; discovered work — a pre-existing bug, failing test, stale doc, or wrong guidance — is appended to the plan as a checkbox, mirrored as a todo before it runs, and fixed to the ideal state, never deferred as a follow-up. A worker that meets a defect outside its assigned files reports it instead of fixing it; only the orchestrator appends the checkbox and dispatches it to a correctly scoped unit. The todo list, Boulder state, and plan checkboxes must always tell the same story.
+3. **Keep them current at every moment.** Mark a todo in_progress when its work dispatches and done immediately after its verification passes. Never batch-complete at the end, never execute work that is not a registered todo; discovered work inside the change's blast radius — the request not delivered, a regression this change introduces, an invalid proof, a failing test or stale doc of touched code — is appended to the plan as a checkbox, mirrored as a todo before it runs, and fixed to the ideal state; a defect outside it gets a tracked issue with reproduction and evidence and a line in the final report. A worker that meets a defect outside its assigned files reports it instead of fixing it; only the orchestrator appends the checkbox and dispatches it to a correctly scoped unit. The todo list, Boulder state, and plan checkboxes must always tell the same story.
 
 ## Phase 1: Select the plan