groundswell 0.0.2 → 0.0.3

package/dist/utils/index.js

@@ -0,0 +1,4 @@
+export { generateId } from './id.js';
+export { Observable } from './observable.js';
+export { mergeWorkflowErrors } from './workflow-error-utils.js';
+//# sourceMappingURL=index.js.map

package/dist/utils/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/utils/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,SAAS,CAAC;AACrC,OAAO,EAAE,UAAU,EAAE,MAAM,iBAAiB,CAAC;AAC7C,OAAO,EAAE,mBAAmB,EAAE,MAAM,2BAA2B,CAAC"}

package/dist/utils/observable.d.ts

@@ -0,0 +1,54 @@
+/**
+ * Lightweight Observable implementation for event streaming
+ * No external dependencies
+ */
+export interface Subscription {
+    unsubscribe(): void;
+}
+export interface Observer<T> {
+    next?: (value: T) => void;
+    error?: (error: unknown) => void;
+    complete?: () => void;
+}
+/**
+ * Logger interface for Observable error logging
+ * Matches WorkflowLogger.error() signature for compatibility
+ */
+export interface ObservableLogger {
+    error(message: string, data?: unknown): void;
+}
+export declare class Observable<T> {
+    private subscribers;
+    private logger?;
+    /**
+     * Create a new Observable
+     * @param logger Optional logger for error reporting (falls back to console.error)
+     */
+    constructor(logger?: ObservableLogger);
+    /**
+     * Subscribe to this observable
+     * @returns Subscription with unsubscribe method
+     */
+    subscribe(observer: Observer<T>): Subscription;
+    /**
+     * Log errors using injected logger or fallback to console.error
+     */
+    private logError;
+    /**
+     * Emit a value to all subscribers
+     */
+    next(value: T): void;
+    /**
+     * Signal an error to all subscribers
+     */
+    error(err: unknown): void;
+    /**
+     * Signal completion to all subscribers
+     */
+    complete(): void;
+    /**
+     * Get current subscriber count
+     */
+    get subscriberCount(): number;
+}
+//# sourceMappingURL=observable.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"observable.d.ts","sourceRoot":"","sources":["../../src/utils/observable.ts"],"names":[],"mappings":"AAAA;;;GAGG;AACH,MAAM,WAAW,YAAY;IAC3B,WAAW,IAAI,IAAI,CAAC;CACrB;AAED,MAAM,WAAW,QAAQ,CAAC,CAAC;IACzB,IAAI,CAAC,EAAE,CAAC,KAAK,EAAE,CAAC,KAAK,IAAI,CAAC;IAC1B,KAAK,CAAC,EAAE,CAAC,KAAK,EAAE,OAAO,KAAK,IAAI,CAAC;IACjC,QAAQ,CAAC,EAAE,MAAM,IAAI,CAAC;CACvB;AAED;;;GAGG;AACH,MAAM,WAAW,gBAAgB;IAC/B,KAAK,CAAC,OAAO,EAAE,MAAM,EAAE,IAAI,CAAC,EAAE,OAAO,GAAG,IAAI,CAAC;CAC9C;AAED,qBAAa,UAAU,CAAC,CAAC;IACvB,OAAO,CAAC,WAAW,CAA+B;IAClD,OAAO,CAAC,MAAM,CAAC,CAAmB;IAElC;;;OAGG;gBACS,MAAM,CAAC,EAAE,gBAAgB;IAIrC;;;OAGG;IACH,SAAS,CAAC,QAAQ,EAAE,QAAQ,CAAC,CAAC,CAAC,GAAG,YAAY;IAS9C;;OAEG;IACH,OAAO,CAAC,QAAQ;IAShB;;OAEG;IACH,IAAI,CAAC,KAAK,EAAE,CAAC,GAAG,IAAI;IAUpB;;OAEG;IACH,KAAK,CAAC,GAAG,EAAE,OAAO,GAAG,IAAI;IAUzB;;OAEG;IACH,QAAQ,IAAI,IAAI;IAWhB;;OAEG;IACH,IAAI,eAAe,IAAI,MAAM,CAE5B;CACF"}

