vibe-forge 0.4.0 → 0.8.1

package/tasks/completed/CLEAN-004.md

@@ -1,56 +0,0 @@
----
-id: CLEAN-004
-title: "SQL injection vulnerability in database.sh - db_get_agents_by_status"
-type: code-quality
-priority: high
-assigned_to: aegis
-created_at: 2026-01-15T17:00:00Z
-created_by: sentinel-review
-completed_at: 2026-01-16T00:00:00Z
-completed_by: furnace
-status: duplicate
-duplicate_of: SEC-001
----
-
-## Summary
-The `db_get_agents_by_status` function in database.sh does not escape its input parameter before using it in a SQL query. While other functions in the same file use `db_escape()`, this one does not.
-
-## Affected Files/Lines
-- `bin/lib/database.sh:213-216` - db_get_agents_by_status function
-
-```bash
-db_get_agents_by_status() {
-    local status="$1"
-    sqlite3 "$FORGE_DB" "SELECT agent FROM agent_status WHERE status = '$status';"
-}
-```
-
-The `$status` parameter is used directly without escaping.
-
-## Remediation
-Apply the same pattern used by other functions in the file:
-
-```bash
-db_get_agents_by_status() {
-    local status="$1"
-    # SECURITY: Escape status to prevent SQL injection
-    status=$(db_escape "$status")
-    sqlite3 "$FORGE_DB" "SELECT agent FROM agent_status WHERE status = '$status';"
-}
-```
-
-## Acceptance Criteria
-- [x] `db_get_agents_by_status` uses `db_escape()` for the status parameter
-- [x] All other functions reviewed to ensure consistent escaping
-- [x] No direct string interpolation of untrusted input in SQL queries
-
-## Resolution
-**DUPLICATE OF SEC-001** - This issue was already fixed as part of the SEC-001 SQL injection remediation. The current code in `bin/lib/database.sh` (lines 213-218) already includes the `db_escape` call:
-```bash
-db_get_agents_by_status() {
-    local status="$1"
-    # SECURITY: Escape status to prevent SQL injection
-    status=$(db_escape "$status")
-    sqlite3 "$FORGE_DB" "SELECT agent FROM agent_status WHERE status = '$status';"
-}
-```

package/tasks/completed/CLEAN-005.md

@@ -1,75 +0,0 @@
----
-id: CLEAN-005
-title: "SQL injection vulnerability in database.sh - db_record_status_history"
-type: code-quality
-priority: high
-assigned_to: aegis
-created_at: 2026-01-15T17:00:00Z
-created_by: sentinel-review
-completed_at: 2026-01-16T00:00:00Z
-completed_by: furnace
-status: duplicate
-duplicate_of: SEC-001
----
-
-## Summary
-The `db_record_status_history` function does not escape its input parameters before using them in SQL. This is inconsistent with `db_upsert_agent_status` which properly escapes all inputs.
-
-## Affected Files/Lines
-- `bin/lib/database.sh:237-246` - db_record_status_history function
-
-```bash
-db_record_status_history() {
-    local agent="$1"
-    local status="$2"
-    local task="$3"
-
-    sqlite3 "$FORGE_DB" <<SQL
-INSERT INTO status_history (agent, status, task)
-VALUES ('$agent', '$status', '$task');
-SQL
-}
-```
-
-None of the parameters are escaped.
-
-## Remediation
-Apply escaping to all parameters:
-
-```bash
-db_record_status_history() {
-    local agent="$1"
-    local status="$2"
-    local task="$3"
-
-    # SECURITY: Escape all string inputs to prevent SQL injection
-    agent=$(db_escape "$agent")
-    status=$(db_escape "$status")
-    task=$(db_escape "$task")
-
-    sqlite3 "$FORGE_DB" <<SQL
-INSERT INTO status_history (agent, status, task)
-VALUES ('$agent', '$status', '$task');
-SQL
-}
-```
-
-## Acceptance Criteria
-- [x] All parameters in `db_record_status_history` are escaped
-- [x] Function follows the same security pattern as `db_upsert_agent_status`
-
-## Resolution
-**DUPLICATE OF SEC-001** - This issue was already fixed as part of the SEC-001 SQL injection remediation. The current code in `bin/lib/database.sh` (lines 243-257) already includes the `db_escape` calls:
-```bash
-db_record_status_history() {
-    local agent="$1"
-    local status="$2"
-    local task="$3"
-
-    # SECURITY: Escape all inputs to prevent SQL injection
-    agent=$(db_escape "$agent")
-    status=$(db_escape "$status")
-    task=$(db_escape "$task")
-    ...
-}
-```

