oh-my-opencode 4.13.0 → 4.14.1

package/packages/omo-codex/plugin/skills/teammode/scripts/team-state.mjs

@@ -9,8 +9,9 @@
 // this file stays the state concern only.
 
 import { randomUUID } from "node:crypto";
-import { lstat, mkdir, readFile, rename, writeFile } from "node:fs/promises";
+import { lstat, mkdir, readFile, rename, rm, writeFile } from "node:fs/promises";
 import { dirname, isAbsolute, join, relative, resolve } from "node:path";
+import { setTimeout as delay } from "node:timers/promises";
 
 export const LENSES = ["area", "ownership", "perspective"];
 export const MEMBER_STATUSES = ["pending", "active", "reported", "blocked", "archived"];
@@ -24,6 +25,8 @@ export function isUnderstaffed(team) {
 // A team dir is a single child of .omo/teams. This pattern alone blocks "/", "\", and a
 // leading "." so ".." and "a/b" can never name a team dir (the escape guard).
 const SESSION_ID_PATTERN = /^[A-Za-z0-9][A-Za-z0-9._-]{0,127}$/;
+const LOCK_TIMEOUT_MS = Number.parseInt(process.env.OMO_TEAMMODE_LOCK_TIMEOUT_MS ?? "10000", 10);
+const LOCK_RETRY_MS = Number.parseInt(process.env.OMO_TEAMMODE_LOCK_RETRY_MS ?? "25", 10);
 
 function isoNow(now) {
 	return now ?? new Date().toISOString();
@@ -233,6 +236,65 @@ async function lstatOrNull(p) {
 	});
 }
 
