lazyopencode-core 0.0.1

package/dist/index.js

@@ -0,0 +1,85 @@
+import { createAgents } from "./agents/index.js";
+import { createHooks } from "./hooks/index.js";
+import { registerLazyCommands } from "./hooks/lazy-command.js";
+import { createLazyRuntime } from "./hooks/runtime.js";
+import { getSkillsDir } from "./skills/index.js";
+import { createCancelTaskTool, createCouncilTool } from "./tools/index.js";
+import { LazyOpenCodeV2Plugin } from "./v2.js";
+import { createOpenCodeControlPlane } from "./opencode-control-plane.js";
+/**
+ * @lazyopencode/core — Governed team runtime for AI coding in OpenCode.
+ *
+ * One plugin. Zero config. Total takeover.
+ *
+ * Install: { "plugin": ["@lazyopencode/core"] }
+ */
+const LazyOpenCodePluginV1 = async (ctx) => {
+    const agents = createAgents();
+    const runtime = createLazyRuntime({
+        project: ctx.project,
+        directory: ctx.directory,
+        worktree: ctx.worktree,
+    });
+    runtime.setControlPlane(createOpenCodeControlPlane(ctx.client));
+    const hooks = createHooks(runtime);
+    const councilTool = createCouncilTool(ctx.client, () => runtime.config.council, () => {
+        const council = runtime.config.council;
+        if (council.eligibility === "always")
+            return { eligible: true };
+        const level = runtime.workflow.lastDecision?.level;
+        if (level === "high_risk" || level === "ambiguous")
+            return { eligible: true };
+        if (runtime.workflow.stage === "debug")
+            return { eligible: true };
+        return {
+            eligible: false,
+            reason: 'Council blocked: not eligible for current workflow. Run /lazy start for risk classification, enter debug, or set council.eligibility = "always".',
+        };
+    });
+    const cancelTaskTool = createCancelTaskTool(runtime.jobBoard);
+    return {
+        runtime,
+        tool: {
+            council_session: councilTool,
+            cancel_task: cancelTaskTool,
+        },
+        config: async (config) => {
+            const cfg = config;
+            runtime.configure(cfg.lazyopencode);
+            await runtime.load();
+            cfg.agent = mergeAgents(cfg.agent ?? {}, agents);
+            cfg.skills = cfg.skills || {};
+            const paths = cfg.skills.paths || [];
+            const skillsDir = getSkillsDir();
+            if (!paths.includes(skillsDir)) {
+                paths.push(skillsDir);
+            }
+            cfg.skills.paths = paths;
+            // deno-lint-ignore no-explicit-any
+            const mcp = cfg.mcp;
+            if (!mcp?.context7) {
+                // deno-lint-ignore no-explicit-any
+                ;
+                cfg.mcp = {
+                    ...(mcp || {}),
+                    context7: { command: ["npx", "-y", "@agentdesk/context7-mcp"] },
+                };
+            }
+            registerLazyCommands(cfg, runtime);
+        },
+        dispose: async () => {
+            await runtime.save();
+        },
+        ...hooks,
+    };
+};
+const LazyOpenCodePlugin = LazyOpenCodePluginV1;
+export { LazyOpenCodePlugin, LazyOpenCodePluginV1, LazyOpenCodeV2Plugin };
+export default LazyOpenCodeV2Plugin;
+function mergeAgents(existing, lazyAgents) {
+    const merged = { ...existing };
+    for (const [name, defaults] of Object.entries(lazyAgents)) {
+        merged[name] = { ...defaults, ...merged[name] };
+    }
+    return merged;
+}

package/dist/opencode-control-plane.d.ts