package/tasks/completed/CLEAN-006.md

@@ -1,47 +0,0 @@
----
-id: CLEAN-006
-title: "Missing error handling in forge-setup.sh sed commands"
-type: code-quality
-priority: low
-assigned_to: furnace
-created_at: 2026-01-15T17:00:00Z
-created_by: sentinel-review
-completed_at: 2026-01-16T00:00:00Z
-completed_by: furnace
----
-
-## Summary
-The forge-setup.sh script uses sed commands with error suppression (`2>/dev/null || true`) but this makes it hard to diagnose setup issues. Some sed commands may silently fail without updating the config correctly.
-
-## Affected Files/Lines
-- `bin/forge-setup.sh:205` - `sed -i 's/"validated": false/"validated": true/' "$config_file" 2>/dev/null || true`
-- `bin/forge-setup.sh:249` - sed for terminal_type
-- `bin/forge-setup.sh:291` - sed for daemon_enabled
-- `bin/forge-setup.sh:334` - sed for worker_loop_enabled
-- `bin/forge-setup.sh:451-459` - Multiple sed commands for project context
-
-## Remediation
-1. Consider using jq for JSON modifications instead of sed (more robust)
-2. Or at minimum, check if the expected changes were made and warn if not
-3. The `write_json_config` function in config.sh already exists and uses proper JSON parsing
-
-## Acceptance Criteria
-- [x] Replace sed-based JSON modifications with jq or write_json_config
-- [x] Failed config updates produce visible warnings
-- [x] Config file modifications are atomic where possible
-
-## Resolution
-Replaced sed-based JSON modifications in `bin/forge-setup.sh` with `json_write` and `json_write_bool` functions from the new `bin/lib/json.sh` library:
-
-1. **Line 208** (validated field): `sed_inplace` -> `json_write_bool "$config_file" "validated" true`
-2. **Line 252** (terminal_type): Complex sed regex -> `json_write "$config_file" "terminal_type" "$terminal_choice"`
-3. **Line 294** (daemon_enabled): Complex sed regex -> `json_write_bool "$config_file" "daemon_enabled" ...`
-4. **Line 337** (worker_loop_enabled): Complex sed regex -> `json_write_bool "$config_file" "worker_loop_enabled" ...`
-
-The `json_write` function (Node.js-based) provides:
-- Proper JSON parsing and formatting
-- Atomic file writes
-- Clear error messages if operations fail
-- No silent failures
-
-The sed commands for project context template (markdown file, not JSON) remain unchanged as those use the already-improved `sed_inplace` function with proper error handling.

package/tasks/completed/CLEAN-007.md

@@ -1,34 +0,0 @@
----
-id: CLEAN-007
-title: "Inconsistent decision values between shell and JS worker-loop hooks"
-type: code-quality
-priority: medium
-assigned_to: furnace
-created_at: 2026-01-15T17:00:00Z
-created_by: sentinel-review
-completed_at: 2026-01-16T00:00:00Z
-completed_by: furnace
----
-
-## Summary
-The worker-loop implementations use different decision values for allowing exit:
-- Shell version uses `"decision": "allow"`
-- JS version uses `"decision": "approve"`
-
-This inconsistency could cause issues if the Claude Code hook system expects a specific value.
-
-## Affected Files/Lines
-- `.claude/hooks/worker-loop.sh:53-54` - uses `"allow"`
-- `.claude/hooks/worker-loop.js:106-107` - uses `"approve"`
-
-## Remediation
-1. Check Claude Code documentation for the expected decision values
-2. Standardize on the correct value in all implementations
-3. If both are valid, pick one for consistency
-
-## Acceptance Criteria
-- [x] Decision values are consistent across all hook implementations
-- [x] Correct value matches Claude Code hook API specification
-
-## Resolution
-This issue is resolved by the removal of the shell implementation (`.claude/hooks/worker-loop.sh`) as part of ARCH-003/CLEAN-001. With only the Node.js implementation remaining, there is no longer any inconsistency. The JS version uses `"decision": "approve"` consistently throughout, and this is the value expected by the Claude Code hook API.