package/dist/utils/observable.js

@@ -0,0 +1,82 @@
+export class Observable {
+    subscribers = new Set();
+    logger;
+    /**
+     * Create a new Observable
+     * @param logger Optional logger for error reporting (falls back to console.error)
+     */
+    constructor(logger) {
+        this.logger = logger;
+    }
+    /**
+     * Subscribe to this observable
+     * @returns Subscription with unsubscribe method
+     */
+    subscribe(observer) {
+        this.subscribers.add(observer);
+        return {
+            unsubscribe: () => {
+                this.subscribers.delete(observer);
+            },
+        };
+    }
+    /**
+     * Log errors using injected logger or fallback to console.error
+     */
+    logError(message, error) {
+        if (this.logger) {
+            this.logger.error(message, { error });
+        }
+        else {
+            // Fallback for backward compatibility
+            console.error(message, error);
+        }
+    }
+    /**
+     * Emit a value to all subscribers
+     */
+    next(value) {
+        for (const subscriber of this.subscribers) {
+            try {
+                subscriber.next?.(value);
+            }
+            catch (err) {
+                this.logError('Observable subscriber error', err);
+            }
+        }
+    }
+    /**
+     * Signal an error to all subscribers
+     */
+    error(err) {
+        for (const subscriber of this.subscribers) {
+            try {
+                subscriber.error?.(err);
+            }
+            catch (e) {
+                this.logError('Observable error handler failed', e);
+            }
+        }
+    }
+    /**
+     * Signal completion to all subscribers
+     */
+    complete() {
+        for (const subscriber of this.subscribers) {
+            try {
+                subscriber.complete?.();
+            }
+            catch (err) {
+                this.logError('Observable complete handler failed', err);
+            }
+        }
+        this.subscribers.clear();
+    }
+    /**
+     * Get current subscriber count
+     */
+    get subscriberCount() {
+        return this.subscribers.size;
+    }
+}
+//# sourceMappingURL=observable.js.map

package/dist/utils/observable.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"observable.js","sourceRoot":"","sources":["../../src/utils/observable.ts"],"names":[],"mappings":"AAsBA,MAAM,OAAO,UAAU;IACb,WAAW,GAAqB,IAAI,GAAG,EAAE,CAAC;IAC1C,MAAM,CAAoB;IAElC;;;OAGG;IACH,YAAY,MAAyB;QACnC,IAAI,CAAC,MAAM,GAAG,MAAM,CAAC;IACvB,CAAC;IAED;;;OAGG;IACH,SAAS,CAAC,QAAqB;QAC7B,IAAI,CAAC,WAAW,CAAC,GAAG,CAAC,QAAQ,CAAC,CAAC;QAC/B,OAAO;YACL,WAAW,EAAE,GAAG,EAAE;gBAChB,IAAI,CAAC,WAAW,CAAC,MAAM,CAAC,QAAQ,CAAC,CAAC;YACpC,CAAC;SACF,CAAC;IACJ,CAAC;IAED;;OAEG;IACK,QAAQ,CAAC,OAAe,EAAE,KAAc;QAC9C,IAAI,IAAI,CAAC,MAAM,EAAE,CAAC;YAChB,IAAI,CAAC,MAAM,CAAC,KAAK,CAAC,OAAO,EAAE,EAAE,KAAK,EAAE,CAAC,CAAC;QACxC,CAAC;aAAM,CAAC;YACN,sCAAsC;YACtC,OAAO,CAAC,KAAK,CAAC,OAAO,EAAE,KAAK,CAAC,CAAC;QAChC,CAAC;IACH,CAAC;IAED;;OAEG;IACH,IAAI,CAAC,KAAQ;QACX,KAAK,MAAM,UAAU,IAAI,IAAI,CAAC,WAAW,EAAE,CAAC;YAC1C,IAAI,CAAC;gBACH,UAAU,CAAC,IAAI,EAAE,CAAC,KAAK,CAAC,CAAC;YAC3B,CAAC;YAAC,OAAO,GAAG,EAAE,CAAC;gBACb,IAAI,CAAC,QAAQ,CAAC,6BAA6B,EAAE,GAAG,CAAC,CAAC;YACpD,CAAC;QACH,CAAC;IACH,CAAC;IAED;;OAEG;IACH,KAAK,CAAC,GAAY;QAChB,KAAK,MAAM,UAAU,IAAI,IAAI,CAAC,WAAW,EAAE,CAAC;YAC1C,IAAI,CAAC;gBACH,UAAU,CAAC,KAAK,EAAE,CAAC,GAAG,CAAC,CAAC;YAC1B,CAAC;YAAC,OAAO,CAAC,EAAE,CAAC;gBACX,IAAI,CAAC,QAAQ,CAAC,iCAAiC,EAAE,CAAC,CAAC,CAAC;YACtD,CAAC;QACH,CAAC;IACH,CAAC;IAED;;OAEG;IACH,QAAQ;QACN,KAAK,MAAM,UAAU,IAAI,IAAI,CAAC,WAAW,EAAE,CAAC;YAC1C,IAAI,CAAC;gBACH,UAAU,CAAC,QAAQ,EAAE,EAAE,CAAC;YAC1B,CAAC;YAAC,OAAO,GAAG,EAAE,CAAC;gBACb,IAAI,CAAC,QAAQ,CAAC,oCAAoC,EAAE,GAAG,CAAC,CAAC;YAC3D,CAAC;QACH,CAAC;QACD,IAAI,CAAC,WAAW,CAAC,KAAK,EAAE,CAAC;IAC3B,CAAC;IAED;;OAEG;IACH,IAAI,eAAe;QACjB,OAAO,IAAI,CAAC,WAAW,CAAC,IAAI,CAAC;IAC/B,CAAC;CACF"}

