5-phase-workflow 1.4.2 → 1.4.4

package/src/commands/5/quick-implement.md

@@ -8,27 +8,6 @@ user-invocable: true
 
 # Quick Implement
 
-## Prerequisites Check
-
-**CRITICAL: Check for configuration before proceeding**
-
-```bash
-if [ ! -f ".claude/.5/config.json" ]; then
-  echo "❌ Configuration not found"
-  echo ""
-  echo "Please run /5:configure first to set up your project."
-  echo ""
-  echo "The configure command will:"
-  echo "  • Detect your project type and build commands"
-  echo "  • Set up ticket tracking conventions"
-  echo "  • Generate documentation (CLAUDE.md)"
-  echo "  • Create project-specific skills"
-  exit 1
-fi
-```
-
-**If config doesn't exist, STOP IMMEDIATELY. Do not proceed with the workflow.**
-
 Fast path for small, well-understood tasks (1-5 files). Skips extensive planning phases but preserves state tracking and skill-based implementation.
 
 ## ⚠️ CRITICAL SCOPE CONSTRAINT
@@ -46,27 +25,10 @@ Your job in this command:
 ✅ Report completion
 
 Your job is NOT:
-❌ Handle complex features (6+ files)
-❌ Work across multiple domains
-❌ Skip clarifying questions if unclear
-❌ Skip state file updates
-❌ Create feature spec files (use full workflow)
-❌ Commit without config - Only commit if git.autoCommit is enabled
-
-**This is a FAST PATH for well-understood, small tasks. For anything complex, use the full workflow.**
-
-## ❌ Boundaries: What This Command Does NOT Do
-
-**CRITICAL:** This command has a LIMITED scope. Do NOT:
-
-- ❌ **Use for complex features** - 6+ files or multiple domains → use full workflow
-- ❌ **Skip clarifying questions** - If implementation is unclear, ask first
-- ❌ **Skip state updates** - State file updates are MANDATORY
-- ❌ **Create feature specs** - This is for quick tasks, not full features
-- ❌ **Commit without config** - Only commit if git.autoCommit is enabled
-- ❌ **Skip plan approval** - Always show plan and get user approval first
-
-**If the task involves more than 5 files or multiple domains, STOP and recommend the full workflow instead.**
+❌ Handle complex features (6+ files or multiple domains → use full workflow)
+❌ Skip clarifying questions, state file updates, or plan approval
+❌ Create feature spec files
+❌ Commit without config (only if git.autoCommit is enabled)
 
 ## Process
 
@@ -87,16 +49,22 @@ git branch --show-current
 
 Extract ticket ID using configurable pattern from config (e.g., `PROJ-\d+` or `\d+`). If not found, ask developer.
 
+**Sanitize the ticket ID:** Only allow alphanumeric characters, dashes (`-`), and underscores (`_`). Strip any other characters (especially `/`, `..`, `~`, spaces). If the sanitized result is empty, ask the user for a valid ticket ID.
+
 Also read `.claude/.5/config.json` and extract:
 - `git.autoCommit` (boolean, default `false`)
 - `git.commitMessage.pattern` (string, default `{ticket-id} {short-description}`)
 
 ### Step 3: Generate Identifiers
 
-```bash
-slug=$(echo "$DESCRIPTION" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g' | sed 's/--*/-/g' | sed 's/^-//;s/-$//' | cut -c1-40)
-feature_name="${TICKET_ID}-${slug}"
-```
+Generate a slug from `$DESCRIPTION` using string manipulation (do NOT use bash for this — avoid shell injection):
+1. Convert to lowercase
+2. Replace any non-alphanumeric character with a dash (`-`)
+3. Collapse consecutive dashes into one
+4. Remove leading/trailing dashes
+5. Truncate to 40 characters
+
+Set `feature_name` to `${TICKET_ID}-${slug}`.
 
 ### Step 4: Analyze and Plan
 
@@ -115,14 +83,15 @@ feature_name="${TICKET_ID}-${slug}"
 
 Write plan to `.5/features/${feature_name}/plan.md` using the template structure.
 
-**Template Reference:** Use the structure from `.claude/templates/workflow/QUICK-PLAN.md`
+**Template Reference:** Use the structure from `.claude/templates/workflow/PLAN.md`
 
 The template contains placeholders for:
