leanlab 0.2.1__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.
- leanlab-0.2.1/.archik/.version +4 -0
- leanlab-0.2.1/.archik/ENGINEERING_LOOP.md +271 -0
- leanlab-0.2.1/.archik/PRINCIPLES.md +72 -0
- leanlab-0.2.1/.archik/SUPERPOWERS.md +37 -0
- leanlab-0.2.1/.archik/actors.archik.actors.yaml +12 -0
- leanlab-0.2.1/.archik/build-task.archik.seq.yaml +190 -0
- leanlab-0.2.1/.archik/init-lab.archik.seq.yaml +143 -0
- leanlab-0.2.1/.archik/main.archik.yaml +380 -0
- leanlab-0.2.1/.archik/run-experiments-fix.archik.seq.yaml +111 -0
- leanlab-0.2.1/.archik/run-experiments-happy.archik.seq.yaml +138 -0
- leanlab-0.2.1/.archik/spec-task.archik.seq.yaml +106 -0
- leanlab-0.2.1/.archik/usecases/build-task.archik.uc.yaml +41 -0
- leanlab-0.2.1/.archik/usecases/diagnose-lab.archik.uc.yaml +38 -0
- leanlab-0.2.1/.archik/usecases/init-lab.archik.uc.yaml +45 -0
- leanlab-0.2.1/.archik/usecases/run-experiments.archik.uc.yaml +46 -0
- leanlab-0.2.1/.archik/usecases/spec-task.archik.uc.yaml +37 -0
- leanlab-0.2.1/.archik/usecases/watch-progress.archik.uc.yaml +28 -0
- leanlab-0.2.1/.github/ISSUE_TEMPLATE/bug_report.yml +41 -0
- leanlab-0.2.1/.github/ISSUE_TEMPLATE/config.yml +8 -0
- leanlab-0.2.1/.github/ISSUE_TEMPLATE/feature_request.yml +22 -0
- leanlab-0.2.1/.github/PULL_REQUEST_TEMPLATE.md +17 -0
- leanlab-0.2.1/.github/RELEASING.md +44 -0
- leanlab-0.2.1/.github/dependabot.yml +52 -0
- leanlab-0.2.1/.github/workflows/ci.yml +79 -0
- leanlab-0.2.1/.github/workflows/publish.yml +75 -0
- leanlab-0.2.1/.gitignore +24 -0
- leanlab-0.2.1/.leanlab/house-prices/Critic_Feedback.md +66 -0
- leanlab-0.2.1/.leanlab/house-prices/Director_Notes.md +77 -0
- leanlab-0.2.1/.leanlab/house-prices/evaluation.py +95 -0
- leanlab-0.2.1/.leanlab/house-prices/experiments/catboost_oof_spatial_prior_01.py +85 -0
- leanlab-0.2.1/.leanlab/house-prices/experiments/hgb_geo_feats_01.py +51 -0
- leanlab-0.2.1/.leanlab/house-prices/experiments/honest_mono_catboost_logcap_01.py +113 -0
- leanlab-0.2.1/.leanlab/house-prices/experiments/lgbm_spatial_clusters_01.py +71 -0
- leanlab-0.2.1/.leanlab/house-prices/experiments/loghonest_spatial_blend_01.py +128 -0
- leanlab-0.2.1/.leanlab/house-prices/experiments/multiscale_spatial_blend_01.py +84 -0
- leanlab-0.2.1/.leanlab/house-prices/experiments/sample.py +7 -0
- leanlab-0.2.1/.leanlab/house-prices/experiments/spatial_stack_01.py +77 -0
- leanlab-0.2.1/.leanlab/house-prices/lab.json +12 -0
- leanlab-0.2.1/.leanlab/house-prices/results.jsonl +7 -0
- leanlab-0.2.1/.leanlab/house-prices/task.md +52 -0
- leanlab-0.2.1/.leanlab/house-prices/validate.py +52 -0
- leanlab-0.2.1/CHANGELOG.md +41 -0
- leanlab-0.2.1/CLAUDE.md +11 -0
- leanlab-0.2.1/CODE_OF_CONDUCT.md +33 -0
- leanlab-0.2.1/CONTRIBUTING.md +62 -0
- leanlab-0.2.1/FUTURE.md +25 -0
- leanlab-0.2.1/LICENSE +21 -0
- leanlab-0.2.1/PKG-INFO +273 -0
- leanlab-0.2.1/README.md +225 -0
- leanlab-0.2.1/SECURITY.md +23 -0
- leanlab-0.2.1/docs/USAGE.md +153 -0
- leanlab-0.2.1/docs/architecture.svg +37 -0
- leanlab-0.2.1/docs/build-task-flow.svg +2 -0
- leanlab-0.2.1/docs/run-experiments-fix.svg +2 -0
- leanlab-0.2.1/docs/run-experiments-happy.svg +2 -0
- leanlab-0.2.1/docs/superpowers/specs/2026-06-21-dashboard-overhaul-design.md +83 -0
- leanlab-0.2.1/docs/superpowers/specs/2026-06-21-leanlab-as-a-tool-design.md +85 -0
- leanlab-0.2.1/docs/superpowers/specs/2026-06-22-coding-lab-design.md +94 -0
- leanlab-0.2.1/frontend/.gitignore +2 -0
- leanlab-0.2.1/frontend/README.md +20 -0
- leanlab-0.2.1/frontend/index.html +12 -0
- leanlab-0.2.1/frontend/package-lock.json +2728 -0
- leanlab-0.2.1/frontend/package.json +23 -0
- leanlab-0.2.1/frontend/postcss.config.js +6 -0
- leanlab-0.2.1/frontend/src/App.jsx +99 -0
- leanlab-0.2.1/frontend/src/components/AgentChat.jsx +48 -0
- leanlab-0.2.1/frontend/src/components/Badge.jsx +14 -0
- leanlab-0.2.1/frontend/src/components/Header.jsx +16 -0
- leanlab-0.2.1/frontend/src/components/LoopPanel.jsx +37 -0
- leanlab-0.2.1/frontend/src/components/Panel.jsx +18 -0
- leanlab-0.2.1/frontend/src/components/Playbook.jsx +15 -0
- leanlab-0.2.1/frontend/src/components/StatRow.jsx +24 -0
- leanlab-0.2.1/frontend/src/components/TasksTable.jsx +83 -0
- leanlab-0.2.1/frontend/src/components/Timeline.jsx +111 -0
- leanlab-0.2.1/frontend/src/components/TokensChart.jsx +30 -0
- leanlab-0.2.1/frontend/src/hooks/useStream.js +22 -0
- leanlab-0.2.1/frontend/src/index.css +25 -0
- leanlab-0.2.1/frontend/src/lib/format.js +63 -0
- leanlab-0.2.1/frontend/src/main.jsx +5 -0
- leanlab-0.2.1/frontend/tailwind.config.js +26 -0
- leanlab-0.2.1/frontend/vite.config.js +15 -0
- leanlab-0.2.1/handoff.md +248 -0
- leanlab-0.2.1/leanlab/__init__.py +1 -0
- leanlab-0.2.1/leanlab/cli.py +315 -0
- leanlab-0.2.1/leanlab/core/__init__.py +1 -0
- leanlab-0.2.1/leanlab/core/agents/__init__.py +10 -0
- leanlab-0.2.1/leanlab/core/agents/claude.py +38 -0
- leanlab-0.2.1/leanlab/core/agents/port.py +49 -0
- leanlab-0.2.1/leanlab/core/agents/protocol.py +64 -0
- leanlab-0.2.1/leanlab/core/coding/__init__.py +1 -0
- leanlab-0.2.1/leanlab/core/coding/board.py +335 -0
- leanlab-0.2.1/leanlab/core/coding/board_dist/assets/index-BBCkNArL.css +1 -0
- leanlab-0.2.1/leanlab/core/coding/board_dist/assets/index-CNGMDAuO.js +40 -0
- leanlab-0.2.1/leanlab/core/coding/board_dist/index.html +13 -0
- leanlab-0.2.1/leanlab/core/coding/engineer.py +304 -0
- leanlab-0.2.1/leanlab/core/coding/gate.py +63 -0
- leanlab-0.2.1/leanlab/core/coding/personas.py +23 -0
- leanlab-0.2.1/leanlab/core/coding/playbook.py +47 -0
- leanlab-0.2.1/leanlab/core/coding/spec.py +232 -0
- leanlab-0.2.1/leanlab/core/doctor.py +220 -0
- leanlab-0.2.1/leanlab/core/init.py +219 -0
- leanlab-0.2.1/leanlab/core/loop.py +374 -0
- leanlab-0.2.1/leanlab/core/monitor.py +553 -0
- leanlab-0.2.1/leanlab/templates/agents/CLAUDE.md +52 -0
- leanlab-0.2.1/leanlab/templates/agents/critic.md +38 -0
- leanlab-0.2.1/leanlab/templates/agents/director.md +37 -0
- leanlab-0.2.1/leanlab/templates/agents/engineer.md +12 -0
- leanlab-0.2.1/leanlab/templates/agents/reviewer.md +34 -0
- leanlab-0.2.1/leanlab/templates/agents/techlead.md +7 -0
- leanlab-0.2.1/leanlab/templates/skill/SKILL.md +99 -0
- leanlab-0.2.1/pyproject.toml +75 -0
- leanlab-0.2.1/tests/test_coding_board.py +159 -0
- leanlab-0.2.1/tests/test_coding_engineer.py +273 -0
- leanlab-0.2.1/tests/test_coding_gate.py +47 -0
- leanlab-0.2.1/tests/test_coding_playbook.py +63 -0
- leanlab-0.2.1/tests/test_coding_spec.py +174 -0
- leanlab-0.2.1/tests/test_core.py +40 -0
- leanlab-0.2.1/tests/test_doctor.py +123 -0
- leanlab-0.2.1/tests/test_init.py +101 -0
- leanlab-0.2.1/tests/test_monitor.py +52 -0
- leanlab-0.2.1/tests/test_run_experiments_fix.py +61 -0
- leanlab-0.2.1/tests/test_run_experiments_happy.py +64 -0
- leanlab-0.2.1/tests/test_tooling.py +55 -0
- leanlab-0.2.1/uv.lock +1059 -0
|
@@ -0,0 +1,271 @@
|
|
|
1
|
+
# Engineering loop
|
|
2
|
+
|
|
3
|
+
> Drop this file into any new project as `CLAUDE.md`. Then your very first message to me should be **`/archik:bootstrap`** — I'll detect what state the project is in (empty, has-code, already-modelled) and route to the right next step. If you already know what you want to build, you can append a one-line brief: `/archik:bootstrap <what you're building>`. I'll then run the loop below.
|
|
4
|
+
>
|
|
5
|
+
> **Framing that makes the rest of the loop work:** when I ask for your brief, end it with *"start by modelling the actors and the first use case I should ship."* That single line forces priorities into the open before any code lands — actors-first (you can't validate a use case without knowing who initiates it), pick exactly one (no "I might also want…"), and "to ship" (the use case names its test paths from message one; slices flip from `proposed` to `active` mechanically when those tests land in BUILD).
|
|
6
|
+
|
|
7
|
+
## How I work on this project
|
|
8
|
+
|
|
9
|
+
I move from **brief → requirements model → structural model → behavioral model → build plan → code**. Each model is a reviewable artifact, gated by a HITL accept before the next one is produced. If implementation invalidates a model, I stop coding and fix the model first.
|
|
10
|
+
|
|
11
|
+
The **requirements model** (actors + use cases + slices) says *who* acts and *what* they want. The **structural model** (archik diagram — nodes, edges, ECB stereotypes) says *what exists*. The **behavioral model** (`*.archik.seq.yaml`, one per slice, with a `realizes` block) says *how it behaves at runtime*. Code is the last artifact, not the first.
|
|
12
|
+
|
|
13
|
+
Three gate types, one per artifact class:
|
|
14
|
+
|
|
15
|
+
- **Inline review** — show YAML in chat, user confirms. Used for actors, use cases, and seq files.
|
|
16
|
+
- **Canvas gate** — `/archik:accept` on the rendered diff. Used only for the structural sidecar.
|
|
17
|
+
- **Plan gate** — user replies "approve". Used for the build plan before any code edits.
|
|
18
|
+
|
|
19
|
+
### Match ritual to scope
|
|
20
|
+
|
|
21
|
+
Not every task needs the full loop. Skip the modeling phases and just edit when the change is:
|
|
22
|
+
|
|
23
|
+
- A single-file script, a one-line config tweak, a typo / copy fix
|
|
24
|
+
- A pure refactor that doesn't change the component graph or any actor-visible behavior
|
|
25
|
+
- A bug fix inside an existing node that doesn't change its responsibility
|
|
26
|
+
|
|
27
|
+
Run the loop when the change introduces new behavior, a new structural shape, a new external interaction, or a new actor.
|
|
28
|
+
|
|
29
|
+
### The five-phase loop
|
|
30
|
+
|
|
31
|
+
**DISCOVER → DESIGN → DECIDE → BUILD → VERIFY**, with one critical back-edge: if BUILD reveals any model is wrong, stop coding and loop back to DESIGN.
|
|
32
|
+
|
|
33
|
+
- **DISCOVER** — `npx archik q stats / list / usecases / actors`, `ls` source dirs. Read before write.
|
|
34
|
+
- **DESIGN** — actors (if new) → use case → structural sidecar (with ECB stereotypes) → seq files (with `realizes`). Each is its own artifact with its own gate (see below).
|
|
35
|
+
- **DECIDE** — `/archik:accept` on the structural sidecar only. Other artifacts are confirmed inline during DESIGN.
|
|
36
|
+
- **BUILD** — numbered plan → "approve" → execute in small commits. Tests-first when the behavior is clearly bounded.
|
|
37
|
+
- **VERIFY** — validate, tests, lint, build, `archik trace`, eyeball UI. Stage the `proposed → active` flip. Promote alphas whose criteria are now met.
|
|
38
|
+
|
|
39
|
+
The **per-milestone rhythm** below is the actionable checklist that walks these phases step-by-step.
|
|
40
|
+
|
|
41
|
+
### Worked example — one slice end-to-end
|
|
42
|
+
|
|
43
|
+
User says: *"add password reset by email."*
|
|
44
|
+
|
|
45
|
+
I'd run the loop like this:
|
|
46
|
+
|
|
47
|
+
1. **DISCOVER** — `npx archik q usecases`, `npx archik q actors`, peek at `src/auth/`. Find that `customer` actor exists, no reset use case yet, an `auth-service` node already handles login.
|
|
48
|
+
|
|
49
|
+
2. **DESIGN (a) actors** — no new actor; skip.
|
|
50
|
+
|
|
51
|
+
3. **DESIGN (b) use case** — write `.archik/usecases/reset-password.archik.uc.yaml` with `primaryActor: customer`, basic flow (request → email sent → click link → set new password), one alternate (`token-expired`), and two slices: `happy` and `expired-token`. Each slice names its test path. Validate. Show inline → user confirms.
|
|
52
|
+
|
|
53
|
+
4. **DESIGN (c) structural** — `npx archik suggest set` adding two `proposed` nodes: a `reset-handler` (`stereotype: control`) and an `email-sender` (`stereotype: boundary` to the email provider, modelled as `external`). Existing `auth-service` already covers entity (passwords table). Two new edges: `reset-handler → email-sender (calls)`, `reset-handler → auth-service (writes)`. Wait for **`/archik:accept`** on the canvas.
|
|
54
|
+
|
|
55
|
+
5. **DESIGN (d) seq** — write `.archik/reset-password-happy.archik.seq.yaml` with `realizes: { useCase: reset-password, slice: happy }`. Participants: `customer`, `reset-handler`, `email-sender`, `auth-service`. Six messages. Validate. Show inline → user confirms.
|
|
56
|
+
|
|
57
|
+
6. **BUILD plan** — `src/auth/resetHandler.ts` (request + verify), `src/auth/emailSender.ts` (provider client), `tests/auth/reset.happy.spec.ts`, `tests/auth/reset.expired.spec.ts`. Each seq message maps to a function call. Out of scope: rate limiting (next milestone). Wait for "approve".
|
|
58
|
+
|
|
59
|
+
7. **Execute** — small commits. One per file roughly.
|
|
60
|
+
|
|
61
|
+
8. **VERIFY** — tests pass; `npx archik trace` shows `reset-password/happy ✓` and `reset-password/expired-token ✓`. Stage a sidecar flipping the two new nodes from `proposed → active` with `sourcePath`. Hand off.
|
|
62
|
+
|
|
63
|
+
The whole flow produces five reviewable artifacts before code lands. Each is small. None is optional once the loop applies.
|
|
64
|
+
|
|
65
|
+
## First message — project brief
|
|
66
|
+
|
|
67
|
+
The recommended opener is **`/archik:bootstrap`** (with or without an inline brief). The slash command detects project state and routes to the right next step automatically. If you skip the slash command and just send a brief, expect me to:
|
|
68
|
+
|
|
69
|
+
1. **Bootstrap or upgrade archik:**
|
|
70
|
+
```sh
|
|
71
|
+
npx archik@latest init # fresh project — creates .archik/main.archik.yaml + slash commands
|
|
72
|
+
npx archik upgrade # already installed — pulls latest, refreshes SKILL.md + slash commands
|
|
73
|
+
```
|
|
74
|
+
Either path leaves the slash commands (`/archik:suggest`, `/archik:accept`, `/archik:usecase`, `/archik:actor`, `/archik:trace`, `/archik:alpha`, etc.) and the live canvas (`npx archik dev`) in place.
|
|
75
|
+
|
|
76
|
+
2. **Read the current state** with `ls -F`, `npx archik q list`, and `npx archik q usecases` (only relevant if archik is already populated).
|
|
77
|
+
|
|
78
|
+
3. **Surface genuine ambiguities** — usually 2–4 questions about scope, target users, hard constraints, or non-obvious tradeoffs. Skip questions whose answers are in the brief.
|
|
79
|
+
|
|
80
|
+
4. **Author the actors file** (direct-write) — who (human or system) initiates use cases. One `*.archik.actors.yaml` for the project. `kind: human | external-system | time | device`. Run `npx archik validate`. Show inline and wait for confirmation.
|
|
81
|
+
|
|
82
|
+
5. **Author the use cases** (direct-write) — what the actors want to accomplish. One `*.archik.uc.yaml` per use case under `.archik/usecases/`. Each includes a basic flow, alternate flows, and slices (a slice = a flow subset + the test paths that prove it). Active slices must name test files that will exist on disk when the code lands. Run `npx archik validate`. Show inline and wait for confirmation.
|
|
83
|
+
|
|
84
|
+
6. **Stage the structural model** via `npx archik suggest set` — every node the finished system needs, marked `status: proposed`, parented to a top-level `module`. Nodes participating in use case flows carry `stereotype: boundary | control | entity`. Wait for **`/archik:accept`** on the canvas (formal gate).
|
|
85
|
+
|
|
86
|
+
7. **Author the behavioral model** (direct-write) — one `.archik.seq.yaml` per slice that has a non-trivial runtime flow. Each seq file carries a `realizes: { useCase, slice }` block so the validator enforces bidirectional integrity. Participants bind to architecture node ids. Run `npx archik validate`. Show inline and wait for confirmation.
|
|
87
|
+
|
|
88
|
+
8. **The whole architecture lives on day one as `proposed`.** Milestones flip subsets from `proposed` to `active` (with `sourcePath`) as code lands. The set of nodes a milestone flips IS the milestone.
|
|
89
|
+
|
|
90
|
+
## Per-milestone rhythm
|
|
91
|
+
|
|
92
|
+
Every milestone follows the same shape. Three gate types apply — **inline review** (show YAML in chat, user confirms), **canvas gate** (`/archik:accept`), and **plan gate** ("approve"):
|
|
93
|
+
|
|
94
|
+
1. **Author actors** — `/archik:actor <id>` if this milestone introduces new actors. Updates `.archik/actors.archik.actors.yaml`, validates, shows inline; wait for user confirmation.
|
|
95
|
+
2. **Author use case** — `/archik:usecase <name>`. Writes a `*.archik.uc.yaml` with basic + alternate flows, slices, and test paths. Slices whose tests don't exist on disk yet start `status: proposed`. Validates, shows inline; wait for user confirmation.
|
|
96
|
+
3. **Structural sidecar** — `/archik:suggest <feature>`. Stages the proposed end-state for this milestone via `npx archik suggest set` under the hood. Tag participating nodes with `stereotype: boundary | control | entity`. Rationale in 2–4 bullets. Every node listed as a seq participant must declare the seq in its own `seqFiles` array (the validator catches missing backrefs).
|
|
97
|
+
4. **`/archik:accept` on the structural diagram** — formal canvas gate. This is the only artifact with a canvas diff review.
|
|
98
|
+
5. **Author seq files** (direct-write) — for each non-trivial slice, write a `.archik.seq.yaml` with a `realizes: { useCase, slice }` block. Run `npx archik validate` after every write. Show inline; wait for user confirmation.
|
|
99
|
+
6. **BUILD plan** — one-line goal, deps, files with paths and signatures, non-obvious bits, acceptance gate, out-of-scope items, the `proposed → active` flip this milestone will produce. For every seq diagram that realizes a slice: each message in the seq must map to a concrete function call in the plan — this is the traceability requirement.
|
|
100
|
+
7. **"approve" on the plan** — plan gate. Don't start editing files until approved.
|
|
101
|
+
8. **Execute** — small commits, narrate non-obvious decisions, declare back-edges to DESIGN openly when they happen.
|
|
102
|
+
9. **Verify** — project tests → lint → build → `/archik:trace` (or `npx archik trace`) → aesthetic eyeball (if UI). Trace must show no untraced active slices before the milestone closes; partials are tolerable mid-flight.
|
|
103
|
+
10. **Stage the `proposed → active` sidecar** — `/archik:suggest "flip <list> to active"`. Flips nodes/edges/slices with their `sourcePath` and `tests` now on disk.
|
|
104
|
+
11. **Hand off** — list what to eyeball; wait for `/archik:accept` and (if there's a deploy) confirm deploy is green. Then `/archik:alpha show` and promote any alpha whose criteria are now met.
|
|
105
|
+
12. **Commit + push** — only after the user confirms.
|
|
106
|
+
|
|
107
|
+
### When to author a sequence diagram
|
|
108
|
+
|
|
109
|
+
Author one when the milestone slice introduces:
|
|
110
|
+
|
|
111
|
+
- **Branching** — auth flows, conditional routing, retries with fallback.
|
|
112
|
+
- **Async fan-out** — one event triggers multiple subscribers.
|
|
113
|
+
- **Cross-context interaction** — three or more nodes participate in a single user-visible action.
|
|
114
|
+
- **External integrations with non-trivial handshake** — OAuth, webhook callbacks, idempotent retries.
|
|
115
|
+
- **Anything the user explicitly wants to spec before code** — even if it would otherwise be trivial.
|
|
116
|
+
|
|
117
|
+
Skip when: a single node handles the request end-to-end with no branching, or the slice is already covered by an existing seq file.
|
|
118
|
+
|
|
119
|
+
## Hard rules
|
|
120
|
+
|
|
121
|
+
1. **Requirements → structure → behavior → code. In that order.** Use cases define the scope of what to build. Structural nodes that participate in a use case flow carry ECB stereotypes. Behavioral seq files carry a `realizes` block. Code lands last.
|
|
122
|
+
2. **Three gate types, one per artifact class.** Actors, use cases, and seq files get an **inline review** (show YAML in chat, user confirms). The structural model gets a **canvas gate** (`/archik:accept`). The build plan gets an **approval gate** ("approve"). Don't conflate them — `/archik:accept` only works on structural sidecars.
|
|
123
|
+
3. **Active slices must be test-backed.** Each active slice in a use case declares the test paths that prove it. The validator rejects active slices with missing test files, mirroring `sourcePath` enforcement.
|
|
124
|
+
4. **Seq files carry a `realizes` block when linked to a slice.** The validator enforces bidirectional integrity — the use case's slice must name the seq file, and the seq file must reference that slice.
|
|
125
|
+
5. **ECB rules are enforced on realized seq diagrams.** Actors call boundaries; boundaries call controls; controls call entities or other controls. No direct actor → entity or entity → boundary messages.
|
|
126
|
+
6. **Stop at every milestone boundary.** Summarize what shipped, run verifications (`archik trace` must have no *untraced* active slices before the milestone closes — partials are tolerable mid-flight), ask for the visual ack before continuing.
|
|
127
|
+
7. **Boring underneath.** No experimental framework features unless explicitly requested. Match the stack the brief specifies.
|
|
128
|
+
8. **No scope creep.** Out-of-scope items go in `FUTURE.md`, not the current milestone.
|
|
129
|
+
9. **Back-edge from BUILD lands on whichever model is wrong.** If implementation reveals the structural model is wrong, fix the structural sidecar. If it reveals the behavioral model is wrong, edit the seq file. If it reveals the use case is wrong, update the uc file. Never paper over.
|
|
130
|
+
10. **Don't add comments that restate code.** Add a comment only when the WHY is non-obvious.
|
|
131
|
+
|
|
132
|
+
## What each phase produces
|
|
133
|
+
|
|
134
|
+
### DISCOVER
|
|
135
|
+
- `npx archik q stats` and `npx archik q list` to ground in the current diagram.
|
|
136
|
+
- `npx archik q usecases` and `npx archik q actors` to ground in the requirements model.
|
|
137
|
+
- `npx archik q sequences` to see flows already modelled.
|
|
138
|
+
- `ls -F` of relevant source dirs.
|
|
139
|
+
- A mental map of what exists vs what the request needs.
|
|
140
|
+
- No code, no diagram changes yet.
|
|
141
|
+
|
|
142
|
+
### DESIGN — (a) Actors
|
|
143
|
+
- One file: `*.archik.actors.yaml`. Separates human actors from system integrations.
|
|
144
|
+
- `kind: human | external-system | time | device`.
|
|
145
|
+
- Each actor has an `id`, a `description`, and optional `goals` (free text).
|
|
146
|
+
- Direct-write — no sidecar workflow. Validate with `npx archik validate`.
|
|
147
|
+
|
|
148
|
+
### DESIGN — (b) Requirements (use cases + slices)
|
|
149
|
+
- One `*.archik.uc.yaml` per use case under `.archik/usecases/`.
|
|
150
|
+
- Required fields: `id`, `name`, `primaryActor` (resolves in the actor index), `flows.basic`, at least one slice.
|
|
151
|
+
- Each slice: `id`, `description`, `flows` (which flows it covers), `tests` (array of on-disk test paths).
|
|
152
|
+
- Active slices with missing test files fail validation — same discipline as `sourcePath`.
|
|
153
|
+
- Optional: `realization.seqFile` per slice (set after the seq diagram is written).
|
|
154
|
+
- Schema: `npx archik schema uc`.
|
|
155
|
+
|
|
156
|
+
### DESIGN — (c) Structural
|
|
157
|
+
- One-line intent.
|
|
158
|
+
- 1–3 clarifying questions only when there's genuine ambiguity.
|
|
159
|
+
- A sidecar staged via `npx archik suggest set --note "..."` containing the **full proposed end-state**.
|
|
160
|
+
- New code-bearing nodes use `status: proposed` and may omit `sourcePath`.
|
|
161
|
+
- Nodes participating in a use case flow carry `stereotype: boundary | control | entity`.
|
|
162
|
+
- `description` on every node explains *what it does*, not *what kind it is*.
|
|
163
|
+
- Bounded contexts named explicitly; cross-context calls default to async unless there's a reason.
|
|
164
|
+
- Public traffic routes through a `gateway`/`auth` node, not directly to a service.
|
|
165
|
+
|
|
166
|
+
**ECB completeness check** — before staging the sidecar, run through
|
|
167
|
+
each active use case slice and verify the structural model has all
|
|
168
|
+
three ECB roles covered (each must carry the matching `stereotype`
|
|
169
|
+
field):
|
|
170
|
+
- A **boundary** node (`stereotype: boundary`) — the entry point the
|
|
171
|
+
actor touches: API handler, gateway, BFF. Missing = the slice has
|
|
172
|
+
no identified entry point; the actor has nowhere to call.
|
|
173
|
+
- A **control** node (`stereotype: control`) — the orchestrator that
|
|
174
|
+
runs the use case logic: service, use-case handler, workflow engine.
|
|
175
|
+
Missing = logic will bleed into the boundary or entity.
|
|
176
|
+
- An **entity** node (`stereotype: entity`) — persistent state:
|
|
177
|
+
repository, domain model, DB-backed store. Missing for a
|
|
178
|
+
state-changing slice = the persistence concern is unmodelled.
|
|
179
|
+
|
|
180
|
+
If any ECB role is absent, add the missing node (`status: proposed`
|
|
181
|
+
if not yet built) and tag it with the correct `stereotype` before
|
|
182
|
+
staging. An incomplete ECB model at structural-design time produces
|
|
183
|
+
ECB rule violations when the seq diagram is validated.
|
|
184
|
+
|
|
185
|
+
### DESIGN — (d) Behavioral
|
|
186
|
+
- One `.archik.seq.yaml` per non-trivial slice.
|
|
187
|
+
- Carries `realizes: { useCase: <id>, slice: <id> }` at the top level.
|
|
188
|
+
- Participants bound to architecture node ids that exist in the structural model.
|
|
189
|
+
- Messages typed correctly: `sync` / `async` / `return` / `create` / `destroy`.
|
|
190
|
+
- Branches modelled with `alt` / `opt` / `loop` groups; large flows via `ref` groups.
|
|
191
|
+
- `npx archik validate` run after every write — catches broken `nodeId` refs, duplicate step ids, and ECB rule violations.
|
|
192
|
+
- Linked from the relevant architecture node via `seqFiles` (this part goes through the structural sidecar).
|
|
193
|
+
|
|
194
|
+
### DECIDE
|
|
195
|
+
- The user runs `/archik:accept` (apply) or `/archik:reject` (with a reason).
|
|
196
|
+
- On reject: ask one specific question pinned to one axis — boundary / relationship / scope / naming / composition / lifecycle. Treat the answer as a hard constraint, re-stage. Never silently retry the same draft.
|
|
197
|
+
- Each model is its own gate.
|
|
198
|
+
|
|
199
|
+
### BUILD
|
|
200
|
+
- A numbered file-level plan, presented before any edit:
|
|
201
|
+
- Each new code-bearing node → its `sourcePath` and the concrete files / signatures.
|
|
202
|
+
- Each new edge that requires code → the corresponding code change.
|
|
203
|
+
- Each accepted seq diagram → trace it: every message in the flow must map to a function call in the plan.
|
|
204
|
+
- Slice test paths declared in the use case → scaffold those test files.
|
|
205
|
+
- Default to **tests-first** when the behavior is clearly bounded.
|
|
206
|
+
- Out-of-scope items called out explicitly.
|
|
207
|
+
- Wait for "approve" before editing.
|
|
208
|
+
- Small, reversible commits — one diagram delta per commit where practical.
|
|
209
|
+
|
|
210
|
+
### VERIFY
|
|
211
|
+
1. Project tests — all passing.
|
|
212
|
+
2. Lint — clean.
|
|
213
|
+
3. Build / typecheck — clean.
|
|
214
|
+
4. `npx archik validate` — schema + cross-file + ECB checks clean.
|
|
215
|
+
5. `npx archik trace` — no untraced active slices. `--fail-on partial` for CI gates.
|
|
216
|
+
6. `npx archik drift` — structural model matches disk.
|
|
217
|
+
7. Aesthetic eyeball when there's a UI — share a screenshot, ask before declaring done.
|
|
218
|
+
8. Stage the `proposed → active` sidecar — flip nodes/edges with `sourcePath`.
|
|
219
|
+
9. After the user accepts: run `npx archik alpha show` and promote any alpha whose criteria are now met.
|
|
220
|
+
10. Commit (with a Co-Authored-By line) and push — only after user confirms.
|
|
221
|
+
|
|
222
|
+
## Archik commands I use
|
|
223
|
+
|
|
224
|
+
**Reading the models:**
|
|
225
|
+
- `npx archik q list | edges | describe <id> | dependents <id> | impact <id>` — structural model.
|
|
226
|
+
- `npx archik q sequences [--node <id>]` — seq flows.
|
|
227
|
+
- `npx archik q stats` — node + edge counts.
|
|
228
|
+
- `npx archik q usecases [--actor <id>]` — use cases; `--actor` filters.
|
|
229
|
+
- `npx archik q describe-usecase <id>` — one use case in detail.
|
|
230
|
+
- `npx archik q actors` — actor index.
|
|
231
|
+
|
|
232
|
+
**Authoring:**
|
|
233
|
+
- `npx archik schema` — once before authoring any sidecar.
|
|
234
|
+
- `npx archik schema uc` — use case schema.
|
|
235
|
+
- `npx archik schema actors` — actors schema.
|
|
236
|
+
- `npx archik suggest set --note "<one-liner>" - <<'YAML' ... YAML` — stage a structural sidecar (full document).
|
|
237
|
+
- Direct `Write` / `Edit` on `*.archik.actors.yaml`, `*.archik.uc.yaml`, `*.archik.seq.yaml` — these have no sidecar workflow.
|
|
238
|
+
|
|
239
|
+
**Lifecycle:**
|
|
240
|
+
- `npx archik suggest accept | reject | show` — structural sidecar lifecycle.
|
|
241
|
+
- `npx archik validate` — schema + cross-file + ECB checks.
|
|
242
|
+
- `npx archik trace [--json] [--fail-on partial|none]` — coverage matrix: use case × slice × test × seq × ECB.
|
|
243
|
+
- `npx archik alpha show` — alpha state snapshot with verification badges.
|
|
244
|
+
- `npx archik alpha promote <alpha> <state> [--note <text>]` — promote with machine-checkable gate.
|
|
245
|
+
|
|
246
|
+
**Verification & rendering:**
|
|
247
|
+
- `npx archik drift` — source paths that no longer exist on disk.
|
|
248
|
+
- `npx archik render --out docs/architecture.svg` — regenerate committed SVG.
|
|
249
|
+
- `npx archik render --seq <path> --out <file>` — render a seq diagram to SVG.
|
|
250
|
+
|
|
251
|
+
## Common pitfalls
|
|
252
|
+
|
|
253
|
+
- **Editing `.archik/main.archik.yaml` by hand** — forbidden; always go through `suggest set`.
|
|
254
|
+
- **Skipping actors before use cases** — actors must exist before use cases can reference `primaryActor`.
|
|
255
|
+
- **Active slices without on-disk test paths** — validator rejects them. Use `status: proposed` for slices whose tests aren't written yet.
|
|
256
|
+
- **Seq file missing `realizes` block** — when a slice declares `realization.seqFile`, that seq file must carry the matching `realizes` block. The validator checks both directions.
|
|
257
|
+
- **Seq participants missing the `seqFiles` backref on the architecture node** — when you write a `realizes`-bound seq, every architecture node listed as a participant must also declare that seq in its own `seqFiles` array. Otherwise the seq is "linked from the requirements side, orphaned from the structural side" — `archik validate` rejects it. When staging the structural sidecar that hosts the participants, add `seqFiles: [.archik/<flow>.archik.seq.yaml]` to each. Closes the third side of the integrity triangle (use case ↔ seq ↔ node).
|
|
258
|
+
- **ECB violations in realized seq diagrams** — actor → boundary → control → entity is the allowed chain. `npx archik validate` catches violations at error level.
|
|
259
|
+
- **Skipping the behavioral model when the slice has branching or async** — write the seq diagram; future Claude reads it.
|
|
260
|
+
- **Writing prose-only summaries instead of staging a sidecar** — every structural change must produce a reviewable artifact.
|
|
261
|
+
- **Skipping the BUILD-plan HITL** — use case + diagram acceptance is not implicit code approval.
|
|
262
|
+
- **Renaming an `id` mid-flow** — forbidden; remove the old and add a new one. Renames break diff, seq participant bindings, and use case actor references.
|
|
263
|
+
- **Letting `archik trace` show untraced active slices at ship time** — partial is a warning; untraced is a gap. Fix before the milestone closes.
|
|
264
|
+
- **Over-claiming an alpha state** — `archik alpha show` marks it `✗ over-claimed`. Either fix the artifacts or demote the state.
|
|
265
|
+
|
|
266
|
+
## Working with this file
|
|
267
|
+
|
|
268
|
+
- This is `CLAUDE.md`. Future Claude sessions read it first.
|
|
269
|
+
- I add an `@AGENTS.md` line at the top if the project has framework-specific agent rules.
|
|
270
|
+
- I add project-specific sections under `## Stack` and `## File / module layout` once the architecture stabilizes — they replace the generic guidance with concrete file paths.
|
|
271
|
+
- Four artifacts, one project: this file is the **rhythm**, the archik diagram is the **structural model**, the use cases + actors are the **requirements model**, the seq files are the **behavioral model**, the code is the **implementation**. The rhythm threads them together.
|
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
<!-- archik:principles:oop -->
|
|
2
|
+
# Coding principles — Object-Oriented
|
|
3
|
+
|
|
4
|
+
The rules below govern *how code is written* once the archik loop reaches
|
|
5
|
+
BUILD. They sit underneath the engineering loop, not beside it: the loop
|
|
6
|
+
decides *what* to build and *in what order*; these decide *how the code is
|
|
7
|
+
shaped*.
|
|
8
|
+
|
|
9
|
+
## Separation of concerns
|
|
10
|
+
|
|
11
|
+
- One module, one reason to change. A file that mixes HTTP parsing,
|
|
12
|
+
business rules, and persistence is three modules wearing one name.
|
|
13
|
+
- Map concerns onto the ECB stereotypes already in the archik model:
|
|
14
|
+
**boundary** code handles I/O and translation, **control** code holds
|
|
15
|
+
use-case logic, **entity** code owns state and invariants. Don't let a
|
|
16
|
+
boundary make business decisions or an entity reach for the network.
|
|
17
|
+
- A function does one thing at one level of abstraction. If you need "and"
|
|
18
|
+
to describe it, split it.
|
|
19
|
+
|
|
20
|
+
## Composition over inheritance
|
|
21
|
+
|
|
22
|
+
- Default to composition. Inheritance is for genuine *is-a* substitutability,
|
|
23
|
+
not code reuse — reuse via collaborators, not base classes.
|
|
24
|
+
- Prefer small objects that delegate to injected collaborators over deep
|
|
25
|
+
class hierarchies. Depth past two levels is a smell.
|
|
26
|
+
- Program to an interface (or the narrowest type that works), not a
|
|
27
|
+
concrete class, at module boundaries.
|
|
28
|
+
|
|
29
|
+
## SOLID
|
|
30
|
+
|
|
31
|
+
- **S**ingle responsibility — see separation of concerns above.
|
|
32
|
+
- **O**pen/closed — extend behavior by adding a collaborator or
|
|
33
|
+
implementation, not by editing a switch that grows with every case.
|
|
34
|
+
- **L**iskov — a subtype must be usable anywhere its supertype is, with no
|
|
35
|
+
surprises. If an override throws "not supported," the hierarchy is wrong.
|
|
36
|
+
- **I**nterface segregation — many small role interfaces beat one fat one.
|
|
37
|
+
Callers depend only on the methods they use.
|
|
38
|
+
- **D**ependency inversion — high-level policy depends on abstractions;
|
|
39
|
+
details (DB, HTTP, clock) are injected. This is what makes control logic
|
|
40
|
+
testable without the world attached.
|
|
41
|
+
|
|
42
|
+
## Design patterns — used judiciously
|
|
43
|
+
|
|
44
|
+
- Patterns are a vocabulary, not a goal. Reach for one when the forces it
|
|
45
|
+
resolves are actually present (e.g. Strategy when behavior varies by case,
|
|
46
|
+
Adapter at an external boundary, Repository to hide persistence).
|
|
47
|
+
- Never introduce a pattern speculatively. A factory with one product or a
|
|
48
|
+
strategy with one strategy is accidental complexity — delete it.
|
|
49
|
+
- Name the pattern in a comment only when the WHY isn't obvious from the
|
|
50
|
+
code.
|
|
51
|
+
|
|
52
|
+
## Clean code
|
|
53
|
+
|
|
54
|
+
- Names carry intent: `unsettledInvoices`, not `data2`. A good name removes
|
|
55
|
+
the need for a comment.
|
|
56
|
+
- Small functions, few parameters. Past three or four parameters, introduce
|
|
57
|
+
a value object.
|
|
58
|
+
- No dead code, no commented-out blocks, no speculative generality (YAGNI).
|
|
59
|
+
- Encapsulate state: expose behavior, not raw fields. Invariants live with
|
|
60
|
+
the data they constrain so they can't be violated from outside.
|
|
61
|
+
- Fail fast and explicitly. Validate at the boundary; let control and
|
|
62
|
+
entity code assume valid input.
|
|
63
|
+
- Comments explain *why*, never restate *what* (this mirrors the loop's
|
|
64
|
+
hard rules).
|
|
65
|
+
|
|
66
|
+
## How this interacts with the loop
|
|
67
|
+
|
|
68
|
+
- These principles shape the BUILD phase. They never override a HITL gate or
|
|
69
|
+
the requirements/structure/behavior/code ordering.
|
|
70
|
+
- If applying a principle would change the component graph (e.g. extracting
|
|
71
|
+
a new control object), that's a structural change — go back through the
|
|
72
|
+
archik sidecar, don't just refactor silently.
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
<!-- archik:superpowers -->
|
|
2
|
+
# Superpowers ⨯ the engineering loop
|
|
3
|
+
|
|
4
|
+
This project opted into the **superpowers** plugin. The skills below are
|
|
5
|
+
wired into specific phases of the archik loop. At each phase, **invoke the
|
|
6
|
+
named skill** — but the skill *feeds* the archik artifact, it does not
|
|
7
|
+
replace it.
|
|
8
|
+
|
|
9
|
+
> If a superpowers skill isn't available in this session, the loop still
|
|
10
|
+
> stands on its own: `@.archik/ENGINEERING_LOOP.md` already describes the
|
|
11
|
+
> same discipline inline. These references make it explicit and stronger
|
|
12
|
+
> when the plugin is installed.
|
|
13
|
+
|
|
14
|
+
## Phase → skill map
|
|
15
|
+
|
|
16
|
+
| Loop phase | Invoke | What it feeds (the archik artifact) |
|
|
17
|
+
| --- | --- | --- |
|
|
18
|
+
| DESIGN — requirements | `superpowers:brainstorming` | Explore intent before committing. Output is the **archik requirements model** (actors + use cases + slices), *not* a separate spec doc. |
|
|
19
|
+
| BUILD — plan | `superpowers:writing-plans` | Turn the accepted models into the **numbered build plan** that goes through the plan gate. |
|
|
20
|
+
| BUILD — code | `superpowers:test-driven-development` | RED → GREEN → REFACTOR per slice. The tests it writes are the ones a slice names; landing them flips the slice `proposed → active`. |
|
|
21
|
+
| BUILD — when stuck | `superpowers:systematic-debugging` | Root-cause a failure before patching. A fix that invalidates a model triggers the loop's back-edge to DESIGN. |
|
|
22
|
+
| VERIFY — before "done" | `superpowers:verification-before-completion` | Evidence before claiming a slice is done. Gates the `proposed → active` flip and any "tests pass" claim. |
|
|
23
|
+
| Pre-merge | `superpowers:requesting-code-review` | Review before integrating, alongside `archik trace` / `archik validate`. |
|
|
24
|
+
| Branch isolation | `superpowers:using-git-worktrees` | Isolate the workspace before executing a multi-step plan. |
|
|
25
|
+
|
|
26
|
+
## Precedence
|
|
27
|
+
|
|
28
|
+
1. **User instructions** (this file, CLAUDE.md, direct requests) win.
|
|
29
|
+
2. **The archik loop gates** (`@.archik/ENGINEERING_LOOP.md`) win over a
|
|
30
|
+
skill's own flow. Example: `brainstorming` wants to write its own spec
|
|
31
|
+
file and end by invoking `writing-plans` — here, the design artifact is
|
|
32
|
+
the archik requirements model, and the plan still goes through the archik
|
|
33
|
+
plan gate.
|
|
34
|
+
3. **Superpowers skill discipline** applies within each phase.
|
|
35
|
+
|
|
36
|
+
The rule of thumb: **use the skill to do the phase well; let archik decide
|
|
37
|
+
what the phase produces and when the gate opens.**
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
version: "1.0"
|
|
2
|
+
actors:
|
|
3
|
+
- id: operator
|
|
4
|
+
kind: human
|
|
5
|
+
description: The researcher who runs leanlab — creates a lab, starts experiment runs, reviews the results table, and watches the dashboard.
|
|
6
|
+
goals:
|
|
7
|
+
- create-a-lab
|
|
8
|
+
- run-experiments
|
|
9
|
+
- review-progress
|
|
10
|
+
- id: claude
|
|
11
|
+
kind: external-system
|
|
12
|
+
description: The Claude LLM the loop launches as Worker / Director / Critic agent sessions to write, steer, and critique experiments. External to leanlab — invoked via the claude CLI.
|
|
@@ -0,0 +1,190 @@
|
|
|
1
|
+
version: "1.0"
|
|
2
|
+
name: Build a coding task — implement to green, prove honest, review, merge
|
|
3
|
+
description: >-
|
|
4
|
+
The engineer loop: implement in the worktree, run the gate, prove the change is honest
|
|
5
|
+
(locked tests untouched + pass without the engineer's own fixtures), then an adversarial
|
|
6
|
+
reviewer panel checks the diff. It loops on gate failures, gaming, or review feedback —
|
|
7
|
+
up to max-attempts — then merges and the tech-lead refreshes the playbook.
|
|
8
|
+
realizes:
|
|
9
|
+
useCase: build-task
|
|
10
|
+
slice: implement-to-green
|
|
11
|
+
participants:
|
|
12
|
+
- id: cli
|
|
13
|
+
nodeId: leanlab-cli
|
|
14
|
+
- id: eng
|
|
15
|
+
nodeId: engineer
|
|
16
|
+
- id: port
|
|
17
|
+
nodeId: agent-port
|
|
18
|
+
- id: agent
|
|
19
|
+
nodeId: claude-agent
|
|
20
|
+
- id: llm
|
|
21
|
+
nodeId: claude
|
|
22
|
+
- id: gate
|
|
23
|
+
nodeId: gate-runner
|
|
24
|
+
- id: tests
|
|
25
|
+
nodeId: acceptance-tests
|
|
26
|
+
- id: rev
|
|
27
|
+
nodeId: reviewer
|
|
28
|
+
- id: tl
|
|
29
|
+
nodeId: techlead
|
|
30
|
+
- id: pb
|
|
31
|
+
nodeId: playbook
|
|
32
|
+
steps:
|
|
33
|
+
- type: note
|
|
34
|
+
id: n-start
|
|
35
|
+
position: over
|
|
36
|
+
participants: [cli, eng]
|
|
37
|
+
text: "Operator builds a spec'd task — the worktree already holds the locked acceptance tests."
|
|
38
|
+
- type: message
|
|
39
|
+
id: m-build
|
|
40
|
+
from: cli
|
|
41
|
+
to: eng
|
|
42
|
+
label: "build(task, max-attempts, reviewers)"
|
|
43
|
+
arrow: sync
|
|
44
|
+
activate: true
|
|
45
|
+
- type: message
|
|
46
|
+
id: m-read-pb
|
|
47
|
+
from: eng
|
|
48
|
+
to: pb
|
|
49
|
+
label: "read PLAYBOOK (injected into the engineer prompt)"
|
|
50
|
+
arrow: sync
|
|
51
|
+
- type: group
|
|
52
|
+
id: g-loop
|
|
53
|
+
kind: loop
|
|
54
|
+
condition: "each round, until merged or max-attempts reached"
|
|
55
|
+
branches:
|
|
56
|
+
- steps:
|
|
57
|
+
- type: message
|
|
58
|
+
id: m-impl
|
|
59
|
+
from: eng
|
|
60
|
+
to: port
|
|
61
|
+
label: "implement / revise the change (read spec + locked tests)"
|
|
62
|
+
arrow: sync
|
|
63
|
+
- type: message
|
|
64
|
+
id: m-impl-agent
|
|
65
|
+
from: port
|
|
66
|
+
to: agent
|
|
67
|
+
label: "run_plain(engineer prompt [+ feedback])"
|
|
68
|
+
arrow: sync
|
|
69
|
+
- type: message
|
|
70
|
+
id: m-impl-llm
|
|
71
|
+
from: agent
|
|
72
|
+
to: llm
|
|
73
|
+
label: "claude -p (edits files in the worktree)"
|
|
74
|
+
arrow: sync
|
|
75
|
+
- type: message
|
|
76
|
+
id: m-impl-ret
|
|
77
|
+
from: port
|
|
78
|
+
to: eng
|
|
79
|
+
label: "change made"
|
|
80
|
+
arrow: return
|
|
81
|
+
- type: message
|
|
82
|
+
id: m-gate
|
|
83
|
+
from: eng
|
|
84
|
+
to: gate
|
|
85
|
+
label: "restore pristine tests, then run the gate"
|
|
86
|
+
arrow: sync
|
|
87
|
+
- type: message
|
|
88
|
+
id: m-gate-tests
|
|
89
|
+
from: gate
|
|
90
|
+
to: tests
|
|
91
|
+
label: "run locked acceptance + project tests"
|
|
92
|
+
arrow: sync
|
|
93
|
+
- type: message
|
|
94
|
+
id: m-gate-ret
|
|
95
|
+
from: gate
|
|
96
|
+
to: eng
|
|
97
|
+
label: "pass | fail"
|
|
98
|
+
arrow: return
|
|
99
|
+
- type: group
|
|
100
|
+
id: g-passed
|
|
101
|
+
kind: alt
|
|
102
|
+
condition: "gate passed"
|
|
103
|
+
branches:
|
|
104
|
+
- label: "[gate green]"
|
|
105
|
+
steps:
|
|
106
|
+
- type: message
|
|
107
|
+
id: m-honest
|
|
108
|
+
from: eng
|
|
109
|
+
to: gate
|
|
110
|
+
label: "honesty checks: tests untouched? pass w/o engineer fixtures?"
|
|
111
|
+
arrow: sync
|
|
112
|
+
- type: message
|
|
113
|
+
id: m-honest-tests
|
|
114
|
+
from: gate
|
|
115
|
+
to: tests
|
|
116
|
+
label: "isolated acceptance run (pytest --noconftest)"
|
|
117
|
+
arrow: sync
|
|
118
|
+
- type: message
|
|
119
|
+
id: m-honest-ret
|
|
120
|
+
from: gate
|
|
121
|
+
to: eng
|
|
122
|
+
label: "honest | tampered / gamed"
|
|
123
|
+
arrow: return
|
|
124
|
+
- type: group
|
|
125
|
+
id: g-honest
|
|
126
|
+
kind: alt
|
|
127
|
+
condition: "change is honest"
|
|
128
|
+
branches:
|
|
129
|
+
- label: "[honest]"
|
|
130
|
+
steps:
|
|
131
|
+
- type: note
|
|
132
|
+
id: n-panel
|
|
133
|
+
position: over
|
|
134
|
+
participants: [rev]
|
|
135
|
+
text: "Adversarial panel: N reviewers, distinct lenses; merge only if ALL approve."
|
|
136
|
+
- type: group
|
|
137
|
+
id: g-panel
|
|
138
|
+
kind: loop
|
|
139
|
+
condition: "for each reviewer lens (correctness / spec / security / robustness)"
|
|
140
|
+
branches:
|
|
141
|
+
- steps:
|
|
142
|
+
- type: message
|
|
143
|
+
id: m-review-call
|
|
144
|
+
from: rev
|
|
145
|
+
to: port
|
|
146
|
+
label: "run_structured(review prompt + lens)"
|
|
147
|
+
arrow: sync
|
|
148
|
+
- type: message
|
|
149
|
+
id: m-review-llm
|
|
150
|
+
from: port
|
|
151
|
+
to: agent
|
|
152
|
+
label: "claude -p (fresh, independent session)"
|
|
153
|
+
arrow: sync
|
|
154
|
+
- type: message
|
|
155
|
+
id: m-review-ret
|
|
156
|
+
from: rev
|
|
157
|
+
to: eng
|
|
158
|
+
label: "quorum: all approved | changes requested"
|
|
159
|
+
arrow: return
|
|
160
|
+
- label: "[tampered / gamed]"
|
|
161
|
+
steps:
|
|
162
|
+
- type: note
|
|
163
|
+
id: n-reject
|
|
164
|
+
position: over
|
|
165
|
+
participants: [eng]
|
|
166
|
+
text: "Reject the attempt, feed the reason back, loop."
|
|
167
|
+
- type: message
|
|
168
|
+
id: m-merge
|
|
169
|
+
from: eng
|
|
170
|
+
to: eng
|
|
171
|
+
label: "commit + merge branch into main"
|
|
172
|
+
arrow: sync
|
|
173
|
+
- type: message
|
|
174
|
+
id: m-refresh
|
|
175
|
+
from: eng
|
|
176
|
+
to: tl
|
|
177
|
+
label: "refresh the playbook"
|
|
178
|
+
arrow: sync
|
|
179
|
+
- type: message
|
|
180
|
+
id: m-write-pb
|
|
181
|
+
from: tl
|
|
182
|
+
to: pb
|
|
183
|
+
label: "rewrite PLAYBOOK.md from recent changes"
|
|
184
|
+
arrow: sync
|
|
185
|
+
- type: message
|
|
186
|
+
id: m-done
|
|
187
|
+
from: eng
|
|
188
|
+
to: cli
|
|
189
|
+
label: "merged — task complete"
|
|
190
|
+
arrow: return
|