@launchsecure/launch-kit 0.0.28 → 0.0.29

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@launchsecure/launch-kit",
-  "version": "0.0.28",
+  "version": "0.0.29",
   "description": "LaunchSecure toolkit — launch-pod (pipeline), launch-chart (project graph MCP), launch-deck (visual playground MCP), launch-kit-beacon (feedback Web Component), launch-recall (file-watcher backup).",
   "license": "MIT",
   "author": "LaunchSecure - AutomateWithUs",
@@ -56,6 +56,23 @@
     "launch-course": "./dist/server/course-entry.js",
     "launch-beacon": "./dist/server/beacon-monitor-entry.js"
   },
+  "scripts": {
+    "build": "pnpm build:client && pnpm build:chart-client && pnpm build:deck-client && pnpm build:council-client && pnpm build:beacon && pnpm build:server",
+    "build:beacon": "vite build --config vite.beacon.config.ts && tsc -p tsconfig.beacon.json --emitDeclarationOnly --outDir dist/beacon/types",
+    "test:beacon": "vitest run --config vite.beacon.config.ts",
+    "test:radar": "vitest run --config vite.radar.config.ts",
+    "test:chart": "vitest run --config vite.chart.test.config.ts",
+    "build:deck-client": "vite build --config vite.deck.config.ts",
+    "build:council-client": "vite build --config vite.council.config.ts",
+    "build:client": "vite build",
+    "build:chart-client": "vite build --config vite.chart.config.ts",
+    "build:server": "esbuild src/server/cli.ts src/server/fb-wizard.ts src/server/graph-mcp-entry.ts src/server/chart-serve.ts src/server/deck-mcp-entry.ts src/server/deck-serve.ts src/server/council-entry.ts src/server/council-serve.ts src/server/recall-entry.ts src/server/init-entry.ts src/server/orbit-entry.ts src/server/course-entry.ts src/server/beacon-monitor-entry.ts src/server/parse-worker-entry.ts --bundle --platform=node --target=node18 --outdir=dist/server --external:node-pty --external:ws --external:typescript --external:web-tree-sitter --external:tree-sitter-typescript --external:cloudflared --external:pg --external:pg-native && rm -rf dist/server/public && cp -r ../claude-code-web/src/public dist/server/public && rm -rf dist/server/graph/queries && mkdir -p dist/server/graph && cp -r src/server/graph/queries dist/server/graph/queries",
+    "dev:client": "vite",
+    "dev:chart": "pnpm build:server && pnpm build:chart-client && node dist/server/graph-mcp-entry.js serve",
+    "dev:server": "pnpm build:server && node dist/server/cli.js",
+    "dev": "pnpm build:server && concurrently -k -n client,server -c cyan,magenta \"vite\" \"node dist/server/cli.js\"",
+    "prepublishOnly": "pnpm build"
+  },
   "files": [
     "dist",
     "prompts",
@@ -75,6 +92,8 @@
     "ws": "^8.18.0"
   },
   "devDependencies": {
+    "@launchsecure/claude-code-web": "workspace:*",
+    "@launchsecure/ui": "workspace:*",
     "@types/node": "^20.0.0",
     "@types/pg": "^8.11.10",
     "@types/react": "^18.3.12",
@@ -98,24 +117,6 @@
     "react-router-dom": "^6.28.0",
     "tailwindcss": "^3.4.19",
     "vite": "^5.4.11",
-    "vitest": "^1.6.0",
-    "@launchsecure/claude-code-web": "0.0.1",
-    "@launchsecure/ui": "0.0.1"
-  },
-  "scripts": {
-    "build": "pnpm build:client && pnpm build:chart-client && pnpm build:deck-client && pnpm build:council-client && pnpm build:beacon && pnpm build:server",
-    "build:beacon": "vite build --config vite.beacon.config.ts && tsc -p tsconfig.beacon.json --emitDeclarationOnly --outDir dist/beacon/types",
-    "test:beacon": "vitest run --config vite.beacon.config.ts",
-    "test:radar": "vitest run --config vite.radar.config.ts",
-    "test:chart": "vitest run --config vite.chart.test.config.ts",
-    "build:deck-client": "vite build --config vite.deck.config.ts",
-    "build:council-client": "vite build --config vite.council.config.ts",
-    "build:client": "vite build",
-    "build:chart-client": "vite build --config vite.chart.config.ts",
-    "build:server": "esbuild src/server/cli.ts src/server/fb-wizard.ts src/server/graph-mcp-entry.ts src/server/chart-serve.ts src/server/deck-mcp-entry.ts src/server/deck-serve.ts src/server/council-entry.ts src/server/council-serve.ts src/server/recall-entry.ts src/server/init-entry.ts src/server/orbit-entry.ts src/server/course-entry.ts src/server/beacon-monitor-entry.ts src/server/parse-worker-entry.ts --bundle --platform=node --target=node18 --outdir=dist/server --external:node-pty --external:ws --external:typescript --external:web-tree-sitter --external:tree-sitter-typescript --external:cloudflared --external:pg --external:pg-native && rm -rf dist/server/public && cp -r ../claude-code-web/src/public dist/server/public && rm -rf dist/server/graph/queries && mkdir -p dist/server/graph && cp -r src/server/graph/queries dist/server/graph/queries",
-    "dev:client": "vite",
-    "dev:chart": "pnpm build:server && pnpm build:chart-client && node dist/server/graph-mcp-entry.js serve",
-    "dev:server": "pnpm build:server && node dist/server/cli.js",
-    "dev": "pnpm build:server && concurrently -k -n client,server -c cyan,magenta \"vite\" \"node dist/server/cli.js\""
+    "vitest": "^1.6.0"
   }