+- **YAML frontmatter:** ticket, feature, created
 - **Header:** `# Quick Implementation: {TICKET-ID}`
-- **Task:** The task description
-- **Components table:** Columns for #, Type, Name, Skill, Module
-- **Affected Modules:** List of modules that will be modified
-- **Execution:** Mode (parallel, sequential, or direct)
+- **Task description:** One sentence summary
+- **Components table:** Columns for Step, Component, Action, File, Description, Complexity
+- **Implementation Notes:** Key details and patterns
+- **Verification:** Build and test commands
 
 ### Step 6: Present Plan and Iterate
 
@@ -155,29 +124,9 @@ Use AskUserQuestion:
 
 **CRITICAL**: You MUST create the state file before starting implementation. This enables resumability if work is interrupted.
 
-Create state file at `.5/features/${feature_name}/state.json` using Write tool:
-
-```json
-{
-  "ticketId": "${TICKET_ID}",
-  "featureName": "${feature_name}",
-  "phase": "quick-implementation",
-  "status": "in-progress",
-  "currentWave": 1,
-  "totalWaves": 1,
-  "completedComponents": [],
-  "pendingComponents": [/* from plan */],
-  "failedAttempts": [],
-  "verificationResults": {},
-  "startedAt": "{ISO timestamp}",
-  "lastUpdated": "{ISO timestamp}"
-}
-```
+Create state file at `.5/features/${feature_name}/state.json` with fields: `ticket`, `feature`, `phase: "quick-implementation"`, `status: "in-progress"`, `currentStep: 1`, `totalSteps: 1`, `completed: []`, `pending: [from plan]`, `failed: []`, `verificationResults: {}`, `startedAt`, `lastUpdated`.
 
-**After creating the file:**
-1. Use Read tool to verify the file was written correctly
-2. Report to user: "State tracking initialized"
-3. If file creation fails, stop and report error
+Verify the file was written correctly with Read tool. If creation fails, stop and report error.
 
 ### Step 8: Execute Implementation
 
@@ -192,7 +141,7 @@ For each component:
 1. Invoke appropriate skill using Skill tool
 2. **Update state file after each component** (MANDATORY):
    - Read current state file
-   - Move component from `pendingComponents` to `completedComponents`
+   - Move component from `pending` to `completed`
    - Update `lastUpdated` timestamp
    - Write back to state file
    - Verify write succeeded
@@ -200,12 +149,17 @@ For each component:
 
 #### Step-Executor Delegation
 
