opencode-manifold 0.5.14 → 0.5.15

package/src/templates/manifold/schema.md

@@ -1,234 +0,0 @@
-# Manifold Schema
-
-This document defines the conventions for all wiki elements in the Manifold folder.
-
----
-
-## Task File Format
-
-Location: `Manifold/tasks/<task-id>.md`
-
-```markdown
-# <task-id>: <Task Title>
-
-**Date:** <YYYY-MM-DD>
-**Status:** <IN_PROGRESS | COMPLETED | ESCALATED_USER>
-**Loops:** <number>
-**Git Commit:** <commit-hash>
-
-## Task
-<Task description from the plan>
-
-## Context Used
-- codebase-index: <files or search terms used>
-- Wiki: <prior task logs referenced>
-- Graph: <graph files read>
-
-## Scoped Prompt
-> <The composed prompt for Senior Dev>
-
-## Design Decisions
-- <Decision 1 and why it was made>
-- <Decision 2 and why it was made>
-
-## Files Touched
-- [[<file-path-1>]]
-- [[<file-path-2>]]
-
-## Loop History
-### Loop 1
-- **Senior:** <brief summary of Senior's implementation>
-- **Junior:** <Junior's COMPLETE or QUESTIONS response>
-
-### Loop 2
-- **Senior:** <brief summary of Senior's revision>
-- **Junior:** <Junior's COMPLETE or QUESTIONS response>
-```
-
----
-
-## index.md Update Procedure
-
-After completing a task, add an entry under the correct plan slug section.
-
-**If the plan slug section doesn't exist, create it:**
-
-```markdown
-## <plan-slug> — <Plan Title>
-
-- [[<task-id>]] — <one-line summary> | <date> | <STATUS>
-```
-
-**If the plan slug section exists, append:**
-
-```markdown
-- [[<task-id>]] — <one-line summary> | <date> | <STATUS>
-```
-
----
-
-## log.md Append Format
-
-Append a single line at the end of `Manifold/log.md`:
-
-```markdown
-## [<YYYY-MM-DD>] <task-id> | <description> | <STATUS> | <loop-count> loops
-```
-
-Example:
-```markdown
-## [2026-04-06] share-cart-001 | Implement cart data model | COMPLETED | 2 loops
-```
-
----
-
-## Graph File Format
-
-Location: `Manifold/graph/<graph-name>.md`
-
-Where `<graph-name>` is the original file path with:
-- Replace `/` with `__SL__`
-- Replace `.` with `__DT__`
-- Append `.md`
-
-Examples:
-- `src/middleware/auth.ts` → `src__SL__middleware__SL__auth__DT__ts.md`
-- `src/utils/helpers.ts` → `src__SL__utils__SL__helpers__DT__ts.md`
-
-```markdown
----
-filePath: <original-file-path>
-calls:
-  - <file this file calls>
-  - <another file>
-dependsOn:
-  - <file this file depends on>
-  - <another dependency>
-tasksThatEdited:
-  - <task-id-1>
-  - <task-id-2>
----
-
-## Calls
-- <file this file calls>
-- <another file>
-
-## Depends On
-- <file this file depends on>
-- <another dependency>
-
-## Tasks That Edited
-- [[<task-id-1>]]
-- [[<task-id-2>]]
-```
-
-**YAML frontmatter** is the source of truth for programmatic reads/writes. The **markdown body** is a rendered view for Obsidian's graph view (wikilinks enable connections).
-
-**`Calls` and `Depends On`** are populated automatically from the codebase index after each task completes. Do NOT manually edit these sections.
-
-**On task completion:** Add the task ID to the `tasksThatEdited` frontmatter field and the `Tasks That Edited` body section of all graph files for files that were touched.
-
-**If graph file doesn't exist:** Create it with the structure above.
-
----
-
-## Wikilink Conventions
-
-- **Task references:** `[[<task-id>]]`
-  - Example: `[[share-cart-001]]`
-- **File references:** `[[<file-path>]]`
-  - Example: `[[src/middleware/auth.ts]]`
-- **Always use absolute-style paths** (no `./` or `../`)
-
----
-
-## Status Values
-
-| Status | When to Use |
-|--------|-------------|
-| `IN_PROGRESS` | Task log created, implementation ongoing |
-| `COMPLETED` | Task finished successfully, Junior approved |
-| `ESCALATED_USER` | Task blocked, requires human intervention |
-
----
-
-## Task Naming
-
-1. Generate a short slug (<30 chars) from the plan
-2. Check `Manifold/plans.json` for collision
-3. If collision: append number (e.g., `share-cart-v2`)
-4. Task files: `Manifold/tasks/<slug>-001.md`, `<slug>-002.md`, etc.
-
----
-
-## Plans Registry
-
-Location: `Manifold/plans.json`
-
-Format:
-```json
-{
-  "<plan-slug>": {
-    "full_title": "<Plan title>",
-    "task_count": 7,
-    "status": "in_progress",
-    "created": "YYYY-MM-DD",
-    "plan_file": "/path/to/plan.md"
-  }
-}
-```
-
----
-
-## Task List Format
-
-Location: `Manifold/plans/<slug>-tasks.md`
-
-Generated by the Todo agent when the input is not already a granular task list.
-
-```markdown
-# Task List: <Plan Title>
-
-**Source:** <path or description of the original input>
-**Generated:** <YYYY-MM-DD>
-**Total Tasks:** <number>
-
----
-
-## Task 1: <title>
-
-- **Description:** <what to do — framed as data transformation where natural>
-- **Purity:** <pure | shell | mixed>
-- **Dependencies:** <none | task numbers>
-- **Input Contract:** <what data/inputs this task needs>
-- **Output Contract:** <what this task produces>
-
----
-
-## Task 2: <title>
-
-- **Description:** <what to do>
-- **Purity:** <pure | shell | mixed>
-- **Dependencies:** 1
-- **Input Contract:** <what it needs from Task 1>
-- **Output Contract:** <what it produces>
-```
-
-### Purity Tags
-
-| Tag | Meaning | When to Use |
-|-----|---------|-------------|
-| `pure` | Data transformation only. No IO, no side effects, no external state. Same input always produces same output. | Task is a self-contained computation: validation, transformation, calculation, schema definition |
-| `shell` | IO or side-effect boundary. Reads/writes to external systems, manages state. | Task is wiring: API endpoints, database operations, file I/O, UI rendering |
-| `mixed` | Logic and IO are interleaved in a way that's impractical to separate without over-engineering. | Task naturally combines both and splitting would create ceremony |
-
-### Dispatch Convention with Purity
-
-When the Manifold agent dispatches a tagged task, the purity tag is included in the description:
-
-```
-dispatchTask({ task_number: 1, description: "[pure] Define cart item schema", plan_file: "..." })
-dispatchTask({ task_number: 2, description: "[shell] Wire cart endpoint to database", plan_file: "..." })
-```
-
-This allows the Clerk to apply purity-aware prompt framing when composing scoped prompts.

