blueshark-forge 0.1.0__tar.gz
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.
- blueshark_forge-0.1.0/LICENSE +21 -0
- blueshark_forge-0.1.0/PKG-INFO +208 -0
- blueshark_forge-0.1.0/README.md +179 -0
- blueshark_forge-0.1.0/blueshark_forge.egg-info/PKG-INFO +208 -0
- blueshark_forge-0.1.0/blueshark_forge.egg-info/SOURCES.txt +23 -0
- blueshark_forge-0.1.0/blueshark_forge.egg-info/dependency_links.txt +1 -0
- blueshark_forge-0.1.0/blueshark_forge.egg-info/entry_points.txt +2 -0
- blueshark_forge-0.1.0/blueshark_forge.egg-info/top_level.txt +1 -0
- blueshark_forge-0.1.0/forge/__init__.py +1 -0
- blueshark_forge-0.1.0/forge/__main__.py +247 -0
- blueshark_forge-0.1.0/forge/agent.py +318 -0
- blueshark_forge-0.1.0/forge/backends.py +246 -0
- blueshark_forge-0.1.0/forge/config.py +53 -0
- blueshark_forge-0.1.0/forge/daemon.py +134 -0
- blueshark_forge-0.1.0/forge/fleet.py +268 -0
- blueshark_forge-0.1.0/forge/repl.py +221 -0
- blueshark_forge-0.1.0/forge/session.py +184 -0
- blueshark_forge-0.1.0/forge/setup.py +180 -0
- blueshark_forge-0.1.0/forge/tools.py +221 -0
- blueshark_forge-0.1.0/forge/tui.py +129 -0
- blueshark_forge-0.1.0/forge/util.py +13 -0
- blueshark_forge-0.1.0/forge/workspace.py +168 -0
- blueshark_forge-0.1.0/pyproject.toml +44 -0
- blueshark_forge-0.1.0/setup.cfg +4 -0
- blueshark_forge-0.1.0/tests/test_forge.py +340 -0
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Yash Pachchi
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
|
@@ -0,0 +1,208 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: blueshark-forge
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: A model-agnostic agentic runtime for the terminal — any local model becomes a capable agent. The intelligence lives in the harness, not the weights.
|
|
5
|
+
Author: Yash Pachchi
|
|
6
|
+
License: MIT
|
|
7
|
+
Project-URL: Homepage, https://github.com/hackspaces/blueshark-forge
|
|
8
|
+
Project-URL: Repository, https://github.com/hackspaces/blueshark-forge
|
|
9
|
+
Project-URL: Issues, https://github.com/hackspaces/blueshark-forge/issues
|
|
10
|
+
Keywords: agent,llm,local,ollama,vllm,coding-agent,harness,agentic,cli
|
|
11
|
+
Classifier: Development Status :: 4 - Beta
|
|
12
|
+
Classifier: Environment :: Console
|
|
13
|
+
Classifier: Intended Audience :: Developers
|
|
14
|
+
Classifier: License :: OSI Approved :: MIT License
|
|
15
|
+
Classifier: Operating System :: MacOS
|
|
16
|
+
Classifier: Operating System :: POSIX :: Linux
|
|
17
|
+
Classifier: Programming Language :: Python :: 3
|
|
18
|
+
Classifier: Programming Language :: Python :: 3.10
|
|
19
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
20
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
21
|
+
Classifier: Programming Language :: Python :: 3.13
|
|
22
|
+
Classifier: Topic :: Software Development
|
|
23
|
+
Classifier: Topic :: Scientific/Engineering :: Artificial Intelligence
|
|
24
|
+
Classifier: Topic :: Utilities
|
|
25
|
+
Requires-Python: >=3.10
|
|
26
|
+
Description-Content-Type: text/markdown
|
|
27
|
+
License-File: LICENSE
|
|
28
|
+
Dynamic: license-file
|
|
29
|
+
|
|
30
|
+
# blueshark-forge
|
|
31
|
+
|
|
32
|
+
A model-agnostic agentic runtime for the terminal. Any model, frontier or a
|
|
33
|
+
small local one, becomes a capable agent, because the intelligence lives in the
|
|
34
|
+
harness, not the weights. And every forge session is part of a fleet: they verify
|
|
35
|
+
each other's work, coordinate, and share what they learn.
|
|
36
|
+
|
|
37
|
+
Not tied to any vendor. Runs on your machine, on your models.
|
|
38
|
+
|
|
39
|
+
## Quick start
|
|
40
|
+
|
|
41
|
+
```bash
|
|
42
|
+
# 1. install Ollama (https://ollama.com) and make sure it's running
|
|
43
|
+
# 2. install forge
|
|
44
|
+
pipx install blueshark-forge # or: pip install blueshark-forge
|
|
45
|
+
|
|
46
|
+
# 3. let it configure itself for THIS machine
|
|
47
|
+
# (detects your RAM/chip, picks a model ladder, pulls the models, writes config)
|
|
48
|
+
forge setup
|
|
49
|
+
|
|
50
|
+
# 4. go — open it in any repo and talk to it
|
|
51
|
+
cd your-project
|
|
52
|
+
forge
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
`forge setup` sizes the model ladder to your hardware automatically (e.g. 48GB
|
|
56
|
+
Apple Silicon → `qwen3-coder:30b → qwen3.6:35b-a3b`). Switch models any time from
|
|
57
|
+
the TUI with `/model`. Everything runs locally.
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
### Not just Ollama
|
|
61
|
+
|
|
62
|
+
`forge setup` also configures **any OpenAI-compatible engine** — vLLM, llama.cpp,
|
|
63
|
+
MLX, LM Studio, TGI, SGLang, or a cloud API — so laptops and clusters both work:
|
|
64
|
+
|
|
65
|
+
```bash
|
|
66
|
+
forge setup --engine vllm --url http://your-server:8000/v1 --models "Qwen/Qwen2.5-Coder-32B-Instruct"
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
## Why
|
|
70
|
+
|
|
71
|
+
Claude Code, Codex, and the rest are excellent, but each locks you to one
|
|
72
|
+
provider's harness. forge is the harness itself, opened up: point it at Gemma,
|
|
73
|
+
Qwen, your own model, or a frontier API, and you get the same agentic loop, tools,
|
|
74
|
+
and multi-agent fabric.
|
|
75
|
+
|
|
76
|
+
The bet: move the agentic scaffolding out of the model's weights and into the
|
|
77
|
+
harness, and even a 9B becomes a real agent. The levers:
|
|
78
|
+
|
|
79
|
+
- **Constrained decoding** — every model output is grammar-forced to a valid tool
|
|
80
|
+
call (Ollama `format` schema). A small model literally cannot emit a malformed
|
|
81
|
+
call.
|
|
82
|
+
- **Bounded steps** — the harness holds the loop; the model does one thing per turn.
|
|
83
|
+
- **Loop detection** — repeated no-progress actions are broken automatically.
|
|
84
|
+
- **Autonomy scaffolding** — task mode tells the model to act, not ask.
|
|
85
|
+
- **Verify-on-done** — a claim of "done" is checked, never trusted.
|
|
86
|
+
|
|
87
|
+
**Workspace + computer awareness** (like a real coding assistant): on start, forge
|
|
88
|
+
builds a gitignore-aware map of the project, detects the language/project type,
|
|
89
|
+
reads the git state, and learns the machine it's on (OS, shell, tool versions), all
|
|
90
|
+
pinned into context. Say "fix the auth bug" or "read this @file" and it already
|
|
91
|
+
knows where things are. It also inherits whatever the fleet has learned about the repo.
|
|
92
|
+
|
|
93
|
+
**Frontier agent loop**: a living plan (todo list the agent maintains and the
|
|
94
|
+
harness pins each turn), surgical `edit_file` (not fragile full rewrites),
|
|
95
|
+
self-correction (failed actions are flagged so the model diagnoses), loop-breaking,
|
|
96
|
+
and context compaction for long sessions.
|
|
97
|
+
|
|
98
|
+
**Local model router (escalation ladder)**: `--model a,b,c` is a ladder of local
|
|
99
|
+
models, cheapest first. forge runs on the fast one and, when it detects it's stuck
|
|
100
|
+
(the same command failing repeatedly), automatically escalates to a stronger LOCAL
|
|
101
|
+
model with full context and keeps going — no cloud, no vendor. The default is
|
|
102
|
+
`gemma2:9b → qwen2.5-coder:7b → qwen3.6`. Threshold tunable via FORGE_STUCK_THRESHOLD.
|
|
103
|
+
This is the whole "local can be enough" bet: a smart harness routing across small
|
|
104
|
+
models beats one big call for most work, and stays on your machine.
|
|
105
|
+
|
|
106
|
+
**Alive terminal**: a spinner while it thinks, a live plan panel, and clean per-step
|
|
107
|
+
rendering with timing and pass/fail.
|
|
108
|
+
|
|
109
|
+
Proven: Gemma-9B, fully local, autonomously fixes a multi-bug repo through forge
|
|
110
|
+
(read → fix → run tests → confirm). The reliability tracks task crispness — a
|
|
111
|
+
clear verification signal (tests) makes small models solid; open-ended judgement
|
|
112
|
+
still wants a bigger model, which is why the fleet's verifier routes to one.
|
|
113
|
+
|
|
114
|
+
## Use
|
|
115
|
+
|
|
116
|
+
```
|
|
117
|
+
forge chat with an agent in the cwd (default model)
|
|
118
|
+
forge --model gemma2:9b pick any Ollama model, or openai:model@url
|
|
119
|
+
forge run "<task>" one-shot: run a task to completion, autonomous
|
|
120
|
+
forge status autopilot state + live sessions
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
The fleet (multi-agent) layer — native, because forge owns its own sessions:
|
|
124
|
+
|
|
125
|
+
```
|
|
126
|
+
forge up start the autopilot (TRUST + COORDINATE + LEARN)
|
|
127
|
+
forge down stop it
|
|
128
|
+
forge send <target> <msg> message another session (it absorbs it mid-work)
|
|
129
|
+
forge receipts trust audit trail — verdicts on "done" claims
|
|
130
|
+
forge learnings [dir] durable facts learned in a repo
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
## Architecture
|
|
134
|
+
|
|
135
|
+
```
|
|
136
|
+
forge (one per terminal)
|
|
137
|
+
repl / run → agent loop (the harness brain)
|
|
138
|
+
· backend: any model (Ollama · OpenAI-compatible · your own)
|
|
139
|
+
· tools: bash / read_file / write_file / list_files
|
|
140
|
+
· levers: constrain · bounded steps · loop-break · autonomy
|
|
141
|
+
· session: transcript + registry + native inbox
|
|
142
|
+
│ many forge sessions
|
|
143
|
+
▼
|
|
144
|
+
forged (the fleet autopilot, native to forge)
|
|
145
|
+
TRUST independent verifier agent disproves "done" claims (routes to
|
|
146
|
+
a capable model; read-only, cannot edit what it judges)
|
|
147
|
+
COORDINATE warns two sessions editing the same file
|
|
148
|
+
LEARN harvests durable repo facts, shares them across sessions
|
|
149
|
+
MESSAGE session-to-session, via each session's inbox
|
|
150
|
+
```
|
|
151
|
+
|
|
152
|
+
Because forge owns the transcript format, the registry, and the inbox, the fleet
|
|
153
|
+
is built in, no external channel API, no reading someone else's logs. This is the
|
|
154
|
+
same fleet system first prototyped on Claude Code, now native and vendor-free.
|
|
155
|
+
|
|
156
|
+
## Layout
|
|
157
|
+
```
|
|
158
|
+
~/forge/forge/
|
|
159
|
+
backends.py model-agnostic backends
|
|
160
|
+
tools.py tools + the constrained action schema
|
|
161
|
+
session.py transcript · registry · inbox · ephemeral sessions
|
|
162
|
+
agent.py the agent loop (harness brain) + levers
|
|
163
|
+
repl.py interactive chat
|
|
164
|
+
fleet.py verify · coordinate · learn · message primitives
|
|
165
|
+
daemon.py forged — the autopilot loop
|
|
166
|
+
__main__.py the CLI
|
|
167
|
+
~/.forge/ runtime: sessions/ · registry.json · learn/ · verdicts.jsonl
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
## Status
|
|
171
|
+
|
|
172
|
+
Working: the agentic terminal (chat + run), model-agnostic backends, the harness
|
|
173
|
+
levers, and the native fleet layer (send/verify/guard/learn + daemon). Verifier
|
|
174
|
+
routes to a capable local model (qwen-coder class) for reliable checking.
|
|
175
|
+
|
|
176
|
+
Next: streaming output, richer TUI, tool sandboxing, more backends (vLLM/MLX,
|
|
177
|
+
Anthropic), and training a model native to forge's protocol — the flywheel where
|
|
178
|
+
forge's own trajectories teach the model to be best *in forge*.
|
|
179
|
+
|
|
180
|
+
|
|
181
|
+
## Security & trust model
|
|
182
|
+
|
|
183
|
+
forge runs on **your** machine with **your** privileges — treat it like any coding
|
|
184
|
+
assistant that can edit files and run commands.
|
|
185
|
+
|
|
186
|
+
- The **file tools** (`read/write/edit/grep/glob`) are confined to the working
|
|
187
|
+
directory. The **`bash` tool is intentionally *not* sandboxed** — it runs
|
|
188
|
+
arbitrary shell commands as you, on purpose (that's what a coding agent needs).
|
|
189
|
+
Run forge in repos you trust, or use OS-level sandboxing for untrusted code.
|
|
190
|
+
- The **fleet inbox** (session-to-session messaging) is localhost-only and
|
|
191
|
+
**token-authenticated**: only real forge sessions (which can read the private
|
|
192
|
+
`~/.forge/registry.json`, mode 0600) can message each other. `~/.forge` is 0700.
|
|
193
|
+
- The **autopilot** (`forge up`) runs a repo's own test command to verify "done"
|
|
194
|
+
claims. It does this on an isolated copy, but it *does* execute the project's
|
|
195
|
+
test script — only run `forge up` over repos you trust.
|
|
196
|
+
|
|
197
|
+
Found a security issue? Please open an issue (or email the maintainer).
|
|
198
|
+
|
|
199
|
+
## Development
|
|
200
|
+
|
|
201
|
+
```bash
|
|
202
|
+
python -m unittest discover -s tests # run the test suite (stdlib, no deps)
|
|
203
|
+
```
|
|
204
|
+
|
|
205
|
+
Tests cover the harness invariants (read-before-edit, path confinement, edit
|
|
206
|
+
exact/fuzzy matching), the tools (read/write/edit/grep/glob with offset + honest
|
|
207
|
+
truncation), fleet, config, and adversarial edge cases (absolute-path escapes,
|
|
208
|
+
traversal, missing files, malformed model output). Contributions welcome.
|
|
@@ -0,0 +1,179 @@
|
|
|
1
|
+
# blueshark-forge
|
|
2
|
+
|
|
3
|
+
A model-agnostic agentic runtime for the terminal. Any model, frontier or a
|
|
4
|
+
small local one, becomes a capable agent, because the intelligence lives in the
|
|
5
|
+
harness, not the weights. And every forge session is part of a fleet: they verify
|
|
6
|
+
each other's work, coordinate, and share what they learn.
|
|
7
|
+
|
|
8
|
+
Not tied to any vendor. Runs on your machine, on your models.
|
|
9
|
+
|
|
10
|
+
## Quick start
|
|
11
|
+
|
|
12
|
+
```bash
|
|
13
|
+
# 1. install Ollama (https://ollama.com) and make sure it's running
|
|
14
|
+
# 2. install forge
|
|
15
|
+
pipx install blueshark-forge # or: pip install blueshark-forge
|
|
16
|
+
|
|
17
|
+
# 3. let it configure itself for THIS machine
|
|
18
|
+
# (detects your RAM/chip, picks a model ladder, pulls the models, writes config)
|
|
19
|
+
forge setup
|
|
20
|
+
|
|
21
|
+
# 4. go — open it in any repo and talk to it
|
|
22
|
+
cd your-project
|
|
23
|
+
forge
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
`forge setup` sizes the model ladder to your hardware automatically (e.g. 48GB
|
|
27
|
+
Apple Silicon → `qwen3-coder:30b → qwen3.6:35b-a3b`). Switch models any time from
|
|
28
|
+
the TUI with `/model`. Everything runs locally.
|
|
29
|
+
|
|
30
|
+
|
|
31
|
+
### Not just Ollama
|
|
32
|
+
|
|
33
|
+
`forge setup` also configures **any OpenAI-compatible engine** — vLLM, llama.cpp,
|
|
34
|
+
MLX, LM Studio, TGI, SGLang, or a cloud API — so laptops and clusters both work:
|
|
35
|
+
|
|
36
|
+
```bash
|
|
37
|
+
forge setup --engine vllm --url http://your-server:8000/v1 --models "Qwen/Qwen2.5-Coder-32B-Instruct"
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
## Why
|
|
41
|
+
|
|
42
|
+
Claude Code, Codex, and the rest are excellent, but each locks you to one
|
|
43
|
+
provider's harness. forge is the harness itself, opened up: point it at Gemma,
|
|
44
|
+
Qwen, your own model, or a frontier API, and you get the same agentic loop, tools,
|
|
45
|
+
and multi-agent fabric.
|
|
46
|
+
|
|
47
|
+
The bet: move the agentic scaffolding out of the model's weights and into the
|
|
48
|
+
harness, and even a 9B becomes a real agent. The levers:
|
|
49
|
+
|
|
50
|
+
- **Constrained decoding** — every model output is grammar-forced to a valid tool
|
|
51
|
+
call (Ollama `format` schema). A small model literally cannot emit a malformed
|
|
52
|
+
call.
|
|
53
|
+
- **Bounded steps** — the harness holds the loop; the model does one thing per turn.
|
|
54
|
+
- **Loop detection** — repeated no-progress actions are broken automatically.
|
|
55
|
+
- **Autonomy scaffolding** — task mode tells the model to act, not ask.
|
|
56
|
+
- **Verify-on-done** — a claim of "done" is checked, never trusted.
|
|
57
|
+
|
|
58
|
+
**Workspace + computer awareness** (like a real coding assistant): on start, forge
|
|
59
|
+
builds a gitignore-aware map of the project, detects the language/project type,
|
|
60
|
+
reads the git state, and learns the machine it's on (OS, shell, tool versions), all
|
|
61
|
+
pinned into context. Say "fix the auth bug" or "read this @file" and it already
|
|
62
|
+
knows where things are. It also inherits whatever the fleet has learned about the repo.
|
|
63
|
+
|
|
64
|
+
**Frontier agent loop**: a living plan (todo list the agent maintains and the
|
|
65
|
+
harness pins each turn), surgical `edit_file` (not fragile full rewrites),
|
|
66
|
+
self-correction (failed actions are flagged so the model diagnoses), loop-breaking,
|
|
67
|
+
and context compaction for long sessions.
|
|
68
|
+
|
|
69
|
+
**Local model router (escalation ladder)**: `--model a,b,c` is a ladder of local
|
|
70
|
+
models, cheapest first. forge runs on the fast one and, when it detects it's stuck
|
|
71
|
+
(the same command failing repeatedly), automatically escalates to a stronger LOCAL
|
|
72
|
+
model with full context and keeps going — no cloud, no vendor. The default is
|
|
73
|
+
`gemma2:9b → qwen2.5-coder:7b → qwen3.6`. Threshold tunable via FORGE_STUCK_THRESHOLD.
|
|
74
|
+
This is the whole "local can be enough" bet: a smart harness routing across small
|
|
75
|
+
models beats one big call for most work, and stays on your machine.
|
|
76
|
+
|
|
77
|
+
**Alive terminal**: a spinner while it thinks, a live plan panel, and clean per-step
|
|
78
|
+
rendering with timing and pass/fail.
|
|
79
|
+
|
|
80
|
+
Proven: Gemma-9B, fully local, autonomously fixes a multi-bug repo through forge
|
|
81
|
+
(read → fix → run tests → confirm). The reliability tracks task crispness — a
|
|
82
|
+
clear verification signal (tests) makes small models solid; open-ended judgement
|
|
83
|
+
still wants a bigger model, which is why the fleet's verifier routes to one.
|
|
84
|
+
|
|
85
|
+
## Use
|
|
86
|
+
|
|
87
|
+
```
|
|
88
|
+
forge chat with an agent in the cwd (default model)
|
|
89
|
+
forge --model gemma2:9b pick any Ollama model, or openai:model@url
|
|
90
|
+
forge run "<task>" one-shot: run a task to completion, autonomous
|
|
91
|
+
forge status autopilot state + live sessions
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
The fleet (multi-agent) layer — native, because forge owns its own sessions:
|
|
95
|
+
|
|
96
|
+
```
|
|
97
|
+
forge up start the autopilot (TRUST + COORDINATE + LEARN)
|
|
98
|
+
forge down stop it
|
|
99
|
+
forge send <target> <msg> message another session (it absorbs it mid-work)
|
|
100
|
+
forge receipts trust audit trail — verdicts on "done" claims
|
|
101
|
+
forge learnings [dir] durable facts learned in a repo
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
## Architecture
|
|
105
|
+
|
|
106
|
+
```
|
|
107
|
+
forge (one per terminal)
|
|
108
|
+
repl / run → agent loop (the harness brain)
|
|
109
|
+
· backend: any model (Ollama · OpenAI-compatible · your own)
|
|
110
|
+
· tools: bash / read_file / write_file / list_files
|
|
111
|
+
· levers: constrain · bounded steps · loop-break · autonomy
|
|
112
|
+
· session: transcript + registry + native inbox
|
|
113
|
+
│ many forge sessions
|
|
114
|
+
▼
|
|
115
|
+
forged (the fleet autopilot, native to forge)
|
|
116
|
+
TRUST independent verifier agent disproves "done" claims (routes to
|
|
117
|
+
a capable model; read-only, cannot edit what it judges)
|
|
118
|
+
COORDINATE warns two sessions editing the same file
|
|
119
|
+
LEARN harvests durable repo facts, shares them across sessions
|
|
120
|
+
MESSAGE session-to-session, via each session's inbox
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
Because forge owns the transcript format, the registry, and the inbox, the fleet
|
|
124
|
+
is built in, no external channel API, no reading someone else's logs. This is the
|
|
125
|
+
same fleet system first prototyped on Claude Code, now native and vendor-free.
|
|
126
|
+
|
|
127
|
+
## Layout
|
|
128
|
+
```
|
|
129
|
+
~/forge/forge/
|
|
130
|
+
backends.py model-agnostic backends
|
|
131
|
+
tools.py tools + the constrained action schema
|
|
132
|
+
session.py transcript · registry · inbox · ephemeral sessions
|
|
133
|
+
agent.py the agent loop (harness brain) + levers
|
|
134
|
+
repl.py interactive chat
|
|
135
|
+
fleet.py verify · coordinate · learn · message primitives
|
|
136
|
+
daemon.py forged — the autopilot loop
|
|
137
|
+
__main__.py the CLI
|
|
138
|
+
~/.forge/ runtime: sessions/ · registry.json · learn/ · verdicts.jsonl
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
## Status
|
|
142
|
+
|
|
143
|
+
Working: the agentic terminal (chat + run), model-agnostic backends, the harness
|
|
144
|
+
levers, and the native fleet layer (send/verify/guard/learn + daemon). Verifier
|
|
145
|
+
routes to a capable local model (qwen-coder class) for reliable checking.
|
|
146
|
+
|
|
147
|
+
Next: streaming output, richer TUI, tool sandboxing, more backends (vLLM/MLX,
|
|
148
|
+
Anthropic), and training a model native to forge's protocol — the flywheel where
|
|
149
|
+
forge's own trajectories teach the model to be best *in forge*.
|
|
150
|
+
|
|
151
|
+
|
|
152
|
+
## Security & trust model
|
|
153
|
+
|
|
154
|
+
forge runs on **your** machine with **your** privileges — treat it like any coding
|
|
155
|
+
assistant that can edit files and run commands.
|
|
156
|
+
|
|
157
|
+
- The **file tools** (`read/write/edit/grep/glob`) are confined to the working
|
|
158
|
+
directory. The **`bash` tool is intentionally *not* sandboxed** — it runs
|
|
159
|
+
arbitrary shell commands as you, on purpose (that's what a coding agent needs).
|
|
160
|
+
Run forge in repos you trust, or use OS-level sandboxing for untrusted code.
|
|
161
|
+
- The **fleet inbox** (session-to-session messaging) is localhost-only and
|
|
162
|
+
**token-authenticated**: only real forge sessions (which can read the private
|
|
163
|
+
`~/.forge/registry.json`, mode 0600) can message each other. `~/.forge` is 0700.
|
|
164
|
+
- The **autopilot** (`forge up`) runs a repo's own test command to verify "done"
|
|
165
|
+
claims. It does this on an isolated copy, but it *does* execute the project's
|
|
166
|
+
test script — only run `forge up` over repos you trust.
|
|
167
|
+
|
|
168
|
+
Found a security issue? Please open an issue (or email the maintainer).
|
|
169
|
+
|
|
170
|
+
## Development
|
|
171
|
+
|
|
172
|
+
```bash
|
|
173
|
+
python -m unittest discover -s tests # run the test suite (stdlib, no deps)
|
|
174
|
+
```
|
|
175
|
+
|
|
176
|
+
Tests cover the harness invariants (read-before-edit, path confinement, edit
|
|
177
|
+
exact/fuzzy matching), the tools (read/write/edit/grep/glob with offset + honest
|
|
178
|
+
truncation), fleet, config, and adversarial edge cases (absolute-path escapes,
|
|
179
|
+
traversal, missing files, malformed model output). Contributions welcome.
|
|
@@ -0,0 +1,208 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: blueshark-forge
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: A model-agnostic agentic runtime for the terminal — any local model becomes a capable agent. The intelligence lives in the harness, not the weights.
|
|
5
|
+
Author: Yash Pachchi
|
|
6
|
+
License: MIT
|
|
7
|
+
Project-URL: Homepage, https://github.com/hackspaces/blueshark-forge
|
|
8
|
+
Project-URL: Repository, https://github.com/hackspaces/blueshark-forge
|
|
9
|
+
Project-URL: Issues, https://github.com/hackspaces/blueshark-forge/issues
|
|
10
|
+
Keywords: agent,llm,local,ollama,vllm,coding-agent,harness,agentic,cli
|
|
11
|
+
Classifier: Development Status :: 4 - Beta
|
|
12
|
+
Classifier: Environment :: Console
|
|
13
|
+
Classifier: Intended Audience :: Developers
|
|
14
|
+
Classifier: License :: OSI Approved :: MIT License
|
|
15
|
+
Classifier: Operating System :: MacOS
|
|
16
|
+
Classifier: Operating System :: POSIX :: Linux
|
|
17
|
+
Classifier: Programming Language :: Python :: 3
|
|
18
|
+
Classifier: Programming Language :: Python :: 3.10
|
|
19
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
20
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
21
|
+
Classifier: Programming Language :: Python :: 3.13
|
|
22
|
+
Classifier: Topic :: Software Development
|
|
23
|
+
Classifier: Topic :: Scientific/Engineering :: Artificial Intelligence
|
|
24
|
+
Classifier: Topic :: Utilities
|
|
25
|
+
Requires-Python: >=3.10
|
|
26
|
+
Description-Content-Type: text/markdown
|
|
27
|
+
License-File: LICENSE
|
|
28
|
+
Dynamic: license-file
|
|
29
|
+
|
|
30
|
+
# blueshark-forge
|
|
31
|
+
|
|
32
|
+
A model-agnostic agentic runtime for the terminal. Any model, frontier or a
|
|
33
|
+
small local one, becomes a capable agent, because the intelligence lives in the
|
|
34
|
+
harness, not the weights. And every forge session is part of a fleet: they verify
|
|
35
|
+
each other's work, coordinate, and share what they learn.
|
|
36
|
+
|
|
37
|
+
Not tied to any vendor. Runs on your machine, on your models.
|
|
38
|
+
|
|
39
|
+
## Quick start
|
|
40
|
+
|
|
41
|
+
```bash
|
|
42
|
+
# 1. install Ollama (https://ollama.com) and make sure it's running
|
|
43
|
+
# 2. install forge
|
|
44
|
+
pipx install blueshark-forge # or: pip install blueshark-forge
|
|
45
|
+
|
|
46
|
+
# 3. let it configure itself for THIS machine
|
|
47
|
+
# (detects your RAM/chip, picks a model ladder, pulls the models, writes config)
|
|
48
|
+
forge setup
|
|
49
|
+
|
|
50
|
+
# 4. go — open it in any repo and talk to it
|
|
51
|
+
cd your-project
|
|
52
|
+
forge
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
`forge setup` sizes the model ladder to your hardware automatically (e.g. 48GB
|
|
56
|
+
Apple Silicon → `qwen3-coder:30b → qwen3.6:35b-a3b`). Switch models any time from
|
|
57
|
+
the TUI with `/model`. Everything runs locally.
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
### Not just Ollama
|
|
61
|
+
|
|
62
|
+
`forge setup` also configures **any OpenAI-compatible engine** — vLLM, llama.cpp,
|
|
63
|
+
MLX, LM Studio, TGI, SGLang, or a cloud API — so laptops and clusters both work:
|
|
64
|
+
|
|
65
|
+
```bash
|
|
66
|
+
forge setup --engine vllm --url http://your-server:8000/v1 --models "Qwen/Qwen2.5-Coder-32B-Instruct"
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
## Why
|
|
70
|
+
|
|
71
|
+
Claude Code, Codex, and the rest are excellent, but each locks you to one
|
|
72
|
+
provider's harness. forge is the harness itself, opened up: point it at Gemma,
|
|
73
|
+
Qwen, your own model, or a frontier API, and you get the same agentic loop, tools,
|
|
74
|
+
and multi-agent fabric.
|
|
75
|
+
|
|
76
|
+
The bet: move the agentic scaffolding out of the model's weights and into the
|
|
77
|
+
harness, and even a 9B becomes a real agent. The levers:
|
|
78
|
+
|
|
79
|
+
- **Constrained decoding** — every model output is grammar-forced to a valid tool
|
|
80
|
+
call (Ollama `format` schema). A small model literally cannot emit a malformed
|
|
81
|
+
call.
|
|
82
|
+
- **Bounded steps** — the harness holds the loop; the model does one thing per turn.
|
|
83
|
+
- **Loop detection** — repeated no-progress actions are broken automatically.
|
|
84
|
+
- **Autonomy scaffolding** — task mode tells the model to act, not ask.
|
|
85
|
+
- **Verify-on-done** — a claim of "done" is checked, never trusted.
|
|
86
|
+
|
|
87
|
+
**Workspace + computer awareness** (like a real coding assistant): on start, forge
|
|
88
|
+
builds a gitignore-aware map of the project, detects the language/project type,
|
|
89
|
+
reads the git state, and learns the machine it's on (OS, shell, tool versions), all
|
|
90
|
+
pinned into context. Say "fix the auth bug" or "read this @file" and it already
|
|
91
|
+
knows where things are. It also inherits whatever the fleet has learned about the repo.
|
|
92
|
+
|
|
93
|
+
**Frontier agent loop**: a living plan (todo list the agent maintains and the
|
|
94
|
+
harness pins each turn), surgical `edit_file` (not fragile full rewrites),
|
|
95
|
+
self-correction (failed actions are flagged so the model diagnoses), loop-breaking,
|
|
96
|
+
and context compaction for long sessions.
|
|
97
|
+
|
|
98
|
+
**Local model router (escalation ladder)**: `--model a,b,c` is a ladder of local
|
|
99
|
+
models, cheapest first. forge runs on the fast one and, when it detects it's stuck
|
|
100
|
+
(the same command failing repeatedly), automatically escalates to a stronger LOCAL
|
|
101
|
+
model with full context and keeps going — no cloud, no vendor. The default is
|
|
102
|
+
`gemma2:9b → qwen2.5-coder:7b → qwen3.6`. Threshold tunable via FORGE_STUCK_THRESHOLD.
|
|
103
|
+
This is the whole "local can be enough" bet: a smart harness routing across small
|
|
104
|
+
models beats one big call for most work, and stays on your machine.
|
|
105
|
+
|
|
106
|
+
**Alive terminal**: a spinner while it thinks, a live plan panel, and clean per-step
|
|
107
|
+
rendering with timing and pass/fail.
|
|
108
|
+
|
|
109
|
+
Proven: Gemma-9B, fully local, autonomously fixes a multi-bug repo through forge
|
|
110
|
+
(read → fix → run tests → confirm). The reliability tracks task crispness — a
|
|
111
|
+
clear verification signal (tests) makes small models solid; open-ended judgement
|
|
112
|
+
still wants a bigger model, which is why the fleet's verifier routes to one.
|
|
113
|
+
|
|
114
|
+
## Use
|
|
115
|
+
|
|
116
|
+
```
|
|
117
|
+
forge chat with an agent in the cwd (default model)
|
|
118
|
+
forge --model gemma2:9b pick any Ollama model, or openai:model@url
|
|
119
|
+
forge run "<task>" one-shot: run a task to completion, autonomous
|
|
120
|
+
forge status autopilot state + live sessions
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
The fleet (multi-agent) layer — native, because forge owns its own sessions:
|
|
124
|
+
|
|
125
|
+
```
|
|
126
|
+
forge up start the autopilot (TRUST + COORDINATE + LEARN)
|
|
127
|
+
forge down stop it
|
|
128
|
+
forge send <target> <msg> message another session (it absorbs it mid-work)
|
|
129
|
+
forge receipts trust audit trail — verdicts on "done" claims
|
|
130
|
+
forge learnings [dir] durable facts learned in a repo
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
## Architecture
|
|
134
|
+
|
|
135
|
+
```
|
|
136
|
+
forge (one per terminal)
|
|
137
|
+
repl / run → agent loop (the harness brain)
|
|
138
|
+
· backend: any model (Ollama · OpenAI-compatible · your own)
|
|
139
|
+
· tools: bash / read_file / write_file / list_files
|
|
140
|
+
· levers: constrain · bounded steps · loop-break · autonomy
|
|
141
|
+
· session: transcript + registry + native inbox
|
|
142
|
+
│ many forge sessions
|
|
143
|
+
▼
|
|
144
|
+
forged (the fleet autopilot, native to forge)
|
|
145
|
+
TRUST independent verifier agent disproves "done" claims (routes to
|
|
146
|
+
a capable model; read-only, cannot edit what it judges)
|
|
147
|
+
COORDINATE warns two sessions editing the same file
|
|
148
|
+
LEARN harvests durable repo facts, shares them across sessions
|
|
149
|
+
MESSAGE session-to-session, via each session's inbox
|
|
150
|
+
```
|
|
151
|
+
|
|
152
|
+
Because forge owns the transcript format, the registry, and the inbox, the fleet
|
|
153
|
+
is built in, no external channel API, no reading someone else's logs. This is the
|
|
154
|
+
same fleet system first prototyped on Claude Code, now native and vendor-free.
|
|
155
|
+
|
|
156
|
+
## Layout
|
|
157
|
+
```
|
|
158
|
+
~/forge/forge/
|
|
159
|
+
backends.py model-agnostic backends
|
|
160
|
+
tools.py tools + the constrained action schema
|
|
161
|
+
session.py transcript · registry · inbox · ephemeral sessions
|
|
162
|
+
agent.py the agent loop (harness brain) + levers
|
|
163
|
+
repl.py interactive chat
|
|
164
|
+
fleet.py verify · coordinate · learn · message primitives
|
|
165
|
+
daemon.py forged — the autopilot loop
|
|
166
|
+
__main__.py the CLI
|
|
167
|
+
~/.forge/ runtime: sessions/ · registry.json · learn/ · verdicts.jsonl
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
## Status
|
|
171
|
+
|
|
172
|
+
Working: the agentic terminal (chat + run), model-agnostic backends, the harness
|
|
173
|
+
levers, and the native fleet layer (send/verify/guard/learn + daemon). Verifier
|
|
174
|
+
routes to a capable local model (qwen-coder class) for reliable checking.
|
|
175
|
+
|
|
176
|
+
Next: streaming output, richer TUI, tool sandboxing, more backends (vLLM/MLX,
|
|
177
|
+
Anthropic), and training a model native to forge's protocol — the flywheel where
|
|
178
|
+
forge's own trajectories teach the model to be best *in forge*.
|
|
179
|
+
|
|
180
|
+
|
|
181
|
+
## Security & trust model
|
|
182
|
+
|
|
183
|
+
forge runs on **your** machine with **your** privileges — treat it like any coding
|
|
184
|
+
assistant that can edit files and run commands.
|
|
185
|
+
|
|
186
|
+
- The **file tools** (`read/write/edit/grep/glob`) are confined to the working
|
|
187
|
+
directory. The **`bash` tool is intentionally *not* sandboxed** — it runs
|
|
188
|
+
arbitrary shell commands as you, on purpose (that's what a coding agent needs).
|
|
189
|
+
Run forge in repos you trust, or use OS-level sandboxing for untrusted code.
|
|
190
|
+
- The **fleet inbox** (session-to-session messaging) is localhost-only and
|
|
191
|
+
**token-authenticated**: only real forge sessions (which can read the private
|
|
192
|
+
`~/.forge/registry.json`, mode 0600) can message each other. `~/.forge` is 0700.
|
|
193
|
+
- The **autopilot** (`forge up`) runs a repo's own test command to verify "done"
|
|
194
|
+
claims. It does this on an isolated copy, but it *does* execute the project's
|
|
195
|
+
test script — only run `forge up` over repos you trust.
|
|
196
|
+
|
|
197
|
+
Found a security issue? Please open an issue (or email the maintainer).
|
|
198
|
+
|
|
199
|
+
## Development
|
|
200
|
+
|
|
201
|
+
```bash
|
|
202
|
+
python -m unittest discover -s tests # run the test suite (stdlib, no deps)
|
|
203
|
+
```
|
|
204
|
+
|
|
205
|
+
Tests cover the harness invariants (read-before-edit, path confinement, edit
|
|
206
|
+
exact/fuzzy matching), the tools (read/write/edit/grep/glob with offset + honest
|
|
207
|
+
truncation), fleet, config, and adversarial edge cases (absolute-path escapes,
|
|
208
|
+
traversal, missing files, malformed model output). Contributions welcome.
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
LICENSE
|
|
2
|
+
README.md
|
|
3
|
+
pyproject.toml
|
|
4
|
+
blueshark_forge.egg-info/PKG-INFO
|
|
5
|
+
blueshark_forge.egg-info/SOURCES.txt
|
|
6
|
+
blueshark_forge.egg-info/dependency_links.txt
|
|
7
|
+
blueshark_forge.egg-info/entry_points.txt
|
|
8
|
+
blueshark_forge.egg-info/top_level.txt
|
|
9
|
+
forge/__init__.py
|
|
10
|
+
forge/__main__.py
|
|
11
|
+
forge/agent.py
|
|
12
|
+
forge/backends.py
|
|
13
|
+
forge/config.py
|
|
14
|
+
forge/daemon.py
|
|
15
|
+
forge/fleet.py
|
|
16
|
+
forge/repl.py
|
|
17
|
+
forge/session.py
|
|
18
|
+
forge/setup.py
|
|
19
|
+
forge/tools.py
|
|
20
|
+
forge/tui.py
|
|
21
|
+
forge/util.py
|
|
22
|
+
forge/workspace.py
|
|
23
|
+
tests/test_forge.py
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
forge
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
__version__ = "0.1.0"
|