lecodes-cli 0.13.1 → 0.13.2

package/dist/index.js

@@ -43217,13 +43217,13 @@ This is an intent-capture stage — screens run on inline mock data, before any
 ## Read this first, then meta.json
 
 \`meta.json\` is the app map: every screen (position, description) and the edges between them
-(navigation intent). **Read it before opening any screen file.** It is the human's file — the
-canvas and the developer own positions and descriptions. When you create a screen, add its meta
-entry **without a \`pos\`** and add edges — the board **auto-places it next to its flow neighbours**,
-so you never hand-pick coordinates (you can't see the board, and positions are the human's to own).
-\`lecodes design arrange --new\` optionally writes those auto-placements into meta.json; the developer's
-⇥ Arrange button re-tidies the whole board. Never reposition or rewrite existing human-authored
-positions or descriptions.
+(navigation intent). **Read it before opening any screen file.** When you create a screen, add its
+meta entry **without a \`pos\`** and add edges — the board places it from its structure (its tab
+lane, its group region, its flow neighbours) and **persists that position itself**; you never
+hand-pick coordinates (you can't see the board). To tidy after a batch of changes, call the
+\`arrange_screens\` MCP tool (or \`lecodes design arrange\`) — the layout engine knows tab rails,
+group regions and flow direction. Never reposition or rewrite existing \`pos\` values or
+human-authored descriptions — positions the developer dragged are theirs.
 
 \`\`\`json
 {
@@ -43247,11 +43247,15 @@ positions or descriptions.
 - **An edge from a screen to itself** (\`"from": "home", "to": "home@empty"\`) is a *state link*: the
   board draws it as a chip on the activator element (clicking it switches the tile's state), never
   as an arrow. Use it to record "tapping X puts this screen into state Y".
-- **Group each screen** you create by its user-facing area — \`"group": "Onboarding"\` — 2–6 screens
-  per group (Onboarding, Checkout, Settings…). Groups render as labeled regions and \`arrange\` lays
-  each out as its own sub-flow, so grouping keeps big boards legible. Semantic clustering is your
-  job (you're good at it); coordinates are \`arrange\`'s (it can see the board, you can't). Don't
-  regroup existing screens unless asked — groups are part of the human's map.
+- **Group only what the tab bar doesn't already section.** Screens on a tab bar are sectioned by
+  their lanes — never set a \`group\` on a tab root or any screen that mounts the bar (a group that
+  duplicates a lane draws nothing and gets flagged for deletion). Group the screens *outside* the
+  bar by user-facing area — \`"group": "Onboarding"\` — 2–6 screens per group (Onboarding,
+  Recovery, Pickers…; on an app with no tab bar that means every screen). Groups render as labeled
+  regions and \`arrange\` lays each out as its own sub-flow, so grouping keeps big boards legible.
+  Semantic clustering is your job (you're good at it); coordinates are \`arrange\`'s (it can see
+  the board, you can't). Don't regroup existing screens unless asked — groups are part of the
+  human's map.
 - **Tag a screen's \`role\`** in its meta entry — its *kind* (\`list\`, \`detail\`, \`form\`, \`auth\`,
   \`modal\`…). Optional, renders on the board, captures concept the screen source can't;
   \`lecodes design check\` lists screens still untagged (never blocking). *(A screen's **states** are
@@ -43332,6 +43336,8 @@ Most apps have one — declare it ONCE, in source, and never draw edges for it:
 - The canvas discovers all of this from the source (like screen states) and draws the bar as a
   **rail + lane bands** — tab switching needs NO edges, and \`design_state\` serves the discovered
   \`hubs\`. In the live prototype, tapping a tab button jumps the board to that tab's root screen.
+- The lane bands replace groups for bar screens: don't \`group\` anything that mounts the bar
+  (see the meta.json section) — groups are for the flows *outside* the bar.
 - Style through theme variables: the bar reads \`var(--primaryColor)\`, \`var(--mutedColor)\`,
   \`var(--tabbarBg)\`, \`var(--screenBg)\` (with fallbacks) — one \`theme({ primaryColor: … })\` call
   restyles it app-wide. You may restyle \`shared/tabs.ts\` itself; keep the \`defineTabs({ … })\`
@@ -43497,8 +43503,8 @@ JSON by hand (a message missing its \`pending\` flag is never delivered, and not
 1. \`board_activity\` (if the server is up), then \`design_comments\` for anything open, then read
    \`meta.json\`, the \`shared/\` signatures, and only the screens you need.
 2. Create/edit screen files; register new screens in \`meta.json\` **without \`pos\`** and add edges —
-   they auto-place next to their neighbours on the board. (\`lecodes design arrange --new\` commits
-   those positions to meta.json if you want them written.)
+   the board places them from their lane/group/flow structure and persists the result. After a
+   larger batch, \`arrange_screens\` (MCP) or \`lecodes design arrange\` re-tidies the whole board.
 3. \`check_screens\` → \`render_screen\` (or \`lecodes design snapshot\`) → verify → fix.
 4. When the developer edits a description, text, or the flow on the canvas — visible in
    \`board_activity\` and in \`meta.json\`/the screen source — treat it as the updated spec.
@@ -43849,11 +43855,12 @@ var DEFAULT_DIR = "design", DEFAULT_PORT = 4477, getContext = (args) => {
   const designServer = await loadDesignServer(ctx);
   const onlyNew = flagBool(args, "new");
   const summary = designServer.arrangeDesign(ctx.designDir, { onlyNew });
+  const score = summary.score ? ` (score ${summary.score.before.toFixed(0)} → ${summary.score.after.toFixed(0)}, lower is better)` : "";
   if (!summary.changed) {
-    log(onlyNew ? "No unplaced screens — nothing to arrange." : "Already tidy — the current layout wins, nothing moved.");
+    log(onlyNew ? "No unplaced screens — nothing to arrange." : `Already in its arranged shape — nothing moved${score}.`);
     return;
   }
-  log(`${c.green("✓")} ${onlyNew ? "Placed" : "Arranged"} ${summary.moved} screen${summary.moved === 1 ? "" : "s"} in ${ctx.dirName}/meta.json.`);
+  log(`${c.green("✓")} ${onlyNew ? "Placed" : "Arranged"} ${summary.moved} screen${summary.moved === 1 ? "" : "s"} in ${ctx.dirName}/meta.json${score}.`);
 }, share = async (ctx, args) => {
   if (!ctx.manifest) {
     throw new CliError("`lecodes design share` needs a cloned project. Run it inside one, and push the design first (lecodes push).");
@@ -45213,7 +45220,7 @@ var require_main = __commonJS((exports, module) => {
 // package.json
 var package_default = {
   name: "lecodes-cli",
-  version: "0.13.1",
+  version: "0.13.2",
   dependencies: {
     "@letary/chisel": "^0.6.0",
     jimp: "^1.6.1"
@@ -45226,8 +45233,8 @@ var package_default = {
     sdk: "workspace:*"
   },
   peerDependencies: {
-    "lecodes-design": "^0.5.0",
-    "lecodes-renderer": "^0.8.0",
+    "lecodes-design": "^0.6.0",
+    "lecodes-renderer": "^0.8.1",
     "lecodes-3d-editor": "^0.2.0"
   },
   bin: {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "lecodes-cli",
-  "version": "0.13.1",
+  "version": "0.13.2",
   "dependencies": {
     "@letary/chisel": "^0.6.0",
     "jimp": "^1.6.1"
@@ -13,8 +13,8 @@
     "sdk": "workspace:*"
   },
   "peerDependencies": {
-    "lecodes-design": "^0.5.0",
-    "lecodes-renderer": "^0.8.0",
+    "lecodes-design": "^0.6.0",
+    "lecodes-renderer": "^0.8.1",
     "lecodes-3d-editor": "^0.2.0"
   },
   "bin": {