trybeacon 0.1.38 → 0.1.40

package/dist/lib/codex-install.js

@@ -28,6 +28,7 @@ The user already has Beacon running. You're going to map this repository's archi
 A single \`beacon_init_persist\` MCP tool call with:
 
 - **hasFrontend**: \`true\` or \`false\` \u2014 does this repo have a frontend surface (UI code)? You just read the repo, so you know. Set it explicitly; it gates the frontend/backend \`layer\` distinction on the boards (a pure-backend repo never shows it).
+- **classificationRoots** (optional): the top-level directories whose immediate children are the meaningful groups on the Files canvas \u2014 e.g. \`["frontend", "backend/app"]\`. The canvas groups files ONE level below each root (so \`frontend\` \u2192 \`frontend/components\`, \`frontend/app\`, \u2026). Pick the dir sitting directly ABOVE the real package dirs \u2014 use \`frontend/src\` if there's a \`src/\` wrapper. List both sides of a monorepo so neither collapses into one flat blob. Not every dir \u2014 just where grouping should START. Omit it for a simple single-root repo; the canvas falls back to automatic grouping.
 - **components**: 8\u201325 main building blocks of this codebase. NOT every file. Group them by \`domain\` (short UPPERCASE: AUTH, API, DATA, UI, JOBS, INFRA, BILLING, SEARCH, \u2026). For each: a one-line technical \`role\`, a one-sentence plain-language \`plain\`, the few \`files\` that implement it (repo-relative), \`depends\` listing other component titles it relies on \u2014 and, when \`hasFrontend\` is true, \`layer\` (\`"frontend" | "backend" | "fullstack"\`). Use the dependency graph you can see in the source \u2014 files that import each other heavily usually belong together. If you spot a bug or something worth investigating while reading a component's code, add \`bugs: [{ note }]\` to that component \u2014 it renders as a bug flag on the node (attributed to the agent). Only flag what you actually saw in the code; don't speculate.
 - **roadmap**: 3\u20136 BROAD strategic directions. Big-picture themes only \u2014 "Harden auth & security", "Add observability", "Scale the data layer", "Pay down test-coverage debt". NOT detailed tasks. NOT file-level. Each gets a short title and one-line \`why\`. If one of them is a concrete BUG to fix (something broken you saw in the code), add \`kind: "BUG"\` so it renders as a typed bug card. When \`hasFrontend\` is true, give each a \`layer\` too (\`"frontend" | "backend" | "fullstack"\`).
 - **overview**: one paragraph describing what this project is and its stack. This lands in AGENTS.md as the project intro.
@@ -87,7 +88,7 @@ The one caveat: if the user manually edited an INIT-source node on the canvas (e
    - **~ changed**: COMPONENT_X (role expanded to cover Y)
    - **schema**: + 2 new tables (TableA, TableB); + 3 new endpoints; \u2212 1 deprecated endpoint
    No need to wait for confirmation \u2014 just show the diff so the user sees what's about to land.
-5. **Call \`beacon_init_persist\`** ONCE with the refreshed full analysis (same shape as init: \`components\`, \`roadmap\`, \`overview\`, \`conventions\`, \`snapshot\`, \`hasFrontend\` \u2014 re-assert it, the stack may have changed). It replaces all init-source nodes and regenerates \`AGENTS.md\`. Bug flags already on a component survive the refresh (they're carried over by title); add \`bugs: [{ note }]\` for anything NEW you found worth investigating \u2014 identical open flags are not duplicated.
+5. **Call \`beacon_init_persist\`** ONCE with the refreshed full analysis (same shape as init: \`components\`, \`roadmap\`, \`overview\`, \`conventions\`, \`snapshot\`, \`hasFrontend\` \u2014 re-assert it, the stack may have changed; and \`classificationRoots\` if the Files-canvas grouping needs to change, e.g. a new top-level dir like \`mobile/\` \u2014 OMIT it to keep the existing roots, don't pass \`[]\` unless you mean to clear them). It replaces all init-source nodes and regenerates \`AGENTS.md\`. Bug flags already on a component survive the refresh (they're carried over by title); add \`bugs: [{ note }]\` for anything NEW you found worth investigating \u2014 identical open flags are not duplicated.
 
 ## What you should NOT do
 

package/dist/lib/daemon-port.js

@@ -0,0 +1,2 @@
+// @bun
+var E=Object.defineProperty;var G=(j)=>j;function H(j,q){this[j]=G.bind(null,q)}var N=(j,q)=>{for(var x in q)E(j,x,{get:q[x],enumerable:!0,configurable:!0,set:H.bind(q,x)})};var O=(j,q)=>()=>(j&&(q=j(j=0)),q);import{connect as I}from"net";var S=4319;function J(j,q,x=400){return new Promise((C)=>{let z=I({host:j,port:q}),B=!1,A=(D)=>{if(B)return;B=!0,z.destroy(),C(D)};z.once("connect",()=>A(!0)),z.once("error",()=>A(!1)),z.setTimeout(x,()=>A(!1))})}async function K(j){for(let q of["127.0.0.1","::1"])if(await J(q,j))return!1;return!0}async function T(j,q=20){for(let x=j;x<j+q;x++)if(await K(x))return x;return j}export{K as isPortFree,T as findAvailablePort,S as DEFAULT_PORT};

package/dist/lib/global-install.js

@@ -28,6 +28,7 @@ The user already has Beacon running. You're going to map this repository's archi
 A single \`beacon_init_persist\` MCP tool call with:
 
 - **hasFrontend**: \`true\` or \`false\` \u2014 does this repo have a frontend surface (UI code)? You just read the repo, so you know. Set it explicitly; it gates the frontend/backend \`layer\` distinction on the boards (a pure-backend repo never shows it).
+- **classificationRoots** (optional): the top-level directories whose immediate children are the meaningful groups on the Files canvas \u2014 e.g. \`["frontend", "backend/app"]\`. The canvas groups files ONE level below each root (so \`frontend\` \u2192 \`frontend/components\`, \`frontend/app\`, \u2026). Pick the dir sitting directly ABOVE the real package dirs \u2014 use \`frontend/src\` if there's a \`src/\` wrapper. List both sides of a monorepo so neither collapses into one flat blob. Not every dir \u2014 just where grouping should START. Omit it for a simple single-root repo; the canvas falls back to automatic grouping.
 - **components**: 8\u201325 main building blocks of this codebase. NOT every file. Group them by \`domain\` (short UPPERCASE: AUTH, API, DATA, UI, JOBS, INFRA, BILLING, SEARCH, \u2026). For each: a one-line technical \`role\`, a one-sentence plain-language \`plain\`, the few \`files\` that implement it (repo-relative), \`depends\` listing other component titles it relies on \u2014 and, when \`hasFrontend\` is true, \`layer\` (\`"frontend" | "backend" | "fullstack"\`). Use the dependency graph you can see in the source \u2014 files that import each other heavily usually belong together. If you spot a bug or something worth investigating while reading a component's code, add \`bugs: [{ note }]\` to that component \u2014 it renders as a bug flag on the node (attributed to the agent). Only flag what you actually saw in the code; don't speculate.
 - **roadmap**: 3\u20136 BROAD strategic directions. Big-picture themes only \u2014 "Harden auth & security", "Add observability", "Scale the data layer", "Pay down test-coverage debt". NOT detailed tasks. NOT file-level. Each gets a short title and one-line \`why\`. If one of them is a concrete BUG to fix (something broken you saw in the code), add \`kind: "BUG"\` so it renders as a typed bug card. When \`hasFrontend\` is true, give each a \`layer\` too (\`"frontend" | "backend" | "fullstack"\`).
 - **overview**: one paragraph describing what this project is and its stack. This lands in AGENTS.md as the project intro.
@@ -87,7 +88,7 @@ The one caveat: if the user manually edited an INIT-source node on the canvas (e
    - **~ changed**: COMPONENT_X (role expanded to cover Y)
    - **schema**: + 2 new tables (TableA, TableB); + 3 new endpoints; \u2212 1 deprecated endpoint
    No need to wait for confirmation \u2014 just show the diff so the user sees what's about to land.
-5. **Call \`beacon_init_persist\`** ONCE with the refreshed full analysis (same shape as init: \`components\`, \`roadmap\`, \`overview\`, \`conventions\`, \`snapshot\`, \`hasFrontend\` \u2014 re-assert it, the stack may have changed). It replaces all init-source nodes and regenerates \`AGENTS.md\`. Bug flags already on a component survive the refresh (they're carried over by title); add \`bugs: [{ note }]\` for anything NEW you found worth investigating \u2014 identical open flags are not duplicated.
+5. **Call \`beacon_init_persist\`** ONCE with the refreshed full analysis (same shape as init: \`components\`, \`roadmap\`, \`overview\`, \`conventions\`, \`snapshot\`, \`hasFrontend\` \u2014 re-assert it, the stack may have changed; and \`classificationRoots\` if the Files-canvas grouping needs to change, e.g. a new top-level dir like \`mobile/\` \u2014 OMIT it to keep the existing roots, don't pass \`[]\` unless you mean to clear them). It replaces all init-source nodes and regenerates \`AGENTS.md\`. Bug flags already on a component survive the refresh (they're carried over by title); add \`bugs: [{ note }]\` for anything NEW you found worth investigating \u2014 identical open flags are not duplicated.
 
 ## What you should NOT do
 

package/drizzle/0007_brainy_george_stacy.sql

@@ -0,0 +1 @@
+ALTER TABLE `ProjectMeta` ADD `classificationRoots` text DEFAULT '[]' NOT NULL;