@launchsecure/launch-kit 0.0.28 → 0.0.30

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@launchsecure/launch-kit",
-  "version": "0.0.28",
+  "version": "0.0.30",
   "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",
@@ -67,6 +67,7 @@
     "html-to-image": "^1.11.13",
     "node-pty": "^1.2.0-beta.12",
     "pg": "^8.13.0",
+    "pgsql-parser": "^17.9.15",
     "tree-sitter": "^0.21.1",
     "tree-sitter-typescript": "^0.23.2",
     "typescript": "^5.5.0",
@@ -112,7 +113,7 @@
     "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",
+    "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 --external:pgsql-parser --external:libpg-query && 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",

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/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/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.

package/scaffolds/ls-marketplace/plugins/kit/skills/beacon-array.md

@@ -0,0 +1,107 @@
+---
+description: Show the array of launch-beacon monitor sessions via the launch-beacon MCP — 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.
+---
+
+# /kit:beacon-array
+
+Liveness + inventory across every `launch-beacon monitor` session this repo has recorded — one row per beacon in the array.
+
+Parse `$ARGUMENTS` as space-separated tokens, in any order:
+- `full` — expanded report. Empty → terse one-line-per-session summary.
+- `--worktree=<slug>` — orbit worktree slug. Forwarded to MCP as the `worktree` arg.
+- `--project_root=<path>` — explicit project root (absolute, or relative to cwd). Forwarded as `project_root`. Takes precedence over `--worktree`.
+
+Examples:
+- `/kit:beacon-array` → terse one-line-per-session summary
+- `/kit:beacon-array full` → expanded report
+- `/kit:beacon-array --worktree=beacon_rewrite` → enumerate sessions captured in that worktree
+- `/kit:beacon-array full --worktree=beacon_rewrite` → expanded report for that worktree
+
+## Enumerate sessions
+
+Call `mcp__local-launch-beacon__beacon_sessions`, forwarding `worktree` / `project_root` if supplied. Returns an array of per-session summaries: token, event count, kind breakdown, first/last seq, last event timestamp.
+
+If the response is `{sessions: []}` OR `{error: ...}`, **alert the user with the exact MCP error string**, then walk the fallback below — do NOT silently `ls`.
+
+**Fallback when the MCP returns nothing:**
+1. If the user did NOT pass `--worktree` / `--project_root` and `launch-orbit` has worktrees registered for this repo, suggest re-running with `--worktree=<slug>` before falling back to the filesystem.
+2. Look for `.launchsecure/beacon-*.ndjson` in cwd, then in up to 2 parent dirs. Use the `Read` tool — never `ls`, `find`, or globbing as the primary path.
+3. If files are found at an alternative path, tell the user the path mismatch explicitly: `"MCP scans <root>/.launchsecure/ but sessions live at <found-path>. Reading directly."`
+4. If nothing is found anywhere, stop with: `"No beacon sessions found in .launchsecure/. Start one with: npx launch-beacon monitor"`.
+
+## Per-session facts
+
+For each session the MCP returns:
+- **token** — session id
+- **events** — total event count
+- **last_ts** — last event timestamp (epoch ms)
+- **last_kind** — kind of the last event (read from the kind breakdown's most-recent entry, or call `beacon_event(seq: last_seq)` for certainty)
+- **kinds** — kind breakdown map (`{click: 142, fetch: 71, …}`)
+- **first_seq / last_seq** — bounds
+
+Compute **age** from `last_ts` (current epoch minus `last_ts`):
+- < 5s → "just now"
+- < 60s → "Ns ago"
+- < 1h → "Nm ago"
+- < 24h → "Nh ago"
+- else → "Nd ago"
+
+## Liveness heuristic
+
+- **active** — `last_ts` is within the last 5 seconds (matches the receiver's batch-flush interval)
+- **idle** — between 5 seconds and 30 minutes
+- **stale** — older than 30 minutes (the receiver enforces a 30-min cap)
+
+## Default output (no arguments)
+
+```
+.launchsecure/
+  ● 8f3c2a91     247 events    click (just now)        ACTIVE
+    a1b2c3d4      89 events    error (12m ago)         idle
+    2557799f   1,247 events    route (2h ago)          stale
+
+3 sessions, 1 active.
+```
+
+Rules:
+- Glyph: `●` (filled) for active, blank for idle/stale.
+- Columns: token (8 chars) — events (right-aligned, thousands-separated) — last event "kind (age)" — status word.
+- Sort newest-first by `last_ts`.
+- Summary line: total count + how many active.
+- Plain text, monospace alignment.
+
+## Full output (`/kit:beacon-array full`)
+
+Same per-session block as default, then expand each:
+
+```
+● 8f3c2a91 — ACTIVE
+   events:      247
+   last event:  2026-05-26T12:20:51Z (just now)
+   last kind:   click
+   kinds:       click 142, fetch 71, route 12, error 3, dialog 9, probe 10
+   seq range:   1–247
+   started:     2026-05-26T12:12:33Z (8m ago)
+
+  a1b2c3d4 — idle
+   ...
+```
+
+For the `started` timestamp, call `mcp__local-launch-beacon__beacon_event` with `seq: <first_seq>, session: <token>` (and forward the same `worktree` / `project_root` args you used on `beacon_sessions`) and read its `ts`. Only do this for the full view — skip in the default view to keep it sub-second.
+
+`kinds:` formatted as `kind1 N1, kind2 N2, …` sorted by count desc, comma-separated.
+
+End with the same summary line as default.
+
+## File size
+
+The `beacon_sessions` summary does NOT include byte size. Both default and full views omit it — size isn't load-bearing for diagnosis. If the user explicitly asks ("how big is this file?"), fall back to `Read`-then-count or `wc -c` for that single file and tell them so: `"MCP doesn't expose byte size — falling back to wc -c."`.
+
+## Constraints
+
+- **MCP-first.** Use `beacon_sessions` and `beacon_event` — never `ls`, `wc`, `stat`, `tail`, `sed` as the primary path.
+- **Alert on fallback.** If the MCP can't answer, say so verbatim before reading the files directly.
+- **Read-only.** No deletion, no rotation, no auto-cleanup.
+- **Fast.** Default view should be sub-second even with many sessions.
+- **Plain text.** No markdown tables, no fenced blocks in the actual output.
+- **Don't suggest cleanup.** That's `/kit:beacon-clear`'s job. Stale sessions are informational, not an error.

package/scaffolds/ls-marketplace/plugins/kit/skills/beacon-clear.md

@@ -0,0 +1,94 @@
+---
+description: Soft-delete launch-beacon monitor session NDJSON files. Default clears only the latest session (so you can start a clean repro); pass `all` to clear every `.launchsecure/beacon-*.ndjson`. Always shows what will be cleared and asks for confirmation. Recoverable from `.launchsecure/.trash/<ts>/`.
+---
+
+# /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.
+
+Parse `$ARGUMENTS` as space-separated tokens, in any order:
+- empty → clear the most recent session file only
+- `all` → clear every `.launchsecure/beacon-*.ndjson` in the target dir
+- a specific token or filename → clear that one file (must match a real path)
+- `--worktree=<slug>` — orbit worktree slug. Forwarded to MCP as the `worktree` arg; the soft-delete acts on the worktree's `.launchsecure/`.
+- `--project_root=<path>` — explicit project root (absolute, or relative to cwd). Forwarded as `project_root`. Takes precedence over `--worktree`.
+
+Examples:
+- `/kit:beacon-clear` → clear the most recent session in cwd's `.launchsecure/`
+- `/kit:beacon-clear all` → clear every session in cwd's `.launchsecure/`
+- `/kit:beacon-clear all --worktree=beacon_rewrite` → clear every session in that worktree's `.launchsecure/`
+
+## Enumerate candidates
+
+Call `mcp__local-launch-beacon__beacon_sessions`, forwarding `worktree` / `project_root` if supplied. Use `token`, `last_ts`, `events`, and `path` (absolute) from the response. **The filesystem operations below MUST use `path` from this response — never reconstruct paths from `.launchsecure/beacon-<token>.ndjson` relative to cwd**, because with `--worktree` / `--project_root` the real directory is elsewhere.
+
+If the response is `{sessions: []}` OR `{error: ...}`, **alert the user with the exact MCP error string**, then walk the fallback below — do NOT silently `ls`.
+
+**Fallback when the MCP returns nothing:**
+1. If the user did NOT pass `--worktree` / `--project_root` and `launch-orbit` has worktrees registered for this repo, suggest re-running with `--worktree=<slug>` before falling back to the filesystem.
+2. Look for `.launchsecure/beacon-*.ndjson` in cwd, then in up to 2 parent dirs. Use the `Read` tool — never `ls`, `find`, or globbing as the primary path.
+3. If files are found at an alternative path, tell the user the path mismatch and ASK before proceeding — the user may not want to clear files at an unexpected location.
+4. If nothing is found anywhere, stop with: `"No beacon sessions found in .launchsecure/. Nothing to clear."`.
+
+## Decide target set
+
+- empty → most-recent session (highest `last_ts`)
+- `all`  → every session the MCP returned
+- otherwise → resolve `$ARGUMENTS` to a single token: try the literal arg first as a session id, then strip a `.ndjson` suffix, then try matching against the filename portion of a path containing `beacon-<token>.ndjson`. Refuse with a clear message if none match.
+
+## Refusal rules
+
+Refuse with a clear message if:
+- the target set is empty
+- any target resolves outside `.launchsecure/` (defence against `..` injection from `$ARGUMENTS` — even if the user passes an absolute path)
+- the active session is being written *right now* (`last_ts` within the last 5 seconds) — print a one-line warning and ask the user to stop the monitor first:
+  ```
+  ⚠ .launchsecure/beacon-8f3c2a91.ndjson was last written 2s ago — looks active.
+    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 — but never silently nuke an actively-written file.
+
+## Confirmation
+
+Print what's about to be moved and ask before doing it.
+
+```
+About to soft-delete 1 file:
+  .launchsecure/beacon-a1b2c3d4.ndjson   89 events, 12m ago
+
+Recoverable from .launchsecure/.trash/<UTC-timestamp>/ until manually purged.
+
+Confirm? (y/N)
+```
+
+For `all`, list every file with event count + age. Don't truncate.
+
+Wait for explicit `y`/`yes`. Anything else → abort with `Cancelled. No files were moved.`
+
+## Soft-delete (move, don't rm)
+
+Create `<sessionDir>/.trash/<UTC-ISO-timestamp>/` and `mv` each target into it, where `<sessionDir>` is `dirname(path)` from the `beacon_sessions` response — NOT a hard-coded `.launchsecure/`. This matters when `--worktree` or `--project_root` was passed, because the dir is then the worktree's `.launchsecure/`, not cwd's. **Never `rm`.** This is the mitigation for the recall coverage gap — recall doesn't snapshot `.launchsecure/*` today (tracked in LS work item #144). Soft-delete preserves the option to recover within the same machine.
+
+```bash
+SESSION_DIR=$(dirname "<path-from-beacon_sessions>")  # e.g. /repo/.claude/worktrees/foo/.launchsecure
+TRASH="$SESSION_DIR/.trash/$(date -u +%Y%m%dT%H%M%SZ)"
+mkdir -p "$TRASH"
+mv "$SESSION_DIR/beacon-<token>.ndjson" "$TRASH/"
+```
+
+After the move, print:
+
+```
+✓ moved 1 file to .launchsecure/.trash/20260526T142233Z/ (89 events archived).
+  Recover with: mv .launchsecure/.trash/20260526T142233Z/beacon-a1b2c3d4.ndjson .launchsecure/
+```
+
+For `all`, print the count and the trash dir once; don't list every recovery command.
+
+## Constraints
+
+- **MCP-first for enumeration.** Use `beacon_sessions` — never `ls` as the primary path.
+- **Destructive — always confirm.** Even if `$ARGUMENTS` is `all`, ask first.
+- **Scope-locked to the session dir.** The session dir is `dirname(path)` from `beacon_sessions` (typically `.launchsecure/`, but `<worktree>/.launchsecure/` when `--worktree`/`--project_root` is passed). Reject any target outside the dir the MCP told you about, even if the user passes an absolute path. We never touch files we didn't write.
+- **Soft-delete only.** Never `rm` — always `mv` into `.launchsecure/.trash/<ts>/`. The trash dir is not auto-pruned; cleaning it up is a deliberate user action.
+- **Don't stop the monitor server.** This command only moves files. The receiver keeps running and will reopen the same file on its next write — which is fine, the file just starts empty again.