cubicore 1.0.0 → 1.0.1
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.
- package/LICENSE +21 -0
- package/README.md +67 -191
- package/package.json +2 -2
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Cubicore
|
|
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.
|
package/README.md
CHANGED
|
@@ -1,14 +1,27 @@
|
|
|
1
1
|
<div align="center">
|
|
2
2
|
|
|
3
|
+
<!-- Linguistic Languages for README are placed here. Must be redirected to that Lingual README. -->
|
|
4
|
+
|
|
3
5
|
# Cubicore
|
|
4
6
|
|
|
5
|
-
|
|
7
|
+
**Just an MCP that follows the classic engineering process, simultaneously like humans do.**
|
|
8
|
+
|
|
9
|
+
Cubicore is a Dynamic Multi-Agentic Factory of Sub-agents tasked to make a project, utilizing the Decrease-and-Conquer Technique to split a large prompt into multiple tasks, where one task is given to each sub-agent.
|
|
6
10
|
|
|
7
|
-
|
|
11
|
+
<p align="center">
|
|
12
|
+
<a href="https://www.npmjs.com/package/cubicore"><img src="https://img.shields.io/npm/v/cubicore?color=blue" alt="npm version"></a>
|
|
13
|
+
<a href="https://www.npmjs.com/package/cubicore"><img src="https://img.shields.io/npm/last-update/cubicore?color=blue" alt="npm last published"></a>
|
|
14
|
+
<a href="https://img.shields.io/badge/node-%3E%3D18-brightgreen"><img src="https://img.shields.io/badge/node-%3E%3D18-brightgreen" alt="Node.js 18+"></a>
|
|
15
|
+
<a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-yellow" alt="MIT license"></a>
|
|
16
|
+
</p>
|
|
17
|
+
|
|
18
|
+
`npx cubicore@latest setup`
|
|
19
|
+
|
|
20
|
+
</div>
|
|
8
21
|
|
|
9
22
|
---
|
|
10
23
|
|
|
11
|
-
What if you wished to make a "company" right at home, where you are the founder of the project, and your fellow sub-agents do the work for you? Cubicore does that for you.
|
|
24
|
+
What if you wished to make a "company" right at home, where you are the founder of the project, and your fellow sub-agents do the work for you? Cubicore does that for you.
|
|
12
25
|
|
|
13
26
|
## Introduction
|
|
14
27
|
|
|
@@ -20,12 +33,8 @@ This upon execution will summon sub-agents, where 1 task is recieved by 1 agent.
|
|
|
20
33
|
|
|
21
34
|
Cubicore can debug any broken layout, buttons, syntax errors, loose code, etc. and fix them automatically until issues disappear. Cubicore also allows the user to "preview" its project to see how it runs. Finally, if the user satisfies with the project, it then commands the "Cubicle" to deploy the application, making things ready while also giving instructions on how to deploy.
|
|
22
35
|
|
|
23
|
-
---
|
|
24
|
-
|
|
25
36
|
## Supported AI Agents
|
|
26
37
|
|
|
27
|
-
Currently, we only support Opencode for now.
|
|
28
|
-
|
|
29
38
|
| AI Agent | Status | Progress |
|
|
30
39
|
|-----------------|--------|------------------------------------------------------------------------|
|
|
31
40
|
| Opencode | ✅ | Done Further token reduction and Optimize productivity of sub-tasks. |
|
|
@@ -34,125 +43,54 @@ Currently, we only support Opencode for now.
|
|
|
34
43
|
| Cursor | ⏰ | Uses Sessions; Tedious to implement as first Session-only integration. |
|
|
35
44
|
| Windsurf | ⏰ | May use Inline Sub-tasks or Sessions. Not Started. |
|
|
36
45
|
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
---
|
|
40
|
-
|
|
41
|
-
## 🧪 Lazy Prompt Examples
|
|
46
|
+
Want to add host support, a command, or translations of this README into other languages? See [CONTRIBUTING.md](CONTRIBUTING.md) — it covers what each kind of contribution needs to look like before it merges.
|
|
42
47
|
|
|
43
|
-
|
|
44
|
-
passes your exact request to the planner, researches your repo, asks clarifying
|
|
45
|
-
questions, scopes down to an MVP, and writes a plan you review before anything
|
|
46
|
-
is built. Cubicore builds what you ask for — a todo app stays a todo app, not
|
|
47
|
-
an expense tracker.
|
|
48
|
+
## Architecture
|
|
48
49
|
|
|
49
|
-
|
|
50
|
+
<p align="center">
|
|
51
|
+
<img src="docs/assets/workflow.svg" alt="Cubicore workflow: plan → execute → preview → debug → deploy" width="640">
|
|
52
|
+
</p>
|
|
50
53
|
|
|
51
|
-
|
|
54
|
+
The five core commands, one loop: **plan → execute → preview → debug → deploy**. `refine` is the companion for changing the plan without re-running everything (basically editing a project).
|
|
52
55
|
|
|
53
|
-
|
|
56
|
+
The plan stage lets the agent to plan what would be the recommended styles, frameworks or software to fit this project.
|
|
54
57
|
|
|
55
|
-
|
|
56
|
-
2. **Research** — reports the tree, modules, and their exports; no shell exploring afterwards
|
|
57
|
-
3. **Decide scope** — demo/MVP, conventional boring stack, one contract per file or feature, fewer larger contracts over many small ones
|
|
58
|
-
4. **Write plan** — `CUBICORE_PLAN.md` (for you), `CUBICORE_PLAN.json` (dispatchable), `CUBICORE_CONTEXT.md` (for presenting in person)
|
|
58
|
+
Execute unleashes sub-tasks according to CUBICORE_PLAN.md file. Preview lets you see the changes the agent has made on the web application (by localhost), or on software/CLI/TUI tools (by local binary).
|
|
59
59
|
|
|
60
|
-
|
|
60
|
+
Debug fixes your code wherever if the position is incorrect, or the button cannot be interacted, as it can utilize the agent's built-in skills. Finally, Deploy marks the final state to publish your project either from a Free or a paid tier service.
|
|
61
61
|
|
|
62
|
-
|
|
62
|
+
The brief process of the Cubicore workflow is shown below.
|
|
63
63
|
|
|
64
|
-
|
|
65
|
-
|
|
64
|
+
<details>
|
|
65
|
+
<summary>The brief process</summary>
|
|
66
66
|
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
Then run `/cubicore:execute` → `/cubicore:debug` → `/cubicore:preview` → `/cubicore:deploy`.
|
|
75
|
-
|
|
76
|
-
### Team of 3 — Demo (`/cubicore:plan-demo` then split)
|
|
77
|
-
|
|
78
|
-
> "Make a hackathon project board where our team can drop ideas and vote on them."
|
|
79
|
-
|
|
80
|
-
After the plan is written, split it across the team:
|
|
81
|
-
|
|
82
|
-
```
|
|
83
|
-
/cubicore:execute planNumber 1 # Member A: frontend board UI
|
|
84
|
-
/cubicore:execute planNumber 2 # Member B: voting logic + API
|
|
85
|
-
/cubicore:execute planNumber 3 # Member C: idea storage + export
|
|
67
|
+
```mermaid
|
|
68
|
+
flowchart LR
|
|
69
|
+
P[plan] --> X[execute]
|
|
70
|
+
X --> PV[preview]
|
|
71
|
+
PV --> DB[debug]
|
|
72
|
+
DB -.->|fix & redo| X
|
|
73
|
+
DB --> D[deploy]
|
|
86
74
|
```
|
|
87
75
|
|
|
88
|
-
|
|
89
|
-
conflicts. Use `/cubicore:status` to check a run, `/cubicore:continue`
|
|
90
|
-
with `planNumber` to resume after interruptions.
|
|
76
|
+
</details>
|
|
91
77
|
|
|
92
|
-
### Team of 3 — Full (`/cubicore:plan-full` then split)
|
|
93
78
|
|
|
94
|
-
|
|
79
|
+
## Using Cubicore
|
|
95
80
|
|
|
96
|
-
|
|
81
|
+
Ask in plain words. No spec, no schema. The planner reads the repo, asks you what it can't answer, writes `CUBICORE_PLAN.md` / `CUBICORE_PLAN.json` / `CUBICORE_CONTEXT.md`, and stops — nothing dispatches until you approve.
|
|
97
82
|
|
|
98
|
-
|
|
99
|
-
/cubicore:execute planNumber 1 # Member A: auth + client portal UI
|
|
100
|
-
/cubicore:execute planNumber 2 # Member B: uploads + invoice generation
|
|
101
|
-
/cubicore:execute planNumber 3 # Member C: dashboard + reporting
|
|
102
|
-
```
|
|
83
|
+
Examples: [`docs/examples.md`](docs/examples.md) · Full reference: [`docs/commands.md`](docs/commands.md) · FAQ: [`docs/faq.md`](docs/faq.md)
|
|
103
84
|
|
|
104
|
-
|
|
105
|
-
conflicts. Use `/cubicore:status` to check each run, `/cubicore:continue`
|
|
106
|
-
with `planNumber` to resume after interruptions.
|
|
107
|
-
|
|
108
|
-
---
|
|
109
|
-
|
|
110
|
-
## Commands
|
|
111
|
-
|
|
112
|
-
| Command | What it does |
|
|
113
|
-
|---|---|
|
|
114
|
-
| `/cubicore:plan-demo` | Demo mode. Research the repository, ask the founder what the repo cannot answer, then write `CUBICORE_PLAN.md` and `CUBICORE_PLAN.json`. Dispatches nothing. **Use for a fresh start; `refine` to change an existing plan.** |
|
|
115
|
-
| `/cubicore:plan-full` | Full product mode of the command above. **Use for a fresh start; `refine` to change an existing plan.** |
|
|
116
|
-
| `/cubicore:execute` | Dispatch the plan — one brief per associate, summoned in parallel, each result gated. Pass `plan` (inline JSON) or `planNumber` (reads `CUBICORE_PLAN_N.json` from disk). `planNumber` is optional: omit it to run the inline plan, or pass a number to dispatch a member plan file. Enforces the cycle budget and cross-plan validation when reading from disk. |
|
|
117
|
-
| `/cubicore:continue` | Resume the last run from where it stopped — skips contracts already done, dispatches only what remains. Exempt from the cycle budget. Reads `CUBICORE_PLAN.json` by default, falls back to `CUBICORE_PLAN_1.json`, or `CUBICORE_PLAN_N.json` when a plan number is given. |
|
|
118
|
-
| `/cubicore:debug` | Review, test, and fix the delivered work until the issues disappear. Runs the mechanical matrix, records findings, and attempts narrowly-scoped fixes. Errors and warnings block; judgement calls are reported and never block. Writes `CUBICORE_DEBUG.md`. |
|
|
119
|
-
| `/cubicore:refine` | Change the current plan before running it, or add a feature to a project that has already been built. Contracts that already passed and were left alone are not re-run, so the second cycle costs the change and not the project. |
|
|
120
|
-
| `/cubicore:estimate` | What the plan will cost before anything is spent: how many associates, the token and wall ceilings, and who owns what. It is the plan's own budget, not a forecast. |
|
|
121
|
-
| `/cubicore:undo` | Undo the last execution — discard its changes and return the tree to the baseline commit Cubicore recorded. Destroys work, so it says what it will destroy first. |
|
|
122
|
-
| `/cubicore:deploy` | Plan the deployment. Asks about the tier, offers stacks with a recommendation, writes the deploy files, and explains the manual steps. Deploys nothing. |
|
|
123
|
-
| `/cubicore:preview` | Run the delivered thing the way the founder would use it — web app on localhost, CLI verified by its output, TUI/GUI verified by its interface. A contract can be correct and still not run. Uses the plan's own `preview` block. |
|
|
124
|
-
| `/cubicore:status` | Report what the run in flight is doing, and wait for it if it is not finished. |
|
|
125
|
-
|
|
126
|
-
**Quick command guide:** `plan-demo`/`plan-full` = fresh plan (always writes from scratch; note warns if plan exists); `refine` = edit existing plan (adds/changes without destroying); `execute` = dispatch; `preview` = keep it running; `debug` = review/test/fix; `undo` = discard; `continue` = resume; `estimate` = budget; `deploy` = deploy plan; `refine` = add/change features. Use the right one — `refine` is the mandatory iterative-editing command; it does jobs no other command can do.
|
|
127
|
-
|
|
128
|
-
### The flow guides itself
|
|
129
|
-
|
|
130
|
-
After every step the agent ends its reply with what to type next, and the alternatives — the recommended one first. It is derived from the state on disk, so it survives a restart and a new session days later.
|
|
131
|
-
|
|
132
|
-
```
|
|
133
|
-
no plan /cubicore:plan
|
|
134
|
-
after plan /cubicore:execute · estimate · refine
|
|
135
|
-
run in flight /cubicore:status
|
|
136
|
-
after the run /cubicore:preview · debug · refine · undo · continue
|
|
137
|
-
issues found /cubicore:debug · refine · undo · continue
|
|
138
|
-
everything passes /cubicore:deploy · refine · undo
|
|
139
|
-
```
|
|
140
|
-
|
|
141
|
-
---
|
|
142
|
-
|
|
143
|
-
## Installation
|
|
85
|
+
### Installation
|
|
144
86
|
|
|
145
87
|
```bash
|
|
146
88
|
npx cubicore@latest setup
|
|
147
89
|
```
|
|
148
90
|
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
1. Prints a banner and asks which OpenCode you run — **Native (CLI / Desktop)** (default) or **Flatpak** (Linux only).
|
|
152
|
-
2. Copies the MCP runtime into a user-global directory.
|
|
153
|
-
3. Registers `mcp.cubicore` in the chosen variant's global config and installs the associate agents (primary agent bounded to 120 steps).
|
|
91
|
+
> [!IMPORTANT]
|
|
92
|
+
> Currently, the only source of installation is on the README, or as an npm package.
|
|
154
93
|
|
|
155
|
-
If the chosen OpenCode's config directory is missing, nothing is written and the script says so. Re-run the same command to update. **Restart OpenCode afterwards.**
|
|
156
94
|
|
|
157
95
|
Then in any project directory, type:
|
|
158
96
|
|
|
@@ -165,108 +103,46 @@ troubleshooting, FAQs, and AI agent installation.
|
|
|
165
103
|
|
|
166
104
|
### How the associates are kept apart
|
|
167
105
|
|
|
168
|
-
Three
|
|
169
|
-
|
|
170
|
-
**At plan time**, the validator rejects overlapping write scopes before a token is spent. It is a conservative over-approximation — `src/routes/` and `src/routes/users.ts` collide, `src/a.ts` and `src/b.ts` do not — because over-reporting costs one re-plan while under-reporting costs a merge conflict.
|
|
106
|
+
Three checks, applied at three different moments — the moment the plan is written, the moment an associate is working, and the moment its work is handed back. None of them trusts the others.
|
|
171
107
|
|
|
172
|
-
**
|
|
108
|
+
**At plan time**, overlapping write scopes are rejected before a single token is spent. It's a conservative glob intersection: `src/routes/` and `src/routes/users.ts` collide; `src/a.ts` and `src/b.ts` don't. Reporting a collision that doesn't exist costs one re-plan. Missing one costs two associates in the same file, which is worse.
|
|
173
109
|
|
|
174
|
-
**
|
|
110
|
+
**During the work**, each associate gets its own git worktree and is told its own scope. A worker writing to `src/api/` has no line of sight into `src/ui/`, and the worktree is the enforcement — not the prompt. An associate that strayed is caught when its diff is checked against what was declared. Where git is unavailable, the work happens in the shared tree and Cubicore says so plainly.
|
|
175
111
|
|
|
176
|
-
|
|
112
|
+
**After the work**, the scope gate compares what changed against what was declared. Over-powered edits are refused; unchecked edits are unverified, which is not the same as passing; a check that couldn't run is recorded as unavailable rather than an error to be fixed.
|
|
177
113
|
|
|
178
|
-
|
|
114
|
+
One housekeeping detail: OpenCode cannot restrict agents to paths. Its permission system is per-action, not per path or glob. So the boundary is never a rule — it's the worktree, plus everything after it.
|
|
179
115
|
|
|
180
116
|
## What Cubicore is for
|
|
181
117
|
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
**Splitting work without coordination is not free parallelism.** Measured
|
|
185
|
-
against one agent doing the same job, twelve uncoordinated workers cost
|
|
186
|
-
**10.9× the tokens and were 2.6× slower**. Every worker loaded the whole
|
|
187
|
-
repository into its own context and nothing stopped them colliding.
|
|
188
|
-
|
|
189
|
-
**Cubicore fixes the cost side.** Against the same twelve-worker fan-out,
|
|
190
|
-
Cubicore was **3.5× cheaper** — narrower write scopes, so each worker reads
|
|
191
|
-
only what its contract needs instead of the whole repository. The naive arm
|
|
192
|
-
spent 96.0M tokens on cache reads; Cubicore spent 25.0M, for the same twelve
|
|
193
|
-
workers. That difference is the contract layer and nothing else.
|
|
118
|
+
Cubicore takes a real project and splits it into **contracts** — small, checkable pieces — and dispatches those pieces to associates that work in parallel without colliding. It earns its keep in these situations:
|
|
194
119
|
|
|
195
|
-
|
|
196
|
-
|
|
197
|
-
|
|
198
|
-
Cubicore has no concurrency cap of its own yet, so the fair comparison could
|
|
199
|
-
not be run as written.
|
|
120
|
+
- **Multi-file changes in an existing codebase**, where one agent would need the whole tree in context at once and still miss things.
|
|
121
|
+
- **Founders who want to review a plan before anything gets built** — the plan is the product, and you get to veto it.
|
|
122
|
+
- **Work where "done" has a definition** — a build that compiles, a test that passes, a lint that is clean. Vague asks don't fit through the contract layer well, and that's deliberate.
|
|
200
123
|
|
|
201
|
-
|
|
202
|
-
on wall clock and cost 3.1× the tokens. The work was too small to need parallel
|
|
203
|
-
workers, and the model was the bottleneck, not the split.
|
|
124
|
+
Cubicore is not a faster agent. Speed is whatever the task, the host, and the model make of it. The value is that parallel agents stay safe and auditable: everyone reads only what they're assigned, nobody overwrites anybody by accident, and the result of the run is a record of what passed each check — not a model's opinion of itself.
|
|
204
125
|
|
|
205
|
-
|
|
206
|
-
about Cubicore:
|
|
126
|
+
## What Cubicore does — and what it doesn't
|
|
207
127
|
|
|
208
|
-
|
|
209
|
-
|
|
210
|
-
|
|
211
|
-
|
|
212
|
-
|
|
213
|
-
| One agent, done in one pass | overhead, and the plan says so |
|
|
128
|
+
- **It plans.** `CUBICORE_PLAN.md` for you, `CUBICORE_PLAN.json` for the associates, `CUBICORE_CONTEXT.md` for the pitch. Review before dispatch; nothing happens until you approve.
|
|
129
|
+
- **It dispatches.** Inline sub-agents where the host supports them, sessions otherwise — both are gated the same way. The session path speaks to OpenCode 2.x's `/api/*` endpoints; the v1 SDK it originally used has been retired by the host.
|
|
130
|
+
- **It gates.** Each associate gets its own worktree; its writes are copied back only after the checks pass. A scope violation or a failing check blocks integration — it never slips through silently.
|
|
131
|
+
- **It loops, bounded.** Plan → execute → debug → execute, and the number of cycles is capped. "Until the debug file is empty" is not a termination condition; an agent that never stops finding things to fix is not a loop, it's a haunting.
|
|
132
|
+
- **It is judgemental only where it's safe to be.** Warnings block work. Opinions about whether the feature is useful go in advisory notes that never gate anything.
|
|
214
133
|
|
|
215
|
-
|
|
216
|
-
"because of splitting". Splitting is what makes the naive version slow. Cubicore
|
|
217
|
-
is what makes splitting pay. And the ceiling is below 9→4 for most projects,
|
|
218
|
-
because Amdahl's serial fraction does not parallelise and the gates cost
|
|
219
|
-
something too.
|
|
134
|
+
What it doesn't do: no judgment in the checks (the validator rejects them), no unattended autonomy, no silent merges. Mechanical gates only — a worker that edits outside its scope or fails a check keeps its work in its own worktree and gets nothing.
|
|
220
135
|
|
|
221
|
-
|
|
222
|
-
repository without colliding, and that "done" means the checks passed rather
|
|
223
|
-
than that a model said so. The speedup is a side effect.
|
|
224
|
-
|
|
225
|
-
Full numbers and the caveats: [bench/RESULTS.md](bench/RESULTS.md).
|
|
226
|
-
|
|
227
|
-
---
|
|
136
|
+
## Known limits
|
|
228
137
|
|
|
229
|
-
|
|
230
|
-
|
|
231
|
-
- **
|
|
232
|
-
|
|
233
|
-
|
|
234
|
-
- **Narrative context.** `CUBICORE_CONTEXT.md` — problem, users, use cases,
|
|
235
|
-
benefits, demo flow, future work, market opportunity, business model,
|
|
236
|
-
competitive advantage, go-to-market, risks, current status, and the ask.
|
|
237
|
-
Written for humans who present the project in person; never parsed by
|
|
238
|
-
Execute or dispatch.
|
|
239
|
-
- **Two dispatch paths.** Inline sub-tasks where the host supports them, sessions
|
|
240
|
-
where it does not. Both gate the same way.
|
|
241
|
-
- **One worktree per associate.** opencode 1.18.x cannot restrict an agent to
|
|
242
|
-
a path, so the filesystem is the boundary: two workers cannot be in one file
|
|
243
|
-
at the same moment. A worker's files are copied back only after its checks
|
|
244
|
-
pass, so an unapproved change never reaches the shared tree.
|
|
245
|
-
- **Fourteen commands, and the flow guides itself.** Every reply ends with the
|
|
246
|
-
next step and the alternatives, derived from the state on disk rather than
|
|
247
|
-
remembered.
|
|
248
|
-
- **A bounded loop.** `plan → execute → debug → execute`, capped at three
|
|
249
|
-
cycles. Not "until the debug file is empty" — that is an unbounded loop whose
|
|
250
|
-
terminal case is an agent that never stops finding things to fix.
|
|
251
|
-
- **Judgement never blocks.** Errors and warnings block. "Is this useful" and
|
|
252
|
-
"is this production ready" are recorded as advisory and left to the founder.
|
|
138
|
+
- **The gate is mechanical, not judgemental.** It checks commands, statuses and scopes. It cannot tell you your build is bad — only that the check failed.
|
|
139
|
+
- **The shell is still unrestricted.** A worker can run anything. The worktree limits the blast radius, not the command.
|
|
140
|
+
- **Benchmarks do not exist yet.** No honest Cubicore-vs-one-agent number has been published; the measurements taken so far are not comparative. Until there is one, the honest answer to "is it faster/cheaper?" is "it depends, and we're not going to guess."
|
|
141
|
+
- **Only OpenCode runs today.** Every claim in this file is about OpenCode. Assume nothing about other agents until their adapter exists.
|
|
142
|
+
- **It runs on what's installed.** Cubicore doesn't bring a runtime; it uses the host's. It doesn't manage your toolchain, and it won't pretend otherwise.
|
|
253
143
|
|
|
254
144
|
---
|
|
255
145
|
|
|
256
|
-
##
|
|
146
|
+
## Contributing
|
|
257
147
|
|
|
258
|
-
|
|
259
|
-
the validator rejects them. Whether a feature is *useful* is not something
|
|
260
|
-
the matrix can decide.
|
|
261
|
-
- **X and Y are measured, but not in one controlled run.** The three arms have
|
|
262
|
-
each run against the same fixture, and the ratios are large enough to
|
|
263
|
-
survive that — but the digits do not come from one clock.
|
|
264
|
-
- **Y**, total tokens against naive fan-out: **0.29**
|
|
265
|
-
- **X**, per-worker cost against naive fan-out: **0.29**
|
|
266
|
-
- Wall clock against naive fan-out: **2.9× faster** — ⚠ confounded, the
|
|
267
|
-
naive arm ran three-wide and Cubicore ran twelve-wide. Do not quote it.
|
|
268
|
-
- Against a *single* agent: parity on wall clock and **3.1× more tokens**
|
|
269
|
-
- **The inline path's shell is still unrestricted.** opencode 1.18.x cannot
|
|
270
|
-
restrict an agent to a path, so a worker with a shell can run anything. The
|
|
271
|
-
worktree contains the damage — a stray file stays in the worker's own
|
|
272
|
-
checkout and is not copied back — but the command still ran.
|
|
148
|
+
Hello there, incoming contributors! Do support us in adding or improving a feature or command, or support Cubicore into an AI agent, or provide another language for the README, or potentially unseen bug fixes or optimizations. More info under [contributing guidelines](CONTRIBUTING.md).
|
package/package.json
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "cubicore",
|
|
3
|
-
"version": "1.0.
|
|
3
|
+
"version": "1.0.1",
|
|
4
4
|
"type": "module",
|
|
5
|
-
"description": "Cubicore
|
|
5
|
+
"description": "Cubicore — build exactly what the founder requested. Plan, dispatch, test, refine, deploy.",
|
|
6
6
|
"main": "dist/mcp-main.js",
|
|
7
7
|
"bin": {
|
|
8
8
|
"cubicore": "dist/cli.js"
|