archik 0.19.5 → 0.20.0

package/commands/spawn.md

@@ -87,30 +87,12 @@ archik suggest set` stages it.
    - **Frontends**: `apps/web`, `apps/mobile`, `client/`,
      `packages/ui` apps that ship a UI → `frontend`.
 
-5. **Choose the kind and ECB stereotype for each node.** Default
+5. **Choose the kind for each node.** Default
    kind: `service`. Use the taxonomy from the skill — `function`
    for serverless, `worker` for background consumers, `agent` for
    LLM-driven agents, etc. When unsure, pick the closest fit and
    add a `notes:` entry explaining the inference.
 
-   For every node that faces a user or external system, also infer
-   its ECB `stereotype`:
-   - `stereotype: boundary` — accepts requests from actors / external
-     systems: API handlers, gateways, adapters, webhook endpoints,
-     BFF layers. Rule of thumb: the first thing an actor touches.
-   - `stereotype: control` — orchestrates use-case logic: services
-     that coordinate domain objects, use-case handlers, workflow
-     engines. Rule of thumb: knows *what* to do but delegates *how*.
-   - `stereotype: entity` — stores or represents domain data:
-     repositories, domain models, DB-backed modules, caches.
-     Rule of thumb: knows the data and its invariants.
-
-   If a node's role is purely infrastructure (`database`, `queue`,
-   `external`, `cloud`, etc.) or genuinely ambiguous, omit
-   `stereotype` — don't guess. The field is optional and the
-   validator only enforces ECB transition rules on seq diagrams
-   that carry a `realizes` block.
-
 6. **Attach `sourcePath` to every code-bearing node.** This is
    non-negotiable in a normal/suggested file — the validator rejects
    any `service`, `function`, `worker`, `module`, `page`, `component`,
@@ -223,27 +205,18 @@ archik suggest set` stages it.
      `/archik:evolve` after accepting if you want a cleaner
      bounded-context version."
 
-   **Offer the Jacobson-chain follow-up at the end of this step**
-   (not after accept — you won't be there). Check what's missing
-   before framing the offer:
+   **Offer a smells check at the end of this step** (not after
+   accept — you won't be there). Run it now so the offer is concrete:
    ```
-   npx archik q actors
-   npx archik q usecases
+   npx archik smells
    ```
-   Then close with one of these follow-up lines, whichever fits:
-   - No actors, diagram has boundary nodes / user-facing components:
-     *"Once you accept, ask me to author a `*.archik.actors.yaml`
-     — that's the starting point for use-case coverage."*
-   - Actors exist but no use cases:
-     *"Once you accept, ask me to stub `*.archik.uc.yaml` files for
-     the key flows."*
-   - Both exist already:
-     *"Run `/archik:evolve` after accepting for ECB and coverage
-     gap suggestions."*
+   If it finds folder loops or oversized files, close with:
+   *"Once you accept, want me to look at the folder loop between
+   `<a>` and `<b>`? The cheapest cut is `<file imports "specifier">`."*
+   If it finds none, skip this line.
 
-   Do NOT author actors or use cases here — that requires the
-   structural diagram to be accepted first and is a separate ask
-   from the user. This note is a prompt, not an action.
+   Do NOT fix smells here — spawn is descriptive, and the fix is a
+   separate ask from the user. This note is a prompt, not an action.
 
 ## Notes
 

package/commands/suggest.md

@@ -37,10 +37,6 @@ start Build phase here; that's gated on accept.
 0. **Frame + clarify (entering DESIGN).** Before any CLI call, restate
    the user's intent in one sentence and list 1–3 sharp clarifying
    questions if any of these are ambiguous in `$ARGUMENTS`:
-   - **Actor + use case** — which actor initiates this? Does an
-     existing use case cover it, or is this a new user-visible
-     behaviour? (Check `npx archik q actors` and `q usecases` in
-     step 2 before asking if the answer isn't obvious from the brief.)
    - **Boundary** — which existing context owns this, or is it a new
      one? (data ownership = bounded context)
    - **Sync vs async** — request/response (`http_call`) or
@@ -57,15 +53,6 @@ start Build phase here; that's gated on accept.
    don't ask questions for the sake of asking.** When in doubt, ask
    the user "you decide?" so they can defer back if they want.
 
-   **Before the structural sidecar, check if the feature needs
-   requirements artifacts first:**
-   - New human-facing flow or actor? Create/update
-     `*.archik.actors.yaml` (direct-write) before staging the sidecar.
-   - New user-visible behaviour? Author a `*.archik.uc.yaml` under
-     `.archik/usecases/` (direct-write) with the flow and at least one
-     slice before staging the sidecar. The structural model references
-     what the use case requires.
-
 1. **Make sure the canvas is running** so the user can review:
    ```
    npx archik status
@@ -85,23 +72,6 @@ start Build phase here; that's gated on accept.
    If `$ARGUMENTS` mentions a specific node by name, also run
    `npx archik q describe <id>` for it.
 
-   If the change is **non-trivial** (new actor, new user-visible
-   behaviour, boundary impact, more than one node affected) also
-   ground in the requirements model:
-   ```
-   npx archik q actors
-   npx archik q usecases
-   ```
-   If any use case looks related, run
-   `npx archik q describe-usecase <id>` to see its slices and
-   check whether the proposed change extends, modifies, or
-   introduces a UC — that determines whether you need to update
-   a `*.archik.uc.yaml` before staging the structural sidecar.
-
-   If step 0 already determined the change is trivially small
-   (one node, one edge, no boundary or UC impact), skip the
-   actor/UC queries and go straight to step 3.
-
 3. **Lock in the schema.** Run this before drafting any YAML —
    the prose in this file describes the workflow, not the field
    shapes. The CLI is the schema:
@@ -135,18 +105,6 @@ start Build phase here; that's gated on accept.
    not just its kind or name. Empty / missing descriptions are
    rejected by the validator.
 
-   **For nodes that participate in a use case flow**, add a
-   `stereotype` field to classify their role in the ECB model:
-   - `stereotype: boundary` — accepts requests from actors / external
-     systems (adapters, gateways, API handlers)
-   - `stereotype: control` — orchestrates the use case logic (services,
-     use-case handlers, orchestrators)
-   - `stereotype: entity` — stores or represents domain data (repos,
-     domain models, DB-backed modules)
-
-   The validator enforces ECB transition rules on seq diagrams that
-   carry a `realizes` block — tag the nodes now so the rules can fire.
-
    ```bash
    npx archik suggest set --note "$ARGUMENTS" - <<'YAML'
    version: "1.0"