package/dist/utils/workflow-error-utils.d.ts

@@ -0,0 +1,22 @@
+import type { WorkflowError } from '../types/error.js';
+/**
+ * Merge multiple WorkflowError objects into a single aggregated error.
+ *
+ * This is the default merger used when errorMergeStrategy is enabled for concurrent tasks.
+ * It aggregates information from all errors to provide a comprehensive view of failures.
+ *
+ * @param errors - Array of WorkflowError objects to merge
+ * @param taskName - Name of the task that spawned the concurrent workflows
+ * @param parentWorkflowId - ID of the parent workflow
+ * @param totalChildren - Total number of child workflows that were spawned
+ * @returns A merged WorkflowError containing aggregated information
+ *
+ * @example
+ * ```ts
+ * const errors: WorkflowError[] = [error1, error2, error3];
+ * const merged = mergeWorkflowErrors(errors, 'myTask', 'parent-123', 5);
+ * // Returns: WorkflowError with message "3 of 5 concurrent child workflows failed in task 'myTask'"
+ * ```
+ */
+export declare function mergeWorkflowErrors(errors: WorkflowError[], taskName: string, parentWorkflowId: string, totalChildren: number): WorkflowError;
+//# sourceMappingURL=workflow-error-utils.d.ts.map

package/dist/utils/workflow-error-utils.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"workflow-error-utils.d.ts","sourceRoot":"","sources":["../../src/utils/workflow-error-utils.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,mBAAmB,CAAC;AAGvD;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,mBAAmB,CACjC,MAAM,EAAE,aAAa,EAAE,EACvB,QAAQ,EAAE,MAAM,EAChB,gBAAgB,EAAE,MAAM,EACxB,aAAa,EAAE,MAAM,GACpB,aAAa,CA4Bf"}

package/dist/utils/workflow-error-utils.js