+Determine the model based on the highest complexity in the plan's components:
+- All components `simple` → `haiku`
+- Any component `moderate` → `sonnet`
+- Any component `complex` → `sonnet`
+
 Spawn an agent with inline instructions:
 
 ```
 Task tool call:
   subagent_type: general-purpose
-  model: haiku
+  model: {haiku or sonnet based on complexity above}
   description: "Execute quick implementation for ${feature_name}"
   prompt: |
     Implement components for a feature by finding patterns in existing code.
@@ -242,8 +196,8 @@ Task tool call:
 
 Process results and **update state file** (MANDATORY):
 - Read current state file
-- Move completed components from `pendingComponents` to `completedComponents`
-- Record any failures in `failedAttempts`
+- Move completed components from `pending` to `completed`
+- Record any failures in `failed`
 - Update `lastUpdated` timestamp
 - Write back to state file
 - Verify write succeeded
@@ -274,76 +228,15 @@ Skill tool call:
 
 ### Step 9b: Auto-Commit (if enabled)
 
-Only fires if `git.autoCommit: true` AND build passed in Step 9.
-
-Creates a **single commit** for all components (not per-component — quick-implement is for small tasks):
-
-1. Stage **only** the specific files from the plan's components (never `git add .`)
-2. Commit using the configured `git.commitMessage.pattern`:
-   - `{ticket-id}` → ticket ID
-   - `{short-description}` → auto-generated summary (imperative mood, max 50 chars for full first line)
-   - Body: one bullet per component
-
-```bash
-# Stage only specific files
-git add {file-1} {file-2} ...
-
-# Commit with configured pattern + body
-git commit -m "{ticket-id} {short-description}
-
-- {concise change 1}
-- {concise change 2}"
-```
-
-3. If commit fails → log warning, record in `state.json`, continue
-4. If build failed in Step 9 → skip commit entirely
+Only fires if `git.autoCommit: true` AND build passed. Creates a single commit: stage only plan files (never `git add .`), commit with configured `git.commitMessage.pattern` (body: one bullet per component). If commit fails, log warning and continue.
 
 ### Step 10: Update State and Report (MANDATORY)
 
 **CRITICAL**: You MUST update the state file to mark completion.
 
-1. **Read current state file**
-2. **Update to completed status**:
-```json
-{
-  "status": "completed",
-  "phase": "completed",
-  "verificationResults": {
-    "buildStatus": "success",
-    "testStatus": "success | skipped",
-    "timestamp": "{ISO timestamp}"
-  },
-  "completedAt": "{ISO timestamp}",
-  "lastUpdated": "{ISO timestamp}"
-}
-```
-3. **Write back using Write tool**
-4. **Verify the update** by reading file again
+Update state file to `status: "completed"`, `phase: "completed"`, with `verificationResults` (buildStatus, testStatus, timestamp), `completedAt`, `lastUpdated`. Verify the write.
 
-Report to user:
-
-```
-✅ Quick implementation complete!
-
-${TICKET_ID}: ${DESCRIPTION}
-
-Components created/modified:
-- {file1}
-- {file2}
-
-Build: Success
-Tests: {Success | Skipped}
-{If git.autoCommit was true: "Commit: {Success | Failed | Skipped (build failed)}"}
-
-State: .5/features/${feature_name}/state.json
-
-Next steps:
-{If auto-commit fired successfully:}
-1. For a new task, run `/clear` before starting
-{If auto-commit not enabled or commit skipped:}
-1. Review and commit changes
-2. For a new task, run `/clear` before starting
-```
+Report: ticket, description, files created/modified, build/test status, commit status (if auto-commit), and next steps (commit if needed, `/clear` before new task).
 
 **🛑 YOUR JOB IS COMPLETE. DO NOT START NEW TASKS.**
 

package/src/commands/5/review-code.md

@@ -18,16 +18,6 @@ After saving the review report, you are DONE.
 
 # Review Code (Phase 5)
 
-## Prerequisites
-
-If the feature argument is `CONFIGURE`, skip this check.
-
-For all other features: Read `.claude/.5/config.json`. If the file does not exist, STOP immediately and tell the user:
-
-"Configuration not found. Please run `/5:configure` first to set up your project."
-
-Do NOT proceed without configuration.
-
 ## Review Tools
 
 Two review tools are supported (configured in `.claude/.5/config.json` field `reviewTool`):
@@ -237,7 +227,7 @@ If "Ask me each": Present each question individually via AskUserQuestion. If the
 
 For "Save to file" mode only.
 
-Determine feature name from `.5/features/*/state.json` (most recent) or ask user.
+Determine feature name from `.5/features/*/state.json` (most recent by `startedAt` field) or ask user.
 
 Write to `.5/features/{feature-name}/review-{YYYYMMDD-HHmmss}-findings.md`.
 
@@ -251,7 +241,7 @@ Skip to REVIEW COMPLETE.
 
 When invoked with `apply`:
 
-1. Determine feature name from `.5/features/*/state.json` or ask user
+1. Determine feature name from `.5/features/*/state.json` (most recent by `startedAt` field) or ask user
 2. Find most recent `review-*-findings.md` in the feature folder
 3. If none found, tell user to run `/5:review-code` first and STOP
 4. Parse each finding and its action marker: `[FIX]`, `[SKIP]`, `[MANUAL]`

package/src/commands/5/update.md

@@ -0,0 +1,17 @@
+---
+name: 5:update
+description: Update the 5-Phase Workflow to the latest version
+allowed-tools: Bash
+context: inherit
+user-invocable: true
+---
+
+# Update 5-Phase Workflow
+
+Run the upgrade command to update to the latest version:
+
+```bash
+npx 5-phase-workflow --upgrade
+```
+
+After the upgrade completes, confirm the new version was installed by checking `.claude/.5/version.json`.

package/src/commands/5/verify-implementation.md

@@ -8,31 +8,6 @@ user-invocable: true
 
 # Verify Implementation (Phase 4)
 
-## Prerequisites Check
-
-**CRITICAL: Check for configuration before proceeding (skip for CONFIGURE feature)**
-
-If the feature argument is `CONFIGURE`, skip this check entirely — the CONFIGURE workflow is what creates the config file.
-
-For all other features, run this check:
-
-```bash
-if [ ! -f ".claude/.5/config.json" ]; then
-  echo "❌ Configuration not found"
-  echo ""
-  echo "Please run /5:configure first to set up your project."
-  echo ""
-  echo "The configure command will:"
-  echo "  • Detect your project type and build commands"
-  echo "  • Set up ticket tracking conventions"
-  echo "  • Generate documentation (CLAUDE.md)"
-  echo "  • Create project-specific skills"
-  exit 1
-fi
-```
-
-**If config doesn't exist and the feature is NOT `CONFIGURE`, STOP IMMEDIATELY. Do not proceed with the workflow.**
-
 Verify that an implementation is complete, correct, and meets feature requirements through multi-layer verification.
 
 ## Scope
@@ -127,7 +102,7 @@ Task tool call:
   model: sonnet
   description: "Verify feature completeness for {feature-name}"
   prompt: |
-    You are verifying that an implementation satisfies its feature specification.
+    Verify that an implementation satisfies its feature specification.
 
     ## Feature Specification
     {full text of feature.md}
@@ -136,61 +111,33 @@ Task tool call:
     {full text of plan.md}
 
     ## Instructions
-
-    1. **Read each implemented file** listed in the components table below:
-       {components table from plan.md}
-
-    2. **Check acceptance criteria** from the feature spec.
-       For each acceptance criterion, determine:
-       - SATISFIED — code clearly implements this criterion (cite file:line as evidence)
-       - NOT SATISFIED — no code found that implements this criterion
-
-    3. **Check functional requirements** from the feature spec.
-       For each requirement, determine:
-       - IMPLEMENTED — code implements this requirement (cite file:line)
-       - NOT IMPLEMENTED — no code found for this requirement
-
-    4. **Check component completeness** from the plan.
-       For each component in the table, read the file and determine:
-       - COMPLETE — file exists and implements what the description says
-       - PARTIAL — file exists but is missing described functionality
-       - MISSING — file does not exist
+    1. Read each file in the components table
+    2. For each acceptance criterion: SATISFIED (cite file:line) or NOT_SATISFIED
+    3. For each requirement: IMPLEMENTED (cite file:line) or NOT_IMPLEMENTED
+    4. For each component: COMPLETE, PARTIAL (note what's missing), or MISSING
 
     ## Output Format
-    Return EXACTLY this structure:
-
-    ACCEPTANCE_CRITERIA:
-    - criterion: "{text of criterion}"
-      status: SATISFIED | NOT SATISFIED
-      evidence: "{file:line}" or "none"
-      notes: "{brief explanation}"
-
-    REQUIREMENTS:
-    - requirement: "{text of requirement}"
-      status: IMPLEMENTED | NOT IMPLEMENTED
-      evidence: "{file:line}" or "none"
-      notes: "{brief explanation}"
-
-    COMPONENTS:
-    - component: "{component name}"
-      file: "{file path}"
-      status: COMPLETE | PARTIAL | MISSING
-      notes: "{what's missing if partial}"
-
-    SUMMARY:
-    - criteria_satisfied: {N}/{M}
-    - requirements_implemented: {N}/{M}
-    - components_complete: {N}/{M}
-
-    ## Rules
-    - Read every file referenced in the components table
-    - Be precise with evidence — cite actual file paths and line numbers
-    - PARTIAL means the file exists but is missing specific functionality described in the plan
-    - Do NOT interact with the user
-    - Do NOT modify any files
+    End with a results block:
+
+    ---VERIFICATION---
+    ---ACCEPTANCE_CRITERIA---
+    {SATISFIED | NOT_SATISFIED | criterion text | file:line or "none"} (one per line)
+    ---REQUIREMENTS---
+    {IMPLEMENTED | NOT_IMPLEMENTED | requirement text | file:line or "none"} (one per line)
+    ---COMPONENTS---
+    {COMPLETE | PARTIAL | MISSING | component name | file path | notes} (one per line)
+    ---SUMMARY---
+    criteria_satisfied: {N}/{M}
+    requirements_implemented: {N}/{M}
+    components_complete: {N}/{M}
+    ---END_VERIFICATION---
+
+    Rules: Read every file. Cite file:line evidence. Do NOT modify files or interact with user.
 ```
 