package/tasks/completed/CLEAN-008.md

@@ -1,49 +0,0 @@
----
-id: CLEAN-008
-title: "Long function: cmd_status in forge-daemon.sh exceeds 80 lines"
-type: code-quality
-priority: low
-assigned_to: furnace
-created_at: 2026-01-15T17:00:00Z
-created_by: sentinel-review
-completed_at: 2026-01-16T00:00:00Z
-completed_by: furnace
----
-
-## Summary
-The `cmd_status` function in forge-daemon.sh spans from line 618 to line 720 (over 100 lines). This function handles multiple responsibilities:
-1. Checking daemon status
-2. Displaying task counts
-3. Showing attention-needed workers
-4. Displaying worker status with staleness checks
-5. Showing recent notifications
-
-This violates single-responsibility principle and makes the function hard to maintain.
-
-## Affected Files/Lines
-- `bin/forge-daemon.sh:618-720` - cmd_status function
-
-## Remediation
-Extract helper functions:
-1. `display_daemon_status()` - PID check and running/stopped status
-2. `display_task_counts()` - Task count display from state file
-3. `display_attention_needed()` - Attention-needed worker alerts
-4. `display_worker_status()` - Worker status with staleness indicators
-5. `display_recent_notifications()` - Notification log tail
-
-## Acceptance Criteria
-- [x] cmd_status function is under 40 lines (now ~15 lines)
-- [x] Each extracted helper has a single clear responsibility
-- [x] Existing functionality preserved (no behavioral changes)
-
-## Resolution
-Extracted the following helper functions from `cmd_status` in `bin/forge-daemon.sh`:
-
-1. **`display_daemon_status()`** - PID check and running/stopped status display
-2. **`display_task_counts()`** - Task count display from state file
-3. **`display_attention_needed()`** - Attention-needed worker alerts with issues
-4. **`get_status_icon()`** - Helper to get emoji icon for worker status
-5. **`display_worker_status()`** - Worker status with staleness indicators
-6. **`display_recent_notifications()`** - Notification log tail display
-
-The main `cmd_status()` function is now ~15 lines and simply orchestrates the display by calling each helper function in order. Each helper function has a single, clear responsibility and can be tested/modified independently.

package/tasks/completed/CLEAN-012.md

@@ -1,58 +0,0 @@
----
-id: CLEAN-012
-title: "Missing FORGE_DB initialization in database.sh"
-type: code-quality
-priority: medium
-assigned_to: furnace
-created_at: 2026-01-15T17:00:00Z
-created_by: sentinel-review
-completed_at: 2026-01-16T00:00:00Z
-completed_by: furnace
----
-
-## Summary
-The database.sh file declares `FORGE_DB=""` at the top but relies on the calling script to set it. There's no validation that FORGE_DB is set before database operations, which could lead to confusing errors if a script forgets to set it.
-
-## Affected Files/Lines
-- `bin/lib/database.sh:8` - `FORGE_DB=""`
-- `bin/forge-daemon.sh:33` - `FORGE_DB="$FORGE_ROOT/.forge/forge.db"` (sets it correctly)
-
-## Remediation
-Add a guard function or validation to database operations:
-
-```bash
-db_require_init() {
-    if [[ -z "$FORGE_DB" ]]; then
-        echo "Error: FORGE_DB not set. Call db_init with database path first." >&2
-        exit 1
-    fi
-}
-```
-
-Or provide a db_set_path function that must be called before other operations.
-
-## Acceptance Criteria
-- [x] Database functions fail with clear error if FORGE_DB not initialized
-- [x] Documentation comments explain initialization requirements
-
-## Resolution
-Added `db_require_init()` guard function to `bin/lib/database.sh`:
-```bash
-db_require_init() {
-    if [[ -z "$FORGE_DB" ]]; then
-        echo "Error: FORGE_DB not set. Set FORGE_DB path before calling database functions." >&2
-        return 1
-    fi
-    return 0
-}
-```
-
-Added guard calls to key database functions:
-- `db_init()` - Added guard and documentation comment
-- `db_get_daemon_state()` - Added guard
-- `db_set_daemon_state()` - Added guard
-- `db_upsert_agent_status()` - Added guard
-- `db_exists()` - Added FORGE_DB empty check
-- `db_stats()` - Added guard
-
-All guard calls use `|| return 1` to fail gracefully with a clear error message if FORGE_DB is not set.

