@anthropologies/claudestory 0.1.47 → 0.1.49

package/dist/cli.js

@@ -8358,7 +8358,7 @@ function getInstalledVersion() {
   }
 }
 function getRunningVersion() {
-  return "0.1.47";
+  return "0.1.49";
 }
 var init_version_check = __esm({
   "src/autonomous/version-check.ts"() {
@@ -10923,7 +10923,7 @@ var init_mcp = __esm({
     init_init();
     ENV_VAR2 = "CLAUDESTORY_PROJECT_ROOT";
     CONFIG_PATH2 = ".story/config.json";
-    version = "0.1.47";
+    version = "0.1.49";
     main().catch((err) => {
       process.stderr.write(`Fatal: ${err instanceof Error ? err.message : String(err)}
 `);
@@ -14354,7 +14354,7 @@ async function runCli() {
     registerSessionCommand: registerSessionCommand2,
     registerRepairCommand: registerRepairCommand2
   } = await Promise.resolve().then(() => (init_register(), register_exports));
-  const version2 = "0.1.47";
+  const version2 = "0.1.49";
   class HandledError extends Error {
     constructor() {
       super("HANDLED_ERROR");

package/dist/mcp.js

@@ -7816,7 +7816,7 @@ function getInstalledVersion() {
   }
 }
 function getRunningVersion() {
-  return "0.1.47";
+  return "0.1.49";
 }
 
 // src/autonomous/guide.ts
@@ -10055,7 +10055,7 @@ async function ensureGitignoreEntries(gitignorePath, entries) {
 // src/mcp/index.ts
 var ENV_VAR2 = "CLAUDESTORY_PROJECT_ROOT";
 var CONFIG_PATH2 = ".story/config.json";
-var version = "0.1.47";
+var version = "0.1.49";
 function tryDiscoverRoot() {
   const envRoot = process.env[ENV_VAR2];
   if (envRoot) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@anthropologies/claudestory",
-  "version": "0.1.47",
+  "version": "0.1.49",
   "license": "UNLICENSED",
   "description": "Cross-session context persistence for AI coding projects. Tracks tickets, issues, roadmap, and handovers so every session builds on the last.",
   "keywords": [

package/src/skill/setup-flow.md

@@ -167,9 +167,7 @@ Show: "So far: [name] is a [surface] + [traits] built with [stack]."
   - "No, start from scratch" -- generate design foundation tickets (color palette, typography, layout, component selection)
   - "Not sure yet"
 
-If NOT "Yes, mockups / Figma" and project has a UI surface, follow up with component library choice:
-- `AskUserQuestion`: "Component library?"
-- options: shadcn/ui (Recommended for Next.js), Material UI, Chakra UI, None/custom
+Component library is inferred from the stack, not asked as a separate gate. Next.js defaults to shadcn/ui, Flutter to Material, React Native to NativeBase/Paper. Only ask if the stack doesn't have a clear default or the user picked "No, start from scratch" (where the component system is part of the design foundation tickets).
 
 **--- Cluster 3: System structure ---**
 
@@ -182,7 +180,7 @@ If NOT "Yes, mockups / Figma" and project has a UI surface, follow up with compo
   - "Frontend + managed backend (Supabase/Firebase)" -- BaaS handles DB, auth, storage. You build the frontend. Fastest path to MVP.
   - "Not sure -- recommend one"
 
-BaaS as a first-class path. If selected: skip ORM choice (BaaS handles it), skip auth gate (BaaS handles it), adjust deployment to match (Vercel + Supabase, or Firebase Hosting + Firebase). Generates different tickets: BaaS setup, client SDK integration, security rules, instead of custom API + auth tickets.
+BaaS as a first-class path. If selected: skip ORM choice (BaaS handles it), adjust deployment to match (Vercel + Supabase, or Firebase Hosting + Firebase). Auth gate still fires -- the user still decides what kind of auth (no auth, individual, team/org), but tickets generated are BaaS-specific (Supabase RLS policies, Firebase Security Rules) instead of custom middleware. Generates different tickets: BaaS setup, client SDK integration, security rules, instead of custom API + auth tickets.
 
 **BaaS + AI edge case:** If the user also selected "AI / LLM powered" as a characteristic, AI gates still fire normally. For document ownership tickets (RAG + auth), reference "Supabase RLS policies" or "Firebase Security Rules" instead of "custom row-level access." The AI cluster's data model tickets adapt to the BaaS context.
 
@@ -246,7 +244,7 @@ Multi-select because these are orthogonal: a system can have both workflows AND
 
 When recommending auth setup for individual accounts, suggest Firebase Auth or Clerk as the easiest options. These handle email/password, social login, session management, and JWT with minimal code. Only recommend custom auth when the user has specific requirements.
 
-**Step 4f:** Sensitive domain (skip unless project description or characteristics suggest health, legal, finance, compliance, government, or regulated industry). This is the canonical sensitive domain gate for ALL projects. The AI safety cluster (Cluster 5) references this answer instead of re-asking. Use `AskUserQuestion`:
+**Step 4f:** Sensitive domain. This is the canonical sensitive domain gate for ALL projects. The AI safety cluster (Cluster 5) references this answer instead of re-asking. Bias toward asking -- skip only for projects that are clearly non-sensitive (portfolio, blog, dev tool, game). Ask for anything with user data, business transactions, or professional use cases. Use `AskUserQuestion`:
 - question: "Is this in a sensitive/regulated domain?"
 - header: "Domain"
 - options:
@@ -358,67 +356,70 @@ Before asking for approval, briefly explain what they're looking at:
 
 "**How this works:** Phases are milestones in your project's development. They track progress from setup to shipping. Tickets are specific work items within each phase. After setup, typing `/story` at the start of any Claude Code session loads this context automatically. Claude will know your project's state, what was done last session, and what to work on next."
 
-Then use `AskUserQuestion` for approval:
-- question: "How does this proposal look?"
-- header: "Proposal"
+Then use ONE `AskUserQuestion` that combines approval and refinement depth (do not ask two separate questions):
+- question: "How should I proceed with this proposal?"
+- header: "Proceed"
 - options:
-  - "Looks good" -- approve and continue
-  - "Adjust phases" -- iterate on phase structure
-  - "Adjust tickets" -- iterate on ticket details
-  - "Start over" -- re-analyze from scratch
+  - "Refine + get a second opinion (Recommended)" -- I'll add descriptions, dependencies, and sizing, then have an independent reviewer check my work before creating anything
+  - "Refine tickets" -- I'll add descriptions, figure out dependencies, and flag oversized tickets
+  - "Create as-is" -- create tickets now as shown
+  - "Adjust first" -- I want to change phases or tickets before proceeding
+- (Other always available for free-text feedback)
 
-Re-show this `AskUserQuestion` after adjustments. Loop until "Looks good."
+If "Adjust first": ask what they want to change, iterate, then re-show this same AskUserQuestion. Loop until they pick a create/refine option.
 
-#### 1d2. Refinement and Review
+If "Create as-is" and no brief exists: warn "Note: tickets will have titles only -- you can add descriptions later." Then proceed to **1e. Execute on Approval**.
 
-After the user approves the proposal structure, use `AskUserQuestion` for refinement depth:
-- question: "Want me to refine these before creating?"
-- header: "Depth"
-- options:
-  - "Yes, refine + get a second opinion (Recommended)" -- I'll refine, then have an independent reviewer check my work
-  - "Yes, refine them" -- I'll add descriptions, figure out dependencies, and flag oversized tickets
-  - "Create as-is" -- create tickets now with just titles
-
-If "Create as-is" and no brief exists: warn "Note: tickets will have titles only -- you can add descriptions later."
-
-**If "Refine tickets" or "Refine + review":**
-
-Refine the proposal. If a brief/PRD was found in step 1b, use those structured notes. If no brief exists (e.g., the user came through step 1c interview), infer descriptions from the interview answers and propose standard dependencies based on the tech stack.
+#### 1d2. Refinement and Review (internal -- user does not see intermediate steps)
 
-**Descriptions:** Extract specs from the brief into ticket descriptions -- entity fields, acceptance criteria, API contracts, business rules. If no brief, write descriptions based on the user's interview answers and common patterns for the chosen stack. Cap each description at 3-4 sentences. Keep them actionable, not exhaustive. The goal is "enough to implement without re-reading the brief."
+**This section runs silently.** The user already chose their depth. Do the work, then present the final result ONCE.
 
-**Dependencies:** Infer `blockedBy` relationships from phase ordering and domain logic:
-- Schema/migration tickets block CRUD API tickets
-- Auth tickets block protected route tickets
-- CRUD/model tickets block business logic that depends on them
-- API tickets block UI tickets that consume them
+If a brief/PRD was found in step 1b, use those structured notes. If no brief exists (e.g., the user came through step 1c interview), infer descriptions from the interview answers and propose standard dependencies based on the tech stack.
 
-**Sizing check:** Flag tickets that cover more than one major concern:
-- Mentions 3+ distinct entities in one ticket
-- Covers both API implementation and UI in one ticket
-- Handles 3+ distinct models, modes, or billing types in one ticket
-- Offer to split flagged tickets into sub-tasks
+**What refinement does (internally):**
+- Extract specs from the brief into ticket descriptions (3-4 sentences each, actionable)
+- Infer `blockedBy` from phase ordering and domain logic (schema before CRUD, auth before protected routes, CRUD before business logic, API before UI)
+- Flag and split oversized tickets (3+ entities, API+UI in one ticket, 3+ models)
+- Cross-reference brief entities against tickets, add missing ones
+- Detect core differentiator -- decompose if single ticket
+- Surface undecided tech choices
 
-**Missing entity detection:** Cross-reference entities and concepts mentioned in the brief against the proposed ticket list. Flag entities that appear in the brief but have no corresponding ticket. Common misses: user profile/settings, notification system, seed data, admin/config screens.
+**If "Refine + review":** After refinement, also run an independent review:
+- If `review_plan` MCP tool is available, use it. Otherwise spawn an independent Claude agent. If neither available, skip with a note.
+- Maximum 2 review rounds.
+- Incorporate all findings into the proposal. The user sees the final result, not the review process.
 
-**Core differentiator detection:** Identify the ticket(s) covering what the brief emphasizes most (the main value proposition). If the core differentiator is a single ticket, flag it for decomposition -- it likely needs 3-4 sub-tickets.
+**Present the final result ONCE.** Do NOT show every ticket with its description. Show a compact summary of what changed:
 
-**Undecided tech choices:** Surface technology decisions mentioned in the brief as "X or Y" that haven't been resolved. Present them as explicit decisions to make before implementation starts (e.g., "ORM: Drizzle or Prisma -- decide before T-002").
-
-After refinement, present the updated proposal showing what changed: added descriptions, new blockedBy links, split tickets, newly created tickets for missing entities, and flagged decisions. Wait for the user to approve the refined proposal before continuing.
+```
+Refinement complete. Here's what changed:
 
-**If "Refine + review":**
+- Added descriptions to 14 tickets
+- Added 8 dependency links (blockedBy chains)
+- No tickets flagged for splitting (all well-scoped)
+- [If review ran] Independent review: 2 suggestions incorporated
+  - T-005 split into T-005a/T-005b (was too broad)
+  - T-012 added blockedBy T-006 (missing dependency)
 
-After refinement, run an independent review of the full proposal (phases, tickets, descriptions, dependencies):
+Updated proposal:
 
-**Backend selection:** Use the same review backend selection as autonomous mode -- if the `review_plan` MCP tool is available, use it (pass the full proposal as the plan document); otherwise spawn an independent Claude agent with the brief + proposal and ask it to audit for gaps, sizing issues, missing dependencies, and architectural concerns. If neither is available, skip review with a note.
+[Show the same phase + ticket table as before, but now with a "Deps" column]
 
-**Review cap:** Maximum 2 review rounds for setup proposals.
+| Ticket | Title                    | Phase      | Deps      |
+|--------|--------------------------|------------|-----------|
+| T-001  | Project setup            | foundation | --        |
+| T-002  | Database schema design   | foundation | T-001     |
+| T-006  | Auth setup               | foundation | T-001     |
+| ...    | ...                      | ...        | ...       |
+```
 
-**After review findings come back:**
-- Present ALL findings to the user as a summary diff: added tickets, changed descriptions, new dependencies, files to be generated.
-- User approves the final version before any execution. Do not auto-incorporate findings.
-- If the user requests changes based on findings, update the proposal and optionally re-review.
+Then use `AskUserQuestion`:
+- question: "Ready to create?"
+- header: "Create"
+- options:
+  - "Create everything (Recommended)"
+  - "Let me adjust first" -- iterate, then re-ask
+  - "Show me the full details" -- expand all ticket descriptions (for users who want to inspect)
 
 #### 1e. Execute on Approval