-}
+}

package/scaffolds/ls-marketplace/.claude-plugin/marketplace.json

@@ -1,5 +1,5 @@
 {
-  "name": "launchsecure",
+  "name": "launch-secure",
   "description": "LaunchSecure plugins for Claude Code — in-app feedback widget activation, and future LS-namespaced workflows. Distributed locally via launch-kit init today; the same catalog will move to github.com/launchsecure/claude-plugins for centralized updates.",
   "owner": {
     "name": "LaunchSecure — AutomateWithUs",
@@ -7,9 +7,9 @@
   },
   "plugins": [
     {
-      "name": "ls",
-      "source": "./plugins/ls",
-      "description": "LS-namespaced slash commands. Exposes /ls:activate-beacon to wire the launch-kit-beacon in-app feedback widget into the current project."
+      "name": "kit",
+      "source": "./plugins/kit",
+      "description": "Kit-namespaced slash commands. Exposes /kit:activate-beacon to wire the launch-kit-beacon in-app feedback widget into the current project."
     }
   ]
 }

package/scaffolds/ls-marketplace/plugins/{ls → kit}/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
-  "name": "ls",
+  "name": "kit",
   "version": "0.1.0",
   "description": "LaunchSecure commands for Claude Code — in-app feedback widget activation, daily standups posted to the Comm Hub, and future LS-namespaced workflows.",
   "author": {
@@ -15,14 +15,5 @@
     "feedback",
     "standup",
     "daily-update"
-  ],
-  "commands": [
-    "./commands/activate-beacon.md",
-    "./commands/standup.md",
-    "./commands/show-mcp-status.md",
-    "./commands/beacon-scan.md",
-    "./commands/beacon-pulse.md",
-    "./commands/beacon-array.md",
-    "./commands/beacon-clear.md"
   ]
 }

package/scaffolds/ls-marketplace/plugins/{ls → kit}/commands/activate-beacon.md

@@ -10,7 +10,7 @@ This command does the integration as a normal dev cycle — read the layout, pro
 
 ## Preflight
 
-1. Confirm `.launch-secure.cred.config` exists at the repo root. If missing, stop and tell the user to run `npx launch-kit init` first — without the cred file the scaffolded `/api/feedback` route has no upstream credentials.
+1. Confirm `.launch-secure.cred.config` exists at the repo root. If missing, stop and tell the user to run `npx @launchsecure/launch-kit init` first — without the cred file the scaffolded `/api/feedback` route has no upstream credentials.
 2. Read `package.json` to detect framework:
    - **Next.js App Router** — `next` in deps AND `app/` or `src/app/` directory present.
    - **Next.js Pages Router** — `next` in deps AND `pages/` directory (no `app/`).
@@ -202,7 +202,7 @@ For Astro, SvelteKit, Nuxt, Express, plain HTML, etc.: do NOT attempt to edit ap
 
 ## Idempotency
 
-Re-running `/ls:activate-beacon`:
+Re-running `/kit:activate-beacon`:
 - If `BeaconMount.tsx` exists, leave it alone unless the user explicitly asks to regenerate.
 - If `<launch-kit-beacon>` is already mounted in the layout, do NOT add a duplicate. Offer to update attributes (endpoint, position) or migrate trigger mode.
 - If `app/api/feedback/route.ts` exists, do NOT overwrite. Diff against the scaffold template and ask whether to merge.

package/scaffolds/ls-marketplace/plugins/kit/commands/activate-statusline.md

