@archme/cli 0.11.0 → 0.11.1

package/dist/cli.js

@@ -13157,7 +13157,7 @@ function buildStoryCoverageGate(opts) {
 function buildFormatRefStories(opts) {
   const draftBlock = opts.persistentDrafts ? FORMAT_REF_DRAFT_STORIES_BLOCK : "";
   const uncoveredSubFlowRule = opts.persistentDrafts ? CROSS_REF_UNCOVERED_DRAFT_STUB : CROSS_REF_UNCOVERED_REAL_STORY;
-  const hierarchyExample = opts.persistentDrafts ? `- Example: storyUpdates: [{add: [{id: "auth", title: "Authentication", description: "User auth flows", draft: true, userStories: [{id: "login", title: "log in with email", draft: true, acceptanceCriteria: ["< 1s response"]}]}]}]` : `- Example: storyUpdates: [{add: [{id: "auth", title: "Authentication", description: "User auth flows", userStories: [{id: "login", title: "log in with email", acceptanceCriteria: ["< 1s response"], sequence: "sequenceDiagram\\n    ..."}]}]}]`;
+  const hierarchyExample = opts.persistentDrafts ? `- Example: storyUpdates: [{add: [{id: "auth", title: "Authentication", description: "User auth flows", draft: true, userStories: [{id: "login", title: "log in with email", draft: true}]}]}]` : `- Example: storyUpdates: [{add: [{id: "auth", title: "Authentication", description: "User auth flows", userStories: [{id: "login", title: "log in with email", sequence: "sequenceDiagram\\n    ..."}]}]}]`;
   return `Recursive story hierarchy:
 - Stories can contain child stories via userStories: [...] \u2014 parent stories act as feature groups
 - Use top-level stories with description, links, and nested children to organize by feature area
@@ -13174,11 +13174,6 @@ Story description format (markdown, 1-4 sentences \u2014 render target is a narr
 - Good: "A signed-out user requests a reset link by email and sets a new password from that link. Links expire after an hour and work once."
 - Bad (3x too long, implementation-level, changelog-style): "The forgot-password handler generates a token via crypto.randomUUID(), inserts a row into password_reset_tokens with expires_at = now() + 1 hour, emails it through the SendGrid client, and the reset endpoint validates the token with FOR UPDATE SKIP LOCKED before calling auth.admin.updateUserById..."
 
-Acceptance criteria format:
-- Each criterion should be an observable guarantee or behavior someone could verify without reading the code.
-- Bad: "RLS policy checks auth.uid() against org_members", "Uses FOR UPDATE SKIP LOCKED in claim query"
-- Good: "Only org members can view jobs", "Concurrent workers never claim the same job"
-
 ${draftBlock}Sequence diagram format:
 - Each story has a "sequence" field containing a Mermaid sequence diagram string
 - Use architecture dot-paths as participant IDs (e.g., root.api.gateway)
@@ -13352,14 +13347,13 @@ Connection format:
     FORMAT_REF_DRAFT_STORIES_BLOCK = `Draft stories:
 - Set draft: true for stories where the architecture isn't built yet
 - Draft inheritance: if a parent has draft: true, all descendants are implicitly draft (skip validation)
-- Draft stories can omit sequence entirely \u2014 they're pure requirements
+- Draft stories can omit sequence entirely \u2014 a title and description are enough
 - Draft stories skip all validation (waypoints, connectivity)
-- Use acceptanceCriteria: string[] for PRD-style requirements on draft stories
 - When architecture supports the story, add a sequence and set draft: false
-- Example draft: {id: "send_push", title: "Send push notification", draft: true, acceptanceCriteria: ["Delivered within 5s", "Supports iOS and Android"]}
+- Example draft: {id: "send_push", title: "Send push notification", draft: true, description: "A user gets a push notification on iOS or Android within seconds of the event."}
 
 `;
-    CROSS_REF_UNCOVERED_DRAFT_STUB = `- If no existing story covers the sub-flow but it is reusable across multiple parent stories, create a draft story for it (acceptanceCriteria only, no sequence) and reference that draft. The draft can be wired up later.`;
+    CROSS_REF_UNCOVERED_DRAFT_STUB = `- If no existing story covers the sub-flow but it is reusable across multiple parent stories, create a draft story for it (title and description only, no sequence) and reference that draft. The draft can be wired up later.`;
     CROSS_REF_UNCOVERED_REAL_STORY = `- If no existing story covers the sub-flow but it is reusable across multiple parent stories, create a real story for it \u2014 with its own sequence traced from the code \u2014 and reference that. Do not leave a sequence-less draft stub.`;
     FORMAT_REF_STORIES = buildFormatRefStories({ persistentDrafts: true });
   }
@@ -13625,6 +13619,8 @@ var init_validationCodes = __esm({
       STORY_MISSING_SEQUENCE_FOR_LEAF: "story.add.missing-sequence-for-leaf",
       /** Parent story id referenced by `under` was not found. */
       STORY_UNDER_PARENT_NOT_FOUND: "story.add.under-parent-not-found",
+      /** An MCP write set `acceptanceCriteria`, which only people author. */
+      STORY_ACCEPTANCE_CRITERIA_AGENT_WRITE: "story.add.acceptance-criteria-agent-write",
       // ──────────────────────────────────────────────────────────────────────────
       // story.remove
       // ──────────────────────────────────────────────────────────────────────────
@@ -19549,6 +19545,9 @@ Rules:
 ## Data Shape (schemas)
 A data-shape change with unchanged topology is still an architectural change \u2014 the same components can talk in the same order while the shape of the data on the wire changes. If this change adds, removes, or retypes a **DB column**, a **function/RPC parameter**, or a **response/return field**, update the \`schema\` of the affected storage component (table, RPC, queue, any persistence layer) and the **input/output interface children** the data flows through. Compact format: \`{ field: type, field?: type, field!: generated, arr: type[], ... }\`. For a **persisted table**, set \`schemaKind: "table"\` + \`schemaName\` on the component and tag key columns inline (\`id: uuid @pk\`, \`user_id?: uuid @fk(auth.users.id)\`); keep DDL, RLS policies, and indexes OUT of \`schema\` \u2014 those are code (the anchored migration). Match the code exactly \u2014 do NOT invent fields the code doesn't have; a \`schema\` more complete than the code can prove is over-claiming.
 
+## Behaviour at a step
+A behaviour change with unchanged participants is still an architectural change: the same components talk in the same order, but what a step does or guarantees has changed (the caller's real IP now reaches the backend, a failed call is now retried, a limit is now enforced). Show it in the \`sequence\` of the story that draws that step \u2014 reword that arrow, or add a short Note at that step when no arrow can carry it (see Sequence wording). A component \`description\` edit on its own barely shows in review, so it does not stand in for the sequence edit.
+
 ## Draft Story Guidance
 \`draft: true\` is a transient build mechanic, not a deliverable: it skips sequence validation while a story is being assembled, and a parent's draft flag propagates to all descendants (suppressing \`autoCreateConnectionsFromStories\`). Feature-group parent stories that have real, sequenced children are NOT drafts. You may set it mid-run to defer validation while assembling a story, but finish the run with zero drafts you created or touched: give each a real sequence and set \`draft: false\`, or remove it. Pre-existing drafts you didn't touch are not yours to sweep.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@archme/cli",
-  "version": "0.11.0",
+  "version": "0.11.1",
   "description": "Map your codebase into a living architecture diagram: run `archme init` in a repo to scan it, `archme daemon start` to keep it current on every commit.",
   "type": "module",
   "license": "SEE LICENSE IN LICENSE",