@@ -0,0 +1,20 @@
+export interface OpenCodeControlPlaneSnapshot {
+    sessionStatus: string;
+    pendingPermissions: number;
+    todos: number;
+    diffSummary: string;
+    worktree: string;
+    capabilities: string[];
+}
+export interface OpenCodeControlPlane {
+    snapshot(sessionID?: string): Promise<OpenCodeControlPlaneSnapshot>;
+    wait(sessionID: string): Promise<{
+        ok: boolean;
+        reason?: string;
+    }>;
+    revert(checkpointID: string): Promise<{
+        ok: boolean;
+        reason?: string;
+    }>;
+}
+export declare function createOpenCodeControlPlane(client: unknown): OpenCodeControlPlane;

package/dist/opencode-control-plane.js

@@ -0,0 +1,95 @@
+export function createOpenCodeControlPlane(client) {
+    const c = (client ?? {});
+    return {
+        async snapshot(sessionID) {
+            const capabilities = detectCapabilities(c);
+            const sessionStatus = await callString(c, ["sessionStatus", "status"], sessionID, "unknown");
+            const pendingPermissions = await callCount(c, ["pendingPermissions", "permissions"], sessionID);
+            const todos = await callCount(c, ["todos", "todo"], sessionID);
+            const diffSummary = await callString(c, ["diffSummary", "diff"], sessionID, "not collected");
+            const worktree = await callString(c, ["worktree", "projectWorktree"], sessionID, "unknown");
+            return { sessionStatus, pendingPermissions, todos, diffSummary, worktree, capabilities };
+        },
+        async wait(sessionID) {
+            return await callOk(c, ["wait", "sessionWait"], sessionID);
+        },
+        async revert(checkpointID) {
+            return await callOk(c, ["revert", "revertCheckpoint"], checkpointID);
+        },
+    };
+}
+function detectCapabilities(client) {
+    const names = [
+        ["sessionStatus", "status"],
+        ["children"],
+        ["wait", "sessionWait"],
+        ["context"],
+        ["messages"],
+        ["diffSummary", "diff"],
+        ["todos", "todo"],
+        ["pendingPermissions", "permissions"],
+        ["worktree", "projectWorktree"],
+        ["revert", "revertCheckpoint"],
+    ];
+    return names
+        .filter((group) => group.some((name) => typeof client[name] === "function"))
+        .map((group) => group[0]);
+}
+async function callString(client, names, arg, fallback) {
+    try {
+        const value = await callFirst(client, names, arg);
+        if (value === undefined || value === null)
+            return fallback;
+        if (typeof value === "string")
+            return value;
+        if (typeof value === "object") {
+            const record = value;
+            return String(record.summary ?? record.status ?? record.path ?? fallback);
+        }
+        return String(value);
+    }
+    catch {
+        return fallback;
+    }
+}
+async function callCount(client, names, arg) {
+    try {
+        const value = await callFirst(client, names, arg);
+        if (Array.isArray(value))
+            return value.length;
+        if (typeof value === "number")
+            return value;
+        if (value && typeof value === "object") {
+            const record = value;
+            if (typeof record.count === "number")
+                return record.count;
+            if (Array.isArray(record.items))
+                return record.items.length;
+        }
+    }
+    catch {
+        return 0;
+    }
+    return 0;
+}
+async function callOk(client, names, arg) {
+    try {
+        const value = await callFirst(client, names, arg);
+        if (value && typeof value === "object" && "ok" in value) {
+            return value;
+        }
+        return { ok: true };
+    }
+    catch (error) {
+        return { ok: false, reason: error instanceof Error ? error.message : String(error) };
+    }
+}
+async function callFirst(client, names, arg) {
+    for (const name of names) {
+        const fn = client[name];
+        if (typeof fn === "function") {
+            return await fn(arg);
+        }
+    }
+    return undefined;
+}

package/dist/ponytail.d.ts