@@ -0,0 +1,46 @@
+---
+description: Wire launch-kit's MCP daemon chips into the user's existing Claude Code statusline. Additive — does not create or replace an existing statusline, only appends colored chips (recall/chart/deck/council) showing each daemon's liveness + last-activity age. Idempotent. Run /kit:deactivate-statusline to undo.
+---
+
+# /kit:activate-statusline
+
+Extends the user's existing `~/.claude/settings.json` statusline so MCP daemon health appears alongside whatever they already show (project name, git branch, context %, etc.).
+
+## What it does
+
+1. Reads `~/.claude/settings.json` and checks for an existing `statusLine.command`.
+   - If absent → reports plainly that the user must create their own statusline first. Do NOT scaffold one — launch-kit only EXTENDS, never CREATES.
+2. Writes two scripts under `~/.launchsecure/`:
+   - `statusline-mcp.sh` — emits the colored MCP chips.
+   - `statusline-wrapper.sh` — runs the user's original command, then appends chips.
+3. Replaces `statusLine.command` with the wrapper, stashing the original under `_launchKitStatuslineOriginal` inside the same settings.json (single source of truth, no sidecar state).
+4. Idempotent: if the wrapper is already wired, refreshes the chip scripts only.
+
+## How to run
+
+Shell out to the kit binary:
+
+```bash
+launch-kit statusline activate                                    # all chips
+launch-kit statusline activate --show=recall,chart                # only these
+launch-kit statusline activate --show=recall,chart,deck,council   # explicit all
+```
+
+The `--show` flag accepts any comma-separated subset of `recall,chart,deck,council`. Omitting it shows all four. Re-running activate with a different `--show` updates the chip set in place — no need to deactivate first.
+
+If the published bin isn't on PATH (dev repo, monorepo), fall back to:
+
+```bash
+node packages/cli/dist/server/init-entry.js statusline activate [--show=...]
+```
+
+If the user passed an argument to the slash command (e.g. `/kit:activate-statusline recall,chart`), forward it as `--show=$ARGUMENTS`.
+
+The command prints one of:
+- `✓ activated …` — newly wrapped
+- `✓ refreshed …` — already wrapped, scripts refreshed
+- `✗ no-statusline …` — user has no statusline; report this and stop, do not propose creating one
+
+## After running
+
+Restart any open Claude Code session for the statusline to pick up the wrapper. Subsequent sessions render the chips automatically.

package/scaffolds/ls-marketplace/plugins/{ls → kit}/commands/beacon-array.md

@@ -2,7 +2,7 @@
 description: Show the array of launch-beacon monitor sessions in `.launchsecure/` — which is most recent, how many events each has, last event time, suspected liveness. Use to confirm a session is being recorded, find an old session to inspect, or audit disk usage. Read-only.
 ---
 
-# /ls:beacon-array
+# /kit:beacon-array
 
 Liveness + inventory across every `launch-beacon monitor` session this repo has recorded — one row per beacon in the array.
 
@@ -59,7 +59,7 @@ Rules:
 - Summary line: total count + how many active.
 - Plain text, monospace alignment.
 
-## Full output (`/ls:beacon-array full`)
+## Full output (`/kit:beacon-array full`)
 
 Same per-session block as default, but expand each into a block with extra fields:
 
@@ -89,4 +89,4 @@ End with the same summary line as default.
 - **Read-only.** No deletion, no rotation, no auto-cleanup.
 - **Fast.** Default view should be sub-second even with many session files. Don't full-parse JSON — line counts + first/last line sed is enough.
 - **Plain text.** No markdown tables, no fenced blocks in the actual output.
-- **Don't suggest cleanup.** That's `/ls:beacon-clear`'s job. Stale sessions are informational, not an error.
+- **Don't suggest cleanup.** That's `/kit:beacon-clear`'s job. Stale sessions are informational, not an error.

package/scaffolds/ls-marketplace/plugins/{ls → kit}/commands/beacon-clear.md

@@ -2,7 +2,7 @@
 description: Wipe launch-beacon monitor session NDJSON files. Default clears only the latest session (so you can start a clean repro); pass `all` to remove every `.launchsecure/beacon-*.ndjson`. Always shows what will be deleted and asks for confirmation. Destructive.
 ---
 
-# /ls:beacon-clear
+# /kit:beacon-clear
 
 Clean slate before a fresh repro. The receiver appends to the same NDJSON file across reconnects of the same session, so an existing file accumulates noise from earlier attempts — clearing first makes the new stream easier to reason about.
 
@@ -33,7 +33,7 @@ Refuse with a clear message if:
 - the active monitor session is being written *right now* (mtime within the last 5 seconds) — print a one-line warning and ask the user to stop the monitor first, e.g.:
   ```
   ⚠ .launchsecure/beacon-8f3c2a91.ndjson was written 2s ago — looks active.
-    Stop the receiver (Ctrl+C in the launch-beacon monitor terminal) and re-run /ls:beacon-clear.
+    Stop the receiver (Ctrl+C in the launch-beacon monitor terminal) and re-run /kit:beacon-clear.
   ```
   The user can still force by passing the token explicitly as the argument — but never silently nuke an actively-written file.
 

package/scaffolds/ls-marketplace/plugins/{ls → kit}/commands/beacon-pulse.md

@@ -2,7 +2,7 @@
 description: Show the most recent error from the active launch-beacon monitor session, plus the N events that preceded it (default 10). Answers "what was happening when it broke" without scrolling through the full stream. Read-only.
 ---
 
-# /ls:beacon-pulse
+# /kit:beacon-pulse
 
 The "what happened just before this error" command — a single pulse, freezing the moment the beacon caught a failure. When a bug fires, the actual story is usually the chain of events leading up to it: the click that triggered a state change, the failed fetch that left auth in a bad state, the route change that mounted the wrong component.
 
