trybeacon 0.1.49 → 0.1.50

package/.next/trace-build

@@ -1 +1 @@
-[{"name":"run-webpack","duration":28440334,"timestamp":173139511,"id":14,"parentId":1,"tags":{},"startTime":1781573958524,"traceId":"63ef3eb53f233cfc"},{"name":"run-typescript","duration":12434254,"timestamp":201582356,"id":4126,"parentId":1,"tags":{},"startTime":1781573986967,"traceId":"63ef3eb53f233cfc"},{"name":"static-check","duration":713209,"timestamp":214103113,"id":4129,"parentId":1,"tags":{},"startTime":1781573999488,"traceId":"63ef3eb53f233cfc"},{"name":"static-generation","duration":4631988,"timestamp":215436526,"id":4283,"parentId":1,"tags":{},"startTime":1781574000822,"traceId":"63ef3eb53f233cfc"},{"name":"collect-build-traces","duration":13341573,"timestamp":214819506,"id":4280,"parentId":1,"tags":{},"startTime":1781574000204,"traceId":"63ef3eb53f233cfc"},{"name":"telemetry-flush","duration":60,"timestamp":228164787,"id":4292,"parentId":1,"tags":{},"startTime":1781574013550,"traceId":"63ef3eb53f233cfc"},{"name":"next-build","duration":55402341,"timestamp":172762516,"id":1,"tags":{"buildMode":"default","version":"16.2.7","bundler":"webpack","has-custom-webpack-config":"false","use-build-worker":"true"},"startTime":1781573958147,"traceId":"63ef3eb53f233cfc"}]
+[{"name":"run-webpack","duration":28943484,"timestamp":118901747,"id":14,"parentId":1,"tags":{},"startTime":1781631967154,"traceId":"6259803428af983d"},{"name":"run-typescript","duration":12690485,"timestamp":147847841,"id":4126,"parentId":1,"tags":{},"startTime":1781631996101,"traceId":"6259803428af983d"},{"name":"static-check","duration":667088,"timestamp":160586710,"id":4129,"parentId":1,"tags":{},"startTime":1781632008839,"traceId":"6259803428af983d"},{"name":"static-generation","duration":4218534,"timestamp":161797331,"id":4283,"parentId":1,"tags":{},"startTime":1781632010050,"traceId":"6259803428af983d"},{"name":"collect-build-traces","duration":11837205,"timestamp":161256828,"id":4280,"parentId":1,"tags":{},"startTime":1781632009510,"traceId":"6259803428af983d"},{"name":"telemetry-flush","duration":58,"timestamp":173097636,"id":4292,"parentId":1,"tags":{},"startTime":1781632021350,"traceId":"6259803428af983d"},{"name":"next-build","duration":54308800,"timestamp":118788903,"id":1,"tags":{"buildMode":"default","version":"16.2.7","bundler":"webpack","has-custom-webpack-config":"false","use-build-worker":"true"},"startTime":1781631967042,"traceId":"6259803428af983d"}]

package/dist/bin/doctor.js