-Parse the agent's structured output into:
+Parse the `---VERIFICATION---` ... `---END_VERIFICATION---` block. If malformed, fall back to extracting summary counts from prose.
+
+From the parsed output, collect:
 - Acceptance criteria results (satisfied/not satisfied counts)
 - Requirements results (implemented/not implemented counts)
 - Component completeness results (complete/partial/missing counts)
@@ -254,53 +201,10 @@ Update `.5/features/{feature-name}/state.json`:
 
 ### Step 8: Handle Results
 
-**If PASSED:**
-
-```
-Verification passed!
-
-Layer 1 (Infrastructure): All files exist, build OK, tests OK
-Layer 2 (Feature Completeness): {N}/{N} criteria satisfied, {N}/{N} requirements implemented
-Layer 3 (Quality): {N}/{N} new files have tests
-
-Report: .5/{feature-name}/verification.md
-```
+Report the status with layer-by-layer summary and link to `verification.md`.
 
-**If `git.autoCommit: false` (default):** offer to commit.
-
-```
-Would you like to commit these changes?
-```
-
-Use AskUserQuestion with options:
-1. "Yes - commit now (Recommended)"
-2. "No - I'll commit later"
-
-If yes: stage and commit with message format `{TICKET-ID} {description}`.
-
-**If `git.autoCommit: true`:** skip the commit offer.
-
-```
-Changes were already committed during implementation ({N} atomic commits).
-```
-
-Then go to Step 11 (Next Steps).
-
-**If PARTIAL or FAILED:**
-
-```
-Verification {status}.
-
-Layer 1 (Infrastructure): {summary}
-Layer 2 (Feature Completeness): {summary}
-Layer 3 (Quality): {summary}
-
-{Count} issue(s) found. Generating fix plan...
-
-Report: .5/{feature-name}/verification.md
-```
-
-Continue to Step 9.
+- **PASSED:** If `git.autoCommit: false`, offer to commit via AskUserQuestion. If `git.autoCommit: true`, note commits were already made. Go to Step 11.
+- **PARTIAL or FAILED:** Note issue count, continue to Step 9.
 
 ### Step 9: Generate Fix Plan (PARTIAL or FAILED only)
 