@@ -10,7 +10,7 @@ Parse `$ARGUMENTS` as one optional integer — the count of preceding events to
 
 ## Preflight
 
-Same as `/ls:beacon-scan` — find the latest NDJSON; if none, stop:
+Same as `/kit:beacon-scan` — find the latest NDJSON; if none, stop:
 
 ```bash
 LATEST=$(ls -t .launchsecure/beacon-*.ndjson 2>/dev/null | head -1)
@@ -23,7 +23,7 @@ Errors are events with `"kind":"error"` or `"kind":"unhandledrejection"`. Find t
 
 ```bash
 ERR_LINE=$(grep -nE '"kind":"(error|unhandledrejection)"' "$LATEST" | tail -1 | cut -d: -f1)
-test -n "$ERR_LINE" || { echo "No errors in the current session. Use /ls:beacon-scan to browse all events."; exit 0; }
+test -n "$ERR_LINE" || { echo "No errors in the current session. Use /kit:beacon-scan to browse all events."; exit 0; }
 ```
 
 ## Pull the window
@@ -62,7 +62,7 @@ window:  10 events before error at line 247
 ```
 
 Format rules:
-- One line per event, same SUMMARY format as `/ls:beacon-scan`.
+- One line per event, same SUMMARY format as `/kit:beacon-scan`.
 - The error block at the end gets the message + (truncated) stack frames if present.
 - Separator above the error is the visual cue.
 
@@ -71,10 +71,10 @@ After the timeline, write **one short paragraph** of analysis: what does the cha
 - click → no observable effect → click again → error → "first click handler crashed silently; second click landed on something else"
 - route change → error → "component on the new route blew up during initial render"
 
-Don't dive into a fix — name the suspected proximate cause, suggest one concrete next step (which file to read, which probe to add, which `/ls:beacon-scan <kind>` to drill into).
+Don't dive into a fix — name the suspected proximate cause, suggest one concrete next step (which file to read, which probe to add, which `/kit:beacon-scan <kind>` to drill into).
 
 ## Constraints
 
 - **Read-only.**
-- **Most recent error only.** If the user wants an earlier one, they can clear the session (`/ls:beacon-clear`) and reproduce, or grep manually.
-- **Plain text.** Same monospace conventions as `/ls:beacon-scan`.
+- **Most recent error only.** If the user wants an earlier one, they can clear the session (`/kit:beacon-clear`) and reproduce, or grep manually.
+- **Plain text.** Same monospace conventions as `/kit:beacon-scan`.

package/scaffolds/ls-marketplace/plugins/{ls → kit}/commands/beacon-scan.md

@@ -2,7 +2,7 @@
 description: Scan recent events from the active launch-beacon monitor session. Defaults to last 50 events across all kinds; pass a kind (`error`, `click`, `fetch`, `route`, `dialog`, `probe`, etc.) to filter, and/or a numeric limit. Reads `.launchsecure/beacon-*.ndjson` — the file written by `launch-beacon monitor`. Read-only.
 ---
 
-# /ls:beacon-scan
+# /kit:beacon-scan
 
 Recent runtime events captured by a `launch-beacon monitor` session. Use this as the first step when investigating something that just happened in the browser — clicks, failed network calls, errors, route changes, probe() calls, dialog mount/unmount.
 
@@ -11,10 +11,10 @@ Parse `$ARGUMENTS` as up to two tokens (space-separated):
 - A **limit**: integer. Default 50.
 
 Examples:
-- `/ls:beacon-scan` → last 50 events of any kind
-- `/ls:beacon-scan error` → last 50 errors only
-- `/ls:beacon-scan click 20` → last 20 click events
-- `/ls:beacon-scan 100` → last 100 events of any kind
+- `/kit:beacon-scan` → last 50 events of any kind
+- `/kit:beacon-scan error` → last 50 errors only
+- `/kit:beacon-scan click 20` → last 20 click events
+- `/kit:beacon-scan 100` → last 100 events of any kind
 
 ## Preflight
 
