@xcompiler/cli 0.2.2

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/README.md ADDED
@@ -0,0 +1,274 @@
1
+ # XCompiler โ€” Extensible Compiler
2
+
3
+ > Multi-LLM, V-model-driven AI Software Factory CLI
4
+ > Turn one paragraph of natural-language requirements into a runnable, tested, deliverable Python or TypeScript project
5
+ > Apache License 2.0
6
+
7
+ [![license](https://img.shields.io/badge/license-Apache--2.0-blue.svg)](LICENSE)
8
+ [![node](https://img.shields.io/badge/node-%3E%3D20-brightgreen.svg)](https://nodejs.org)
9
+
10
+ ๐ŸŒ **Languages**: **EN** (default) ยท [็ฎ€ไฝ“ไธญๆ–‡](README.CN.md)
11
+
12
+ ---
13
+
14
+ ## What is this
15
+
16
+ XCompiler splits "writing code" into two phases โ€” **compile** and **execute** โ€” modelled on a traditional compiler's `cc` / `a.out`:
17
+
18
+ | Command | Role | Input | Output |
19
+ |---|---|---|---|
20
+ | **`xcompiler build`** | **AI Compiler** โ€” translates natural-language requirements into executable phase-steps (a plan) | A requirement text (`-i req.md`, `-t topic.md`, or interactive) | `plan.json` (topologically ordered Step DAG) + `topic.md` + `plan.md` |
21
+ | **`xcompiler run`** | **AI Executor** โ€” runs the compiled phase-steps in topological order | `plan.json` | Runnable Python/TypeScript project + green tests + `docs/05-delivery.md` |
22
+
23
+ > Analogy: `xcompiler build` โ‰ˆ a compiler turning C source into machine instructions; `xcompiler run` โ‰ˆ the CPU executing those instructions.
24
+ > Difference: XCompiler's "instructions" are V-model phases (REQUIREMENT / ARCH / CODE / TEST / REFACTOR / DELIVERY), and each "execution unit" is a sandbox-constrained multi-Agent loop.
25
+
26
+ Every Step gets a git snapshot and an audit-log entry; failures automatically enter a DEBUG retry loop (โ‰ค 3 rounds).
27
+
28
+ ---
29
+
30
+ ## Built-in V-model pipeline
31
+
32
+ XCompiler encodes the **V-model** of software engineering directly as the decomposition skeleton of `xcompiler build` and the execution scheduler of `xcompiler run`. Each phase has mandatory artefacts, a tool whitelist, and a quality gate:
33
+
34
+ ```text
35
+ โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ xcompiler build (AI Compiler) โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
36
+ โ”‚ โ”‚
37
+ Requirement โ”€โ”€โ–บ Intake โ”€โ”€โ–บ Clarify โ”€โ”€โ–บ Decompose โ”€โ”€โ–บ plan.json
38
+ (NL) โ”‚ โ”‚
39
+ โ””โ”€ Gate 1 โ”€โ”€โ”€โ”˜ Gate 2 (two human confirmation gates)
40
+
41
+
42
+ โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ xcompiler run (AI Executor) โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
43
+ โ”‚ topology executes V-model left โ†’ right โ”‚
44
+
45
+ REQUIREMENT โ—„โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ verify โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ–บ DELIVERY
46
+ โ”‚ โ–ฒ
47
+ โ–ผ โ”‚
48
+ ARCH โ—„โ”€โ”€โ”€โ”€โ”€ refactor / docs โ”€โ”€โ”€โ”€โ”€โ–บ REFACTOR
49
+ โ”‚ โ–ฒ
50
+ โ–ผ โ”‚
51
+ CODE โ—„โ”€โ”€โ”€โ”€โ”€โ”€ test gate โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ–บ TEST
52
+ โ”‚ โ–ฒ
53
+ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ–บ DEBUG (โ‰ค3 retries) โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
54
+ (auto failure loop)
55
+ ```
56
+
57
+ | Phase | Lead Agent / Skill | Mandatory Artefact | Quality Gate |
58
+ |---|---|---|---|
59
+ | REQUIREMENT | Planner | `topic.md` | Gate 1 human confirmation |
60
+ | ARCH | Architect | `architecture.md`๏ผ›TypeScript ๅŒๆญฅ็ปดๆŠค `package.json` | plan lint |
61
+ | CODE | Coder (`patcher` / `author`) | `src/**.{py,ts}` | EditGuard line cap |
62
+ | TEST | Tester (`tester`) | `tests/**.{py,ts}` | **tests exit=0** |
63
+ | DEBUG | Debugger (`debugger`) | fix patch | โ‰ค `max_debug_retries` |
64
+ | REFACTOR | Refactorer | optimised `src/` | tests do not regress |
65
+ | DELIVERY | Author | `docs/05-delivery.md` | All Steps DONE + entry `--help` =0 |
66
+
67
+ ---
68
+
69
+ ## System architecture
70
+
71
+ ```text
72
+ โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
73
+ โ”‚ CLI layer โ”‚
74
+ โ”‚ xcompiler โ”€โ”ฌโ”€ xcompiler build (= xcompiler_build) AI Compiler โ”‚
75
+ โ”‚ โ””โ”€ xcompiler run (= xcompiler_run) AI Executor โ”‚
76
+ โ”‚ + xcompiler ls / show โ”‚
77
+ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
78
+ โ”‚ โ”‚
79
+ โ–ผ โ–ผ
80
+ โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
81
+ โ”‚ Planner (compile) โ”‚ โ”‚ PhaseEngine (run) โ”‚
82
+ โ”‚ - intake/clarify โ”‚ โ”‚ - topology sched. โ”‚
83
+ โ”‚ - decompose (V) โ”‚ โ”‚ - DEBUG loop โ”‚
84
+ โ”‚ - plan lint โ”‚ โ”‚ - resumable โ”‚
85
+ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
86
+ โ”‚ โ”‚
87
+ โ–ผ โ–ผ
88
+ โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
89
+ โ”‚ Agent / Skill layer โ”‚
90
+ โ”‚ Architect ยท Coder ยท Tester ยท Debugger ยท โ”‚
91
+ โ”‚ Refactorer ยท Author โ”‚
92
+ โ”‚ Skills: patcher / author / tester / โ”‚
93
+ โ”‚ dep_resolver / debugger / refactor โ”‚
94
+ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
95
+ โ”‚
96
+ โ–ผ
97
+ โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
98
+ โ”‚ Tool layer (whitelist + EditGuard) โ”‚
99
+ โ”‚ read_file ยท write_file ยท append_file ยท โ”‚
100
+ โ”‚ replace_in_file ยท run_program ยท run_tests ยท git_* โ”‚
101
+ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
102
+ โ”‚
103
+ โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ผโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
104
+ โ–ผ โ–ผ โ–ผ
105
+ โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
106
+ โ”‚ LLM Router โ”‚ โ”‚ Sandbox โ”‚ โ”‚ Workspace โ”‚
107
+ โ”‚ chain + โ”‚ โ”‚ subprocess โ”‚ โ”‚ git + audit โ”‚
108
+ โ”‚ fallback โ”‚ โ”‚ / docker โ”‚ โ”‚ + .xcompiler/ โ”‚
109
+ โ”‚ (ollama, โ”‚ โ”‚ venv iso. โ”‚ โ”‚ plan.json โ”‚
110
+ โ”‚ openai) โ”‚ โ”‚ โ”‚ โ”‚ โ”‚
111
+ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
112
+ ```
113
+
114
+ The runtime also exposes a typed PluginHost across the compile, LLM, run, step,
115
+ attempt and tool boundaries. Plugins can register Tools / Skills without bypassing
116
+ the existing whitelist and EditGuard security model.
117
+
118
+ Layer responsibilities:
119
+
120
+ - **CLI**: argument parsing, workspace lock, `--force` / `--from` / `--phase` modes.
121
+ - **Planner / PhaseEngine**: top-level scheduler for "compile" and "execute" respectively.
122
+ - **Agent / Skill**: each Skill is a `(role + system prompt + tool whitelist)` bundle bound to one V-model phase.
123
+ - **Tool**: atomic operations, all guarded by EditGuard / whitelist; writes are restricted to a Step's declared `outputs`.
124
+ - **LLM Router**: multi-provider chain + fallbacks with full audit trail.
125
+ - **Sandbox**: Python uses venv/pip/pytest; TypeScript uses npm/tsx/vitest, via subprocess or docker.
126
+ - **Workspace**: git snapshots + `.xcompiler/audit.jsonl` + `.xcompiler/.lock`, fully resumable.
127
+
128
+ ---
129
+
130
+ ## Quick start
131
+
132
+ ```bash
133
+ # 1. Install dependencies
134
+ npm ci
135
+ cp .env.example .env # fill OLLAMA_BASE_URL etc.
136
+ cp config.example.yaml config.yaml
137
+
138
+ # 2. Build and install as a global command
139
+ npm run build
140
+ npm link # or: npm install -g .
141
+ xcompiler --help
142
+
143
+ # 3. Write requirements โ†’ compile a plan
144
+ echo "Parse a DBC file into an Excel report" > req.md
145
+ xcompiler build -i req.md --yes
146
+
147
+ # 4. Execute the plan
148
+ xcompiler run /tmp/xcompiler-<timestamp>/plan.json
149
+
150
+ # 5. Resume later from the generated project file
151
+ xcompiler load /tmp/xcompiler-<timestamp>/xcompiler-<timestamp>.xc
152
+ ```
153
+
154
+ Dev mode (no build step):
155
+
156
+ ```bash
157
+ npm run dev -- build
158
+ npm run dev -- run path/to/plan.json
159
+ ```
160
+
161
+ Incremental evolution on top of an existing workspace:
162
+
163
+ ```bash
164
+ # add a feature against the current project baseline
165
+ xcompiler build -w path/to/workspace -i feature_req.md --intent feature --yes
166
+
167
+ # or compile + execute in one go
168
+ xcompiler evolve -w path/to/workspace -i refactor_req.md --intent refactor --yes
169
+
170
+ # append a new requirement through clarification + V-model on the same project
171
+ xcompiler append path/to/workspace/<name>.xc -i feature_req.md --yes
172
+
173
+ # let stable XCompiler build and qualify its next generation in an isolated worktree
174
+ xcompiler bootstrap -r path/to/XCompiler -i self_req.md --yes
175
+ ```
176
+
177
+ ### Common options
178
+
179
+ | Command | Option | Purpose |
180
+ |---|---|---|
181
+ | `xcompiler build` | `-i <file>` | Use a requirements file (non-interactive) |
182
+ | `xcompiler build` | `-t <file>` | Reuse a previously clarified `topic.md` and skip Gate 1 |
183
+ | `xcompiler build` | `--intent <greenfield\|feature\|refactor\|self>` | Choose greenfield, incremental, or isolated self-bootstrap planning |
184
+ | `xcompiler build` | `--baseline-plan <file>` | Point incremental planning at an explicit existing `plan.json` |
185
+ | `xcompiler build` / `xcompiler run` | `--project-file <file>` | Create/update a specific `XXX.xc` project file |
186
+ | `xcompiler build` | `--force` | Override the workspace lock and regenerate the plan |
187
+ | `xcompiler evolve` | `...` | Compile an incremental plan, then immediately execute it in the same workspace |
188
+ | `xcompiler load <XXX.xc>` | โ€” | Load project config/progress and continue the current plan |
189
+ | `xcompiler append <XXX.xc>` | `-i <file>` | Clarify and execute a new incremental requirement on the existing project |
190
+ | `xcompiler bootstrap` | `--promote` | Explicitly fast-forward a qualified candidate; the default only creates a candidate and report |
191
+ | `xcompiler bootstrap` | `--docker-qualification` | Opt into the experimental Docker qualification runner; subprocess is the default |
192
+ | `xcompiler run` | `--reset` | Reset all Steps to PENDING |
193
+ | `xcompiler run` | `--force` | Equivalent to `--reset` + override lock |
194
+ | `xcompiler run` | `--from <stepId>` / `--phase <phase>` | Resume / run only one phase |
195
+ | `xcompiler run` | `--dry-run` | Print topology only |
196
+ | `xcompiler ls` | โ€” | Scan workspace and list every plan's status |
197
+ | `xcompiler show <stepId>` | โ€” | Inspect a single Step (definition / outputs / recent audit) |
198
+
199
+ ---
200
+
201
+ ## Default runtime
202
+
203
+ - **LLM**: local ollama (`gemma4:31b` for Planner / Architect, `qwen3-coder:30b` for Coder / Tester / Debugger).
204
+ Set `fallbacks: [openai]` in `config.yaml` to fall back to an OpenAI-compatible endpoint when the primary chain fails.
205
+ - **i18n**: set top-level `locale: en` or `locale: zh` in `config.yaml` to control CLI and prompt language.
206
+ - **Sandbox**: `subprocess` by default (creates an isolated venv at `<workspace>/.sandbox/<project>/`); switch to `docker` for bind-mount + network / resource limits.
207
+ - **Audit**: every run writes `<workspace>/.xcompiler/audit.jsonl` and `docs/process_log.md`, recording all LLM I/O, tool calls and Step state transitions.
208
+ - **Cross-run debug memory**: `<workspace>/.xcompiler/debug_cache.json` persists DEBUG attempts; subsequent `xcompiler run` calls enter Debugger mode with prior failures fed back to the LLM.
209
+
210
+ ---
211
+
212
+ ## Documentation
213
+
214
+ | Path | Content |
215
+ |---|---|
216
+ | [docs/XCompiler_design.md](docs/XCompiler_design.md) | Overall design: V-model phases, Agent / Skill / Tool abstractions, Sandbox & Workspace |
217
+ | [docs/implementation_plan.md](docs/implementation_plan.md) | M1 โ†’ M6 milestones and landing steps |
218
+ | [docs/deploy.md](docs/deploy.md) | Deployment guide (local + Docker) |
219
+ | [docs/plugin_api.md](docs/plugin_api.md) | Typed plugin API, lifecycle hooks, ordering and failure policy |
220
+ | [docs/versioning.md](docs/versioning.md) | Core and Plugin API version sources, sync commands and release checks |
221
+ | [docs/self_bootstrap.md](docs/self_bootstrap.md) | Generational bootstrap, worktree isolation, qualification gates and promotion protocol |
222
+ | [docs/dev_audit_log.md](docs/dev_audit_log.md) | XCompiler's own delivery log (every requirement / decision / artefact / verification) |
223
+
224
+ > Doc layering:
225
+ > - `docs/` is the single documentation root; design documents use semantic names while V-model run artefacts use the `01-` through `05-` phase prefixes.
226
+ > - `docs/dev_audit_log.md` documents "how we built XCompiler" and is itself a XCompiler deliverable.
227
+ > - `<workspace>/docs/process_log.md` is auto-generated by the runtime `AuditLogger`, recording every interaction of "the user building a Python project with XCompiler" as that product's delivery summary.
228
+
229
+ ---
230
+
231
+ ## Runtime tuning (`config.yaml โ†’ agent.*`)
232
+
233
+ | Field | Default | Effect |
234
+ |---|---|---|
235
+ | `max_rounds_per_step` | 6 | Upper bound on LLM dialogue rounds within a single Step |
236
+ | `max_debug_rounds_per_step` | `max(8, 2 ร— max_rounds_per_step)` | DEBUG retry round cap |
237
+ | `max_debug_retries` | 3 | Max DEBUG retry count |
238
+ | `max_edit_lines_per_step` | `auto` | EditGuard cumulative write-line cap per Step; `auto` adapts to phase/tools/outputs/prompt context, while a number keeps a fixed hard cap |
239
+ | `max_write_chunk_bytes` | `auto` | `write_file` / `append_file` per-call content byte budget; `auto` adapts to phase/context, while complex work should still split by module/function/class boundaries |
240
+ | `sandbox_limits.network` | `download-only` | unrestricted outbound without published ports; use `off` for isolation; legacy `pypi-only` is rejected |
241
+
242
+ ---
243
+
244
+ ## Tests
245
+
246
+ ```bash
247
+ npm run typecheck
248
+ npm test # vitest, ~140 cases
249
+ npm run smoke:ollama # real ollama end-to-end smoke test
250
+ ```
251
+
252
+ ---
253
+
254
+ ## Deployment
255
+
256
+ Full steps in [docs/deploy.md](docs/deploy.md):
257
+
258
+ ```bash
259
+ # A. Local (Node 24 + Python 3)
260
+ npm ci && npm run build && npm link
261
+ xcompiler --help
262
+
263
+ # B. Docker (multi-stage image + compose)
264
+ docker build -t xcompiler:latest .
265
+ docker compose run --rm xcompiler --help
266
+ ```
267
+
268
+ The image bundles `python3 / git / docker.io / tini`. The sandbox can be `subprocess` (default) or `docker` (DooD โ€” mount `/var/run/docker.sock`).
269
+
270
+ ---
271
+
272
+ ## License
273
+
274
+ [Apache License 2.0](LICENSE) ยฉ 2026 The XCompiler Authors. See [NOTICE](NOTICE) for details.