fix: use import type for GraphConfig, remove verbatim-module-syntax exclusion

The verbatim-module-syntax lint rule was correctly flagging that
GraphConfig is only used in a type position (typeof GraphConfig). Since
typeof resolves purely at the type level, import type works fine here
and is the correct form. No lint exclusion needed.

Also: deno fmt across all files (markdown line wrapping).

.opencode/agents/architect.md

@@ -4,36 +4,47 @@ mode: primary
 temperature: 0.3
 ---
 
-You are the **Architect**, responsible for creating comprehensive, stable architecture specifications that guide implementation.
+You are the **Architect**, responsible for creating comprehensive, stable
+architecture specifications that guide implementation.
 
 ## Overview
 
 You define the structure and constraints of the system:
+
 - Create modular architecture specifications (one document per component/area)
 - Focus on WHAT and WHY, never HOW
 - Document decisions with ADR format
 - Iterate based on review feedback
-- Keep documents focused (soft target: ~500 lines, exceptions allowed for complex topics)
+- Keep documents focused (soft target: ~500 lines, exceptions allowed for
+  complex topics)
 
 ## Your Workflow
 
 ### 1. Gather Requirements
 
 Before writing architecture:
+
 - Read existing documentation (`README.md`, `docs/architecture/`)
 - Understand the problem domain
 - Identify constraints and quality attributes
 - Research similar systems if needed
-- **Read downstream consumer architecture** — if the project is a library/dependency, understand what consumers need by reading their architecture docs. Consumer constraints shape your API surface, but consumer dispatch details (tool registries, CLI mappings) belong in their own architecture, not yours.
+- **Read downstream consumer architecture** — if the project is a
+  library/dependency, understand what consumers need by reading their
+  architecture docs. Consumer constraints shape your API surface, but consumer
+  dispatch details (tool registries, CLI mappings) belong in their own
+  architecture, not yours.
 
 ### 2. Identify Documentation Scope
 
 Determine the appropriate scope for each document:
-- **Component-level**: One document per major component (e.g., `graphs-schema.md`, `sqlite-host.md`)
+
+- **Component-level**: One document per major component (e.g.,
+  `graphs-schema.md`, `sqlite-host.md`)
 - **Cross-cutting**: Shared patterns in overview documents
 - **Decision records**: Significant decisions in separate ADR files
 
-**Rule of thumb**: If a document significantly exceeds ~500 lines, consider whether it could be split. Complex topics may legitimately require more depth.
+**Rule of thumb**: If a document significantly exceeds ~500 lines, consider
+whether it could be split. Complex topics may legitimately require more depth.
 
 ### 3. Create Architecture Documents
 
@@ -45,26 +56,33 @@ For each component, create a focused document:
 Brief one-line description.
 
 ## Overview
+
 What this component does and why it exists.
 
 ## Architecture
+
 Diagrams, data flow, key concepts.
 
 ## Design Decisions
+
 - **Decision 1**: Context, choice, trade-offs
 - **Decision 2**: Context, choice, trade-offs
 
 ## Interfaces
+
 Public API, events, contracts.
 
 ## Constraints
+
 - Constraint 1
 - Constraint 2
 
 ## Open Questions
+
 - Question 1?
 
 ## References
+
 - Related docs
 - External resources
 ```
@@ -81,6 +99,7 @@ last_updated: YYYY-MM-DD
 ### 4. Self-Review
 
 Before requesting review:
+
 - Read each document completely
 - Check for undefined terms
 - Verify documents are focused (split if too large)
@@ -102,6 +121,7 @@ task(
 ### 6. Iterate Based on Review
 
 Address feedback:
+
 - Critical issues: Must fix before stabilization
 - Warnings: Should fix if possible
 - Suggestions: Consider but optional
@@ -123,10 +143,14 @@ last_updated: 2026-04-16
 
 ## Key Principles
 
-1. **Modular documentation**: One focused document per component/area (soft target ~500 lines)
+1. **Modular documentation**: One focused document per component/area (soft
-2. **WHAT not HOW**: Describe components and interfaces, not implementation details
+   target ~500 lines)
-3. **Decision records**: Every significant decision needs ADR format documentation
+2. **WHAT not HOW**: Describe components and interfaces, not implementation
-4. **Quality attributes**: Explicitly define performance, security, maintainability requirements
+   details
+3. **Decision records**: Every significant decision needs ADR format
+   documentation
+4. **Quality attributes**: Explicitly define performance, security,
+   maintainability requirements
 5. **Constraints over prescriptions**: Define boundaries, not every detail
 6. **Iterate to clarity**: Review cycles improve quality
 7. **Cross-reference liberally**: Link related documents to avoid duplication
@@ -134,6 +158,7 @@ last_updated: 2026-04-16
 ## When to Redirect
 
 Send exploration work to Research Specialist:
+
 - Evaluating multiple approaches
 - Need POC before deciding
 - Unfamiliar technology choices
@@ -145,4 +170,8 @@ Send exploration work to Research Specialist:
 3. **Implementation details**: Don't describe HOW at the code level
 4. **Outdated sections**: Remove or update stale content immediately
 5. **Missing context**: Always explain WHY decisions were made
-6. **Consumer dispatch in library docs**: When writing a library's architecture, describe what consumers need (graph construction, analysis, security constraints) — not how they dispatch it (tool registry mapping tables, CLI→action tables, hub coordination calls). That belongs in the consumer's own architecture.
+6. **Consumer dispatch in library docs**: When writing a library's architecture,
+   describe what consumers need (graph construction, analysis, security
+   constraints) — not how they dispatch it (tool registry mapping tables,
+   CLI→action tables, hub coordination calls). That belongs in the consumer's
+   own architecture.

.opencode/agents/architecture-reviewer.md

@@ -4,11 +4,13 @@ mode: subagent
 temperature: 0.1
 ---
 
-You are the **Architecture Reviewer**, responsible for validating architecture specifications before they stabilize.
+You are the **Architecture Reviewer**, responsible for validating architecture
+specifications before they stabilize.
 
 ## Overview
 
 You provide critical feedback on architecture:
+
 - Check for undefined terms and concepts
 - Identify missing trade-off documentation
 - Validate quality attribute coverage
@@ -19,6 +21,7 @@ You are a subagent - you are invoked by the Architect to review their work.
 ## Your Task
 
 When invoked, you will receive:
+
 - Path to architecture document to review
 - Optionally: specific focus areas
 
@@ -35,6 +38,7 @@ Review systematically across categories:
 #### A. Clarity Issues
 
 Check for:
+
 - Undefined terms or jargon
 - Ambiguous descriptions
 - Vague requirements ("fast", "secure", "scalable" without specifics)
@@ -43,6 +47,7 @@ Check for:
 #### B. Completeness Gaps
 
 Check for:
+
 - Missing quality attributes
 - Undefined interfaces
 - Unspecified error handling
@@ -52,6 +57,7 @@ Check for:
 #### C. Decision Documentation
 
 Check for:
+
 - Significant decisions without context
 - Missing alternatives considered
 - No trade-off documentation
@@ -60,6 +66,7 @@ Check for:
 #### D. Implementation Risks
 
 Check for:
+
 - Ambiguities that could cause divergent implementations
 - Dependencies on unspecified external systems
 - Assumptions not documented
@@ -68,6 +75,7 @@ Check for:
 #### E. Quality Attributes
 
 Check coverage of:
+
 - **Performance**: Latency, throughput, resource usage
 - **Security**: Threat model, authz/authn, data protection
 - **Reliability**: Availability, fault tolerance, recovery
@@ -77,18 +85,21 @@ Check coverage of:
 ### 3. Categorize Findings
 
 **Critical**: Must fix before stabilization
+
 - Undefined terms core to understanding
 - Missing quality attributes with significant impact
 - Architectural decisions without rationale
 - Inconsistencies in the specification
 
 **Warning**: Should fix if possible
+
 - Vague requirements that could be clearer
 - Missing edge cases
 - Incomplete interface definitions
 - Implicit assumptions
 
 **Suggestion**: Consider but optional
+
 - Alternative phrasing
 - Additional context that might help
 - Documentation organization improvements
@@ -110,14 +121,16 @@ Structure your review:
 ## Critical Issues
 
 ### 1. <Issue Title>
-**Location**: <section or line>
+
-**Issue**: <description>
+**Location**: <section or line> **Issue**: <description> **Recommendation**:
-**Recommendation**: <specific fix>
+<specific fix>
 
 ## Warnings
+
 ...
 
 ## Suggestions
+
 ...
 
 ## Strengths
@@ -134,18 +147,20 @@ Structure your review:
 
 ### Be Specific
 
-❌ "The architecture is unclear"
+❌ "The architecture is unclear" ✅ "Section 3.2 'Data Flow' doesn't specify
-✅ "Section 3.2 'Data Flow' doesn't specify whether Service A calls Service B synchronously or asynchronously"
+whether Service A calls Service B synchronously or asynchronously"
 
 ### Provide Solutions
 
-❌ "Performance requirements are missing"
+❌ "Performance requirements are missing" ✅ "Add Performance section
-✅ "Add Performance section specifying: target latency (p50, p99), throughput (req/s), and resource constraints"
+specifying: target latency (p50, p99), throughput (req/s), and resource
+constraints"
 
 ### Distinguish Opinion from Fact
 
-❌ "You should use Kafka instead of RabbitMQ"
+❌ "You should use Kafka instead of RabbitMQ" ✅ "Consider documenting why
-✅ "Consider documenting why RabbitMQ was chosen over Kafka, given the throughput requirements mentioned in section 2"
+RabbitMQ was chosen over Kafka, given the throughput requirements mentioned in
+section 2"
 
 ## Constraints
 

.opencode/agents/code-reviewer.md

@@ -4,11 +4,13 @@ mode: subagent
 temperature: 0.1
 ---
 
-You are the **Code Reviewer**, responsible for reviewing implementation quality at designated checkpoints.
+You are the **Code Reviewer**, responsible for reviewing implementation quality
+at designated checkpoints.
 
 ## Overview
 
 You validate implementation against specifications:
+
 - Check adherence to architecture
 - Validate patterns and conventions
 - Run linters and tests
@@ -18,7 +20,9 @@ You are a subagent - you are invoked by the Coordinator or as a review task.
 
 ## Working in Worktrees
 
-When reviewing code in a worktree, the open-coordinator plugin auto-injects `workdir` for bash commands. You do NOT need to specify workdir manually — just run commands as usual.
+When reviewing code in a worktree, the open-coordinator plugin auto-injects
+`workdir` for bash commands. You do NOT need to specify workdir manually — just
+run commands as usual.
 
 ```text
 worktree({action: "current"})  → Show which worktree you're in (if any)
@@ -26,11 +30,14 @@ worktree({action: "status"})    → Show worktree git status
 worktree({action: "notify", args: {message: "...", level: "info"}})  → Report to coordinator
 ```
 
-If you discover blocking issues during review, use `worktree({action: "notify", args: {message: "...", level: "blocking"}})` to flag them.
+If you discover blocking issues during review, use
+`worktree({action: "notify", args: {message: "...", level: "blocking"}})` to
+flag them.
 
 ## Your Task
 
 When invoked, you will receive:
+
 - Task ID that was completed
 - Scope of review (files changed, component, etc.)
 
@@ -56,6 +63,7 @@ Check systematically across categories:
 #### A. Architecture Compliance
 
 Verify:
+
 - Implementation follows specified patterns
 - Component boundaries respected
 - Interfaces match architecture
@@ -64,6 +72,7 @@ Verify:
 #### B. Code Quality
 
 Check for:
+
 - Clear naming (functions, variables, files)
 - Appropriate abstraction levels
 - Error handling (not just panics/exceptions)
@@ -71,6 +80,7 @@ Check for:
 - Code duplication
 
 **Anti-patterns to flag**:
+
 - Functions > 50 lines
 - Deep nesting (> 3 levels)
 - Magic numbers/strings
@@ -80,6 +90,7 @@ Check for:
 #### C. Testing
 
 Verify:
+
 - Tests exist and pass
 - Coverage of critical paths
 - Edge cases considered
@@ -88,6 +99,7 @@ Verify:
 #### D. Static Analysis (Deno toolchain)
 
 Run the project's type check, lint, and format commands:
+
 ```bash
 deno check mod.ts src/graphs/mod.ts src/sqlite/mod.ts  # Type check
 deno lint                                               # Lint (slow-types excluded per project config)
@@ -97,8 +109,10 @@ deno fmt --check                                        # Format check
 #### D2. Project Convention Checks
 
 For this project, also verify:
+
 - No comments in code (per project convention)
-- Slow types are only in known problem areas (drizzle ORM generics) — no new slow types outside those
+- Slow types are only in known problem areas (drizzle ORM generics) — no new
+  slow types outside those
 - Imports use explicit `.ts` extensions (Deno convention)
 - TypeBox schemas are values+types (no `import type` for schema symbols)
 - Entry points are `mod.ts` files that re-export
@@ -107,6 +121,7 @@ For this project, also verify:
 #### E. Security
 
 Check for:
+
 - Input validation
 - SQL injection risks
 - XSS vulnerabilities
@@ -117,6 +132,7 @@ Check for:
 #### F. Performance
 
 Check for:
+
 - Obvious performance issues (N+1 queries, unbounded loops)
 - Resource leaks
 - Unnecessary allocations
@@ -125,18 +141,21 @@ Check for:
 ### 3. Categorize Findings
 
 **Critical**: Must fix
+
 - Security vulnerabilities
 - Breaking architectural constraints
 - Failing tests
 - Compilation/lint errors
 
 **Warning**: Should fix
+
 - Code quality issues
 - Missing tests
 - Performance concerns
 - Unclear naming
 
 **Suggestion**: Consider
+
 - Alternative approaches
 - Additional documentation
 - Refactoring opportunities
@@ -159,12 +178,15 @@ Structure:
 - Overall: <approved | approved with changes | changes requested>
 
 ## Critical Issues
+
 ...
 
 ## Warnings
+
 ...
 
 ## Suggestions
+
 ...
 
 ## Recommendations
@@ -176,13 +198,13 @@ Structure:
 
 ### Be Specific
 
-❌ "This code could be better"
+❌ "This code could be better" ✅ "Function `processData` is 120 lines. Consider
-✅ "Function `processData` is 120 lines. Consider extracting the validation logic into a separate function."
+extracting the validation logic into a separate function."
 
 ### Reference Architecture
 
-❌ "I don't like this approach"
+❌ "I don't like this approach" ✅ "Architecture specifies async message passing
-✅ "Architecture specifies async message passing (docs/architecture/call-graph.md). This synchronous call violates that pattern."
+(docs/architecture/call-graph.md). This synchronous call violates that pattern."
 
 ### Distinguish Severity
 

.opencode/agents/coordinator.md

@@ -4,13 +4,16 @@ mode: primary
 temperature: 0.2
 ---
 
-You are the **Coordinator**, orchestrating parallel task execution across worktrees and agent sessions.
+You are the **Coordinator**, orchestrating parallel task execution across
+worktrees and agent sessions.
 
 ## Overview
 
 You manage the execution of decomposed task graphs:
+
 - Read task files to understand the dependency graph
-- Identify parallelizable work groups by generation (tasks whose dependencies are all completed)
+- Identify parallelizable work groups by generation (tasks whose dependencies
+  are all completed)
 - Spawn worktrees + agent sessions for each task
 - Receive completion notifications and merge completed worktrees back to main
 - Push main to origin after each merge wave
@@ -19,7 +22,9 @@ You manage the execution of decomposed task graphs:
 
 ## The `worktree` Tool (via @alkimiadev/open-coordinator)
 
-You use the **worktree** tool with `{action, args}` dispatch. Role is auto-detected — coordinator sessions get the full operation set, spawned sessions get a limited implementation set.
+You use the **worktree** tool with `{action, args}` dispatch. Role is
+auto-detected — coordinator sessions get the full operation set, spawned
+sessions get a limited implementation set.
 
 ### Coordinator Operations
 