@@ -337,86 +241,15 @@ Use AskUserQuestion:
 
 **If user selects "Apply fixes automatically":**
 
-For each fix in the fix plan, spawn an agent following the same pattern as `implement-feature`:
-
-- **simple** fixes → `haiku` model
-- **moderate** fixes → `haiku` or `sonnet` depending on context
-- **complex** fixes → `sonnet` model
-
-Group independent fixes for parallel execution. Fixes modifying the same file must be sequential.
-
-```
-Task tool call:
-  subagent_type: general-purpose
-  model: {based on complexity}
-  description: "Fix: {short description}"
-  prompt: |
-    You are fixing a verification issue in a codebase.
-
-    ## Issue
-    Category: {infrastructure | feature-gap | quality}
-    File: {file-path}
-    Issue: {description of what's wrong}
-    Fix: {description of what to do}
-
-    ## Context
-    {relevant section from plan.md or feature.md}
-
-    ## Instructions
-    1. If creating a new file: find a similar existing file using Glob, read it to understand the pattern, create the new file following that pattern
-    2. If modifying a file: read the file, make the described change
-    3. Verify the file exists after changes
-    4. Report what you did
-
-    Use Glob to find similar files. Use Read to understand patterns. Use Write/Edit to create/modify files.
-```
-
-After all fixes are applied, re-run build and tests:
-
-```bash
-{build-command}
-{test-command}
-```
-
-**If `git.autoCommit: true` and fixes succeeded (build + tests pass):**
+Spawn agents following `implement-feature` patterns (simple→haiku, moderate→haiku/sonnet, complex→sonnet). Group independent fixes for parallel execution; same-file fixes must be sequential.
 
