sublation-os 1.0.1 → 1.1.0

package/.cursor/commands/sublation-os/create-tasks.md

@@ -0,0 +1,254 @@
+I want you to create a tasks breakdown from a given spec and requirements for a new feature using the following MULTI-PHASE process and instructions.
+
+Carefully read and execute the instructions in the following files IN SEQUENCE, following their numbered file names.  Only proceed to the next numbered instruction file once the previous numbered instruction has been executed.
+
+Instructions to follow in sequence:
+
+# PHASE 1: Get Spec Requirements
+
+The FIRST STEP is to make sure you have ONE OR BOTH of these files to inform your tasks breakdown:
+- `sublation-os/specs/[this-spec]/spec.md`
+- `sublation-os/specs/[this-spec]/planning/requirements.md`
+
+IF you don't have ONE OR BOTH of those files in your current conversation context, then ask user to provide direction on where to you can find them by outputting the following request then wait for user's response:
+
+"I'll need a spec.md or requirements.md (or both) in order to build a tasks list.
+
+Please direct me to where I can find those.  If you haven't created them yet, you can run /shape-spec or /write-spec."
+
+# PHASE 2: Create Tasks List
+
+Now that you have the spec.md AND/OR requirements.md, please break those down into an actionable tasks list with strategic grouping and ordering, by following these instructions:
+
+# Task List Creation
+
+## Core Responsibilities
+
+1. **Analyze spec and requirements**: Read and analyze the spec.md and/or requirements.md to inform the tasks list you will create.
+2. **Plan task execution order**: Break the requirements into a list of tasks in an order that takes their dependencies into account.
+3. **Group tasks by specialization**: Group tasks that require the same skill or stack specialization together (backend, api, ui design, etc.)
+4. **Create Tasks list**: Create the markdown tasks list broken into groups with sub-tasks.
+
+## Workflow
+
+### Step 1: Analyze Spec & Requirements
+
+Read each of these files (whichever are available) and analyze them to understand the requirements for this feature implementation:
+- `sublation-os/specs/[this-spec]/spec.md`
+- `sublation-os/specs/[this-spec]/planning/requirements.md`
+
+Use your learnings to inform the tasks list and groupings you will create in the next step.
+
+
+### Step 2: Create Tasks Breakdown
+
+Generate `sublation-os/specs/[current-spec]/tasks.md`.
+
+**Important**: The exact tasks, task groups, and organization will vary based on the feature's specific requirements. The following is an example format - adapt the content of the tasks list to match what THIS feature actually needs.
+
+```markdown
+# Task Breakdown: [Feature Name]
+
+## Overview
+Total Tasks: [count]
+
+## Task List
+
+### Database Layer
+
+#### Task Group 1: Data Models and Migrations
+**Dependencies:** None
+
+- [ ] 1.0 Complete database layer
+  - [ ] 1.1 Write 2-8 focused tests for [Model] functionality
+    - Limit to 2-8 highly focused tests maximum
+    - Test only critical model behaviors (e.g., primary validation, key association, core method)
+    - Skip exhaustive coverage of all methods and edge cases
+  - [ ] 1.2 Create [Model] with validations
+    - Fields: [list]
+    - Validations: [list]
+    - Reuse pattern from: [existing model if applicable]
+  - [ ] 1.3 Create migration for [table]
+    - Add indexes for: [fields]
+    - Foreign keys: [relationships]
+  - [ ] 1.4 Set up associations
+    - [Model] has_many [related]
+    - [Model] belongs_to [parent]
+  - [ ] 1.5 Ensure database layer tests pass
+    - Run ONLY the 2-8 tests written in 1.1
+    - Verify migrations run successfully
+    - Do NOT run the entire test suite at this stage
+
+**Acceptance Criteria:**
+- The 2-8 tests written in 1.1 pass
+- Models pass validation tests
+- Migrations run successfully
+- Associations work correctly
+
+### API Layer
+
+#### Task Group 2: API Endpoints
+**Dependencies:** Task Group 1
+
+- [ ] 2.0 Complete API layer
+  - [ ] 2.1 Write 2-8 focused tests for API endpoints
+    - Limit to 2-8 highly focused tests maximum
+    - Test only critical controller actions (e.g., primary CRUD operation, auth check, key error case)
+    - Skip exhaustive testing of all actions and scenarios
+  - [ ] 2.2 Create [resource] controller
+    - Actions: index, show, create, update, destroy
+    - Follow pattern from: [existing controller]
+  - [ ] 2.3 Implement authentication/authorization
+    - Use existing auth pattern
+    - Add permission checks
+  - [ ] 2.4 Add API response formatting
+    - JSON responses
+    - Error handling
+    - Status codes
+  - [ ] 2.5 Ensure API layer tests pass
+    - Run ONLY the 2-8 tests written in 2.1
+    - Verify critical CRUD operations work
+    - Do NOT run the entire test suite at this stage
+
+**Acceptance Criteria:**
+- The 2-8 tests written in 2.1 pass
+- All CRUD operations work
+- Proper authorization enforced
+- Consistent response format
+
+### Frontend Components
+
+#### Task Group 3: UI Design
+**Dependencies:** Task Group 2
+
+- [ ] 3.0 Complete UI components
+  - [ ] 3.1 Write 2-8 focused tests for UI components
+    - Limit to 2-8 highly focused tests maximum
+    - Test only critical component behaviors (e.g., primary user interaction, key form submission, main rendering case)
+    - Skip exhaustive testing of all component states and interactions
+  - [ ] 3.2 Create [Component] component
+    - Reuse: [existing component] as base
+    - Props: [list]
+    - State: [list]
+  - [ ] 3.3 Implement [Feature] form
+    - Fields: [list]
+    - Validation: client-side
+    - Submit handling
+  - [ ] 3.4 Build [View] page
+    - Layout: [description]
+    - Components: [list]
+    - Match mockup: `planning/visuals/[file]`
+  - [ ] 3.5 Apply base styles
+    - Follow existing design system
+    - Use variables from: [style file]
+  - [ ] 3.6 Implement responsive design
+    - Mobile: 320px - 768px
+    - Tablet: 768px - 1024px
+    - Desktop: 1024px+
+  - [ ] 3.7 Add interactions and animations
+    - Hover states
+    - Transitions
+    - Loading states
+  - [ ] 3.8 Ensure UI component tests pass
+    - Run ONLY the 2-8 tests written in 3.1
+    - Verify critical component behaviors work
+    - Do NOT run the entire test suite at this stage
+
+**Acceptance Criteria:**
+- The 2-8 tests written in 3.1 pass
+- Components render correctly
+- Forms validate and submit
+- Matches visual design
+
+### Testing
+
+#### Task Group 4: Test Review & Gap Analysis
+**Dependencies:** Task Groups 1-3
+
+- [ ] 4.0 Review existing tests and fill critical gaps only
+  - [ ] 4.1 Review tests from Task Groups 1-3
+    - Review the 2-8 tests written by database-engineer (Task 1.1)
+    - Review the 2-8 tests written by api-engineer (Task 2.1)
+    - Review the 2-8 tests written by ui-designer (Task 3.1)
+    - Total existing tests: approximately 6-24 tests
+  - [ ] 4.2 Analyze test coverage gaps for THIS feature only
+    - Identify critical user workflows that lack test coverage
+    - Focus ONLY on gaps related to this spec's feature requirements
+    - Do NOT assess entire application test coverage
+    - Prioritize end-to-end workflows over unit test gaps
+  - [ ] 4.3 Write up to 10 additional strategic tests maximum
+    - Add maximum of 10 new tests to fill identified critical gaps
+    - Focus on integration points and end-to-end workflows
+    - Do NOT write comprehensive coverage for all scenarios
+    - Skip edge cases, performance tests, and accessibility tests unless business-critical
+  - [ ] 4.4 Run feature-specific tests only
+    - Run ONLY tests related to this spec's feature (tests from 1.1, 2.1, 3.1, and 4.3)
+    - Expected total: approximately 16-34 tests maximum
+    - Do NOT run the entire application test suite
+    - Verify critical workflows pass
+
+**Acceptance Criteria:**
+- All feature-specific tests pass (approximately 16-34 tests total)
+- Critical user workflows for this feature are covered
+- No more than 10 additional tests added when filling in testing gaps
+- Testing focused exclusively on this spec's feature requirements
+
+## Execution Order
+
+Recommended implementation sequence:
+1. Database Layer (Task Group 1)
+2. API Layer (Task Group 2)
+3. Frontend Design (Task Group 3)
+4. Test Review & Gap Analysis (Task Group 4)
+```
+
+**Note**: Adapt this structure based on the actual feature requirements. Some features may need:
+- Different task groups (e.g., email notifications, payment processing, data migration)
+- Different execution order based on dependencies
+- More or fewer sub-tasks per group
+
+## Important Constraints
+
+- **Create tasks that are specific and verifiable**
+- **Group related tasks:** For example, group back-end engineering tasks together and front-end UI tasks together.
+- **Limit test writing during development**:
+  - Each task group (1-3) should write 2-8 focused tests maximum
+  - Tests should cover only critical behaviors, not exhaustive coverage
+  - Test verification should run ONLY the newly written tests, not the entire suite
+  - If there is a dedicated test coverage group for filling in gaps in test coverage, this group should add only a maximum of 10 additional tests IF NECESSARY to fill critical gaps
+- **Use a focused test-driven approach** where each task group starts with writing 2-8 tests (x.1 sub-task) and ends with running ONLY those tests (final sub-task)
+- **Include acceptance criteria** for each task group
+- **Reference visual assets** if visuals are available
+
+
+## Display confirmation and next step
+
+Display the following message to the user:
+
+```
+The tasks list has created at `sublation-os/specs/[this-spec]/tasks.md`.
+
+Review it closely to make sure it all looks good.
+
+NEXT STEP 👉 Run `/implement-tasks` (simple, effective) or `/orchestrate-tasks` (advanced, powerful) to start building!
+```
+
+## User Standards & Preferences Compliance
+
+IMPORTANT: Ensure that the tasks list is ALIGNED and DOES NOT CONFLICT with the user's preferences and standards as detailed in the following files:
+
+@sublation-os/standards/backend/api.md
+@sublation-os/standards/backend/migrations.md
+@sublation-os/standards/backend/models.md
+@sublation-os/standards/backend/queries.md
+@sublation-os/standards/frontend/accessibility.md
+@sublation-os/standards/frontend/components.md
+@sublation-os/standards/frontend/css.md
+@sublation-os/standards/frontend/responsive.md
+@sublation-os/standards/global/coding-style.md
+@sublation-os/standards/global/commenting.md
+@sublation-os/standards/global/conventions.md
+@sublation-os/standards/global/error-handling.md
+@sublation-os/standards/global/tech-stack.md
+@sublation-os/standards/global/validation.md
+@sublation-os/standards/testing/test-writing.md