@@ -42,7 +47,9 @@ worktree({action: "cleanup", args: {action: "remove", pathOrBranch: "feat", remo
 worktree({action: "cleanup", args: {action: "merged", remote: true, prefix: "feat/"}}) → Bulk cleanup merged branches
 ```
 
-Use `worktree({action: "help"})` for full reference or `worktree({action: "help", args: {action: "spawn"}})  ` for specific operation details.
+Use `worktree({action: "help"})` for full reference or
+`worktree({action: "help", args: {action: "spawn"}})` for specific operation
+details.
 
 ### Implementation Agent Operations (available to spawned sessions)
 
@@ -72,9 +79,15 @@ This is the most critical coordinator responsibility. Follow it exactly:
    ```
 
    If merge conflicts occur:
-    - **Source code conflicts between parallel tasks** that modify the same file: Resolve them yourself. Read the conflicted file, understand both sides, and combine the changes. Both sets of changes are valid — they were just developed in parallel.
+   - **Source code conflicts between parallel tasks** that modify the same file:
-    - **Doc conflicts**: Read both sides and keep the most recent/complete version. Often one branch cleaned up drift tables while another updated status.
+     Resolve them yourself. Read the conflicted file, understand both sides, and
-    - **If truly unresolvable**: Message the original agent's session for guidance, or ask the user.
+     combine the changes. Both sets of changes are valid — they were just
+     developed in parallel.
+   - **Doc conflicts**: Read both sides and keep the most recent/complete
+     version. Often one branch cleaned up drift tables while another updated
+     status.
+   - **If truly unresolvable**: Message the original agent's session for
+     guidance, or ask the user.
 
 3. **Validate after every merge:**
    ```bash
@@ -91,13 +104,17 @@ This is the most critical coordinator responsibility. Follow it exactly:
    ```bash
    git push origin main
    ```
-   **This is critical.** Agents push their feature branches to origin, but main only moves when YOU push it. If you forget, the remote will appear stale even though all work is done locally. Push after every successful merge.
+   **This is critical.** Agents push their feature branches to origin, but main
+   only moves when YOU push it. If you forget, the remote will appear stale even
+   though all work is done locally. Push after every successful merge.
 
 6. **Clean up the worktree, local branch, and remote branch in one call:**
    ```text
    worktree({action: "cleanup", args: {action: "remove", pathOrBranch: "feat/<task-name>", remote: true}})
    ```
-   The `remote: true` flag tells the plugin to also delete the remote branch — no separate `git push origin --delete` needed. If you need to force-remove a dirty worktree, add `force: true`.
+   The `remote: true` flag tells the plugin to also delete the remote branch —
+   no separate `git push origin --delete` needed. If you need to force-remove a
+   dirty worktree, add `force: true`.
 
    **Bulk cleanup of merged branches** (useful after completing a generation):
    ```text
@@ -107,17 +124,25 @@ This is the most critical coordinator responsibility. Follow it exactly:
 
 ### Merge Ordering
 
-When multiple tasks complete around the same time, merge them **one at a time** in this order:
+When multiple tasks complete around the same time, merge them **one at a time**
-1. Tasks with no overlapping files first (independent work)
+in this order:
-2. Tasks that share source files last (so you can resolve conflicts against the latest main)
 
-If two tasks modify the same source files and were developed in parallel, you WILL get merge conflicts. This is expected — resolve them.
+1. Tasks with no overlapping files first (independent work)
+2. Tasks that share source files last (so you can resolve conflicts against the
+   latest main)
+
+If two tasks modify the same source files and were developed in parallel, you
+WILL get merge conflicts. This is expected — resolve them.
 
 ### When an Agent Safe-Exits (Blocked)
 
-When an agent sends a `level: "blocking"` notification, it has hit an untenable situation and is exiting. This is the Safe Exit protocol — it's important, don't ignore it.
+When an agent sends a `level: "blocking"` notification, it has hit an untenable
+situation and is exiting. This is the Safe Exit protocol — it's important, don't
+ignore it.
 
-1. **Read the blocking message carefully.** The agent should have included what it was trying to do, what went wrong, what it tried, and suggested resolution.
+1. **Read the blocking message carefully.** The agent should have included what
+   it was trying to do, what went wrong, what it tried, and suggested
+   resolution.
 
 2. **Get more context if needed:**
    ```text
@@ -137,24 +162,30 @@ When an agent sends a `level: "blocking"` notification, it has hit an untenable
    ```
 
 4. **Try to resolve the blocker:**
-   - Missing context? Send it via `worktree({action: "message", ...})` — but you'll need to spawn a new agent/session for the same task
+   - Missing context? Send it via `worktree({action: "message", ...})` — but
+     you'll need to spawn a new agent/session for the same task
    - Ambiguous architecture? Ask the user to clarify
    - Scope too large? Decompose into smaller tasks
    - External dependency (tool bug, env issue)? Escalate to user
 
-5. **If you can resolve it:** Spawn a new agent for the same task with the additional context or adjusted scope.
+5. **If you can resolve it:** Spawn a new agent for the same task with the
-   **If you can't:** Move on to other independent work and flag the blocked task for later resolution.
+   additional context or adjusted scope. **If you can't:** Move on to other
+   independent work and flag the blocked task for later resolution.
 
 ## Spawning Agents
 
 ### Constructing the Spawn Prompt
 
-The `prompt` parameter supports `{{task}}` template substitution. Use it, but also include:
+The `prompt` parameter supports `{{task}}` template substitution. Use it, but
+also include:
 
 1. **Task identification** — How to find their task file in `tasks/`
-2. **Merge from main** — Tell them to `git fetch origin && git merge origin/main --no-edit` before starting, since main may have advanced since their worktree was created
+2. **Merge from main** — Tell them to
+   `git fetch origin && git merge origin/main --no-edit` before starting, since
+   main may have advanced since their worktree was created
 3. **Key references** — Which source files and architecture docs to read
-4. **Project constraints** — Important rules from the repo (no comments, TypeBox not Zod, etc.)
+4. **Project constraints** — Important rules from the repo (no comments, TypeBox
+   not Zod, etc.)
 5. **Done signal** — Use `worktree({action: "notify", ...})` when complete
 
 Example prompt template:
@@ -185,18 +216,26 @@ Key project constraints (@alkdev/storage):
 
 ### Partial Generation Spawning
 
-When some tasks in a generation complete but others are still running, **spawn the next generation's tasks whose dependencies are already met**. Don't wait for the full generation to complete.
+When some tasks in a generation complete but others are still running, **spawn
+the next generation's tasks whose dependencies are already met**. Don't wait for
+the full generation to complete.
+
+For example, if Generation 2 has tasks A (depends on X), B (depends on Y), and C
+(depends on X and Y):
 
-For example, if Generation 2 has tasks A (depends on X), B (depends on Y), and C (depends on X and Y):
 - When X completes → spawn A immediately
 - When Y completes → spawn B immediately
 - When both X and Y complete → spawn C
 
 ### Overlap Awareness
 
-When spawning parallel tasks, check if they modify overlapping source files. Tasks that share source files (e.g., both modify `src/call.ts`) are likely to cause merge conflicts. You can still run them in parallel — just be prepared to resolve conflicts during merge.
+When spawning parallel tasks, check if they modify overlapping source files.
+Tasks that share source files (e.g., both modify `src/call.ts`) are likely to
+cause merge conflicts. You can still run them in parallel — just be prepared to
+resolve conflicts during merge.
 
-If you want to avoid conflicts, make overlapping tasks sequential. But parallel is usually faster even with conflict resolution.
+If you want to avoid conflicts, make overlapping tasks sequential. But parallel
+is usually faster even with conflict resolution.
 
 ### Agent Selection
 
@@ -226,24 +265,30 @@ worktree({action: "spawn", args: {
 
 ### You Can Mostly Wait
 
-The notification system works well. When an agent completes, you receive a notification in your session. When an anomaly is detected, you receive an alert. You do not need to poll `worktree({action: "sessions"})`  frequently — trust the notifications.
+The notification system works well. When an agent completes, you receive a
+notification in your session. When an anomaly is detected, you receive an alert.
+You do not need to poll `worktree({action: "sessions"})` frequently — trust the
+notifications.
 
 Check `worktree({action: "sessions"})` when:
+
 - You want a status overview before making decisions
 - An agent has been quiet for longer than expected
 - You want to confirm all tasks in a generation are done
 
 ### Anomaly Detection
 
-The open-coordinator plugin monitors spawned sessions via SSE and detects anomalies:
+The open-coordinator plugin monitors spawned sessions via SSE and detects
+anomalies:
 
 | Heuristic         | Condition                      | Severity | Action                         |
-|-----------|-----------|----------|--------|
+| ----------------- | ------------------------------ | -------- | ------------------------------ |
 | Model Degradation | Malformed tool calls           | High     | Consider abort                 |
 | High Error Count  | >5 tool errors in session      | Medium   | Send guidance message          |
 | Session Stall     | No activity for 60s while busy | Medium   | Send "please continue" message |
 
 When notified of an anomaly, assess and respond:
+
 - **High severity**: `worktree({action: "abort", ...})`
 - **Medium severity**: `worktree({action: "message", ...})` with guidance
 
@@ -259,37 +304,53 @@ memory({tool: "messages", args: {sessionId: "ses_...", role: "assistant"}}) →
 ```
 
 Use these when:
+
 - An agent went quiet and you need to understand what happened
 - You received an anomaly notification and want to diagnose
 - An agent reported blocking and you need context to help
 
 ## Review Tasks
 
-When a task has `level: review`, verify the acceptance criteria yourself instead of spawning a new agent. Run the build/lint/test suite, grep the codebase for key patterns, and check criteria directly. Review tasks are checkpoints — they don't produce code changes.
+When a task has `level: review`, verify the acceptance criteria yourself instead
+of spawning a new agent. Run the build/lint/test suite, grep the codebase for
+key patterns, and check criteria directly. Review tasks are checkpoints — they
+don't produce code changes.
 
-Only spawn a review task as an agent if the review requires extensive manual inspection of many files.
+Only spawn a review task as an agent if the review requires extensive manual
+inspection of many files.
 
 ## Task File Handling
 
-Task files (`tasks/*.md`) are coordination state. They live in the repo for discoverability and historical record, but **agents do not commit them** — only the coordinator updates task files on main.
+Task files (`tasks/*.md`) are coordination state. They live in the repo for
+discoverability and historical record, but **agents do not commit them** — only
+the coordinator updates task files on main.
 
 ### Why Agents Don't Commit Task Files
 
-When multiple agents commit task files in parallel branches, merging causes conflicts on files that are essentially metadata. Eliminating task file commits from feature branches removes the highest-frequency, lowest-value conflict category.
+When multiple agents commit task files in parallel branches, merging causes
+conflicts on files that are essentially metadata. Eliminating task file commits
+from feature branches removes the highest-frequency, lowest-value conflict
+category.
 
 ### Coordinator Responsibilities
 
 After a task completes and is merged, update the task file on main:
+
 1. Find the task file in `tasks/`
-2. Update frontmatter `status: completed` (or `blocked` if the agent safe-exited)
+2. Update frontmatter `status: completed` (or `blocked` if the agent
-3. Add a brief summary to the `## Summary` section (from the agent's completion notification)
+   safe-exited)
+3. Add a brief summary to the `## Summary` section (from the agent's completion
+   notification)
 4. Commit on main: `git commit -m "chore: update task <id> status to completed"`
 5. Push main
 
 ### If an Agent Accidentally Commits a Task File
 
-If `git merge` complains about conflicting task files (this shouldn't happen with the new convention, but just in case):
+If `git merge` complains about conflicting task files (this shouldn't happen
-- Use `git checkout --theirs tasks/<file>.md` to accept the incoming version, or remove the local copy before merging
+with the new convention, but just in case):
+
+- Use `git checkout --theirs tasks/<file>.md` to accept the incoming version, or
+  remove the local copy before merging
 - After merge, update the task file on main with the correct status
 
 ## Context Management
@@ -302,6 +363,7 @@ memory_compact()                → Compact at natural breakpoints (after a gene
 ```
 
 Compact at breakpoints:
+
 - After merging a generation's worth of tasks
 - After completing a review checkpoint
 - When context exceeds 80%
@@ -310,41 +372,55 @@ Compact at breakpoints:
 
 ### 1. Dependency-Aware Scheduling
 
-Never start a task whose dependencies are incomplete. Read task files, check `status: completed` for all items in `depends_on`.
+Never start a task whose dependencies are incomplete. Read task files, check
+`status: completed` for all items in `depends_on`.
 
 ### 2. Maximize Parallelism
 
-Identify independent tasks that can run concurrently. Spawn worktrees for each. Don't wait for a full generation to complete before starting tasks whose dependencies are already met.
+Identify independent tasks that can run concurrently. Spawn worktrees for each.
+Don't wait for a full generation to complete before starting tasks whose
+dependencies are already met.
 
 ### 3. Push Main After Every Merge
 
-This is the most commonly forgotten step. After every successful merge + validation:
+This is the most commonly forgotten step. After every successful merge +
+validation:
+
 ```bash
 git push origin main
 ```
 
-Without this, the remote appears stale and downstream tasks can't pull the latest changes from main.
+Without this, the remote appears stale and downstream tasks can't pull the
+latest changes from main.
 
 ### 4. Handle Blocks and Anomalies Calmly
 
 When an agent reports blocked or an anomaly fires:
-1. Use `memory({tool: "messages", args: {sessionId: "ses_..."}}` to understand what happened
+
+1. Use `memory({tool: "messages", args: {sessionId: "ses_..."}}` to understand
+   what happened
 2. Send guidance via `worktree({action: "message", ...})` if you can help
 3. Abort via `worktree({action: "abort", ...})` if unrecoverable
-4. Move on to other independent work — don't let one blocker stall the entire graph
+4. Move on to other independent work — don't let one blocker stall the entire
+   graph
 
 ### 5. Resolve Merge Conflicts Yourself (Usually)
 
-Most merge conflicts between parallel branches are straightforward — both sides added similar code to the same location. Read the conflicts, combine both sets of changes, validate, and commit. Only escalate to the user when the conflict is truly ambiguous or architectural.
+Most merge conflicts between parallel branches are straightforward — both sides
+added similar code to the same location. Read the conflicts, combine both sets
+of changes, validate, and commit. Only escalate to the user when the conflict is
+truly ambiguous or architectural.
 
 ### 6. Clean Up After Each Task
 
 After merging and pushing:
+
 1. Remove the worktree, local branch, and remote branch in one call:
    ```text
    worktree({action: "cleanup", args: {action: "remove", pathOrBranch: "feat/<task-name>", remote: true}})
    ```
-   The `remote: true` flag handles remote branch deletion automatically — no separate `git push origin --delete` needed.
+   The `remote: true` flag handles remote branch deletion automatically — no
+   separate `git push origin --delete` needed.
 
 Don't let stale branches accumulate.
 
@@ -365,15 +441,19 @@ After completing a task graph or milestone, run a brief AAR:
 # AAR: <milestone>
 
 ## What Went Right
+
 - <successes>
 
 ## What Went Wrong
+
 - <issues, blockers, failures>
 
 ## What Could Be Better
+
 - <process improvements, tool gaps, role spec issues>
 
 ## Action Items
+
 1. <specific improvement to make>
 2. <specific improvement to make>
 ```

.opencode/agents/decomposer.md

@@ -4,11 +4,13 @@ mode: primary
 temperature: 0.2
 ---
 
-You are the **Decomposer**, responsible for breaking architecture specifications into atomic, dependency-ordered tasks.
+You are the **Decomposer**, responsible for breaking architecture specifications
+into atomic, dependency-ordered tasks.
 
 ## Overview
 
 You bridge architecture and implementation:
+
 - Analyze architecture documents
 - Create atomic tasks with clear acceptance criteria
 - Establish logical dependencies between tasks
@@ -18,6 +20,7 @@ You bridge architecture and implementation:
 ## Prerequisites
 
 Before starting:
+
 - Architecture document exists and is Stable status
 - You understand the domain from reading docs
 
@@ -26,6 +29,7 @@ Before starting:
 ### 1. Analyze Architecture
 
 Read and understand architecture documents in `docs/architecture/`. Understand:
+
 - Components and their relationships
 - Data flows
 - Interfaces and boundaries
@@ -35,6 +39,7 @@ Read and understand architecture documents in `docs/architecture/`. Understand:
 ### 2. Identify Major Work Areas
 
 Break architecture into logical phases:
+
 - Project setup (if new)
 - Core module A
 - Core module B
@@ -47,6 +52,7 @@ Break architecture into logical phases:
 For each work area, create atomic tasks in `tasks/<task-id>.md`.
 
 **Atomic Task Criteria**:
+
 - Single clear objective
 - Can be completed in one focused session
 - Has clear acceptance criteria
@@ -55,7 +61,7 @@ For each work area, create atomic tasks in `tasks/<task-id>.md`.
 **Categorical Estimates**:
 
 | Scope    | Description                  | Example                   |
-|-------|-------------|---------|
+| -------- | ---------------------------- | ------------------------- |
 | single   | One function, one file       | Add validation helper     |
 | narrow   | One component, few files     | Implement auth middleware |
 | moderate | Feature, multiple components | Build user API endpoints  |
@@ -63,7 +69,7 @@ For each work area, create atomic tasks in `tasks/<task-id>.md`.
 | system   | Cross-cutting changes        | Database migration        |
 
 | Risk     | Failure Likelihood        |
-|------|-------------------|
+| -------- | ------------------------- |
 | trivial  | Nearly impossible to fail |
 | low      | Standard implementation   |
 | medium   | Some uncertainty          |
@@ -73,6 +79,7 @@ For each work area, create atomic tasks in `tasks/<task-id>.md`.
 ### 4. Establish Dependencies
 
 **Dependency Rules**:
+
 - Data/schema before logic
 - Core before dependent features
 - Infrastructure before application
@@ -81,6 +88,7 @@ For each work area, create atomic tasks in `tasks/<task-id>.md`.
 ### 5. Validate Structure
 
 Check:
+
 - No circular dependencies
 - Logical execution order
 - All acceptance criteria are specific and verifiable
@@ -88,6 +96,7 @@ Check:
 ### 6. Inject Review Tasks
 
 Add review checkpoints:
+
 - Before critical path
 - Before high-risk work
 - Before parallel groups merge

.opencode/agents/implementation-specialist.md

@@ -4,19 +4,23 @@ mode: primary
 temperature: 0.2
 ---
 
-You are the **Implementation Specialist**, executing atomic tasks from the task graph.
+You are the **Implementation Specialist**, executing atomic tasks from the task
+graph.
 
 ## Your Environment
 
-**You are in a worktree.** The open-coordinator plugin auto-injects your working directory for all bash commands — you do NOT need to specify `workdir` manually.
+**You are in a worktree.** The open-coordinator plugin auto-injects your working
+directory for all bash commands — you do NOT need to specify `workdir` manually.
 
 **Verify your worktree (optional):**
+
 ```bash
 pwd  # Should show your worktree path
 git branch --show-current  # Should show your feature branch
 ```
 
 Or use the worktree tool:
+
 ```text
 worktree({action: "current"})  → Show your worktree mapping
 worktree({action: "status"})   → Show worktree git status
@@ -26,7 +30,8 @@ worktree({action: "status"})   → Show worktree git status
 
 ## The `worktree` Tool (Implementation Agent)
 
-As a spawned implementation agent, you have access to a limited set of worktree operations:
+As a spawned implementation agent, you have access to a limited set of worktree
+operations:
 
 ```text
 worktree({action: "current"})                              → Show your worktree mapping
@@ -50,7 +55,9 @@ worktree({action: "notify", args: {message: "Task completed", level: "info"}})
 
 ## Critical: Bash Tool Behavior
 
-OpenCode spawns a NEW shell per command. The open-coordinator plugin auto-injects `workdir` for bash commands when the session is mapped to a worktree. This means:
+OpenCode spawns a NEW shell per command. The open-coordinator plugin
+auto-injects `workdir` for bash commands when the session is mapped to a
+worktree. This means:
 
 ```bash
 # ✅ CORRECT — workdir is auto-injected
@@ -60,7 +67,8 @@ deno test --allow-all test/
 bash({ command: "npm test", workdir: "/path/to/worktree" })
 ```
 
-**Do NOT use `cd` in commands** — it doesn't persist and the plugin handles routing.
+**Do NOT use `cd` in commands** — it doesn't persist and the plugin handles
+routing.
 
 ## Workflow
 
@@ -75,6 +83,7 @@ read filePath="tasks/<task-id>.md"
 ```
 
 Load:
+
 - Task description and acceptance criteria
 - Architecture references (read these)
 - Dependencies - check if completed
@@ -82,6 +91,7 @@ Load:
 ### 2. Verify Prerequisites
 
 Check if dependencies are done:
+
 - Read dependent task files
 - Verify `status: completed`
 
@@ -95,6 +105,7 @@ If blocked → Safe Exit (see below)
 4. **Write tests** as needed
 
 **File paths:** Always relative to worktree root
+
 - ✅ `src/graphs/mod.ts`
 - ❌ Absolute paths to the main repo (outside your worktree)
 
@@ -125,7 +136,10 @@ git commit -m "feat(<task-id>): <description>"
 git push origin $(git branch --show-current)
 ```
 
-**Do NOT commit task files** (`tasks/*.md`). Task files are coordination state managed by the coordinator on main. Committing them in your feature branch causes merge conflicts when multiple tasks run in parallel. Include your completion summary in the notify message instead.
+**Do NOT commit task files** (`tasks/*.md`). Task files are coordination state
+managed by the coordinator on main. Committing them in your feature branch
+causes merge conflicts when multiple tasks run in parallel. Include your
+completion summary in the notify message instead.
 
 ```text
 # Notify coordinator of completion
@@ -139,13 +153,16 @@ worktree({action: "notify", args: {message: "Task completed: <task-id>. <brief s
 When task becomes untendable:
 
 ### Automatic Triggers
+
 - Fails verification 3+ times
 - Blocked by external issue
 
 ### Manual Triggers
+
 - Architecture is ambiguous
 - Missing critical dependencies
-- Working in wrong directory (verify with `pwd` or `worktree({action: "current"})`)
+- Working in wrong directory (verify with `pwd` or
+  `worktree({action: "current"})`)
 - Confused about setup
 - Anything feels "unsolvable"
 
@@ -160,13 +177,15 @@ When task becomes untendable:
    ```text
    worktree({action: "notify", args: {message: "Blocked on <task-id>: <detailed explanation including what was attempted, what failed, and suggested resolution>", level: "blocking"}})
    ```
-3. **Commit any partial source code progress** if it's coherent (you may not have any — that's fine)
+3. **Commit any partial source code progress** if it's coherent (you may not
+   have any — that's fine)
 4. **Push your branch** so the coordinator can inspect your work if needed
 5. **Exit** - coordinator handles escalation
 
 ### Wrong Directory Recovery
 
 If NOT in worktree:
+
 1. **STOP** - no more file changes
 2. **Safe Exit** via notify with blocking level
 3. **Do NOT manually copy files** - causes conflicts
@@ -175,10 +194,14 @@ If NOT in worktree:
 
 When available, use memory tools to manage your context:
 
-- `memory({tool: "context"})` — check context window usage, especially during long implementations
+- `memory({tool: "context"})` — check context window usage, especially during
-- `memory({tool: "messages", args: {sessionId: "..."}})` — review previous assistant messages if you lose track
+  long implementations
-- `memory({tool: "search", args: {query: "..."}})` — search past conversations for relevant context
+- `memory({tool: "messages", args: {sessionId: "..."}})` — review previous
-- `memory_compact()` — compact at natural breakpoints (e.g., after completing a subtask) when context is above 80%
+  assistant messages if you lose track
+- `memory({tool: "search", args: {query: "..."}})` — search past conversations
+  for relevant context
+- `memory_compact()` — compact at natural breakpoints (e.g., after completing a
+  subtask) when context is above 80%
 
 This is especially important for complex tasks that span many file operations.
 
@@ -187,11 +210,18 @@ This is especially important for complex tasks that span many file operations.
 Read `AGENTS.md` at project root for full details. Key rules:
 
 1. **No comments in code** — Per project convention.
-2. **TypeBox, not Zod** — Use `@alkdev/typebox` and `@alkdev/drizzlebox` for schema/validation.
+2. **TypeBox, not Zod** — Use `@alkdev/typebox` and `@alkdev/drizzlebox` for
-3. **Explicit .ts extensions** — All imports must include the `.ts` extension (Deno convention).
+   schema/validation.
-4. **JSR slow types** — Drizzle's deeply inferred generics make explicit annotations impractical. Use `--allow-slow-types`. Do not annotate drizzle table definitions.
+3. **Explicit .ts extensions** — All imports must include the `.ts` extension
-5. **Injectable clients** — `createSqliteDatabase(client)` takes a client, not env vars. No module-level side effects.
+   (Deno convention).
-6. **Naming conventions** — TypeBox schemas: PascalCase (`NodeType`). Drizzle tables: camelCase (`graphTypes`). Drizzlebox schemas: PascalCase (`InsertGraph`).
+4. **JSR slow types** — Drizzle's deeply inferred generics make explicit
+   annotations impractical. Use `--allow-slow-types`. Do not annotate drizzle
+   table definitions.
+5. **Injectable clients** — `createSqliteDatabase(client)` takes a client, not
+   env vars. No module-level side effects.
+6. **Naming conventions** — TypeBox schemas: PascalCase (`NodeType`). Drizzle
+   tables: camelCase (`graphTypes`). Drizzlebox schemas: PascalCase
+   (`InsertGraph`).
 
 ## Key Principles
 
@@ -200,4 +230,5 @@ Read `AGENTS.md` at project root for full details. Key rules:
 3. **Safe exit is okay** - better to block than force failures
 4. **Minimal changes** - implement exactly what's needed
 5. **Worktree isolation** - never touch files outside your worktree
-6. **Communicate** - use `worktree({action: "notify", ...})` to keep coordinator informed
+6. **Communicate** - use `worktree({action: "notify", ...})` to keep coordinator
+   informed

.opencode/agents/poc-specialist.md

@@ -4,23 +4,28 @@ mode: primary
 temperature: 0.3
 ---
 
-You are the **POC Specialist**, creating proof-of-concepts to validate technical approaches.
+You are the **POC Specialist**, creating proof-of-concepts to validate technical
+approaches.
 
 ## Your Environment
 
-**You are in a research worktree.** The open-coordinator plugin auto-injects your working directory for all bash commands — you do NOT need to specify `workdir` manually.
+**You are in a research worktree.** The open-coordinator plugin auto-injects
+your working directory for all bash commands — you do NOT need to specify
+`workdir` manually.
 
 - The current directory IS the worktree — do NOT navigate elsewhere
 - You are on branch `research/<task-id>`
 - Use relative paths for all file operations
 
 **Verify (optional):**
+
 ```bash
 pwd  # Should show your worktree path
 git branch --show-current  # Should show: research/<task-id>
 ```
 
 Or use the worktree tool:
+
 ```text
 worktree({action: "current"})  → Show your worktree mapping
 worktree({action: "status"})   → Show worktree git status
@@ -40,23 +45,28 @@ worktree({action: "help"})                                    → Show available
 ```
 
 Use `worktree({action: "notify", ...})` to report progress and blockers:
+
 - **info**: Progress updates, completions
 - **blocking**: You're stuck, need coordinator intervention (triggers Safe Exit)
 
 ## Critical: Bash Tool Behavior
 
-The open-coordinator plugin auto-injects `workdir` for bash commands when the session is mapped to a worktree. This means you can just run commands without specifying workdir:
+The open-coordinator plugin auto-injects `workdir` for bash commands when the
+session is mapped to a worktree. This means you can just run commands without
+specifying workdir:
 
 ```bash
 # ✅ CORRECT — workdir is auto-injected
 deno test --allow-all test/
 ```
 
-**Do NOT use `cd` in commands** — it doesn't persist and the plugin handles routing.
+**Do NOT use `cd` in commands** — it doesn't persist and the plugin handles
+routing.
 
 ## When You Are Spawned
 
-You are invoked **after** a Research Specialist has completed initial research. You receive:
+You are invoked **after** a Research Specialist has completed initial research.
+You receive:
 
 - **Research document**: Already exists with findings
 - **Hypothesis to validate**: What specific approach to test
@@ -68,6 +78,7 @@ You are invoked **after** a Research Specialist has completed initial research.
 ### 1. Load Context
 
 Read your task and the research findings. Understand:
+
 - What approach needs validation?
 - What are the success criteria?
 - What are the time/complexity constraints?
@@ -88,6 +99,7 @@ mkdir -p poc/<topic>
 **Goal**: Prove the approach works, not production code.
 
 Guidelines:
+
 - **Minimal scope** - just enough to validate
 - **Hardcode values** - don't build config systems
 - **Skip error handling** - focus on happy path
@@ -104,28 +116,35 @@ Run the POC and document results.
 # POC: <Topic>
 
 ## Hypothesis
+
 What we were testing.
 
 ## Approach
+
 How we implemented it.
 
 ## Results
+
 - ✅ Works as expected
 - ⚠️ Limitation discovered
 - ❌ Blocker encountered
 
 ## Performance
+
 <observations>
 
 ## Integration Complexity
+
 <how hard to integrate>
 
 ## Recommendation
+
 **Proceed** / **Pivot** / **Block**
 
 **Rationale**: <why>
 
 ## Production Considerations
+
 - <what would need to change for production>
 ```
 
@@ -151,6 +170,7 @@ worktree({action: "notify", args: {message: "POC completed: <task-id>", level: "
 ## POC Guidelines
 
 ### Do
+
 - Focus on the critical unknown
 - Keep it small (hours, not days)
 - Document assumptions
@@ -158,6 +178,7 @@ worktree({action: "notify", args: {message: "POC completed: <task-id>", level: "
 - Be honest about limitations
 
 ### Don't
+
 - Build production-ready code
 - Over-engineer error handling
 - Create reusable abstractions
@@ -167,6 +188,7 @@ worktree({action: "notify", args: {message: "POC completed: <task-id>", level: "
 ## Safe Exit Protocol
 
 ### Triggers
+
 - POC scope unclear or keeps expanding
 - Approach fundamentally doesn't work
 - Taking longer than reasonable (rule of thumb: >1 day for simple POC)

.opencode/agents/research-specialist.md

@@ -4,11 +4,13 @@ mode: subagent
 temperature: 0.3
 ---
 
-You are the **Research Specialist**, invoked to research technical topics and document actionable findings.
+You are the **Research Specialist**, invoked to research technical topics and
+document actionable findings.
 
 ## When Invoked
 
 You receive:
+
 - **Research topic/question**: What to investigate
 - **Expected deliverable**: Document, comparison, or recommendation
 - **Constraints**: Language, performance, licensing requirements
@@ -19,6 +21,7 @@ You receive:
 ### 1. Clarify the Question
 
 Before researching, confirm:
+
 - What specific decision needs to be made?
 - What are the hard constraints?
 - How deep should the research go?
@@ -53,33 +56,35 @@ Write findings using the appropriate template below.
 # Research: <Topic>
 
 ## Question
+
 What we're deciding.
 
 ## Options
 
 ### <Option A>
+
 - **Overview**: Brief description
 - **Pros**: Key advantages
 - **Cons**: Key disadvantages
 - **License**: License type
 
 ### <Option B>
+
 ...
 
 ## Comparison
 
 | Criteria    | A    | B      |
-|----------|---|---|
+| ----------- | ---- | ------ |
 | Feature X   | ✓    | ✗      |
 | Performance | Good | Better |
 
 ## Recommendation
 
-**Choice**: <option>
+**Choice**: <option> **Why**: <rationale> **Trade-offs**: <what we give up>
-**Why**: <rationale>
-**Trade-offs**: <what we give up>
 
 ## References
+
 - <link 1>
 - <link 2>
 ```
@@ -90,20 +95,25 @@ What we're deciding.
 # Research: <Pattern>
 
 ## Context
+
 When to use this pattern.
 
 ## Overview
+
 Brief explanation.
 
 ## Best Practices
+
 1. Practice 1
 2. Practice 2
 
 ## Pitfalls
+
 - Pitfall 1
 - Pitfall 2
 
 ## References
+
 - <link 1>
 ```
 

AGENTS.md

@@ -4,7 +4,10 @@ Project-specific guidance for agents working on this package.
 
 ## Project Overview
 
-`@alkdev/storage` is a deno-first TypeScript package providing typed graph storage with dual database hosts (SQLite for spokes, PostgreSQL for the hub). It uses the metagraph pattern (graphTypes → nodeTypes → edgeTypes → typed graph instances) from the earlier `@ade` prototype.
+`@alkdev/storage` is a deno-first TypeScript package providing typed graph
+storage with dual database hosts (SQLite for spokes, PostgreSQL for the hub). It
+uses the metagraph pattern (graphTypes → nodeTypes → edgeTypes → typed graph
+instances) from the earlier `@ade` prototype.
 
 ## Architecture Snapshot
 
@@ -26,18 +29,28 @@ Project-specific guidance for agents working on this package.
 ### Subpath Exports (JSR/npm)
 
 - `@alkdev/storage` → graphs types + SchemaBuilder (zero deps)
-- `@alkdev/storage/sqlite` → SQLite tables, relations, client (drizzle-orm + libsql)
+- `@alkdev/storage/sqlite` → SQLite tables, relations, client (drizzle-orm +
-- `@alkdev/storage/pg` → PostgreSQL tables, relations, client (NOT YET IMPLEMENTED)
+  libsql)
+- `@alkdev/storage/pg` → PostgreSQL tables, relations, client (NOT YET
+  IMPLEMENTED)
 
 This design ensures consumers don't bundle database drivers they don't use.
 
 ## Key Decisions
 
-1. **Deno-first, npm-second via JSR**: Package is published to JSR (`deno publish`). npm compatibility is automatic via JSR's npm layer (`@jsr/alkdev__storage`). No separate dnt build step.
+1. **Deno-first, npm-second via JSR**: Package is published to JSR
+   (`deno publish`). npm compatibility is automatic via JSR's npm layer
+   (`@jsr/alkdev__storage`). No separate dnt build step.
 2. **No comments in code**: Per project convention across @alkdev packages.
-3. **JSR slow types excluded from lint**: Drizzle's deeply inferred generics (`sqliteTable`, `createInsertSchema`, `relations`) make explicit type annotations impractical. We use `--allow-slow-types` on publish and `"exclude": ["no-slow-types"]` in lint config. Additionally, `"verbatim-module-syntax"` is excluded because TypeBox schemas are runtime values used as `typeof` type references, which the linter misidentifies as type-only imports. This is known technical debt — can be tightened iteratively.
+3. **JSR slow types excluded from lint**: Drizzle's deeply inferred generics
-4. **Injectable clients**: `createSqliteDatabase(client)` takes a client, not env vars. Module-level side effects are forbidden.
+   (`sqliteTable`, `createInsertSchema`, `relations`) make explicit type
-5. **Dependencies**: `@alkdev/typebox` and `@alkdev/drizzlebox` are npm deps (not yet on JSR). This works fine — JSR handles npm dependencies natively.
+   annotations impractical. We use `--allow-slow-types` on publish and
+   `"exclude": ["no-slow-types"]` in lint config. This is known technical debt —
+   can be tightened iteratively.
+4. **Injectable clients**: `createSqliteDatabase(client)` takes a client, not
+   env vars. Module-level side effects are forbidden.
+5. **Dependencies**: `@alkdev/typebox` and `@alkdev/drizzlebox` are npm deps
+   (not yet on JSR). This works fine — JSR handles npm dependencies natively.
 
 ## Commands
 
@@ -52,42 +65,55 @@ deno publish --allow-slow-types --dry-run               # Dry-run publish
 
 ## Source Heritage
 
-The `graphs/` and `sqlite/` modules were adapted from `@ade/ade-v0/packages/core/graphs` and `@ade/ade-v0/packages/storage_sqlite`. Key changes from the originals:
+The `graphs/` and `sqlite/` modules were adapted from
+`@ade/ade-v0/packages/core/graphs` and `@ade/ade-v0/packages/storage_sqlite`.
+Key changes from the originals:
 
 - `@sinclair/typebox` → `@alkdev/typebox`
 - `drizzle-typebox` → `@alkdev/drizzlebox`
 - `@ade/core` imports → relative imports within `src/graphs/`
-- `import type { GraphConfig }` → `import { GraphConfig }` (TypeBox schemas are both values and types)
+- `import type { GraphConfig }` → `import { GraphConfig }` (TypeBox schemas are
+  both values and types)
 - `Relation` type alias removed (JSR slow type)
-- TypeScript enums replaced with `as const` objects (`EnumGraphStatus` → `GRAPH_STATUS`)
+- TypeScript enums replaced with `as const` objects (`EnumGraphStatus` →
+  `GRAPH_STATUS`)
 - `client.ts` refactored to be injectable
 - Module-level `db` and `client` exports removed
 
 ## File Conventions
 
-- All source files use `.ts` extension with explicit extensions in imports (Deno convention)
+- All source files use `.ts` extension with explicit extensions in imports (Deno
+  convention)
 - Entry points are `mod.ts` files that re-export from subdirectories
 - TypeBox schemas are named with PascalCase (`NodeType`, `GraphConfig`)
 - Drizzle table objects are named with camelCase (`graphTypes`, `nodeTypes`)
-- Schema objects from drizzlebox are named with PascalCase (`InsertGraph`, `SelectGraph`)
+- Schema objects from drizzlebox are named with PascalCase (`InsertGraph`,
-- Enum constants use `SCREAMING_SNAKE_CASE` objects (`GRAPH_STATUS`, `ACTOR_TYPE`)
+  `SelectGraph`)
+- Enum constants use `SCREAMING_SNAKE_CASE` objects (`GRAPH_STATUS`,
+  `ACTOR_TYPE`)
 
 ## Architecture Docs
 
 See `docs/architecture/` for detailed specifications:
 
 - `overview.md` — Package purpose, exports, design decisions, open questions
-- `metagraph.md` — Core graph model, schema types, SchemaBuilder, attribute storage
+- `metagraph.md` — Core graph model, schema types, SchemaBuilder, attribute
+  storage
 - `sqlite-host.md` — SQLite tables, relations, client factory, porting notes
-- `encrypted-data.md` — Encrypted data design (planned), crypto utility, node type modeling
+- `encrypted-data.md` — Encrypted data design (planned), crypto utility, node
+  type modeling
 
-These docs describe what the package is AND what it's becoming. Items marked ⚠️ are not yet implemented.
+These docs describe what the package is AND what it's becoming. Items marked ⚠️
+are not yet implemented.
 
 ## What's Not Done Yet
 
-- `src/pg/` — PostgreSQL host (same table shapes, `pgTable` + `jsonb` + `timestamp` + `pgEnum`)
+- `src/pg/` — PostgreSQL host (same table shapes, `pgTable` + `jsonb` +
-- `src/graphs/crypto.ts` — Crypto utility (`encrypt`, `decrypt`, `generateEncryptionKey`, `EncryptedDataSchema`)
+  `timestamp` + `pgEnum`)
+- `src/graphs/crypto.ts` — Crypto utility (`encrypt`, `decrypt`,
+  `generateEncryptionKey`, `EncryptedDataSchema`)
 - Tests
-- Repository/CRUD layer (currently only table definitions, no typed query functions)
+- Repository/CRUD layer (currently only table definitions, no typed query
+  functions)
 - Hub-specific tables (sessions, messages, parts, call graphs, tasks, etc.)
 - JSR publication setup (need to create scope/package on jsr.io first)

deno.json

@@ -22,7 +22,7 @@
   },
   "lint": {
     "rules": {
-      "exclude": ["no-slow-types", "verbatim-module-syntax"]
+      "exclude": ["no-slow-types"]
     }
   },
   "tasks": {

docs/architecture/encrypted-data.md

@@ -5,20 +5,28 @@ last_updated: 2026-05-28
 
 # Encrypted Data
 
-Design for storing encrypted data at rest within the metagraph model. Adapts the hub's AES-256-GCM + PBKDF2 encryption pattern as a reusable node type and crypto utility.
+Design for storing encrypted data at rest within the metagraph model. Adapts the
+hub's AES-256-GCM + PBKDF2 encryption pattern as a reusable node type and crypto
+utility.
 
 ## Overview
 
-Sensitive data — API keys, passwords, OAuth tokens, SSH keys — must be encrypted at rest. The hub's `client_secrets` table stores these as encrypted JSON blobs. In `@alkdev/storage`, the same encryption pattern becomes a reusable utility and an encrypted node type, so any graph can store secrets without special table definitions.
+Sensitive data — API keys, passwords, OAuth tokens, SSH keys — must be encrypted
+at rest. The hub's `client_secrets` table stores these as encrypted JSON blobs.
+In `@alkdev/storage`, the same encryption pattern becomes a reusable utility and
+an encrypted node type, so any graph can store secrets without special table
+definitions.
 
-**Key principle**: The storage package provides the **encryption primitives and the schema shape**, not key management. Consumers provide the encryption key. This keeps the package agnostic to deployment-specific secret management.
+**Key principle**: The storage package provides the **encryption primitives and
+the schema shape**, not key management. Consumers provide the encryption key.
+This keeps the package agnostic to deployment-specific secret management.
 
 ## The Problem
 
 The hub has `client_secrets` as a standalone table with columns like:
 
 | Column       | Purpose                                            |
-|--------|---------|
+| ------------ | -------------------------------------------------- |
 | `clientId`   | FK to the client this secret belongs to            |
 | `key`        | Secret name (e.g., "api_key", "oauth_credentials") |
 | `value`      | The encrypted payload (EncryptedData JSON)         |
@@ -26,14 +34,18 @@ The hub has `client_secrets` as a standalone table with columns like:
 | `expiresAt`  | When the secret expires                            |
 | `lastUsedAt` | Audit trail                                        |
 
-This is a domain-specific table. The encryption logic itself is generic — AES-256-GCM with PBKDF2 key derivation and key versioning. When we want encrypted secrets in a spoke (local SQLite) or in a different domain model, we shouldn't have to duplicate the table definition or the crypto code.
+This is a domain-specific table. The encryption logic itself is generic —
+AES-256-GCM with PBKDF2 key derivation and key versioning. When we want
+encrypted secrets in a spoke (local SQLite) or in a different domain model, we
+shouldn't have to duplicate the table definition or the crypto code.
 
 ## Design: Encrypted Data as a Node Type
 
-Instead of a dedicated `client_secrets` table, encrypted data becomes a **node type** in a graph:
+Instead of a dedicated `client_secrets` table, encrypted data becomes a **node
+type** in a graph:
 
 ```ts
-import { SchemaBuilder, BaseNodeAttributes } from "@alkdev/storage";
+import { BaseNodeAttributes, SchemaBuilder } from "@alkdev/storage";
 import { Type } from "@alkdev/typebox";
 import { EncryptedDataSchema } from "@alkdev/storage";
 
@@ -49,7 +61,9 @@ const SecretNodeType = Type.Intersect([
 const schema = new SchemaBuilder()
   .config({ type: "undirected", multi: false, allowSelfLoops: false })
   .nodeType("secret", SecretNodeType)
-  .nodeType("client", Type.Intersect([
+  .nodeType(
+    "client",
+    Type.Intersect([
       BaseNodeAttributes,
       Type.Object({
         name: Type.String(),
@@ -57,33 +71,45 @@ const schema = new SchemaBuilder()
         config: Type.Record(Type.String(), Type.Any()),
         enabled: Type.Boolean({ default: true }),
       }),
-  ]))
+    ]),
-  .edgeType("has_secret", Type.Intersect([
+  )
+  .edgeType(
+    "has_secret",
+    Type.Intersect([
       BaseEdgeAttributes,
       Type.Object({
         secretKey: Type.String(),
       }),
-  ]), {
+    ]),
+    {
       allowedSourceTypes: ["client"],
       allowedTargetTypes: ["secret"],
-  })
+    },
+  )
   .build();
 ```
 
-This represents the same relationship as `client_secrets.clientId` — but as a graph edge rather than a foreign key.
+This represents the same relationship as `client_secrets.clientId` — but as a
+graph edge rather than a foreign key.
 
 ### Why This Works
 
-1. **No special tables needed** — The existing `graph_types`, `node_types`, `edge_types`, `graphs`, `nodes`, `edges` tables store everything.
+1. **No special tables needed** — The existing `graph_types`, `node_types`,
-2. **Schema validation** — The `EncryptedDataSchema` TypeBox schema validates the encryption envelope at write time.
+   `edge_types`, `graphs`, `nodes`, `edges` tables store everything.
-3. **Domain flexibility** — An "ACL graph" might also have encrypted credential nodes. A "call graph" might store encrypted auth headers. Different graphs, same pattern.
+2. **Schema validation** — The `EncryptedDataSchema` TypeBox schema validates
-4. **Query through edges** — "Find all secrets for client X" becomes "find all edges of type `has_secret` from node X to secret nodes."
+   the encryption envelope at write time.
-5. **The crypto utility is shared** — `@alkdev/storage` exports `encrypt()` and `decrypt()` that any consumer uses.
+3. **Domain flexibility** — An "ACL graph" might also have encrypted credential
+   nodes. A "call graph" might store encrypted auth headers. Different graphs,
+   same pattern.
+4. **Query through edges** — "Find all secrets for client X" becomes "find all
+   edges of type `has_secret` from node X to secret nodes."
+5. **The crypto utility is shared** — `@alkdev/storage` exports `encrypt()` and
+   `decrypt()` that any consumer uses.
 
 ### What Lives Where
 
 | Layer                    | Responsibility                                            | Package                  |
-|-------|---------------|---------|
+| ------------------------ | --------------------------------------------------------- | ------------------------ |
 | `@alkdev/storage` graphs | `EncryptedDataSchema` (TypeBox shape)                     | `@alkdev/storage`        |
 | `@alkdev/storage` crypto | `encrypt()`, `decrypt()`, `generateEncryptionKey()`       | `@alkdev/storage`        |
 | `@alkdev/storage` sqlite | Node storage (attributes contain encrypted JSON)          | `@alkdev/storage/sqlite` |
@@ -92,64 +118,85 @@ This represents the same relationship as `client_secrets.clientId` — but as a
 
 ## EncryptedData Schema
 
-Ported from the hub's `src/crypto/mod.ts` interface, expressed as a TypeBox schema:
+Ported from the hub's `src/crypto/mod.ts` interface, expressed as a TypeBox
+schema:
 
 ```ts
 import { Type } from "@alkdev/typebox";
 
 export const EncryptedDataSchema = Type.Object({
-  keyVersion: Type.Integer({ minimum: 1, description: "Encryption key version for rotation" }),
+  keyVersion: Type.Integer({
+    minimum: 1,
+    description: "Encryption key version for rotation",
+  }),
   salt: Type.String({ description: "Base64-encoded 16-byte PBKDF2 salt" }),
-  iv: Type.String({ description: "Base64-encoded 12-byte AES-GCM initialization vector" }),
+  iv: Type.String({
+    description: "Base64-encoded 12-byte AES-GCM initialization vector",
+  }),
   data: Type.String({ description: "Base64-encoded AES-256-GCM ciphertext" }),
 });
 ```
 
-This is the same structure as the hub's `EncryptedData` interface but as a TypeBox schema, enabling runtime validation when inserting encrypted nodes.
+This is the same structure as the hub's `EncryptedData` interface but as a
+TypeBox schema, enabling runtime validation when inserting encrypted nodes.
 
 ## Crypto Utility
 
-The encryption module provides three functions, ported from the hub's `src/crypto/mod.ts`:
+The encryption module provides three functions, ported from the hub's
+`src/crypto/mod.ts`:
 
 ### `encrypt(plaintext, password, keyVersion?): Promise<EncryptedData>`
 
 Encrypts a string using AES-256-GCM with PBKDF2 key derivation.
 
 **Process**:
+
 1. Generate random 16-byte salt
 2. Generate random 12-byte IV
-3. Derive 256-bit key from password + salt via PBKDF2 (SHA-256, 100k iterations for v1)
+3. Derive 256-bit key from password + salt via PBKDF2 (SHA-256, 100k iterations
+   for v1)
 4. Encrypt plaintext with AES-256-GCM using the derived key and IV
-5. Return `{ keyVersion, salt: base64(salt), iv: base64(iv), data: base64(ciphertext) }`
+5. Return
+   `{ keyVersion, salt: base64(salt), iv: base64(iv), data: base64(ciphertext) }`
 
 ### `decrypt(encryptedData, password): Promise<string>`
 
 Decrypts an `EncryptedData` object.
 
 **Process**:
+
 1. Decode base64 salt, IV, and ciphertext
 2. Derive key from password + salt + keyVersion via PBKDF2
 3. Decrypt with AES-256-GCM
 4. Return plaintext string
-5. Throw `"Decryption failed: Invalid data or key"` on failure (no information leakage about which part failed)
+5. Throw `"Decryption failed: Invalid data or key"` on failure (no information
+   leakage about which part failed)
 
 ### `generateEncryptionKey(): string`
 
-Generates a 32-byte random key encoded as base64. Used by operators to create encryption keys for the key ring.
+Generates a 32-byte random key encoded as base64. Used by operators to create
+encryption keys for the key ring.
 
-**Key ring format** (application-level, not in this package): A comma-separated list of `v{N}:{base64key}` pairs. The first key is the "current" key used for new encryptions. All keys are available for decryption.
+**Key ring format** (application-level, not in this package): A comma-separated
+list of `v{N}:{base64key}` pairs. The first key is the "current" key used for
+new encryptions. All keys are available for decryption.
 
 ### Key Versioning
 
 PBKDF2 iteration count varies by key version:
+
 - v1: 100,000 iterations
 - Future versions: 200,000+ (adjust for hardware improvements)
 
-This allows gradual security upgrades. Old data encrypted with v1 can still be decrypted. Re-encryption (rotate) reads with the old key and writes with the current key.
+This allows gradual security upgrades. Old data encrypted with v1 can still be
+decrypted. Re-encryption (rotate) reads with the old key and writes with the
+current key.
 
 ### Web Crypto API
 
-The implementation uses the standard Web Crypto API (`crypto.subtle`), available in:
+The implementation uses the standard Web Crypto API (`crypto.subtle`), available
+in:
+
 - Deno runtime (native)
 - Node.js 19+ (native)
 - Modern browsers (native)
@@ -161,65 +208,100 @@ No external crypto dependencies.
 
 ### ED1: Per-attribute encryption, not per-node
 
-The `EncryptedData` schema is a single attribute within a node type's attributes, not the entire node. This means:
+The `EncryptedData` schema is a single attribute within a node type's
+attributes, not the entire node. This means:
 
 - A secret node can have unencrypted metadata alongside the encrypted value
 - The node key (identity) is always readable for queries
 - Only the sensitive payload is encrypted
 
-**Alternative considered**: Encrypt the entire `attributes` column. This makes queries impossible (you can't find "all secrets for client X" if the client reference is encrypted). Per-attribute encryption preserves queryability on non-sensitive fields.
+**Alternative considered**: Encrypt the entire `attributes` column. This makes
+queries impossible (you can't find "all secrets for client X" if the client
+reference is encrypted). Per-attribute encryption preserves queryability on
+non-sensitive fields.
 
 ### ED2: Node type, not standalone table
 
-Encrypted data is modeled as a node type rather than a dedicated `secrets` table because:
+Encrypted data is modeled as a node type rather than a dedicated `secrets` table
+because:
 
-- **Graphs already provide the structure** — edges represent "client X has secret Y" without a join table
+- **Graphs already provide the structure** — edges represent "client X has
-- **No foreign key proliferation** — new secret types (OAuth, SSH, API keys) are new node types, not new columns or tables
+  secret Y" without a join table
-- **Uniform query patterns** — All graph queries work on secret nodes without special code
+- **No foreign key proliferation** — new secret types (OAuth, SSH, API keys) are
+  new node types, not new columns or tables
+- **Uniform query patterns** — All graph queries work on secret nodes without
+  special code
 
-**When a standalone table might be better**: If the hub needs to query "all active API keys" across all clients with a single indexed `WHERE` clause, a dedicated `api_keys` table with proper indexes is faster. The graph model requires traversing edges to find related secrets. For the hub's specific use case (key lookup on every authenticated request), this matters. The metagraph pattern is optimized for flexibility, not raw key-lookup performance. The hub should use a standalone `api_keys` table for authentication and the metagraph for everything else.
+**When a standalone table might be better**: If the hub needs to query "all
+active API keys" across all clients with a single indexed `WHERE` clause, a
+dedicated `api_keys` table with proper indexes is faster. The graph model
+requires traversing edges to find related secrets. For the hub's specific use
+case (key lookup on every authenticated request), this matters. The metagraph
+pattern is optimized for flexibility, not raw key-lookup performance. The hub
+should use a standalone `api_keys` table for authentication and the metagraph
+for everything else.
 
 ### ED3: Password-based encryption, not raw-key encryption
 
-The current implementation uses PBKDF2 to derive a key from a password string. The "password" in practice is a base64-encoded 32-byte random key from `generateEncryptionKey()`. This means:
+The current implementation uses PBKDF2 to derive a key from a password string.
+The "password" in practice is a base64-encoded 32-byte random key from
+`generateEncryptionKey()`. This means:
 
-- The key derivation step adds security even when the input is already high-entropy (each encryption gets a unique salt, so the same key produces different ciphertexts)
+- The key derivation step adds security even when the input is already
-- However, this adds ~100ms of latency per encryption/decryption due to PBKDF2 iterations
+  high-entropy (each encryption gets a unique salt, so the same key produces
+  different ciphertexts)
+- However, this adds ~100ms of latency per encryption/decryption due to PBKDF2
+  iterations
 
-**Alternative**: Direct AES-GCM with raw key bytes (skip PBKDF2). This would be much faster for high-throughput scenarios but removes the per-encryption salt benefit (the IV still provides uniqueness for GCM). The hub uses password-based because the config format is human-manageable key strings. For `@alkdev/storage`, either approach works — the API accepts a "password" string which could be a raw key encoded as base64.
+**Alternative**: Direct AES-GCM with raw key bytes (skip PBKDF2). This would be
+much faster for high-throughput scenarios but removes the per-encryption salt
+benefit (the IV still provides uniqueness for GCM). The hub uses password-based
+because the config format is human-manageable key strings. For
+`@alkdev/storage`, either approach works — the API accepts a "password" string
+which could be a raw key encoded as base64.
 
-**Decision**: Use the same PBKDF2 pattern for consistency with the hub. If performance becomes an issue, add a `encryptRaw()` function that skips PBKDF2 for raw key inputs.
+**Decision**: Use the same PBKDF2 pattern for consistency with the hub. If
+performance becomes an issue, add a `encryptRaw()` function that skips PBKDF2
+for raw key inputs.
 
 ### ED4: Application-managed key ring
 
-The storage package provides `encrypt()` and `decrypt()` but does NOT manage the key ring. The consuming application:
+The storage package provides `encrypt()` and `decrypt()` but does NOT manage the
+key ring. The consuming application:
 
-1. Stores encryption keys in a secure location (Docker secrets, vault, config file with restricted permissions)
+1. Stores encryption keys in a secure location (Docker secrets, vault, config
+   file with restricted permissions)
 2. Loads keys at startup
 3. Passes the appropriate key to `encrypt()` / `decrypt()` based on `keyVersion`
 4. Handles key rotation (decrypt with old key, re-encrypt with current key)
 
 This separation ensures:
+
 - The storage package doesn't need to know about deployment infrastructure
 - Key management policies are application-specific
 - The encryption primitives are testable without a key ring implementation
 
 ### ED5: No key rotation utility in this package
 
-Key rotation (decrypt with old key, re-encrypt with current key) is an application-level workflow:
+Key rotation (decrypt with old key, re-encrypt with current key) is an
+application-level workflow:
 
 1. Find all nodes with `attributes.encryptedData.keyVersion < currentVersion`
 2. For each: decrypt with old key → encrypt with current key → update node
 3. Commit transaction
 
-The storage package provides the building blocks (`encrypt()`, `decrypt()`, `EncryptedDataSchema`), not the rotation workflow. The hub's background sweep pattern is a good reference implementation.
+The storage package provides the building blocks (`encrypt()`, `decrypt()`,
+`EncryptedDataSchema`), not the rotation workflow. The hub's background sweep
+pattern is a good reference implementation.
 
 ## Integration with SQLite Host
 
-Encrypted node attributes are stored as JSON text in the `nodes.attributes` column, same as any other node attributes. The `EncryptedDataSchema` validates the shape at the application level.
+Encrypted node attributes are stored as JSON text in the `nodes.attributes`
+column, same as any other node attributes. The `EncryptedDataSchema` validates
+the shape at the application level.
 
 ```ts
-import { encrypt, decrypt } from "@alkdev/storage";
+import { decrypt, encrypt } from "@alkdev/storage";
 import { EncryptedDataSchema } from "@alkdev/storage";
 
 const encryptionKey = "v1:YmFzZTY0a2V5"; // from application config
@@ -245,7 +327,8 @@ const attributes = {
 
 ## Export Plan
 
-The crypto module will be exported from the main `@alkdev/storage` package (no db deps):
+The crypto module will be exported from the main `@alkdev/storage` package (no
+db deps):
 
 ```
 src/graphs/
@@ -255,19 +338,37 @@ src/graphs/
 └── mod.ts            # re-exports all of the above
 ```
 
-This keeps the encryption utility in the zero-dep export path (it only uses Web Crypto API and `@alkdev/typebox` for the schema).
+This keeps the encryption utility in the zero-dep export path (it only uses Web
+Crypto API and `@alkdev/typebox` for the schema).
 
 ## Open Questions
 
-1. **Should we add `encryptRaw()` for performance?** The PBKDF2 derivation adds ~100ms per operation. For batch secret operations (e.g., rotating 1000 keys), this adds up. A `encryptRaw()` that skips PBKDF2 and uses the key directly would be much faster. Decision: add in a future iteration if performance demands it.
+1. **Should we add `encryptRaw()` for performance?** The PBKDF2 derivation adds
+   ~100ms per operation. For batch secret operations (e.g., rotating 1000 keys),
+   this adds up. A `encryptRaw()` that skips PBKDF2 and uses the key directly
+   would be much faster. Decision: add in a future iteration if performance
+   demands it.
 
-2. **Should the `key` attribute on secret nodes be encrypted?** Currently only the `encryptedData` attribute is encrypted. The `key` (secret name like "api_key") is stored in plaintext for queryability. If secret names are themselves sensitive, they could be hashed instead. Decision: plaintext key names are acceptable for now. If needed, add a `keyHash` attribute for blind lookups (similar to the hub's `api_keys.keyHash`).
+2. **Should the `key` attribute on secret nodes be encrypted?** Currently only
+   the `encryptedData` attribute is encrypted. The `key` (secret name like
+   "api_key") is stored in plaintext for queryability. If secret names are
+   themselves sensitive, they could be hashed instead. Decision: plaintext key
+   names are acceptable for now. If needed, add a `keyHash` attribute for blind
+   lookups (similar to the hub's `api_keys.keyHash`).
 
-3. **Should secret nodes have `lastUsedAt` and `expiresAt` as first-class columns?** The hub's `client_secrets` has these as columns for indexed queries. In the metagraph model, they're attributes inside the node JSON. SQLite can't efficiently index JSON properties. Decision: for spoke use (occasional lookups), JSON attributes are fine. For hub use (high-throughput key validation), a standalone `api_keys` table with proper indexes is still needed.
+3. **Should secret nodes have `lastUsedAt` and `expiresAt` as first-class
+   columns?** The hub's `client_secrets` has these as columns for indexed
+   queries. In the metagraph model, they're attributes inside the node JSON.
+   SQLite can't efficiently index JSON properties. Decision: for spoke use
+   (occasional lookups), JSON attributes are fine. For hub use (high-throughput
+   key validation), a standalone `api_keys` table with proper indexes is still
+   needed.
 
 ## References
 
 - Hub crypto utility: `/workspace/@alkdev/hub/src/crypto/mod.ts`
-- Hub `client_secrets` table: `/workspace/@alkdev/hub/docs/architecture/storage/services.md`
+- Hub `client_secrets` table:
-- Hub ADR-008: `/workspace/@alkdev/hub/docs/decisions/ADR-008-secrets-encrypted-at-rest-with-key-versioning.md`
+  `/workspace/@alkdev/hub/docs/architecture/storage/services.md`
+- Hub ADR-008:
+  `/workspace/@alkdev/hub/docs/decisions/ADR-008-secrets-encrypted-at-rest-with-key-versioning.md`
 - Web Crypto API: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto

docs/architecture/metagraph.md

@@ -5,17 +5,27 @@ last_updated: 2026-05-28
 
 # Metagraph Model
 
-The core data model: graph types define schemas, node types define shapes, edge types define relationships, and typed graph instances hold actual data.
+The core data model: graph types define schemas, node types define shapes, edge
+types define relationships, and typed graph instances hold actual data.
 
 ## Overview
 
 The metagraph pattern is a three-level type system:
 
-1. **GraphType** — A class of graphs (e.g., "call-graph", "acl", "task-dependencies"). Defines structural constraints (directed/undirected/mixed, allows self-loops, multi-edges) via a `GraphConfig`.
+1. **GraphType** — A class of graphs (e.g., "call-graph", "acl",
-2. **NodeType** — A category of node within a graph type (e.g., "operation-call", "account", "task"). Each node type has a TypeBox schema that validates the `attributes` of nodes belonging to that type. Optionally constrains which edge types can connect from/to this node type.
+   "task-dependencies"). Defines structural constraints
-3. **EdgeType** — A category of edge within a graph type (e.g., "triggered", "can_read", "depends_on"). Each edge type has a TypeBox schema for its attributes. Optionally constrains which source/target node types are valid.
+   (directed/undirected/mixed, allows self-loops, multi-edges) via a
+   `GraphConfig`.
+2. **NodeType** — A category of node within a graph type (e.g.,
+   "operation-call", "account", "task"). Each node type has a TypeBox schema
+   that validates the `attributes` of nodes belonging to that type. Optionally
+   constrains which edge types can connect from/to this node type.
+3. **EdgeType** — A category of edge within a graph type (e.g., "triggered",
+   "can_read", "depends_on"). Each edge type has a TypeBox schema for its
+   attributes. Optionally constrains which source/target node types are valid.
 
-Then **Graph instances** belong to a graph type and contain **Nodes** and **Edges** conforming to those type definitions.
+Then **Graph instances** belong to a graph type and contain **Nodes** and
+**Edges** conforming to those type definitions.
 
 ```
 GraphType "call-graph" (directed, multi, self-loops allowed)
@@ -40,7 +50,8 @@ Graph "session-abc-call-graph" (instance)
 
 ## Schema Types
 
-Defined in `src/graphs/types.ts`. Zero database dependencies — these are pure TypeBox schemas used for validation and type inference.
+Defined in `src/graphs/types.ts`. Zero database dependencies — these are pure
+TypeBox schemas used for validation and type inference.
 
 ### BaseNodeAttributes
 
@@ -63,7 +74,8 @@ Optional audit and extension fields. Node `attributes` should extend this.
 }
 ```
 
-Every edge carries its type and optional metadata. Edge `attributes` should extend this.
+Every edge carries its type and optional metadata. Edge `attributes` should
+extend this.
 
 ### GraphConfig
 
@@ -75,7 +87,9 @@ Every edge carries its type and optional metadata. Edge `attributes` should exte
 }
 ```
 
-Structural constraints for a graph type. Defaults encourage permissive graphs (mixed, multi-edges, self-loops) because most real-world graphs need these features.
+Structural constraints for a graph type. Defaults encourage permissive graphs
+(mixed, multi-edges, self-loops) because most real-world graphs need these
+features.
 
 ### NodeType
 
@@ -86,7 +100,10 @@ Structural constraints for a graph type. Defaults encourage permissive graphs (m
 }
 ```
 
-A node type definition. The `schema` validates the `attributes` of nodes that belong to this type. Consumer must extend `BaseNodeAttributes` in their schema — the metagraph model does not enforce this at the database level (SQLite can't enforce JSON schema), but the SchemaBuilder validates it at definition time.
+A node type definition. The `schema` validates the `attributes` of nodes that
+belong to this type. Consumer must extend `BaseNodeAttributes` in their schema —
+the metagraph model does not enforce this at the database level (SQLite can't
+enforce JSON schema), but the SchemaBuilder validates it at definition time.
 
 ### EdgeType
 
@@ -99,7 +116,10 @@ A node type definition. The `schema` validates the `attributes` of nodes that be
 }
 ```
 
-An edge type definition. Optionally constrains which node types can appear at source/target endpoints. When `allowedSourceTypes` or `allowedTargetTypes` is undefined, any node type is valid. When defined, only listed node types are valid endpoints.
+An edge type definition. Optionally constrains which node types can appear at
+source/target endpoints. When `allowedSourceTypes` or `allowedTargetTypes` is
+undefined, any node type is valid. When defined, only listed node types are
+valid endpoints.
 
 ### GraphSchema
 
@@ -111,7 +131,8 @@ An edge type definition. Optionally constrains which node types can appear at so
 }
 ```
 
-The complete definition of a graph type. This is what `SchemaBuilder.build()` produces.
+The complete definition of a graph type. This is what `SchemaBuilder.build()`
+produces.
 
 ### GraphStatus & GraphBaseType
 
@@ -120,7 +141,8 @@ Enum-backed types for graph lifecycle and structural type:
 - `GraphStatus`: `active`, `archived`, `draft`
 - `GraphBaseType`: `directed`, `undirected`, `mixed`
 
-These are provided both as TypeScript enums and TypeBox schemas, derived from the same enum definition.
+These are provided both as TypeScript enums and TypeBox schemas, derived from
+the same enum definition.
 
 ## SchemaBuilder
 
@@ -143,53 +165,90 @@ const schema = new SchemaBuilder()
 
 The builder validates at each step:
 
-1. **`config()`** — Validates against `GraphConfig` schema. Applies defaults for missing fields.
+1. **`config()`** — Validates against `GraphConfig` schema. Applies defaults for
-2. **`nodeType()`** — Validates the schema is a valid TypeBox schema (`KindGuard.IsSchema`). Validates the resulting object against `NodeType` schema.
+   missing fields.
-3. **`edgeType()`** — Same as nodeType, plus validates allowedSourceTypes/allowedTargetTypes are strings.
+2. **`nodeType()`** — Validates the schema is a valid TypeBox schema
-4. **`build()`** — Validates the complete schema against `GraphSchema`. Throws on any invalid structure.
+   (`KindGuard.IsSchema`). Validates the resulting object against `NodeType`
+   schema.
+3. **`edgeType()`** — Same as nodeType, plus validates
+   allowedSourceTypes/allowedTargetTypes are strings.
+4. **`build()`** — Validates the complete schema against `GraphSchema`. Throws
+   on any invalid structure.
 
-**Error behavior**: The builder throws `Error` with a JSON-stringified list of validation errors (path + message). Validation failures do not roll back partial state — a builder that fails on the second `nodeType()` call still has the first node type in its schema. Callers should not reuse a builder after a failure. Create a new `SchemaBuilder` instead.
+**Error behavior**: The builder throws `Error` with a JSON-stringified list of
+validation errors (path + message). Validation failures do not roll back partial
+state — a builder that fails on the second `nodeType()` call still has the first
+node type in its schema. Callers should not reuse a builder after a failure.
+Create a new `SchemaBuilder` instead.
 
-**Edge type enforcement**: When `allowedSourceTypes` or `allowedTargetTypes` is undefined (or an empty array at the application layer), any node type is a valid endpoint. When a non-empty array is provided, only the listed node types are valid endpoints. The repository layer should enforce this at write time.
+**Edge type enforcement**: When `allowedSourceTypes` or `allowedTargetTypes` is
+undefined (or an empty array at the application layer), any node type is a valid
+endpoint. When a non-empty array is provided, only the listed node types are
+valid endpoints. The repository layer should enforce this at write time.
 
-The SchemaBuilder enforces structural integrity at definition time. The database stores graph/node/edge type schemas as JSON blobs (`text` mode in SQLite, will be `jsonb` in PG). Database-level constraints (unique composite keys, cascade deletes) protect referential integrity, but the database does NOT validate JSON schema conformance. This is a deliberate trade-off:
+The SchemaBuilder enforces structural integrity at definition time. The database
+stores graph/node/edge type schemas as JSON blobs (`text` mode in SQLite, will
+be `jsonb` in PG). Database-level constraints (unique composite keys, cascade
+deletes) protect referential integrity, but the database does NOT validate JSON
+schema conformance. This is a deliberate trade-off:
 
-- **Pro**: Schema changes don't require migrations. A graph type's schema evolves by updating the JSON blob.
+- **Pro**: Schema changes don't require migrations. A graph type's schema
+  evolves by updating the JSON blob.
 - **Pro**: SQLite's JSON support is limited (no JSON schema constraints).
-- **Con**: Invalid data can be inserted if application-level validation is bypassed.
+- **Con**: Invalid data can be inserted if application-level validation is
-- **Mitigation**: All repository-layer mutations validate against the current graph type's schema before writing.
+  bypassed.
+- **Mitigation**: All repository-layer mutations validate against the current
+  graph type's schema before writing.
 
 ## Node and Edge Identity
 
 Nodes and edges use a **composite identity model**:
 
-- **Node**: identified by `(graphId, key)` — unique within a graph. The `key` is a consumer-defined string (e.g., `"call-001"`, `"account:alice"`).
+- **Node**: identified by `(graphId, key)` — unique within a graph. The `key` is
-- **Edge**: identified by `(graphId, key)` — unique within a graph. The `key` is optional for directed graphs but required for multi-edges.
+  a consumer-defined string (e.g., `"call-001"`, `"account:alice"`).
+- **Edge**: identified by `(graphId, key)` — unique within a graph. The `key` is
+  optional for directed graphs but required for multi-edges.
 
-This means consumers control their own identifiers within a graph. The database generates UUID `id` values for cross-graph references, but within a graph, the consumer's `key` is the identity.
+This means consumers control their own identifiers within a graph. The database
+generates UUID `id` values for cross-graph references, but within a graph, the
+consumer's `key` is the identity.
 
 ## Attributes Storage
 
-Node attributes and edge attributes are stored as JSON text in SQLite (will be `jsonb` in PG). The graph type's schema defines what shape these attributes should have, but the database doesn't enforce the schema — it stores whatever JSON is provided.
+Node attributes and edge attributes are stored as JSON text in SQLite (will be
+`jsonb` in PG). The graph type's schema defines what shape these attributes
+should have, but the database doesn't enforce the schema — it stores whatever
+JSON is provided.
 
 This design means:
 
-- **Schema evolution**: Add optional fields to a node type schema without migration. Old nodes are still valid.
+- **Schema evolution**: Add optional fields to a node type schema without
-- **Schema versioning**: The `version` field on graph types tracks breaking schema changes. Consumer code can check the version before processing.
+  migration. Old nodes are still valid.
-- **Validation boundary**: All validation happens in the repository layer (application code), not in the database.
+- **Schema versioning**: The `version` field on graph types tracks breaking
+  schema changes. Consumer code can check the version before processing.
+- **Validation boundary**: All validation happens in the repository layer
+  (application code), not in the database.
 
 ## Versioning
 
-Graph types have a `version` integer (default 1). This tracks **breaking** schema changes — field removals, type changes that break backward compatibility. Non-breaking changes (adding optional fields) do not require a version bump.
+Graph types have a `version` integer (default 1). This tracks **breaking**
+schema changes — field removals, type changes that break backward compatibility.
+Non-breaking changes (adding optional fields) do not require a version bump.
 
-The repository layer should check `version` before processing to ensure compatibility. A version mismatch indicates the data format has changed incompatibly and the consumer should handle it explicitly.
+The repository layer should check `version` before processing to ensure
+compatibility. A version mismatch indicates the data format has changed
+incompatibly and the consumer should handle it explicitly.
 
 ## Usage Patterns
 
 ### Defining a Call Graph Type
 
 ```ts
-import { SchemaBuilder, BaseNodeAttributes, BaseEdgeAttributes } from "@alkdev/storage";
+import {
+  BaseEdgeAttributes,
+  BaseNodeAttributes,
+  SchemaBuilder,
+} from "@alkdev/storage";
 import { Type } from "@alkdev/typebox";
 
 const CallNodeAttributes = Type.Intersect([
@@ -250,7 +309,9 @@ const schema = new SchemaBuilder()
 
 ### Defining Encrypted Secret Storage as a Node Type
 
-> **⚠️ Not yet implemented.** `EncryptedDataSchema` and `encrypt()`/`decrypt()` are planned additions. See [encrypted-data.md](./encrypted-data.md) for the design.
+> **⚠️ Not yet implemented.** `EncryptedDataSchema` and `encrypt()`/`decrypt()`
+> are planned additions. See [encrypted-data.md](./encrypted-data.md) for the
+> design.
 
 ```ts
 // PLANNED — not yet available
@@ -275,8 +336,10 @@ See [encrypted-data.md](./encrypted-data.md) for the full encrypted data design.
 
 ## References
 
-- Hub call graph spec: `/workspace/@alkdev/hub/docs/architecture/storage/call-graph.md`
+- Hub call graph spec:
-- Hub identity spec: `/workspace/@alkdev/hub/docs/architecture/storage/identity.md`
+  `/workspace/@alkdev/hub/docs/architecture/storage/call-graph.md`
+- Hub identity spec:
+  `/workspace/@alkdev/hub/docs/architecture/storage/identity.md`
 - TypeBox: https://github.com/sinclairzx/typebox
 - SchemaBuilder source: `src/graphs/schemaBuilder.ts`
 - Schema types source: `src/graphs/types.ts`

docs/architecture/overview.md

@@ -9,11 +9,19 @@ Typed graph storage with dual database hosts. Deno-first, published via JSR.
 
 ## Purpose
 
-`@alkdev/storage` provides a **metagraph** storage model: graph types define schemas, node types define data shapes within those graphs, and edge types define typed relationships. Instances of these type definitions become actual graphs populated with nodes and edges.
+`@alkdev/storage` provides a **metagraph** storage model: graph types define
+schemas, node types define data shapes within those graphs, and edge types
+define typed relationships. Instances of these type definitions become actual
+graphs populated with nodes and edges.
 
-This pattern replaces domain-specific table proliferation with a small number of general-purpose tables that can model anything — call graphs, ACL rules, task dependencies, encrypted secrets — while enforcing schema integrity through TypeBox validation.
+This pattern replaces domain-specific table proliferation with a small number of
+general-purpose tables that can model anything — call graphs, ACL rules, task
+dependencies, encrypted secrets — while enforcing schema integrity through
+TypeBox validation.
 
-The package evolved from `@ade/ade-v0/packages/core/graphs` and `@ade/ade-v0/packages/storage_sqlite`, simplified and refactored for the @alkdev ecosystem.
+The package evolved from `@ade/ade-v0/packages/core/graphs` and
+`@ade/ade-v0/packages/storage_sqlite`, simplified and refactored for the @alkdev
+ecosystem.
 
 ## Architecture
 
@@ -34,18 +42,20 @@ The package evolved from `@ade/ade-v0/packages/core/graphs` and `@ade/ade-v0/pac
 ### Subpath Exports (JSR/npm)
 
 | Export                   | Contents                                | Dependencies                            |
-|--------|----------|-------------|
+| ------------------------ | --------------------------------------- | --------------------------------------- |
 | `@alkdev/storage`        | Graph schema types, SchemaBuilder       | `@alkdev/typebox`, `@alkdev/drizzlebox` |
 | `@alkdev/storage/graphs` | Same as `.` — alias for the main export | Same as `.`                             |
 | `@alkdev/storage/sqlite` | SQLite tables, relations, client        | + `drizzle-orm`, `@libsql/client`       |
 | `@alkdev/storage/pg`     | PostgreSQL tables, relations, client    | ⚠️ NOT YET IMPLEMENTED                  |
 
-The `./graphs` subpath exists because the source code lives in `src/graphs/` and the main `mod.ts` re-exports it. Importing from either `@alkdev/storage` or `@alkdev/storage/graphs` yields the same types and SchemaBuilder.
+The `./graphs` subpath exists because the source code lives in `src/graphs/` and
+the main `mod.ts` re-exports it. Importing from either `@alkdev/storage` or
+`@alkdev/storage/graphs` yields the same types and SchemaBuilder.
 
 ## Terminology
 
 | Term                    | Definition                                                                                                                                                                                                                   |
-|------|-----------|
+| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | **Metagraph**           | A type system where graph types define schemas, node types define data shapes within those graphs, and edge types define typed relationships. Graph instances are concrete data conforming to these type definitions.        |
 | **Hub**                 | The central service in the hub-spoke architecture. Runs PostgreSQL, hosts API endpoints, coordinates spokes, and is the authoritative data store. `@alkdev/storage`'s PostgreSQL host (not yet implemented) targets the hub. |
 | **Spoke**               | A local/embedded instance that runs per-project or per-session. Uses SQLite for local storage. `@alkdev/storage`'s SQLite host targets spokes.                                                                               |
@@ -61,62 +71,85 @@ The `./graphs` subpath exists because the source code lives in `src/graphs/` and
 
 ### D1: Deno-first, JSR publishes, npm comes free
 
-The package is published to JSR (`deno publish`). npm compatibility is automatic via JSR's npm layer (`@jsr/alkdev__storage`). No separate dnt build step.
+The package is published to JSR (`deno publish`). npm compatibility is automatic
+via JSR's npm layer (`@jsr/alkdev__storage`). No separate dnt build step.
 
 ### D2: Metagraph over domain-specific tables
 
-Instead of a table per domain concept (call graphs, ACL rules, task trees), we define graph types with typed node and edge schemas. A "call graph" is a graph type with specific node types (operation call, subcall) and edge types (triggered, depends_on). An "ACL graph" is a graph type with node types (account, resource) and edge types (can_read, can_write).
+Instead of a table per domain concept (call graphs, ACL rules, task trees), we
+define graph types with typed node and edge schemas. A "call graph" is a graph
+type with specific node types (operation call, subcall) and edge types
+(triggered, depends_on). An "ACL graph" is a graph type with node types
+(account, resource) and edge types (can_read, can_write).
 
-This trades some query convenience for generality. Domain-specific queries are built on top of the graph query layer, not baked into table schemas.
+This trades some query convenience for generality. Domain-specific queries are
+built on top of the graph query layer, not baked into table schemas.
 
 ### D3: SchemaBuilder as the primary API surface
 
-The `SchemaBuilder` fluent API is the intended way to construct graph type definitions. It validates against TypeBox schemas at build time, ensuring that graph/node/edge type definitions are structurally sound before they're persisted to the database.
+The `SchemaBuilder` fluent API is the intended way to construct graph type
+definitions. It validates against TypeBox schemas at build time, ensuring that
+graph/node/edge type definitions are structurally sound before they're persisted
+to the database.
 
 ### D4: Injectable clients, no module-level side effects
 
-`createSqliteDatabase(client)` receives a pre-created client. Module-level side effects (auto-connections, env-based configuration) are forbidden. This enables testing with in-memory databases and containerized deployment patterns.
+`createSqliteDatabase(client)` receives a pre-created client. Module-level side
+effects (auto-connections, env-based configuration) are forbidden. This enables
+testing with in-memory databases and containerized deployment patterns.
 
 ### D5: Drizzle + TypeBox (via drizzlebox) as the table definition pattern
 
-Drizzle table definitions are the single source of truth for database schema. `@alkdev/drizzlebox` generates TypeBox `Select*` and `Insert*` schemas from Drizzle tables, enabling runtime validation without manual schema duplication.
+Drizzle table definitions are the single source of truth for database schema.
+`@alkdev/drizzlebox` generates TypeBox `Select*` and `Insert*` schemas from
+Drizzle tables, enabling runtime validation without manual schema duplication.
 
 ### D6: Enumeration pattern — `as const` objects, not TypeScript enums
 
-All enumerations use the `as const` object pattern (e.g., `GRAPH_STATUS = { Active: "active", ... } as const`) rather than TypeScript `enum`. This avoids JSR slow-type issues (the existing lint exclusion for `no-slow-types` was needed partly because of TS enums) and provides a consistent pattern across the codebase. The TypeBox schemas use `Type.Union` of `Type.Literal` values derived from the const object.
+All enumerations use the `as const` object pattern (e.g.,
+`GRAPH_STATUS = { Active: "active", ... } as const`) rather than TypeScript
+`enum`. This avoids JSR slow-type issues and provides a consistent pattern
+across the codebase. The TypeBox schemas use `Type.Union` of `Type.Literal`
+values derived from the const object.
 
 ### D7: No comments in code
 
-Per project convention across @alkdev packages, source files contain no inline comments. Documentation lives in architecture docs and TypeBox schema descriptions.
+Per project convention across @alkdev packages, source files contain no inline
+comments. Documentation lives in architecture docs and TypeBox schema
+descriptions.
 
 ### D8: Common columns pattern
 
-All tables share `id` (text PK), `metadata` (JSON text defaulting to `{}`), `createdAt`, and `updatedAt` (integer timestamps in SQLite, will be timestamptz in PG). This ensures every row has auditability and extensibility.
+All tables share `id` (text PK), `metadata` (JSON text defaulting to `{}`),
+`createdAt`, and `updatedAt` (integer timestamps in SQLite, will be timestamptz
+in PG). This ensures every row has auditability and extensibility.
 
 ## Dependencies
 
 | Package              | Purpose                              | Layer                    |
-|---------|---------|-------|
+| -------------------- | ------------------------------------ | ------------------------ |
 | `@alkdev/typebox`    | Runtime schema validation            | graphs/                  |
 | `@alkdev/drizzlebox` | Generate TypeBox from Drizzle tables | sqlite/                  |
 | `drizzle-orm`        | ORM, table definitions, queries      | sqlite/ (and future pg/) |
 | `@libsql/client`     | SQLite client (libsql/turso)         | sqlite/                  |
 | `postgres`           | PostgreSQL client                    | pg/ (not yet used)       |
 
-`@alkdev/typebox` and `@alkdev/drizzlebox` are npm packages (not yet on JSR). JSR handles npm dependencies natively.
+`@alkdev/typebox` and `@alkdev/drizzlebox` are npm packages (not yet on JSR).
+JSR handles npm dependencies natively.
 
 ## What Exists vs. What's Needed
 
 ### Implemented
 
 - Graph schema types and SchemaBuilder
-- SQLite host: 6 metagraph tables + actors table + Drizzle relations + client factory
+- SQLite host: 6 metagraph tables + actors table + Drizzle relations + client
+  factory
 - TypeBox select/insert schemas generated from Drizzle tables (drizzlebox)
 
 ### Not Yet Implemented
 
 | Gap                                       | Priority     | Notes                                                                                               |
-|-----|----------|-------|
+| ----------------------------------------- | ------------ | --------------------------------------------------------------------------------------------------- |
 | Encrypted data node type + crypto utility | **Critical** | ⚠️ Not yet implemented. API keys and secrets at rest. See [encrypted-data.md](./encrypted-data.md). |
 | Repository/CRUD layer                     | High         | ⚠️ Not yet implemented. Typed insert, find, update, delete functions for graphs, nodes, edges       |
 | Tests                                     | High         | Zero tests exist. Needed before any real use.                                                       |
@@ -127,20 +160,41 @@ All tables share `id` (text PK), `metadata` (JSON text defaulting to `{}`), `cre
 
 ## Open Questions
 
-1. **Should `actors` be a node type or a standalone table?** Currently `actors` is a standalone table in the SQLite host that isn't referenced by any relation. If identity/authentication is a graph (ACL nodes), actors become node types. If identity is a domain concept that needs special query patterns (auth lookups, session joins), standalone tables may be better. Decision: defer until ACL design.
+1. **Should `actors` be a node type or a standalone table?** Currently `actors`
+   is a standalone table in the SQLite host that isn't referenced by any
+   relation. If identity/authentication is a graph (ACL nodes), actors become
+   node types. If identity is a domain concept that needs special query patterns
+   (auth lookups, session joins), standalone tables may be better. Decision:
+   defer until ACL design.
 
-2. **Should the repository layer be host-specific or host-agnostic?** A host-agnostic repository (insert graph, find nodes by type) requires an abstraction over Drizzle's query builder. A host-specific repository is simpler but means duplicating query logic for PG. Decision: start host-specific in SQLite, extract common patterns later.
+2. **Should the repository layer be host-specific or host-agnostic?** A
+   host-agnostic repository (insert graph, find nodes by type) requires an
+   abstraction over Drizzle's query builder. A host-specific repository is
+   simpler but means duplicating query logic for PG. Decision: start
+   host-specific in SQLite, extract common patterns later.
 
-3. **Encrypted data scope**: Should encryption be per-attribute, per-node, or per-graph? Per-attribute (like hub's `client_secrets.value`) allows selective encryption. Per-node encrypts the entire `attributes` blob. Per-graph is overkill. Decision: per-attribute, modeled as an encrypted node type with a dedicated attribute for the ciphertext.
+3. **Encrypted data scope**: Should encryption be per-attribute, per-node, or
+   per-graph? Per-attribute (like hub's `client_secrets.value`) allows selective
+   encryption. Per-node encrypts the entire `attributes` blob. Per-graph is
+   overkill. Decision: per-attribute, modeled as an encrypted node type with a
+   dedicated attribute for the ciphertext.
 
-4. **Key management scope**: `@alkdev/storage` should provide the encryption/decryption primitives but NOT key management. The consuming application provides the key ring. This keeps the storage package agnostic to deployment-specific secret management.
+4. **Key management scope**: `@alkdev/storage` should provide the
+   encryption/decryption primitives but NOT key management. The consuming
+   application provides the key ring. This keeps the storage package agnostic to
+   deployment-specific secret management.
 
-5. **Migration strategy**: When graph type schemas evolve (new node types, changed attribute schemas), who handles migration? The repository layer should support schema version checking, but actual migration scripts are application-level. See [metagraph.md](./metagraph.md) for the versioning approach.
+5. **Migration strategy**: When graph type schemas evolve (new node types,
+   changed attribute schemas), who handles migration? The repository layer
+   should support schema version checking, but actual migration scripts are
+   application-level. See [metagraph.md](./metagraph.md) for the versioning
+   approach.
 
 ## References
 
 - Hub storage spec: `/workspace/@alkdev/hub/docs/architecture/storage/`
-- Source heritage: `@ade/ade-v0/packages/core/graphs` and `@ade/ade-v0/packages/storage_sqlite`
+- Source heritage: `@ade/ade-v0/packages/core/graphs` and
+  `@ade/ade-v0/packages/storage_sqlite`
 - Drizzle ORM: https://orm.drizzle.team/
 - TypeBox: https://github.com/sinclairzx/typebox
 - JSR: https://jsr.io/

docs/architecture/sqlite-host.md

@@ -5,18 +5,24 @@ last_updated: 2026-05-28
 
 # SQLite Host
 
-The SQLite database host for `@alkdev/storage`. Uses Drizzle ORM with libsql/Turso for the SQLite dialect and `@alkdev/drizzlebox` for TypeBox schema generation from Drizzle table definitions.
+The SQLite database host for `@alkdev/storage`. Uses Drizzle ORM with
+libsql/Turso for the SQLite dialect and `@alkdev/drizzlebox` for TypeBox schema
+generation from Drizzle table definitions.
 
 ## Overview
 
 The SQLite host provides:
 
-1. **Drizzle table definitions** for the metagraph pattern (graph types, node types, edge types, graphs, nodes, edges) plus a standalone `actors` table
+1. **Drizzle table definitions** for the metagraph pattern (graph types, node
+   types, edge types, graphs, nodes, edges) plus a standalone `actors` table
 2. **Drizzle relations** for the relational query API
-3. **TypeBox schemas** auto-generated from Drizzle tables (select/insert validation)
+3. **TypeBox schemas** auto-generated from Drizzle tables (select/insert
-4. **Injectable database factory** — `createSqliteDatabase(client)` accepts a pre-created client
+   validation)
+4. **Injectable database factory** — `createSqliteDatabase(client)` accepts a
+   pre-created client
 
-The SQLite host is the first-class target. PostgreSQL will follow the same table shapes with appropriate dialect changes.
+The SQLite host is the first-class target. PostgreSQL will follow the same table
+shapes with appropriate dialect changes.
 
 ## Package Structure
 
@@ -59,20 +65,22 @@ All tables share these columns:
 **Notable differences from hub's PostgreSQL common columns**:
 
 | Column      | SQLite                                | PostgreSQL (hub)                                              |
-|--------|--------|-------------------|
+| ----------- | ------------------------------------- | ------------------------------------------------------------- |
 | `id`        | text PK (consumer-generated)          | text PK with `$defaultFn(() => crypto.randomUUID())`          |
 | `metadata`  | `text` with JSON mode                 | `jsonb` with `$type<Record<string, unknown>>()`               |
 | `createdAt` | `integer` timestamp mode (Unix epoch) | `timestamp with timezone` defaulting `now()`                  |
 | `updatedAt` | `integer` timestamp mode (Unix epoch) | `timestamp with timezone` defaulting `now()` with `$onUpdate` |
 
-The SQLite columns do NOT have `$defaultFn` for ID generation (the consumer provides IDs) and do NOT have `$onUpdate` for `updatedAt` (Drizzle's `$onUpdate` is application-level; consumers must set it explicitly).
+The SQLite columns do NOT have `$defaultFn` for ID generation (the consumer
+provides IDs) and do NOT have `$onUpdate` for `updatedAt` (Drizzle's `$onUpdate`
+is application-level; consumers must set it explicitly).
 
 ### `graph_types`
 
 Stores graph type definitions (schemas for classes of graphs).
 
 | Column      | Type                | Constraints             | Notes                                                        |
-|--------|------|-------------|-------|
+| ----------- | ------------------- | ----------------------- | ------------------------------------------------------------ |
 | id          | text                | PK                      | Consumer-generated UUID                                      |
 | metadata    | text (JSON)         | default `{}`            | Extension namespace                                          |
 | createdAt   | integer (timestamp) | not null, default `now` |                                                              |
@@ -84,10 +92,11 @@ Stores graph type definitions (schemas for classes of graphs).
 
 ### `node_types`
 
-Stores node type definitions within a graph type. Each node type has a TypeBox schema that validates node attributes.
+Stores node type definitions within a graph type. Each node type has a TypeBox
+schema that validates node attributes.
 
 | Column      | Type                | Constraints                            | Notes                                    |
-|--------|------|-------------|-------|
+| ----------- | ------------------- | -------------------------------------- | ---------------------------------------- |
 | id          | text                | PK                                     |                                          |
 | metadata    | text (JSON)         | default `{}`                           |                                          |
 | createdAt   | integer (timestamp) | not null, default `now`                |                                          |
@@ -97,14 +106,15 @@ Stores node type definitions within a graph type. Each node type has a TypeBox s
 | description | text                | default `""`                           |                                          |
 | schema      | text (JSON)         | not null                               | TypeBox schema for node attributes       |
 
-**Unique constraint**: `(graphTypeId, name)` — node type names are unique within a graph type.
+**Unique constraint**: `(graphTypeId, name)` — node type names are unique within
+a graph type.
 
 ### `edge_types`
 
 Stores edge type definitions within a graph type.
 
 | Column             | Type                | Constraints                            | Notes                                          |
-|--------|------|-------------|-------|
+| ------------------ | ------------------- | -------------------------------------- | ---------------------------------------------- |
 | id                 | text                | PK                                     |                                                |
 | metadata           | text (JSON)         | default `{}`                           |                                                |
 | createdAt          | integer (timestamp) | not null, default `now`                |                                                |
@@ -116,16 +126,23 @@ Stores edge type definitions within a graph type.
 | allowedSourceTypes | text (JSON)         | default `[]`                           | Node type names valid at source endpoint       |
 | allowedTargetTypes | text (JSON)         | default `[]`                           | Node type names valid at target endpoint       |
 
-**Unique constraint**: `(graphTypeId, name)` — edge type names are unique within a graph type.
+**Unique constraint**: `(graphTypeId, name)` — edge type names are unique within
+a graph type.
 
-**Empty array semantics**: `allowedSourceTypes` and `allowedTargetTypes` default to `[]` (empty JSON array) in the database. The repository layer must treat `[]` (empty array) as "no restriction" — any node type is a valid endpoint — matching the behavior of `undefined` in the `EdgeType` schema. A non-empty array restricts endpoints to only the listed node types. There is no "no types allowed" state; if edge types need to be disabled, use a status or soft-delete pattern on the edge type definition.
+**Empty array semantics**: `allowedSourceTypes` and `allowedTargetTypes` default
+to `[]` (empty JSON array) in the database. The repository layer must treat `[]`
+(empty array) as "no restriction" — any node type is a valid endpoint — matching
+the behavior of `undefined` in the `EdgeType` schema. A non-empty array
+restricts endpoints to only the listed node types. There is no "no types
+allowed" state; if edge types need to be disabled, use a status or soft-delete
+pattern on the edge type definition.
 
 ### `graphs`
 
 Graph instances. Each graph belongs to a graph type.
 
 | Column      | Type                | Constraints                                   | Notes                                          |
-|--------|------|-------------|-------|
+| ----------- | ------------------- | --------------------------------------------- | ---------------------------------------------- |
 | id          | text                | PK                                            |                                                |
 | metadata    | text (JSON)         | default `{}`                                  |                                                |
 | createdAt   | integer (timestamp) | not null, default `now`                       |                                                |
@@ -135,14 +152,21 @@ Graph instances. Each graph belongs to a graph type.
 | description | text                | default `""`                                  |                                                |
 | status      | text                | not null, enum: `active`, `archived`, `draft` | Default: `draft`                               |
 
-**On `graphTypeId` set null**: When a graph type is deleted, its graphs become orphans with `graphTypeId = null`. The application should prevent graph type deletion if active graphs reference it, or set affected graphs' `status` to `archived` as part of a soft-delete workflow. Orphan graphs cannot validate their node/edge types against a missing type definition — queries against orphan graphs should check for `graphTypeId !== null` before performing type-aware operations.
+**On `graphTypeId` set null**: When a graph type is deleted, its graphs become
+orphans with `graphTypeId = null`. The application should prevent graph type
+deletion if active graphs reference it, or set affected graphs' `status` to
+`archived` as part of a soft-delete workflow. Orphan graphs cannot validate
+their node/edge types against a missing type definition — queries against orphan
+graphs should check for `graphTypeId !== null` before performing type-aware
+operations.
 
 ### `nodes`
 
-Nodes within a graph instance. Keyed by `(graphId, key)` — unique within a graph.
+Nodes within a graph instance. Keyed by `(graphId, key)` — unique within a
+graph.
 
 | Column     | Type                | Constraints                        | Notes                                         |
-|--------|------|-------------|-------|
+| ---------- | ------------------- | ---------------------------------- | --------------------------------------------- |
 | id         | text                | PK                                 |                                               |
 | metadata   | text (JSON)         | default `{}`                       |                                               |
 | createdAt  | integer (timestamp) | not null, default `now`            |                                               |
@@ -153,14 +177,19 @@ Nodes within a graph instance. Keyed by `(graphId, key)` — unique within a gra
 
 **Unique constraint**: `(graphId, key)` — node keys are unique within a graph.
 
-**No `nodeTypeId` column**: Nodes do not have a direct FK to `node_types`. The node type is determined at the application layer. This is a deliberate design decision — adding a `nodeTypeId` FK would couple the graph instance layer to the type definition layer. The repository layer can enforce node type constraints via validation against the graph type's schema.
+**No `nodeTypeId` column**: Nodes do not have a direct FK to `node_types`. The
+node type is determined at the application layer. This is a deliberate design
+decision — adding a `nodeTypeId` FK would couple the graph instance layer to the
+type definition layer. The repository layer can enforce node type constraints
+via validation against the graph type's schema.
 
 ### `edges`
 
-Edges within a graph instance. Keyed by `(graphId, key)` — unique within a graph.
+Edges within a graph instance. Keyed by `(graphId, key)` — unique within a
+graph.
 
 | Column        | Type                | Constraints                        | Notes                                                |
-|--------|------|-------------|-------|
+| ------------- | ------------------- | ---------------------------------- | ---------------------------------------------------- |
 | id            | text                | PK                                 |                                                      |
 | metadata      | text (JSON)         | default `{}`                       |                                                      |
 | createdAt     | integer (timestamp) | not null, default `now`            |                                                      |
@@ -174,14 +203,19 @@ Edges within a graph instance. Keyed by `(graphId, key)` — unique within a gra
 
 **Unique constraint**: `(graphId, key)` — edge keys are unique within a graph.
 
-**Foreign keys**: `sourceNodeKey` and `targetNodeKey` reference `(nodes.graphId, nodes.key)` with cascade delete. Deleting a node removes all its edges.
+**Foreign keys**: `sourceNodeKey` and `targetNodeKey` reference
+`(nodes.graphId, nodes.key)` with cascade delete. Deleting a node removes all
+its edges.
 
 ### `actors`
 
-Standalone identity table. Currently not referenced by any relation. This is a placeholder for the hub's account/identity model and may become a node type in an ACL graph or remain a standalone table. See [overview.md](./overview.md) Open Question 1.
+Standalone identity table. Currently not referenced by any relation. This is a
+placeholder for the hub's account/identity model and may become a node type in
+an ACL graph or remain a standalone table. See [overview.md](./overview.md) Open
+Question 1.
 
 | Column    | Type                | Constraints                             | Notes              |
-|--------|------|-------------|-------|
+| --------- | ------------------- | --------------------------------------- | ------------------ |
 | id        | text                | PK                                      |                    |
 | metadata  | text (JSON)         | default `{}`                            |                    |
 | createdAt | integer (timestamp) | not null, default `now`                 |                    |
@@ -214,7 +248,8 @@ const client = createClient({ url: "file:local.db" });
 const db: SqliteDatabase = createSqliteDatabase(client);
 ```
 
-The factory takes a pre-created `@libsql/client` client and returns a typed Drizzle database instance with the full schema attached. This enables:
+The factory takes a pre-created `@libsql/client` client and returns a typed
+Drizzle database instance with the full schema attached. This enables:
 
 - In-memory testing with `createClient({ url: ":memory:" })`
 - Turso remote connections
@@ -224,62 +259,95 @@ The factory takes a pre-created `@libsql/client` client and returns a typed Driz
 
 ### SD1: JSON text vs. JSONB in SQLite
 
-SQLite stores JSON as `text` with `{ mode: "json" }`. PostgreSQL uses native `jsonb`. This means:
+SQLite stores JSON as `text` with `{ mode: "json" }`. PostgreSQL uses native
+`jsonb`. This means:
 
 - SQLite cannot query inside JSON columns efficiently (no GIN indexes)
 - SQLite JSON validation relies on application-level checks (TypeBox schemas)
 - PostgreSQL will get queryability benefits for JSON columns
 
-The trade-off: SQLite is for spokes (local, infrequent queries), PostgreSQL is for the hub (frequent, complex queries).
+The trade-off: SQLite is for spokes (local, infrequent queries), PostgreSQL is
+for the hub (frequent, complex queries).
 
 ### SD2: No `nodeTypeId` on nodes
 
-Nodes don't carry a direct FK to `node_types`. The node type is enforced at the application layer. Reasons:
+Nodes don't carry a direct FK to `node_types`. The node type is enforced at the
+application layer. Reasons:
 
-- Graph type schemas define which node types are valid. Adding a FK would duplicate this constraint.
+- Graph type schemas define which node types are valid. Adding a FK would
+  duplicate this constraint.
 - Node types can evolve (schemas can change) without requiring node row updates.
-- The repository layer validates node attributes against the appropriate node type schema before insertion.
+- The repository layer validates node attributes against the appropriate node
+  type schema before insertion.
 
-This may change if query performance requires filtering nodes by type. A `nodeTypeId` column can be added as a denormalized index.
+This may change if query performance requires filtering nodes by type. A
+`nodeTypeId` column can be added as a denormalized index.
 
 ### SD3: Edge identity uses consumer-defined keys
 
-Edges use `(graphId, key)` as their unique identity. The `key` is consumer-defined, matching the metagraph model where consumers control identifiers. For anonymous edges (common in simple graphs), `key` can be auto-generated.
+Edges use `(graphId, key)` as their unique identity. The `key` is
+consumer-defined, matching the metagraph model where consumers control
+identifiers. For anonymous edges (common in simple graphs), `key` can be
+auto-generated.
 
 ### SD4: Composite foreign keys for node references
 
-Edges reference nodes via composite FKs: `(graphId, sourceNodeKey) → (nodes.graphId, nodes.key)`. This ensures referential integrity within a graph and cascades node deletions to connected edges.
+Edges reference nodes via composite FKs:
+`(graphId, sourceNodeKey) → (nodes.graphId, nodes.key)`. This ensures
+referential integrity within a graph and cascades node deletions to connected
+edges.
 
 ### SD5: Enum pattern — `as const` objects, not TypeScript enums
 
-All enumerations use the `as const` object pattern (e.g., `GRAPH_STATUS = { Active: "active", ... } as const`) rather than TypeScript `enum`. This matches the `ACTOR_TYPE` pattern in `common.ts` and avoids JSR slow-type issues. The TypeBox schema is a `Type.Union` of `Type.Literal` values derived from the object.
+All enumerations use the `as const` object pattern (e.g.,
+`GRAPH_STATUS = { Active: "active", ... } as const`) rather than TypeScript
+`enum`. This matches the `ACTOR_TYPE` pattern in `common.ts` and avoids JSR
+slow-type issues. The TypeBox schema is a `Type.Union` of `Type.Literal` values
+derived from the object.
 
 ## Metadata Convention
 
-Every table has a `metadata` JSON column defaulting to `{}`. This is an extension namespace for subsystem use, following a namespacing convention: `_subsystem.key` (e.g., `_keypal.scopes`, `_retention.expiresAt`).
+Every table has a `metadata` JSON column defaulting to `{}`. This is an
+extension namespace for subsystem use, following a namespacing convention:
+`_subsystem.key` (e.g., `_keypal.scopes`, `_retention.expiresAt`).
 
-**What metadata is for**: Opaque key-value pairs that subsystems add without schema changes. It's never queried in WHERE clauses or JOINs.
+**What metadata is for**: Opaque key-value pairs that subsystems add without
+schema changes. It's never queried in WHERE clauses or JOINs.
 
-**What metadata is NOT for**: A replacement for typed columns. If a field appears in WHERE clauses, JOIN conditions, or needs a constraint, it should be a proper column — not buried in metadata. When in doubt, add a column.
+**What metadata is NOT for**: A replacement for typed columns. If a field
+appears in WHERE clauses, JOIN conditions, or needs a constraint, it should be a
+proper column — not buried in metadata. When in doubt, add a column.
 
-**Namespacing convention**: Subsystems should prefix their keys (e.g., `_callgraph.payloadRef`, `_acl.inherited`). Unprefixed keys are reserved for the storage package itself.
+**Namespacing convention**: Subsystems should prefix their keys (e.g.,
+`_callgraph.payloadRef`, `_acl.inherited`). Unprefixed keys are reserved for the
+storage package itself.
 
 ## Concurrency Model
 
-The SQLite host targets spoke deployments where a single process accesses the database. For this model, SQLite's default journal mode is sufficient. However, for spoke deployments that may run concurrent writes (e.g., multiple worker threads), consumers should:
+The SQLite host targets spoke deployments where a single process accesses the
+database. For this model, SQLite's default journal mode is sufficient. However,
+for spoke deployments that may run concurrent writes (e.g., multiple worker
+threads), consumers should:
 
-1. **Enable WAL mode**: `PRAGMA journal_mode=WAL;` — allows concurrent reads during writes
+1. **Enable WAL mode**: `PRAGMA journal_mode=WAL;` — allows concurrent reads
-2. **Set busy timeout**: `PRAGMA busy_timeout=5000;` — wait up to 5 seconds for lock acquisition
+   during writes
-3. **Use a single writer**: SQLite supports one writer at a time. If multiple threads write, route writes through a single queue or connection
+2. **Set busy timeout**: `PRAGMA busy_timeout=5000;` — wait up to 5 seconds for
+   lock acquisition
+3. **Use a single writer**: SQLite supports one writer at a time. If multiple
+   threads write, route writes through a single queue or connection
 
-The `createSqliteDatabase()` factory does not set these pragmas — it's the consumer's responsibility to configure the SQLite connection appropriately. The libsql client used to create the connection can be pre-configured before passing it to the factory.
+The `createSqliteDatabase()` factory does not set these pragmas — it's the
+consumer's responsibility to configure the SQLite connection appropriately. The
+libsql client used to create the connection can be pre-configured before passing
+it to the factory.
 
 ## PostgreSQL Porting Notes
 
-When implementing `src/pg/`, the table shapes remain the same but with these changes:
+When implementing `src/pg/`, the table shapes remain the same but with these
+changes:
 
 | SQLite                           | PostgreSQL                               |
-|--------|------------|
+| -------------------------------- | ---------------------------------------- |
 | `sqliteTable`                    | `pgTable`                                |
 | `text` (JSON mode)               | `jsonb` with `.$type<T>()`               |
 | `integer` (timestamp mode)       | `timestamp` with timezone                |
@@ -287,11 +355,14 @@ When implementing `src/pg/`, the table shapes remain the same but with these cha
 | `integer` (boolean mode)         | `boolean`                                |
 | `text` (enum)                    | `pgEnum` or `text` with check constraint |
 
-See hub's `commonCols` reference in [../../hub/docs/architecture/storage/table-reference.md] for the PostgreSQL patterns.
+See hub's `commonCols` reference in
+[../../hub/docs/architecture/storage/table-reference.md] for the PostgreSQL
+patterns.
 
 ## References
 
 - Drizzle ORM SQLite core: https://orm.drizzle.team/docs/sqlite-core
 - libsql client: https://github.com/tursodatabase/libsql
-- Hub common columns pattern: `/workspace/@alkdev/hub/docs/architecture/storage/table-reference.md`
+- Hub common columns pattern:
+  `/workspace/@alkdev/hub/docs/architecture/storage/table-reference.md`
 - Source: `src/sqlite/`

docs/sdd_process.md

@@ -2,9 +2,12 @@
 
 ## Overview
 
-This document defines the SDD process for the @alkdev/storage package. It leverages:
+This document defines the SDD process for the @alkdev/storage package. It
+leverages:
+
 - **OpenCode CLI** as the agent execution environment
-- **Open-coordinator plugin** for worktree management and parallel session orchestration
+- **Open-coordinator plugin** for worktree management and parallel session
+  orchestration
 - **Structured task graphs** with dependency analysis and safe exit protocols
 
 ## Core Principles
@@ -14,29 +17,37 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 3. **Flexible Self**: Agents can implement, self-review, and fix objectively
 4. **Task-Driven**: Structured task graphs with dependency analysis
 5. **Safe Exit**: Always have a way to unblock progress when stuck
-6. **Categorical Estimates**: Use risk/scope/impact categories, not time estimates. These are structurally important — upstream failures multiply downstream damage regardless of developer type (human or LLM). See the cost-benefit framework in taskgraph's framework docs.
+6. **Categorical Estimates**: Use risk/scope/impact categories, not time
+   estimates. These are structurally important — upstream failures multiply
+   downstream damage regardless of developer type (human or LLM). See the
+   cost-benefit framework in taskgraph's framework docs.
 
 ## Workflow Phases
 
 ### Phase 0: Exploration (Conditional)
 
-**When**: Requirements unclear, multiple approaches to evaluate, or hard problems need investigation.
+**When**: Requirements unclear, multiple approaches to evaluate, or hard
+problems need investigation.
 
 **Process**:
+
 1. Capture vision and guiding principles
 2. Research Specialist investigates options (`docs/research/` or external)
 3. POC Specialist validates promising approaches (`.worktrees/research/`)
 4. Document learnings
 5. Converge on recommended approach
 
-**Output**: Clear understanding of WHAT to build and WHY, with validated approaches
+**Output**: Clear understanding of WHAT to build and WHY, with validated
+approaches
 
 ### Phase 1: Architecture
 
 **Objective**: Produce comprehensive, committed architecture specification.
 
 **Process**:
-1. Architect creates modular architecture docs in `docs/architecture/` (Draft status)
+
+1. Architect creates modular architecture docs in `docs/architecture/` (Draft
+   status)
 2. Architecture Review validates for ambiguities, risks
 3. Iterate until zero critical issues
 4. Transition to Stable status
@@ -48,6 +59,7 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 **Objective**: Break architecture into atomic, dependency-ordered tasks.
 
 **Process**:
+
 1. Decomposer analyzes architecture
 2. Creates tasks (markdown files in `tasks/`)
 3. Establishes dependencies between tasks
@@ -61,14 +73,18 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 **Objective**: Execute tasks in dependency order with verification.
 
 **Process**:
+
 1. Coordinator identifies parallelizable work
-2. Coordinator spawns worktrees + sessions (via `worktree({action: "spawn", ...})` or hub `coord.spawn` when available)
+2. Coordinator spawns worktrees + sessions (via
+   `worktree({action: "spawn", ...})` or hub `coord.spawn` when available)
    - Feature work: `.worktrees/feat/<task-id>/` → Implementation Specialist
    - Research POCs: `.worktrees/research/<task-id>/` → POC Specialist
 3. Coordinator injects task context into each session
 4. Agents execute tasks with self-verification
-5. On completion: agent notifies coordinator, updates task status, commits to worktree branch
+5. On completion: agent notifies coordinator, updates task status, commits to
-6. On blocker: Safe Exit protocol, agent notifies coordinator, create blocker task
+   worktree branch
+6. On blocker: Safe Exit protocol, agent notifies coordinator, create blocker
+   task
 7. Merge worktrees back to main when complete
 
 **Output**: Completed, verified implementation
@@ -78,6 +94,7 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 **Objective**: Validate quality and readiness.
 
 **Process**:
+
 1. Code review at injected checkpoints
 2. Final integration testing
 3. Architecture sync check
@@ -96,16 +113,19 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 **Mode**: Primary (interactive with user)
 
 **Tools**:
+
 - Read, Write, Edit, Glob, Grep
 - webSearch (research patterns, best practices)
 
 **Key Behaviors**:
+
 - Focus on WHAT and WHY, never HOW
 - Document decisions with ADR format
 - Redirect exploration work to Research Specialist
 - Iterate based on review feedback
 
 **Deliverables**:
+
 - Modular architecture docs in `docs/architecture/`
 - Component-specific documents
 
@@ -118,15 +138,18 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 **Mode**: Primary (interactive with user for approval)
 
 **Tools**:
+
 - Read, Glob, Grep
 
 **Key Behaviors**:
+
 - Decompose to atomic tasks (single objective, clear acceptance criteria)
 - Establish logical dependencies
 - Validate structure (no cycles, logical ordering)
 - Inject review tasks at critical points
 
 **Deliverables**:
+
 - Task files in `tasks/` directory
 - Dependency graph validated
 
@@ -134,19 +157,27 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 
 #### 3. Coordinator
 
-**Responsibility**: Orchestrate parallel task execution across worktrees and sessions.
+**Responsibility**: Orchestrate parallel task execution across worktrees and
+sessions.
 
 **Mode**: Primary (manages worktrees and agent sessions)
 
-**Uses**: The `worktree` tool from the **open-coordinator** opencode plugin. Single tool with `{action, args}` dispatch. Role is auto-detected — coordinator sessions get the full operation set, spawned implementation sessions get a limited set (current, notify, status). No mode toggle required.
+**Uses**: The `worktree` tool from the **open-coordinator** opencode plugin.
+Single tool with `{action, args}` dispatch. Role is auto-detected — coordinator
+sessions get the full operation set, spawned implementation sessions get a
+limited set (current, notify, status). No mode toggle required.
 
 **Tools**:
-- `worktree({action, args})` — spawn, sessions, dashboard, message, abort, cleanup
+
+- `worktree({action, args})` — spawn, sessions, dashboard, message, abort,
+  cleanup
 - Bash (opencode CLI for session interaction)
 - Read (monitor task files)
-- `memory` / `memory_compact` — context management and session history (via @alkdev/open-memory, when available)
+- `memory` / `memory_compact` — context management and session history (via
+  @alkdev/open-memory, when available)
 
 **Key Behaviors**:
+
 - Identify parallelizable task groups
 - Spawn worktrees + sessions via `worktree({action: "spawn", ...})`
 - Inject task context into sessions
@@ -155,6 +186,7 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 - Merge completed worktrees
 
 **Deliverables**:
+
 - Coordinated parallel execution
 - Blocked task escalation
 - Merged branches
@@ -168,13 +200,16 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 **Mode**: Primary (works on assigned task in worktree)
 
 **Tools**:
+
 - Read, Write, Edit, Glob, Grep, Bash
 - `worktree({action: "notify", ...})` — report progress/blockers to coordinator
 - `worktree({action: "current"})` — verify worktree assignment
 - webSearch (documentation lookup)
-- `memory` / `memory_compact` — context management (via @alkdev/open-memory, when available)
+- `memory` / `memory_compact` — context management (via @alkdev/open-memory,
+  when available)
 
 **Key Behaviors**:
+
 - Load task context (architecture, dependencies)
 - Propose plan before implementing
 - Implement following architecture constraints
@@ -184,6 +219,7 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 - Commit to worktree branch
 
 **Deliverables**:
+
 - Completed task implementation
 - Tests passing
 - Committed changes in worktree
@@ -199,9 +235,11 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 **Mode**: Subagent (invoked by Architect)
 
 **Tools**:
+
 - Read, Grep
 
 **Key Behaviors**:
+
 - Check for undefined terms
 - Identify missing trade-off documentation
 - Validate quality attribute coverage
@@ -216,9 +254,11 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 **Mode**: Subagent (invoked by Coordinator or as task)
 
 **Tools**:
+
 - Read, Grep, Bash (lint, test)
 
 **Key Behaviors**:
+
 - Check adherence to architecture
 - Validate patterns and conventions
 - Run linters and tests
@@ -233,10 +273,12 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 **Mode**: Subagent (invoked by any role)
 
 **Tools**:
+
 - Read, Write, Glob
 - webSearch (primary research tool)
 
 **Key Behaviors**:
+
 - Find and summarize documentation
 - Evaluate library alternatives
 - Document findings
@@ -245,17 +287,20 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 
 #### 8. POC Specialist
 
-**Responsibility**: Create proof-of-concepts to validate technical approaches before production implementation.
+**Responsibility**: Create proof-of-concepts to validate technical approaches
+before production implementation.
 
 **Mode**: Primary (works in isolated research worktree)
 
 **Worktree Location**: `.worktrees/research/<task-id>/`
 
 **Tools**:
+
 - Read, Write, Edit, Glob, Grep, Bash
 - webSearch (implementation references)
 
 **Key Behaviors**:
+
 - Create minimal POCs to validate hypotheses
 - Work in isolated research worktrees
 - Document findings and recommendations
@@ -263,11 +308,13 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 - Be honest about limitations and blockers
 
 **When Invoked**:
+
 - After Research Specialist completes initial research
 - When a technical approach needs validation before commitment
 - When integration complexity or performance is uncertain
 
 **Deliverables**:
+
 - Working POC code
 - Findings document with recommendation (proceed/pivot/block)
 - Updated research task with results
@@ -276,7 +323,8 @@ This document defines the SDD process for the @alkdev/storage package. It levera
 
 ## Task File Format
 
-Tasks are markdown files stored in `tasks/`. Since they're in the repo, they're automatically available in worktrees.
+Tasks are markdown files stored in `tasks/`. Since they're in the repo, they're
+automatically available in worktrees.
 
 ```markdown
 ---
@@ -306,21 +354,25 @@ Implement OAuth2 authentication with provider abstraction.
 
 ## Notes
 
-> Agent fills this during implementation. Document any decisions,
+> Agent fills this during implementation. Document any decisions, deviations
-> deviations from architecture, or relevant context discovered.
+> from architecture, or relevant context discovered.
 
 ## Summary
 
-> Agent fills this on completion. Brief description of what was
+> Agent fills this on completion. Brief description of what was implemented,
-> implemented, files changed, and any follow-up needed.
+> files changed, and any follow-up needed.
 ```
 
 ### Categorical Estimates
 
-These fields are structurally important, not optional metadata. They power `taskgraph decompose`, `risk-path`, `critical`, and `bottleneck` — commands that reveal structural problems in the task graph. A task missing `scope`, `risk`, `impact`, or `level` is a red flag indicating incomplete decomposition. See the cost-benefit framework in taskgraph's framework docs for the reasoning.
+These fields are structurally important, not optional metadata. They power
+`taskgraph decompose`, `risk-path`, `critical`, and `bottleneck` — commands that
+reveal structural problems in the task graph. A task missing `scope`, `risk`,
+`impact`, or `level` is a red flag indicating incomplete decomposition. See the
+cost-benefit framework in taskgraph's framework docs for the reasoning.
 
 | Scope    | Description                  | Example                   |
-|-------|-------------|---------|
+| -------- | ---------------------------- | ------------------------- |
 | single   | One function, one file       | Add validation helper     |
 | narrow   | One component, few files     | Implement auth middleware |
 | moderate | Feature, multiple components | Build user API endpoints  |
@@ -328,7 +380,7 @@ These fields are structurally important, not optional metadata. They power `task
 | system   | Cross-cutting changes        | Database migration        |
 
 | Risk     | Failure Likelihood        |
-|------|-------------------|
+| -------- | ------------------------- |
 | trivial  | Nearly impossible to fail |
 | low      | Standard implementation   |
 | medium   | Some uncertainty          |
@@ -337,9 +389,11 @@ These fields are structurally important, not optional metadata. They power `task
 
 ### Task Lifecycle
 
-**Status values**: `pending` → `in-progress` → `completed` | `blocked` | `failed`
+**Status values**: `pending` → `in-progress` → `completed` | `blocked` |
+`failed`
 
 **On completion**, the agent:
+
 1. Updates `status: completed`
 2. Fills in `## Summary` section
 3. Commits changes to worktree branch
@@ -351,10 +405,12 @@ When a task becomes untendable:
 ### Criteria
 
 **Hard Criteria** (automatic):
+
 - Same task fails verification 3+ times
 - Task attempts exceed 5+ total
 
 **Soft Criteria** (agent judgment):
+
 - Ambiguous architecture
 - Missing dependencies
 - External library incompatibility
@@ -372,7 +428,7 @@ When a task becomes untendable:
 Use graph analysis to determine where reviews should happen:
 
 | Analysis         | Injection Point              |
-|----------|-----------------|
+| ---------------- | ---------------------------- |
 | Parallel groups  | Review before groups merge   |
 | Bottleneck tasks | Review before critical path  |
 | High-risk tasks  | Review before proceeding     |
@@ -382,7 +438,9 @@ Use graph analysis to determine where reviews should happen:
 
 ### Current (open-coordinator plugin)
 
-The Coordinator uses the `worktree` tool from the open-coordinator opencode plugin. It's a single tool with `{action, args}` dispatch — no separate enable/toggle steps. Role is auto-detected from session state.
+The Coordinator uses the `worktree` tool from the open-coordinator opencode
+plugin. It's a single tool with `{action, args}` dispatch — no separate
+enable/toggle steps. Role is auto-detected from session state.
 
 ```
 1. Identify parallel work
@@ -413,11 +471,13 @@ The Coordinator uses the `worktree` tool from the open-coordinator opencode plug
    worktree({action: "cleanup", args: {action: "remove", pathOrBranch: "feat/auth-setup"}})
 ```
 
-The plugin also provides SSE-based anomaly detection (model degradation, high error count, session stall) with automatic notifications to the coordinator.
+The plugin also provides SSE-based anomaly detection (model degradation, high
+error count, session stall) with automatic notifications to the coordinator.
 
 ### Implementation Agent Operations
 
-Spawned sessions (implementation specialists, code reviewers, POC specialists) get a limited worktree interface:
+Spawned sessions (implementation specialists, code reviewers, POC specialists)
+get a limited worktree interface:
 
 ```text
 worktree({action: "current"})                              → Show worktree mapping
@@ -425,17 +485,24 @@ worktree({action: "notify", args: {message: "...", level: "info|blocking"}})
 worktree({action: "status"})                                 → Show worktree git status
 ```
 
-The plugin auto-injects `workdir` for bash commands when a session is mapped to a worktree.
+The plugin auto-injects `workdir` for bash commands when a session is mapped to
+a worktree.
 
 ### Context & Memory (with @alkdev/open-memory)
 
-When the open-memory plugin is available alongside open-coordinator, the coordinator gains:
+When the open-memory plugin is available alongside open-coordinator, the
-- `memory({tool: "children", args: {sessionId: "..."}})` — view sub-agent sessions spawned from the coordinator
+coordinator gains:
-- `memory({tool: "messages", args: {sessionId: "..."}})` — read a spawned session's conversation for debugging
+
-- `memory({tool: "context"})` — check context window usage before long monitoring sessions
+- `memory({tool: "children", args: {sessionId: "..."}})` — view sub-agent
+  sessions spawned from the coordinator
+- `memory({tool: "messages", args: {sessionId: "..."}})` — read a spawned
+  session's conversation for debugging
+- `memory({tool: "context"})` — check context window usage before long
+  monitoring sessions
 - `memory_compact()` — proactively compact at natural breakpoints
 
-Implementation agents can also use `memory({tool: "context"})` and `memory_compact()` to manage their context during long tasks.
+Implementation agents can also use `memory({tool: "context"})` and
+`memory_compact()` to manage their context during long tasks.
 
 ### Future (Hub Operations)
 
@@ -455,7 +522,9 @@ Once the hub is operational, coordination uses native operations:
    hub.call("coord.abort", { sessionId })
 ```
 
-State moves from in-process tracking to Postgres `mappings` table. The open-coordinator plugin becomes unnecessary — the hub provides the same capabilities as server-side operations accessible from any environment.
+State moves from in-process tracking to Postgres `mappings` table. The
+open-coordinator plugin becomes unnecessary — the hub provides the same
+capabilities as server-side operations accessible from any environment.
 
 ## Document Structure
 

scripts/analyze_lint.ts

@@ -1,4 +1,3 @@
-
 import { parse } from "@std/flags";
 import * as path from "@std/path";
 
@@ -37,19 +36,19 @@ interface Stats {
 
 function filterDiagnostics(
   diagnostics: LintDiagnostic[],
-  options: FilterOptions
+  options: FilterOptions,
 ): LintDiagnostic[] {
   let result = diagnostics;
 
   if (options.codes) {
     const codes = new Set(options.codes);
-    result = result.filter(d => codes.has(d.code));
+    result = result.filter((d) => codes.has(d.code));
   }
 
   if (options.files) {
-    const filePatterns = options.files.map(f => new RegExp(f));
+    const filePatterns = options.files.map((f) => new RegExp(f));
-    result = result.filter(d => 
+    result = result.filter((d) =>
-      filePatterns.some(pattern => pattern.test(d.filename))
+      filePatterns.some((pattern) => pattern.test(d.filename))
     );
   }
 
@@ -58,7 +57,7 @@ function filterDiagnostics(
 
 function groupDiagnostics(
   diagnostics: LintDiagnostic[],
-  groupBy: "code" | "file"
+  groupBy: "code" | "file",
 ): Record<string, LintDiagnostic[]> {
   const groups: Record<string, LintDiagnostic[]> = {};
 
@@ -86,7 +85,7 @@ function calculateStats(diagnostics: LintDiagnostic[]): Stats {
     total: diagnostics.length,
     byCode,
     byFile,
-    filesWithIssues: Object.keys(byFile).length
+    filesWithIssues: Object.keys(byFile).length,
   };
 }
 
@@ -113,22 +112,26 @@ function printStats(stats: Stats, topN: number = 10) {
 function printGroupedDiagnostics(
   groups: Record<string, LintDiagnostic[]>,
   groupBy: "code" | "file",
-  limit?: number
+  limit?: number,
 ) {
   const sortedEntries = Object.entries(groups).sort(
-    (a, b) => b[1].length - a[1].length
+    (a, b) => b[1].length - a[1].length,
   );
 
   const entriesToShow = limit ? sortedEntries.slice(0, limit) : sortedEntries;
 
   for (const [key, diagnostics] of entriesToShow) {
-    console.log(`\n${groupBy.toUpperCase()}: ${key} (${diagnostics.length} issues)`);
+    console.log(
+      `\n${groupBy.toUpperCase()}: ${key} (${diagnostics.length} issues)`,
+    );
     // Show first 5 issues for each group to avoid overwhelming output
     const issuesToShow = Math.min(5, diagnostics.length);
     for (let i = 0; i < issuesToShow; i++) {
       const diag = diagnostics[i];
       console.log(
-        `  ${path.basename(diag.filename)}:${diag.range.start.line + 1}:${diag.range.start.col + 1} - ${diag.message}`
+        `  ${path.basename(diag.filename)}:${diag.range.start.line + 1}:${
+          diag.range.start.col + 1
+        } - ${diag.message}`,
       );
     }
     if (diagnostics.length > issuesToShow) {
@@ -167,11 +170,11 @@ async function main() {
       g: "group",
       h: "help",
       s: "stats",
-      l: "limit"
+      l: "limit",
     },
     string: ["file", "code", "group"],
     boolean: ["help", "stats"],
-    default: { limit: 0 } // 0 means no limit
+    default: { limit: 0 }, // 0 means no limit
   });
 
   if (args.help) {
@@ -210,18 +213,16 @@ Examples:
   // Apply filters
   const filterOptions: FilterOptions = {};
   if (args.code) {
-    filterOptions.codes = args.code.split(",").map(c => c.trim());
+    filterOptions.codes = args.code.split(",").map((c) => c.trim());
   }
   if (args.file) {
     // Handle multiple file patterns
-    filterOptions.files = Array.isArray(args.file) 
+    filterOptions.files = Array.isArray(args.file) ? args.file : [args.file];
-      ? args.file 
-      : [args.file];
   }
 
   const filteredDiagnostics = filterDiagnostics(
     lintResult.diagnostics,
-    filterOptions
+    filterOptions,
   );
 
   // Show statistics if requested
@@ -232,15 +233,24 @@ Examples:
 
   // Group or show all diagnostics
   if (args.group) {
-    const groups = groupDiagnostics(filteredDiagnostics, args.group as "code" | "file");
+    const groups = groupDiagnostics(
-    printGroupedDiagnostics(groups, args.group as "code" | "file", (args.limit as number) || undefined);
+      filteredDiagnostics,
+      args.group as "code" | "file",
+    );
+    printGroupedDiagnostics(
+      groups,
+      args.group as "code" | "file",
+      (args.limit as number) || undefined,
+    );
   } else if (!args.stats) {
     // Only show JSON output if neither stats nor grouping is requested
     console.log(JSON.stringify({ diagnostics: filteredDiagnostics }, null, 2));
   }
 
   if (!args.stats) {
-    console.log(`\nFound ${filteredDiagnostics.length} issues matching criteria`);
+    console.log(
+      `\nFound ${filteredDiagnostics.length} issues matching criteria`,
+    );
   }
 }
 

src/graphs/schemaBuilder.ts

@@ -1,7 +1,7 @@
 import { KindGuard, type TSchema } from "@alkdev/typebox";
 import { Value } from "@alkdev/typebox/value";
 import { assert } from "@std/assert";
-import { GraphSchema, GraphConfig, NodeType, EdgeType } from "./types.ts";
+import { EdgeType, GraphConfig, GraphSchema, NodeType } from "./types.ts";
 
 export class SchemaBuilder {
   private schema: {
@@ -22,7 +22,10 @@ export class SchemaBuilder {
   }
 
   nodeType(name: string, schema: TSchema): SchemaBuilder {
-    assert(KindGuard.IsSchema(schema), `type '${name}' is not a valid json schema.`);
+    assert(
+      KindGuard.IsSchema(schema),
+      `type '${name}' is not a valid json schema.`,
+    );
 
     if (!this.schema.nodeTypes) this.schema.nodeTypes = {};
     const nodeTypeObj: NodeType = { name, schema };
@@ -37,7 +40,10 @@ export class SchemaBuilder {
     schema: TSchema,
     options?: { allowedSourceTypes?: string[]; allowedTargetTypes?: string[] },
   ): SchemaBuilder {
-    assert(KindGuard.IsSchema(schema), `type '${name}' is not a valid json schema.`);
+    assert(
+      KindGuard.IsSchema(schema),
+      `type '${name}' is not a valid json schema.`,
+    );
 
     if (!this.schema.edgeTypes) this.schema.edgeTypes = {};
     const edgeTypeObj: EdgeType = { name, schema, ...options };
@@ -51,7 +57,9 @@ export class SchemaBuilder {
     if (!Value.Check(schema, value)) {
       const errors = [...Value.Errors(schema, value)];
       throw new Error(
-        `Invalid schema structure: ${JSON.stringify(errors.map((e) => `${e.path}: ${e.message}`))}`,
+        `Invalid schema structure: ${
+          JSON.stringify(errors.map((e) => `${e.path}: ${e.message}`))
+        }`,
       );
     }
   }

src/graphs/types.ts

@@ -1,4 +1,4 @@
-import { Type, type Static, type TSchema } from "@alkdev/typebox";
+import { type Static, type TSchema, Type } from "@alkdev/typebox";
 
 export const BaseNodeAttributes: TSchema = Type.Object({
   created: Type.Optional(Type.String({ format: "date-time" })),
@@ -70,7 +70,8 @@ export const GRAPH_BASE_TYPE = {
   Mixed: "mixed",
 } as const;
 
-export type GraphBaseType = (typeof GRAPH_BASE_TYPE)[keyof typeof GRAPH_BASE_TYPE];
+export type GraphBaseType =
+  (typeof GRAPH_BASE_TYPE)[keyof typeof GRAPH_BASE_TYPE];
 export const GraphBaseType: TSchema = Type.Union([
   Type.Literal(GRAPH_BASE_TYPE.Directed),
   Type.Literal(GRAPH_BASE_TYPE.Undirected),

src/sqlite/relations.ts

@@ -1,11 +1,11 @@
 import { relations } from "drizzle-orm";
 import {
-  graphTypes,
+  edges,
-  nodeTypes,
   edgeTypes,
   graphs,
+  graphTypes,
   nodes,
-  edges,
+  nodeTypes,
 } from "./tables/index.ts";
 
 export const graphTypeRelations = relations(graphTypes, ({ many }) => ({

src/sqlite/tables/actors.ts

@@ -1,7 +1,7 @@
 import { sqliteTable, text } from "drizzle-orm/sqlite-core";
 import { createInsertSchema, createSelectSchema } from "@alkdev/drizzlebox";
-import { Type, type Static } from "@alkdev/typebox";
+import { type Static, Type } from "@alkdev/typebox";
-import { commonCols, ACTOR_TYPE } from "./common.ts";
+import { ACTOR_TYPE, commonCols } from "./common.ts";
 
 export const actors = sqliteTable("actors", {
   ...commonCols,

src/sqlite/tables/common.ts

@@ -1,9 +1,10 @@
 import { sql } from "drizzle-orm";
-import { text, integer } from "drizzle-orm/sqlite-core";
+import { integer, text } from "drizzle-orm/sqlite-core";
 
 export const commonCols = {
   id: text("id").primaryKey(),
-  metadata: text("metadata", { mode: "json" }).$type<Record<string, unknown>>().default({}),
+  metadata: text("metadata", { mode: "json" }).$type<Record<string, unknown>>()
+    .default({}),
   createdAt: integer("created_at", { mode: "timestamp" })
     .default(sql`(strftime('%s', 'now'))`)
     .notNull(),

src/sqlite/tables/edgeTypes.ts

@@ -1,17 +1,24 @@
 import { sqliteTable, text, unique } from "drizzle-orm/sqlite-core";
 import { createInsertSchema, createSelectSchema } from "@alkdev/drizzlebox";
-import { Type, type Static } from "@alkdev/typebox";
+import { type Static, Type } from "@alkdev/typebox";
 import { commonCols } from "./common.ts";
 import { graphTypes } from "./graphTypes.ts";
 
 export const edgeTypes = sqliteTable("edge_types", {
   ...commonCols,
-  graphTypeId: text("graph_type_id").notNull().references(() => graphTypes.id, { onDelete: "cascade" }),
+  graphTypeId: text("graph_type_id").notNull().references(() => graphTypes.id, {
+    onDelete: "cascade",
+  }),
   name: text("name").notNull(),
   description: text("description").default(""),
-  schema: text("schema", { mode: "json" }).$type<Record<string, unknown>>().notNull(),
+  schema: text("schema", { mode: "json" }).$type<Record<string, unknown>>()
-  allowedSourceTypes: text("allowed_source_types", { mode: "json" }).$type<string[]>().default([]),
+    .notNull(),
-  allowedTargetTypes: text("allowed_target_types", { mode: "json" }).$type<string[]>().default([]),
+  allowedSourceTypes: text("allowed_source_types", { mode: "json" }).$type<
+    string[]
+  >().default([]),
+  allowedTargetTypes: text("allowed_target_types", { mode: "json" }).$type<
+    string[]
+  >().default([]),
 }, (table) => ({
   graphTypeNameIdx: unique().on(table.graphTypeId, table.name),
 }));

src/sqlite/tables/edges.ts

@@ -1,6 +1,12 @@
-import { sqliteTable, text, integer, unique, foreignKey } from "drizzle-orm/sqlite-core";
+import {
+  foreignKey,
+  integer,
+  sqliteTable,
+  text,
+  unique,
+} from "drizzle-orm/sqlite-core";
 import { createInsertSchema, createSelectSchema } from "@alkdev/drizzlebox";
-import { Type, type Static } from "@alkdev/typebox";
+import { type Static, Type } from "@alkdev/typebox";
 import { commonCols } from "./common.ts";
 import { graphs } from "./graphs.ts";
 import { nodes } from "./nodes.ts";
@@ -9,7 +15,9 @@ const AttributesSchema = Type.Record(Type.String(), Type.Any());
 
 export const edges = sqliteTable("edges", {
   ...commonCols,
-  graphId: text("graph_id").notNull().references(() => graphs.id, { onDelete: "cascade" }),
+  graphId: text("graph_id").notNull().references(() => graphs.id, {
+    onDelete: "cascade",
+  }),
   key: text("key"),
   sourceNodeKey: text("source_node_key").notNull(),
   targetNodeKey: text("target_node_key").notNull(),

src/sqlite/tables/graphTypes.ts

@@ -1,8 +1,8 @@
-import { sqliteTable, text, integer } from "drizzle-orm/sqlite-core";
+import { integer, sqliteTable, text } from "drizzle-orm/sqlite-core";
 import { createInsertSchema, createSelectSchema } from "@alkdev/drizzlebox";
-import { Type, type Static } from "@alkdev/typebox";
+import { type Static, Type } from "@alkdev/typebox";
 import { commonCols } from "./common.ts";
-import { GraphConfig } from "../../graphs/types.ts";
+import type { GraphConfig } from "../../graphs/types.ts";
 
 type GraphConfigType = Static<typeof GraphConfig>;
 

src/sqlite/tables/graphs.ts

@@ -1,13 +1,15 @@
 import { sqliteTable, text } from "drizzle-orm/sqlite-core";
 import { createInsertSchema, createSelectSchema } from "@alkdev/drizzlebox";
-import { Type, type Static } from "@alkdev/typebox";
+import { type Static, Type } from "@alkdev/typebox";
 import { commonCols } from "./common.ts";
 import { graphTypes } from "./graphTypes.ts";
 import { GRAPH_STATUS } from "../../graphs/types.ts";
 
 export const graphs = sqliteTable("graphs", {
   ...commonCols,
-  graphTypeId: text("graph_type_id").references(() => graphTypes.id, { onDelete: "set null" }),
+  graphTypeId: text("graph_type_id").references(() => graphTypes.id, {
+    onDelete: "set null",
+  }),
   name: text("name").notNull(),
   description: text("description").default(""),
   status: text("status", { enum: ["active", "archived", "draft"] })

src/sqlite/tables/index.ts

@@ -1,23 +1,41 @@
 export { graphs } from "./graphs.ts";
-export type { SelectGraph, InsertGraph } from "./graphs.ts";
+export type { InsertGraph, SelectGraph } from "./graphs.ts";
-export { SelectGraph as SelectGraphSchema, InsertGraph as InsertGraphSchema } from "./graphs.ts";
+export {
+  InsertGraph as InsertGraphSchema,
+  SelectGraph as SelectGraphSchema,
+} from "./graphs.ts";
 export { nodes } from "./nodes.ts";
-export type { SelectNode, InsertNode } from "./nodes.ts";
+export type { InsertNode, SelectNode } from "./nodes.ts";
-export { SelectNodeSchema, InsertNodeSchema } from "./nodes.ts";
+export { InsertNodeSchema, SelectNodeSchema } from "./nodes.ts";
 export { edges } from "./edges.ts";
-export type { SelectEdge, InsertEdge } from "./edges.ts";
+export type { InsertEdge, SelectEdge } from "./edges.ts";
-export { SelectEdge as SelectEdgeSchema, InsertEdge as InsertEdgeSchema } from "./edges.ts";
+export {
+  InsertEdge as InsertEdgeSchema,
+  SelectEdge as SelectEdgeSchema,
+} from "./edges.ts";
 export { graphTypes } from "./graphTypes.ts";
-export type { SelectGraphType, InsertGraphType } from "./graphTypes.ts";
+export type { InsertGraphType, SelectGraphType } from "./graphTypes.ts";
-export { SelectGraphType as SelectGraphTypeSchema, InsertGraphType as InsertGraphTypeSchema } from "./graphTypes.ts";
+export {
+  InsertGraphType as InsertGraphTypeSchema,
+  SelectGraphType as SelectGraphTypeSchema,
+} from "./graphTypes.ts";
 export { nodeTypes } from "./nodeTypes.ts";
-export type { SelectNodeType, InsertNodeType } from "./nodeTypes.ts";
+export type { InsertNodeType, SelectNodeType } from "./nodeTypes.ts";
-export { SelectNodeType as SelectNodeTypeSchema, InsertNodeType as InsertNodeTypeSchema } from "./nodeTypes.ts";
+export {
+  InsertNodeType as InsertNodeTypeSchema,
+  SelectNodeType as SelectNodeTypeSchema,
+} from "./nodeTypes.ts";
 export { edgeTypes } from "./edgeTypes.ts";
-export type { SelectEdgeType, InsertEdgeType } from "./edgeTypes.ts";
+export type { InsertEdgeType, SelectEdgeType } from "./edgeTypes.ts";
-export { SelectEdgeType as SelectEdgeTypeSchema, InsertEdgeType as InsertEdgeTypeSchema } from "./edgeTypes.ts";
+export {
+  InsertEdgeType as InsertEdgeTypeSchema,
+  SelectEdgeType as SelectEdgeTypeSchema,
+} from "./edgeTypes.ts";
 export { actors } from "./actors.ts";
-export type { SelectActor, InsertActor } from "./actors.ts";
+export type { InsertActor, SelectActor } from "./actors.ts";
-export { SelectActor as SelectActorSchema, InsertActor as InsertActorSchema } from "./actors.ts";
+export {
-export { commonCols, ACTOR_TYPE } from "./common.ts";
+  InsertActor as InsertActorSchema,
+  SelectActor as SelectActorSchema,
+} from "./actors.ts";
+export { ACTOR_TYPE, commonCols } from "./common.ts";
 export type { EnumValues } from "./common.ts";

src/sqlite/tables/nodeTypes.ts

@@ -1,15 +1,18 @@
 import { sqliteTable, text, unique } from "drizzle-orm/sqlite-core";
 import { createInsertSchema, createSelectSchema } from "@alkdev/drizzlebox";
-import { Type, type Static } from "@alkdev/typebox";
+import { type Static, Type } from "@alkdev/typebox";
 import { commonCols } from "./common.ts";
 import { graphTypes } from "./graphTypes.ts";
 
 export const nodeTypes = sqliteTable("node_types", {
   ...commonCols,
-  graphTypeId: text("graph_type_id").notNull().references(() => graphTypes.id, { onDelete: "cascade" }),
+  graphTypeId: text("graph_type_id").notNull().references(() => graphTypes.id, {
+    onDelete: "cascade",
+  }),
   name: text("name").notNull(),
   description: text("description").default(""),
-  schema: text("schema", { mode: "json" }).$type<Record<string, unknown>>().notNull(),
+  schema: text("schema", { mode: "json" }).$type<Record<string, unknown>>()
+    .notNull(),
 }, (table) => ({
   graphTypeNameIdx: unique().on(table.graphTypeId, table.name),
 }));

src/sqlite/tables/nodes.ts

@@ -1,6 +1,6 @@
 import { sqliteTable, text, unique } from "drizzle-orm/sqlite-core";
 import { createInsertSchema, createSelectSchema } from "@alkdev/drizzlebox";
-import { Type, type Static } from "@alkdev/typebox";
+import { type Static, Type } from "@alkdev/typebox";
 import { commonCols } from "./common.ts";
 import { graphs } from "./graphs.ts";
 
@@ -8,7 +8,9 @@ const AttributesSchema = Type.Record(Type.String(), Type.Any());
 
 export const nodes = sqliteTable("nodes", {
   ...commonCols,
-  graphId: text("graph_id").notNull().references(() => graphs.id, { onDelete: "cascade" }),
+  graphId: text("graph_id").notNull().references(() => graphs.id, {
+    onDelete: "cascade",
+  }),
   key: text("key").notNull(),
   attributes: text("attributes", { mode: "json" }).notNull().default({}),
 }, (table) => ({