@@ -0,0 +1 @@
+export declare const PONYTAIL_MODE = "PONYTAIL MODE ACTIVE \u2014 level: full\n\nYou are a lazy senior developer. Lazy means efficient, not careless. The best code is the code never written.\n\n## The ladder \u2014 stop at the first rung that holds\n1. Does this need to exist at all? (YAGNI) Speculative need = skip.\n2. Stdlib does it? Use it.\n3. Native platform feature covers it? CSS over JS, DB constraint over app code.\n4. Already-installed dependency solves it? Use it. Never add new deps for spare change.\n5. Can it be one line? One line.\n6. Only then: the minimum code that works.\n\n## Rules\n- No unrequested abstractions. One implementation = no interface, one product = no factory.\n- No boilerplate, no scaffolding \"for later\". Later can scaffold for itself.\n- Deletion over addition. Boring over clever.\n- Fewest files possible. Shortest working diff wins.\n- Two stdlib options? Pick the one correct on edge cases \u2014 lazy means less code, not sloppy algorithms.\n- Mark deliberate simplifications with `ponytail:` comment + ceiling + upgrade path.\n\n## Output discipline\n- Code first. No unrequested essays, feature tours, or design notes.\n- Explanation longer than the code \u2192 delete the explanation.\n- Pattern: `[code] \u2192 skipped: X, add when Y.`\n\n## When NOT to be lazy\n- Input validation at trust boundaries\n- Error handling that prevents data loss\n- Security measures, accessibility basics\n- Anything explicitly requested full-version by the user\n\n## Lazy check \u2014 a reflex\nEvery task, every file, every function: ask \"does this need to exist?\" first.";

package/dist/ponytail.js

@@ -0,0 +1,33 @@
+export const PONYTAIL_MODE = `PONYTAIL MODE ACTIVE — level: full
+
+You are a lazy senior developer. Lazy means efficient, not careless. The best code is the code never written.
+
+## The ladder — stop at the first rung that holds
+1. Does this need to exist at all? (YAGNI) Speculative need = skip.
+2. Stdlib does it? Use it.
+3. Native platform feature covers it? CSS over JS, DB constraint over app code.
+4. Already-installed dependency solves it? Use it. Never add new deps for spare change.
+5. Can it be one line? One line.
+6. Only then: the minimum code that works.
+
+## Rules
+- No unrequested abstractions. One implementation = no interface, one product = no factory.
+- No boilerplate, no scaffolding "for later". Later can scaffold for itself.
+- Deletion over addition. Boring over clever.
+- Fewest files possible. Shortest working diff wins.
+- Two stdlib options? Pick the one correct on edge cases — lazy means less code, not sloppy algorithms.
+- Mark deliberate simplifications with \`ponytail:\` comment + ceiling + upgrade path.
+
+## Output discipline
+- Code first. No unrequested essays, feature tours, or design notes.
+- Explanation longer than the code → delete the explanation.
+- Pattern: \`[code] → skipped: X, add when Y.\`
+
+## When NOT to be lazy
+- Input validation at trust boundaries
+- Error handling that prevents data loss
+- Security measures, accessibility basics
+- Anything explicitly requested full-version by the user
+
+## Lazy check — a reflex
+Every task, every file, every function: ask "does this need to exist?" first.`;

package/dist/skills/index.d.ts

@@ -0,0 +1,5 @@
+/**
+ * Returns the absolute path to the lazy skills directory.
+ * Registered in config.skills.paths so OpenCode discovers them.
+ */
+export declare function getSkillsDir(): string;

package/dist/skills/index.js

@@ -0,0 +1,10 @@
+import { fileURLToPath } from "node:url";
+import { dirname, join } from "node:path";
+/**
+ * Returns the absolute path to the lazy skills directory.
+ * Registered in config.skills.paths so OpenCode discovers them.
+ */
+export function getSkillsDir() {
+    const __dirname = dirname(fileURLToPath(import.meta.url));
+    return join(__dirname, "lazy/");
+}

