louke 0.3.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.
- louke-0.3.0/LICENSE +21 -0
- louke-0.3.0/PKG-INFO +287 -0
- louke-0.3.0/README.md +261 -0
- louke-0.3.0/louke/__init__.py +13 -0
- louke-0.3.0/louke/__main__.py +80 -0
- louke-0.3.0/louke/_common.py +61 -0
- louke-0.3.0/louke/_security.py +128 -0
- louke-0.3.0/louke/_tests.py +134 -0
- louke-0.3.0/louke/_tools/__init__.py +0 -0
- louke-0.3.0/louke/_tools/add_frontmatter.py +40 -0
- louke-0.3.0/louke/_tools/check_acs.py +128 -0
- louke-0.3.0/louke/_tools/check_assertions.py +103 -0
- louke-0.3.0/louke/_tools/check_foundation.py +552 -0
- louke-0.3.0/louke/_tools/check_identity.py +306 -0
- louke-0.3.0/louke/_tools/ci_scan.py +58 -0
- louke-0.3.0/louke/_tools/git_diff_quote_resolver.py +127 -0
- louke-0.3.0/louke/_tools/quote_parser.py +564 -0
- louke-0.3.0/louke/_tools/verify_acceptance.py +368 -0
- louke-0.3.0/louke/_tools/verify_issue_schema.py +710 -0
- louke-0.3.0/louke/agents/Archer.md +159 -0
- louke-0.3.0/louke/agents/Devon.md +167 -0
- louke-0.3.0/louke/agents/Judge.md +168 -0
- louke-0.3.0/louke/agents/Keeper.md +141 -0
- louke-0.3.0/louke/agents/Lex.md +281 -0
- louke-0.3.0/louke/agents/Librarian.md +143 -0
- louke-0.3.0/louke/agents/Maestro.md +180 -0
- louke-0.3.0/louke/agents/Prism.md +231 -0
- louke-0.3.0/louke/agents/Sage.md +474 -0
- louke-0.3.0/louke/agents/Scout.md +228 -0
- louke-0.3.0/louke/agents/Shield.md +159 -0
- louke-0.3.0/louke/agents/Warden.md +142 -0
- louke-0.3.0/louke/archer.py +73 -0
- louke-0.3.0/louke/devon.py +84 -0
- louke-0.3.0/louke/judge.py +121 -0
- louke-0.3.0/louke/keeper.py +189 -0
- louke-0.3.0/louke/lex.py +66 -0
- louke-0.3.0/louke/librarian.py +194 -0
- louke-0.3.0/louke/maestro.py +252 -0
- louke-0.3.0/louke/prism.py +179 -0
- louke-0.3.0/louke/py.typed +0 -0
- louke-0.3.0/louke/sage.py +79 -0
- louke-0.3.0/louke/scout.py +82 -0
- louke-0.3.0/louke/shield.py +165 -0
- louke-0.3.0/louke/templates/acceptance.md +35 -0
- louke-0.3.0/louke/templates/bug-fix.md +43 -0
- louke-0.3.0/louke/templates/issues.md +17 -0
- louke-0.3.0/louke/templates/prd.md +22 -0
- louke-0.3.0/louke/templates/project-info.md +10 -0
- louke-0.3.0/louke/templates/security-checklist.md +114 -0
- louke-0.3.0/louke/templates/spec.md +78 -0
- louke-0.3.0/louke/templates/task-log.md +33 -0
- louke-0.3.0/louke/templates/task-plan.md +29 -0
- louke-0.3.0/louke/templates/test-plan.md +251 -0
- louke-0.3.0/louke/warden.py +38 -0
- louke-0.3.0/louke.egg-info/PKG-INFO +287 -0
- louke-0.3.0/louke.egg-info/SOURCES.txt +59 -0
- louke-0.3.0/louke.egg-info/dependency_links.txt +1 -0
- louke-0.3.0/louke.egg-info/entry_points.txt +2 -0
- louke-0.3.0/louke.egg-info/top_level.txt +1 -0
- louke-0.3.0/pyproject.toml +44 -0
- louke-0.3.0/setup.cfg +4 -0
louke-0.3.0/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2025-2026 louke team
|
|
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.
|
louke-0.3.0/PKG-INFO
ADDED
|
@@ -0,0 +1,287 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: louke
|
|
3
|
+
Version: 0.3.0
|
|
4
|
+
Summary: Lòukè - 超越氛围写意,乃是工笔造物 (beyond vibes, into craft)
|
|
5
|
+
Author: louke team
|
|
6
|
+
License: MIT
|
|
7
|
+
Project-URL: Homepage, https://github.com/zillionare/louke
|
|
8
|
+
Project-URL: Repository, https://github.com/zillionare/louke
|
|
9
|
+
Project-URL: Issues, https://github.com/zillionare/louke/issues
|
|
10
|
+
Keywords: spec-driven,tdd,multi-agent,craft,hold-point,agent-framework
|
|
11
|
+
Classifier: Development Status :: 3 - Alpha
|
|
12
|
+
Classifier: Intended Audience :: Developers
|
|
13
|
+
Classifier: License :: OSI Approved :: MIT License
|
|
14
|
+
Classifier: Operating System :: OS Independent
|
|
15
|
+
Classifier: Programming Language :: Python :: 3
|
|
16
|
+
Classifier: Programming Language :: Python :: 3.9
|
|
17
|
+
Classifier: Programming Language :: Python :: 3.10
|
|
18
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
19
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
20
|
+
Classifier: Topic :: Software Development
|
|
21
|
+
Classifier: Topic :: Software Development :: Quality Assurance
|
|
22
|
+
Requires-Python: >=3.9
|
|
23
|
+
Description-Content-Type: text/markdown
|
|
24
|
+
License-File: LICENSE
|
|
25
|
+
Dynamic: license-file
|
|
26
|
+
|
|
27
|
+
# louke
|
|
28
|
+
|
|
29
|
+
> **beyond vibes, into Louke(craft).**
|
|
30
|
+
|
|
31
|
+