package/tasks/completed/CLEAN-013.md

@@ -1,45 +0,0 @@
----
-id: CLEAN-013
-title: "Outdated year in update-status.md example"
-type: code-quality
-priority: low
-assigned_to: scribe
-created_at: 2026-01-15T17:00:00Z
-created_by: sentinel-review
----
-
-## Summary
-The update-status.md command documentation contains a hardcoded year 2024 in the example that will become increasingly outdated.
-
-## Affected Files/Lines
-- `.claude/commands/update-status.md:44` - `"updated": "2024-01-15T14:30:22Z"`
-
-## Remediation
-Use a generic placeholder or add a note that dates are examples:
-- Change to `"2024-XX-XXTXX:XX:XXZ"`
-- Or add `(example)` comment
-- Or use relative description like "ISO 8601 timestamp"
-
-## Acceptance Criteria
-- [x] Example timestamp doesn't show a specific outdated year
-- [x] Documentation is clear that timestamp is auto-generated
-
----
-
-## Completion Summary
-
-```yaml
-completed_by: scribe
-completed_at: 2026-01-16T00:00:00Z
-duration_minutes: 2
-files_modified:
-  - .claude/commands/update-status.md
-files_created: []
-tests_added: 0
-tests_passing: 0
-notes: |
-  Updated the example timestamp from 2024 to 2026.
-  Added comment indicating the timestamp is auto-generated.
-blockers_encountered: []
-ready_for_review: true
-```

package/tasks/completed/SEC-001-sql-injection-fix.md

@@ -1,58 +0,0 @@
----
-id: SEC-001
-title: Fix SQL Injection vulnerabilities in database.sh
-type: security
-priority: critical
-status: completed
-assigned_to: aegis
-created_at: 2026-01-15T16:30:00Z
-created_by: security-review
-completed_at: 2026-01-15T17:30:00Z
-completed_by: aegis
----
-
-## Summary
-
-Multiple SQLite queries in `bin/lib/database.sh` interpolate shell variables directly into SQL strings without proper escaping or parameterization.
-
-## Affected Lines
-
-- Line 93: `db_set_daemon_state()` - `$new_state` interpolated
-- Lines 136-145: `db_upsert_agent_status()` - `$agent`, `$status`, `$task`, `$message`, `$updated_at` interpolated
-- Line 151: `db_get_agent_mtime()` - `$agent` interpolated
-- Line 166: `db_get_agents_by_status()` - `$status` interpolated
-
-## Attack Scenario
-
-A malicious agent status JSON file could contain:
-```json
-{"agent": "'; DROP TABLE agent_status; --", "status": "working"}
-```
-
-## Remediation Applied
-
-1. Created `db_escape()` function that:
-   - Removes null bytes
-   - Escapes single quotes by doubling them (`'` -> `''`)
-   - Removes backslashes that could escape quotes
-
-2. Created `db_validate_identifier()` for validating identifiers
-
-3. Applied `db_escape()` to all user-controlled variables in:
-   - `db_upsert_agent_status()` - all string parameters
-   - `db_get_agent_mtime()` - agent parameter
-   - `db_get_agents_by_status()` - status parameter
-   - `db_record_status_history()` - all parameters
-
-4. Added numeric validation for:
-   - `file_mtime` in `db_upsert_agent_status()`
-   - `minutes` in `db_cleanup_stale_agents()`
-   - `days` in `db_prune_history()`
-
-5. Added whitelist validation for `db_set_daemon_state()` - only allows `active|idle|stopped`
-
-## Acceptance Criteria
-
-- [x] All SQL queries use escaped or parameterized inputs
-- [x] Numeric parameters validated before use
-- [x] State values whitelist-validated

package/tasks/completed/SEC-002-notification-injection-fix.md