-Auto-commit the fix files:
-```bash
-# Stage only the specific fix files
-git add {fix-file-1} {fix-file-2} ...
+Each agent prompt includes: category, file path, issue description, fix description, and relevant context from plan/feature spec. Agent finds similar files via Glob, reads patterns, applies fix with Write/Edit.
 
-# Commit with ticket ID
-git commit -m "{ticket-id} fix verification issues
+After fixes: re-run build and tests. If `git.autoCommit: true` and fixes succeeded, commit fix files with `{ticket-id} fix verification issues`. Update `fix-plan.md` with APPLIED/FAILED status per fix.
 
-- {concise fix 1}
-- {concise fix 2}"
-```
-
-If commit fails → log warning, continue.
+**If user selects manual fix:** save `fix-plan.md` and exit with re-run guidance.
 
-Update `fix-plan.md` with results:
-- Mark each fix as APPLIED / FAILED
-- Record build and test results after fixes
-
-Report to user:
-```
-Applied {N} fixes.
-
-Build: {status}
-Tests: {status}
-{If git.autoCommit was true: "Commit: {Success | Failed | Skipped}"}
-
-{If any fixes failed, list them}
-
-Updated: .5/{feature-name}/fix-plan.md
-```
-
-**If user selects manual fix:** exit with guidance.
-```
-Fix plan saved: .5/{feature-name}/fix-plan.md
-
-When ready, re-run: /5:verify-implementation {feature-name}
-```
+**Iteration limit:** On 3rd+ verify+fix cycle, warn user to consider manual fixes or revisiting the plan.
 
 ### Step 11: Next Steps
 

package/src/hooks/check-updates.js

@@ -53,24 +53,21 @@ async function checkForUpdates(workspaceDir) {
 
   // Update last check time
   versionData.updateCheckLastRun = new Date().toISOString();
-  fs.writeFileSync(versionFile, JSON.stringify(versionData, null, 2));
 
   // Compare versions
   const installed = versionData.installedVersion;
   const latestVersion = await getLatestVersion();
 
-  if (!latestVersion || installed === latestVersion) {
-    // No update available
-    process.exit(0);
-  }
-
-  // Check if update is available (installed < latest)
-  if (compareVersions(installed, latestVersion) < 0) {
-    // Show update notification
-    console.log(`\n\x1b[34mℹ\x1b[0m Update available: ${installed} → ${latestVersion}`);
-    console.log(`  Run: \x1b[1mnpx 5-phase-workflow --upgrade\x1b[0m\n`);
+  if (latestVersion && compareVersions(installed, latestVersion) < 0) {
+    // Update available — persist for statusline to display
+    versionData.latestAvailableVersion = latestVersion;
+  } else {
+    // No update (or network failure) — clear any stale value
+    versionData.latestAvailableVersion = null;
   }
 
+  // Single consolidated write
+  fs.writeFileSync(versionFile, JSON.stringify(versionData, null, 2));
   process.exit(0);
 }
 
@@ -107,9 +104,10 @@ async function getLatestVersion() {
 }
 
 // Compare semver versions
+// Uses parseInt to handle pre-release tags (e.g., "2-beta" → 2)
 function compareVersions(v1, v2) {
-  const parts1 = v1.split('.').map(Number);
-  const parts2 = v2.split('.').map(Number);
+  const parts1 = v1.split('.').map(p => parseInt(p, 10) || 0);
+  const parts2 = v2.split('.').map(p => parseInt(p, 10) || 0);
 
   for (let i = 0; i < 3; i++) {
     if (parts1[i] > parts2[i]) return 1;

package/src/hooks/config-guard.js

@@ -0,0 +1,30 @@
+#!/usr/bin/env node
+const fs = require('fs');
+const path = require('path');
+
+let input = '';
+process.stdin.setEncoding('utf8');
+process.stdin.on('data', chunk => input += chunk);
+process.stdin.on('end', () => {
+  try {
+    const data = JSON.parse(input);
+    const cwd = data.cwd || process.cwd();
+    const configFile = path.join(cwd, '.claude', '.5', 'config.json');
+
+    if (fs.existsSync(configFile)) {
+      process.exit(0);
+    }
+
+    // No config — block with helpful message
+    process.stderr.write(
+      'Configuration not found. Please run /5:configure first to set up your project.\n\n' +
+      'The configure command will:\n' +
+      '  - Detect your project type and build commands\n' +
+      '  - Set up ticket tracking conventions\n' +
+      '  - Write project configuration'
+    );
+    process.exit(2);
+  } catch (e) {
+    process.exit(0); // Silent failure — don't block on parse errors
+  }
+});