@codyswann/lisa 1.29.1 → 1.30.0

package/all/copy-overwrite/.claude/agents/spec-analyst.md

@@ -0,0 +1,41 @@
+---
+name: spec-analyst
+description: Analyzes requirements for ambiguities, missing details, and unstated assumptions. Outputs clarifying questions ranked by architectural impact.
+tools: Read, Grep, Glob
+model: sonnet
+---
+
+# Specification Gap Analyst
+
+Find every gap in requirements before implementation begins -- not after. Surface questions so the team lead can ask the user. Never answer questions on behalf of the user.
+
+## Focus Areas
+
+Analyze the input for gaps in these categories:
+
+1. **Technology/language choice** -- Is the language, framework, or runtime specified? If project context makes it obvious, note that instead of asking.
+2. **Scale and performance** -- Expected limits? (input size, concurrency, throughput)
+3. **Input/output format** -- What format does input arrive in? What format should output be? (CLI args, JSON, file, stdin/stdout)
+4. **Error handling** -- What should happen on invalid input? (throw, return null, log and continue, exit code)
+5. **Target audience** -- Who will use this? (developers via API, end users via CLI, automated systems)
+6. **Deployment context** -- Where does this run? (local, CI, server, browser, container)
+7. **Integration points** -- Does this need to work with existing code, APIs, or databases?
+8. **Edge cases** -- What happens at boundaries? (zero, negative, very large, empty, null)
+9. **Naming and location** -- Where should new files live? What naming conventions apply?
+10. **Acceptance criteria** -- How do we know this is "done"? What does success look like?
+
+## Output Format
+
+Return a numbered list of clarifying questions sorted by impact level (high first). For each question:
+
+- State the question clearly (one sentence)
+- Explain why it matters (one sentence -- what could go wrong if assumed incorrectly)
+- Note the impact level: **high** (affects architecture), **medium** (affects implementation), **low** (affects polish)
+
+## Rules
+
+- Never assume defaults for ambiguous requirements -- surface the ambiguity
+- Never answer questions on behalf of the user
+- Flag every gap, even if it seems obvious -- what's obvious to an engineer may not be what the user intended
+- Use project context (`package.json`, existing code patterns, `CLAUDE.md`) to avoid asking questions the project has already answered
+- Be concise -- one sentence per question, one sentence for why it matters

package/all/copy-overwrite/.claude/rules/plan.md

@@ -10,18 +10,23 @@ When making a plan:
 - Verify correct versions of third-party libraries
 - Look for reusable code
 - If a decision is left unresolved by the human, use the recommended option
-- The plan MUST include TaskCreate instructions for each task (following the Task Creation Specification below). Specify that subagents should handle as many tasks in parallel as possible.
+- The plan MUST include TaskCreate instructions for each task (following the Task Creation Specification below)
+- Specify that subagents should handle as many tasks in parallel as possible
+
+Do NOT include separate tasks for linting, type-checking, or formatting. These are handled automatically by PostToolUse hooks and lint-staged pre-commit hooks.
+
+IMPORTANT: The `## Sessions` section in plan files is auto-maintained by `track-plan-sessions.sh` -- do not manually edit it.
 
 ### Required Tasks
 
 The following tasks are always required unless the plan includes only trivial changes:
 
-- Product/UX review using `product-reviewer` agent (validate feature works from a non-technical perspective)
+- Product/UX review using `product-reviewer` agent
 - CodeRabbit code review
 - Local code review via `/plan-local-code-review`
-- Technical review using `tech-reviewer` agent (beginner-friendly; correctness, security, performance)
+- Technical review using `tech-reviewer` agent
 - Implement valid review suggestions (run after all reviews complete)
-- Simplify code using code simplifier agent (run after review implementation)
+- Simplify code using `code-simplifier` agent (run after review implementation)
 - Update/add/remove tests as needed (run after review implementation)
 - Update/add/remove documentation -- JSDoc, markdown files, etc. (run after review implementation)
 - Verify all verification metadata in existing tasks (run after review implementation)
@@ -29,14 +34,27 @@ The following tasks are always required unless the plan includes only trivial ch
 
 The following task is always required regardless of plan size:
 