@@ -0,0 +1,45 @@
+/**
+ * Merge multiple WorkflowError objects into a single aggregated error.
+ *
+ * This is the default merger used when errorMergeStrategy is enabled for concurrent tasks.
+ * It aggregates information from all errors to provide a comprehensive view of failures.
+ *
+ * @param errors - Array of WorkflowError objects to merge
+ * @param taskName - Name of the task that spawned the concurrent workflows
+ * @param parentWorkflowId - ID of the parent workflow
+ * @param totalChildren - Total number of child workflows that were spawned
+ * @returns A merged WorkflowError containing aggregated information
+ *
+ * @example
+ * ```ts
+ * const errors: WorkflowError[] = [error1, error2, error3];
+ * const merged = mergeWorkflowErrors(errors, 'myTask', 'parent-123', 5);
+ * // Returns: WorkflowError with message "3 of 5 concurrent child workflows failed in task 'myTask'"
+ * ```
+ */
+export function mergeWorkflowErrors(errors, taskName, parentWorkflowId, totalChildren) {
+    // Create merged error message
+    const message = `${errors.length} of ${totalChildren} concurrent child workflows failed in task '${taskName}'`;
+    // Get all unique workflow IDs that failed
+    const failedWorkflowIds = [...new Set(errors.map((e) => e.workflowId))];
+    // Aggregate all logs
+    const allLogs = errors.flatMap((e) => e.logs);
+    // Create merged WorkflowError
+    const mergedError = {
+        message,
+        original: {
+            name: 'WorkflowAggregateError',
+            message,
+            errors,
+            totalChildren,
+            failedChildren: errors.length,
+            failedWorkflowIds,
+        },
+        workflowId: parentWorkflowId,
+        stack: errors[0]?.stack, // Use first error's stack trace
+        state: errors[0]?.state || {}, // Use first error's state
+        logs: allLogs,
+    };
+    return mergedError;
+}
+//# sourceMappingURL=workflow-error-utils.js.map

package/dist/utils/workflow-error-utils.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"workflow-error-utils.js","sourceRoot":"","sources":["../../src/utils/workflow-error-utils.ts"],"names":[],"mappings":"AAGA;;;;;;;;;;;;;;;;;;GAkBG;AACH,MAAM,UAAU,mBAAmB,CACjC,MAAuB,EACvB,QAAgB,EAChB,gBAAwB,EACxB,aAAqB;IAErB,8BAA8B;IAC9B,MAAM,OAAO,GAAG,GAAG,MAAM,CAAC,MAAM,OAAO,aAAa,+CAA+C,QAAQ,GAAG,CAAC;IAE/G,0CAA0C;IAC1C,MAAM,iBAAiB,GAAG,CAAC,GAAG,IAAI,GAAG,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,UAAU,CAAC,CAAC,CAAC,CAAC;IAExE,qBAAqB;IACrB,MAAM,OAAO,GAAG,MAAM,CAAC,OAAO,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC;IAE9C,8BAA8B;IAC9B,MAAM,WAAW,GAAkB;QACjC,OAAO;QACP,QAAQ,EAAE;YACR,IAAI,EAAE,wBAAwB;YAC9B,OAAO;YACP,MAAM;YACN,aAAa;YACb,cAAc,EAAE,MAAM,CAAC,MAAM;YAC7B,iBAAiB;SACP;QACZ,UAAU,EAAE,gBAAgB;QAC5B,KAAK,EAAE,MAAM,CAAC,CAAC,CAAC,EAAE,KAAK,EAAE,gCAAgC;QACzD,KAAK,EAAE,MAAM,CAAC,CAAC,CAAC,EAAE,KAAK,IAAK,EAA8B,EAAE,0BAA0B;QACtF,IAAI,EAAE,OAAO;KACd,CAAC;IAEF,OAAO,WAAW,CAAC;AACrB,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "groundswell",
-  "version": "0.0.2",
+  "version": "0.0.3",
   "url": "https://github.com/groundswell-ai/groundswell",
   "description": "Hierarchical workflow orchestration engine with full observability",
   "keywords": [
@@ -61,5 +61,8 @@
   },
   "engines": {
     "node": ">=18"
-  }
+  },
+  "files": [
+    "dist"
+  ]
 }

package/.claude/commands/subtask-planning/prp-base-create.md