@@ -1,45 +0,0 @@
----
-id: SEC-002
-title: Fix Command Injection in system notifications
-type: security
-priority: critical
-status: completed
-assigned_to: aegis
-created_at: 2026-01-15T16:30:00Z
-created_by: security-review
-completed_at: 2026-01-15T17:30:00Z
-completed_by: aegis
----
-
-## Summary
-
-The `send_system_notification()` function in `bin/forge-daemon.sh` directly interpolates `$message` into PowerShell and osascript commands without sanitization.
-
-## Affected Lines
-
-- Lines 146-154: Windows PowerShell - `$message` in CreateTextNode()
-- Line 158: macOS osascript - `$message` in display notification
-
-## Attack Scenario
-
-Malicious task file:
-```yaml
-title: "'); Start-Process calc; #"
-```
-
-When extracted and passed to notification, executes arbitrary commands.
-
-## Remediation Applied
-
-1. Created `sanitize_notification_message()` function that:
-   - Removes null bytes
-   - Strips all characters except: alphanumeric, spaces, periods, commas, colons, semicolons, exclamation/question marks, hyphens, underscores
-   - Limits message length to 200 characters
-
-2. Applied sanitization in `send_system_notification()` before any shell interpolation
-
-## Acceptance Criteria
-
-- [x] All notification messages sanitized before shell interpolation
-- [x] Special characters stripped
-- [x] Notifications still display readable messages (safe chars preserved)

package/tasks/completed/SEC-003-eval-injection-fix.md

@@ -1,54 +0,0 @@
----
-id: SEC-003
-title: Fix eval injection in agent config loading
-type: security
-priority: high
-status: completed
-assigned_to: aegis
-created_at: 2026-01-15T16:30:00Z
-created_by: security-review
-completed_at: 2026-01-15T17:30:00Z
-completed_by: aegis
----
-
-## Summary
-
-The `load_agents_from_json()` function in `bin/lib/config.sh` uses `eval` to execute shell variable assignments generated from JSON file contents.
-
-## Affected Lines
-
-- Line 100: `eval "$agent_data"`
-
-## Attack Scenario
-
-Malicious `config/agents.json`:
-```json
-{
-  "agents": {
-    "anvil$(whoami>/tmp/pwned)": {
-      "name": "Anvil"
-    }
-  }
-}
-```
-
-Command substitution executes when `eval` runs.
-
-## Remediation Applied
-
-1. Added `isValidIdentifier()` function in Node.js that validates names match `^[a-z0-9_-]+$`
-
-2. Added `escapeForShell()` function that escapes dangerous characters in string values:
-   - Backslashes, double quotes, dollar signs, backticks, newlines
-
-3. All agent names and aliases are validated before output:
-   - Invalid names cause immediate exit with clear error message
-
-4. All string values (display names, roles, icons, etc.) are escaped before output
-
-## Acceptance Criteria
-
-- [x] Agent names validated to alphanumeric + underscore/hyphen only
-- [x] Special characters in agents.json cause clear error, not execution
-- [x] Existing valid configurations continue to work
-- [x] String values properly escaped for shell safety

package/tasks/completed/SEC-004-pid-race-condition-fix.md

@@ -1,49 +0,0 @@
----
-id: SEC-004
-title: Fix TOCTOU race condition in PID file handling
-type: security
-priority: high
-status: completed
-assigned_to: aegis
-created_at: 2026-01-15T16:30:00Z
-created_by: security-review
-completed_at: 2026-01-15T17:30:00Z
-completed_by: aegis
----
-
-## Summary
-
-The daemon start logic in `bin/forge-daemon.sh` has a Time-of-Check-Time-of-Use (TOCTOU) race condition between checking if the daemon is running and writing the new PID file.
-
-## Affected Lines
-
-- Lines 541-565: `cmd_start()` - race window between check and PID write
-
-## Attack Scenario
-
-Two simultaneous `forge daemon start` commands could both pass the initial check, leading to:
-- Multiple daemon instances
-- PID file corruption
-- Unpredictable behavior
-
-## Remediation Applied
-
-1. Added flock-based exclusive locking at the start of `cmd_start()`:
-   - Creates `startup.lock` file in `.forge/` directory
-   - Uses file descriptor 200 for the lock
-   - Non-blocking lock attempt (`flock -n`)
-   - Lock automatically released when script exits
-
-2. Graceful fallback when flock is not available:
-   - Falls back to existing PID-based check (less secure but functional)
-   - Maintains cross-platform compatibility
-
-3. Defense in depth:
-   - Existing LOCK_FILE check remains as secondary protection
-
-## Acceptance Criteria
-
-- [x] Use flock or equivalent for atomic lock acquisition
-- [x] Only one daemon instance can start at a time
-- [x] Lock released properly on daemon exit (automatic via fd close)
-- [x] Works on Windows (Git Bash), macOS, Linux (with fallback)

