@codyswann/lisa 1.17.0 → 1.18.0

package/all/copy-overwrite/.claude/hooks/track-plan-sessions.sh

@@ -15,6 +15,10 @@
 # Marker files: $PLANS_DIR/.active-plan-<session-id> contain the absolute path to the
 # active plan file. Stale markers (>24h) are cleaned up on each invocation.
 #
+# Dedup: Session ID dedup is scoped to the ## Sessions section only, not the entire
+# file. This prevents false positives when session IDs appear elsewhere in plan content
+# (e.g., scratchpad directory paths like /private/tmp/claude-501/.../SESSION_ID/...).
+#
 # Debug logging: All key decisions are logged to $PLANS_DIR/.track-plan-debug.log for
 # diagnostics if session IDs land in the wrong plan file.
 #
@@ -123,9 +127,11 @@ if [[ ! -f "$PLAN_FILE" ]]; then
   exit 0
 fi
 
-# Check if session ID already exists in the file (dedup)
-if grep -qF "$SESSION_ID" "$PLAN_FILE" 2>/dev/null; then
-  log_debug "dedup: session ID already in $PLAN_FILE (resolved via $RESOLUTION_METHOD), skipping write"
+# Check if session ID already exists in the ## Sessions section (dedup)
+# Only search within the Sessions section to avoid false positives from session IDs
+# appearing in plan content (e.g., scratchpad paths contain session IDs)
+if sed -n '/^## Sessions$/,$p' "$PLAN_FILE" 2>/dev/null | grep -qF "$SESSION_ID"; then
+  log_debug "dedup: session ID already in $PLAN_FILE sessions section (resolved via $RESOLUTION_METHOD), skipping write"
   exit 0
 fi
 

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

@@ -10,7 +10,7 @@ When making a plan:
 - Always make sure you understand the correct versions of third party libraries
 - Always save the plan with a name befitting the actual plan contents
 - Always look for code that can be reused for implementation
-- The plan MUST including written instructions to create a task list using TaskCreate for each task. The list should contain items related to the plan and specify that subagents should handle as many in parallel as possible. The following should always be included in the task list
+- The plan MUST include written instructions to create a task list using TaskCreate for each task (following the Task Creation Specification below). The list should contain items related to the plan and specify that subagents should handle as many in parallel as possible. The following should always be included in the task list
   - update/add/remove tests, containing the tests that need to get updated, added or removed
   - update/add/remove documentation (jsdocs, markdown files, etc), containing the documentation that need to get updated, added or removed
   - archive the plan (to be completed after all other tasks have been completed). This task should explcitly say to:
@@ -27,3 +27,53 @@ When making a plan:
 - If referencing a ticket (jira, linear, etc), always add a comment to the ticket with the finalized plan
 - The `## Sessions` section in plan files is auto-maintained by the `track-plan-sessions.sh` hook — do not manually edit it
 
+## Task Creation Specification
+
+When plans include TaskCreate instructions, each task must use this format:
+
+### Parameters
+
+- **subject**: Imperative form (e.g., "Add logout button to header")
+- **activeForm**: Present continuous form (e.g., "Adding logout button to header")
+
+### Description Template
+
+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)
+
+**Acceptance Criteria:** Checkbox list of completion criteria
+
+**Relevant Research:** Code references, patterns, architecture constraints extracted from research
+
+**Skills to Invoke:** `/coding-philosophy` is always required, plus other applicable skills
+
+**Implementation Details:** Files to modify, functions to implement, edge cases
+
+**Testing Requirements:** Unit tests (with `describe/it` structure), Integration tests, E2E tests (or "N/A")
+
+**Verification:** Every task MUST have empirical verification (see `verfication.md` for types). Include: verification type, proof command, and expected output.
+
+**Learnings:** On task completion, use `TaskUpdate` to save discoveries: `metadata: { learnings: ["Learning 1", ...] }`
+
+### Metadata
+
+```json
+{
+  "plan": "<plan-name>",
+  "type": "bug|task|epic|story",
+  "skills": ["/coding-philosophy", ...],
+  "verification": {
+    "type": "test|ui-recording|test-coverage|api-test|manual-check|documentation",
+    "command": "the proof command",
+    "expected": "what success looks like"
+  }
+}
+```
+
+### Task Sizing
+
+Each task must be small enough to have a **single, specific verification**. Ask: "Can I prove this is done with ONE command?" Split tasks that require multiple verifications.
+

package/package.json

@@ -85,7 +85,7 @@
   },
   "resolutions": {},
   "name": "@codyswann/lisa",
-  "version": "1.17.0",
+  "version": "1.18.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "bin": {