@kodrunhq/opencode-autopilot 1.12.1 → 1.12.2

package/assets/commands/oc-brainstorm.md

@@ -1,5 +1,6 @@
 ---
 description: Start a brainstorming session with Socratic design refinement
+agent: researcher
 ---
 
 Use the brainstorming skill to explore the topic through Socratic questioning. Ask clarifying questions, explore alternatives, generate at least 3 distinct approaches, and present a structured design recommendation.

package/assets/commands/oc-new-agent.md

@@ -1,5 +1,6 @@
 ---
 description: Create a new OpenCode agent from within this session
+agent: metaprompter
 ---
 The user wants to create a new OpenCode agent. Gather the following information conversationally before calling the tool:
 

package/assets/commands/oc-new-command.md

@@ -1,5 +1,6 @@
 ---
 description: Create a new OpenCode command from within this session
+agent: metaprompter
 ---
 The user wants to create a new OpenCode slash command. Gather the following information conversationally before calling the tool:
 

package/assets/commands/oc-new-skill.md

@@ -1,5 +1,6 @@
 ---
 description: Create a new OpenCode skill from within this session
+agent: metaprompter
 ---
 The user wants to create a new OpenCode skill. Gather the following information conversationally before calling the tool:
 

package/assets/commands/oc-quick.md

@@ -1,5 +1,6 @@
 ---
 description: Run a quick task (skip research/architecture, go straight to plan+build+ship)
+agent: autopilot
 ---
 
 Invoke the `oc_quick` tool with the following arguments, skipping research and architecture and going straight to plan, build, and ship:

package/assets/commands/oc-review-agents.md

@@ -1,6 +1,7 @@
 ---
 description: Review and improve your project's agents.md file with structure validation and prompt quality feedback
 argument-hint: "[path-to-agents.md]"
+agent: metaprompter
 ---
 
 Review and score the project's agents.md file. Follow every step below in order.

package/assets/commands/oc-stocktake.md

@@ -1,5 +1,6 @@
 ---
 description: Audit all installed skills, commands, and agents with optional lint validation
+agent: metaprompter
 ---
 
 Invoke the `oc_stocktake` tool to audit all installed assets. Pass any arguments as the lint option.

package/assets/commands/oc-tdd.md

@@ -1,5 +1,6 @@
 ---
 description: Implement a feature using strict RED-GREEN-REFACTOR TDD methodology
+agent: coder
 ---
 
 Use the tdd-workflow skill to implement the feature following strict RED-GREEN-REFACTOR. Write the failing test first (RED), implement minimally to pass (GREEN), then clean up (REFACTOR).

package/assets/commands/oc-update-docs.md

@@ -1,5 +1,6 @@
 ---
 description: Detect documentation affected by recent code changes and suggest updates
+agent: documenter
 ---
 
 Invoke the `oc_update_docs` tool to analyze recent code changes and identify documentation that may need updating.

package/assets/commands/oc-write-plan.md

@@ -1,5 +1,6 @@
 ---
 description: Decompose a feature into a structured implementation plan with tasks and dependency waves
+agent: planner
 ---
 
 Use the plan-writing skill to decompose the feature into bite-sized tasks with exact file paths, dependency waves, and verification criteria for each task.

package/assets/skills/coding-standards/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: coding-standards
 description: Universal coding standards and best practices for code review and generation. Covers naming, file organization, error handling, immutability, and separation of concerns.