-- Archive the plan (run after all other tasks). This task must explicitly say to:
-  - Create a folder named `<plan-name>` in `./plans/completed`
-  - Rename the plan to reflect its actual contents
-  - Move it into `./plans/completed/<plan-name>`
-  - Read session IDs from `./plans/completed/<plan-name>`
-  - Move each `~/.claude/tasks/<session-id>` directory to `./plans/completed/<plan-name>/tasks`
-  - Update any "in_progress" task to "completed"
-  - Commit and push changes to the PR
+- **Archive the plan** (run after all other tasks). See the Archive Procedure section below for the full steps this task must include.
+
+### Archive Procedure
+
+The archive task must follow these steps exactly. All file operations MUST use `mv` via Bash -- never use Write, Edit, or copy tools, as they overwrite the `## Sessions` table maintained by `track-plan-sessions.sh`.
+
+1. Create destination folder: `mkdir -p ./plans/completed/<plan-name>`
+2. Rename the plan file to reflect its actual contents
+3. Move the plan file: `mv plans/<plan-file>.md ./plans/completed/<plan-name>/<renamed>.md`
+4. Verify source is gone: `! ls plans/<plan-file>.md 2>/dev/null && echo "Source removed"`
+5. Parse session IDs from the `## Sessions` table in the moved plan file
+6. Move each task directory: `mv ~/.claude/tasks/<session-id> ./plans/completed/<plan-name>/tasks/`
+   - **Fallback** (if Sessions table is empty): `grep -rl '"plan": "<plan-name>"' ~/.claude/tasks/*/` and move parent directories of matches
+7. Update any `in_progress` tasks to `completed` via TaskUpdate
+8. Final git operations:
+   ```bash
+   git add . && git commit -m "chore: archive <plan-name> plan"
+   GIT_SSH_COMMAND="ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5" git push
+   gh pr ready
+   gh pr merge --auto --merge
+   ```
 
 ### Branch and PR Rules
 
@@ -54,31 +72,27 @@ When referencing a ticket (JIRA, Linear, etc.):
 - Update the ticket with the working branch
 - Add a comment on the ticket with the finalized plan
 
-NOTE: Do NOT include a separate task for linting, type-checking, or formatting. These are handled automatically by PostToolUse hooks (lint-on-edit.sh, format-on-edit.sh) and lint-staged pre-commit hooks (ESLint, Prettier, ast-grep).
-
-IMPORTANT: The `## Sessions` section in plan files is auto-maintained by `track-plan-sessions.sh` -- do not manually edit it.
-
 ## Git Workflow
 
 Every plan follows this workflow to keep PRs clean:
 
 1. **First task:** Verify/create branch and open a draft PR (`gh pr create --draft`). No implementation before the draft PR exists.
 2. **During implementation:** Commits only, no pushes. Pre-commit hooks validate lint, format, and typecheck.
-3. **After archive task:** One final `git push`, then mark PR ready (`gh pr ready`), then enable auto-merge (`gh pr merge --auto --merge`).
+3. **After archive task:** One final push, then mark PR ready, then enable auto-merge (see Archive Procedure step 8).
 
 ## Implementation Team Guidance
 
 When plans spawn an Agent Team for implementation, recommend these specialized agents:
 
-| Agent | Use For | Why |
-|-------|---------|-----|
-| `implementer` | Code implementation | Pre-loaded with project conventions, empirical verification |
-| `tech-reviewer` | Technical review | Beginner-friendly findings; covers correctness, security, performance |
-| `product-reviewer` | Product/UX review | Validates from non-technical perspective; runs feature empirically |
-| `learner` | Post-implementation learning | Processes task learnings through `skill-evaluator` to create skills, add rules, or discard |
-| `test-coverage-agent` | Writing tests | Specialized for comprehensive, meaningful test coverage |
-| `code-simplifier` (plugin) | Code simplification | Simplifies and refines for clarity and maintainability |
-| `coderabbit` (plugin) | CodeRabbit review | Automated AI code review |
+| Agent | Use For |
+|-------|---------|
+| `implementer` | Code implementation (pre-loaded with project conventions) |
+| `tech-reviewer` | Technical review (correctness, security, performance) |
+| `product-reviewer` | Product/UX review (validates from non-technical perspective) |
+| `learner` | Post-implementation learning (processes learnings into skills/rules) |
+| `test-coverage-agent` | Writing comprehensive, meaningful tests |
+| `code-simplifier` (plugin) | Code simplification and refinement |
+| `coderabbit` (plugin) | Automated AI code review |
 
 The **team lead** handles git operations (commits, pushes, PR management) -- teammates focus on their specialized work.
 