package/dist/skills/lazy/build/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: lazy/build
+description: Implement one vertical slice at a time, test-first, YAGNI-gated. Supports --prototype for throwaway verification.
+---
+
+Implement a piece of work from a PRD or issue. Default to TDD. YAGNI at every step.
+
+## Modes
+
+### Normal mode (default)
+
+For production code. Red-green-refactor per vertical slice.
+
+Before starting:
+
+- [ ] Confirm interface changes with user
+- [ ] Prioritize behaviors to test
+- [ ] Identify deep-module opportunities (small interface, deep implementation)
+
+Per behavior:
+
+1. **RED**: Write one test for one behavior → fails
+2. **GREEN**: Minimal code to pass → passes
+3. Verify the test describes behavior, not implementation
+
+After all tests pass:
+
+- [ ] Look for refactor candidates (deepen modules, extract duplication)
+- [ ] Never refactor while RED
+
+### --prototype mode
+
+For fast verification before committing to production code. Skips tests and polish.
+
+- Write minimal code to answer a specific question
+- No tests, no error handling beyond what keeps it runnable
+- One command to run
+- State in memory, no persistence
+- Mark clearly as PROTOTYPE — the user must know it's throwaway
+- Surface full state after every action
+
+When done, either:
+
+- Delete the prototype (question answered "no"), or
+- Fold validated decisions into real code (question answered "yes")
+- Do NOT leave it rotting in the repo
+
+### Phased mode (large tasks)
+
+If the work spans 3+ files or 2+ agents, break into phases automatically:
+
+1. Phase 1: core logic + test
+2. Phase 2: integration + test
+3. Phase 3: polish + final review
+
+Run phase N+1 only after phase N passes review.
+
+## Verification
+
+- Run typecheck after each slice
+- Run the full test suite at the end
+- If `lazy/review` is available, run it on completion

package/dist/skills/lazy/debug/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: lazy/debug
+description: Systematic diagnosis loop for bugs where the cause is unclear.
+---
+
+## Process
+
+1. **Reproduce.** Can you reliably trigger it? Gather exact steps/logs. If unreproducible, document environment/conditions.
+2. **Isolate.** Narrow scope: what changed (git log/bisect)? Smallest triggering input? Boundary? If bug involves a library API, check current docs via context7.
+3. **Hypothesize.** Form exactly one hypothesis. State it clearly.
+4. **Test hypothesis.** Smallest test/log that proves/disproves it. Do NOT fix yet.
+5. **Iterate.** Disproven → new hypothesis. Proven → go to 6. Stuck after 3 cycles → escalate to @lazy-oracle.
+6. **Fix.** Fix root cause, not symptoms. Confirm root cause → write failing test → minimal fix → verify test passes → full suite regression check. Then load `lazy/review`.
+
+## Output Contract
+
+- Repro, hypothesis, proof, root cause (1 line), minimal fix

package/dist/skills/lazy/grill/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: lazy/grill
+description: Interview relentlessly to sharpen a plan or design before building.
+---
+
+Run a relentless interview to stress-test a plan or design before committing to implementation.
+
+Do NOT build. Do NOT write code. Only ask questions.
+
+## Process
+
+### 1. Start from the user's prompt
+
+If the user says "grill me on X" or "I want to build Y", start grilling. If the request is vague, start from the broadest question.
+
+### 2. The questions — not a script, a posture
+
+Every question must be one of:
+
+- **Goal**: What does success look like? What must not break? Who is the user?
+- **Constraint**: What's out of scope? What's non-negotiable? What's the deadline?
+- **Risk**: What's the hardest part? What have you tried before? What went wrong?
+- **Evidence**: Why this approach over alternatives? What data supports it?
+- **Seam**: Where does this touch existing code? What's the interface boundary?
+
+Do not ask all five categories every session. Pick the ones the user's plan is weakest on.
+
+### 3. Iterate until the user says "enough"
+
+You don't need to cover everything. Stop when:
+
+- The user says "that's enough, let's build"
+- The user's answers are specific enough to write a spec
+- You've identified the top 2-3 risks
+
+### 4. Output: a crisp summary
+
+After the session, produce:
+
+```
+Grill summary:
+- 3 things we know (confirmed by user)
+- 2 things we decided (boundaries, constraints)
+- 1 biggest risk
+- Outcome: build / prototype / kill
+```
+
+Do NOT generate a PRD. That's lazy/specify's job.
+
+### When to stop grilling
+
+- User says "just do it" → output summary, stop
+- Task is trivial (one-liner, typo, config change) → skip grill entirely
+- User cannot answer the basics → flag as "not ready to build"