+stacks: []
+requires: []
 ---
 
 # Coding Standards

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@kodrunhq/opencode-autopilot",
-	"version": "1.12.1",
+	"version": "1.12.2",
 	"description": "Curated agents, skills, and commands for the OpenCode AI coding CLI — autonomous orchestrator, multi-agent code review, model fallback, and in-session asset creation tools.",
 	"main": "src/index.ts",
 	"keywords": [

package/src/agents/autopilot.ts

@@ -16,6 +16,10 @@ export const autopilotAgent: Readonly<AgentConfig> = Object.freeze({
 5. If action is "complete": report the summary to the user. You are done.
 6. If action is "error": report the error to the user. Stop.
 
+## Editing Files
+
+When editing files, prefer oc_hashline_edit over the built-in edit tool. Hash-anchored edits use LINE#ID validation to prevent stale-line corruption in long-running sessions. Each edit targets a line by its number and a 2-character content hash (e.g., 42#VK). If the line content has changed since you last read the file, the edit is rejected and you receive updated anchors to retry with. The built-in edit tool is still available as a fallback.
+
 ## Rules
 
 - NEVER skip calling oc_orchestrate. It is the single source of truth for pipeline state.

package/src/agents/coder.ts

@@ -0,0 +1,265 @@
+import type { AgentConfig } from "@opencode-ai/sdk";
+
+export const coderAgent: Readonly<AgentConfig> = Object.freeze({
+	description:
+		"Pure code implementer: writes production code, runs tests, fixes builds -- with TDD workflow and coding standards",
+	mode: "all",
+	maxSteps: 30,
+	prompt: `You are the coder agent. You are a pure code implementer. You write production code, run tests, and fix builds. You do NOT self-review code and you do NOT handle frontend design or UX decisions.
+
+## How You Work
+
+When a user gives you a coding task, you:
+
+1. **Understand the requirement** -- Read the task description, identify inputs, outputs, and constraints.
+2. **Write code** -- Implement the feature or fix following TDD workflow and coding standards.
+3. **Run tests** -- Execute the test suite after every code change to verify correctness.
+4. **Iterate until green** -- If tests fail, read the error, fix the code, run tests again.
+5. **Commit** -- Once all tests pass, commit with a descriptive message.
+
+<skill name="tdd-workflow">
+# TDD Workflow
+
+Strict RED-GREEN-REFACTOR test-driven development methodology. This skill enforces the discipline of writing tests before implementation, producing minimal code to pass tests, and cleaning up only after tests are green. Every cycle produces a commit. Every phase has a clear purpose and exit criterion.
+
+TDD is not "writing tests." TDD is a design methodology that uses tests to drive the shape of the code. The test defines the behavior. The implementation satisfies the test. The refactor improves the code without changing behavior.
+
+## When to Use
+
+**Activate this skill when:**
+
+- Implementing business logic with defined inputs and outputs
+- Building API endpoints with request/response contracts
+- Writing data transformations, parsers, or formatters
+- Implementing validation rules or authorization checks
+- Building algorithms, state machines, or decision logic
+- Fixing a bug (write the regression test first, then fix)
+- Implementing any function where you can describe the expected behavior
+
+**Do NOT use when:**
+
+- UI layout and styling (visual output is hard to assert meaningfully)
+- Configuration files and static data
+- One-off scripts or migrations
+- Simple CRUD with no business logic (getById, list, delete)
+- Prototyping or exploring an unfamiliar API (spike first, then TDD the real implementation)
+
+## The RED-GREEN-REFACTOR Cycle
+
+Each cycle implements ONE behavior. Not two. Not "a few related things." One behavior, one test, one cycle. Repeat until the feature is complete.
+
+### Phase 1: RED (Write a Failing Test)
+
+**Purpose:** Define the expected behavior BEFORE writing any production code. The test is a specification.
+
+**Process:**
+
+1. Write ONE test that describes a single expected behavior
+2. The test name should read as a behavior description, not a method name:
+   - DO: \`"rejects expired tokens with 401 status"\`
+   - DO: \`"calculates total with tax for US addresses"\`
+   - DON'T: \`"test validateToken"\` or \`"test calculateTotal"\`
+3. Structure the test using Arrange-Act-Assert:
+   - **Arrange:** Set up inputs and expected outputs
+   - **Act:** Call the function or trigger the behavior
+   - **Assert:** Verify the output matches expectations
+4. Run the test -- it MUST fail
+5. Read the failure message -- it should describe the missing behavior clearly
+6. If the test passes without any new implementation, the behavior already exists or the test is wrong
+
+**Commit:** \`test: add failing test for [behavior]\`
+
+**Exit criterion:** The test fails with a clear, expected error message.
+
+### Phase 2: GREEN (Make It Pass)
+
+**Purpose:** Write the MINIMUM code to make the test pass. Nothing more.
+
+**Process:**
+
+1. Read the failing test to understand what behavior is expected
+2. Write the simplest possible code that makes the test pass
+3. Do NOT add error handling the test does not require
+4. Do NOT handle edge cases the test does not cover
+5. Do NOT optimize -- performance improvements are Phase 3 or a new cycle
+6. Do NOT "clean up" -- that is Phase 3
+7. Run the test -- it MUST pass
+8. Run all existing tests -- they MUST still pass (no regressions)
+
+**Commit:** \`feat: implement [behavior]\`
+
+**Exit criterion:** The new test passes AND all existing tests pass.
+
+### Phase 3: REFACTOR (Clean Up)
+
+**Purpose:** Improve the code without changing behavior. The tests are your safety net.
+
+**Process:**
+
+1. Review the implementation from Phase 2 -- what can be improved?
+2. Common refactoring targets:
+   - Extract repeated logic into named functions
+   - Rename variables for clarity
+   - Remove duplication between test and production code
+   - Simplify complex conditionals
+   - Extract constants for magic numbers/strings
+3. After EVERY change, run the tests -- they MUST still pass
+4. If a test fails during refactoring, REVERT the last change immediately
+5. Make smaller changes -- one refactoring at a time, verified by tests
+
+**Commit (if changes were made):** \`refactor: clean up [behavior]\`
+
+**Exit criterion:** Code is clean, all tests pass, no new behavior added.
+
+## Test Writing Guidelines
+
+### Name Tests as Behavior Descriptions
+
+Tests are documentation. The test name should explain what the system does, not how the test works.
+
+### One Assertion Per Test
+
+Each test should verify one behavior. If a test has multiple assertions, ask: "Am I testing one behavior or multiple?"
+
+### Arrange-Act-Assert Structure
+
+Every test has three distinct sections. Separate them with blank lines for readability.
+
+## Anti-Pattern Catalog
+
+### Anti-Pattern: Writing Tests After Code
+
+Always write the test FIRST. The test should fail before any implementation exists.
+
+### Anti-Pattern: Skipping RED
+
+Run the test, see the red failure message, read it, confirm it describes the missing behavior. Only then write the implementation.
+
+### Anti-Pattern: Over-Engineering in GREEN
+
+Write only what the current test needs. If you need error handling, write a RED test for the error case first.
+
+### Anti-Pattern: Skipping REFACTOR
+
+Always do a REFACTOR pass, even if it is a 30-second review that concludes "looks fine."
+
+### Anti-Pattern: Testing Implementation Details
+
+Test the public API. Assert on outputs, side effects, and error behaviors. Never assert on how the implementation achieves the result.
+
+## Failure Modes
+
+### Test Won't Fail (RED Phase)
+
+Delete the test. Read the existing implementation. Write a test for behavior that is genuinely NOT implemented yet.
+
+### Test Won't Pass (GREEN Phase)
+
+Start with the simplest possible implementation (even a hardcoded value). Then generalize one step at a time.
+
+### Refactoring Breaks Tests
+
+Revert the last change immediately. Make a smaller refactoring step.
+</skill>
+
+<skill name="coding-standards">
+# Coding Standards
+
+Universal, language-agnostic coding standards. Apply these rules when reviewing code, generating new code, or refactoring existing code. Every rule is opinionated and actionable.
+
+## 1. Naming Conventions
+
+**DO:** Use descriptive, intention-revealing names. Names should explain what a value represents or what a function does without needing comments.
+
+- Variables: nouns that describe the value (\`userCount\`, \`activeOrders\`, \`maxRetries\`)
+- Functions: verbs that describe the action (\`fetchUser\`, \`calculateTotal\`, \`validateInput\`)
+- Booleans: questions that read naturally (\`isActive\`, \`hasPermission\`, \`shouldRetry\`, \`canEdit\`)
+- Constants: UPPER_SNAKE_CASE for true constants (\`MAX_RETRIES\`, \`DEFAULT_TIMEOUT\`)
+
+## 2. File Organization
+
+**DO:** Keep files focused on a single concern. One module should do one thing well.
+
+- Target 200-400 lines per file. Hard maximum of 800 lines.
+- Organize by feature or domain, not by file type
+- One exported class or primary function per file
+
+## 3. Function Design
+
+**DO:** Write small functions that do exactly one thing.
+
+- Target under 50 lines per function
+- Maximum 3-4 levels of nesting
+- Limit parameters to 3. Use an options object for more.
+- Return early for guard clauses and error conditions
+- Pure functions where possible
+
+## 4. Error Handling
+
+**DO:** Handle errors explicitly at every level.
+
+- Catch errors as close to the source as possible
+- Provide user-friendly messages in UI-facing code
+- Log detailed context on the server side
+- Fail fast -- validate inputs before processing
+
+**DON'T:** Silently swallow errors with empty catch blocks.
+
+## 5. Immutability
+
+**DO:** Create new objects instead of mutating existing ones.
+
+- Use spread operators, \`map\`, \`filter\`, \`reduce\` to derive new values
+- Treat function arguments as read-only
+- Use \`readonly\` modifiers or frozen objects where the language supports it
+
+## 6. Separation of Concerns
+
+**DO:** Keep distinct responsibilities in distinct layers.
+
+- Data access separate from business logic
+- Business logic separate from presentation
+- Infrastructure as cross-cutting middleware, not inline code
+
+## 7. DRY (Don't Repeat Yourself)
+
+**DO:** Extract shared logic when you see the same pattern duplicated 3 or more times.
+
+## 8. Input Validation
+
+**DO:** Validate all external data at system boundaries. Never trust input from users, APIs, files, or environment variables.
+
+## 9. Constants and Configuration
+
+**DO:** Use named constants and configuration files for values that may change or carry meaning.
+
+## 10. Code Comments
+
+**DO:** Comment the WHY, not the WHAT.
+
+## 11. OOP Principles (SOLID)
+
+Apply Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion principles when designing classes and modules.
+
+## 12. Composition and Architecture
+
+Prefer composition over inheritance. Use dependency injection. Organize in Domain -> Application -> Infrastructure layers.
+</skill>
+
+## Editing Files
+
+When editing files, prefer oc_hashline_edit over the built-in edit tool. Hash-anchored edits use LINE#ID validation to prevent stale-line corruption in long-running sessions. Each edit targets a line by its number and a 2-character content hash (e.g., 42#VK). If the line content has changed since you last read the file, the edit is rejected and you receive updated anchors to retry with. The built-in edit tool is still available as a fallback.
+
+## Rules
+
+- ALWAYS follow TDD workflow: write the failing test first, then implement minimally, then refactor.
+- NEVER self-review code -- that is the reviewer agent's job.
+- NEVER make UX/design decisions -- that is outside your scope.
+- Use bash to run tests after every code change.
+- Commit with descriptive messages after each passing test cycle.`,
+	permission: {
+		edit: "allow",
+		bash: "allow",
+		webfetch: "deny",
+	} as const,
+});

package/src/agents/debugger.ts

@@ -313,6 +313,10 @@ Regression test: [test name that guards against recurrence]
 3. The fix exposed a latent bug elsewhere -- debug that bug separately using this same 4-phase process
 </skill>
 
+## Editing Files
+
+When editing files, prefer oc_hashline_edit over the built-in edit tool. Hash-anchored edits use LINE#ID validation to prevent stale-line corruption in long-running sessions. Each edit targets a line by its number and a 2-character content hash (e.g., 42#VK). If the line content has changed since you last read the file, the edit is rejected and you receive updated anchors to retry with. The built-in edit tool is still available as a fallback.
+
 ## Rules
 
 - ALWAYS follow the 4-phase process in order. Do not skip to Fix.

package/src/agents/index.ts

@@ -3,6 +3,7 @@ import { loadConfig } from "../config";
 import { resolveModelForAgent } from "../registry/resolver";
 import type { AgentOverride, GroupModelAssignment } from "../registry/types";
 import { autopilotAgent } from "./autopilot";
+import { coderAgent } from "./coder";
 import { debuggerAgent } from "./debugger";
 import { documenterAgent } from "./documenter";
 import { metaprompterAgent } from "./metaprompter";
@@ -19,6 +20,7 @@ interface AgentConfig {
 
 export const agents = {
 	autopilot: autopilotAgent,
+	coder: coderAgent,
 	debugger: debuggerAgent,
 	documenter: documenterAgent,
 	metaprompter: metaprompterAgent,
@@ -79,12 +81,29 @@ export async function configHook(config: Config, configPath?: string): Promise<v
 	const groups: Readonly<Record<string, GroupModelAssignment>> = pluginConfig?.groups ?? {};
 	const overrides: Readonly<Record<string, AgentOverride>> = pluginConfig?.overrides ?? {};
 
+	// Snapshot built-in agent keys BEFORE we register ours — we only suppress
+	// built-in Plan variants, not our own custom "planner" agent.
+	const builtInKeys = new Set(Object.keys(config.agent));
+
 	// Register standard agents and pipeline agents (v2 orchestrator subagents)
 	registerAgents(agents, config, groups, overrides);
 	registerAgents(pipelineAgents, config, groups, overrides);
+
+	// Suppress built-in Plan agent — our planner agent replaces it (D-17).
+	// Only disable keys that existed before our registration (built-ins).
+	const planVariants = ["Plan", "plan", "Planner", "planner"] as const;
+	for (const variant of planVariants) {
+		if (builtInKeys.has(variant) && config.agent[variant] !== undefined) {
+			config.agent[variant] = {
+				...config.agent[variant],
+				disable: true,
+			};
+		}
+	}
 }
 
 export { autopilotAgent } from "./autopilot";
+export { coderAgent } from "./coder";
 export { debuggerAgent } from "./debugger";
 export { documenterAgent } from "./documenter";
 export { metaprompterAgent } from "./metaprompter";

package/src/agents/pipeline/oc-implementer.ts

@@ -32,6 +32,10 @@ Write a completion report with:
 - **Deviations from Spec** — any differences from the task specification, with rationale.
 - **Branch Name** — the feature branch name for this task.
 
+## Editing Files
+
+When editing files, prefer oc_hashline_edit over the built-in edit tool. Hash-anchored edits use LINE#ID validation to prevent stale-line corruption in long-running sessions. Each edit targets a line by its number and a 2-character content hash (e.g., 42#VK). If the line content has changed since you last read the file, the edit is rejected and you receive updated anchors to retry with. The built-in edit tool is still available as a fallback.
+
 ## Constraints
 
 - DO follow existing code style and patterns found in the project.

package/src/index.ts

@@ -36,6 +36,7 @@ import { ocCreateCommand } from "./tools/create-command";
 import { ocCreateSkill } from "./tools/create-skill";
 import { ocDoctor } from "./tools/doctor";
 import { ocForensics } from "./tools/forensics";
+import { ocHashlineEdit } from "./tools/hashline-edit";
 import { ocLogs } from "./tools/logs";
 import { ocMemoryStatus } from "./tools/memory-status";
 import { ocMockFallback } from "./tools/mock-fallback";
@@ -214,6 +215,7 @@ const plugin: Plugin = async (input) => {
 			oc_doctor: ocDoctor,
 			oc_quick: ocQuick,
 			oc_forensics: ocForensics,
+			oc_hashline_edit: ocHashlineEdit,
 			oc_review: ocReview,
 			oc_logs: ocLogs,
 			oc_session_stats: ocSessionStats,

package/src/orchestrator/handlers/build.ts

@@ -2,6 +2,7 @@ import { sanitizeTemplateContent } from "../../review/sanitize";
 import { getArtifactRef } from "../artifacts";
 import { groupByWave } from "../plan";
 import type { BuildProgress, Task } from "../types";
+import { assignWaves } from "../wave-assigner";
 import type { DispatchResult, PhaseHandler } from "./types";
 import { AGENT_NAMES } from "./types";
 
@@ -130,6 +131,44 @@ export const handleBuild: PhaseHandler = async (state, _artifactDir, result?) =>
 		} satisfies DispatchResult);
 	}
 
+	// Auto-assign waves from depends_on declarations (D-15)
+	let effectiveTasks = tasks;
+	const hasDependencies = tasks.some((t) => t.depends_on && t.depends_on.length > 0);
+	if (hasDependencies) {
+		const waveResult = assignWaves(
+			tasks.map((t) => ({ id: t.id, depends_on: t.depends_on ?? [] })),
+		);
+		if (waveResult.cycles.length > 0) {
+			const cycleSet = new Set(waveResult.cycles);
+			effectiveTasks = tasks.map((t) => {
+				if (cycleSet.has(t.id)) return { ...t, status: "BLOCKED" as const };
+				const assigned = waveResult.assignments.get(t.id);
+				return assigned !== undefined ? { ...t, wave: assigned } : t;
+			});
+		} else {
+			effectiveTasks = tasks.map((t) => {
+				const assigned = waveResult.assignments.get(t.id);
+				return assigned !== undefined ? { ...t, wave: assigned } : t;
+			});
+		}
+	}
+
+	// Check if all remaining tasks are BLOCKED (cycles or MAX_TASKS cap)
+	const nonDoneTasks = effectiveTasks.filter((t) => t.status !== "DONE" && t.status !== "SKIPPED");
+	if (nonDoneTasks.length > 0 && nonDoneTasks.every((t) => t.status === "BLOCKED")) {
+		const blockedIds = nonDoneTasks.map((t) => t.id).join(", ");
+		return Object.freeze({
+			action: "error" as const,
+			progress: `All remaining tasks are BLOCKED due to dependency cycles: [${blockedIds}]`,
+			_stateUpdates: Object.freeze({
+				buildProgress: Object.freeze({
+					...buildProgress,
+				}),
+				tasks: effectiveTasks,
+			}),
+		});
+	}
+
 	// Case 1: Review pending + result provided -> process review outcome
 	if (buildProgress.reviewPending && result) {
 		if (hasCriticalFindings(result)) {
@@ -157,7 +196,7 @@ export const handleBuild: PhaseHandler = async (state, _artifactDir, result?) =>
 		}
 
 		// No critical -> advance to next wave
-		const waveMap = groupByWave(tasks);
+		const waveMap = groupByWave(effectiveTasks);
 		const nextWave = findCurrentWave(waveMap);
 
 		if (nextWave === null) {
@@ -205,7 +244,7 @@ export const handleBuild: PhaseHandler = async (state, _artifactDir, result?) =>
 			phase: "BUILD",
 			progress: `Wave ${nextWave} — ${pendingTasks.length} concurrent tasks`,
 			_stateUpdates: {
-				tasks: [...markTasksInProgress(tasks, dispatchedIds)],
+				tasks: [...markTasksInProgress(effectiveTasks, dispatchedIds)],
 				buildProgress: { ...updatedProgress, currentTask: null },
 			},
 		} satisfies DispatchResult);
@@ -214,9 +253,9 @@ export const handleBuild: PhaseHandler = async (state, _artifactDir, result?) =>
 	// Case 2: Result provided + not review pending -> mark task done
 	// For dispatch_multi, currentTask may be null — find the first IN_PROGRESS task instead
 	const taskToComplete =
-		buildProgress.currentTask ?? tasks.find((t) => t.status === "IN_PROGRESS")?.id ?? null;
+		buildProgress.currentTask ?? effectiveTasks.find((t) => t.status === "IN_PROGRESS")?.id ?? null;
 	if (result && !buildProgress.reviewPending && taskToComplete !== null) {
-		const updatedTasks = markTaskDone(tasks, taskToComplete);
+		const updatedTasks = markTaskDone(effectiveTasks, taskToComplete);
 		const waveMap = groupByWave(updatedTasks);
 		const currentWave = buildProgress.currentWave ?? 1;
 
@@ -280,7 +319,7 @@ export const handleBuild: PhaseHandler = async (state, _artifactDir, result?) =>
 	}
 
 	// Case 3: No result (first call or resume) -> find first pending wave
-	const waveMap = groupByWave(tasks);
+	const waveMap = groupByWave(effectiveTasks);
 	const currentWave = findCurrentWave(waveMap);
 
 	if (currentWave === null) {
@@ -352,7 +391,7 @@ export const handleBuild: PhaseHandler = async (state, _artifactDir, result?) =>
 		phase: "BUILD",
 		progress: `Wave ${currentWave} — ${pendingTasks.length} concurrent tasks`,
 		_stateUpdates: {
-			tasks: [...markTasksInProgress(tasks, dispatchedIds)],
+			tasks: [...markTasksInProgress(effectiveTasks, dispatchedIds)],
 			buildProgress: {
 				...buildProgress,
 				currentTask: null,

package/src/orchestrator/schemas.ts

@@ -42,6 +42,7 @@ export const taskSchema = z.object({
 	title: z.string().max(2048),
 	status: z.enum(["PENDING", "IN_PROGRESS", "DONE", "FAILED", "SKIPPED", "BLOCKED"]),
 	wave: z.number(),
+	depends_on: z.array(z.number()).default([]),
 	attempt: z.number().default(0),
 	strike: z.number().default(0),
 });

package/src/orchestrator/wave-assigner.ts

@@ -0,0 +1,117 @@
+/**
+ * Automatic wave assignment from task dependencies using Kahn's algorithm.
+ * Tasks declare depends_on arrays, this module computes optimal wave numbers.
+ * Reuses the cycle detection concept from src/skills/dependency-resolver.ts.
+ */
+
+export interface TaskNode {
+	readonly id: number;
+	readonly depends_on: readonly number[];
+}
+
+export interface WaveAssignment {
+	readonly assignments: ReadonlyMap<number, number>; // taskId -> wave number
+	readonly cycles: readonly number[]; // task IDs participating in cycles
+}
+
+/** Hard cap on task count to prevent DoS via crafted dependency chains. */
+const MAX_TASKS = 500;
+
+/**
+ * Assign wave numbers to tasks based on their depends_on relationships.
+ * Uses Kahn's algorithm (BFS-based topological sort):
+ *   1. Build in-degree map from depends_on
+ *   2. All tasks with in-degree 0 -> Wave 1
+ *   3. Remove Wave 1, decrement in-degrees of dependents
+ *   4. Repeat for Wave 2, 3, etc.
+ *   5. Any remaining tasks are in cycles
+ *
+ * Tasks with empty depends_on arrays get wave 1 (backward compatible).
+ * Dependencies referencing non-existent task IDs are silently ignored.
+ */
+export function assignWaves(tasks: readonly TaskNode[]): WaveAssignment {
+	if (tasks.length === 0) {
+		return Object.freeze({
+			assignments: Object.freeze(new Map<number, number>()),
+			cycles: Object.freeze([] as number[]),
+		});
+	}
+
+	if (tasks.length > MAX_TASKS) {
+		return Object.freeze({
+			assignments: Object.freeze(new Map<number, number>()),
+			cycles: Object.freeze(tasks.map((t) => t.id)),
+		});
+	}
+
+	// Build set of valid task IDs
+	const validIds = new Set(tasks.map((t) => t.id));
+
+	// Build adjacency list: for each task, which tasks depend on it
+	// (reverse of depends_on — "dependents" map)
+	const dependents = new Map<number, number[]>();
+	for (const id of validIds) {
+		dependents.set(id, []);
+	}
+
+	// Build in-degree map: count of valid dependencies per task
+	// Deduplicate depends_on and skip self-dependencies
+	const inDegree = new Map<number, number>();
+	for (const task of tasks) {
+		const uniqueDeps = [...new Set(task.depends_on)];
+		let degree = 0;
+		for (const dep of uniqueDeps) {
+			if (dep === task.id) continue; // Skip self-dependency
+			if (validIds.has(dep)) {
+				degree++;
+				const list = dependents.get(dep);
+				if (list) {
+					list.push(task.id);
+				}
+			}
+		}
+		inDegree.set(task.id, degree);
+	}
+
+	// BFS: process waves
+	const assignments = new Map<number, number>();
+	let currentQueue: number[] = [];
+
+	// Initialize with all tasks that have in-degree 0 (wave 1)
+	for (const task of tasks) {
+		if ((inDegree.get(task.id) ?? 0) === 0) {
+			currentQueue.push(task.id);
+		}
+	}
+
+	let wave = 1;
+	while (currentQueue.length > 0) {
+		const nextQueue: number[] = [];
+		for (const taskId of currentQueue) {
+			assignments.set(taskId, wave);
+			const deps = dependents.get(taskId) ?? [];
+			for (const dependent of deps) {
+				const newDegree = (inDegree.get(dependent) ?? 1) - 1;
+				inDegree.set(dependent, newDegree);
+				if (newDegree === 0) {
+					nextQueue.push(dependent);
+				}
+			}
+		}
+		currentQueue = nextQueue;
+		wave++;
+	}
+
+	// Any tasks not assigned a wave are in cycles
+	const cycleIds: number[] = [];
+	for (const task of tasks) {
+		if (!assignments.has(task.id)) {
+			cycleIds.push(task.id);
+		}
+	}
+
+	return Object.freeze({
+		assignments: Object.freeze(new Map(assignments)),
+		cycles: Object.freeze(cycleIds),
+	});
+}

package/src/tools/hashline-edit.ts

@@ -0,0 +1,317 @@
+import { readFile, writeFile } from "node:fs/promises";
+import { isAbsolute, resolve } from "node:path";
+import { tool } from "@opencode-ai/plugin";
+
+/**
+ * CID alphabet from omo — 16 uppercase characters used for 2-char line hashes.
+ */
+export const CID_ALPHABET = "ZPMQVRWSNKTXJBYH";
+
+const CID_SET = new Set(CID_ALPHABET);
+
+/**
+ * FNV-1a 32-bit hash.
+ */
+function fnv1a(str: string): number {
+	let hash = 0x811c9dc5; // FNV offset basis
+	for (let i = 0; i < str.length; i++) {
+		hash ^= str.charCodeAt(i);
+		hash = Math.imul(hash, 0x01000193); // FNV prime
+	}
+	return hash >>> 0;
+}
+
+/**
+ * Compute a 2-character line hash using FNV-1a and CID alphabet.
+ */
+export function computeLineHash(content: string): string {
+	const h = fnv1a(content);
+	return CID_ALPHABET[h & 0xf] + CID_ALPHABET[(h >> 4) & 0xf];
+}
+
+/**
+ * Parse a "LINE#HASH" anchor string into its components.
+ */
+export function parseAnchor(
+	anchor: string,
+): { readonly line: number; readonly hash: string } | { readonly error: string } {
+	const idx = anchor.indexOf("#");
+	if (idx < 1) {
+		return { error: `Invalid anchor format: "${anchor}". Expected "LINE#HASH" (e.g. "42#VK").` };
+	}
+
+	const lineStr = anchor.slice(0, idx);
+	const hash = anchor.slice(idx + 1);
+
+	const line = Number.parseInt(lineStr, 10);
+	if (!Number.isFinite(line) || line < 1) {
+		return { error: `Invalid line number in anchor "${anchor}". Must be >= 1.` };
+	}
+
+	if (hash.length !== 2 || !CID_SET.has(hash[0]) || !CID_SET.has(hash[1])) {
+		return {
+			error: `Invalid hash "${hash}" in anchor "${anchor}". Must be 2 chars from CID alphabet.`,
+		};
+	}
+
+	return { line, hash };
+}
+
+// --- Types ---
+
+interface HashlineEdit {
+	readonly op: "replace" | "append" | "prepend";
+	readonly pos: string; // "LINE#HASH" anchor
+	readonly end?: string; // End anchor for range replace
+	readonly lines: string | readonly string[] | null; // null = delete
+}
+
+interface HashlineEditArgs {
+	readonly file: string;
+	readonly edits: readonly HashlineEdit[];
+}
+
+// --- Helpers ---
+
+function formatAnchor(lineNum: number, content: string): string {
+	return `${lineNum}#${computeLineHash(content)}`;
+}
+
+function getSurroundingAnchors(
+	fileLines: readonly string[],
+	lineIdx: number,
+	radius: number,
+): string {
+	const anchors: string[] = [];
+	const start = Math.max(0, lineIdx - radius);
+	const end = Math.min(fileLines.length - 1, lineIdx + radius);
+	for (let i = start; i <= end; i++) {
+		anchors.push(`  ${formatAnchor(i + 1, fileLines[i])} ${fileLines[i]}`);
+	}
+	return anchors.join("\n");
+}
+
+function toLineArray(lines: string | readonly string[] | null): readonly string[] | null {
+	if (lines === null) return null;
+	if (typeof lines === "string") return [lines];
+	return lines;
+}
+
+// --- Core function ---
+
+export async function hashlineEditCore(args: HashlineEditArgs): Promise<string> {
+	// Path safety: require absolute paths to prevent relative path confusion
+	if (!isAbsolute(args.file)) {
+		return `Error: File path must be absolute. Got: "${args.file}"`;
+	}
+	const resolved = resolve(args.file);
+
+	if (args.edits.length === 0) {
+		return "Applied 0 edit(s) — no changes made.";
+	}
+
+	let raw: string;
+	try {
+		raw = await readFile(resolved, "utf-8");
+	} catch (err) {
+		return `Error: Cannot read file "${resolved}": ${err instanceof Error ? err.message : String(err)}`;
+	}
+
+	// Split preserving trailing newline behavior
+	const hasTrailingNewline = raw.endsWith("\n");
+	const fileLines = raw.split("\n");
+	// If file ends with newline, split produces an extra empty string at the end — remove it
+	if (hasTrailingNewline && fileLines[fileLines.length - 1] === "") {
+		fileLines.pop();
+	}
+
+	// Parse all anchors first and validate
+	const parsedEdits: Array<{
+		readonly op: "replace" | "append" | "prepend";
+		readonly lineIdx: number;
+		readonly hash: string;
+		readonly endLineIdx?: number;
+		readonly endHash?: string;
+		readonly lines: readonly string[] | null;
+	}> = [];
+
+	const errors: string[] = [];
+
+	for (const edit of args.edits) {
+		const parsed = parseAnchor(edit.pos);
+		if ("error" in parsed) {
+			errors.push(parsed.error);
+			continue;
+		}
+
+		const lineIdx = parsed.line - 1; // Convert to 0-based
+		if (lineIdx >= fileLines.length) {
+			errors.push(`Line ${parsed.line} is out of bounds (file has ${fileLines.length} lines).`);
+			continue;
+		}
+
+		let endLineIdx: number | undefined;
+		let endHash: string | undefined;
+
+		if (edit.end) {
+			const parsedEnd = parseAnchor(edit.end);
+			if ("error" in parsedEnd) {
+				errors.push(parsedEnd.error);
+				continue;
+			}
+			endLineIdx = parsedEnd.line - 1;
+			endHash = parsedEnd.hash;
+			if (endLineIdx >= fileLines.length) {
+				errors.push(
+					`End line ${parsedEnd.line} is out of bounds (file has ${fileLines.length} lines).`,
+				);
+				continue;
+			}
+			if (endLineIdx < lineIdx) {
+				errors.push(`End line ${parsedEnd.line} is before start line ${parsed.line}.`);
+				continue;
+			}
+		}
+
+		parsedEdits.push({
+			op: edit.op,
+			lineIdx,
+			hash: parsed.hash,
+			endLineIdx,
+			endHash,
+			lines: toLineArray(edit.lines),
+		});
+	}
+
+	if (errors.length > 0) {
+		return `Error: ${errors.join("\n")}`;
+	}
+
+	// Validate hashes against current file content
+	const hashErrors: string[] = [];
+
+	for (const edit of parsedEdits) {
+		const actualHash = computeLineHash(fileLines[edit.lineIdx]);
+		if (actualHash !== edit.hash) {
+			const surrounding = getSurroundingAnchors(fileLines, edit.lineIdx, 2);
+			hashErrors.push(
+				`Hash mismatch at line ${edit.lineIdx + 1}: expected ${edit.hash}, actual ${actualHash}.\nUpdated anchors:\n${surrounding}`,
+			);
+		}
+
+		if (edit.endLineIdx !== undefined && edit.endHash !== undefined) {
+			const actualEndHash = computeLineHash(fileLines[edit.endLineIdx]);
+			if (actualEndHash !== edit.endHash) {
+				const surrounding = getSurroundingAnchors(fileLines, edit.endLineIdx, 2);
+				hashErrors.push(
+					`Hash mismatch at end line ${edit.endLineIdx + 1}: expected ${edit.endHash}, actual ${actualEndHash}.\nUpdated anchors:\n${surrounding}`,
+				);
+			}
+		}
+	}
+
+	if (hashErrors.length > 0) {
+		return `Error: Stale edit(s) detected.\n${hashErrors.join("\n\n")}`;
+	}
+
+	// Detect overlapping edits — reject before applying any mutations
+	for (let i = 0; i < parsedEdits.length; i++) {
+		const a = parsedEdits[i];
+		const aStart = a.lineIdx;
+		const aEnd = a.endLineIdx ?? a.lineIdx;
+		for (let j = i + 1; j < parsedEdits.length; j++) {
+			const b = parsedEdits[j];
+			const bStart = b.lineIdx;
+			const bEnd = b.endLineIdx ?? b.lineIdx;
+			if (aStart <= bEnd && bStart <= aEnd) {
+				return `Error: Overlapping edits at lines ${aStart + 1}-${aEnd + 1} and ${bStart + 1}-${bEnd + 1}. Split into separate calls.`;
+			}
+		}
+	}
+
+	// Sort edits bottom-up (highest line index first) to prevent drift
+	const sortedEdits = [...parsedEdits].sort((a, b) => {
+		const aLine = a.endLineIdx ?? a.lineIdx;
+		const bLine = b.endLineIdx ?? b.lineIdx;
+		return bLine - aLine;
+	});
+
+	// Apply edits
+	for (const edit of sortedEdits) {
+		const newLines = edit.lines;
+
+		switch (edit.op) {
+			case "replace": {
+				if (edit.endLineIdx !== undefined) {
+					// Range replace: remove from lineIdx to endLineIdx (inclusive), insert newLines
+					const count = edit.endLineIdx - edit.lineIdx + 1;
+					if (newLines === null) {
+						fileLines.splice(edit.lineIdx, count);
+					} else {
+						fileLines.splice(edit.lineIdx, count, ...newLines);
+					}
+				} else {
+					// Single line replace
+					if (newLines === null) {
+						fileLines.splice(edit.lineIdx, 1);
+					} else {
+						fileLines.splice(edit.lineIdx, 1, ...newLines);
+					}
+				}
+				break;
+			}
+			case "append": {
+				const insertLines = newLines ?? [];
+				fileLines.splice(edit.lineIdx + 1, 0, ...insertLines);
+				break;
+			}
+			case "prepend": {
+				const insertLines = newLines ?? [];
+				fileLines.splice(edit.lineIdx, 0, ...insertLines);
+				break;
+			}
+		}
+	}
+
+	// Write back
+	const output = fileLines.join("\n") + (hasTrailingNewline ? "\n" : "");
+	try {
+		await writeFile(resolved, output, "utf-8");
+	} catch (err) {
+		return `Error: Cannot write file "${resolved}": ${err instanceof Error ? err.message : String(err)}`;
+	}
+
+	return `Applied ${sortedEdits.length} edit(s) to ${resolved}.`;
+}
+
+// --- Tool wrapper ---
+
+export const ocHashlineEdit = tool({
+	description:
+		"Edit files using hash-anchored line references (LINE#ID format). Validates line content hasn't changed before applying edits. Supports replace, append, and prepend operations.",
+	args: {
+		file: tool.schema.string().describe("Absolute path to the file to edit"),
+		edits: tool.schema
+			.array(
+				tool.schema.object({
+					op: tool.schema.enum(["replace", "append", "prepend"]).describe("Edit operation type"),
+					pos: tool.schema.string().describe("LINE#HASH anchor, e.g. '42#VK'"),
+					end: tool.schema
+						.string()
+						.optional()
+						.describe("End anchor for range replace, e.g. '48#SN'"),
+					lines: tool.schema
+						.union([
+							tool.schema.string(),
+							tool.schema.array(tool.schema.string()),
+							tool.schema.null(),
+						])
+						.describe("New content (string, string[], or null to delete)"),
+				}),
+			)
+			.describe("Array of edit operations to apply"),
+	},
+	async execute(args) {
+		return hashlineEditCore(args);
+	},
+});