@launchsecure/launch-kit 0.0.29 → 0.0.31

package/scaffolds/ls-marketplace/plugins/kit/skills/diagram/SKILL.md

@@ -0,0 +1,152 @@
+---
+description: Render a Mermaid diagram (flowchart, sequence, ERD, state, gantt) via launch-deck. For ERDs, auto-derives tables and relations from launch-chart's db layer so the diagram matches the real schema. Files a chart-gap feedback comment to LS if the db layer is missing or empty.
+when_to_use: |
+  Auto-fire when the user wants a RENDERED Mermaid diagram visible in the browser — flowchart, sequence, ERD, state machine, or gantt. Trigger phrases: "diagram X", "draw the flowchart for Y", "sequence diagram of W", "ERD for the schema / for X module", "state diagram for V's lifecycle", "gantt of the rollout", "show me visually how X flows", "render this as a diagram", "give me a chart of the user table relations". Deck is required because Mermaid must be rendered to be useful — DSL text in the terminal cannot substitute. Do NOT auto-fire for: plain-text process explanations the user can read in the terminal ("walk me through how X works" — that's /kit:analyse or a direct terminal answer), ASCII flowcharts inline in chat, requests that already include Mermaid the user wrote, or schema questions where the answer is a few sentences rather than a diagram.
+allowed-tools:
+  - mcp__launch-deck__server_status
+  - mcp__launch-deck__start_server
+  - mcp__launch-deck__deck
+  - mcp__launch-deck__await_feedback
+  - mcp__launch-chart__chart_server_status
+  - mcp__launch-chart__detect_project_stack
+  - mcp__launch-chart__read_graph
+  - mcp__launch-chart__inspect_node
+  - mcp__launch-secure__kit_feedback_submit
+  - Bash
+---
+
+# /kit:diagram
+
+Push a Mermaid diagram to launch-deck. Five flavors:
+
+- **flowchart** — boxes-and-arrows for any process
+- **sequence** — request/response timing between actors
+- **erd** — entity-relationship diagram. Auto-pulled from chart `db` layer unless the user provides their own DSL.
+- **state** — state machine
+- **gantt** — timeline
+
+Parse `$ARGUMENTS`:
+- **kind** (required) — `flowchart` | `sequence` | `erd` | `state` | `gantt`. If absent, ask.
+- **subject** (required for non-erd) — what to diagram, e.g. "user login flow" or "OAuth handshake".
+- **--scope=<filter>** — for ERDs, limit to one module or table set (e.g. `--scope=auth` or `--scope=User,Org,Membership`). Default: all tables.
+- **--session=<id>** — deck session name. Default `diagram-<kind>-<subject-slug>`.
+- **--dsl=<raw-mermaid>** — bypass auto-generation; push the user's DSL verbatim.
+- **--feedback** — push in feedback mode and await response.
+
+Examples:
+- `/kit:diagram flowchart user login flow`
+- `/kit:diagram sequence OAuth handshake between client, gateway, idp`
+- `/kit:diagram erd --scope=work-items`
+- `/kit:diagram erd` → full project ERD
+- `/kit:diagram state work-item lifecycle: backlog → todo → in-progress → done`
+
+## Preflight
+
+1. Confirm `mcp__launch-deck__server_status` is running; start if not.
+2. For `erd`: confirm `mcp__launch-chart__chart_server_status` is up, then call `mcp__launch-chart__detect_project_stack` and check `db` is in the layers list.
+
+## Build the DSL
+
+### flowchart / sequence / state / gantt
+
+Translate the subject into Mermaid DSL based on what the user described. For sequence, infer actors from the subject (client/server/db are common defaults). Add concise labels — don't overload with prose.
+
+Example flowchart skeleton:
+
+```mermaid
+flowchart TD
+  Start([User opens app]) --> Auth{Session valid?}
+  Auth -- yes --> Home[Home]
+  Auth -- no --> Login[Login form]
+  Login -- success --> Home
+```
+
+If the user passed `--dsl=…`, skip generation — use their DSL.
+
+### erd
+
+Query the db layer to derive entities and edges:
+
+1. `mcp__launch-chart__read_graph(layer: "db", type: "table"[, module: <scope>])` — gets every table node.
+2. For each table, `mcp__launch-chart__inspect_node(node_id: <id>, fields: ["columns", "relations"])` to get fields and FK relations.
+3. Render Mermaid `erDiagram` DSL:
+
+```mermaid
+erDiagram
+  USER ||--o{ WORK_ITEM : owns
+  USER {
+    string id PK
+    string email
+    datetime createdAt
+  }
+  WORK_ITEM {
+    string id PK
+    string userId FK
+    string title
+    enum type
+  }
+```
+
+Rules:
+- Use `||--o{` for 1:N FK relations, `}o--o{` for many-to-many join tables.
+- Include PK + FK markers; include enum/scalar type for the first ~8 columns per table; truncate the rest with a `… (N more)` comment.
+- Cap at 25 tables to keep the diagram readable. If the project has more than 25 in scope, ask the user to narrow with `--scope=`.
+
+**Chart-gap detection** — file a feedback comment per the protocol below before stopping if:
+- the db layer is missing from `detect_project_stack`
+- `read_graph(layer: "db")` returns 0 nodes
+- the chart shows tables but `inspect_node` returns no `columns` (parser misconfiguration)
+
+## Push to deck
+
+Call `mcp__launch-deck__deck` with:
+- `session: <session>`
+- `mode: "show"` or `"feedback"` (+ `prompt: "Does this match the schema you expected?"` for ERDs)
+- `blocks: [{ type: "mermaid", label: <kind>-<subject>, content: <mermaid-dsl> }]`
+
+If `--feedback`, call `await_feedback` and surface the response.
+
+## Open in browser
+
+After the push (and after `await_feedback` if `--feedback`), open the per-session URL so the user lands directly on this diagram:
+
+```
+open "<deck-url>/#<session>"          # macOS
+xdg-open "<deck-url>/#<session>"      # Linux
+```
+
+`<deck-url>` is the `url` returned by `mcp__launch-deck__server_status` (typically `http://localhost:52829`). The `#<session>` hash deep-links to this exact session.
+
+## Output
+
+```
+diagram pushed — deck session "<session>" — <deck-url>/#<session>
+kind: <kind>
+nodes: <N>  edges: <M>
+```
+
+For ERDs add `tables: <N>  relations: <M>  scope: <scope or "all">`.
+
+## Chart-gap protocol (shared)
+
+When the chart MCP returns less data than expected (db layer missing, 0 tables, empty columns), file ONE report via `mcp__launch-secure__kit_feedback_submit` (the kit-self feedback channel — NOT `communication_write`, which would land in the user's own project Comm Hub instead of the launch-kit project) before stopping:
+
+```
+title: "launch-chart gap: <one-line>"
+source: "kit:diagram"
+body: |
+  Skill: /kit:diagram
+  Tool:  read_graph(layer="db", …) / inspect_node(...)
+  Returned: <tables_count> tables, <relations_count> relations
+  Expected: db layer present per detect_project_stack
+  Project stack: <one-line summary>
+```
+
+Then fall back: render a `flowchart` placeholder explaining "DB layer not available — re-run `npx launch-chart generate_graph` then retry" instead of the ERD.
+
+## Constraints
+
+- **MCP-first for ERDs.** Never grep `prisma/schema.prisma` to build the DSL — the chart has the parsed model.
+- **Cap entities at 25.** Past that, Mermaid wraps unreadably; ask the user to narrow scope.
+- **Mermaid only.** This skill does not draw raster images — Mermaid DSL is the deliverable.
+- **One block per push.**

package/scaffolds/ls-marketplace/plugins/kit/skills/orbit/SKILL.md

@@ -0,0 +1,87 @@
+---
+description: Create an isolated worktree, run pre-merge gates, or merge an orbit into its target — using launch-orbit MCP tools with launch-chart layer detection in the pre-flight. Encodes the project's orbit standards (database fork by profile, gate enforcement, post-merge cleanup) so every orbit gets created and merged the same way.
+---
+
+# /kit:orbit
+
+Drive a launch-orbit worktree through its lifecycle: create → work → check_mergeable → merge → drop. Wraps the MCP tools with sensible defaults and a layer-aware pre-flight so the operator doesn't forget the project's conventions.
+
+Parse `$ARGUMENTS` — first token is the subcommand:
+
+- **create &lt;branch&gt;** — `[--base=<ref>] [--profile=<name>]` — fork resources per `orbit.json`, return path + envFile.
+- **list** — list every orbit registered on this machine.
+- **switch &lt;branch&gt;** — print the path/env for an existing orbit (no shell mutation).
+- **doctor** — surface registry inconsistencies.
+- **check &lt;branch&gt; --target=&lt;target-branch&gt;** — run pre-merge gates WITHOUT merging.
+- **merge &lt;branch&gt; --target=&lt;target-branch&gt;** — `[--cleanup=full|none] [--skip-gate=<id>,…]` — run gates + merge.
+- **drop &lt;branch&gt;** — `[--no-backup]` — tear down (backup, drop DB, remove worktree, deregister).
+
+Examples:
+- `/kit:orbit create feat-channel-rename --profile=fe`
+- `/kit:orbit check feat-channel-rename --target=implementation`
+- `/kit:orbit merge feat-channel-rename --target=implementation`
+- `/kit:orbit doctor`
+
+## Preflight (runs on create / check / merge)
+
+1. Confirm `mcp__launch-orbit__orbit_doctor` returns no critical inconsistencies for THIS project. If it does, surface them and stop — the operator probably wants `/kit:orbit drop <stale-branch>` first.
+2. Confirm `orbit.json` exists at the repo root. If missing, tell the user to add one (point at the orbit docs) and stop.
+3. Run `mcp__launch-chart__detect_project_stack` and print the detected layers as part of the pre-flight log. This is the project's "what's in scope" surface — surface it before any branch op so the operator sees if the chart misses a layer that orbit.json's gates reference (e.g. orbit.json's build-lint gate runs against the api layer but chart doesn't see api).
+4. For **merge**: confirm `--target=` is set. Default is NOT `master` — explicit target only.
+
+## Per-subcommand behavior
+
+### create
+
+1. `mcp__launch-orbit__orbit_create` with `branch`, `baseRef` (if `--base`), `profile` (if `--profile`).
+2. On success, surface the returned `nextAction` (`cd <path>`) verbatim and the `envFile` path. Don't auto-cd — the operator's shell is theirs to drive.
+3. Remind: in the new worktree, `npx launch-kit refresh` will rewire MCPs against the worktree's `.launch-secure.cred.config` symlink if needed.
+
+### list
+
+`mcp__launch-orbit__orbit_list` → one row per orbit: `slug  branch  age  path  resources`.
+
+### switch
+
+`mcp__launch-orbit__orbit_switch(branch)` → print `cd <path>` + `envFile`. Don't run cd.
+
+### doctor
+
+`mcp__launch-orbit__orbit_doctor` → list every issue with a one-line fix (e.g. `orphan-registration` → `/kit:orbit drop <branch>`).
+
+### check
+
+`mcp__launch-orbit__orbit_check_mergeable(branch, target)` → render the gate report:
+
+```
+orbit feat-channel-rename → implementation
+  ✓ builtin/mergeability           (no textual conflicts)
+  ✗ builtin/build-lint             (tsc: 3 errors, see <artifact>)
+  ✓ launchsecure/migration-safety  (no destructive migrations)
+
+result: BLOCKED — fix build-lint then retry.
+```
+
+### merge
+
+1. Run `check` first (same report). If `passed: false`, stop with the report — don't attempt the merge.
+2. If `passed: true`, call `mcp__launch-orbit__orbit_merge(branch, target, cleanup, skipGates)` and surface the result.
+3. Default `cleanup: "full"` (orbit is dropped post-merge after pg_dump). The operator must pass `--cleanup=none` to keep the orbit around.
+4. After a successful merge, recommend `/kit:standup` to surface the change in the next standup, and `/kit:diagram` if it touched the schema.
+
+### drop
+
+`mcp__launch-orbit__orbit_drop(branch, backup: !args.noBackup)` → idempotent. Surface `backups[]` paths.
+
+## Conventions encoded here
+
+- **No bare `--target=master`.** Default merge target is `implementation` per project CLAUDE.md ("implementation branch is parent for all impl branches"). If the operator types `--target=master`, double-check by asking once.
+- **No `--skip-gate` without a reason in the next message.** Surface a banner: `"Skipping gates: <ids>. Reason?"` — let the operator answer in chat; do NOT proceed silently.
+- **Always run `check` before `merge`.** The skill enforces this — even if the operator runs `merge` directly, the skill runs `check` first.
+- **Layer awareness.** Pre-flight always prints `detect_project_stack` layers so the operator sees parity (or absence) between chart layers and orbit gate scope.
+
+## Constraints
+
+- **MCP-first.** Never shell out to `git worktree`, `git merge`, `pg_dump` directly — orbit's tools own these.
+- **Idempotent.** All subcommands are safe to retry. Drop especially — it handles partial-state gracefully.
+- **Surface, don't hide.** If a gate fails, print the artifact path; if the doctor finds inconsistency, print the exact slug.

package/scaffolds/ls-marketplace/plugins/kit/skills/prototype/SKILL.md

@@ -0,0 +1,110 @@
+---
+description: Generate a working HTML/JS prototype page and push it to launch-deck for click-through review. Use to validate behavior — flow, transitions, interactions — before any framework code is touched. Calls deck's rich-html block with framework=raw; supports CDN scripts, animations, real DOM events.
+when_to_use: |
+  Auto-fire when the user wants an INTERACTIVE throwaway page to validate behavior — click flows, transitions, optimistic updates, keyboard shortcuts, drag/drop — before any production code. Trigger phrases: "prototype X", "let me click through Y", "build a working demo of Z", "test the interaction for X", "throwaway version of W", "make it interactive so I can try it", "show me how the kanban drag would feel". Deck is required because the deliverable is a rendered, clickable page the user must touch — text/code descriptions in the terminal don't substitute. Do NOT auto-fire for: production implementation (use the appropriate fe:* / be:* flow), static visual mockups (use /kit:wireframe), reading or explaining existing code behavior (use /kit:analyse), plain-text walkthroughs of an interaction that the user can read in the terminal, or any request that's clearly about discussion not artifact production.
+allowed-tools:
+  - mcp__launch-deck__server_status
+  - mcp__launch-deck__start_server
+  - mcp__launch-deck__deck
+  - mcp__launch-deck__await_feedback
+  - mcp__launch-chart__read_graph
+  - Bash
+---
+
+# /kit:prototype
+
+Build a self-contained, interactive HTML page (HTML + CSS + JS, optional CDN scripts) and push it to launch-deck. Unlike `/kit:wireframe`, this is a *working* prototype: the user can click, type, navigate fake routes, see transitions — the goal is to test behavior cheaply.
+
+Parse `$ARGUMENTS`:
+- **description** (required) — what the prototype should demonstrate, e.g. "drag-to-reorder kanban with optimistic update and rollback on error".
+- **--session=<id>** — deck session name. Default `proto-<slugified-description-first-3-words>`.
+- **--feedback** — push in `feedback` mode with `prompt: "Did this match the interaction you had in mind?"` and call `await_feedback`.
+- **--cdn=tailwind|alpine|htmx|react|vue|none** — comma-separated CDN(s) to include. Default `tailwind` for styling. `none` for pure handwritten CSS.
+- **--theme=light|dark** — only when the prototype demands one mode (e.g. a dark-mode-only design).
+
+Examples:
+- `/kit:prototype drag-to-reorder kanban with optimistic update`
+- `/kit:prototype keyboard shortcut palette with fuzzy search --cdn=tailwind,alpine`
+- `/kit:prototype landing page hero with parallax scroll --feedback`
+
+## Preflight
+
+1. Confirm `mcp__launch-deck__server_status` is running. Start if not.
+2. If the description references real entities/pages in this repo, run `mcp__launch-chart__read_graph(search: <hint>)` to pull the shape — so the prototype mirrors actual data field names. Optional; skip on first iteration to keep the loop fast.
+
+## Build the page
+
+Generate a complete `<!DOCTYPE html>` document. Layout:
+
+```html
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="utf-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1">
+  <title><short title></title>
+  <!-- CDNs (per --cdn flag) -->
+  <script src="https://cdn.tailwindcss.com"></script>
+  <script defer src="https://unpkg.com/alpinejs"></script>
+  <style>
+    /* page-specific styles */
+  </style>
+</head>
+<body class="…">
+  <!-- the prototype -->
+  <script>
+    // event handlers, state, fake data
+  </script>
+</body>
+</html>
+```
+
+CDN catalog (use only what's requested):
+- **tailwind** — `<script src="https://cdn.tailwindcss.com"></script>`
+- **alpine** — `<script defer src="https://unpkg.com/alpinejs"></script>` for `x-data` reactivity
+- **htmx** — `<script src="https://unpkg.com/htmx.org"></script>` for fake server swaps
+- **react** — `<script crossorigin src="https://unpkg.com/react/umd/react.production.min.js"></script>` + `react-dom` + Babel CDN if JSX
+- **vue** — `<script src="https://unpkg.com/vue@3/dist/vue.global.prod.js"></script>`
+
+Design rules:
+- **Fake the backend.** Use in-memory arrays, `setTimeout` to simulate latency, `Math.random() < 0.1` to simulate intermittent failures (for testing rollback flows).
+- **No real PII or secrets.** Use placeholder names ("Ada", "Lin", "Mehmet"), placeholder copy, never a real user from this project.
+- **Show the interaction explicitly.** If the prototype's point is drag-to-reorder, make the drag affordance OBVIOUS (cursor change, hover scale, snap line). If the point is optimistic update + rollback, force a visible failure within ~5 clicks so the reviewer experiences it.
+- **One screen unless the user asks for multi-screen.** Multi-screen prototypes use a fake router (`window.history.pushState` + a click handler) — don't pull in `react-router`.
+
+## Push to deck
+
+Call `mcp__launch-deck__deck` with:
+- `session: <session>`
+- `mode: "show"` or `"feedback"` (+ `prompt`)
+- `blocks: [{ type: "rich-html", framework: "raw", label: <short-title>, content: <full-doctype-html>, theme: <theme?> }]`
+
+`framework: "raw"` means the deck does NOT wrap your content — what you ship IS the page. That's why the full `<!DOCTYPE html>` doctype is required.
+
+If `--feedback`, call `mcp__launch-deck__await_feedback` afterward and surface the response.
+
+## Open in browser
+
+After the push (and after `await_feedback` if `--feedback`), open the per-session URL so the user lands directly on this prototype:
+
+```
+open "<deck-url>/#<session>"          # macOS
+xdg-open "<deck-url>/#<session>"      # Linux
+```
+
+`<deck-url>` is the `url` returned by `mcp__launch-deck__server_status` (typically `http://localhost:52829`). The `#<session>` hash deep-links to this exact session.
+
+## Output
+
+```
+prototype pushed — deck session "<session>" — <deck-url>/#<session>
+size: <N> KB markup, <M> CDN scripts, <K> inline event handlers
+demonstrates: <one-line>
+```
+
+## Constraints
+
+- **Self-contained.** No external API calls, no auth flows, no real LS endpoints. Everything in one HTML file.
+- **One block per push.** Multi-block prototypes belong as separate sessions.
+- **Iterate via re-push.** Same `--session` overwrites — that's the loop. Don't accumulate prototype-v2, prototype-v3 sessions.
+- **No production-ready output.** If the user is happy with the prototype and wants to "turn it into the real thing," that's a separate `/fe:*` workflow — this skill is throw-away to validate behavior.

package/scaffolds/ls-marketplace/plugins/kit/skills/recovery/SKILL.md

@@ -0,0 +1,95 @@
+---
+description: Recover deleted, overwritten, or accidentally-modified files. Prefers launch-recall's shadow-git backup when wired (per-file snapshot history, debounced, doesn't need commits); falls back to git reflog / git stash / git log when recall isn't available. Read-only by default; restore is one-shot and prompts before overwriting. Never suggests destructive ops (git reset / git clean / rm) — recovery only.
+when_to_use: |
+  Auto-fire whenever the user signals they've lost work or want to undo something on disk. Trigger phrases: "I lost X", "lost my changes", "deleted by mistake", "accidentally deleted / removed / overwrote", "auto-formatter ate", "prettier ate my comments", "can I get back / recover / restore X", "undo my last edit", "undo what I did to X", "go back to previous version", "previous version of X", "what was in X before", "revert this file", "rollback this file" (note: "rollback the deploy" is NOT this — that's deploy-check / orbit territory), "the file is gone", "where did X go" when framed as loss. Also auto-fire on manual subcommand usage: status / doctor / history / show / restore / diff / report. Do NOT auto-fire for: bug investigation ("why doesn't X work" → /kit:debug), code structure ("how does X work" → /kit:analyse), git workflow ("how do I commit / push / merge" → general git help).
+allowed-tools:
+  - mcp__launch-recall__recall_status
+  - mcp__launch-recall__recall_doctor
+  - mcp__launch-recall__recall_history
+  - mcp__launch-recall__recall_report
+  - Bash(git --git-dir=*)
+  - Bash(git reflog*)
+  - Bash(git stash list*)
+  - Bash(git log*)
+  - Bash(git show*)
+  - Bash(git diff*)
+---
+
+# /kit:recovery
+
+Recover deleted / overwritten / lost files. **Recall-first** when wired, **git-fallback** when not. Read-only except for `restore` (which prompts).
+
+## Preflight — detect which path is available
+
+Always start by checking which recovery backend is reachable. Run BOTH probes (cheap, in parallel):
+
+1. `mcp__launch-recall__recall_status` → if it returns `{running: true, lastSnapshotAt: …}`, recall is the preferred path. Note the `watchTree` for context.
+2. `Bash("git rev-parse --is-inside-work-tree 2>&1")` → confirms a regular git repo exists (for the fallback path and for cross-checks).
+
+Surface what's available before doing anything else:
+- Both available → use recall first, mention git as fallback.
+- Only git available → tell user `"launch-recall not wired in this project — falling back to git reflog/log. (Recall would give you per-file history without needing commits. Run `npx @launchsecure/launch-kit refresh` to wire it.)"`
+- Neither available → stop and surface that. Can't recover blind.
+
+## Subcommand interface (manual invocation)
+
+Parse `$ARGUMENTS` — first token is the subcommand. If the first token doesn't match any known subcommand, treat the whole input as a **natural-language recovery request** (see below).
+
+- **status** — recall watcher liveness + last snapshot age (one line).
+- **doctor** — recall health check (3-line report: shadow_repo / watcher_alive / recent_snapshot).
+- **report** — project-wide recall stats (totalSnapshots, shadowSizeBytes, recentSnapshots).
+- **history `<path>`** — `[--limit=N]` — snapshots for the path (recall) OR `git log -p -- <path>` rows (fallback). Default limit 20.
+- **show `<path>` `<sha>`** — print the file at that snapshot (no write).
+- **diff `<path>` `<sha>`** — unified diff vs current working tree (or "file deleted from working tree" if absent). Cap 500 lines.
+- **restore `<path>` `<sha>`** — `[--to=<target-path>]` — restore the file. Strict confirmation protocol below.
+
+Examples:
+- `/kit:recovery status`
+- `/kit:recovery history src/server/comms/build-feed.ts`
+- `/kit:recovery show src/server/comms/build-feed.ts a1b2c3d`
+- `/kit:recovery restore src/server/comms/build-feed.ts a1b2c3d`
+- `/kit:recovery restore prisma/schema.prisma a1b2c3d --to=prisma/schema.recovered.prisma`
+
+## Natural-language recovery flow (auto-invoke path)
+
+When the user says "I lost X" / "deleted by mistake" / "prettier ate my comments" / "can I get back…", follow this loop:
+
+1. **Identify the target**: parse the user's prompt for a file path. If absent, ask: `"Which file or directory? (full path from repo root)"`. Do not guess.
+2. **Preflight** (see above) so you know which backend you're on.
+3. **List options**:
+   - Recall path: `recall_history(path: <path>, limit: 20)` → table of `sha | age | message`.
+   - Git path: `git log --oneline -20 -- <path>` (committed) AND `git reflog | head -20` (recent HEAD moves) AND `git stash list` (stashes). Present each source separately so the user knows which kind of recovery they're picking.
+4. **Show a candidate's content** before any restore: `show` the latest snapshot/commit so the user can confirm it's what they want.
+5. **Confirm restore** per the protocol below. NEVER restore without explicit `yes`.
+
+## Restore protocol (the only write operation)
+
+1. Resolve target path: `--to=<target>` if given, else the original `<path>`.
+2. If the target **exists on disk**:
+   - Print a side-by-side summary: `current size <N> bytes, snapshot size <M> bytes`.
+   - Show the first ~20 lines of the diff (current → snapshot).
+   - Ask: `"Overwrite <target>? (yes / show full diff / no)"` — wait for explicit `yes`.
+3. If the target does **NOT exist** on disk (file was deleted), restore without prompt but tell the user before writing: `"Restoring deleted file to <target> from snapshot <sha>."`
+4. Restore command:
+   - Recall path: `git --git-dir=<shadowRepoPath> --work-tree=<projectRoot> show <sha>:<path> > <target>`
+   - Git path: `git show <sha>:<path> > <target>` (against the regular repo)
+5. After restore: `"Restored. (Recall — if active — just captured a new snapshot of the restore itself, so your prior working-tree state is also recoverable.)"`
+
+## When recall is NOT wired — git fallback instructions
+
+If `recall_status` says recall isn't running OR the MCP isn't reachable, walk the user through the git-only path:
+
+- **Recently deleted file but no commit since**: `git checkout HEAD -- <path>` (restores from last commit). Confirm before running — this overwrites uncommitted changes if any exist.
+- **Lost edits made after the last commit, no stash**: usually unrecoverable from git alone unless your editor has a local history feature (VS Code: "Timeline" view, JetBrains: "Local History"). Surface this honestly: `"Git only tracks what you commit. Your editor may have local history — check VS Code's Timeline or JetBrains' Local History panel for unsaved changes."`
+- **File existed in a previous commit, deleted later**: `git log --oneline --all -- <path>` to find the last commit that contained it, then `git show <sha>:<path>` to view, then `git show <sha>:<path> > <path>` to restore.
+- **Stashed changes**: `git stash list` to enumerate, `git stash show -p stash@{N}` to view, `git stash apply stash@{N}` to apply (non-destructive — keeps the stash).
+- **Recent HEAD moves (force-push, rebase, reset)**: `git reflog` shows the prior positions. `git show <sha>:<path>` to view, then restore via `git show > file` (NOT `git reset --hard` — that moves your branch).
+
+## Constraints
+
+- **Read-only by default.** Only `restore` writes; everything else reads.
+- **Restore requires explicit `yes` confirmation** when overwriting an existing file. Never auto-overwrite — per project memory `feedback_no_dumb_reverts`, destructive ops need explicit confirmation.
+- **Never suggest `git reset --hard` / `git clean -f` / `rm` as recovery.** These DESTROY more state than they recover. Always restore via `git show > file` so the rest of the tree is untouched.
+- **Never auto-init recall.** If recall isn't wired, point at `npx @launchsecure/launch-kit refresh` — don't run it for the user. Their project, their choice.
+- **Surface both paths when both are available.** Recall has per-file granularity without needing commits; git has the canonical commit history. Sometimes the user wants the committed version, not the latest in-flight edit. Let them choose.
+- **Quote both ambiguities when history is empty.** If `recall_history` returns nothing AND the file still exists, say BOTH "path may be in recall's ignore list" AND "file may simply have no churn" — don't guess.

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

@@ -12,7 +12,7 @@ Read $ARGUMENTS to decide output verbosity:
 
 ## Preflight
 
-1. Verify the launch-recall MCP is wired by checking whether `mcp__launch-recall__recall_status` (or `mcp__local-launch-recall__recall_status` for dev repos) is callable. If neither is available, say so plainly: "launch-recall MCP not wired in this project — nothing to report" and stop.
+1. Verify the launch-recall MCP is wired by attempting `mcp__launch-recall__recall_status` (or `mcp__local-launch-recall__recall_status` for dev repos). If neither is callable, **alert the user verbatim**: `"launch-recall MCP not wired in this project — nothing to report. (Skill is MCP-first; no shell fallback for daemon status.)"` and stop.
 2. Pick whichever recall MCP is available. Prefer the project-level published one (`mcp__launch-recall__*`) unless only the local dev one is wired.
 
 ## Daemons
@@ -36,7 +36,7 @@ Or if dead:
 ```
 recall    ✗ dead   pidfile missing/stale
 
-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).
+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 `npx -y -p @launchsecure/launch-kit launch-recall watch` from the project root).
 ```
 
 Rules for the default view:
@@ -103,7 +103,7 @@ Don't over-warn — if a repo has genuinely been idle (e.g. you opened it for th
 
 ## Notes for the assistant
 
-- 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.
+- **MCP-first, no shell fallback.** Use the wired `launch-recall` MCP tools — do NOT shell out to `node packages/cli/dist/server/recall-entry.js status` or `ps`-based liveness checks. If the MCP isn't wired, the preflight step already stops the skill — no silent grep/find.
 - 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 `/kit:*` 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:*` skills. This one is a status pane.

package/scaffolds/ls-marketplace/plugins/kit/skills/wireframe/SKILL.md

@@ -0,0 +1,90 @@
+---
+description: Generate a hand-drawn wireframe mockup using wired-elements and push it to launch-deck for review. Use when the user wants to sketch a UI/page layout before any real implementation — sign-off material for discussion, not production HTML. Calls deck's rich-html block with framework=wired.
+when_to_use: |
+  Auto-fire when the user wants to SKETCH a UI/page layout as a low-fi visual artifact for review or sign-off. Trigger phrases: "wireframe", "sketch the UI for X", "mock up a page", "rough layout for X", "low-fi mockup", "what could this screen look like", "give me a sketch of the settings page", "sign-off on this layout". Deck is required because the deliverable is a rendered visual artifact the user will look at — text in the terminal cannot substitute. Do NOT auto-fire for: plain-text layout descriptions the user can read in the terminal, production component code (use /fe:* flows), polished pixel-perfect mockups (use /kit:prototype with proper styling), ASCII-art layouts in chat, or any request where the user is asking ABOUT a wireframe rather than asking FOR one.
+allowed-tools:
+  - mcp__launch-deck__server_status
+  - mcp__launch-deck__start_server
+  - mcp__launch-deck__deck
+  - mcp__launch-deck__await_feedback
+  - mcp__launch-chart__read_graph
+  - Bash
+---
+
+# /kit:wireframe
+
+Sketch a UI screen as a low-fi wired-elements wireframe and push it to launch-deck. The output is intentionally sketchy (the wired-elements aesthetic) — it communicates structure and information density, not final visual design.
+
+Parse `$ARGUMENTS`:
+- **description** (required) — free-form description of the screen, e.g. "settings page with three tabs: profile, billing, integrations; right rail shows recent activity". If absent, ask the user.
+- **--session=<id>** — deck session name. Default `wireframe-<slugified-description-first-3-words>`.
+- **--feedback** — push in `feedback` mode with `prompt: "What's missing from this layout?"` and call `await_feedback` afterward.
+- **--theme=light|dark** — only set when the wireframe ONLY makes sense in one mode. Default: omit (deck's sun/moon toggle wins).
+
+Examples:
+- `/kit:wireframe settings page with three tabs: profile, billing, integrations`
+- `/kit:wireframe org dashboard with KPI strip on top, project grid below --feedback`
+
+## Preflight
+
+1. Confirm `mcp__launch-deck__server_status` returns running. If not, call `mcp__launch-deck__start_server` first.
+2. If the description is shorter than ~8 words OR mentions a real page in this repo, run `mcp__launch-chart__read_graph(type: "page", search: <hint>)` to find a similar existing page first — confirm with the user whether to mirror that page's structure or design new layout from scratch. (This is a courtesy to avoid wireframing something that already exists; skip on `--no-chart`.)
+
+## Build the wired markup
+
+Translate the description into a wired-elements page body. Use these elements:
+
+| Need | Use |
+|---|---|
+| Container | `<wired-card elevation="2">` |
+| Heading | plain `<h1>` / `<h2>` (wired-card text inherits) |
+| Buttons | `<wired-button>Label</wired-button>` |
+| Input | `<wired-input placeholder="…"></wired-input>` |
+| Checkbox | `<wired-checkbox>Label</wired-checkbox>` |
+| Dropdown | `<wired-combo>` with `<wired-item value="…">…</wired-item>` children |
+| Tabs | `<wired-tabs>` with `<wired-tab name="…">…</wired-tab>` children |
+| Slider | `<wired-slider min=… max=…>` |
+| Divider | `<wired-divider>` |
+
+Layout rules:
+- Wrap the page in a top-level `<wired-card>` so it gets the sketched border.
+- Use CSS grid (`display:grid; grid-template-columns: …;`) for multi-column layouts — inline `<style>` is fine, the deck rich-html block renders it.
+- Pad generously (`padding: 24px; gap: 16px`) — the wired-elements aesthetic looks cramped without space.
+- Annotate non-obvious regions with comments like `<!-- right rail: activity feed -->` so the reviewer can navigate the markup.
+
+Do NOT include real production CSS, no Tailwind utility classes, no shadcn primitives. This is on-purpose a sketch.
+
+## Push to deck
+
+Call `mcp__launch-deck__deck` with:
+- `session: <session>`
+- `mode: "show"` (or `"feedback"` if `--feedback` was passed; also set `prompt`)
+- `blocks: [{ type: "rich-html", framework: "wired", label: <short-title>, content: <body-html>, theme: <theme?> }]`
+
+If `--feedback` was passed, immediately call `mcp__launch-deck__await_feedback` with the same session and surface the user's response back.
+
+## Open in browser
+
+After the push (and after `await_feedback` if `--feedback`), open the per-session URL so the user lands directly on this wireframe:
+
+```
+open "<deck-url>/#<session>"          # macOS
+xdg-open "<deck-url>/#<session>"      # Linux
+```
+
+`<deck-url>` is the `url` returned by `mcp__launch-deck__server_status` (typically `http://localhost:52829`). The `#<session>` hash deep-links to this exact session — the deck-client picks it up on load and on hashchange.
+
+## Output
+
+```
+wireframe pushed — deck session "<session>" — <deck-url>/#<session>
+elements: <N> cards, <M> buttons, <K> inputs, <T> tabs
+```
+
+If `--feedback`: also print the feedback comment + any option selections, then ask what to change.
+
+## Constraints
+
+- **No production assets.** Don't pull real images, real fonts, real brand colors — the wired sketch IS the point. If the user asks for a "polished" mockup, suggest `/kit:prototype` instead.
+- **Single block per push.** Don't split one wireframe into multiple deck blocks; one screen = one rich-html block.
+- **Iterate via re-push.** Re-running with the same `--session` overwrites; that's the iteration loop.

package/scaffolds/statusline/statusline-mcp.sh

@@ -114,19 +114,31 @@ chip_recall() {
 }
 
 chip_chart() {
+  # Drift-based color — reflects how out-of-sync the graph is with the code,
+  # NOT whether a watcher daemon is alive. A user who regenerated by hand
+  # and never started the watcher should still see green when the graph is
+  # fresh. Daemon liveness lives in /kit:show-mcp-status.
+  #
+  #   RED    — .freshness.json missing OR failedFiles non-empty (broken graph)
+  #   ORANGE — state != "fresh" (chart MCP says the snapshot has drifted)
+  #   GREEN  — state == "fresh" AND no failed files
   local freshness="$PROJECT_ROOT/.launchsecure/graphs/.freshness.json"
   if [ ! -f "$freshness" ]; then _state="red"; _display="${RED}chart${RESET}"; return; fi
-  local last
+
+  local last state_field
   last=$(grep -o '"lastFullRegenAt"[^,}]*' "$freshness" | head -1 | sed 's/.*"\([0-9TZ:.+-]*\)".*/\1/')
-  local lock="$PROJECT_ROOT/.launchsecure/launch-chart.lock"
-  local color="$ORANGE"; local state="orange"
-  if [ -f "$lock" ]; then
-    local pid
-    pid=$(pid_from_lockfile "$lock")
-    if [ -n "$pid" ] && kill -0 "$pid" 2>/dev/null; then
-      color="$GREEN"; state="green"
-    fi
+  state_field=$(grep -o '"state"[[:space:]]*:[[:space:]]*"[^"]*"' "$freshness" | head -1 | sed 's/.*"\([^"]*\)"$/\1/')
+
+  # failedFiles is non-empty iff the empty-array literal `[]` isn't present.
+  local color state
+  if ! grep -q '"failedFiles"[[:space:]]*:[[:space:]]*\[[[:space:]]*\]' "$freshness"; then
+    color="$RED"; state="red"
+  elif [ "$state_field" != "fresh" ]; then
+    color="$ORANGE"; state="orange"
+  else
+    color="$GREEN"; state="green"
   fi
+
   if [ -n "$last" ] && [ "$last" != "null" ]; then
     local epoch age
     epoch=$(iso_to_epoch "$last")

package/dist/beacon/types/capture/element.d.ts

@@ -1,3 +0,0 @@
-import type { RawPinCapture } from '../types';
-export declare function capturePin(el: Element): RawPinCapture;
-//# sourceMappingURL=element.d.ts.map

package/dist/beacon/types/capture/element.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"element.d.ts","sourceRoot":"","sources":["../../../../src/beacon-client/capture/element.ts"],"names":[],"mappings":"AAEA,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,UAAU,CAAC;AAwD9C,wBAAgB,UAAU,CAAC,EAAE,EAAE,OAAO,GAAG,aAAa,CAsBrD"}

package/dist/beacon/types/capture/events.d.ts

@@ -1,20 +0,0 @@
-import type { CapturedEvent } from '../types';
-/**
- * Attach `error` and `unhandledrejection` listeners on `window`. Idempotent — safe
- * to call repeatedly (e.g., HMR reloads). No-op in non-browser environments.
- *
- * Called at module load from index.ts so we start capturing before the beacon
- * element mounts. Errors that fire during initial page hydration are exactly
- * the ones users are most likely to report and least able to describe.
- */
-export declare function installEventCapture(): void;
-/** Snapshot of the captured events buffer. Returns a copy; callers can mutate it. */
-export declare function getCapturedEvents(): CapturedEvent[];
-/**
- * Register a callback that fires every time a new event is added to the buffer.
- * Returns an unsubscribe function. Used by the drawer to live-update its chip
- * count so users see errors arrive in real-time, regardless of whether the
- * widget was opened before or after the error fired.
- */
-export declare function subscribeToEvents(fn: () => void): () => void;
-//# sourceMappingURL=events.d.ts.map