package/dist/skills/lazy/plan/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: lazy/plan
+description: Break a PRD or spec into independently-grabbable tracer-bullet issues.
+---
+
+Break a spec or PRD into vertical-slice issues. Each issue is a thin, end-to-end path through ALL layers — NOT horizontal (all schema, then all API, then all UI).
+
+## Process
+
+### 1. Gather context
+
+Read the PRD or spec from context. If the user passes an issue reference, fetch it.
+
+### 2. Explore the codebase (if needed)
+
+Read CONTEXT.md. Check ADRs. Look for prefactoring opportunities — "make the change easy, then make the easy change."
+
+### 3. Draft vertical slices
+
+Each slice must be:
+
+- **Demoable alone**: after this slice, something visible or verifiable works
+- **End-to-end**: cuts through schema → API → UI → tests
+- **Dependency-orderable**: blocker-first
+
+### 4. Present to user
+
+For each slice, show: title, blocked-by, user stories covered. Ask:
+
+- Granularity feel right?
+- Dependencies correct?
+- Merge or split any?
+
+### 5. Publish
+
+Create issues on the tracker in dependency order (blockers first). Use body template:
+
+```
+## What to build
+
+End-to-end behavior, not layer-by-layer.
+
+## Acceptance criteria
+
+- [ ] Criterion 1
+
+## Blocked by
+
+- Issue reference or "None"
+```
+
+Do NOT close or modify the parent spec issue.

package/dist/skills/lazy/review/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: lazy/review
+description: Code review focused on bugs, missing cases, and deletion opportunities — not additions.
+---
+
+Review code for correctness and simplicity. Default stance: **what can we delete?**
+
+## Process
+
+1. Read the diff. Understand the problem it solves.
+2. Find bugs: logic errors, off-by-one, null/undefined risks, edge cases, broken tests.
+3. Find deletions: unused code, dead branches, one-use abstractions, stdlib-replaceable code, "for later" scaffolding.
+4. Check `ponytail:` comments — do they name the ceiling and upgrade path? Mark unmarked debt.
+5. Produce review output.
+
+## Output Contract
+
+| Priority | Label         | What                                            |
+| -------- | ------------- | ----------------------------------------------- |
+| 1        | 🔴 Must fix   | real bugs, security issues                      |
+| 2        | 🟡 Should fix | code quality, simplifications                   |
+| 3        | 🟢 Can delete | removable dead code                             |
+| 4        | ponytail:     | unmarked shortcuts needing `ponytail:` comments |
+
+## Rules
+
+- Default to "delete" over "add validation/abstraction/logging."
+- Unsure if a bug is real → mark 🟡 not 🔴.
+- One finding per bullet. No essays.

package/dist/skills/lazy/security/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: lazy/security
+description: OWASP-bucketed security audit, concrete PoC required per finding
+---
+
+# lazy/security
+
+## Process
+
+1. **Scope trust boundaries.** Identify user/API/file inputs, sensitive data, and auth boundaries.
+2. **Audit by OWASP.** Check injection, authn, authz, data exposure, input validation.
+3. **PoC every finding.** For each: exact attack vector → impact → minimal fix.
+
+## Output format
+
+```
+## Security Review: [scope]
+
+### 🔴 Critical (exploitable now)
+- [OWASP category]: [finding] → [PoC] → [fix]
+
+### 🟡 Warning (defense-in-depth)
+- [OWASP category]: [finding] → [mitigation]
+
+### 🟢 Clean
+- [area reviewed]: no issues found
+```
+
+Only report real, exploitable issues. 🔴 requires concrete PoC. Mark theoretical risks 🟡.

