trybeacon 0.1.61 → 0.1.63

package/dist/lib/codex-install.js

@@ -51,9 +51,17 @@ A single \`beacon_init_persist\` MCP tool call with:
 - Don't fabricate tables/endpoints. If you can't find the schema source, omit \`snapshot\`.
 - Don't ask the user to confirm before persisting. The user invoked /beacon-init \u2014 that's the confirmation.
 
-If \`beacon_init_persist\` isn't available, the Beacon panel isn't running in this repo. Tell the user to run \`beacon\` here first, then re-invoke /beacon-init.
+## If \`beacon_init_persist\` is NOT in your tools (or the call can't reach the daemon)
 
-After the tool returns, tell the user the counts (components / roadmap / tables / endpoints) and point them at the running Beacon panel.
+That happens when this repo was never opened with \`beacon\`: there's no \`.mcp.json\`, so the Beacon MCP server isn't in this session \u2014 and MCP tools can't be added mid-session. (It also covers a wired repo whose daemon is down, so the tool call errors.) **Do NOT stop and tell the user to run \`beacon\` first.** /beacon-init bootstraps itself: write the EXACT analysis object you'd have passed to \`beacon_init_persist\` to a temp JSON file, then persist it through the CLI:
+
+\`\`\`bash
+beacon init-persist /tmp/beacon-init.json   # or: beacon init-persist < /tmp/beacon-init.json
+\`\`\`
+
+That one command wires the repo (writes \`.mcp.json\` + skills so your NEXT session gets the \`beacon_*\` tools natively, heals the global install), starts the Beacon daemon if it isn't running, registers + provisions this workspace, and POSTs your analysis to the same \`/api/init\` endpoint the MCP tool uses \u2014 so init completes in THIS session. Read the counts it prints and report them.
+
+After the tool (or \`beacon init-persist\`) returns, tell the user the counts (components / roadmap / tables / endpoints) and point them at the running Beacon panel.
 `,L=`---
 name: beacon-refresh
 description: Re-survey the repo and update Beacon's architecture / schema / endpoints map after /beacon-init was already run \u2014 picks up new components, removed ones, schema changes, and new routes. Use when the user runs /beacon-refresh or asks to "refresh", "update", "re-sync", or "bring Beacon up to date" with the current code.
@@ -179,14 +187,14 @@ When the workspace HAS A FRONTEND (Beacon knows \u2014 the agent set \`hasFronte
 ### Adding a card directly \u2014 \`beacon_feature\` (no review gate)
 
 To put a card on the board WITHOUT the plan-review flow, call \`beacon_feature\` \u2014 ONE tool for a feature's whole lifecycle:
-- \`{ action: "add" }\` creates a card in a SINGLE call. It defaults to \`status: "backlog"\` (a PENDING item you're NOT working on yet); pass \`status: "active"\` to start it IN_PROGRESS now. A title that matches an existing card returns \`exists\` (reuse it) \u2014 \`add\` never activates or demotes a card already on the board.
+- \`{ action: "add" }\` creates a card in a SINGLE call. It defaults to \`status: "backlog"\` (a PENDING item you're NOT working on yet); pass \`status: "active"\` to start it IN_PROGRESS now. A title that matches an existing card in the SAME category + layer returns \`exists\` (reuse it) \u2014 the same title in a DIFFERENT category or layer (FE/BE/FS) creates a distinct card; \`add\` never activates or demotes a card already on the board.
 - \`{ action: "start" }\` marks an existing card IN_PROGRESS (create-or-flag).
 - \`{ action: "subtasks" }\` adds child tasks under a card.
 - \`{ action: "done" }\` completes feature(s) and registers the files/architecture touched.
 
 A NEW card REQUIRES \`category\` + \`priority\` (and \`layer\` where the workspace has a frontend). Use \`beacon_propose_plan\` / \`beacon_present_plan\` only when you want the user to REVIEW before the card lands.
 
-REUSE before you create. Call \`beacon_map\` FIRST \u2014 it lists every card with its \`category\`, \`priority\`, \`layer\` and \`status\`, so you reuse an existing category (don't invent a near-synonym) and spot duplicates WITHOUT calling \`beacon_entities\`. Beacon HARD-BLOCKS a feature that duplicates an existing one (it returns the existing feature to use instead) and one created without a category. \`category\` is the ONLY domain field. \`front\` (in \`beacon_feature\`) nests a card UNDER an existing parent feature \u2014 it is NOT a domain tag; a \`front\` that matches no real feature is rejected.
+REUSE before you create. Call \`beacon_map\` FIRST \u2014 it lists every card with its \`category\`, \`priority\`, \`layer\` and \`status\`, so you reuse an existing category (don't invent a near-synonym) and spot duplicates WITHOUT calling \`beacon_entities\`. Beacon blocks only an EXACT duplicate \u2014 same title AND category AND layer \u2014 plus a card created without a category; a same-named card in a DIFFERENT category, or on a different layer (frontend/backend/fullstack), is allowed as its own card. \`category\` is the ONLY domain field. \`front\` (in \`beacon_feature\`) nests a card UNDER an existing parent feature \u2014 it is NOT a domain tag; a \`front\` that matches no real feature is rejected.
 
 When listing features, give each \`dependsOn: ["Other feature title", \u2026]\` for any feature that must ship after another in the same plan. Beacon draws these as "depends on" links so the roadmap shows the dependency chain instead of loose, disconnected cards.
 

package/dist/lib/global-install.js

@@ -51,9 +51,17 @@ A single \`beacon_init_persist\` MCP tool call with:
 - Don't fabricate tables/endpoints. If you can't find the schema source, omit \`snapshot\`.
 - Don't ask the user to confirm before persisting. The user invoked /beacon-init \u2014 that's the confirmation.
 
-If \`beacon_init_persist\` isn't available, the Beacon panel isn't running in this repo. Tell the user to run \`beacon\` here first, then re-invoke /beacon-init.
+## If \`beacon_init_persist\` is NOT in your tools (or the call can't reach the daemon)
 
-After the tool returns, tell the user the counts (components / roadmap / tables / endpoints) and point them at the running Beacon panel.
+That happens when this repo was never opened with \`beacon\`: there's no \`.mcp.json\`, so the Beacon MCP server isn't in this session \u2014 and MCP tools can't be added mid-session. (It also covers a wired repo whose daemon is down, so the tool call errors.) **Do NOT stop and tell the user to run \`beacon\` first.** /beacon-init bootstraps itself: write the EXACT analysis object you'd have passed to \`beacon_init_persist\` to a temp JSON file, then persist it through the CLI:
+
+\`\`\`bash
+beacon init-persist /tmp/beacon-init.json   # or: beacon init-persist < /tmp/beacon-init.json
+\`\`\`
+
+That one command wires the repo (writes \`.mcp.json\` + skills so your NEXT session gets the \`beacon_*\` tools natively, heals the global install), starts the Beacon daemon if it isn't running, registers + provisions this workspace, and POSTs your analysis to the same \`/api/init\` endpoint the MCP tool uses \u2014 so init completes in THIS session. Read the counts it prints and report them.
+
+After the tool (or \`beacon init-persist\`) returns, tell the user the counts (components / roadmap / tables / endpoints) and point them at the running Beacon panel.
 `,n=`---
 name: beacon-refresh
 description: Re-survey the repo and update Beacon's architecture / schema / endpoints map after /beacon-init was already run \u2014 picks up new components, removed ones, schema changes, and new routes. Use when the user runs /beacon-refresh or asks to "refresh", "update", "re-sync", or "bring Beacon up to date" with the current code.
@@ -179,14 +187,14 @@ When the workspace HAS A FRONTEND (Beacon knows \u2014 the agent set \`hasFronte
 ### Adding a card directly \u2014 \`beacon_feature\` (no review gate)
 
 To put a card on the board WITHOUT the plan-review flow, call \`beacon_feature\` \u2014 ONE tool for a feature's whole lifecycle:
-- \`{ action: "add" }\` creates a card in a SINGLE call. It defaults to \`status: "backlog"\` (a PENDING item you're NOT working on yet); pass \`status: "active"\` to start it IN_PROGRESS now. A title that matches an existing card returns \`exists\` (reuse it) \u2014 \`add\` never activates or demotes a card already on the board.
+- \`{ action: "add" }\` creates a card in a SINGLE call. It defaults to \`status: "backlog"\` (a PENDING item you're NOT working on yet); pass \`status: "active"\` to start it IN_PROGRESS now. A title that matches an existing card in the SAME category + layer returns \`exists\` (reuse it) \u2014 the same title in a DIFFERENT category or layer (FE/BE/FS) creates a distinct card; \`add\` never activates or demotes a card already on the board.
 - \`{ action: "start" }\` marks an existing card IN_PROGRESS (create-or-flag).
 - \`{ action: "subtasks" }\` adds child tasks under a card.
 - \`{ action: "done" }\` completes feature(s) and registers the files/architecture touched.
 
 A NEW card REQUIRES \`category\` + \`priority\` (and \`layer\` where the workspace has a frontend). Use \`beacon_propose_plan\` / \`beacon_present_plan\` only when you want the user to REVIEW before the card lands.
 
-REUSE before you create. Call \`beacon_map\` FIRST \u2014 it lists every card with its \`category\`, \`priority\`, \`layer\` and \`status\`, so you reuse an existing category (don't invent a near-synonym) and spot duplicates WITHOUT calling \`beacon_entities\`. Beacon HARD-BLOCKS a feature that duplicates an existing one (it returns the existing feature to use instead) and one created without a category. \`category\` is the ONLY domain field. \`front\` (in \`beacon_feature\`) nests a card UNDER an existing parent feature \u2014 it is NOT a domain tag; a \`front\` that matches no real feature is rejected.
+REUSE before you create. Call \`beacon_map\` FIRST \u2014 it lists every card with its \`category\`, \`priority\`, \`layer\` and \`status\`, so you reuse an existing category (don't invent a near-synonym) and spot duplicates WITHOUT calling \`beacon_entities\`. Beacon blocks only an EXACT duplicate \u2014 same title AND category AND layer \u2014 plus a card created without a category; a same-named card in a DIFFERENT category, or on a different layer (frontend/backend/fullstack), is allowed as its own card. \`category\` is the ONLY domain field. \`front\` (in \`beacon_feature\`) nests a card UNDER an existing parent feature \u2014 it is NOT a domain tag; a \`front\` that matches no real feature is rejected.
 
 When listing features, give each \`dependsOn: ["Other feature title", \u2026]\` for any feature that must ship after another in the same plan. Beacon draws these as "depends on" links so the roadmap shows the dependency chain instead of loose, disconnected cards.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "trybeacon",
-  "version": "0.1.61",
+  "version": "0.1.63",
   "description": "The visual planning surface for the coding agent in your terminal.",
   "homepage": "https://trybeacon.sh",
   "bin": {