@@ -71,7 +71,7 @@ Beacon was already initialized in this repo (\`/beacon-init\` ran at some point)
 
 ## What gets preserved vs replaced
 
-The \`beacon_init_persist\` tool **replaces only init-derived nodes** (\`source=INIT\`). A curated architecture node (created by \`beacon_describe_feature\` or by hand) whose title matches a component in your refreshed analysis is **merged in place** \u2014 your fresh \`domain\`/\`role\`/\`plain\`/\`layer\`/\`files\` land on it, but it keeps its source, position, status, and bug flags, and no duplicate INIT node is created. Curated nodes your analysis does NOT mention survive untouched, as do hand-edited tables, custom positions, notes, and draft feature plans. So you can re-run this freely.
+The \`beacon_init_persist\` tool **replaces only init-derived nodes** (\`source=INIT\`). A curated architecture node (created by \`beacon_feature\` action:done or by hand) whose title matches a component in your refreshed analysis is **merged in place** \u2014 your fresh \`domain\`/\`role\`/\`plain\`/\`layer\`/\`files\` land on it, but it keeps its source, position, status, and bug flags, and no duplicate INIT node is created. Curated nodes your analysis does NOT mention survive untouched, as do hand-edited tables, custom positions, notes, and draft feature plans. So you can re-run this freely.
 
 The one caveat: if the user manually edited an INIT-source node on the canvas (e.g., renamed it, rewrote its role), that edit IS overwritten when you re-persist \u2014 and a renamed node no longer title-matches, so it survives as its own card. If the user mentions hand-curated INIT nodes, ask whether they want those carried into the new analysis verbatim.
 
@@ -175,13 +175,23 @@ When listing endpoints, give each \`uses: [{ table, access }]\` so the endpoint\
 
 EVERY feature MUST carry \`category\` (e.g. AUTH | SEARCH | DATA | INTEL | BILLING | \u2026; \`cluster\` is accepted as an alias) and \`priority\` (0 = P0 critical, 1 = P1 high, 2 = P2 medium, 3 = P3 low). Beacon REJECTS a plan whose features omit either \u2014 \`beacon_propose_plan\` returns the list of what's missing, and an ExitPlanMode \`\`\`beacon block is denied \u2014 so set both on every feature instead of relying on defaults.
 
-When the workspace HAS A FRONTEND (Beacon knows \u2014 the agent set \`hasFrontend\` at init, or frontend files were detected), every feature must ALSO carry \`layer\`: \`"frontend" | "backend" | "fullstack"\` \u2014 which side of the stack the work lands on. Plans omitting it are REJECTED the same way category/priority are. It works on every surface that creates roadmap cards (\`beacon_propose_plan\`, the \`\`\`beacon block, \`beacon_start_feature\`, \`beacon_add_subtasks\` \u2014 sub-tasks default to the parent's layer) and on architecture components (\`beacon_describe_feature\` / \`beacon_init_persist\`). In a pure-backend repo, never set it \u2014 the boards don't show it there.
+When the workspace HAS A FRONTEND (Beacon knows \u2014 the agent set \`hasFrontend\` at init, or frontend files were detected), every feature must ALSO carry \`layer\`: \`"frontend" | "backend" | "fullstack"\` \u2014 which side of the stack the work lands on. Plans omitting it are REJECTED the same way category/priority are. It works on every surface that creates roadmap cards (\`beacon_propose_plan\`, the \`\`\`beacon block, \`beacon_feature\` \u2014 sub-tasks default to the parent's layer) and on architecture components (\`beacon_feature\` action:done / \`beacon_init_persist\`). In a pure-backend repo, never set it \u2014 the boards don't show it there.
 
-REUSE before you create. Call \`beacon_map\` to see the features + categories that already exist. Beacon HARD-BLOCKS a feature that duplicates an existing one (it returns the existing feature to use instead) and one created without a category \u2014 so don't re-create work that's already on the board, and reuse an existing category rather than a near-synonym. \`category\` is the ONLY domain field. \`front\` (in \`beacon_start_feature\`) nests a feature UNDER an existing parent feature \u2014 it is NOT a domain tag; a \`front\` that matches no real feature is rejected.
+### 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: "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.
 
 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.
 
-A roadmap item that is a BUG to fix (not a feature to build) should carry \`kind: "BUG"\` \u2014 it renders as a typed bug card. This works everywhere roadmap cards are created: \`beacon_propose_plan\` features, the \`\`\`beacon block, \`beacon_start_feature\` (when the user says they're starting on a bug), \`beacon_add_subtasks\` items (a bug discovered mid-work), and \`beacon_init_persist\` roadmap items. Default is FEATURE.
+A roadmap item that is a BUG to fix (not a feature to build) should carry \`kind: "BUG"\` \u2014 it renders as a typed bug card. This works everywhere roadmap cards are created: \`beacon_propose_plan\` features, the \`\`\`beacon block, \`beacon_feature\` (add/start when the user is working on a bug; or \`subtasks\` items for a bug discovered mid-work), and \`beacon_init_persist\` roadmap items. Default is FEATURE.
 
 ### 2b. Presenting a plan in plan mode (ExitPlanMode)
 
@@ -199,11 +209,11 @@ Beacon extracts it deterministically and **strips the block from the prose** (it
 
 ### 3. At the end, register the work \u2014 in ONE call
 
-Call \`beacon_describe_feature\` **ONCE** with a \`features\` array \u2014 one entry per feature the plan created \u2014 each with the files you touched and a short markdown description. This flips each one to **Done** \u2014 including its sub-tasks (the cascade completes every PENDING/IN_PROGRESS child; a sub-task you did NOT finish must be set BLOCKED or CANCELLED before registering, so it survives visibly) \u2014 and keeps \`beacon_context_for_feature\` accurate for the next session.
+Call \`beacon_feature({ action: "done" })\` **ONCE** with a \`features\` array \u2014 one entry per feature the plan created \u2014 each with the files you touched and a short markdown description. This flips each one to **Done** \u2014 including its sub-tasks (the cascade completes every PENDING/IN_PROGRESS child; a sub-task you did NOT finish must be set BLOCKED or CANCELLED before registering, so it survives visibly) \u2014 and keeps \`beacon_context_for_feature\` accurate for the next session.
 
 Key each entry by its node \`id\`: the ids are handed back to you when the plan is approved (in the approval message / additionalContext), so you don't fuzzy-match titles or pay a disambiguation round-trip. If you don't have an id, \`title\` still works.
 
-Register them all in that single batched call. If a plan added five features, that's ONE \`beacon_describe_feature\` call with five entries \u2014 NOT five calls, and NOT just an umbrella ("Harden auth"), which leaves the individual features stuck on **Pending**.
+Register them all in that single batched call. If a plan added five features, that's ONE \`beacon_feature({ action: "done" })\` call with five entries \u2014 NOT five calls, and NOT just an umbrella ("Harden auth"), which leaves the individual features stuck on **Pending**.
 
 If the feature added or materially changed a REAL architectural component (a subsystem \u2014 NOT a file), also pass \`architecture: [{ title, domain, role, \u2026 }]\` so the Architecture map stays accurate. It upserts curated components by title; never list files as components. If you found a bug or something worth investigating in a component's code, add \`bugs: [{ note }]\` to its architecture entry \u2014 it renders as a bug flag on the node (attributed to the agent); identical open flags are not duplicated. Only flag what you actually saw in the code.
 

package/dist/bin/hook.js

@@ -71,7 +71,7 @@ Beacon was already initialized in this repo (\`/beacon-init\` ran at some point)
 
 ## What gets preserved vs replaced
 
-The \`beacon_init_persist\` tool **replaces only init-derived nodes** (\`source=INIT\`). A curated architecture node (created by \`beacon_describe_feature\` or by hand) whose title matches a component in your refreshed analysis is **merged in place** \u2014 your fresh \`domain\`/\`role\`/\`plain\`/\`layer\`/\`files\` land on it, but it keeps its source, position, status, and bug flags, and no duplicate INIT node is created. Curated nodes your analysis does NOT mention survive untouched, as do hand-edited tables, custom positions, notes, and draft feature plans. So you can re-run this freely.
+The \`beacon_init_persist\` tool **replaces only init-derived nodes** (\`source=INIT\`). A curated architecture node (created by \`beacon_feature\` action:done or by hand) whose title matches a component in your refreshed analysis is **merged in place** \u2014 your fresh \`domain\`/\`role\`/\`plain\`/\`layer\`/\`files\` land on it, but it keeps its source, position, status, and bug flags, and no duplicate INIT node is created. Curated nodes your analysis does NOT mention survive untouched, as do hand-edited tables, custom positions, notes, and draft feature plans. So you can re-run this freely.
 
 The one caveat: if the user manually edited an INIT-source node on the canvas (e.g., renamed it, rewrote its role), that edit IS overwritten when you re-persist \u2014 and a renamed node no longer title-matches, so it survives as its own card. If the user mentions hand-curated INIT nodes, ask whether they want those carried into the new analysis verbatim.
 
@@ -175,13 +175,23 @@ When listing endpoints, give each \`uses: [{ table, access }]\` so the endpoint\
 
 EVERY feature MUST carry \`category\` (e.g. AUTH | SEARCH | DATA | INTEL | BILLING | \u2026; \`cluster\` is accepted as an alias) and \`priority\` (0 = P0 critical, 1 = P1 high, 2 = P2 medium, 3 = P3 low). Beacon REJECTS a plan whose features omit either \u2014 \`beacon_propose_plan\` returns the list of what's missing, and an ExitPlanMode \`\`\`beacon block is denied \u2014 so set both on every feature instead of relying on defaults.
 
-When the workspace HAS A FRONTEND (Beacon knows \u2014 the agent set \`hasFrontend\` at init, or frontend files were detected), every feature must ALSO carry \`layer\`: \`"frontend" | "backend" | "fullstack"\` \u2014 which side of the stack the work lands on. Plans omitting it are REJECTED the same way category/priority are. It works on every surface that creates roadmap cards (\`beacon_propose_plan\`, the \`\`\`beacon block, \`beacon_start_feature\`, \`beacon_add_subtasks\` \u2014 sub-tasks default to the parent's layer) and on architecture components (\`beacon_describe_feature\` / \`beacon_init_persist\`). In a pure-backend repo, never set it \u2014 the boards don't show it there.
+When the workspace HAS A FRONTEND (Beacon knows \u2014 the agent set \`hasFrontend\` at init, or frontend files were detected), every feature must ALSO carry \`layer\`: \`"frontend" | "backend" | "fullstack"\` \u2014 which side of the stack the work lands on. Plans omitting it are REJECTED the same way category/priority are. It works on every surface that creates roadmap cards (\`beacon_propose_plan\`, the \`\`\`beacon block, \`beacon_feature\` \u2014 sub-tasks default to the parent's layer) and on architecture components (\`beacon_feature\` action:done / \`beacon_init_persist\`). In a pure-backend repo, never set it \u2014 the boards don't show it there.
 
-REUSE before you create. Call \`beacon_map\` to see the features + categories that already exist. Beacon HARD-BLOCKS a feature that duplicates an existing one (it returns the existing feature to use instead) and one created without a category \u2014 so don't re-create work that's already on the board, and reuse an existing category rather than a near-synonym. \`category\` is the ONLY domain field. \`front\` (in \`beacon_start_feature\`) nests a feature UNDER an existing parent feature \u2014 it is NOT a domain tag; a \`front\` that matches no real feature is rejected.
+### 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: "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.
 
 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.
 
-A roadmap item that is a BUG to fix (not a feature to build) should carry \`kind: "BUG"\` \u2014 it renders as a typed bug card. This works everywhere roadmap cards are created: \`beacon_propose_plan\` features, the \`\`\`beacon block, \`beacon_start_feature\` (when the user says they're starting on a bug), \`beacon_add_subtasks\` items (a bug discovered mid-work), and \`beacon_init_persist\` roadmap items. Default is FEATURE.
+A roadmap item that is a BUG to fix (not a feature to build) should carry \`kind: "BUG"\` \u2014 it renders as a typed bug card. This works everywhere roadmap cards are created: \`beacon_propose_plan\` features, the \`\`\`beacon block, \`beacon_feature\` (add/start when the user is working on a bug; or \`subtasks\` items for a bug discovered mid-work), and \`beacon_init_persist\` roadmap items. Default is FEATURE.
 
 ### 2b. Presenting a plan in plan mode (ExitPlanMode)
 
@@ -199,11 +209,11 @@ Beacon extracts it deterministically and **strips the block from the prose** (it
 
 ### 3. At the end, register the work \u2014 in ONE call
 
-Call \`beacon_describe_feature\` **ONCE** with a \`features\` array \u2014 one entry per feature the plan created \u2014 each with the files you touched and a short markdown description. This flips each one to **Done** \u2014 including its sub-tasks (the cascade completes every PENDING/IN_PROGRESS child; a sub-task you did NOT finish must be set BLOCKED or CANCELLED before registering, so it survives visibly) \u2014 and keeps \`beacon_context_for_feature\` accurate for the next session.
+Call \`beacon_feature({ action: "done" })\` **ONCE** with a \`features\` array \u2014 one entry per feature the plan created \u2014 each with the files you touched and a short markdown description. This flips each one to **Done** \u2014 including its sub-tasks (the cascade completes every PENDING/IN_PROGRESS child; a sub-task you did NOT finish must be set BLOCKED or CANCELLED before registering, so it survives visibly) \u2014 and keeps \`beacon_context_for_feature\` accurate for the next session.
 
 Key each entry by its node \`id\`: the ids are handed back to you when the plan is approved (in the approval message / additionalContext), so you don't fuzzy-match titles or pay a disambiguation round-trip. If you don't have an id, \`title\` still works.
 
-Register them all in that single batched call. If a plan added five features, that's ONE \`beacon_describe_feature\` call with five entries \u2014 NOT five calls, and NOT just an umbrella ("Harden auth"), which leaves the individual features stuck on **Pending**.
+Register them all in that single batched call. If a plan added five features, that's ONE \`beacon_feature({ action: "done" })\` call with five entries \u2014 NOT five calls, and NOT just an umbrella ("Harden auth"), which leaves the individual features stuck on **Pending**.
 
 If the feature added or materially changed a REAL architectural component (a subsystem \u2014 NOT a file), also pass \`architecture: [{ title, domain, role, \u2026 }]\` so the Architecture map stays accurate. It upserts curated components by title; never list files as components. If you found a bug or something worth investigating in a component's code, add \`bugs: [{ note }]\` to its architecture entry \u2014 it renders as a bug flag on the node (attributed to the agent); identical open flags are not duplicated. Only flag what you actually saw in the code.