package/src/templates/manifold/state.json

@@ -1,11 +0,0 @@
-{
-  "current_task": null,
-  "state": "idle",
-  "loop_count": 0,
-  "clerk_retry_count": 0,
-  "scoped_prompt": null,
-  "senior_output": null,
-  "junior_response": null,
-  "debug_suggestion": null,
-  "loop_history": []
-}

package/src/templates/skills/clerk-orchestration/SKILL.md

@@ -1,139 +0,0 @@
-# Clerk Orchestration Skill
-
-This skill guides the Clerk agent through researching context and composing effective scoped prompts.
-
-## Research Phase
-
-### 1. Codebase-Index Search
-
-Use the `codebase-index` tool for semantic search:
-
-**How to query:**
-- Think about what code is relevant to the task
-- Formulate queries like:
-  - "Where is authentication logic?"
-  - "How are API routes structured?"
-  - "What middleware patterns exist?"
-- The tool understands intent, not just keywords
-
-**Parameters:**
-- `query`: Your search phrase
-- `maxResults`: From `Manifold/settings.json` (default: 10)
-
-**When to use vs direct file reads:**
-- Use semantic search when you don't know the exact file
-- Use direct reads when you already know which file to check
-
-### 2. Wiki Lookback
-
-Read recent task logs from `Manifold/tasks/`:
-
-**What to look for:**
-- Design decisions that might apply
-- Rejected approaches (avoid repeating mistakes)
-- Established patterns and conventions
-- Dependencies between tasks
-
-**Parameters:**
-- `recentTaskCount`: From `Manifold/settings.json` (default: 3)
-
-**Search strategies:**
-- By keyword: search for terms in the task description
-- By file path: look for tasks that touched the same files
-- By slug: if you know the plan slug, find related tasks
-
-### 3. Graph Analysis
-
-Read graph files from `Manifold/graph/` for dependency analysis:
-
-**Graph file naming:** `src/middleware/auth.ts` → `src_middleware_auth_ts.md`
-
-**What graph files contain:**
-- `## Calls`: What this file calls
-- `## Depends On`: What this file depends on
-- `## Tasks That Edited`: Which tasks modified this file
-
-**How to find relevant graphs:**
-1. Start from files identified in codebase search
-2. Read their graph entries
-3. Follow the dependency chain (read graphs for dependencies too)
-4. Limit to ~5 most relevant graphs to avoid overload
-
-## Scoped Prompt Composition
-
-### The Formula
-
-A good scoped prompt contains:
-
-1. **Task Goal** (1-2 sentences)
-   - What the Senior Dev must accomplish
-   - Be specific, not "implement auth"
-   - Prefer framing as a data transformation: "Given X, produce Y" when this makes the goal clearer
-
-2. **Relevant Code Snippets** (as needed)
-   - Include 3-10 of the most relevant snippets
-   - Include file paths
-   - Focus on the patterns to follow
-
-3. **Prior Decisions** (if applicable)
-   - Relevant design decisions from wiki
-   - Why certain approaches were chosen
-   - What to avoid
-
-4. **Design Guidelines** (1-5 bullet points)
-   - Language/framework conventions
-   - Project-specific patterns
-   - Non-functional requirements (performance, security)
-
-5. **Purity Directive** (if task has a purity tag)
-   - `[pure]` → Explicitly state: no IO, no side effects, no external state. Frame the input/output contract.
-   - `[shell]` → Clarify the IO boundary: what is being read/written, what external system is involved
-   - `[mixed]` → Note where the logic/IO boundary falls; keep the pure portions clean
-   - No tag → Skip this section
-
-### Purity-Aware Prompting
-
-The Todo agent may tag tasks with purity indicators. Use these to shape how you frame the scoped prompt:
-
-**For `pure` tasks:**
-- Frame the task goal as: "Write a function/module that transforms [input type] into [output type]"
-- Specify the input/output contract explicitly
-- Emphasize: no filesystem, no network, no database, no global state mutations
-- Example: *"Write `calculateDiscount(items: CartItem[], rules: DiscountRule[]): number` — pure function, no IO, deterministic output"*
-
-**For `shell` tasks:**
-- Identify what upstream pure logic this task wires up (if any)
-- Specify the IO boundary: database operations, API calls, file reads/writes
-- Example: *"Wire the `calculateDiscount` function into the `/api/cart/update` endpoint. Read cart from DB, call the pure function, persist result"*
-
-**For `mixed` tasks:**
-- Acknowledge that logic and IO are interleaved
-- Help the Senior Dev keep the logic portions testable by noting where the boundary falls
-- Don't force an artificial split — just make the boundary visible
-
-**Pragmatic rule:** If functional framing makes the goal *less clear* (e.g., in a framework that's inherently imperative like Express middleware), use whatever framing is most natural for the project. The goal is clarity, not purity dogma.
-
-### Breadth vs Focus
-
-**Include enough to be useful:**
-- The Senior Dev needs to understand the context
-- Include files that will be modified
-- Include files that set patterns to follow
-
-**Don't overwhelm:**
-- Don't include the entire codebase
-- Don't include every file that touches a module
-- Prioritize: direct dependencies > indirect, recent changes > old
-
-**Rule of thumb:** If the prompt gets longer than ~800 words, trim it.
-
-## Checklist Before Submitting
-
-- [ ] Task goal is specific and actionable
-- [ ] Task goal is framed as a data transformation where natural (without forcing it)
-- [ ] Code snippets are directly relevant (not just interesting)
-- [ ] Prior decisions are actually applicable to this task
-- [ ] Design guidelines are specific (not vague platitudes)
-- [ ] Purity directive matches the task's purity tag (if present)
-- [ ] Prompt length is reasonable (under ~800 words)
-- [ ] All context documents are listed for the task log

package/src/templates/skills/research/SKILL.md

@@ -1,75 +0,0 @@
-# Research Skill
-
-Use this skill to gather relevant context before composing a scoped prompt or decomposing a plan.
-
-## When to Use
-
-Use this skill when:
-- The Clerk needs to gather context before calling @senior-dev
-- The Todo agent needs to research the codebase before decomposing a plan
-
-## Research Steps
-
-### 1. Codebase-Index Search
-
-Use the `codebase-index` tool for semantic search:
-
-**How to query:**
-- Think about what code is relevant to the task
-- Formulate queries like:
-  - "Where is authentication logic?"
-  - "How are API routes structured?"
-  - "What middleware patterns exist?"
-- The tool understands intent, not just keywords
-
-**Parameters:**
-- `query`: Your search phrase
-- `maxResults`: From `Manifold/settings.json` (default: 10)
-
-**When to use vs direct file reads:**
-- Use semantic search when you don't know the exact file
-- Use direct reads when you already know which file to check
-
-### 2. Wiki Lookback
-
-Read recent task logs from `Manifold/tasks/`:
-
-**What to look for:**
-- Design decisions that might apply
-- Rejected approaches (avoid repeating mistakes)
-- Established patterns and conventions
-- Dependencies between tasks
-
-**Parameters:**
-- `recentTaskCount`: From `Manifold/settings.json` (default: 3)
-
-**Search strategies:**
-- By keyword: search for terms in the task description
-- By file path: look for tasks that touched the same files
-- By slug: if you know the plan slug, find related tasks
-
-### 3. Graph Analysis
-
-Read graph files from `Manifold/graph/` for dependency analysis:
-
-**Graph file naming:** `src/middleware/auth.ts` → `src_middleware_auth_ts.md`
-
-**What graph files contain:**
-- `## Calls`: What this file calls
-- `## Depends On`: What this file depends on
-- `## Tasks That Edited`: Which tasks modified this file
-
-**How to find relevant graphs:**
-1. Start from files identified in codebase search
-2. Read their graph entries
-3. Follow the dependency chain (read graphs for dependencies too)
-4. Limit to ~5 most relevant graphs to avoid overload
-
-## Output
-
-After using this skill, document the context sources used:
-- Which files were identified as relevant
-- Which wiki logs provided prior decisions
-- Which graph files showed dependencies
-
-This context documentation will be needed for the task log.

package/src/templates/skills/wiki-ingest/SKILL.md

@@ -1,139 +0,0 @@
-# Wiki Ingest Skill
-
-This skill guides the Clerk on how to log task results to the wiki.
-
-## Task File Format
-
-Create or update `Manifold/tasks/<task-id>.md`:
-
-```markdown
-# <task-id>: <Task Title>
-
-**Date:** <YYYY-MM-DD>
-**Status:** <IN_PROGRESS | COMPLETED | ESCALATED_USER>
-**Loops:** <number>
-**Git Commit:** <commit-hash>
-
-## Task
-<Task description>
-
-## Context Used
-- codebase-index: <files or search terms>
-- Wiki: <prior task logs referenced>
-- Graph: <graph files read>
-
-## Scoped Prompt
-> <The composed prompt for Senior Dev>
-
-## Design Decisions
-- <Decision 1 and why>
-- <Decision 2 and why>
-
-## Files Touched
-- [[<file-path-1>]]
-- [[<file-path-2>]]
-
-## Loop History
-### Loop 1
-- **Senior:** <what Senior produced>
-- **Junior:** <Junior's response>
-
-### Loop 2
-- **Senior:** <what Senior produced>
-- **Junior:** <Junior's response>
-```
-
-## Index.md Update
-
-After completing a task, add entry to `Manifold/index.md`:
-
-```markdown
-## <plan-slug> — <Plan Title>
-
-- [[<task-id-001>]] — <one-line summary> | <date> | COMPLETED
-- [[<task-id-002>]] — <one-line summary> | <date> | IN_PROGRESS
-```
-
-## Log.md Append
-
-Append a line to `Manifold/log.md`:
-
-```markdown
-## [<date>] <task-id> | <description> | <STATUS> | <loop-count> loops
-```
-
-Example:
-```markdown
-## [2026-04-06] share-cart-001 | Implement cart data model | COMPLETED | 2 loops
-```
-
-## Graph File Update
-
-For each file touched, update or create `Manifold/graph/<graph-name>.md`:
-
-```markdown
----
-filePath: <original-file-path>
-calls:
-  - <files this file calls>
-dependsOn:
-  - <files this file depends on>
-tasksThatEdited:
-  - <task-id>
----
-
-## Calls
-- <files this file calls>
-
-## Depends On
-- <files this file depends on>
-
-## Tasks That Edited
-- [[<task-id>]]
-- [[<other-task-id>]]
-```
-
-**IMPORTANT:** Only update the `Tasks That Edited` section and the `tasksThatEdited` frontmatter field. The `Calls` and `Depends On` sections are populated automatically from the codebase index — do NOT manually edit them.
-
-### Graph Filename Convention
-
-Replace `/` with `__SL__` and `.` with `__DT__`, append `.md`:
-- `src/middleware/auth.ts` → `src__SL__middleware__SL__auth__DT__ts.md`
-- `src/utils/helpers.ts` → `src__SL__utils__SL__helpers__DT__ts.md`
-
-## Status Values
-
-| Status | When to Use |
-|--------|-------------|
-| `IN_PROGRESS` | Task log created, implementation ongoing |
-| `COMPLETED` | Task finished successfully, Junior approved |
-| `ESCALATED_USER` | Task blocked, requires human intervention |
-
-## Wikilink Conventions
-
-- Tasks: `[[task-id]]` — e.g., `[[share-cart-001]]`
-- Files: `[[file-path]]` — e.g., `[[src/middleware/auth.ts]]`
-- Always use absolute-style paths for files
-
-## Loop History Recording
-
-For each Senior→Junior exchange, record:
-1. What Senior produced (brief summary)
-2. Junior's response (COMPLETE or QUESTIONS + issues)
-
-If Debug was involved, add:
-3. Debug's analysis and suggestion
-4. Senior's response to the debug suggestion
-5. Debug's final review
-
-## Checklist Before Completing
-
-- [ ] Task file created with all sections
-- [ ] Status set correctly (COMPLETED or ESCALATED_USER)
-- [ ] Loop count accurate
-- [ ] All files touched listed with wikilinks
-- [ ] Design decisions recorded with reasoning
-- [ ] Loop history complete
-- [ ] index.md updated
-- [ ] log.md appended
-- [ ] All touched files' graph entries updated

package/src/templates/skills/wiki-query/SKILL.md

@@ -1,94 +0,0 @@
-# Wiki Query Skill
-
-This skill guides the Clerk on how to search the wiki for prior context.
-
-## Where to Look
-
-### 1. index.md — Task Catalog
-
-`Manifold/index.md` lists all tasks by plan.
-
-**Search strategies:**
-- By plan slug: look under the plan's section
-- By date: find tasks from a specific time period
-- By status: find IN_PROGRESS tasks to understand current work
-
-### 2. log.md — Chronological Log
-
-`Manifold/log.md` has a running history of all tasks.
-
-**Format:**
-```markdown
-## [2026-04-06] task-001 | Implement auth | COMPLETED | 2 loops
-```
-
-**Search strategies:**
-- By date range: find recent completions
-- By status: find ESCALATED_USER tasks (to avoid similar issues)
-- By loop count: find high-loop tasks (might indicate complexity)
-
-### 3. Task Files — Detailed History
-
-`Manifold/tasks/<task-id>.md` has full task details.
-
-**What to look for:**
-- `## Design Decisions` — why things were done a certain way
-- `## Loop History` — what issues Junior caught
-- `## Context Used` — what Clerk researched
-
-**Search strategies:**
-- By keyword: grep for terms like "cache", "auth", "performance"
-- By file: find tasks that touched `src/models/cart.ts`
-- By decision: find tasks that decided on "Map vs Array"
-
-### 4. Graph Files — Dependency Analysis
-
-`Manifold/graph/<graph-name>.md` tracks file relationships.
-
-**What they contain:**
-- YAML frontmatter with `filePath`, `calls`, `dependsOn`, `tasksThatEdited` (source of truth for programmatic access)
-- Rendered markdown body with `## Calls`, `## Depends On`, `## Tasks That Edited` sections (for Obsidian graph view)
-
-**How to use:**
-1. Find graph files relevant to your task (from codebase search)
-2. Read them to understand dependencies (use frontmatter for structured data)
-3. Check "Tasks That Edited" for prior work on those files
-4. Read relevant task files for context
-
-## Combining Sources
-
-### Example: Adding share functionality to cart
-
-1. **Codebase search** → identified `src/models/cart.ts` and `src/utils/share.ts`
-2. **Graph for cart.ts** → depends on `src/models/order.ts`, called by `src/routes/cart.ts`
-3. **index.md** → found "share-cart" plan with 3 completed tasks
-4. **Read task logs** → share-cart-001 used Map for items, share-cart-002 used localStorage
-5. **Result** → scoped prompt includes: use Map for O(1) lookup, persist to localStorage, follow the share URL format from task-002
-
-## What to Look For
-
-### Design Decisions
-- Why was X chosen over Y?
-- What constraints influenced the approach?
-- What was explicitly rejected and why?
-
-### Rejected Approaches
-- What has Junior (or Debug) rejected before?
-- What patterns should Senior avoid?
-
-### Established Conventions
-- Project-specific file organization
-- Language idioms used in this codebase
-- Testing patterns
-
-### Prior Art
-- Similar features that might share code
-- Shared utilities already available
-- Dependencies between tasks
-
-## Search Tips
-
-- **Be specific**: "JWT validation" not just "auth"
-- **Use file paths**: "src/middleware/auth" to find related files
-- **Check dates**: recent decisions are more relevant than old ones
-- **Follow links**: wikilinks in task files lead to related context