@@ -56,7 +56,7 @@ If the buffer is empty after filtering, say so: `No events match that filter in
 
 ## Constraints
 
-- **Read-only.** Never delete, modify, or write to the NDJSON file. Wiping is `/ls:beacon-clear`.
+- **Read-only.** Never delete, modify, or write to the NDJSON file. Wiping is `/kit:beacon-clear`.
 - **Always use the latest session by default.** If the user wants a specific session, they'll pass it as a third token — accept any of `<token>`, `<filename>`, or absolute path, and resolve to a valid `.launchsecure/beacon-*.ndjson` path before scanning. Reject with a clear error if it doesn't exist.
 - **Plain text output.** Monospace alignment beats markdown tables here. The user is reading this fast during a debug loop.
-- **Don't speculate on root cause.** Surface anomalies; let the user direct the next query (often: `/ls:beacon-pulse` for context around the latest error).
+- **Don't speculate on root cause.** Surface anomalies; let the user direct the next query (often: `/kit:beacon-pulse` for context around the latest error).

package/scaffolds/ls-marketplace/plugins/kit/commands/deactivate-statusline.md

@@ -0,0 +1,34 @@
+---
+description: Remove launch-kit's MCP daemon chips from the user's Claude Code statusline. Restores the original statusLine.command from the snapshot under _launchKitStatuslineOriginal and deletes the kit-managed wrapper + chip scripts. Idempotent — silently reports if nothing to undo.
+---
+
+# /kit:deactivate-statusline
+
+Reverses `/kit:activate-statusline`. Restores `~/.claude/settings.json`'s `statusLine.command` to whatever it pointed at before activation.
+
+## What it does
+
+1. Reads `~/.claude/settings.json`.
+2. If `_launchKitStatuslineOriginal` is present, copies it back to `statusLine` and deletes the stash key.
+3. Removes `~/.launchsecure/statusline-wrapper.sh` and `~/.launchsecure/statusline-mcp.sh`.
+4. If `_launchKitStatuslineOriginal` is absent → reports "not active" and stops.
+
+## How to run
+
+```bash
+launch-kit statusline deactivate
+```
+
+Or, in a dev repo:
+
+```bash
+node packages/cli/dist/server/init-entry.js statusline deactivate
+```
+
+The command prints one of:
+- `✓ deactivated …`
+- `✗ not-active …`
+
+## After running
+
+Restart any open Claude Code session for the statusline change to take effect.

package/scaffolds/ls-marketplace/plugins/{ls → kit}/commands/show-mcp-status.md

@@ -2,13 +2,13 @@
 description: Show the health of launch-kit's daemon-style MCPs (today just launch-recall). Default output is a terse one-line summary per daemon; pass `full` for expanded details — PID, pidfile, last snapshot, debounce, shadow repo size, recent activity. Read-only; never mutates state.
 ---
 
-# /ls:show-mcp-status
+# /kit:show-mcp-status
 
 Reports the liveness and recent activity of launch-kit's long-running MCP daemons. The recall watcher is the only daemon today; this command is structured so additional daemons can be added without changing its interface.
 
 Read $ARGUMENTS to decide output verbosity:
-- empty (`/ls:show-mcp-status`) → terse one-liner per daemon. Goal: fits in one or two visual lines.
-- `full` (`/ls:show-mcp-status full`) → expanded report per daemon. Goal: enough detail to diagnose health problems.
+- empty (`/kit:show-mcp-status`) → terse one-liner per daemon. Goal: fits in one or two visual lines.
+- `full` (`/kit:show-mcp-status full`) → expanded report per daemon. Goal: enough detail to diagnose health problems.
 
 ## Preflight
 
@@ -36,7 +36,7 @@ Or if dead:
 ```
 recall    ✗ dead   pidfile missing/stale
 