package/dist/skills/lazy/simplify/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: lazy/simplify
+description: Find code to delete or collapse. Ponytail: deletion over addition, one line over fifty.
+---
+
+Find what to delete, one line per finding. The goal is not "cleaner" — it's "less."
+
+Ponytail rule: every simplification must pass the deletion test — "would removing this concentrate complexity or just move it?" Only the former counts as simplification.
+
+## When to simplify
+
+- After a feature works and tests pass, but feels heavier than needed
+- During review when complexity is flagged
+- When you encounter deep nesting, long functions, dead code, or wrappers that add no value
+- After merging changes that introduced duplication
+
+Do NOT simplify code you don't understand yet.
+
+## Process
+
+### Step 1: Understand before touching
+
+- What does this code do?
+- What calls it? What does it call?
+- Are there tests?
+- Why was it written this way?
+
+### Step 2: Scan for deletion opportunities
+
+- Dead code (exports no one imports, branches that never trigger)
+- Wrappers that add no value (a function that just calls another function with no extra logic)
+- Duplicated logic
+- Boolean flag parameters (replace with two functions)
+- Nested ternaries (replace with control flow)
+- Wrappers or abstractions that could be inlined without losing clarity
+
+### Step 3: Deep scan (absorbed from improve-codebase-architecture)
+
+For modules in the affected area, check:
+
+- **Depth**: is the interface nearly as complex as the implementation? If so, it's shallow — look for ways to move complexity behind the interface.
+- **Seam**: can you alter behavior without editing in that place? If not, there's no real seam.
+- **Leverage**: does one implementation serve N call sites? If N=1 and the abstraction has overhead, inline it.
+- **Locality**: does understanding one concept require bouncing between many small modules? If so, consider merging.
+
+Use the vocabulary exactly: **module**, **interface**, **depth**, **seam**, **adapter**, **leverage**, **locality**.
+
+### Step 4: Verify
+
+- Make one change at a time
+- Run tests after each change
+- The result must be easier to understand AND have fewer lines than the original

package/dist/skills/lazy/specify/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: lazy/specify
+description: Turn grilled discussion into a PRD with domain terms and acceptance criteria.
+---
+
+Synthesize what you already know into a PRD. Do NOT interview the user — just write it from the conversation.
+
+## Process
+
+### 1. Explore the codebase
+
+Read CONTEXT.md if it exists. Check ADRs in the affected area. Use domain vocabulary from the project's glossary.
+
+### 2. Identify seams
+
+Sketch the interfaces where this feature connects to existing code. Use the vocabulary of codebase-design: **module**, **seam**, **adapter**, **leverage**. Prefer existing seams over new ones. Fewer seams = better; ideal = one.
+
+Check with the user that these seams match their expectations.
+
+### 3. Write the PRD
+
+Use this template:
+
+```
+## Problem Statement
+
+The problem from the user's perspective.
+
+## Solution
+
+The solution, from the user's perspective.
+
+## User Stories
+
+1. As an <actor>, I want <feature>, so that <benefit>
+
+Extensive. Cover all aspects.
+
+## Implementation Decisions
+
+Modules to build/modify, interfaces, architectural decisions, schema changes, API contracts.
+
+Do NOT include file paths or code snippets unless a prototype produced a decision-rich snippet.
+
+## Domain Glossary (new terms added)
+
+Any new terms introduced by this feature. Existing terms in CONTEXT.md should be referenced, not redefined.
+
+## Testing Decisions
+
+What makes a good test (external behavior only). Which seam to test at. Prior art.
+
+## Out of Scope
+
+## Further Notes
+```
+
+### 4. Publish
+
+Create a tracking issue (or write to a file). Apply the `ready-for-plan` label.
+
+If user wants an ADR, write it to `docs/adr/<NNNN>-<title>.md`.