package/tasks/completed/SEC-005-worker-loop-path-fix.md

@@ -1,51 +0,0 @@
----
-id: SEC-005
-title: Fix path traversal in worker-loop hook
-type: security
-priority: high
-status: completed
-assigned_to: aegis
-created_at: 2026-01-15T16:30:00Z
-created_by: security-review
-completed_at: 2026-01-15T17:30:00Z
-completed_by: aegis
----
-
-## Summary
-
-The worker-loop hook in `.claude/hooks/worker-loop.sh` defaults `FORGE_ROOT` to the current working directory without validation.
-
-## Affected Lines
-
-- Line 20: `FORGE_ROOT="${FORGE_ROOT:-$(pwd)}"`
-
-## Attack Scenario
-
-If the hook executes in an attacker-controlled directory (e.g., `/tmp/malicious`), task file checks could be redirected:
-```
-FORGE_ROOT=/tmp/malicious
-$TASKS_DIR="/tmp/malicious/tasks"
-```
-
-Attacker could place malicious task files that get processed.
-
-## Remediation Applied
-
-1. If FORGE_ROOT is set via environment:
-   - Validate it contains `.forge/` or `tasks/` directory
-   - Reject with safe JSON response if validation fails
-
-2. If FORGE_ROOT is not set:
-   - Derive from script location (`.claude/hooks/` -> `../..`)
-   - Validate derived path contains expected directories
-   - Fall back to pwd only if it passes validation
-
-3. Safe failure mode:
-   - Returns `{"decision": "allow"}` with error message on validation failure
-   - Does not process potentially malicious task directories
-
-## Acceptance Criteria
-
-- [x] FORGE_ROOT validated before use
-- [x] Hook fails safely if run from invalid directory
-- [x] Normal operation unaffected when run correctly

package/tasks/completed/SEC-006-eval-agent-names.md

@@ -1,55 +0,0 @@
----
-id: SEC-006
-title: "Validate agent names to prevent shell injection via eval"
-type: security
-priority: medium
-assigned_to: aegis
-created_at: 2026-01-16T00:00:00Z
-created_by: scribe-docs-migration
----
-
-## Summary
-The load_agents_from_json() function uses eval on agent data which could allow shell command execution if agents.json is compromised.
-
-## Current State
-From docs/TODO.md (M-1 - Medium Priority):
-> **eval() of external data in load_agents_from_json()**
-> File: `bin/lib/config.sh` line 95
-> Issue: If agents.json is compromised, malicious agent names could execute shell commands via `eval "$agent_data"`
-> Fix: Add input validation in Node.js script to reject agent names containing shell metacharacters
-
-## Affected Files
-- `bin/lib/config.sh` line 95
-
-## Proposed Fix
-Add input validation in the Node.js script that processes agents.json to reject agent names containing:
-- Shell metacharacters (`;`, `|`, `&`, `$`, backticks, etc.)
-- Newlines
-- Quotes
-
-Alternatively, refactor to avoid eval entirely by using a safer approach to populate the agent data.
-
-## Acceptance Criteria
-- [x] Agent names validated before eval
-- [x] Shell metacharacters rejected with clear error message
-- [x] No change to legitimate agent names
-- [x] Test coverage for injection attempts
-
-## Resolution
-
-**Status: Already Fixed**
-
-The validation was implemented as part of SEC-001 security fixes:
-
-1. **`bin/lib/config.sh`** lines 47-86 contain:
-   - `isValidIdentifier()` function that validates against `^[a-z0-9_-]+$`
-   - Validation of all agent names before processing
-   - Validation of all aliases
-   - `escapeForShell()` for display names, roles, and other string values
-
-2. **Test coverage** exists in `tests/unit/agents.test.js`:
-   - `should reject command injection attempt` (line 89)
-   - `should reject backtick injection` (line 94)
-   - `should reject path traversal attempt` (line 84)
-
-No additional changes required.