package/.cursor/commands/sublation-os/implement-tasks.md

@@ -0,0 +1,207 @@
+Now that we have a spec and tasks list ready for implementation, we will proceed with implementation of this spec by following this multi-phase process:
+
+PHASE 1: Determine which task group(s) from tasks.md should be implemented
+PHASE 2: Implement the given task(s)
+PHASE 3: After ALL task groups have been implemented, produce the final verification report.
+
+Carefully read and execute the instructions in the following files IN SEQUENCE, following their numbered file names.  Only proceed to the next numbered instruction file once the previous numbered instruction has been executed.
+
+Instructions to follow in sequence:
+
+# PHASE 1: Determine Tasks
+
+First, check if the user has already provided instructions about which task group(s) to implement.
+
+**If the user HAS provided instructions:** Proceed to PHASE 2 to delegate implementation of those specified task group(s) to the **implementer** subagent.
+
+**If the user has NOT provided instructions:**
+
+Read `agent-os/specs/[this-spec]/tasks.md` to review the available task groups, then output the following message to the user and WAIT for their response:
+
+```
+Should we proceed with implementation of all task groups in tasks.md?
+
+If not, then please specify which task(s) to implement.
+```
+
+# PHASE 2: Implement Tasks
+
+Now that you have the task group(s) to be implemented, proceed with implementation by following these instructions:
+
+Implement all tasks assigned to you and ONLY those task(s) that have been assigned to you.
+
+## Implementation process:
+
+1. Analyze the provided spec.md, requirements.md, and visuals (if any)
+2. Analyze patterns in the codebase according to its built-in workflow
+3. Implement the assigned task group according to requirements and standards
+4. Update `agent-os/specs/[this-spec]/tasks.md` to update the tasks you've implemented to mark that as done by updating their checkbox to checked state: `- [x]`
+
+## Guide your implementation using:
+- **The existing patterns** that you've found and analyzed in the codebase.
+- **Specific notes provided in requirements.md, spec.md AND/OR tasks.md**
+- **Visuals provided (if any)** which would be located in `agent-os/specs/[this-spec]/planning/visuals/`
+- **User Standards & Preferences** which are defined below.
+
+## Self-verify and test your work by:
+- Running ONLY the tests you've written (if any) and ensuring those tests pass.
+- IF your task involves user-facing UI, and IF you have access to browser testing tools, open a browser and use the feature you've implemented as if you are a user to ensure a user can use the feature in the intended way.
+  - Take screenshots of the views and UI elements you've tested and store those in `agent-os/specs/[this-spec]/verification/screenshots/`.  Do not store screenshots anywhere else in the codebase other than this location.
+  - Analyze the screenshot(s) you've taken to check them against your current requirements.
+
+
+## Display confirmation and next step
+
+Display a summary of what was implemented.
+
+IF all tasks are now marked as done (with `- [x]`) in tasks.md, display this message to user:
+
+```
+All tasks have been implemented: `agent-os/specs/[this-spec]/tasks.md`.
+
+NEXT STEP 👉 Run `3-verify-implementation.md` to verify the implementation.
+```
+
+IF there are still tasks in tasks.md that have yet to be implemented (marked unfinished with `- [ ]`) then display this message to user:
+
+```
+Would you like to proceed with implementation of the remaining tasks in tasks.md?
+
+If not, please specify which task group(s) to implement next.
+```
+
+## User Standards & Preferences Compliance
+
+IMPORTANT: Ensure that the tasks list is ALIGNED and DOES NOT CONFLICT with the user's preferences and standards as detailed in the following files:
+
+@agent-os/standards/backend/api.md
+@agent-os/standards/backend/migrations.md
+@agent-os/standards/backend/models.md
+@agent-os/standards/backend/queries.md
+@agent-os/standards/frontend/accessibility.md
+@agent-os/standards/frontend/components.md
+@agent-os/standards/frontend/css.md
+@agent-os/standards/frontend/responsive.md
+@agent-os/standards/global/coding-style.md
+@agent-os/standards/global/commenting.md
+@agent-os/standards/global/conventions.md
+@agent-os/standards/global/error-handling.md
+@agent-os/standards/global/tech-stack.md
+@agent-os/standards/global/validation.md
+@agent-os/standards/testing/test-writing.md
+
+# PHASE 3: Verify Implementation
+
+Now that we've implemented all tasks in tasks.md, we must run final verifications and produce a verification report using the following MULTI-PHASE workflow:
+
+## Workflow
+
+### Step 1: Ensure tasks.md has been updated
+
+Check `agent-os/specs/[this-spec]/tasks.md` and ensure that all tasks and their sub-tasks are marked as completed with `- [x]`.
+
+If a task is still marked incomplete, then verify that it has in fact been completed by checking the following:
+- Run a brief spot check in the code to find evidence that this task's details have been implemented
+- Check for existence of an implementation report titled using this task's title in `agent-os/spec/[this-spec]/implementation/` folder.
+
+IF you have concluded that this task has been completed, then mark it's checkbox and its' sub-tasks checkboxes as completed with `- [x]`.
+
+IF you have concluded that this task has NOT been completed, then mark this checkbox with ⚠️ and note it's incompleteness in your verification report.
+
+
+### Step 2: Update roadmap (if applicable)
+
+Open `agent-os/product/roadmap.md` and check to see whether any item(s) match the description of the current spec that has just been implemented.  If so, then ensure that these item(s) are marked as completed by updating their checkbox(s) to `- [x]`.
+
+
+### Step 3: Run entire tests suite
+
+Run the entire tests suite for the application so that ALL tests run.  Verify how many tests are passing and how many have failed or produced errors.
+
+Include these counts and the list of failed tests in your final verification report.
+
+DO NOT attempt to fix any failing tests.  Just note their failures in your final verification report.
+
+
+### Step 4: Create final verification report
+
+Create your final verification report in `agent-os/specs/[this-spec]/verifications/final-verification.html`.
+
+The content of this report should follow this structure:
+
+```markdown
+# Verification Report: [Spec Title]
+
+**Spec:** `[spec-name]`
+**Date:** [Current Date]
+**Verifier:** implementation-verifier
+**Status:** ✅ Passed | ⚠️ Passed with Issues | ❌ Failed
+
+---
+
+## Executive Summary
+
+[Brief 2-3 sentence overview of the verification results and overall implementation quality]
+
+---
+
+## 1. Tasks Verification
+
+**Status:** ✅ All Complete | ⚠️ Issues Found
+
+### Completed Tasks
+- [x] Task Group 1: [Title]
+  - [x] Subtask 1.1
+  - [x] Subtask 1.2
+- [x] Task Group 2: [Title]
+  - [x] Subtask 2.1
+
+### Incomplete or Issues
+[List any tasks that were found incomplete or have issues, or note "None" if all complete]
+
+---
+
+## 2. Documentation Verification
+
+**Status:** ✅ Complete | ⚠️ Issues Found
+
+### Implementation Documentation
+- [x] Task Group 1 Implementation: `implementations/1-[task-name]-implementation.md`
+- [x] Task Group 2 Implementation: `implementations/2-[task-name]-implementation.md`
+
+### Verification Documentation
+[List verification documents from area verifiers if applicable]
+
+### Missing Documentation
+[List any missing documentation, or note "None"]
+
+---
+
+## 3. Roadmap Updates
+
+**Status:** ✅ Updated | ⚠️ No Updates Needed | ❌ Issues Found
+
+### Updated Roadmap Items
+- [x] [Roadmap item that was marked complete]
+
+### Notes
+[Any relevant notes about roadmap updates, or note if no updates were needed]
+
+---
+
+## 4. Test Suite Results
+
+**Status:** ✅ All Passing | ⚠️ Some Failures | ❌ Critical Failures
+
+### Test Summary
+- **Total Tests:** [count]
+- **Passing:** [count]
+- **Failing:** [count]
+- **Errors:** [count]
+
+### Failed Tests
+[List any failing tests with their descriptions, or note "None - all tests passing"]
+
+### Notes
+[Any additional context about test results, known issues, or regressions]
+```

