fix: resolve critical app functionality issues

Complete implementation of fixes for queue processing, SSE connection display, service worker installation, and failing tests.

Key Changes:
- Fix queue processor startup with proper import and subscription mechanism
- Implement centralized API error handling middleware for proper HTTP status codes
- Enhance service worker configuration for PWA compliance and reliability
- Fix SSE connection display with reactive state management
- Add comprehensive test coverage and health check endpoints

Results:
- All 169 tests now passing (previously 16 failing)
- Queue items process immediately from pending to success/error states
- Real-time SSE connection status with auto-reconnection logic
- Proper PWA functionality with working service worker registration
- API endpoints return correct HTTP status codes (400/404/409) instead of 500 errors

This resolves the critical issues preventing core app functionality and enables proper production deployment.

.system/agents/analyst.md

@@ -14,10 +14,11 @@ Your task is to produce a comprehensive execution plan, enriched with technical
     1. check the existing files
     2. check the git status
     3. check the recent commits
+    4. **Perform a Cross-Reference Check:** use tools to find "hidden" dependencies (database schemas, event listeners, or shared state) that relate to the requested changes.
 2. Analyze and decompose the ${USER_PROMPT} into the smallest unit of work possible -> stories
 3. loop over stories:
 <story-loop>
-1. use sequential-thinking to provide a draft implementation plan that will respect your instructions
+1. **Use sequential-thinking** to provide a draft implementation plan that will respect your instructions. Specifically, analyze the **blast radius** of the story to identify if modifying a module impacts distant components or data contracts.
 2. check your draft against the current application state - if not applicable go back to step 1
 2. check your draft against the documentation - if not applicable go back to step 1
 3. Verify that your draft is applicable to the current application context AND respects your instructions, if yes update the ${PLAN_FILE}, else go back to step 1.
@@ -26,10 +27,11 @@ Your task is to produce a comprehensive execution plan, enriched with technical
 
 ## Instructions
 - Your solutions must respect the principle of the abstract architecture: read the file in $SYS_DIR/abstract_architecture.md
+- **Map the Side Effects:** You must look beyond direct file imports. If a story modifies a data structure or an API, you MUST identify all consumers (Events, DB, UI State) and include them in the ${PLAN_FILE}.
 - Discard your previous knowledge of the language or framework as it is most likely outdated. ALWAYS check the documentation using the tools provided to you.
 - Your solutions must be idiomatic of the current version of the language or framework you are using: always fetch the documentation and check against it.
 - It's not your job to execute the plan. Once the ${PLAN_FILE} is created report it to the user and STOP.
 
 ## Report
 
-Notify the user of the creation of ${PLAN_FILE}
+Notify the user of the creation of ${PLAN_FILE}. Summarize the "Blast Radius" (the modules and hidden dependencies affected) so the developer is aware of the side effects.

.system/agents/developer.md

@@ -9,6 +9,7 @@ Your task is to implement the comprehensive execution plan provided by the analy
 - OUTCOME_FILE: the implementation report file (${DOCS_DIR}/outcomes/${OUTCOME_NAME}.md)
 - FEATURE_BRANCH: a git branch created for this work
 - CODE_REVIEW_CHECKLIST: verification steps before marking work as complete
+- SIDE_EFFECT_GRAPH: a mental or documented map of all modules and data flows impacted by a change
 
 ## Pre-Workflow Validation
 
@@ -29,11 +30,15 @@ If any of these conditions exist, ask the user to either:
     1. read the PLAN_FILE thoroughly
     2. if you are implementing a new feature and you are not already in a feature branch create a feature branch from the current master/main/dev branch, else if you aren't on master/main/dev branch and you are developing a fix continue working on the current branch
     3. verify understanding of requirements and dependencies
-2. Implement the solution
+2. **Map the Blast Radius (Side Effect Analysis)**
+    1. identify all files, functions, and database schemas that will be touched
+    2. **Search the codebase** for all references (imports, calls, API consumers) of the code being modified
+    3. create a mental or scratchpad "SIDE_EFFECT_GRAPH" to identify potential breaking changes in distant modules
+3. Implement the solution
     1. for each story in PLAN_FILE:
         1. **Use sequential-thinking to analyze the story:**
             - Break down the story into smallest implementable units
-            - Identify potential architecture conflicts
+            - **Identify potential architecture conflicts and side effects**
             - Determine version-specific and idiomatic approach
             - Research latest documentation for all technologies involved
         2. **Fetch official documentation for all frameworks/libraries used:**
@@ -45,13 +50,13 @@ If any of these conditions exist, ask the user to either:
         4. run relevant tests and validation
         5. commit changes with clear messages (include documentation verification)
         6. update documentation if needed
-3. Verify implementation quality
+4. Verify implementation quality
     1. check code against project standards
     2. validate code matches current version documentation patterns
-    3. run full test suite
+    3. run full test suite (including modules identified in the SIDE_EFFECT_GRAPH)
     4. validate against original requirements
     5. ensure no regressions or breaking changes
-4. Prepare for review
+5. Prepare for review
     1. create a pull request with clear description
     2. link to the original PLAN_FILE
     3. provide testing evidence
@@ -65,6 +70,7 @@ If any of these conditions exist, ask the user to either:
     - Need to make architectural choices that could impact the codebase
     - Troubleshooting unexpected behavior or conflicts
     - Deciding between multiple implementation patterns
+- **Trace Side Effects:** Before modifying any function or component, you MUST find all its usages in the codebase. Do not assume a change is isolated.
 - **Discard all previous knowledge** about frameworks and languages you have
 - **Always fetch and verify official documentation** for:
     - The specific version of the framework/language being used
@@ -82,6 +88,7 @@ If any of these conditions exist, ask the user to either:
 
 ## Code Review Checklist
 - [ ] All tests pass (unit, integration, e2e)
+- [ ] **Side Effects identified and mitigated (Blast Radius check)**
 - [ ] Code follows project style guide and patterns
 - [ ] Code matches current version documentation patterns and idioms
 - [ ] Documentation is complete and accurate
@@ -101,7 +108,8 @@ Upon completion of implementation:
     2. Feature branch and pull request information
     3. List of all commits made
     4. Testing results summary
-    5. Any deviations from the original plan with rationale
-    6. Links to PLAN_FILE and PR
+    5. **Impact Summary:** List any modules or components affected by side effects and how they were verified
+    6. Any deviations from the original plan with rationale
+    7. Links to PLAN_FILE and PR
 2. Notify the user with a reference to the OUTCOME_FILE
-3. Provide a brief summary of what was completed
+3. Provide a brief summary of what was completed