-1 daemon down. Run /ls:show-mcp-status full for details, or restart the watcher (kill any stale pid, then either start a new Claude Code session — the SessionStart hook respawns it — or run `node packages/cli/dist/server/recall-entry.js watch` from this repo).
+1 daemon down. Run /kit:show-mcp-status full for details, or restart the watcher (kill any stale pid, then either start a new Claude Code session — the SessionStart hook respawns it — or run `node packages/cli/dist/server/recall-entry.js watch` from this repo).
 ```
 
 Rules for the default view:
@@ -46,7 +46,7 @@ Rules for the default view:
 - Summary line on a fresh line at the end. If anything is wrong, include a one-sentence recovery hint.
 - No JSON, no PID files paths, no debug info — that's for `full`.
 
-## Full output (`/ls:show-mcp-status full`)
+## Full output (`/kit:show-mcp-status full`)
 
 For each daemon, call BOTH `recall_status` AND `recall_report`. Combine into a per-daemon block:
 
@@ -106,4 +106,4 @@ Don't over-warn — if a repo has genuinely been idle (e.g. you opened it for th
 - Use the wired `launch-recall` MCP tools — do not shell out to `node packages/cli/dist/server/recall-entry.js status` even though it works. Going through MCP makes this command portable across projects that have launch-kit init'd via npx vs dev-build.
 - When listing recent snaps, use the `recentSnapshots` array from `recall_report`. It's already sorted newest-first; just truncate.
 - For "X ago" formatting, do the math yourself. Don't fetch any time service.
-- If you find yourself wanting to add features beyond status display (restart the watcher, prune snaps, etc.) — stop. Those belong in separate `/ls:*` commands. This one is a status pane.
+- If you find yourself wanting to add features beyond status display (restart the watcher, prune snaps, etc.) — stop. Those belong in separate `/kit:*` commands. This one is a status pane.

package/scaffolds/ls-marketplace/plugins/{ls → kit}/commands/standup.md

@@ -1,21 +1,20 @@
 ---
-description: Draft a daily standup from work done since the last push, group themes using launch-chart, show the draft, and post to LaunchSecure Comm Hub as a daily_update after explicit confirmation.
+description: Draft a daily standup from work done since the last push, surface in-progress local work and follow-ups, show the draft, and post to LaunchSecure Comm Hub as a daily_update after explicit confirmation.
 ---
 
 # Standup
 
-Generates a daily-update comment for the LaunchSecure Comm Hub. Pulls commits since the last push (with fallbacks), groups them by codebase layer/module using `launch-chart`, drafts a summary in the project's house style, shows it to the user, and posts only after the user confirms. Never posts without explicit "yes".
+Generates a daily-update comment for the LaunchSecure Comm Hub. Pulls commits since the last push (with fallbacks), surfaces what's still in-flight locally (uncommitted work, explicit follow-ups, in-progress work items), drafts a summary in the project's house style, shows it to the user, and posts only after the user confirms. Never posts without explicit "yes".
 
 ## Preflight
 
-1. Verify `.launch-secure.cred.config` exists at the repo root. If missing, abort and tell the user to run `npx launch-kit init` first — without the cred file the `launch-secure` MCP cannot authenticate, so we cannot read prior standups or post the new one.
+1. Verify `.launch-secure.cred.config` exists at the repo root. If missing, abort and tell the user to run `npx @launchsecure/launch-kit init` first — without the cred file the `launch-secure` MCP cannot authenticate, so we cannot read prior standups or post the new one.
 2. Verify we are inside a git repo (`git rev-parse --git-dir`). If not, abort with a clear message.
-3. Record the current branch (`git rev-parse --abbrev-ref HEAD`).
-4. Detect whether `launch-chart` is wired by calling `mcp__launch-chart__detect_project_stack`. If the call fails or returns nothing, fall back to git-only grouping (note this in the final summary).
+3. Record the current branch (`git rev-parse --abbrev-ref HEAD`) and current git email (`git config user.email`).
 
 ## Gather
 
-Pull data from layered sources, in this order:
+Pull data from layered sources, in this order. Default to git + commit messages — they already carry the structure. Only reach for `launch-chart` in the explicit case described in step 3.
 
 ### 1. Determine the window
 
@@ -27,34 +26,42 @@ Tell the user which window was used in one short line ("Using commits since last
 
 ### 2. Collect change context
 
-- `git diff --stat @{push}..HEAD` (or whichever window was chosen) — file paths + line counts. Drives theme grouping in the next step.
+- `git diff --stat @{push}..HEAD` (or whichever window was chosen) — file paths + line counts. Drives theme grouping.
 - `git log --pretty=format:'%h %s' <window>` — short subject lines for quick scan.
+- `git log --pretty=format:'%h%n%B%n---' <window>` — full commit bodies. Needed for step 4 (follow-up detection).
 - Branch names + PR references in commit messages (look for `#<digits>`, `LS-<id>`, branch slugs like `fix/foo-bar`). These are work-item handles.
 
-### 3. Group by layer/module using launch-chart
+### 3. Group into themes
 
-This is the chart's job — do **not** group by file path string-matching. For each changed file (deduped from the diff stat):
+**Default: group by commit-message scope.** Conventional-commit subjects like `feat(launch-kit): …`, `refactor(server): …`, `chore(lint): …` already declare the theme — use the scope as the theme name. Multiple commits with the same scope collapse into one `→ <Scope>` section.
 
-- Call `mcp__launch-chart__read_graph({ search: "<file basename>", layer: "<best guess: ui|api|db|static>" })` to resolve the file to a graph node, OR
-- Call `mcp__launch-chart__read_graph({ node_id: "<full path>" })` if the file path matches a known node id format
+**Only escalate to `launch-chart` when ALL of these are true:**
+- Window has ≥20 changed files across ≥5 top-level directories, AND
+- Commit scopes are missing, inconsistent, or too coarse to reveal structure (e.g. everything is `chore: …` or untagged).
 
-From the resolved nodes, pull each node's `module` and `layer` fields. Group commits/files into themes by `module` first, then by `layer` when `module` is missing. Common LS modules: `auth`, `pda`, `pda-guides`, `pda-shell`, `radar`, `chart`, `orbit`, `recall`, `comms`, `board`, `webhooks`, `feedback`, `briefs`, `mcp`, etc.
+In that case: call `mcp__launch-chart__detect_project_stack` to verify the chart is wired, then for each changed file call `mcp__launch-chart__read_graph({ search: "<basename>" })` and group by the resolved node's `module` field. Common LS modules: `auth`, `pda`, `pda-guides`, `pda-shell`, `radar`, `chart`, `orbit`, `recall`, `comms`, `board`, `webhooks`, `feedback`, `briefs`, `mcp`.
 
-If a file doesn't resolve in the chart (new file, non-TS, config), bucket it under "Misc" or by directory (`scripts/`, `docs/`, `.github/`).
+Files that don't resolve in the chart (new files, non-TS, config) bucket under "Misc" or by directory.
 