@@ -95,12 +109,14 @@ Every task description must be a markdown document with these sections:
 
 **Type:** Bug | Task | Epic | Story
 
-**Description:** Clear description based on type (Bug: symptoms/root cause; Story: Gherkin Given/When/Then; Task: clear goal; Epic: goal with sub-tasks)
+**Description:** Clear description based on type:
+- Bug: symptoms and root cause
+- Story: Gherkin Given/When/Then
+- Task: clear goal
+- Epic: goal with sub-tasks
 
 ### Type-Specific Requirements
 
-When the plan type is determined, apply the corresponding requirements:
-
 #### Bug
 - **Replication step** (mandatory): Reproduce the bug empirically before any fix
 - **Root cause analysis**: Identify why the bug occurs
@@ -119,6 +135,8 @@ When the plan type is determined, apply the corresponding requirements:
 - **Decompose into sub-tasks** (Stories/Tasks/Bugs)
 - **Each sub-task gets its own type-specific requirements**
 
+### Additional Description Sections
+
 **Acceptance Criteria:** Checkbox list of completion criteria
 
 **Relevant Research:** Code references, patterns, architecture constraints
@@ -135,6 +153,8 @@ When the plan type is determined, apply the corresponding requirements:
 
 ### Metadata
 
+Every task MUST include this JSON metadata block. Do NOT omit `skills` (use `[]` if none) or `verification`.
+
 ```json
 {
   "plan": "<plan-name>",

package/all/copy-overwrite/.claude/skills/plan-create/SKILL.md

@@ -7,35 +7,28 @@ description: "Creates an implementation plan from a ticket URL, file path, or te
 
 Create an implementation plan for: $ARGUMENTS
 
+All plans must follow the rules in @.claude/rules/plan.md (required tasks, branch/PR rules, task creation specification, metadata schema, and archive procedure).
+
 ## Step 1: Parse Input
 
 Determine the input type from `$ARGUMENTS`:
 
-1. **Ticket URL/ID** — For when the argument references a JIRA, Github or Linear issue/ticket number or url
-   - Fetch ticket details with the appropriate CLI or MCP Server
-   - Extract: title, description, acceptance criteria, priority, epic/parent
-   - Note the ticket URL for continuous integration updates
-
-2. **File path** — If the the arguments reference a file:
-   - Read the file contents
-   - Use the file as context for the plan
-
-3. **Free text** — Otherwise, treat the entire argument as a text description of the work
+1. **Ticket URL/ID** -- Fetch ticket details with the appropriate CLI or MCP Server. Extract: title, description, acceptance criteria, priority, epic/parent. Note the ticket URL for later integration updates.
+2. **File path** -- Read the file contents and use as context for the plan.
+3. **Free text** -- Treat the entire argument as a text description of the work.
 
 If no argument provided, prompt the user for input.
 
 ## Step 2: Detect Plan Type
 
-Analyze the input to determine the plan type:
-
 | Type | Indicators |
 |------|------------|
-| **Bug** | Describes symptoms, errors, incorrect behavior, "broken", "fails", "crash", "regression" |
-| **Story/Feature** | Describes new capability, user-facing change, "add", "implement", "create", "as a user" |
-| **Task** | Describes internal work, refactoring, configuration, maintenance, "update", "migrate", "refactor" |
-| **Epic** | Describes large scope with multiple features/stories, "overhaul", "redesign", multiple distinct deliverables |
+| **Bug** | Symptoms, errors, incorrect behavior, "broken", "fails", "crash", "regression" |
+| **Story/Feature** | New capability, user-facing change, "add", "implement", "create", "as a user" |
+| **Task** | Internal work, refactoring, configuration, maintenance, "update", "migrate", "refactor" |
+| **Epic** | Large scope with multiple features/stories, "overhaul", "redesign", multiple deliverables |
 
-If the type is ambiguous, default to **Task**.
+If ambiguous, default to **Task**.
 
 ## Step 3: Spawn Research Team
 
@@ -43,116 +36,71 @@ Create an Agent Team to research the work in parallel. The team lead operates in
 
 ### Phase 1: Research (parallel)
 
-Spawn these three teammates simultaneously:
+Spawn these four teammates simultaneously:
 
 #### Ticket/Task Researcher
-- **Name**: `researcher`
-- **Agent type**: `general-purpose`
-- **Mode**: `plan`
-- **Prompt**: Research the input (ticket, file, or description). If a ticket URL, fetch full details via JIRA MCP or GitHub CLI. If a bug, attempt to reproduce it empirically (Playwright, browser, direct API call, etc.). Extract requirements, acceptance criteria, and context.
+- **Name**: `researcher` | **Agent type**: `general-purpose` | **Mode**: `plan`
+- **Prompt**: Research the input (ticket, file, or description). If a ticket URL, fetch full details via JIRA MCP or GitHub CLI. If a bug, attempt to reproduce it empirically. Extract requirements, acceptance criteria, and context.
 
 #### Codebase Explorer
-- **Name**: `explorer`
-- **Agent type**: `Explore`
-- **Mode**: `plan`
-- **Prompt**: Explore the codebase for relevant code, existing patterns, and reusable scripts. Read lint and format rules to understand project standards. Identify files that would need modification, existing utilities that can be reused, and architecture constraints. Check for existing scripts in `package.json` that could be used for replication or verification.
+- **Name**: `explorer` | **Agent type**: `Explore` | **Mode**: `plan`
+- **Prompt**: Explore the codebase for relevant code, existing patterns, and reusable scripts. Read lint and format rules. Identify files needing modification, reusable utilities, and architecture constraints. Check `package.json` scripts for replication or verification.
 
 #### Devil's Advocate
-- **Name**: `devils-advocate`
-- **Agent type**: `general-purpose`
-- **Mode**: `plan`
-- **Prompt**: Review the input from a critical perspective. Identify anti-patterns, N+1 queries, missing edge cases, security concerns, and performance issues. Do not assume anti-patterns are acceptable just because they exist in the codebase — undocumented anti-patterns should be flagged, not used as reference.
+- **Name**: `devils-advocate` | **Agent type**: `general-purpose` | **Mode**: `plan`
+- **Prompt**: Review the input critically. Identify anti-patterns, N+1 queries, missing edge cases, security concerns, and performance issues. Undocumented anti-patterns in the codebase should be flagged, not used as reference.
+
+#### Spec Gap Analyst
+- **Name**: `spec-analyst` | **Agent type**: `spec-analyst` | **Mode**: `plan`
+- **Prompt**: Analyze the input for specification gaps. Read `package.json` and existing code for project context. Identify every ambiguity or unstated assumption that could lead to wrong architectural decisions. Report as a numbered list of clarifying questions, sorted by impact.
+
+### Gap Resolution
 
-### Phase 2: Review (parallel, after Phase 1 findings are synthesized)
+After Phase 1 completes and before synthesizing the draft plan:
 
-After collecting and synthesizing Phase 1 findings into a draft plan, spawn these two reviewers simultaneously:
+1. Collect gaps from the spec-analyst's findings
+2. Present gaps to the user via AskUserQuestion -- group related questions and include why each matters
+3. If no gaps identified, state "No specification gaps identified" and proceed to Phase 2
+4. Incorporate answers into the draft plan context before Phase 2 review
+
+### Phase 2: Review (parallel, after Phase 1 synthesis)
+
+After synthesizing Phase 1 findings (including gap resolution answers) into a draft plan, spawn these two reviewers simultaneously:
 
 #### Tech Reviewer
-- **Name**: `tech-reviewer`
-- **Agent type**: `tech-reviewer`
-- **Mode**: `plan`
-- **Prompt**: Review the draft plan for correctness, security, and coding-philosophy compliance. Validate the proposed approach, identify technical risks, and confirm the implementation strategy is sound. Flag any issues ranked by severity.
+- **Name**: `tech-reviewer` | **Agent type**: `tech-reviewer` | **Mode**: `plan`
+- **Prompt**: Review the draft plan for correctness, security, and coding-philosophy compliance. Validate the approach, identify technical risks, and flag issues ranked by severity.
 
 #### Product Reviewer
-- **Name**: `product-reviewer`
-- **Agent type**: `product-reviewer`
-- **Mode**: `plan`
-- **Prompt**: Review the draft plan from a non-technical/UX perspective. Does the plan solve the right problem? Will the proposed solution work for end users? Are there user-facing concerns the technical team may have missed?
+- **Name**: `product-reviewer` | **Agent type**: `product-reviewer` | **Mode**: `plan`
+- **Prompt**: Review the draft plan from a non-technical/UX perspective. Does the plan solve the right problem? Will the solution work for end users? Are there user-facing concerns the technical team missed?
 
 ### Bug-Specific Rules
 
 If the plan type is **Bug**:
 
-- The bug **must** be empirically replicated (Playwright, browser, direct API call, etc.) — not guessed at
+- The bug **must** be empirically replicated (Playwright, browser, direct API call, etc.) -- not guessed at
 - If the research team cannot reproduce the bug, **STOP**. Update the ticket with findings and what additional information is needed, then end the session
 - Do not attempt to fix a bug you cannot prove exists
-- Never include solutions with obvious anti-patterns (e.g., N+1 queries). If unavoidable due to API limitations, **STOP** and update the ticket with what is needed
-
-## Step 4: Synthesize & Write Plan
-
-After all teammates have reported and the team lead has approved their findings:
-
-1. Synthesize findings into a unified plan and save it
-2. The plan must include, at minimum, the info found in the @.claude/rules/plan.md rule
-
-### Plan Structure
+- Never include solutions with obvious anti-patterns (e.g., N+1 queries). If unavoidable, **STOP** and update the ticket
 
-The plan file must include, at minimum:
+## Step 4: Synthesize and Write Plan
 
-1. **Title and context** — What is being done and why
-2. **Input source** — Ticket URL, file path, or description
-3. **Plan type** — Bug, Task, Story/Feature, or Epic
-4. **Branch and PR** — Following branch/PR rules from @.claude/rules/plan.md
-5. **Analysis** — Synthesized research findings from all teammates
-6. **Implementation approach** — How the work will be done
-7. **Tasks** — Following the Task Creation Specification from @.claude/rules/plan.md
-8. **Implementation Team** — Instructions to spawn a second Agent Team (see Step 6)
+After all teammates have reported and the team lead has approved their findings, synthesize into a unified plan file with these sections:
 
-### Type-Specific Requirements
+1. **Title and context** -- What is being done and why
+2. **Input source** -- Ticket URL, file path, or description
+3. **Plan type** -- Bug, Task, Story/Feature, or Epic
+4. **Branch and PR** -- Following Branch and PR Rules from @.claude/rules/plan.md
+5. **Analysis** -- Synthesized research findings from all teammates
+6. **Implementation approach** -- How the work will be done
+7. **Tasks** -- Following the Task Creation Specification from @.claude/rules/plan.md, including the JSON metadata block for each task
+8. **Required tasks** -- All tasks from the Required Tasks section in @.claude/rules/plan.md (archive task must be last)
+9. **Implementation team** -- Instructions to spawn a second Agent Team using the agents from the Implementation Team Guidance table in @.claude/rules/plan.md
 
-Apply these additional requirements based on the detected type:
+Apply the Type-Specific Requirements from @.claude/rules/plan.md based on the detected plan type. For Bugs, also include a replication task before any fix and a proof command for every fix task. For Epics, include dependency mapping between sub-tasks.
 
-#### Bug
-- **Replication step** (mandatory): Include a task to reproduce the bug empirically before any fix
-- **Root cause analysis**: Identify why the bug occurs, not just what triggers it
-- **Regression test**: Write a test that fails without the fix and passes with it
-- **Verification**: Run the replication step again after the fix to confirm resolution
-- **Proof command**: Every fix task must include a proof command and expected output
-
-#### Story/Feature
-- **UX review**: Include a product-reviewer agent task to validate from user perspective
-- **Feature flag consideration**: Note whether this should be behind a feature flag
-- **Documentation**: Include user-facing documentation if applicable
-
-#### Task
-- **Standard implementation** with empirical verification
-
-#### Epic
-- **Decompose into sub-tasks**: Break into Stories, Tasks, and/or Bugs
-- **Each sub-task gets its own type-specific requirements**
-- **Dependency mapping**: Identify which sub-tasks depend on others
-
-## Step 5: Include Required Tasks
-
-Include all required tasks defined in the @.claude/rules/plan.md rule (Required Tasks section), including the archive task which must always be last.
-
-## Step 6: Implementation Team Instructions
-
-The plan must include instructions to spawn a **second Agent Team** for implementation. Recommend these specialized agents:
-
-| Agent | Use For |
-|-------|---------|
-| `implementer` | Code implementation (pre-loaded with project conventions) |
-| `tech-reviewer` | Technical review (correctness, security, performance) |
-| `product-reviewer` | Product/UX review (validates from non-technical perspective) |
-| `learner` | Post-implementation learning (processes learnings into skills/rules) |
-| `test-coverage-agent` | Writing comprehensive tests |
-| `code-simplifier` | Code simplification and refinement |
-| `coderabbit` | Automated AI code review |
-
-The **team lead** handles git operations (commits, pushes, PR management) — teammates focus on their specialized work.
-
-## Step 7: Ticket Integration
+## Step 5: Ticket Integration
 
 If the input was a ticket ID or URL:
 
@@ -160,14 +108,10 @@ If the input was a ticket ID or URL:
 2. Associate the branch and PR with the ticket
 3. Post the approved plan as a comment on the ticket
 4. Use `/jira-sync` at key milestones
-5. If blocked (cannot reproduce, unavoidable anti-pattern, missing information, etc.), update the ticket before stopping
-
-## Step 8: Present to User
+5. If blocked, update the ticket before stopping
 
-Present the synthesized plan to the user for review. The user should be able to:
+## Step 6: Present to User
 
-- Approve the plan as-is
-- Request modifications
-- Reject the plan
+Present the synthesized plan to the user for review. The user may approve, request modifications, or reject.
 
 All decisions in the plan must include a recommendation. If a decision is left unresolved, use the recommended option.

package/all/copy-overwrite/.claude/skills/plan-implement/SKILL.md

@@ -13,13 +13,34 @@ If no argument provided, search for plan files in the `plans/` directory and pre
 
 1. **Read the plan file** specified in `$ARGUMENTS`
 2. **Parse all tasks** from the plan, including their dependencies, descriptions, and verification requirements
-3. **Create tasks** using TaskCreate for each task in the plan
-4. **Set up dependencies** between tasks using TaskUpdate (addBlockedBy/addBlocks)
-5. **Spawn an Agent Team** with specialized agents to execute tasks in parallel where dependencies allow
-6. **Execute tasks** following the plan's specified order and dependency graph
-7. **Verify each task** using its verification metadata before marking complete
-8. **Commit changes** after implementation using conventional commit format
+3. **Parse task metadata** -- extract the JSON metadata code fence from each task (see @.claude/rules/plan.md Metadata section for the required schema)
+4. **Create tasks** using TaskCreate for each task in the plan, passing the full parsed metadata
+5. **Set up dependencies** between tasks using TaskUpdate (addBlockedBy/addBlocks)
+6. **Spawn an Agent Team** with specialized agents to execute tasks in parallel where dependencies allow
+7. **Execute tasks** following the plan's specified order and dependency graph
+8. **Verify each task** using its `verification.command` before marking complete
+9. **Archive the plan** following the Archive Procedure in @.claude/rules/plan.md
 
 ## Agent Team Composition
 
-Use the specialized agents listed in $ARGUMENTS and the @.claude/rules/plan.md rule (Implementation Team Guidance section). The **team lead** handles git operations (commits, pushes, PR management) -- teammates focus on their specialized work.
+Use the specialized agents listed in $ARGUMENTS and the Implementation Team Guidance table in @.claude/rules/plan.md. The **team lead** handles git operations (commits, pushes, PR management) -- teammates focus on their specialized work.
+
+## Task Metadata Rules
+
+Each task in the plan file contains a JSON metadata code fence (schema defined in @.claude/rules/plan.md Metadata section).
+
+- Every TaskCreate call MUST include the full `metadata` object from the plan's JSON code fence
+- If a task is missing `skills` or `verification`, flag it as an error and ask the user before proceeding
+- Run `verification.command` before marking any task complete
+
+## Compaction Resilience
+
+Context compaction can cause the team lead to lose in-memory state (task assignments, owner fields). Follow these rules:
+
+1. **Dual owner storage** -- on every TaskUpdate that sets `owner`, also store it in `metadata.owner`:
+   ```
+   TaskUpdate({ taskId: "1", owner: "implementer-1", metadata: { owner: "implementer-1" } })
+   ```
+2. **Re-read after compaction** -- immediately call TaskList to reload all task state
+3. **Restore missing owners** -- if any task has `metadata.owner` but no `owner` field, restore it via TaskUpdate
+4. **Never rely on memory** -- always call TaskList before assigning new work

package/dist/utils/fibonacci.d.ts

@@ -0,0 +1,32 @@
+/**
+ * Fibonacci sequence utilities providing safe, validated computation
+ * within JavaScript's integer precision limits.
+ *
+ * Caps at fibonacci(78) / sequence length 79 because fibonacci(79)
+ * exceeds Number.MAX_SAFE_INTEGER, which would silently corrupt results.
+ *
+ * @module fibonacci
+ */
+/**
+ * Compute the nth Fibonacci number (0-indexed).
+ *
+ * Uses an iterative tuple-reduce approach to avoid stack overflow
+ * and keep computation O(n) time, O(1) space.
+ *
+ * @param n - The zero-based index in the Fibonacci sequence
+ * @returns The nth Fibonacci number
+ * @throws {RangeError} If n is negative, non-integer, NaN, Infinity, or greater than 78
+ */
+export declare function fibonacci(n: number): number;
+/**
+ * Generate the first `length` Fibonacci numbers as a readonly array.
+ *
+ * Builds the sequence incrementally with reduce so each element derives
+ * from its two predecessors without recomputing from scratch.
+ *
+ * @param length - How many Fibonacci numbers to generate
+ * @returns A readonly array of Fibonacci numbers
+ * @throws {RangeError} If length is negative, non-integer, NaN, Infinity, or greater than 79
+ */
+export declare function fibonacciSequence(length: number): readonly number[];
+//# sourceMappingURL=fibonacci.d.ts.map

package/dist/utils/fibonacci.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"fibonacci.d.ts","sourceRoot":"","sources":["../../src/utils/fibonacci.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAQH;;;;;;;;;GASG;AACH,wBAAgB,SAAS,CAAC,CAAC,EAAE,MAAM,GAAG,MAAM,CAsB3C;AAED;;;;;;;;;GASG;AACH,wBAAgB,iBAAiB,CAAC,MAAM,EAAE,MAAM,GAAG,SAAS,MAAM,EAAE,CAiBnE"}

package/dist/utils/fibonacci.js

@@ -0,0 +1,56 @@
+/**
+ * Fibonacci sequence utilities providing safe, validated computation
+ * within JavaScript's integer precision limits.
+ *
+ * Caps at fibonacci(78) / sequence length 79 because fibonacci(79)
+ * exceeds Number.MAX_SAFE_INTEGER, which would silently corrupt results.
+ *
+ * @module fibonacci
+ */
+/** Largest n for which fibonacci(n) fits in a safe JS integer. */
+const MAX_SAFE_N = 78;
+/** Largest sequence length where all elements remain safe JS integers. */
+const MAX_SAFE_LENGTH = 79;
+/**
+ * Compute the nth Fibonacci number (0-indexed).
+ *
+ * Uses an iterative tuple-reduce approach to avoid stack overflow
+ * and keep computation O(n) time, O(1) space.
+ *
+ * @param n - The zero-based index in the Fibonacci sequence
+ * @returns The nth Fibonacci number
+ * @throws {RangeError} If n is negative, non-integer, NaN, Infinity, or greater than 78
+ */
+export function fibonacci(n) {
+    if (!Number.isInteger(n) || n < 0) {
+        throw new RangeError(`Expected a non-negative integer for n, got ${String(n)}`);
+    }
+    if (n > MAX_SAFE_N) {
+        throw new RangeError("fibonacci(n) exceeds Number.MAX_SAFE_INTEGER for n > 78");
+    }
+    if (n <= 1) {
+        return n;
+    }
+    const [, result] = Array.from({ length: n - 1 }).reduce(([prev, curr]) => [curr, prev + curr], [0, 1]);
+    return result;
+}
+/**
+ * Generate the first `length` Fibonacci numbers as a readonly array.
+ *
+ * Builds the sequence incrementally with reduce so each element derives
+ * from its two predecessors without recomputing from scratch.
+ *
+ * @param length - How many Fibonacci numbers to generate
+ * @returns A readonly array of Fibonacci numbers
+ * @throws {RangeError} If length is negative, non-integer, NaN, Infinity, or greater than 79
+ */
+export function fibonacciSequence(length) {
+    if (!Number.isInteger(length) || length < 0) {
+        throw new RangeError(`Expected a non-negative integer for length, got ${String(length)}`);
+    }
+    if (length > MAX_SAFE_LENGTH) {
+        throw new RangeError("fibonacciSequence(length) exceeds Number.MAX_SAFE_INTEGER for length > 79");
+    }
+    return Array.from({ length }).reduce((acc, _, i) => [...acc, i < 2 ? i : (acc[i - 1] ?? 0) + (acc[i - 2] ?? 0)], []);
+}
+//# sourceMappingURL=fibonacci.js.map

package/dist/utils/fibonacci.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"fibonacci.js","sourceRoot":"","sources":["../../src/utils/fibonacci.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,kEAAkE;AAClE,MAAM,UAAU,GAAG,EAAE,CAAC;AAEtB,0EAA0E;AAC1E,MAAM,eAAe,GAAG,EAAE,CAAC;AAE3B;;;;;;;;;GASG;AACH,MAAM,UAAU,SAAS,CAAC,CAAS;IACjC,IAAI,CAAC,MAAM,CAAC,SAAS,CAAC,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC;QAClC,MAAM,IAAI,UAAU,CAClB,8CAA8C,MAAM,CAAC,CAAC,CAAC,EAAE,CAC1D,CAAC;IACJ,CAAC;IAED,IAAI,CAAC,GAAG,UAAU,EAAE,CAAC;QACnB,MAAM,IAAI,UAAU,CAClB,yDAAyD,CAC1D,CAAC;IACJ,CAAC;IAED,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC;QACX,OAAO,CAAC,CAAC;IACX,CAAC;IAED,MAAM,CAAC,EAAE,MAAM,CAAC,GAAG,KAAK,CAAC,IAAI,CAAC,EAAE,MAAM,EAAE,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,MAAM,CAErD,CAAC,CAAC,IAAI,EAAE,IAAI,CAAC,EAAE,EAAE,CAAC,CAAC,IAAI,EAAE,IAAI,GAAG,IAAI,CAAU,EAAE,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,CAAC;IAE1D,OAAO,MAAM,CAAC;AAChB,CAAC;AAED;;;;;;;;;GASG;AACH,MAAM,UAAU,iBAAiB,CAAC,MAAc;IAC9C,IAAI,CAAC,MAAM,CAAC,SAAS,CAAC,MAAM,CAAC,IAAI,MAAM,GAAG,CAAC,EAAE,CAAC;QAC5C,MAAM,IAAI,UAAU,CAClB,mDAAmD,MAAM,CAAC,MAAM,CAAC,EAAE,CACpE,CAAC;IACJ,CAAC;IAED,IAAI,MAAM,GAAG,eAAe,EAAE,CAAC;QAC7B,MAAM,IAAI,UAAU,CAClB,2EAA2E,CAC5E,CAAC;IACJ,CAAC;IAED,OAAO,KAAK,CAAC,IAAI,CAAC,EAAE,MAAM,EAAE,CAAC,CAAC,MAAM,CAClC,CAAC,GAAG,EAAE,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC,GAAG,GAAG,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,CAAC,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,EAC1E,EAAE,CACH,CAAC;AACJ,CAAC"}

package/dist/utils/index.d.ts

@@ -1,3 +1,4 @@
+export * from "./fibonacci.js";
 export * from "./file-operations.js";
 export * from "./json-utils.js";
 export * from "./path-utils.js";

package/dist/utils/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/utils/index.ts"],"names":[],"mappings":"AAAA,cAAc,sBAAsB,CAAC;AACrC,cAAc,iBAAiB,CAAC;AAChC,cAAc,iBAAiB,CAAC"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/utils/index.ts"],"names":[],"mappings":"AAAA,cAAc,gBAAgB,CAAC;AAC/B,cAAc,sBAAsB,CAAC;AACrC,cAAc,iBAAiB,CAAC;AAChC,cAAc,iBAAiB,CAAC"}

package/dist/utils/index.js

@@ -1,3 +1,4 @@
+export * from "./fibonacci.js";
 export * from "./file-operations.js";
 export * from "./json-utils.js";
 export * from "./path-utils.js";

package/dist/utils/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/utils/index.ts"],"names":[],"mappings":"AAAA,cAAc,sBAAsB,CAAC;AACrC,cAAc,iBAAiB,CAAC;AAChC,cAAc,iBAAiB,CAAC"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/utils/index.ts"],"names":[],"mappings":"AAAA,cAAc,gBAAgB,CAAC;AAC/B,cAAc,sBAAsB,CAAC;AACrC,cAAc,iBAAiB,CAAC;AAChC,cAAc,iBAAiB,CAAC"}

package/package.json

@@ -88,7 +88,7 @@
     "@isaacs/brace-expansion": "^5.0.1"
   },
   "name": "@codyswann/lisa",
-  "version": "1.29.1",
+  "version": "1.30.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "bin": {