archik 0.12.41 → 0.12.43

package/README.md

@@ -71,6 +71,8 @@ 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 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>
     <img src="https://cdn.jsdelivr.net/gh/bacharSalleh/archik@main/docs/archik.gif" alt="Archik canvas demo" width="780">

package/commands/bootstrap.md

@@ -47,7 +47,10 @@ brief and start the DESIGN loop.
 3. If `$ARGUMENTS` already contains a brief, treat it as the brief
    and skip step 4. Otherwise:
 4. **Ask for the brief**, in this exact shape (so the user knows
-   what fields you actually need):
+   what fields you actually need). The closing line is the load-
+   bearing one — it commits the conversation to actors-first +
+   pick-exactly-one + ship-it-with-tests, which is the framing
+   that makes the rest of the loop work:
    > "Send me a project brief in this shape (skip any line that
    > doesn't apply):
    >
@@ -57,8 +60,14 @@ brief and start the DESIGN loop.
    > **Constraints:** budget, deadline, team size, hard-no's.
    > **Out of scope:** things you explicitly DON'T want.
    >
-   > After you reply, I'll model actors first, then propose the
-   > first use case to ship."
+   > **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. 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.41",
+  "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,6 +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 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