|
|
32
|
+
|
|
33
|
+
[🇨🇳 中文](README.zh.md) · [🇺🇸 English](README.md)
|
|
34
|
+
|
|
35
|
+
**louke is a multi-agent collaborative development methodology built on spec-first, test-driven, and tool-aligned agent behavior.** Every stage transition is a tool-enforced check.
|
|
36
|
+
|
|
37
|
+
---
|
|
38
|
+
|
|
39
|
+
### Why louke?
|
|
40
|
+
|
|
41
|
+
You can't build a real software with one-sentence vibecoding.
|
|
42
|
+
|
|
43
|
+
A real software has hundreds to thousands of sub-requirements, tens of thousands of execution paths and boundary checks.
|
|
44
|
+
|
|
45
|
+
Real work takes concrete, detailed specs, acceptance criteria, and test plans. Humans must participate in and guide the production of these documents; tools must break them into traceable sub-items so agent code maps one-to-one to those items. Only then can we build a retractable, traceable, trustworthy software production process.
|
|
46
|
+
|
|
47
|
+
That's the value of louke. Beyond vibecoding — agent programming becomes precision manufacturing, executing every detail you specified perfectly.
|
|
48
|
+
|
|
49
|
+
When vibecoding:
|
|
50
|
+
|
|
51
|
+
- You haven't figured out what software you want, yet expect the agent to know
|
|
52
|
+
- Words are always suggestive and leave too much room for imagination, but software must be precise
|
|
53
|
+
- You have many Stories, but neither AI nor you has formed a complete blueprint
|
|
54
|
+
|
|
55
|
+
Even spec-kit / superpowers / oh-my-openagent don't turn spec into a "programming contract". For spec to be a contract, three things must hold simultaneously — and louke is the only one that achieves them:
|
|
56
|
+
|
|
57
|
+
- **Sub-requirements are orthogonal** — non-conflicting and non-overlapping, already pruned by Occam's razor
|
|
58
|
+
- **Right-sized granularity** — you can't expect an agent to read a 10,000-word document and still grasp every small detail, unless you break them into items that fit cleanly into a PR
|
|
59
|
+
- **Traceable** — every thread from requirement to code to test must be bidirectionally traceable: forward to find the source, backward to find the landing. Any requirement that can't be matched to its code and tests is a blank check hanging on the wall
|
|
60
|
+
|
|
61
|
+
And the deepest gap between louke and other frameworks: louke turns this into **Infrastructure-as-Checkpoint** — the traceable loop is not in the AI's self-discipline, but in the forced execution of external CLIs at commit-time. `exit 0/1` is an OS process return value; you can't bypass it. The engineering world only recognizes this one language.
|
|
62
|
+
|
|
63
|
+
### What louke provides
|
|
64
|
+
|
|
65
|
+
louke turns the contract's three principles into 5 observable things. Each maps to an `lk` command or a traceable artifact — not just prompts, but tools:
|
|
66
|
+
|
|
67
|
+
- **spec → GitHub issue, commits must reference issue** — Lex converts each FR into an issue; Devon's commit message enforces `#NNN` format. Requirement to code, one-way trace, never lost
|
|
68
|
+
|
|
69
|
+
- **test ↔ AC-FRXXXX-YY auto-association, CI static validation closes both directions** — every test docstring must carry an `AC-FRXXXX-YY` ID. `lk archer ci-scan` validates at commit-time: every AC must be referenced by a test, every test must reference an AC. If the loop doesn't close, merge is blocked
|
|
70
|
+
|
|
71
|
+
- **Anti-pattern CI gate + identity consistency check** — `lk keeper gate` statically scans 8 anti-patterns (`assert True` / `try/except: pass` / no-issue skip / mock-framework core / ...). `lk scout identity-check` locks gh/git identity consistency before workflow start. Violations block
|
|
72
|
+
|
|
73
|
+
- **Project wiki auto-distillation** — based on LLM compounding engineering, `.louke/raw/` (each agent's session records) → `.louke/wiki/` (structured knowledge). Facts, decisions, current state at a glance, lint-checkable
|
|
74
|
+
|
|
75
|
+
- **Socratic requirement interrogation** — Sage asks multiple rounds of questions around a vague story until it produces traceable `spec.md` + `acceptance.md`
|
|
76
|
+
|
|
77
|
+
`louke` defines 12 specialized agents, a 10-stage pipeline, and an `lk` CLI — so every transition is a real check, not the soft "agents review each other". Each agent has its own dedicated toolbox; at every hold point, work is gated for verification.
|
|
78
|
+
|
|
79
|
+
### The Pipeline
|
|
80
|
+
|
|
81
|
+
| Stage | Implementer | Reviewer | Notes |
|
|
82
|
+
|---|---|---|---|
|
|
83
|
+
| M-FOUND | Scout | Warden | Project setup + permission gate |
|
|
84
|
+
| M-SPEC | Sage | Lex | spec + FR → issue, Lex reviews + 100% verifies |
|
|
85
|
+
| M-TESTPLAN | Archer | Sage | Test plan (Sage has unique spec context) |
|
|
86
|
+
| M-ARCH | Archer | Prism | Architecture + interfaces |
|
|
87
|
+
| M-LOCK | Maestro | User | 3-signal lock (Sage quote-parser + Lex 3 stages + User confirm) |
|
|
88
|
+
| M-DEV | Devon | **Prism → Keeper ★** | Code + unit tests |
|
|
89
|
+
| M-E2E | Shield | **Prism → Keeper ★** | e2e tests (B-level) |
|
|
90
|
+
| M-BUGFIX | Devon | **Keeper ★** | Bug fixes |
|
|
91
|
+
| M-SECURITY | Judge (S-level) | User | Deep security audit |
|
|
92
|
+
| M-MILESTONE | Librarian | Maestro | raw → wiki distillation |
|
|
93
|
+
|
|
94
|
+
★ **HOLD POINT** — tool-enforced check (`lk` CLI returns 0/1; pipeline doesn't advance until it passes). `★` only marks the PROD gate that blocks merge at commit-time; stage-transition hold points aren't separately marked.
|
|
95
|
+
|
|
96
|
+
**Principle: implementer ≠ reviewer. Always.**
|
|
97
|
+
|
|
98
|
+
### Naming
|
|
99
|
+
|
|
100
|
+
The 12 agents are named for what they do, not for decoration:
|
|
101
|
+
|
|
102
|
+
| Agent | Meaning | Job image |
|
|
103
|
+
|-------|---------|-----------|
|
|
104
|
+
| **Maestro** | Conductor | coordinates the whole ensemble |
|
|
105
|
+
| **Scout** | Pathfinder | scouts the terrain, verifies preconditions |
|
|
106
|
+
| **Warden** | Gatekeeper | guards the door, confirms exit conditions |
|
|
107
|
+
| **Sage** | The wise | asks Socratic questions |
|
|
108
|
+
| **Lex** | The law | enforces spec-level precision + organizes issues |
|
|
109
|
+
| **Archer** | Marksman / architect | designs the execution path (test-plan + architecture) |
|
|
110
|
+
| **Devon** | Smith | forges code from the fire of tests (R-G-R) |
|
|
111
|
+
| **Prism** | Prism | refracts code through multiple angles (test anti-patterns + security quick scan) |
|
|
112
|
+
| **Judge** | Arbiter | S-grade deep security audit |
|
|
113
|
+
| **Shield** | Shield | writes end-to-end scripts (B-grade) |
|
|
114
|
+
| **Keeper** | Warden of gates | enforces quality gates (commit format + tests + lint + regression) |
|
|
115
|
+
| **Librarian** | Librarian | distills Wiki, preserves project memory |
|
|
116
|
+
|
|
117
|
+
### Install
|
|
118
|
+
|
|
119
|
+
> **Platform support**: macOS and Linux only. Windows users: please use [WSL2](https://learn.microsoft.com/en-us/windows/wsl/) or Docker. The installer self-checks `uname -s` and exits with a clear error on unsupported platforms.
|
|
120
|
+
|
|
121
|
+
```bash
|
|
122
|
+
# Standard pip-based install (recommended): auto-creates venv, sets PATH, links lk to ~/.local/bin
|
|
123
|
+
curl -sSL https://raw.githubusercontent.com/zillionare/louke/main/install.sh | bash
|
|
124
|
+
|
|
125
|
+
# Or pin a version
|
|
126
|
+
curl -sSL https://raw.githubusercontent.com/zillionare/louke/main/install.sh | bash -s -- v0.3.0
|
|
127
|
+
|
|
128
|
+
# Or dev mode (clone + editable install)
|
|
129
|
+
git clone https://github.com/zillionare/louke
|
|
130
|
+
cd louke
|
|
131
|
+
./install.sh --editable
|
|
132
|
+
|
|
133
|
+
# Verify
|
|
134
|
+
lk --help
|
|
135
|
+
```
|
|
136
|
+
|
|
137
|
+
`install.sh` does 4 things:
|
|
138
|
+
|
|
139
|
+
1. Creates an isolated venv at `~/.louke/venv/` (no system-Python pollution)
|
|
140
|
+
2. `pip install louke` into that venv
|
|
141
|
+
3. `~/.local/bin/lk` → symlink to venv's `lk`, and appends PATH to your shell rc
|
|
142
|
+
4. Verifies the install + prints uninstall instructions
|
|
143
|
+
|
|
144
|
+
Uninstall:
|
|
145
|
+
|
|
146
|
+
```bash
|
|
147
|
+
rm -rf ~/.louke/venv ~/.local/bin/lk
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
You now have:
|
|
151
|
+
- `lk` CLI (32 commands, 12 agents)
|
|
152
|
+
- `templates/` — 4 doc templates (spec, acceptance, test-plan, security-checklist)
|
|
153
|
+
- `louke/_tools/` — Python scripts wrapped by `lk`
|
|
154
|
+
|
|
155
|
+
### Use in Your Project
|
|
156
|
+
|
|
157
|
+
Initialize via `lk scout foundation`:
|
|
158
|
+
|
|
159
|
+
```bash
|
|
160
|
+
lk scout foundation --repo YOUR_ORG/YOUR_REPO --version v0.1 --spec-id v0.1-001-init
|
|
161
|
+
# → creates .louke/project/project-info.md
|
|
162
|
+
# → creates .louke/project/specs/v0.1-001-init/story.md
|
|
163
|
+
# → opens editor for you to fill in story (interactive)
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
`lk scout foundation` walks you through:
|
|
167
|
+
1. Step 1 — Collect story/version/repo/DoD (interactive)
|
|
168
|
+
2. Step 2 — Create repo + project + permissions
|
|
169
|
+
3. Step 3 — Verify gh + git identity
|
|
170
|
+
4. Step 4 — Run `lk warden foundation-check` (F1-F11 automated checks)
|
|
171
|
+
5. Step 5 — Commit + push
|
|
172
|
+
|
|
173
|
+
### Use with Your AI Assistant
|
|
174
|
+
|
|
175
|
+
`agents/*.md` are written as natural-language agent prompts. Any coding agent that reads instructions can use them.
|
|
176
|
+
|
|
177
|
+
#### OpenCode
|
|
178
|
+
|
|
179
|
+
Add the framework as a plugin in `~/.config/opencode/opencode.json`:
|
|
180
|
+
|
|
181
|
+
```json
|
|
182
|
+
{"plugin": ["louke"]}
|
|
183
|
+
```
|
|
184
|
+
|
|
185
|
+
#### Claude Code
|
|
186
|
+
|
|
187
|
+
Place `agents/` under `.claude/agents/` and reference each role via `--agent`:
|
|
188
|
+
|
|
189
|
+
```bash
|
|
190
|
+
claude --agent agents/Sage.md "interview me about user auth"
|
|
191
|
+
```
|
|
192
|
+
|
|
193
|
+
#### VSCode (Cursor / Continue / Copilot)
|
|
194
|
+
|
|
195
|
+
Add the agent prompts to your rules:
|
|
196
|
+
|
|
197
|
+
```json
|
|
198
|
+
// .continue/config.json
|
|
199
|
+
{
|
|
200
|
+
"rules": [
|
|
201
|
+
"agents/Maestro.md",
|
|
202
|
+
"agents/Sage.md",
|
|
203
|
+
"agents/Archer.md"
|
|
204
|
+
]
|
|
205
|
+
}
|
|
206
|
+
```
|
|
207
|
+
|
|
208
|
+
In Cursor: **Settings → Rules → Add file → `agents/Sage.md`**
|
|
209
|
+
|
|
210
|
+
### A Working Session
|
|
211
|
+
|
|
212
|
+
In a typical session with one of the above AI assistants:
|
|
213
|
+
|
|
214
|
+
```
|
|
215
|
+
1. lk scout foundation # Initialize project, verify permissions
|
|
216
|
+
2. "You are Sage. Interview me about user auth." # AI plays Sage role
|
|
217
|
+
3. lk sage commit-spec --spec ... # Commit spec + acceptance
|
|
218
|
+
4. lk lex verify-acceptance # [HOLD POINT] Different agent, tool-enforced
|
|
219
|
+
5. "You are Archer. Write test-plan + arch + interfaces."
|
|
220
|
+
6. lk archer ci-scan # AC reference + anti-pattern scan
|
|
221
|
+
7. "You are Devon. Implement in R-G-R."
|
|
222
|
+
8. lk devon commit-rgr --phase red/green/refactor
|
|
223
|
+
9. lk keeper gate # [HOLD POINT] Tool-enforced commit format
|
|
224
|
+
10. lk judge security-audit # [HOLD POINT] S-level security review
|
|
225
|
+
11. lk librarian from-raw # Distill session → wiki
|
|
226
|
+
12. lk maestro status # Check progress
|
|
227
|
+
```
|
|
228
|
+
|
|
229
|
+
Each `★` HOLD POINT returns 0 (pass) or 1 (fail). The pipeline doesn't advance until it passes.
|
|
230
|
+
|
|
231
|
+
### How It Works: One Spec, End to End
|
|
232
|
+
|
|
233
|
+
Say you want to build user auth:
|
|
234
|
+
|
|
235
|
+
1. **M-FOUND** (Scout) — `lk scout foundation` creates the repo, GitHub Project, and a Test Issue to verify permissions.
|
|
236
|
+
2. **M-SPEC** (Sage → Lex) — Sage interviews you Socratically (MFA? session timeout? rate limiting?). Lex finds 3 issues. Sage fixes, marks spec locked when **3 signals align**: `lk sage quote-check` exit 0, Lex 3 stages pass, user confirms in IDE.
|
|
237
|
+
3. **M-TESTPLAN** (Archer → Sage) — Archer writes `test-plan.md` with 3-layer testing strategy + AC traceability + anti-pattern rules. Sage reviews (it has unique spec context from M-SPEC).
|
|
238
|
+
4. **M-ARCH** (Archer → Prism) — Archer writes `architecture.md` + `interfaces.md`. Prism checks spec/code consistency.
|
|
239
|
+
5. **M-LOCK** — Spec locked. Implementation begins.
|
|
240
|
+
6. **M-DEV** (Devon → Prism → Keeper) — Devon implements in R-G-R. Each commit prefixed `test: red`, `feat: green`, `refactor`. Prism reviews (cynical + test patterns + security quick scan). Keeper runs `lk keeper gate` (commit format + tests).
|
|
241
|
+
7. **M-E2E** (Shield → Prism → Keeper) — Shield writes e2e (B-level, simple methods: Playwright/testclient/DB). Same Prism + Keeper.
|
|
242
|
+
8. **M-SECURITY** (Judge S-level → User) — `lk judge security-audit` does pattern scan + S-level semantic review. User makes final call.
|
|
243
|
+
9. **M-MILESTONE** (Librarian → Maestro) — `lk librarian from-raw` distills the session to wiki. `lk maestro advance --stage M-MILESTONE` closes the milestone.
|
|
244
|
+
|
|
245
|
+
Each transition is a different agent. Each hold point is tool-enforced. Each handoff is explicit.
|
|
246
|
+
|
|
247
|
+
### How louke compares
|
|
248
|
+
|
|
249
|
+
| Framework | Is spec a contract? | Who reviews | Enforcement layer | spec → code → test loop |
|
|
250
|
+
|---|---|---|---|---|
|
|
251
|
+
| **spec-kit** (GitHub) | spec.md is the source, but no MECE / granularity / traceability constraints | No review | None | Manual + social |
|
|
252
|
+
| **superpowers** (obra, 240k★) | plan.md is plain text, no AC numbering, no commit-time validation | subagent review (same model reviewing itself) | prompt-level self-discipline | TDD indirect guarantee (no ID binding between test and spec) |
|
|
253
|
+
| **oh-my-openagent** (code-yeongyu, 64k★) | agents digest spec themselves | team of agents (same LLM, different prompts) | hooks / middleware | task self-defined, no FR ↔ test binding |
|
|
254
|
+
| **louke** | FR-XXX / AC-XXX-N + `lk archer ci-scan` | 12 different personas (implementer ≠ reviewer, cross-stage context disjoint) | `lk` CLI exit 0/1 (OS process return value) | FR ↔ issue ↔ commit ↔ AC ↔ test end-to-end |
|
|
255
|
+
|
|
256
|
+
### Architecture (Light)
|
|
257
|
+
|
|
258
|
+
```
|
|
259
|
+
agents/*.md templates/*.md louke/ louke/_tools/*.py
|
|
260
|
+
(12 prompts) (spec, acceptance, (32 commands, (Python scripts,
|
|
261
|
+
test-plan, security- 12 agents) wrapped by lk)
|
|
262
|
+
checklist)
|
|
263
|
+
│ │ │ │
|
|
264
|
+
└───────────┬───────────┴────────────┬───────────────┘ │
|
|
265
|
+
│ │ │
|
|
266
|
+
↓ ↓ ↓
|
|
267
|
+
AI assistant Tool-enforced wrapped by lk
|
|
268
|
+
(OpenCode, Cursor, hold points
|
|
269
|
+
Claude Code, (lk keeper gate,
|
|
270
|
+
Continue, etc.) lk judge
|
|
271
|
+
security-audit)
|
|
272
|
+
|
|
273
|
+
Two-tier memory:
|
|
274
|
+
.louke/raw/ → episodic, per-agent session records
|
|
275
|
+
.louke/wiki/ → distilled knowledge, maintained by Librarian
|
|
276
|
+
```
|
|
277
|
+
|
|
278
|
+
Four things louke doesn't compromise on:
|
|
279
|
+
|
|
280
|
+
- **12 Agents** = implementer ≠ reviewer; cross-stage context is disjoint
|
|
281
|
+
- **`lk` CLI** = OS-process-level contract; `exit 0/1` is unbypassable
|
|
282
|
+
- **Two-tier memory** = `raw/` (episodic) + `wiki/` (distilled), maintained by Librarian
|
|
283
|
+
- **Promise** = spec → code → test three-segment bidirectional reachability; breakage at any node can be traced to its source
|
|
284
|
+
|
|
285
|
+
### License
|
|
286
|
+
|
|
287
|
+
MIT
|
louke-0.3.0/README.md
ADDED
|
@@ -0,0 +1,261 @@
|
|
|
1
|
+
# louke
|
|
2
|
+
|
|
3
|
+
> **beyond vibes, into Louke(craft).**
|
|
4
|
+
|
|
5
|
+

|
|
6
|
+
|
|
7
|
+
[🇨🇳 中文](README.zh.md) · [🇺🇸 English](README.md)
|
|
8
|
+
|
|
9
|
+
**louke is a multi-agent collaborative development methodology built on spec-first, test-driven, and tool-aligned agent behavior.** Every stage transition is a tool-enforced check.
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
### Why louke?
|
|
14
|
+
|
|
15
|
+
You can't build a real software with one-sentence vibecoding.
|
|
16
|
+
|
|
17
|
+
A real software has hundreds to thousands of sub-requirements, tens of thousands of execution paths and boundary checks.
|
|
18
|
+
|
|
19
|
+
Real work takes concrete, detailed specs, acceptance criteria, and test plans. Humans must participate in and guide the production of these documents; tools must break them into traceable sub-items so agent code maps one-to-one to those items. Only then can we build a retractable, traceable, trustworthy software production process.
|
|
20
|
+
|
|
21
|
+
That's the value of louke. Beyond vibecoding — agent programming becomes precision manufacturing, executing every detail you specified perfectly.
|
|
22
|
+
|
|
23
|
+
When vibecoding:
|
|
24
|
+
|
|
25
|
+
- You haven't figured out what software you want, yet expect the agent to know
|
|
26
|
+
- Words are always suggestive and leave too much room for imagination, but software must be precise
|
|
27
|
+
- You have many Stories, but neither AI nor you has formed a complete blueprint
|
|
28
|
+
|
|
29
|
+
Even spec-kit / superpowers / oh-my-openagent don't turn spec into a "programming contract". For spec to be a contract, three things must hold simultaneously — and louke is the only one that achieves them:
|
|
30
|
+
|
|
31
|
+
- **Sub-requirements are orthogonal** — non-conflicting and non-overlapping, already pruned by Occam's razor
|
|
32
|
+
- **Right-sized granularity** — you can't expect an agent to read a 10,000-word document and still grasp every small detail, unless you break them into items that fit cleanly into a PR
|
|
33
|
+
- **Traceable** — every thread from requirement to code to test must be bidirectionally traceable: forward to find the source, backward to find the landing. Any requirement that can't be matched to its code and tests is a blank check hanging on the wall
|
|
34
|
+
|
|
35
|
+
And the deepest gap between louke and other frameworks: louke turns this into **Infrastructure-as-Checkpoint** — the traceable loop is not in the AI's self-discipline, but in the forced execution of external CLIs at commit-time. `exit 0/1` is an OS process return value; you can't bypass it. The engineering world only recognizes this one language.
|
|
36
|
+
|
|
37
|
+
### What louke provides
|
|
38
|
+
|
|
39
|
+
louke turns the contract's three principles into 5 observable things. Each maps to an `lk` command or a traceable artifact — not just prompts, but tools:
|
|
40
|
+
|
|
41
|
+
- **spec → GitHub issue, commits must reference issue** — Lex converts each FR into an issue; Devon's commit message enforces `#NNN` format. Requirement to code, one-way trace, never lost
|
|
42
|
+
|
|
43
|
+
- **test ↔ AC-FRXXXX-YY auto-association, CI static validation closes both directions** — every test docstring must carry an `AC-FRXXXX-YY` ID. `lk archer ci-scan` validates at commit-time: every AC must be referenced by a test, every test must reference an AC. If the loop doesn't close, merge is blocked
|
|
44
|
+
|
|
45
|
+
- **Anti-pattern CI gate + identity consistency check** — `lk keeper gate` statically scans 8 anti-patterns (`assert True` / `try/except: pass` / no-issue skip / mock-framework core / ...). `lk scout identity-check` locks gh/git identity consistency before workflow start. Violations block
|
|
46
|
+
|
|
47
|
+
- **Project wiki auto-distillation** — based on LLM compounding engineering, `.louke/raw/` (each agent's session records) → `.louke/wiki/` (structured knowledge). Facts, decisions, current state at a glance, lint-checkable
|
|
48
|
+
|
|
49
|
+
- **Socratic requirement interrogation** — Sage asks multiple rounds of questions around a vague story until it produces traceable `spec.md` + `acceptance.md`
|
|
50
|
+
|
|
51
|
+
`louke` defines 12 specialized agents, a 10-stage pipeline, and an `lk` CLI — so every transition is a real check, not the soft "agents review each other". Each agent has its own dedicated toolbox; at every hold point, work is gated for verification.
|
|
52
|
+
|
|
53
|
+
### The Pipeline
|
|
54
|
+
|
|
55
|
+
| Stage | Implementer | Reviewer | Notes |
|
|
56
|
+
|---|---|---|---|
|
|
57
|
+
| M-FOUND | Scout | Warden | Project setup + permission gate |
|
|
58
|
+
| M-SPEC | Sage | Lex | spec + FR → issue, Lex reviews + 100% verifies |
|
|
59
|
+
| M-TESTPLAN | Archer | Sage | Test plan (Sage has unique spec context) |
|
|
60
|
+
| M-ARCH | Archer | Prism | Architecture + interfaces |
|
|
61
|
+
| M-LOCK | Maestro | User | 3-signal lock (Sage quote-parser + Lex 3 stages + User confirm) |
|
|
62
|
+
| M-DEV | Devon | **Prism → Keeper ★** | Code + unit tests |
|
|
63
|
+
| M-E2E | Shield | **Prism → Keeper ★** | e2e tests (B-level) |
|
|
64
|
+
| M-BUGFIX | Devon | **Keeper ★** | Bug fixes |
|
|
65
|
+
| M-SECURITY | Judge (S-level) | User | Deep security audit |
|
|
66
|
+
| M-MILESTONE | Librarian | Maestro | raw → wiki distillation |
|
|
67
|
+
|
|
68
|
+
★ **HOLD POINT** — tool-enforced check (`lk` CLI returns 0/1; pipeline doesn't advance until it passes). `★` only marks the PROD gate that blocks merge at commit-time; stage-transition hold points aren't separately marked.
|
|
69
|
+
|
|
70
|
+
**Principle: implementer ≠ reviewer. Always.**
|
|
71
|
+
|
|
72
|
+
### Naming
|
|
73
|
+
|
|
74
|
+
The 12 agents are named for what they do, not for decoration:
|
|
75
|
+
|
|
76
|
+
| Agent | Meaning | Job image |
|
|
77
|
+
|-------|---------|-----------|
|
|
78
|
+
| **Maestro** | Conductor | coordinates the whole ensemble |
|
|
79
|
+
| **Scout** | Pathfinder | scouts the terrain, verifies preconditions |
|
|
80
|
+
| **Warden** | Gatekeeper | guards the door, confirms exit conditions |
|
|
81
|
+
| **Sage** | The wise | asks Socratic questions |
|
|
82
|
+
| **Lex** | The law | enforces spec-level precision + organizes issues |
|
|
83
|
+
| **Archer** | Marksman / architect | designs the execution path (test-plan + architecture) |
|
|
84
|
+
| **Devon** | Smith | forges code from the fire of tests (R-G-R) |
|
|
85
|
+
| **Prism** | Prism | refracts code through multiple angles (test anti-patterns + security quick scan) |
|
|
86
|
+
| **Judge** | Arbiter | S-grade deep security audit |
|
|
87
|
+
| **Shield** | Shield | writes end-to-end scripts (B-grade) |
|
|
88
|
+
| **Keeper** | Warden of gates | enforces quality gates (commit format + tests + lint + regression) |
|
|
89
|
+
| **Librarian** | Librarian | distills Wiki, preserves project memory |
|
|
90
|
+
|
|
91
|
+
### Install
|
|
92
|
+
|
|
93
|
+
> **Platform support**: macOS and Linux only. Windows users: please use [WSL2](https://learn.microsoft.com/en-us/windows/wsl/) or Docker. The installer self-checks `uname -s` and exits with a clear error on unsupported platforms.
|
|
94
|
+
|
|
95
|
+
```bash
|
|
96
|
+
# Standard pip-based install (recommended): auto-creates venv, sets PATH, links lk to ~/.local/bin
|
|
97
|
+
curl -sSL https://raw.githubusercontent.com/zillionare/louke/main/install.sh | bash
|
|
98
|
+
|
|
99
|
+
# Or pin a version
|
|
100
|
+
curl -sSL https://raw.githubusercontent.com/zillionare/louke/main/install.sh | bash -s -- v0.3.0
|
|
101
|
+
|
|
102
|
+
# Or dev mode (clone + editable install)
|
|
103
|
+
git clone https://github.com/zillionare/louke
|
|
104
|
+
cd louke
|
|
105
|
+
./install.sh --editable
|
|
106
|
+
|
|
107
|
+
# Verify
|
|
108
|
+
lk --help
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
`install.sh` does 4 things:
|
|
112
|
+
|
|
113
|
+
1. Creates an isolated venv at `~/.louke/venv/` (no system-Python pollution)
|
|
114
|
+
2. `pip install louke` into that venv
|
|
115
|
+
3. `~/.local/bin/lk` → symlink to venv's `lk`, and appends PATH to your shell rc
|
|
116
|
+
4. Verifies the install + prints uninstall instructions
|
|
117
|
+
|
|
118
|
+
Uninstall:
|
|
119
|
+
|
|
120
|
+
```bash
|
|
121
|
+
rm -rf ~/.louke/venv ~/.local/bin/lk
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
You now have:
|
|
125
|
+
- `lk` CLI (32 commands, 12 agents)
|
|
126
|
+
- `templates/` — 4 doc templates (spec, acceptance, test-plan, security-checklist)
|
|
127
|
+
- `louke/_tools/` — Python scripts wrapped by `lk`
|
|
128
|
+
|
|
129
|
+
### Use in Your Project
|
|
130
|
+
|
|
131
|
+
Initialize via `lk scout foundation`:
|
|
132
|
+
|
|
133
|
+
```bash
|
|
134
|
+
lk scout foundation --repo YOUR_ORG/YOUR_REPO --version v0.1 --spec-id v0.1-001-init
|
|
135
|
+
# → creates .louke/project/project-info.md
|
|
136
|
+
# → creates .louke/project/specs/v0.1-001-init/story.md
|
|
137
|
+
# → opens editor for you to fill in story (interactive)
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
`lk scout foundation` walks you through:
|
|
141
|
+
1. Step 1 — Collect story/version/repo/DoD (interactive)
|
|
142
|
+
2. Step 2 — Create repo + project + permissions
|
|
143
|
+
3. Step 3 — Verify gh + git identity
|
|
144
|
+
4. Step 4 — Run `lk warden foundation-check` (F1-F11 automated checks)
|
|
145
|
+
5. Step 5 — Commit + push
|
|
146
|
+
|
|
147
|
+
### Use with Your AI Assistant
|
|
148
|
+
|
|
149
|
+
`agents/*.md` are written as natural-language agent prompts. Any coding agent that reads instructions can use them.
|
|
150
|
+
|
|
151
|
+
#### OpenCode
|
|
152
|
+
|
|
153
|
+
Add the framework as a plugin in `~/.config/opencode/opencode.json`:
|
|
154
|
+
|
|
155
|
+
```json
|
|
156
|
+
{"plugin": ["louke"]}
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
#### Claude Code
|
|
160
|
+
|
|
161
|
+
Place `agents/` under `.claude/agents/` and reference each role via `--agent`:
|
|
162
|
+
|
|
163
|
+
```bash
|
|
164
|
+
claude --agent agents/Sage.md "interview me about user auth"
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
#### VSCode (Cursor / Continue / Copilot)
|
|
168
|
+
|
|
169
|
+
Add the agent prompts to your rules:
|
|
170
|
+
|
|
171
|
+
```json
|
|
172
|
+
// .continue/config.json
|
|
173
|
+
{
|
|
174
|
+
"rules": [
|
|
175
|
+
"agents/Maestro.md",
|
|
176
|
+
"agents/Sage.md",
|
|
177
|
+
"agents/Archer.md"
|
|
178
|
+
]
|
|
179
|
+
}
|
|
180
|
+
```
|
|
181
|
+
|
|
182
|
+
In Cursor: **Settings → Rules → Add file → `agents/Sage.md`**
|
|
183
|
+
|
|
184
|
+
### A Working Session
|
|
185
|
+
|
|
186
|
+
In a typical session with one of the above AI assistants:
|
|
187
|
+
|
|
188
|
+
```
|
|
189
|
+
1. lk scout foundation # Initialize project, verify permissions
|
|
190
|
+
2. "You are Sage. Interview me about user auth." # AI plays Sage role
|
|
191
|
+
3. lk sage commit-spec --spec ... # Commit spec + acceptance
|
|
192
|
+
4. lk lex verify-acceptance # [HOLD POINT] Different agent, tool-enforced
|
|
193
|
+
5. "You are Archer. Write test-plan + arch + interfaces."
|
|
194
|
+
6. lk archer ci-scan # AC reference + anti-pattern scan
|
|
195
|
+
7. "You are Devon. Implement in R-G-R."
|
|
196
|
+
8. lk devon commit-rgr --phase red/green/refactor
|
|
197
|
+
9. lk keeper gate # [HOLD POINT] Tool-enforced commit format
|
|
198
|
+
10. lk judge security-audit # [HOLD POINT] S-level security review
|
|
199
|
+
11. lk librarian from-raw # Distill session → wiki
|
|
200
|
+
12. lk maestro status # Check progress
|
|
201
|
+
```
|
|
202
|
+
|
|
203
|
+
Each `★` HOLD POINT returns 0 (pass) or 1 (fail). The pipeline doesn't advance until it passes.
|
|
204
|
+
|
|
205
|
+
### How It Works: One Spec, End to End
|
|
206
|
+
|
|
207
|
+
Say you want to build user auth:
|
|
208
|
+
|
|
209
|
+
1. **M-FOUND** (Scout) — `lk scout foundation` creates the repo, GitHub Project, and a Test Issue to verify permissions.
|
|
210
|
+
2. **M-SPEC** (Sage → Lex) — Sage interviews you Socratically (MFA? session timeout? rate limiting?). Lex finds 3 issues. Sage fixes, marks spec locked when **3 signals align**: `lk sage quote-check` exit 0, Lex 3 stages pass, user confirms in IDE.
|
|
211
|
+
3. **M-TESTPLAN** (Archer → Sage) — Archer writes `test-plan.md` with 3-layer testing strategy + AC traceability + anti-pattern rules. Sage reviews (it has unique spec context from M-SPEC).
|
|
212
|
+
4. **M-ARCH** (Archer → Prism) — Archer writes `architecture.md` + `interfaces.md`. Prism checks spec/code consistency.
|
|
213
|
+
5. **M-LOCK** — Spec locked. Implementation begins.
|
|
214
|
+
6. **M-DEV** (Devon → Prism → Keeper) — Devon implements in R-G-R. Each commit prefixed `test: red`, `feat: green`, `refactor`. Prism reviews (cynical + test patterns + security quick scan). Keeper runs `lk keeper gate` (commit format + tests).
|
|
215
|
+
7. **M-E2E** (Shield → Prism → Keeper) — Shield writes e2e (B-level, simple methods: Playwright/testclient/DB). Same Prism + Keeper.
|
|
216
|
+
8. **M-SECURITY** (Judge S-level → User) — `lk judge security-audit` does pattern scan + S-level semantic review. User makes final call.
|
|
217
|
+
9. **M-MILESTONE** (Librarian → Maestro) — `lk librarian from-raw` distills the session to wiki. `lk maestro advance --stage M-MILESTONE` closes the milestone.
|
|
218
|
+
|
|
219
|
+
Each transition is a different agent. Each hold point is tool-enforced. Each handoff is explicit.
|
|
220
|
+
|
|
221
|
+
### How louke compares
|
|
222
|
+
|
|
223
|
+
| Framework | Is spec a contract? | Who reviews | Enforcement layer | spec → code → test loop |
|
|
224
|
+
|---|---|---|---|---|
|
|
225
|
+
| **spec-kit** (GitHub) | spec.md is the source, but no MECE / granularity / traceability constraints | No review | None | Manual + social |
|
|
226
|
+
| **superpowers** (obra, 240k★) | plan.md is plain text, no AC numbering, no commit-time validation | subagent review (same model reviewing itself) | prompt-level self-discipline | TDD indirect guarantee (no ID binding between test and spec) |
|
|
227
|
+
| **oh-my-openagent** (code-yeongyu, 64k★) | agents digest spec themselves | team of agents (same LLM, different prompts) | hooks / middleware | task self-defined, no FR ↔ test binding |
|
|
228
|
+
| **louke** | FR-XXX / AC-XXX-N + `lk archer ci-scan` | 12 different personas (implementer ≠ reviewer, cross-stage context disjoint) | `lk` CLI exit 0/1 (OS process return value) | FR ↔ issue ↔ commit ↔ AC ↔ test end-to-end |
|
|
229
|
+
|
|
230
|
+
### Architecture (Light)
|
|
231
|
+
|
|
232
|
+
```
|
|
233
|
+
agents/*.md templates/*.md louke/ louke/_tools/*.py
|
|
234
|
+
(12 prompts) (spec, acceptance, (32 commands, (Python scripts,
|
|
235
|
+
test-plan, security- 12 agents) wrapped by lk)
|
|
236
|
+
checklist)
|
|
237
|
+
│ │ │ │
|
|
238
|
+
└───────────┬───────────┴────────────┬───────────────┘ │
|
|
239
|
+
│ │ │
|
|
240
|
+
↓ ↓ ↓
|
|
241
|
+
AI assistant Tool-enforced wrapped by lk
|
|
242
|
+
(OpenCode, Cursor, hold points
|
|
243
|
+
Claude Code, (lk keeper gate,
|
|
244
|
+
Continue, etc.) lk judge
|
|
245
|
+
security-audit)
|
|
246
|
+
|
|
247
|
+
Two-tier memory:
|
|
248
|
+
.louke/raw/ → episodic, per-agent session records
|
|
249
|
+
.louke/wiki/ → distilled knowledge, maintained by Librarian
|
|
250
|
+
```
|
|
251
|
+
|
|
252
|
+
Four things louke doesn't compromise on:
|
|
253
|
+
|
|
254
|
+
- **12 Agents** = implementer ≠ reviewer; cross-stage context is disjoint
|
|
255
|
+
- **`lk` CLI** = OS-process-level contract; `exit 0/1` is unbypassable
|
|
256
|
+
- **Two-tier memory** = `raw/` (episodic) + `wiki/` (distilled), maintained by Librarian
|
|
257
|
+
- **Promise** = spec → code → test three-segment bidirectional reachability; breakage at any node can be traced to its source
|
|
258
|
+
|
|
259
|
+
### License
|
|
260
|
+
|
|
261
|
+
MIT
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
"""lk - louke CLI.
|
|
2
|
+
|
|
3
|
+
工具统一入口。每个 agent 一个入口文件 (louke/{agent}.py),agent prompt 通过
|
|
4
|
+
`lk <agent> {command} [--args]` 调用,避免在 agents/*.md 中出现裸 bash 多步命令。
|
|
5
|
+
|
|
6
|
+
设计原则:
|
|
7
|
+
1. 每 agent 一个入口文件 (louke/{agent}.py)
|
|
8
|
+
2. agent 不直接调底层脚本,而是通过 `lk <agent>` 调用
|
|
9
|
+
3. 多步命令封装成单个 `lk` 命令,减少出错可能
|
|
10
|
+
4. 子命令内部可用 subprocess 调底层工具 (louke/_tools/*.py),或实现新逻辑
|
|
11
|
+
5. 退出码遵循 Unix 惯例: 0 = 成功, 非 0 = 失败
|
|
12
|
+
"""
|
|
13
|
+
__version__ = "0.1.0"
|
|
@@ -0,0 +1,80 @@
|
|
|
1
|
+
"""lk CLI entry point.
|
|
2
|
+
|
|
3
|
+
Usage:
|
|
4
|
+
lk <agent> <command> [options]
|
|
5
|
+
|
|
6
|
+
Examples:
|
|
7
|
+
lk scout identity-check --repo owner/repo
|
|
8
|
+
lk sage quote-check --spec v0.1-001-init
|
|
9
|
+
lk warden foundation-check --repo owner/repo --version v0.1 --spec-id v0.1-001-init
|
|
10
|
+
lk lex verify-acceptance --spec v0.1-001-init
|
|
11
|
+
lk archer ci-scan --spec v0.1-001-init
|
|
12
|
+
|
|
13
|
+
设计:
|
|
14
|
+
- 每 agent 一个模块 (louke/{agent}.py),暴露 register(subparsers) 和 run(args)
|
|
15
|
+
- __main__ 解析 lk <agent> <command>,dispatch 到对应 agent.run()
|
|
16
|
+
"""
|
|
17
|
+
import argparse
|
|
18
|
+
import sys
|
|
19
|
+
|
|
20
|
+
from . import (
|
|
21
|
+
scout,
|
|
22
|
+
sage,
|
|
23
|
+
warden,
|
|
24
|
+
lex,
|
|
25
|
+
archer,
|
|
26
|
+
keeper,
|
|
27
|
+
judge,
|
|
28
|
+
prism,
|
|
29
|
+
devon,
|
|
30
|
+
shield,
|
|
31
|
+
librarian,
|
|
32
|
+
maestro,
|
|
33
|
+
)
|
|
34
|
+
|
|
35
|
+
AGENTS = {
|
|
36
|
+
'scout': scout,
|
|
37
|
+
'sage': sage,
|
|
38
|
+
'warden': warden,
|
|
39
|
+
'lex': lex,
|
|
40
|
+
'archer': archer,
|
|
41
|
+
'keeper': keeper,
|
|
42
|
+
'judge': judge,
|
|
43
|
+
'prism': prism,
|
|
44
|
+
'devon': devon,
|
|
45
|
+
'shield': shield,
|
|
46
|
+
'librarian': librarian,
|
|
47
|
+
'maestro': maestro,
|
|
48
|
+
}
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
def build_parser():
|
|
52
|
+
parser = argparse.ArgumentParser(
|
|
53
|
+
prog='lk',
|
|
54
|
+
description='louke CLI - 工具统一入口(每 agent 一个子命令空间)',
|
|
55
|
+
)
|
|
56
|
+
subparsers = parser.add_subparsers(
|
|
57
|
+
dest='agent', required=True, metavar='<agent>'
|
|
58
|
+
)
|
|
59
|
+
for name, module in AGENTS.items():
|
|
60
|
+
if hasattr(module, 'register'):
|
|
61
|
+
module.register(subparsers)
|
|
62
|
+
return parser
|
|
63
|
+
|
|
64
|
+
|
|
65
|
+
def main(argv=None):
|
|
66
|
+
parser = build_parser()
|
|
67
|
+
args = parser.parse_args(argv)
|
|
68
|
+
agent_module = AGENTS.get(args.agent)
|
|
69
|
+
if not agent_module or not hasattr(agent_module, 'run'):
|
|
70
|
+
parser.error(f"agent '{args.agent}' 未实现")
|
|
71
|
+
return 1
|
|
72
|
+
try:
|
|
73
|
+
return agent_module.run(args) or 0
|
|
74
|
+
except Exception as e:
|
|
75
|
+
print(f"lk {args.agent} {getattr(args, 'command', '?')}: {e}", file=sys.stderr)
|
|
76
|
+
return 1
|
|
77
|
+
|
|
78
|
+
|
|
79
|
+
if __name__ == '__main__':
|
|
80
|
+
sys.exit(main())
|