archik 0.12.42 → 0.12.43

package/README.md

@@ -71,7 +71,7 @@ Day-to-day after that:
 
 `/archik:suggest` and `/archik:usecase` stage reviewable artifacts — diff overlay on the canvas, accept or reject. **Claude never edits YAML by hand**; the skill enforces CLI-only access.
 
-> **The framing that makes the rest of the loop work:** when Claude asks for your brief, end it with *"start by modelling the actors and the first use case I should ship."* Three things hide in that one sentence: actors-first (you can't validate a use case without knowing who initiates it), pick exactly one (forces priorities into the open before any code lands), and "to ship" (the use case gets `status: active` with real test paths — the system's commitments become mechanical from message one).
+> **The framing that makes the rest of the loop work:** when Claude asks for your brief, end it with *"start by modelling the actors and the first use case I should ship."* Three things hide in that one sentence: actors-first (you can't validate a use case without knowing who initiates it), pick exactly one (forces priorities into the open before any code lands), and "to ship" (the use case names its test paths from message one — slices start `status: proposed` and flip to `active` mechanically once those tests land in BUILD; the commitment is in the YAML, not the chat log).
 
 <p align="center">
   <video src="https://github.com/bacharSalleh/archik/raw/main/docs/record.mp4" poster="https://cdn.jsdelivr.net/gh/bacharSalleh/archik@main/docs/archik.gif" width="780" controls muted autoplay loop playsinline>

package/commands/bootstrap.md

@@ -62,9 +62,12 @@ brief and start the DESIGN loop.
    >
    > **Then end with:** *'Start by modelling the actors and the
    > first use case I should ship.'* — that single line is what
-   > forces priorities into the open before any code lands and
-   > makes the use case `status: active` with real test paths from
-   > message one."
+   > forces priorities into the open before any code lands. The
+   > use case names its test paths from message one; slices start
+   > `status: proposed` (because the tests don't exist on disk
+   > yet) and flip to `status: active` automatically when the
+   > tests land in BUILD. The commitment lives in the YAML, not
+   > in the chat log."
 5. When the brief lands, run the standard DESIGN loop:
    `/archik:actor` (if needed) → `/archik:usecase` → `/archik:suggest`
    (structural sidecar) → behavioural seq files. Stop at each

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "archik",
-  "version": "0.12.42",
+  "version": "0.12.43",
   "description": "The shared vocabulary between you and Claude Code, at the engineering level. Plain-YAML architecture diagrams with a live browser canvas, headless SVG render in CI, and an installable Claude skill so the model treats the diagram as the spec.",
   "keywords": [
     "architecture",

package/skills/archik/SKILL.md

@@ -10,7 +10,7 @@ description: Use whenever .archik/main.archik.yaml or architecture.archik.yaml e
 - **The YAML is the source of truth.** `.archik/main.archik.yaml` (and any `*.archik.yaml` sub-files) describe the system the user is building. The browser canvas is just a stateless projection of that file.
 - **The CLI is your only interface to it.** You never read, write, or edit archik files directly. Every read goes through `npx archik q ...`; every write goes through `npx archik suggest set` → user accepts via `/archik:accept`.
 - **Two command surfaces:** the user types `/archik:*` slash commands; you run `npx archik ...` directly. They're not interchangeable — see the tables below.
-- **Actors first, one use case to ship.** When a user hands you a brief on a fresh project, the right opening move is *model the actors, then propose the first use case to ship* — never "let me sketch your whole system." Actors-first because you can't validate a use case without knowing who initiates it. Pick exactly one because forcing priorities into the open before any code lands is the entire point of the loop. "To ship" because that use case becomes `status: active` with real test paths — the project's commitments turn mechanical from the very first turn.
+- **Actors first, one use case to ship.** When a user hands you a brief on a fresh project, the right opening move is *model the actors, then propose the first use case to ship* — never "let me sketch your whole system." Actors-first because you can't validate a use case without knowing who initiates it. Pick exactly one because forcing priorities into the open before any code lands is the entire point of the loop. "To ship" because the use case names its test paths from message one — slices start `status: proposed` (the tests don't exist on disk yet) and flip to `status: active` automatically when the tests land in BUILD. The project's commitments live in the YAML, not in the chat log.
 
 ## Command surfaces