package/.cursor/commands/sublation-os/investigate.md

@@ -0,0 +1,164 @@
+---
+argument-hint: [message]
+description: Diagnose errors using ReAct (Reasoning + Acting) methodology with iterative investigation
+---
+
+You are investigating an error using the **ReAct (Reasoning + Acting)** approach, which combines systematic reasoning with targeted actions to diagnose issues.
+
+## Error to Investigate
+$message
+
+---
+
+## Investigation Process
+
+Use the **Thought-Action-Observation** loop iteratively until the root cause is identified. Document each cycle clearly.
+
+### Investigation Cycle 1: Initial Analysis
+
+**THOUGHT**:
+Analyze the error systematically before taking action:
+- What does the error message tell me? (error type, location, context)
+- Based on the error type, what are the 3 most likely causes?
+- What information would help me confirm or eliminate these hypotheses?
+- What should I investigate first to get maximum diagnostic value?
+
+**ACTION**:
+{Describe what you're doing and why}
+Examples:
+- Read the file mentioned in the stack trace to understand context
+- Search for recent changes to the affected code
+- Check logs for related errors or warnings
+- Examine configuration files
+- Review related test files
+
+**OBSERVATION**:
+After completing the action, document what you learned:
+- What did I find? (specific findings, not interpretations)
+- Does this confirm or eliminate any hypotheses?
+- What new questions or patterns emerge?
+- Do I have enough information, or do I need another cycle?
+
+---
+
+### Investigation Cycle 2: Hypothesis Testing
+
+**THOUGHT**:
+Based on the previous observation, reason through the next step:
+- Which hypothesis is most likely now? Why?
+- What specific evidence would confirm or reject this hypothesis?
+- What's the next best action to take?
+
+**ACTION**:
+{Targeted investigation based on your reasoning}
+
+**OBSERVATION**:
+{What you discovered and how it changes your understanding}
+
+---
+
+### Investigation Cycle 3-N: Iterative Deep Dive
+
+**THOUGHT**: {Continue reasoning based on accumulated observations}
+**ACTION**: {Continue investigating}
+**OBSERVATION**: {Continue learning}
+
+*Continue cycles until you have high confidence in the root cause (typically 3-5 cycles)*
+
+---
+
+## Root Cause Analysis
+
+After completing investigation cycles, synthesize your findings:
+
+### 🎯 Root Cause
+{Clear, specific statement of what's wrong - reference exact files and line numbers if possible}
+
+### 🔍 Evidence Trail
+Document the key observations that led to this conclusion:
+1. {First key finding}
+2. {Second key finding}
+3. {Confirming evidence}
+
+### 📊 Confidence Level
+**Confidence**: ⬛⬛⬛⬜⬜ (High/Medium/Low)
+
+**Reasoning**: {Why are you confident or uncertain? What alternative explanations remain?}
+
+---
+
+## Resolution Plan
+
+### ✅ Recommended Fix
+
+**THOUGHT**:
+Given the root cause, what's the best approach to fix it?
+- Consider multiple solutions if applicable
+- Think through trade-offs and side effects
+- Evaluate complexity and risk
+
+**Primary Solution**:
+{Detailed fix with code examples or specific changes}
+
+**Why This Approach**:
+{Reasoning for why this is the best solution}
+
+**Alternative Solutions** (if applicable):
+{Other viable approaches and why they weren't chosen}
+
+### 🧪 Verification Steps
+How to confirm the fix works:
+1. {Specific test or check}
+2. {Expected outcome}
+3. {Additional validation}
+
+### ⚠️ Potential Side Effects
+{Any risks or areas to watch after applying the fix}
+
+---
+
+## Documentation
+
+Save this investigation report to:
+`.sublation-os/investigations/[YYYY-MM-DD]-[brief-description].md`
+
+Use this format for the filename:
+- `2025-01-15-auth-token-expiry.md`
+- `2025-01-15-database-connection-timeout.md`
+
+---
+
+## Quality Standards
+
+**Good Investigation Example**:
+
+**THOUGHT**: The error "Cannot read property 'map' of undefined" in UserList.tsx:45 suggests data isn't loaded. Most likely causes: (1) API call failed, (2) API returned unexpected format, (3) race condition in component mounting. I'll check the API call first since that's most common.
+
+**ACTION**: Read UserList.tsx to see how data is fetched and when map() is called.
+
+**OBSERVATION**: Line 45 calls users.map() but users comes from useState with no default value. The useEffect fetches users, but there's no loading state. The map() runs before data arrives.
+
+✅ **Specific and actionable**
+✅ **Clear reasoning documented**
+✅ **Each step builds on previous learning**
+
+**Poor Investigation Example**:
+
+**THOUGHT**: Something is wrong with the code.
+**ACTION**: Look at files.
+**OBSERVATION**: Found a problem.
+
+❌ **Too vague**
+❌ **No reasoning shown**
+❌ **Not helpful for learning**
+
+---
+
+## Integration with Memory System
+
+After resolving the issue, consider running `/learn` to capture:
+- The mistake or pattern that caused the issue
+- How to detect similar issues in the future
+- Codebase-specific gotchas discovered
+
+This helps future debugging sessions by building institutional knowledge.