-### 4. Audit pass (optional, skip if it slows things down)
+### 4. Collect in-progress signals (the "what's still in flight" data)
 
-Call `mcp__launch-chart__audit_layer({ layer: "all" })` to surface any drift introduced today (schema_drift, unprotected_routes, dead_screens, hardcoded_values). If the audit reports new issues that didn't exist before (best-effort — compare against the prior standup's audit if possible, otherwise just report current state), flag them in the closing `----` block.
+This is the data that makes the standup honest about what's still open, not just what shipped. Always run all three:
 
-### 5. Blast radius for the biggest changes (deploy-safety signal)
+**4a. Uncommitted local work** — `git status --short`. Group by area (e.g. `scripts/`, `.claude/`, untracked dirs). Filter out build artifacts that don't represent intentional work (`.launchsecure/graphs/*.json`, `node_modules`, `dist`, `.next`). What remains is in-flight code or scaffolds — surface it under "Pending / in-progress".
 
-For the top-3 files by lines-changed in `git diff --stat`, call `mcp__launch-chart__blast_points({ node_id: "<file>", hops: 2 })`. If any of them has a blast radius of >10 dependent nodes, note it as a deploy-risk signal in the `----` block ("touched X which has 24 downstream consumers — review before deploy").
+**4b. Follow-up flags in commit bodies** — grep the full commit bodies pulled in step 2 for these patterns (case-insensitive): `follow-up`, `followup`, `TODO`, `flagged`, `deferred`, `not patched`, `rolled back`, `revert`, `queued`, `to be solved`, `next pass`. Each hit is a self-declared open item by the author — surface the sentence verbatim or paraphrased under "Pending / in-progress".
 
-### 6. Work-item linkage
+**4c. In-progress work items assigned to current user** — call `mcp__launch-secure__work_items_list({ assignee_email: "<git email from preflight>", status: "IN_PROGRESS" })`. For each returned item, capture title + id. Don't list more than 5; if more exist, list 5 + "(N more)".
 
-For each work-item handle found in commit messages, call `mcp__launch-secure__work_items_list` (or `work_item_get` if you have an ID) to pull title + status. If any work items were closed today (status changed to DONE/COMPLETED), call them out in the closing block.
+If any of 4a/4b/4c return nothing, that section just doesn't appear in the draft. Don't fabricate filler.
 
-### 7. Release detection
+### 5. Work-item closure linkage
+
+For each work-item handle found in commit messages from step 2 (regex `#\d+|LS-\w+`), call `mcp__launch-secure__work_item_get({ id: "<id>" })` (or `work_items_list` with id filter). If any status changed to DONE/COMPLETED, call them out in the closing `----` block as a one-liner.
+
+Skip this step if no handles were found in commit messages — don't pull the full work-items list to fish for closures.
+
+### 6. Release detection
 
 A commit qualifies the post for the `release` tag if ANY of the following are true:
 - `package.json` `version` field changed in `git diff @{push}..HEAD -- package.json`
@@ -66,7 +73,7 @@ If any are true, set `addReleaseTag = true`. Otherwise `false`.
 
 ## Draft
 
-Produce the standup in the **exact** house format. This is the format Prajyot uses for human-written daily updates (verified against the May 18, 19, 20 posts in the Comm Hub):
+Produce the standup in the **exact** house format. This is the format Prajyot uses for human-written daily updates (verified against the May 18, 19, 20, 21 posts in the Comm Hub):
 
 ```
 Hey @everyone
@@ -85,6 +92,16 @@ Pushed <N> commits to <branch> today. Highlights:
 
 ----
 
+Pending / in-progress:
+
+→ <Pending area 1>
+- <one-line item — what's open, why, where>
+
+→ <Pending area 2>
+- <one-line item>
+
+----
+
 <one-line PSA or deploy-safety note. Examples: "TS clean, no schema/migration changes, safe to deploy." or "Includes prisma migration <name> — run migrate-with-backup.sh before deploy.">
 
 Thanks
@@ -94,20 +111,21 @@ Thanks
 
 - `Hey @everyone` — exactly this. Not "Hey team", not "Hi everyone". Single line, blank line after.
 - `Pushed N commits to <branch> today. Highlights:` — replace `<branch>` with the actual branch from preflight. If the window was a fallback (not "since last push"), say "Drafted N commits' worth of work on <branch> today. Highlights:" instead — be honest about the window.
-- `→ <Theme>` — right-arrow + space + theme name. Theme names come from chart's `module` grouping (e.g. "→ Radar", "→ Webhooks", "→ Chart / Freshness"). Capitalize the first letter.
+- `→ <Theme>` — right-arrow + space + theme name. Theme names come from commit-message scope (default) or chart module grouping (escalated case). Capitalize the first letter.
 - `- <bullet>` — plain hyphen + space. Bullets are **outcomes**, not commit messages. Translate "feat(radar): add transcript view" into "Structured transcript view with overlay reply drawer". Drop scope prefixes and verb tense.
 - Blank line between themes.
-- `----` — four hyphens, on its own line, blank line above and below.
-- The closing block: one short line is fine. Don't pad.
+- `----` — four hyphens, on its own line, blank line above and below. Used twice: once to open the Pending block, once to close it.
+- **Pending / in-progress block** — omit entirely if steps 4a/4b/4c all returned nothing. If present, populate from those three sources. Each `→` sub-heading names an area (e.g. `→ Feedback widget`, `→ Codex config writer`, `→ Beacon monitor UX`). Bullets are short, factual, name the file or symbol when relevant.
+- Closing block: one short line is fine. Don't pad. Mention work-item closures + any deploy-affecting changes here.
 - `Thanks` — exact word, no comma, no name signature (the post's author is attached automatically).
 
 **Constraints:**
 
 - Plain text only. No `**bold**`, no `*italic*`, no backticks, no `# headers`, no markdown link syntax. The Comm Hub renders as plain text.