+function positiveIntegerOrFallback(value, fallback) {
+	return Number.isInteger(value) && value > 0 ? value : fallback;
+}
+
+async function readLockOwner(lockDir) {
+	return readFile(join(lockDir, "owner.json"), "utf8")
+		.then((content) => JSON.parse(content))
+		.catch(() => null);
+}
+
+async function describeLockOwner(lockDir) {
+	const owner = await readLockOwner(lockDir);
+	if (!owner || typeof owner !== "object") return "another team.mjs command";
+	const parts = [];
+	if (owner.command) parts.push(String(owner.command));
+	if (owner.pid) parts.push(`pid ${owner.pid}`);
+	if (owner.createdAt) parts.push(`since ${owner.createdAt}`);
+	return parts.length > 0 ? parts.join(", ") : "another team.mjs command";
+}
+
+export async function withTeamLock(dir, command, fn, options = {}) {
+	const timeoutMs = positiveIntegerOrFallback(options.timeoutMs ?? LOCK_TIMEOUT_MS, 10000);
+	const retryMs = positiveIntegerOrFallback(options.retryMs ?? LOCK_RETRY_MS, 25);
+	const lockDir = join(dir, ".team.lock");
+	const deadline = Date.now() + timeoutMs;
+	let acquired = false;
+	for (;;) {
+		try {
+			await mkdir(lockDir, { mode: 0o700 });
+			acquired = true;
+			await writeFile(
+				join(lockDir, "owner.json"),
+				`${JSON.stringify({ pid: process.pid, command, createdAt: new Date().toISOString() }, null, 2)}\n`,
+				{ encoding: "utf8", flag: "wx" },
+			);
+			break;
+		} catch (error) {
+			if (acquired) {
+				await rm(lockDir, { recursive: true, force: true });
+				throw error;
+			}
+			if (!error || error.code !== "EEXIST") throw error;
+			const st = await lstatOrNull(lockDir);
+			if (st?.isSymbolicLink()) throw new Error(`refused: team lock path is a symlink: ${lockDir}`);
+			if (st && !st.isDirectory()) throw new Error(`refused: team lock path is not a directory: ${lockDir}`);
+			if (Date.now() >= deadline) {
+				const owner = await describeLockOwner(lockDir);
+				throw new Error(`team state is locked by ${owner}; retry after that command completes`);
+			}
+			await delay(Math.min(retryMs, Math.max(1, deadline - Date.now())));
+		}
+	}
+	try {
+		return await fn();
+	} finally {
+		await rm(lockDir, { recursive: true, force: true });
+	}
+}
+
 // Create a directory chain refusing any symlinked component, so team state can never be
 // written through a symlink that escapes the workspace.
 async function mkdirNoSymlink(dir, stopAt) {

package/packages/omo-codex/plugin/skills/teammode/scripts/team.mjs

@@ -20,7 +20,7 @@ import { randomUUID } from "node:crypto";
 import { realpathSync } from "node:fs";
 import { rm } from "node:fs/promises";
 import { fileURLToPath, pathToFileURL } from "node:url";
-import { buildGuide, buildMemberPrompt } from "./team-guide.mjs";
+import { buildGuide, buildMemberPrompt, codexThreadLink } from "./team-guide.mjs";
 import {
 	addMember,
 	archive,
@@ -35,6 +35,7 @@ import {
 	setMemberStatus,
 	setMemberWorktree,
 	teamExists,
+	withTeamLock,
 	writeGuideAtomic,
 	writeTeamAtomic,
 } from "./team-state.mjs";
@@ -82,57 +83,71 @@ async function persist(team, dir) {
 	await writeGuideAtomic(team, buildGuide(team), dir);
 }
 
+async function mutateTeam(cwd, sessionId, command, fn) {
+	const dir = await assertSafeTeamDir(cwd, sessionId);
+	return withTeamLock(dir, command, async () => {
+		const team = await readTeam(dir);
+		return fn(team, dir);
+	});
+}
+
 const handlers = {
 	async init(cwd, flags) {
 		const teamName = requireFlag(flags, "name");
 		const sessionName = requireFlag(flags, "session-name");
 		const sessionId = typeof flags.session === "string" ? flags.session : `team-${randomUUID().slice(0, 8)}`;
 		const dir = await ensureTeamDir(cwd, sessionId);
-		if (await teamExists(dir)) {
-			process.stdout.write(`exists: ${dir} (left untouched; re-init is a safe no-op)\n`);
-			return;
-		}
-		const team = buildTeam({
-			teamName,
-			sessionName,
-			sessionId,
-			dir,
-			worktreeEnabled: flags.worktree === true,
-			baseBranch: typeof flags["base-branch"] === "string" ? flags["base-branch"] : "dev",
+		await withTeamLock(dir, "init", async () => {
+			if (await teamExists(dir)) {
+				process.stdout.write(`exists: ${dir} (left untouched; re-init is a safe no-op)\n`);
+				return;
+			}
+			const team = buildTeam({
+				teamName,
+				sessionName,
+				sessionId,
+				dir,
+				worktreeEnabled: flags.worktree === true,
+				baseBranch: typeof flags["base-branch"] === "string" ? flags["base-branch"] : "dev",
+			});
+			await persist(team, dir);
+			process.stdout.write(`created: ${dir}\n`);
+			process.stdout.write(`team.json + guide.md written; artifacts/ ready. session id: ${sessionId}\n`);
+			process.stdout.write(`next: add-member --team ${sessionId} --id A --name "<short role>" --focus "<part/ownership/perspective>" --lens area|ownership|perspective --deliverable "<...>"\n`);
 		});
-		await persist(team, dir);
-		process.stdout.write(`created: ${dir}\n`);
-		process.stdout.write(`team.json + guide.md written; artifacts/ ready. session id: ${sessionId}\n`);
-		process.stdout.write(`next: add-member --team ${sessionId} --id A --name "<short role>" --focus "<part/ownership/perspective>" --lens area|ownership|perspective --deliverable "<...>"\n`);
 	},
 
 	async "add-member"(cwd, flags) {
 		const sessionId = requireFlag(flags, "team");
-		const { dir, team } = await loadTeam(cwd, sessionId);
 		const memberId = requireFlag(flags, "id").trim();
-		addMember(team, {
+		const memberInput = {
 			id: memberId,
 			name: typeof flags.name === "string" ? flags.name : null,
 			focus: requireFlag(flags, "focus"),
 			lens: requireFlag(flags, "lens"),
 			deliverable: typeof flags.deliverable === "string" ? flags.deliverable : "",
 			branch: typeof flags.branch === "string" ? flags.branch : null,
+		};
+		const { team, member } = await mutateTeam(cwd, sessionId, "add-member", async (team, dir) => {
+			addMember(team, memberInput);
+			await persist(team, dir);
+			return { team, member: team.members.find((m) => m.id === memberId) };
 		});
-		await persist(team, dir);
-		const member = team.members.find((m) => m.id === memberId);
 		process.stdout.write(`added member ${memberId} to team ${sessionId}.\n\nSend this as the new thread's first message (title the thread "${member.threadTitle}"):\n---\n${buildMemberPrompt(team, memberId)}\n---\n`);
 	},
 
 	async "bind-thread"(cwd, flags) {
 		const sessionId = requireFlag(flags, "team");
-		const { dir, team } = await loadTeam(cwd, sessionId);
-		bindThread(team, {
+		const input = {
 			id: requireFlag(flags, "id"),
 			threadId: requireFlag(flags, "thread"),
 			cwd: typeof flags.cwd === "string" ? flags.cwd : null,
 			worktreePath: typeof flags["worktree-path"] === "string" ? flags["worktree-path"] : null,
+		};
+		await mutateTeam(cwd, sessionId, "bind-thread", async (team, dir) => {
+			bindThread(team, input);
+			await persist(team, dir);
 		});
-		await persist(team, dir);
 		process.stdout.write(`bound member ${flags.id} to thread ${flags.thread}.\n`);
 	},
 
@@ -144,38 +159,49 @@ const handlers = {
 
 	async "set-status"(cwd, flags) {
 		const sessionId = requireFlag(flags, "team");
-		const { dir, team } = await loadTeam(cwd, sessionId);
-		setMemberStatus(team, {
+		const input = {
 			id: requireFlag(flags, "id"),
 			status: requireFlag(flags, "status"),
 			note: typeof flags.note === "string" ? flags.note : "",
+		};
+		await mutateTeam(cwd, sessionId, "set-status", async (team, dir) => {
+			setMemberStatus(team, input);
+			await persist(team, dir);
 		});
-		await persist(team, dir);
 		process.stdout.write(`member ${flags.id} -> ${flags.status}\n`);
 	},
 
 	async "worktree-add"(cwd, flags) {
 		const sessionId = requireFlag(flags, "team");
-		const { dir, team } = await loadTeam(cwd, sessionId);
-		const member = memberOrThrow(team, requireFlag(flags, "id"));
-		const result = addMemberWorktree(cwd, team, member, {
-			baseBranch: typeof flags["base-branch"] === "string" ? flags["base-branch"] : null,
+		const memberId = requireFlag(flags, "id");
+		const baseBranch = typeof flags["base-branch"] === "string" ? flags["base-branch"] : null;
+		const { member, result } = await mutateTeam(cwd, sessionId, "worktree-add", async (team, dir) => {
+			const member = memberOrThrow(team, memberId);
+			const result = addMemberWorktree(cwd, team, member, { baseBranch });
+			setMemberWorktree(team, { id: member.id, path: result.path, branch: result.branch });
+			await persist(team, dir);
+			return { member, result };
 		});
-		setMemberWorktree(team, { id: member.id, path: result.path, branch: result.branch });
-		await persist(team, dir);
 		const note = result.created ? "" : " (already exists)";
+		const thread = member.threadId
+			? `\nMember thread: ${codexThreadLink(member.threadId)}\nTell that member to: cd "${result.path}"`
+			: "\nMember thread is not bound yet; wait for the real Codex thread id, then bind-thread before sending bootstrap. After binding, send the member this worktree path.";
 		process.stdout.write(
-			`worktree for member ${member.id}${note}: ${result.path} on branch ${result.branch} (off ${result.base}).\nTell that member to: cd "${result.path}"\n`,
+			`worktree for member ${member.id}${note}: ${result.path} on branch ${result.branch} (off ${result.base}).${thread}\n`,
 		);
 	},
 
 	async "worktree-remove"(cwd, flags) {
 		const sessionId = requireFlag(flags, "team");
-		const { dir, team } = await loadTeam(cwd, sessionId);
-		const member = memberOrThrow(team, requireFlag(flags, "id"));
-		removeMemberWorktree(cwd, team, member, { force: flags.force === true });
-		clearMemberWorktree(team, { id: member.id });
-		await persist(team, dir);
+		const memberId = requireFlag(flags, "id");
+		const force = flags.force === true;
+		const member = await mutateTeam(cwd, sessionId, "worktree-remove", async (team, dir) => {
+			const member = memberOrThrow(team, memberId);
+			removeMemberWorktree(cwd, team, member, { force });
+			clearMemberWorktree(team, { id: member.id });
+			await persist(team, dir);
+			return member;
+		});
 		process.stdout.write(`removed worktree for member ${member.id}\n`);
 	},
 
@@ -205,25 +231,30 @@ const handlers = {
 
 	async archive(cwd, flags) {
 		const sessionId = requireFlag(flags, "team");
-		const { dir, team } = await loadTeam(cwd, sessionId);
-		archive(team, {
+		const input = {
 			id: typeof flags.id === "string" ? flags.id : null,
 			note: typeof flags.note === "string" ? flags.note : "",
+		};
+		await mutateTeam(cwd, sessionId, "archive", async (team, dir) => {
+			archive(team, input);
+			await persist(team, dir);
 		});
-		await persist(team, dir);
 		process.stdout.write(flags.id ? `archived member ${flags.id}\n` : `archived team ${sessionId} and closed all members\n`);
 	},
 
 	async delete(cwd, flags) {
 		const sessionId = requireFlag(flags, "team");
-		const { dir, team } = await loadTeam(cwd, sessionId);
-		const active = team.members.filter((m) => m.status !== "archived");
-		if (flags.force !== true && (team.status !== "archived" || active.length > 0)) {
-			throw new Error(
-				`refused: team "${sessionId}" is not archived or still has ${active.length} active member(s). Archive first, or pass --force to delete anyway.`,
-			);
-		}
-		await rm(dir, { recursive: true, force: true });
+		const dir = await assertSafeTeamDir(cwd, sessionId);
+		await withTeamLock(dir, "delete", async () => {
+			const team = await readTeam(dir);
+			const active = team.members.filter((m) => m.status !== "archived");
+			if (flags.force !== true && (team.status !== "archived" || active.length > 0)) {
+				throw new Error(
+					`refused: team "${sessionId}" is not archived or still has ${active.length} active member(s). Archive first, or pass --force to delete anyway.`,
+				);
+			}
+			await rm(dir, { recursive: true, force: true });
+		});
 		process.stdout.write(`deleted team state: ${dir}\n`);
 	},
 
@@ -232,7 +263,8 @@ const handlers = {
 		const { team } = await loadTeam(cwd, sessionId);
 		process.stdout.write(`Team ${team.teamName} [${team.status}] - leader: main session - ${team.members.length} member(s)\n`);
 		for (const m of team.members) {
-			process.stdout.write(`  ${m.id} (${m.lens}) ${m.focus} -> ${m.deliverable || "(no deliverable)"} [${m.status}]${m.threadId ? ` thread=${m.threadId}` : ""}${m.cwd ? ` cwd=${m.cwd}` : ""}\n`);
+			const thread = m.threadId ? ` thread=${m.threadId} link=${codexThreadLink(m.threadId)}` : "";
+			process.stdout.write(`  ${m.id} (${m.lens}) ${m.focus} -> ${m.deliverable || "(no deliverable)"} [${m.status}]${thread}${m.cwd ? ` cwd=${m.cwd}` : ""}\n`);
 		}
 		if (isUnderstaffed(team)) {
 			process.stdout.write(
@@ -243,9 +275,11 @@ const handlers = {
 
 	async guide(cwd, flags) {
 		const sessionId = requireFlag(flags, "team");
-		const { dir, team } = await loadTeam(cwd, sessionId);
-		await writeGuideAtomic(team, buildGuide(team), dir);
-		process.stdout.write(`${team.paths.guide}\n`);
+		const guidePath = await mutateTeam(cwd, sessionId, "guide", async (team, dir) => {
+			await writeGuideAtomic(team, buildGuide(team), dir);
+			return team.paths.guide;
+		});
+		process.stdout.write(`${guidePath}\n`);
 	},
 };
 

package/packages/omo-codex/plugin/skills/ultraresearch/SKILL.md

@@ -1,256 +1,10 @@
 ---
 name: ultraresearch
-description: "Maximum-saturation research orchestration: parallel explore+librarian swarms across codebase, web, official docs, and OSS repos; a recursive EXPAND loop driven by leads workers return in message text; empirical verification by running code; cited synthesis and optional MD/HTML/PDF/PPTX reports. ACTIVATES ONLY on an explicit user demand for research — the word 'ultraresearch' ('/ultraresearch', '$ultraresearch') or an explicit request for research / deep research / an ultra-precise investigation, in any language. Never self-activates for ordinary questions, debugging, or implementation context-gathering. While active it overrides exploration-bounding defaults: exhaustive coverage is the goal."
+description: "Legacy alias for ulw-research. MUST USE when the user asks for ultraresearch, /ultraresearch, or $ultraresearch; immediately load and follow the ulw-research skill."
 ---
 
-## Codex Harness Tool Compatibility
+# Ultraresearch Alias
 
-This skill may include examples copied from the OpenCode harness. In Codex, do not call OpenCode-only tools such as `call_omo_agent(...)`, `task(...)`, `background_output(...)`, or `team_*(...)` literally. Translate those examples to Codex native tools:
+`ultraresearch` is the legacy name for `ulw-research`.
 
-| OpenCode example | Codex tool to use |
-| --- | --- |
-| `call_omo_agent(subagent_type="explore", ...)` | `multi_agent_v1.spawn_agent({"message":"TASK: act as an explorer. ...","agent_type":"explorer","fork_context":false})` |
-| `call_omo_agent(subagent_type="librarian", ...)` | `multi_agent_v1.spawn_agent({"message":"TASK: act as a librarian. ...","agent_type":"librarian","fork_context":false})` |
-| `task(subagent_type="plan", ...)` | `multi_agent_v1.spawn_agent({"message":"TASK: act as a planning agent. ...","agent_type":"plan","fork_context":false})` |
-| `task(subagent_type="oracle", ...)` for final verification | `multi_agent_v1.spawn_agent({"message":"TASK: act as a rigorous reviewer. ...","agent_type":"lazycodex-gate-reviewer","fork_context":false})` |
-| `task(category="...", ...)` for implementation or QA | `multi_agent_v1.spawn_agent({"message":"TASK: act as an implementation or QA worker. ...","fork_context":false})` |
-| `background_output(task_id="...")` | `multi_agent_v1.wait_agent(...)` for mailbox signals |
-| `team_*(...)` | Use Codex native subagents via `multi_agent_v1.spawn_agent`, `multi_agent_v1.send_input`, `multi_agent_v1.wait_agent`, and `multi_agent_v1.close_agent` |
-
-Role-specific behavior must be described in a self-contained `message`. Use `fork_context: false` to start the child with only the initial prompt (no parent history); use `fork_context: true` only when full parent history is truly required. Include any required conversation context, files, diffs, constraints, and requested skill names directly in the spawned agent's `message`. OMO installs these selectable agent roles into `~/.codex/agents/`: `explorer`, `librarian`, `plan`, `momus`, `metis`, `lazycodex-code-reviewer`, `lazycodex-qa-executor`, and `lazycodex-gate-reviewer` - pass the matching name as `agent_type` so the child gets that role's model and instructions. If the spawn tool exposes no `agent_type` parameter, omit it and describe the role inside `message`. If a code block below conflicts with this section, this section wins.
-
-For work likely to exceed one wait cycle, require the child to send `WORKING: <task> - <current phase>` before long passes and `BLOCKED: <reason>` only when progress stops. A `multi_agent_v1.wait_agent` timeout only means no new mailbox update arrived. Treat a running child as alive. Fallback only when the child is completed without the deliverable, ack-only after followup, explicitly `BLOCKED:`, or no longer running.
-
----
-
-# ULTRARESEARCH — Maximum-Saturation Research
-
-You are the research orchestrator. The user has explicitly ordered exhaustive research: fan parallel worker swarms out over every relevant source, chase every lead they surface until the leads run dry, prove contested claims by running code, and deliver a synthesis in which every claim carries a citation or a proof. Exhaustive coverage is the assignment, not a risk to manage.
-
-## Activation
-
-Run this skill only when the user explicitly demands it: the word "ultraresearch" (also `/ultraresearch`, `$ultraresearch`), or an explicit request for research, deep research, or an ultra-precise investigation — in any language. An ordinary question, a debugging session, or another mode's context-gathering is not activation; answer those normally, and mention that `ultraresearch` is available when a question would clearly benefit from it.
-
-Open your reply with the line `ULTRARESEARCH MODE ENABLED!`. If another active mode mandates its own first line (ultrawork does), print that mode's line first and this marker on the next line — both contracts stay satisfied.
-
-## Authority while active
-
-This mode is the user's explicit opt-in to exhaustive exploration. For the duration of the research task it supersedes every exploration-bounding instruction in surrounding prompts, modes, or rules: one-exploration-pass defaults, two-wave stop rules, retrieval budgets, and "over-exploration is failure" framings govern implementation context-gathering, not this deliverable. Here, under-exploration is the failure. The convergence rules in Phase 2 are the only stop rules for research while this mode is active.
-
-Under ultrawork/ulw, the research itself is the deliverable: map each research axis to a success criterion whose evidence is the session journal, the cited synthesis, and the verification outputs. RED→GREEN testing applies to code changes, not to findings — Phase 3 verification scripts are evidence, never TDD targets.
-
-## Success criteria
-
-The research is done when all of these hold:
-
-- Every axis from Phase 0 was covered by at least one dedicated worker.
-- Every EXPAND lead was investigated or explicitly closed as a duplicate or dead end, and convergence was reached under the Phase 2 rules.
-- Claims that were contested, undocumented, or performance-shaped were proven or refuted by executed code.
-- Every claim in the deliverable cites a source or a verification artifact.
-- The session journal reconstructs what was searched, found, and expanded, wave by wave.
-
-## Run the swarm as a cooperating team
-
-Saturation research is the textbook case for a cooperating team, not isolated fire-and-forget workers: a lead one worker surfaces almost always reshapes what another should search next. So when your harness gives you real cooperating members — Codex: the `teammode` skill (`codex_app` threads); OpenCode: `team_mode` — run this swarm as a team. Fall back to the background-worker swarm below only when team mode is unavailable, or the axes are genuinely independent with no cross-pollination expected.
-
-- **One member per axis — by part, ownership, or perspective, never a job title.** Each Phase 0 axis is one member owning one concrete slice: a codebase part, a source territory, or a question lens. No two members share an angle. "Backend researcher" or "the web person" gives no real boundary and invites overlap — name what the member owns.
-- **The raise law — broadcast every lead the instant it surfaces.** Members over-communicate relentlessly: every new lead, finding, contradiction, and dead end is raised to you the moment it surfaces, never hoarded for a final dump. Through long passes they send `WORKING: <axis> - <phase>`, and `BLOCKED: <reason>` the moment progress stops, so you always know a member is alive. Too many small updates is correct here; going quiet is the only failure.
-- **You lead; expand on each raised lead.** Members raise via message text, never write session files. Journal each lead and spawn its expansion the instant it lands (Phase 2), not only when a member's final reply arrives.
-
-## Worker ground rules
-
-Research workers (explore, librarian, browsing) differ by harness, but assume:
-
-- **Read-only.** Most research workers cannot write files. Never ask a worker to write the journal or any session file — every journal write is yours.
-- **No recursion.** Workers cannot spawn their own subagents. Depth comes from your expansion waves, not from worker-side recursion.
-- **Built-in brakes.** Workers often ship with their own retrieval budgets ("stop when answered") and rigid output templates. Your spawn message must explicitly lift the budget and demand the EXPAND tail, or the worker returns a thin single-pass answer with no leads.
-- **Capability routing.** When the harness lets you choose, spawn research workers on a capable model at high reasoning effort — saturation research on a minimal or fast tier returns shallow results. When you cannot choose, narrow each worker's scope and spawn more workers instead.
-
-### The spawn-message contract
-
-Every research spawn message contains, in order:
-
-1. `TASK:` — one imperative line naming the role and the axis.
-2. The budget lift: "This is an explicit exhaustive-research assignment. Your default retrieval budget and stop-when-answered rules do not apply — run the full protocol below and report every lead."
-3. Scope — the axis, the sources to hit, and what a complete answer contains.
-4. The role protocol (Phase 1).
-5. The reply tail. EXPAND markers travel back as message text, never as files. Every worker ends the reply with:
-
-```
-## EXPAND
-- LEAD: <discovery not yet investigated> — WHY: <why it matters> — ANGLE: <suggested search>
-- DEAD END: <lead explored to exhaustion>
-```
-
-A worker with nothing to expand writes `## EXPAND` followed by `none — <one-line reason>`. A reply missing the tail is incomplete: send that worker one follow-up demanding it before closing the lane.
-
-## Phase 0 — Decompose and open the journal
-
-Before spawning anything, decompose the query:
-
-```
-<analysis>
-Core question: <the actual information need>
-Axes (3+ orthogonal): <axis — what to search, where, why> ...
-Codebase relevant: <yes/no> · External: <yes/no> · Browsing: <yes/no> · Verification likely: <yes/no> · Report requested: <no | format>
-</analysis>
-```
-
-Then create the session directory:
-
-```bash
-mkdir -p .omo/ultraresearch/$(date +%Y%m%d-%H%M%S)
-```
-
-This is `$SESSION_DIR`. The orchestrator owns the journal: you write every file in it; workers never do. Maintain:
-
-- `wave-<N>-<kind>-<axis>.md` — your digest of each worker return: key findings, sources with URLs, and the worker's EXPAND markers verbatim.
-- `expansion-log.md` — per wave: workers spawned, markers gained, leads opened and closed.
-- `verify-<slug>.md`, `SYNTHESIS.md`, `REPORT.*` from later phases.
-
-Append each digest the moment its worker returns, not in a batch at the end — the journal is your recovery point after context loss and the user's audit trail.
-
-## Phase 1 — Saturation wave
-
-Launch the entire first wave in one turn — every axis at once, as team members if you formed a team, else as background workers. Sequential launches and "start with one and see" defeat the mode.
-
-Scaling floor — more angles always justify more workers:
-
-| Query scope | explore | librarian | browsing | repo-dive | floor |
-|---|---|---|---|---|---|
-| Single topic, codebase only | 3 | 0 | 0 | 0 | 3 |
-| Single topic, web only | 0 | 4 | 1 | 1 | 6 |
-| Single topic, both | 2 | 3 | 1 | 1 | 7 |
-| Multi-faceted | 4 | 6 | 2 | 2 | 14 |
-| Full due diligence | 4 | 6 | 3 | 2 | 15 |
-
-Role protocols — embed the relevant one in each spawn message; every worker gets a unique angle:
-
-- **Codebase (explore), 2-4 workers.** Grep with 3+ keyword variations; structural/AST search; LSP definitions and references; file-name globs; `git log --all -S '<keyword>'` and `--grep` for history including deleted code. Cross-validate hits across tools. Report absolute file paths, patterns with `file:line`, and how findings connect.
-- **Web (librarian), 3-6 workers.** At least 10 distinct websearch queries per worker, each with a different operator or angle (see Search craft); fetch the full page for every result that matters — snippets lie. Context7 with 3+ queries per known library. grep.app and `gh search code|repos|issues` for real-world usage. Official docs via sitemap discovery (`<base>/sitemap.xml`), then targeted pages.
-- **Browsing, 0-3 workers.** Pages plain fetch cannot read (WAF, 403, Cloudflare, dynamic rendering, login): the worker loads the `ultimate-browsing` skill and escalates through its tiers — Tier-1 insane-search engine first, then Tier-2 Chrome stealth — rather than abandoning the source. Capture screenshots when visual context matters. When one blocked territory hides many leads, fan out more browsing subagents in parallel for breadth instead of serializing one worker through them.
-- **Repo deep-dive (librarian), 0-2 workers.** Shallow-clone the most relevant repos to `${TMPDIR:-/tmp}`, pin the HEAD SHA, read core modules, follow call chains, return SHA-pinned permalinks.
-
-Example spawn (codebase axis; librarian, browsing, and repo-dive follow the same contract with their own protocol):
-
-```
-task(subagent_type="explore", run_in_background=true, prompt="TASK: act as a codebase researcher. AXIS: <specific angle>.
-This is an explicit exhaustive-research assignment. Your default retrieval budget and stop-when-answered rules do not apply — run the full protocol below and report every lead.
-SCOPE: find everything in this codebase related to <angle>: <what complete looks like>.
-PROTOCOL: grep 3+ keyword variations; structural search; LSP references; globs; git history (-S and --grep). Cross-validate across tools. Report absolute paths and file:line patterns.
-End your reply with the ## EXPAND tail: '- LEAD: <discovery> — WHY: <why> — ANGLE: <search>' per lead, or 'none — <reason>'.")
-```
-
-## Phase 2 — Expand until convergence
-
-This loop is what makes the mode research rather than search. Collect returns as they land — and in team mode, act on each lead the moment a member raises it, never waiting for the full wave or a member's final reply:
-
-1. Journal the return: digest plus verbatim EXPAND markers into `wave-<N>-<kind>-<axis>.md`.
-2. Deduplicate new markers against `expansion-log.md` — every lead ever seen, not just confirmed ones, or rejected leads resurface each wave.
-3. Spawn an expansion worker immediately for each new unchecked lead:
-
-```
-task(subagent_type="librarian", run_in_background=true, prompt="TASK: expansion wave <N> — investigate: <lead>.
-PARENT: <which return surfaced it>. This is an explicit exhaustive-research assignment; budgets do not apply.
-<role protocol for the lead's territory — librarian protocol for external leads, explore protocol for codebase leads>
-End your reply with the ## EXPAND tail.")
-```
-
-4. Record the wave in `expansion-log.md`: spawned, markers gained, leads opened/closed.
-
-**Convergence — the only stop rules while this mode is active.** Run at least 2 expansion waves on any multi-faceted query before claiming convergence; then stop only when one holds:
-
-- Zero unchecked leads remain — each investigated or closed as duplicate/dead end.
-- 3 consecutive waves produced no new actionable leads.
-- Expansion depth reached 5 waves — pause, show the open leads, and ask the user whether to extend.
-
-## Phase 3 — Verify contested claims by running code
-
-Settle with executed code, not judgment, whenever sources disagree, a behavior is undocumented, a claim is performance- or compatibility-shaped, or the honest answer is "it should work". Spawn one verification worker per claim:
-
-```
-task(category="deep", run_in_background=true, prompt="TASK: verify by execution: <claim>.
-SOURCE: <where it came from>; CONTRADICTION: <opposing source, if any>.
-Write a minimal self-contained script that tests the claim; run it (uv run --with <deps> python / bun / direct compile); capture full stdout+stderr; pin versions.
-Reply with: the exact code, the full output, environment (OS, runtime, dependency versions), and a verdict — CONFIRMED / REFUTED / PARTIAL — grounded in the output.")
-```
-
-Journal each verdict to `verify-<slug>.md`.
-
-## Phase 3b — Lock non-code claims through a claim ledger
-
-Code settles code-shaped claims (Phase 3). Numeric, market-share, legal, dated, causal, and financial claims cannot be run — so they pass through a data-flow-lock instead (the verification idea adapted from fivetaku/insane-research): the synthesis may assert a high-risk non-code claim **only** if it cleared this gate, and the gate's output is the sole allowlist the synthesis draws from. Skip the gate and there is nothing to synthesize — the lock is self-enforcing.
-
-The claim ledger is orchestrator-owned. Workers only return verified-claim markers as message text, the same channel as EXPAND markers — never a file. As leads resolve, you record one ledger entry per asserted claim and compute its status; workers report claim candidates in their replies, and you decide.
-
-A high-risk claim clears the gate to `verified-claims` only when all hold:
-
-- **>= 2 independent source domains** corroborate it (two pages on the same domain count once).
-- **One counter-search** actively looked for a refutation and did not find a stronger one.
-- **A primary source** (the standard, filing, dataset, or first-party doc) backs it, not only secondary commentary.
-
-Anything that fails goes to an `Unresolved` (insufficient evidence) or `Refuted` (counter-search won) annex — abstention is a correct outcome, not a gap to paper over. Maintain `claim-ledger.md` with one row per claim — `claim | risk | domains | counter-search | primary? | status (verified/unresolved/refuted)` — and write the cleared rows into a `verified-claims` digest. Worker reply marker (message text, same channel as EXPAND):
-
-```
-## CLAIMS
-- CLAIM: <non-code assertion> — RISK: high|normal — SOURCES: <domain1, domain2> — COUNTER: <refutation search result> — PRIMARY: <primary source or none>
-```
-
-## Phase 4 — Synthesize
-
-After convergence and all verifications, re-read the whole journal and write `SYNTHESIS.md`:
-
-```
-# Ultraresearch Synthesis: <query>
-Workers: <total> · Waves: <count> · Sources: <count> · Verifications: <count>
-
-## Executive summary        — 2-3 paragraphs answering the core question
-## Findings by theme        — per theme: consensus, evidence links, key quote (<20 words, attributed), verified yes/no
-## Codebase findings        — absolute paths with line references
-## Sources (ranked)         — URL, what it contains, reliability, access date
-## Verified claims          — code: claim | verdict | verify-<slug>.md · non-code: only rows cleared into verified-claims
-## Contradictions           — source A vs source B, resolution with evidence
-## Gaps                     — what saturation could not answer · unresolved/refuted claim-ledger rows
-## Expansion trace          — per wave: workers → markers; convergence reason
-```
-
-Deliver the synthesis with inline `[Source N]` citations on every claim. Every high-risk non-code claim you assert must be a verified-claims row from Phase 3b — assert nothing the gate left in the unresolved/refuted annex. When no report was requested, this is the deliverable.
-
-## Phase 5 — Report (only when requested)
-
-Format by the user's words: "report" / "document" → Markdown (default) · "pdf" → HTML first, then weasyprint (`uv run --with weasyprint python`) · "slides" / "presentation" / "deck" → python-pptx · "html" / "webpage" → standalone HTML.
-
-Asset workers (background, parallel): charts for quantitative findings (`uv run --with matplotlib --with plotly python`) saved by you to `$SESSION_DIR/assets/`; full-page screenshots of the top 5-10 sources (browsing skill); generated diagrams (imagegen skill) when architecture or flows need them.
-
-Assembly worker — `task(category="deep", load_skills=["frontend-design", "open-design", "data-scientist", "imagegen"], run_in_background=true, ...)`: before writing, read every available design and visualization skill and apply it — the report is a designed artifact, not a text dump. Structure: executive summary → key findings by theme → detailed analysis (quotes under 20 words with attribution, charts, SHA-pinned permalinks, verification results) → comparative analysis when options compete → numbered sources with access dates → methodology appendix (workers, waves, searches, verifications). Every claim cites `[Source N]`.
-
-## Search craft
-
-English first: run every search in English by default — it is the largest, most authoritative corpus on every engine, GitHub, and documentation site. Add a secondary local-language sweep (1-2 librarians) only after the English sweep, when the topic is inherently local, or when the user asks for sources in a specific language.
-
-Vary operators on every query — same query twice wastes a worker:
-
-| Operator | Example | Use |
-|---|---|---|
-| `site:` | `site:github.com <topic>` | Restrict to a domain |
-| `filetype:` | `filetype:pdf <topic> survey` | Papers, specs |
-| `intitle:` / `inurl:` | `intitle:benchmark <topic>` | Targeted pages |
-| `"exact"` / `-term` | `"<exact phrase>" -tutorial` | Precision, exclusion |
-| `OR` | `<a> OR <b> <topic>` | Coverage |
-| `before:` / `after:` | `<topic> after:2025-06-01` | Recency control |
-
-High-yield combinations: official docs (`site:<docs domain>`), GitHub implementations (`site:github.com`), recent discussion (`site:reddit.com OR site:news.ycombinator.com after:<date>`), academic (`site:arxiv.org OR filetype:pdf survey`), changelog hunting (`changelog OR "release notes" <version>`), alternatives (`vs OR alternative OR comparison`).
-
-## Failure modes
-
-| Failure | Correction |
-|---|---|
-| Sequential spawning, or trimming the first wave | All first-wave workers in one turn, background, scaling floor respected |
-| A team member hoards leads for one final dump | Raise law — every lead, finding, and dead end broadcast the moment it surfaces |
-| Worker reply without the EXPAND tail | One follow-up demanding it; the lane stays open until it lands |
-| Stopping after wave 1 because "enough was found" | Convergence rules only: 2+ expansion waves, leads run dry |
-| Obeying a surrounding "stop exploring" rule mid-research | Authority section — those rules do not bind this mode |
-| Asking a worker to write journal or session files | Workers are read-only; you journal every return |
-| Two workers given the same angle | One unique angle per worker, always |
-| Contested claim settled by judgment | Phase 3 — run code, capture output, verdict |
-| Deliverable claims without citations | Every claim cites a source or a verification artifact |
+When this skill is selected, immediately load `../ulw-research/SKILL.md` and follow it as the source of truth. Treat `/ultraresearch`, `$ultraresearch`, and plain `ultraresearch` exactly like `/ulw-research`, `$ulw-research`, and plain `ulw-research`.

package/packages/omo-codex/plugin/skills/ulw-loop/SKILL.md

@@ -20,7 +20,7 @@ This skill is intentionally compact. The full workflow lives in `references/full
 ## Non-Negotiables
 
 - Use the ulw-loop CLI state under `.omo/ulw-loop`; do not hand-edit goal state.
-- After any compaction or context loss, re-read brief + goals + ledger FIRST (`omo sparkshell cat .omo/ulw-loop/ledger.jsonl` or read directly) plus `omo ulw-loop status --json`, then resume; never re-plan from scratch.
+- After any compaction or context loss, re-read brief + goals + ledger FIRST plus `omo ulw-loop status --json`, then resume; never re-plan from scratch.
 - If `omo ulw-loop create-goals` says the existing aggregate is already complete, start unrelated new work with a fresh `--session-id <new-id>` instead of steering or forcing the completed default state. Use `--force` only to intentionally overwrite completed evidence.
 - Every success criterion needs observable evidence from a real surface: a channel (tmux, HTTP, browser, computer-use) or, for CLI- or data-shaped criteria, an auxiliary surface (CLI stdout, DB diff, parsed config dump).
 - Record evidence through the CLI only after cleanup receipts are available.