@@ -1,120 +0,0 @@
-# Create BASE PRP
-
-## Feature: $ARGUMENTS or $(tsk next) subtask
-
-## PRP Creation Mission
-
-Create a comprehensive PRP that enables **one-pass implementation success** through systematic research and context curation.
-
-
-**Critical Understanding**:
-You must start by reading and understanding the prp concepts plan/README.md
-Be aware that the executing AI agent only receives:
-- The PRP content you create
-- Its training data knowledge
-- Access to codebase files (but needs guidance on which ones)
-
-
-**Therefore**: Your research and context curation directly determines implementation success. Incomplete context = implementation failure.
-
-## Research Process
-
-> During the research process, create clear tasks and spawn as many agents and subagents as needed using the batch tools. The deeper research we do here the better the PRP will be. We optimize for chance of success, not for speed.
-
-1. **Codebase Analysis in depth**
-   - Create clear todos and spawn subagents to search the codebase for similar features/patterns. Think hard and plan your approach
-   - Identify all the necessary files to reference in the PRP
-   - Note all existing conventions to follow
-   - Check existing test patterns for validation approach, if none are found plan to find a new one
-   - Use the batch tools to spawn subagents to search the codebase for similar features/patterns
-
-2. **Internal Research at scale**
-   - Use relevant research and plan information in the `plan/M#P#T#S#` directory according to the current subtask
-   - Consider the scope of the subtask within the overall PRD. Respect the boundaries of scope of implementation for this task. Ensure cohesion across
-   previously completed tasks and guard against harming future task completion in your plan
-
-2. **External Research at scale**
-   - Create clear todos and spawn subagents with instructions to do deep research for similar features/patterns online and include urls to documentation and examples
-   - Library documentation (include specific URLs)
-   - Store all research in plans/\[M#P#T#S#]/research according to the current task and reference critical pieces of documentation in the PRP with clear
-   reasoning and instructions
-   - Implementation examples (GitHub/StackOverflow/blogs)
-   - New validation approach none found in existing codebase and user confirms they would like one added
-   - Best practices and common pitfalls found during research
-   - Use the batch tools to spawn subagents to search for similar features/patterns online and include urls to documentation and examples
-
-3. **User Clarification**
-   - Ask for clarification if you need it
-   - If no testing framework is found, ask the user if they would like to set one up
-   - If a fundamental misalignemnt of objectives across tasks is detected, halt and produce a thorough explanation of the problem at a 10th grade level
-
-## PRP Generation Process
-
-### Step 1: Choose Template
-
-Use `plan/templates/prp_base.md` as your template structure - it contains all necessary sections and formatting.
-
-### Step 2: Context Completeness Validation
-
-Before writing, apply the **"No Prior Knowledge" test** from the template:
-_"If someone knew nothing about this codebase, would they have everything needed to implement this successfully?"_
-
-### Step 3: Research Integration
-
-Transform your research findings into the template sections:
-
-**Goal Section**: Use research to define specific, measurable Feature Goal and concrete Deliverable
-**Context Section**: Populate YAML structure with your research findings - specific URLs, file patterns, gotchas
-**Implementation Tasks**: Create dependency-ordered tasks using information-dense keywords from codebase analysis
-**Validation Gates**: Use project-specific validation commands that you've verified work in this codebase
-
-### Step 4: Information Density Standards
-
-Ensure every reference is **specific and actionable**:
-
-- URLs include section anchors, not just domain names
-- File references include specific patterns to follow, not generic mentions
-- Task specifications include exact naming conventions and placement
-- Validation commands are project-specific and executable
-
-### Step 5: ULTRATHINK Before Writing
-
-After research completion, create comprehensive PRP writing plan using TodoWrite tool:
-
-- Plan how to structure each template section with your research findings
-- Identify gaps that need additional research
-- Create systematic approach to filling template with actionable context
-
-## Output
-
-Store the PRP at `plan/M#P#T#S#/PRP.md`
-Store documentation at `plan/M#P#T#S#/research/`
-
-## PRP Quality Gates
-
-### Context Completeness Check
-
-- [ ] Passes "No Prior Knowledge" test from template
-- [ ] All YAML references are specific and accessible
-- [ ] Implementation tasks include exact naming and placement guidance
-- [ ] Validation commands are project-specific and verified working
-
-### Template Structure Compliance
-
-- [ ] All required template sections completed
-- [ ] Goal section has specific Feature Goal, Deliverable, Success Definition
-- [ ] Implementation Tasks follow dependency ordering
-- [ ] Final Validation Checklist is comprehensive
-
-### Information Density Standards
-
-- [ ] No generic references - all are specific and actionable
-- [ ] File patterns point at specific examples to follow
-- [ ] URLs include section anchors for exact guidance
-- [ ] Task specifications use information-dense keywords from codebase
-
-## Success Metrics
-
-**Confidence Score**: Rate 1-10 for one-pass implementation success likelihood
-
-**Validation**: The completed PRP should enable an AI agent unfamiliar with the codebase to implement the feature successfully using only the PRP content and codebase access.

package/.claude/commands/subtask-planning/prp-base-execute.md

@@ -1,65 +0,0 @@
-# Execute BASE PRP
-
-## PRP File: $ARGUMENTS or $(tsk next) subtask information located at plans/M#P#T#S#/PRP.md
-
-## Mission: One-Pass Implementation Success
-
-PRPs enable working code on the first attempt through:
-
-- **Context Completeness**: Everything needed, nothing guessed
-- **Progressive Validation**: 4-level gates catch errors early
-- **Pattern Consistency**: Follow existing codebase approaches
-- Read PRPs/README.md to understand PRP concepts
-
-**Your Goal**: Transform the PRP into working code that passes all validation gates.
-
-## Execution Process
-
-1. **Load PRP**
-   - Read the specified PRP file completely
-   - Absorb all context, patterns, requirements and gather codebase intelligence
-   - Use the provided documentation references and file patterns, consume the right documentation before the appropriate todo/task
-   - Trust the PRP's context and guidance - it's designed for one-pass success
-   - If needed do additional codebase exploration and research as needed
-
-2. **ULTRATHINK & Plan**
-   - Create comprehensive implementation plan following the PRP's task order
-   - Break down into clear todos using TodoWrite tool
-   - Use subagents for parallel work when beneficial (always create prp inspired prompts for subagents when used)
-   - Follow the patterns referenced in the PRP
-   - Use specific file paths, class names, and method signatures from PRP context
-   - Never guess - always verify the codebase patterns and examples referenced in the PRP yourself
-
-3. **Execute Implementation**
-   - Follow the PRP's Implementation Tasks sequence, add more detail as needed, especially when using subagents
-   - Use the patterns and examples referenced in the PRP
-   - Create files in locations specified by the desired codebase tree
-   - Apply naming conventions from the task specifications and CLAUDE.md
-
-4. **Progressive Validation**
-
-   **Execute the level validation system from the PRP:**
-   - **Level 1**: Run syntax & style validation commands from PRP
-   - **Level 2**: Execute unit test validation from PRP
-   - **Level 3**: Run integration testing commands from PRP
-   - **Level 4**: Execute specified validation from PRP
-
-   **Each level must pass before proceeding to the next.**
-
-5. **Completion Verification**
-   - Work through the Final Validation Checklist in the PRP
-   - Verify all Success Criteria from the "What" section are met
-   - Confirm all Anti-Patterns were avoided
-   - Implementation is ready and working
-
-**Failure Protocol**: When validation fails, use the patterns and gotchas from the PRP to fix issues, then re-run validation until passing.
-
-If a fundamental issue with the plan is found, halt and produce a thorough explanation of the problem at a 10th grade level.
-
-Strictly output your results in this JSON format:
-
-```json
-{
-   "result": "success" | "error" | "issue",
-   "message": "Detailed explanation of the issue"
-}

package/.claude/commands/task-breakdown.md

@@ -1,94 +0,0 @@
-Act as a Lead Technical Architect and Project Management Synthesizer. You have already convened a panel of senior specialists (Security, DevOps, Backend, Frontend, and QA) who hold adversarial views on scope and complexity. Your job is not to output their debate, but to output their rigorous, unified consensus on how to decompose the attached PRD.
-
-Your Primary Goal: Assess the PRD to determine its hierarchy (Phase > Milestone > Task > Subtask) and decompose it into atomic, coherent work units.
-
-Hierarchy Definitions:
-
-Phase: Project-scope goals (e.g., MVP, V1.0). Weeks to months of effort.
-
-Milestone: Key objectives within a Phase. 1 to 12 weeks of effort.
-
-Task: Complete features within a Milestone. Days to weeks of effort.
-
-Subtask: Atomic implementation steps. 0.5, 1, or 2 Story Points (SP). Max 2 SP per subtask.
-
-Critical Constraints & Standard of Work (SOW):
-
-Coherence & Continuity (Priority):
-
-You must ensure architectural flow. Subtasks must not exist in a vacuum.
-
-If Subtask A defines a data schema, Subtask B must explicitly be told to consume that specific schema.
-
-Reference specific file paths, variable names, or API endpoints within the context_scope to ensure the implementing agent follows the chain of logic.
-
-Implicit TDD & Quality:
-
-Do not create subtasks for "Write Tests."
-
-Assume every subtask implies: "Write the failing test, implement the code, pass the test."
-
-Code is not complete without tests.
-
-The "Context Scope" Blinder:
-
-For every Subtask, the context_scope must be a strict set of instructions for a developer who cannot see the rest of the project.
-
-It must define Inputs (what data/interfaces are available from previous subtasks) and Outputs (what exact interface this subtask exposes).
-
-It must explicitly state Mocking Strategies to keep the subtask isolated.
-
-Process:
-
-Analyze the attached or referenced PRD.
-
-Determine the highest level of scope (Phase, Milestone, or Task) this PRD represents.
-
-Decompose strictly downwards to the Subtask level.
-
-Output Format:
-Output only a JSON object. No conversational text.
-
-```json
-{
-  "backlog": [
-    {
-      "type": "Phase",
-      "id": "P[#]",
-      "title": "Phase Title",
-      "status": "Planned | Researching | Ready | Implementing | Complete | Failed",
-      "description": "High level goal.",
-      "milestones": [
-        {
-          "type": "Milestone",
-          "id": "P[#].M[#]",
-          "title": "Milestone Title",
-          "status": "Planned",
-          "description": "Key objective.",
-          "tasks": [
-            {
-              "type": "Task",
-              "id": "P[#].M[#].T[#]",
-              "title": "Task Title",
-              "status": "Planned",
-              "description": "Feature definition.",
-              "subtasks": [
-                {
-                  "type": "Subtask",
-                  "id": "P[#].M[#].T[#].S[#]",
-                  "title": "Subtask Title",
-                  "status": "Planned",
-                  "story_points": 1,
-                  "dependencies": ["ID of prerequisite subtask"],
-                  "context_scope": "CONTRACT DEFINITION:\n1. INPUT: [Specific data structure/variable] from [Dependency ID].\n2. LOGIC: Implement [PRD Section X] logic. Mock [Service Y] for isolation.\n3. OUTPUT: Return [Result Object/Interface] for consumption by [Next Subtask ID]."
-                }
-              ]
-            }
-          ]
-        }
-      ]
-    }
-  ]
-}
-```
-

package/.claude/settings.local.json

@@ -1,9 +0,0 @@
-{
-  "permissions": {
-    "allow": [
-      "Bash(mkdir:*)"
-    ],
-    "deny": [],
-    "ask": []
-  }
-}

package/.claude/system_prompts/task-breakdown.md

@@ -1,101 +0,0 @@
-# LEAD TECHNICAL ARCHITECT & PROJECT SYNTHESIZER
-
-> **ROLE:** Act as a Lead Technical Architect and Project Management Synthesizer.
-> **CONTEXT:** You represent the rigorous, unified consensus of a senior panel (Security, DevOps, Backend, Frontend, QA).
-> **GOAL:** Validate the PRD through research, document findings, and decompose the PRD into a strict hierarchy: `Phase` > `Milestone` > `Task` > `Subtask`.
-
----
-
-## HIERARCHY DEFINITIONS
-
-*   **PHASE:** Project-scope goals (e.g., MVP, V1.0). *Weeks to months.*
-*   **MILESTONE:** Key objectives within a Phase. *1 to 12 weeks.*
-*   **TASK:** Complete features within a Milestone. *Days to weeks.*
-*   **SUBTASK:** Atomic implementation steps. **0.5, 1, or 2 Story Points (SP).** (Max 2 SP, do not break subtasks down further than 2 SP unless required).
-
----
-
-## CRITICAL CONSTRAINTS & STANDARD OF WORK (SOW)
-
-### 1. RESEARCH-DRIVEN ARCHITECTURE (NEW PRIORITY)
-*   **VALIDATE BEFORE BREAKING DOWN:** You cannot plan what you do not understand.
-*   **SPAWN SUBAGENTS:** Use your tools to spawn agents to research the codebase and external documentation *before* defining the hierarchy.
-*   **REALITY CHECK:** Verify that the PRD's requests match the current codebase state (e.g., don't plan a React hook if the project is vanilla JS).
-*   **PERSISTENCE:** You must store architectural findings in `plan/architecture/` so the downstream PRP (Product Requirement Prompt) agents have access to them.
-
-### 2. COHERENCE & CONTINUITY
-*   **NO VACUUMS:** You must ensure architectural flow. Subtasks must not exist in isolation.
-*   **EXPLICIT HANDOFFS:** If `Subtask A` defines a schema, `Subtask B` must be explicitly instructed to consume that schema.
-*   **STRICT REFERENCES:** Reference specific file paths, variable names, or API endpoints confirmed during your **Research Phase**.
-
-### 3. IMPLICIT TDD & QUALITY
-*   **DO NOT** create subtasks for "Write Tests."
-*   **IMPLIED WORKFLOW:** Assume every subtask implies: *"Write the failing test -> Implement the code -> Pass the test."*
-*   **DEFINITION OF DONE:** Code is not complete without tests.
-
-### 4. THE "CONTEXT SCOPE" BLINDER
-For every Subtask, the `context_scope` must be a **strict set of instructions** for a developer who cannot see the rest of the project. It must define:
-*   **INPUT:** What specific data/interfaces are available from previous subtasks?
-*   **OUTPUT:** What exact interface does this subtask expose?
-*   **MOCKING:** What external services must be mocked to keep this subtask isolated?
-
----
-
-## PROCESS
-
-1.  **ANALYZE** the attached or referenced PRD.
-2.  **RESEARCH (SPAWN & VALIDATE):**
-    *   **Spawn** subagents to map the codebase and verify PRD feasibility.
-    *   **Spawn** subagents to find external documentation for new tech.
-    *   **Store** findings in `plan/architecture/` (e.g., `system_context.md`, `external_deps.md`).
-3.  **DETERMINE** the highest level of scope (Phase, Milestone, or Task).
-4.  **DECOMPOSE** strictly downwards to the Subtask level, using your research to populate the `context_scope`.
-
----
-
-## OUTPUT FORMAT
-
-**CONSTRAINT:** Output **ONLY** a valid JSON object. No conversational text.
-
-```json
-{
-  "backlog": [
-    {
-      "type": "Phase",
-      "id": "P[#]",
-      "title": "Phase Title",
-      "status": "Planned | Researching | Ready | Implementing | Complete | Failed",
-      "description": "High level goal.",
-      "milestones": [
-        {
-          "type": "Milestone",
-          "id": "P[#].M[#]",
-          "title": "Milestone Title",
-          "status": "Planned",
-          "description": "Key objective.",
-          "tasks": [
-            {
-              "type": "Task",
-              "id": "P[#].M[#].T[#]",
-              "title": "Task Title",
-              "status": "Planned",
-              "description": "Feature definition.",
-              "subtasks": [
-                {
-                  "type": "Subtask",
-                  "id": "P[#].M[#].T[#].S[#]",
-                  "title": "Subtask Title",
-                  "status": "Planned",
-                  "story_points": 1,
-                  "dependencies": ["ID of prerequisite subtask"],
-                  "context_scope": "CONTRACT DEFINITION:\n1. RESEARCH NOTE: [Finding from plan/architecture/ regarding this feature].\n2. INPUT: [Specific data structure/variable] from [Dependency ID].\n3. LOGIC: Implement [PRD Section X] logic. Mock [Service Y] for isolation.\n4. OUTPUT: Return [Result Object/Interface] for consumption by [Next Subtask ID]."
-                }
-              ]
-            }
-          ]
-        }
-      ]
-    }
-  ]
-}
-```