-- Aim for ≤ 350 words total. Standups are skim-able; trim aggressively.
+- Aim for ≤ 400 words total (was 350; bumped to accommodate the Pending block). Standups are skim-able; trim aggressively.
 - Top 3–6 themes is the sweet spot. If you have 20 commits in 12 different modules, collapse the small ones into a "→ Misc" theme.
 - Bullets should be **outcome-shaped**: what landed in the product, not what the diff did. "Multi-select EventTypesPicker on subscription forms" beats "modified components/webhooks/EventTypesPicker.tsx".
-- Mention work-item closures and any deploy-affecting changes (migrations, env var changes, breaking API changes) in the closing block.
+- Pending items are honest snapshots, not commitments. "Drawer fix reverted — to be solved fresh" is fine; "will be fixed by EOD" is not.
 
 ## Confirm
 
@@ -127,7 +145,7 @@ Anything ambiguous → treat as "edit, what would you like changed?".
 
 Before posting, call `mcp__launch-secure__communication_read({ tag: "daily_update", limit: 5 })`. If any returned comment has:
 - `resourceType: "comment"` (not `"daily_update"` — that's bot-only, distinct stream)
-- `author.email` matches the current user's email (from `git config user.email`)
+- `author.email` matches the current user's email (from preflight)
 - `createdAt` within the last 12 hours
 
 …then a manual daily_update already exists from today. Offer:
@@ -156,22 +174,18 @@ On success: report the comment ID and a friendly "posted to LS Comm Hub" line. I
 
 On failure: surface the error verbatim. Don't retry automatically — auth or schema errors deserve human attention. The draft is preserved in chat so the user can retry manually.
 
-## Tag handling
-
-Before adding any tag, you may verify it exists via `mcp__launch-secure__tags_list`. The `daily_update` and `release` tags are standard in LS projects; if either is missing, the post will still succeed but the tag won't attach. Surface this as a warning, not a blocker.
-
 ## Idempotency
 
-Re-running `/ls:standup`:
+Re-running `/kit:standup`:
 - Always re-pulls the window fresh. No cached state.
 - Duplicate check handles same-day reposts.
 - The draft is never written to disk — only shown in chat. User can copy it manually if they cancel.
 
 ## Notes for the assistant
 
-- Use `launch-chart` for grouping, not grep/glob. The whole point is producing themes that match how the codebase is organized, not how files are named.
-- The user's preference is short, terse standups (verified style across May 18→20 posts). Default to under-rather-than-over.
-- "Outcome bullet, not commit message" is the single most important transform. A standup full of "feat(x): add y" reads like a changelog, not a status.
-- Never assume `release` tag without evidence (see Release detection above). False positives confuse downstream consumers.
-- Don't ask the user clarifying questions before drafting — produce a first cut, then iterate. The draft is cheap; the conversation isn't.
-- If `launch-chart` is unavailable (no `.launchchart.json`, MCP not responding), fall back to grouping by top-level path segment (`src/app/api/` → "API", `src/client/components/board/` → "Board", etc.) and note "chart unavailable, grouped by path" in chat (not in the post).
+- **Default to git, not the chart.** Conventional-commit scopes already declare themes; only reach for `launch-chart` when scopes are missing or inconsistent across ≥20 files / ≥5 directories. This was the most common failure of the previous prompt — chart calls produced no different grouping than commit-scope grouping would have.
+- **The Pending / in-progress block is the standup's main job, not the shipped-themes block.** Shipped work is visible in `git log`; what's still open isn't. Always run the three step-4 gathers.
+- **Don't ask clarifying questions before drafting.** Produce a first cut from whatever data step 1–6 returned, then iterate. The draft is cheap; the conversation isn't.
+- **Outcome bullet, not commit message** is the single most important transform. A standup full of "feat(x): add y" reads like a changelog, not a status.
+- **Never assume `release` tag without evidence** (see step 6). False positives confuse downstream consumers.
+- **If a step's tool fails**, note it inline and continue with the remaining sources — don't abort the whole standup over one failed call.