vibe-forge 0.8.2 → 0.8.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,194 +1,194 @@
1
- # Vibe Forge Architecture
2
-
3
- This document describes the architectural decisions and structure of the Vibe Forge codebase.
4
-
5
- ## Language Strategy
6
-
7
- Vibe Forge uses a **hybrid Bash/Node.js architecture** with the following rationale:
8
-
9
- ### Bash (Primary for Scripts)
10
-
11
- The core CLI and daemon are implemented in Bash because:
12
-
13
- 1. **Native shell integration** - Vibe Forge orchestrates terminal sessions and Claude Code processes, which are inherently shell operations
14
- 2. **Unix philosophy** - Small composable scripts that can be debugged, piped, and modified easily
15
- 3. **Transparency** - Users can inspect and modify scripts without build steps
16
- 4. **Git Bash compatibility** - Windows users with Git Bash can run the same scripts
17
-
18
- Files in Bash:
19
- - `bin/forge.sh` - Main CLI entry point
20
- - `bin/forge-setup.sh` - Setup and initialization
21
- - `bin/forge-spawn.sh` - Terminal spawning orchestration
22
- - `bin/forge-daemon.sh` - Background daemon for task monitoring
23
- - `bin/lib/*.sh` - Shared libraries (colors, config, agents, database, json, util)
24
-
25
- ### Node.js (Cross-Platform Utilities)
26
-
27
- Node.js is used where cross-platform compatibility or complex logic is needed:
28
-
29
- 1. **npx installer** - `bin/cli.js` runs via npx before Vibe Forge is installed
30
- 2. **Terminal detection** - `bin/lib/terminal.js` detects and spawns terminals across Windows/macOS/Linux
31
- 3. **JSON parsing** - All Bash scripts use Node.js for JSON via `bin/lib/json.sh` wrapper
32
- 4. **Claude hooks** - `.claude/hooks/worker-loop.js` runs as Claude Code hook
33
- 5. **Dashboard server** - `bin/dashboard/server.js` provides HTTP + WebSocket for the web UI
34
-
35
- ### Design Principles
36
-
37
- 1. **Single Source of Truth** - Configuration in `config/agents.json`, loaded by both languages
38
- 2. **Node.js for JSON** - All JSON parsing uses `bin/lib/json.sh` which calls Node.js (no jq dependency)
39
- 3. **Bash for orchestration** - Process management, file watching, terminal control
40
- 4. **Thin wrappers** - `forge.cmd` on Windows calls Bash via Git Bash
41
-
42
- ### JSON Handling
43
-
44
- All JSON operations use the `json.sh` library which provides:
45
-
46
- ```bash
47
- # Reading JSON
48
- value=$(json_read "$file" "key" "default")
49
-
50
- # Reading multiple keys efficiently
51
- read -r name status task <<< "$(json_read_multi "$file" name status task)"
52
-
53
- # Writing JSON
54
- json_write "$file" "key" "value"
55
- json_write_bool "$file" "enabled" true
56
-
57
- # Pretty printing
58
- json_pretty "$file"
59
-
60
- # Key existence check
61
- if json_has_key "$file" "key"; then ...
62
- ```
63
-
64
- This eliminates the jq dependency while maintaining security (arguments passed to Node.js, not interpolated).
65
-
66
- ## Directory Structure
67
-
68
- ```
69
- vibe-forge/
70
- ├── agents/ # Agent personality definitions
71
- │ ├── anvil/
72
- │ │ └── personality.md
73
- │ ├── furnace/
74
- │ └── ...
75
- ├── bin/ # Executables
76
- │ ├── cli.js # npx entry point (Node.js)
77
- │ ├── forge.sh # Main CLI (Bash)
78
- │ ├── forge.cmd # Windows wrapper
79
- │ ├── forge-setup.sh # Setup script
80
- │ ├── forge-spawn.sh # Terminal spawning
81
- │ ├── forge-daemon.sh # Background daemon
82
- │ ├── dashboard/ # Web dashboard (Node.js)
83
- │ │ ├── server.js # HTTP + WebSocket server
84
- │ │ ├── api/ # REST API endpoints
85
- │ │ │ ├── tasks.js # Task CRUD
86
- │ │ │ ├── agents.js # Agent status
87
- │ │ │ └── dispatch.js # Task dispatch
88
- │ │ └── public/ # Frontend assets
89
- │ │ ├── index.html # Dashboard UI
90
- │ │ ├── style.css # Styles (dark mode)
91
- │ │ └── app.js # Frontend logic
92
- │ └── lib/ # Shared libraries
93
- │ ├── agents.sh # Agent resolution
94
- │ ├── colors.sh # Terminal colors
95
- │ ├── config.sh # Configuration loading
96
- │ ├── constants.sh # Constants (fallback)
97
- │ ├── database.sh # SQLite operations
98
- │ ├── json.sh # JSON utilities (Node.js based)
99
- │ ├── terminal.js # Terminal detection (Node.js)
100
- │ └── util.sh # Utility functions
101
- ├── config/ # Configuration files
102
- │ ├── agents.json # Agent roster (source of truth)
103
- │ └── agent-manifest.yaml # Rich documentation (non-normative)
104
- ├── context/ # Runtime context
105
- │ ├── agent-status/ # Agent status files
106
- │ └── forge-state.yaml # Current forge state
107
- ├── docs/ # Documentation
108
- ├── tasks/ # Task lifecycle folders
109
- │ ├── pending/
110
- │ ├── in-progress/
111
- │ ├── completed/
112
- │ └── ...
113
- └── tests/ # Test suites
114
- ├── unit/ # Jest unit tests (shell functions tested via child_process)
115
- └── helpers/ # Test utilities
116
- ```
117
-
118
- ## Data Flow
119
-
120
- ```
121
- ┌──────────────┐ ┌────────────────┐ ┌──────────────┐
122
- │ CLI Input │ --> │ forge.sh │ --> │ Command │
123
- │ (user) │ │ (dispatch) │ │ Handler │
124
- └──────────────┘ └────────────────┘ └──────────────┘
125
-
126
- v
127
- ┌──────────────┐ ┌────────────────┐ ┌──────────────┐
128
- │ Claude │ <-- │ forge-spawn.sh │ <-- │ Terminal │
129
- │ Code │ │ + terminal.js │ │ Spawning │
130
- └──────────────┘ └────────────────┘ └──────────────┘
131
-
132
- v
133
- ┌──────────────┐ ┌────────────────┐ ┌──────────────┐
134
- │ Tasks │ <-> │ forge-daemon │ <-> │ SQLite │
135
- │ (files) │ │ (monitor) │ │ Database │
136
- └──────────────┘ └────────────────┘ └──────────────┘
137
- ^ ^
138
- │ │
139
- └─────────────────┬─────────────────────────┘
140
-
141
- v
142
- ┌────────────────────┐
143
- │ Dashboard Server │ <-- Browser (http://localhost:2800)
144
- │ (port 2800 🔥) │
145
- │ + WebSocket /ws │
146
- └────────────────────┘
147
- ```
148
-
149
- ### Dashboard Architecture
150
-
151
- The dashboard is a self-contained Node.js server that provides:
152
-
153
- 1. **Static file serving** - HTML, CSS, JS from `bin/dashboard/public/`
154
- 2. **REST API** - Task management, agent status, dispatch at `/api/*`
155
- 3. **WebSocket** - Real-time updates at `/ws`
156
- 4. **Issue detection** - Stale docs, failing tests, security issues
157
-
158
- Port **2800** was chosen as the default because it's the operating temperature of a forge in degrees Fahrenheit. 🔥
159
-
160
- ## Future Considerations
161
-
162
- ### Potential Node.js Migration
163
-
164
- While Option B (hybrid) is the current strategy, a future Node.js migration could provide:
165
-
166
- 1. **Better Windows support** - Native Node.js without Git Bash dependency
167
- 2. **Unified codebase** - Single language to maintain
168
- 3. **Type safety** - TypeScript for larger refactors
169
- 4. **npm ecosystem** - Libraries for terminal control, process management
170
-
171
- Migration path if pursued:
172
- 1. `src/lib/config.ts` - Configuration management
173
- 2. `src/lib/agents.ts` - Agent resolution
174
- 3. `src/lib/database.ts` - SQLite operations
175
- 4. `src/daemon.ts` - Background daemon
176
- 5. `src/forge.ts` - Main CLI (keeping forge.sh as thin wrapper initially)
177
-
178
- ### Requirements for Migration
179
-
180
- Before pursuing full Node.js migration:
181
- - Ensure all Bash-specific functionality can be replicated
182
- - Maintain transparency (scripts users can inspect)
183
- - Keep startup time fast (current scripts are instant)
184
- - Preserve Unix composability where valuable
185
-
186
- ## ADR Summary
187
-
188
- | Decision | Choice | Rationale |
189
- |----------|--------|-----------|
190
- | Primary language | Bash | Native shell integration, transparency |
191
- | JSON parsing | Node.js via json.sh | Security, cross-platform |
192
- | Terminal detection | Node.js | Cross-platform compatibility |
193
- | Windows support | Git Bash + forge.cmd | Maintains Unix-like experience |
194
- | Configuration | JSON (agents.json) | Machine-readable, single source |
1
+ # Vibe Forge Architecture
2
+
3
+ This document describes the architectural decisions and structure of the Vibe Forge codebase.
4
+
5
+ ## Language Strategy
6
+
7
+ Vibe Forge uses a **hybrid Bash/Node.js architecture** with the following rationale:
8
+
9
+ ### Bash (Primary for Scripts)
10
+
11
+ The core CLI and daemon are implemented in Bash because:
12
+
13
+ 1. **Native shell integration** - Vibe Forge orchestrates terminal sessions and Claude Code processes, which are inherently shell operations
14
+ 2. **Unix philosophy** - Small composable scripts that can be debugged, piped, and modified easily
15
+ 3. **Transparency** - Users can inspect and modify scripts without build steps
16
+ 4. **Git Bash compatibility** - Windows users with Git Bash can run the same scripts
17
+
18
+ Files in Bash:
19
+ - `bin/forge.sh` - Main CLI entry point
20
+ - `bin/forge-setup.sh` - Setup and initialization
21
+ - `bin/forge-spawn.sh` - Terminal spawning orchestration
22
+ - `bin/forge-daemon.sh` - Background daemon for task monitoring
23
+ - `bin/lib/*.sh` - Shared libraries (colors, config, agents, database, json, util)
24
+
25
+ ### Node.js (Cross-Platform Utilities)
26
+
27
+ Node.js is used where cross-platform compatibility or complex logic is needed:
28
+
29
+ 1. **npx installer** - `bin/cli.js` runs via npx before Vibe Forge is installed
30
+ 2. **Terminal detection** - `bin/lib/terminal.js` detects and spawns terminals across Windows/macOS/Linux
31
+ 3. **JSON parsing** - All Bash scripts use Node.js for JSON via `bin/lib/json.sh` wrapper
32
+ 4. **Claude hooks** - `.claude/hooks/worker-loop.js` runs as Claude Code hook
33
+ 5. **Dashboard server** - `bin/dashboard/server.js` provides HTTP + WebSocket for the web UI
34
+
35
+ ### Design Principles
36
+
37
+ 1. **Single Source of Truth** - Configuration in `config/agents.json`, loaded by both languages
38
+ 2. **Node.js for JSON** - All JSON parsing uses `bin/lib/json.sh` which calls Node.js (no jq dependency)
39
+ 3. **Bash for orchestration** - Process management, file watching, terminal control
40
+ 4. **Thin wrappers** - `forge.cmd` on Windows calls Bash via Git Bash
41
+
42
+ ### JSON Handling
43
+
44
+ All JSON operations use the `json.sh` library which provides:
45
+
46
+ ```bash
47
+ # Reading JSON
48
+ value=$(json_read "$file" "key" "default")
49
+
50
+ # Reading multiple keys efficiently
51
+ read -r name status task <<< "$(json_read_multi "$file" name status task)"
52
+
53
+ # Writing JSON
54
+ json_write "$file" "key" "value"
55
+ json_write_bool "$file" "enabled" true
56
+
57
+ # Pretty printing
58
+ json_pretty "$file"
59
+
60
+ # Key existence check
61
+ if json_has_key "$file" "key"; then ...
62
+ ```
63
+
64
+ This eliminates the jq dependency while maintaining security (arguments passed to Node.js, not interpolated).
65
+
66
+ ## Directory Structure
67
+
68
+ ```
69
+ vibe-forge/
70
+ ├── agents/ # Agent personality definitions
71
+ │ ├── anvil/
72
+ │ │ └── personality.md
73
+ │ ├── furnace/
74
+ │ └── ...
75
+ ├── bin/ # Executables
76
+ │ ├── cli.js # npx entry point (Node.js)
77
+ │ ├── forge.sh # Main CLI (Bash)
78
+ │ ├── forge.cmd # Windows wrapper
79
+ │ ├── forge-setup.sh # Setup script
80
+ │ ├── forge-spawn.sh # Terminal spawning
81
+ │ ├── forge-daemon.sh # Background daemon
82
+ │ ├── dashboard/ # Web dashboard (Node.js)
83
+ │ │ ├── server.js # HTTP + WebSocket server
84
+ │ │ ├── api/ # REST API endpoints
85
+ │ │ │ ├── tasks.js # Task CRUD
86
+ │ │ │ ├── agents.js # Agent status
87
+ │ │ │ └── dispatch.js # Task dispatch
88
+ │ │ └── public/ # Frontend assets
89
+ │ │ ├── index.html # Dashboard UI
90
+ │ │ ├── style.css # Styles (dark mode)
91
+ │ │ └── app.js # Frontend logic
92
+ │ └── lib/ # Shared libraries
93
+ │ ├── agents.sh # Agent resolution
94
+ │ ├── colors.sh # Terminal colors
95
+ │ ├── config.sh # Configuration loading
96
+ │ ├── constants.sh # Constants (fallback)
97
+ │ ├── database.sh # SQLite operations
98
+ │ ├── json.sh # JSON utilities (Node.js based)
99
+ │ ├── terminal.js # Terminal detection (Node.js)
100
+ │ └── util.sh # Utility functions
101
+ ├── config/ # Configuration files
102
+ │ ├── agents.json # Agent roster (source of truth)
103
+ │ └── agent-manifest.yaml # Rich documentation (non-normative)
104
+ ├── context/ # Runtime context
105
+ │ ├── agent-status/ # Agent status files
106
+ │ └── forge-state.yaml # Current forge state
107
+ ├── docs/ # Documentation
108
+ ├── tasks/ # Task lifecycle folders
109
+ │ ├── pending/
110
+ │ ├── in-progress/
111
+ │ ├── completed/
112
+ │ └── ...
113
+ └── tests/ # Test suites
114
+ ├── unit/ # Jest unit tests (shell functions tested via child_process)
115
+ └── helpers/ # Test utilities
116
+ ```
117
+
118
+ ## Data Flow
119
+
120
+ ```
121
+ ┌──────────────┐ ┌────────────────┐ ┌──────────────┐
122
+ │ CLI Input │ --> │ forge.sh │ --> │ Command │
123
+ │ (user) │ │ (dispatch) │ │ Handler │
124
+ └──────────────┘ └────────────────┘ └──────────────┘
125
+
126
+ v
127
+ ┌──────────────┐ ┌────────────────┐ ┌──────────────┐
128
+ │ Claude │ <-- │ forge-spawn.sh │ <-- │ Terminal │
129
+ │ Code │ │ + terminal.js │ │ Spawning │
130
+ └──────────────┘ └────────────────┘ └──────────────┘
131
+
132
+ v
133
+ ┌──────────────┐ ┌────────────────┐ ┌──────────────┐
134
+ │ Tasks │ <-> │ forge-daemon │ <-> │ SQLite │
135
+ │ (files) │ │ (monitor) │ │ Database │
136
+ └──────────────┘ └────────────────┘ └──────────────┘
137
+ ^ ^
138
+ │ │
139
+ └─────────────────┬─────────────────────────┘
140
+
141
+ v
142
+ ┌────────────────────┐
143
+ │ Dashboard Server │ <-- Browser (http://localhost:2800)
144
+ │ (port 2800 🔥) │
145
+ │ + WebSocket /ws │
146
+ └────────────────────┘
147
+ ```
148
+
149
+ ### Dashboard Architecture
150
+
151
+ The dashboard is a self-contained Node.js server that provides:
152
+
153
+ 1. **Static file serving** - HTML, CSS, JS from `bin/dashboard/public/`
154
+ 2. **REST API** - Task management, agent status, dispatch at `/api/*`
155
+ 3. **WebSocket** - Real-time updates at `/ws`
156
+ 4. **Issue detection** - Stale docs, failing tests, security issues
157
+
158
+ Port **2800** was chosen as the default because it's the operating temperature of a forge in degrees Fahrenheit. 🔥
159
+
160
+ ## Future Considerations
161
+
162
+ ### Potential Node.js Migration
163
+
164
+ While Option B (hybrid) is the current strategy, a future Node.js migration could provide:
165
+
166
+ 1. **Better Windows support** - Native Node.js without Git Bash dependency
167
+ 2. **Unified codebase** - Single language to maintain
168
+ 3. **Type safety** - TypeScript for larger refactors
169
+ 4. **npm ecosystem** - Libraries for terminal control, process management
170
+
171
+ Migration path if pursued:
172
+ 1. `src/lib/config.ts` - Configuration management
173
+ 2. `src/lib/agents.ts` - Agent resolution
174
+ 3. `src/lib/database.ts` - SQLite operations
175
+ 4. `src/daemon.ts` - Background daemon
176
+ 5. `src/forge.ts` - Main CLI (keeping forge.sh as thin wrapper initially)
177
+
178
+ ### Requirements for Migration
179
+
180
+ Before pursuing full Node.js migration:
181
+ - Ensure all Bash-specific functionality can be replicated
182
+ - Maintain transparency (scripts users can inspect)
183
+ - Keep startup time fast (current scripts are instant)
184
+ - Preserve Unix composability where valuable
185
+
186
+ ## ADR Summary
187
+
188
+ | Decision | Choice | Rationale |
189
+ |----------|--------|-----------|
190
+ | Primary language | Bash | Native shell integration, transparency |
191
+ | JSON parsing | Node.js via json.sh | Security, cross-platform |
192
+ | Terminal detection | Node.js | Cross-platform compatibility |
193
+ | Windows support | Git Bash + forge.cmd | Maintains Unix-like experience |
194
+ | Configuration | JSON (agents.json) | Machine-readable, single source |