@launchsecure/launch-kit 0.0.27 → 0.0.28

package/scaffolds/ls-marketplace/plugins/ls/commands/standup.md

@@ -0,0 +1,177 @@
+---
+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.
+---
+
+# 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".
+
+## 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.
+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).
+
+## Gather
+
+Pull data from layered sources, in this order:
+
+### 1. Determine the window
+
+- **Primary**: `git log --reverse --pretty=format:'%h%x09%an%x09%ae%x09%s%n%b%n%x00' @{push}..HEAD`. The `@{push}` revspec resolves to where this branch was last pushed; the diff is commits ahead of upstream.
+- **Fallback 1**: if the primary returns empty OR `@{push}` errors with `unknown revision`, query the `launch-secure` MCP via `communication_read({ tag: "daily_update", limit: 1 })`. Take the most recent comment's `createdAt`; gather commits since then via `git log --since="<that timestamp>"`.
+- **Fallback 2**: if no prior `daily_update` exists either, use `git log --since="24 hours ago"`.
+
+Tell the user which window was used in one short line ("Using commits since last push (12 commits)" or "No commits since last push — falling back to commits since 2026-05-20 14:01 (last standup)").
+
+### 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 log --pretty=format:'%h %s' <window>` — short subject lines for quick scan.
+- 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
+
+This is the chart's job — do **not** group by file path string-matching. For each changed file (deduped from the diff stat):
+
+- 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
+
+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.
+
+If a file doesn't resolve in the chart (new file, non-TS, config), bucket it under "Misc" or by directory (`scripts/`, `docs/`, `.github/`).
+
+### 4. Audit pass (optional, skip if it slows things down)
+
+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.
+
+### 5. Blast radius for the biggest changes (deploy-safety signal)
+
+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").
+
+### 6. Work-item linkage
+
+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.
+
+### 7. 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`
+- A migration file under `prisma/migrations/` was added or `prisma/schema.prisma` changed
+- A deploy/publish was mentioned in commit subjects (regex: `\b(publish|release|deploy|bump)\b`)
+- A new bin or export was added to a package's `package.json`
+
+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):
+
+```
+Hey @everyone
+
+Pushed <N> commits to <branch> today. Highlights:
+
+→ <Theme 1>
+- <outcome bullet, not a commit message>
+- <outcome bullet>
+
+→ <Theme 2>
+- <outcome bullet>
+
+→ <Theme N>
+- <outcome bullet>
+
+----
+
+<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
+```
+
+**Strict format rules:**
+
+- `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.
+- `- <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.
+- `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.
+- 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.
+
+## Confirm
+
+Show the draft to the user verbatim in a code-fenced block (so they see plain-text formatting as-is), then ask **exactly**:
+
+> "Post this as a daily_update to LS Comm Hub? Reply `yes` to post, `edit` to revise, or `cancel` to abort."
+
+Responses:
+
+- **`yes`, `y`, `ok`, `post it`** — proceed to duplicate check + post.
+- **`edit`, `change <thing>`, free-form revisions** — apply the edits, regenerate the draft, re-show, re-ask.
+- **`cancel`, `no`, `nope`** — abort. Don't post. Don't keep partial state.
+
+Anything ambiguous → treat as "edit, what would you like changed?".
+
+## Duplicate check
+
+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`)
+- `createdAt` within the last 12 hours
+
+…then a manual daily_update already exists from today. Offer:
+
+> "A daily_update already exists from you today (posted at <time>, <preview-50-chars>). Choose: `replace` to update it (communication_update), `append` to post another, `cancel` to stop."
+
+- **replace** → call `mcp__launch-secure__communication_update({ id: "<existing-id>", content: <new-draft> })`. Preserve tags.
+- **append** → proceed to post.
+- **cancel** → abort.
+
+## Post
+
+Call `mcp__launch-secure__communication_write`:
+
+```
+{
+  resourceType: "comment",
+  content: "<the final draft, plain text>",
+  tags: addReleaseTag ? ["daily_update", "release"] : ["daily_update"]
+}
+```
+
+`org_slug` and `project_slug` are auto-supplied from the cred config via the MCP's headersHelper — do NOT pass them yourself.
+
+On success: report the comment ID and a friendly "posted to LS Comm Hub" line. If the response includes a URL field, surface it.
+
+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`:
+- 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).

package/scaffolds/recall-hook/scripts/ensure-recall.sh

@@ -0,0 +1,69 @@
+#!/usr/bin/env bash
+# Ensures the launch-recall watcher is running. Designed for the Claude Code
+# SessionStart hook (.claude/settings.json). Idempotent: silently no-ops if
+# recall isn't configured, logs OK if watcher is already alive, spawns a
+# detached watcher if it isn't.
+#
+# Portable across two layouts:
+#   - Dev: project has packages/cli/dist/server/recall-entry.js (e.g.
+#     launchsecure-v2 itself) → spawn via `node`.
+#   - Customer: project doesn't ship launch-kit → spawn via
+#     `npx -y -p @launchsecure/launch-kit launch-recall watch`. First run
+#     downloads from npm (slow); subsequent runs use the npx cache.
+#
+# Exits 0 in all cases — recall failing should never block Claude Code startup.
+
+set -u
+
+REPO_ROOT="${CLAUDE_PROJECT_DIR:-$(pwd)}"
+RECALL_DIR="$REPO_ROOT/.recall"
+PIDFILE="$RECALL_DIR/watch.pid"
+LOCAL_RECALL_BIN="$REPO_ROOT/packages/cli/dist/server/recall-entry.js"
+
+# No recall configured here — exit quietly. Hook is safe to ship in any repo;
+# it only acts when there's a shadow-git to protect.
+if [[ ! -d "$RECALL_DIR/repo.git" ]]; then
+  exit 0
+fi
+
+# Watcher already alive?
+if [[ -f "$PIDFILE" ]]; then
+  pid="$(cat "$PIDFILE" 2>/dev/null || true)"
+  if [[ -n "${pid:-}" ]] && kill -0 "$pid" 2>/dev/null; then
+    echo "[recall] watcher alive (pid $pid)" >&2
+    exit 0
+  fi
+fi
+
+# Pick spawn command. Prefer the local dev build (instant) over npx (slow on
+# first run because of the npm download).
+if [[ -f "$LOCAL_RECALL_BIN" ]]; then
+  SPAWN_CMD=(node "$LOCAL_RECALL_BIN" watch)
+  via="local dev build"
+else
+  SPAWN_CMD=(npx -y -p @launchsecure/launch-kit launch-recall watch)
+  via="npx (initial download may take a moment)"
+fi
+
+echo "[recall] starting watcher via $via" >&2
+
+# Spawn detached. nohup + redirected fds + & keeps the watcher alive past this
+# script's exit. disown removes it from the shell's job table.
+nohup "${SPAWN_CMD[@]}" >/dev/null 2>&1 &
+disown 2>/dev/null || true
+
+# Brief check — long enough for the local-dev path, not long enough to block
+# session start when npx is downloading.
+sleep 0.5
+
+if [[ -f "$PIDFILE" ]]; then
+  newpid="$(cat "$PIDFILE" 2>/dev/null || true)"
+  if [[ -n "${newpid:-}" ]] && kill -0 "$newpid" 2>/dev/null; then
+    echo "[recall] watcher started (pid $newpid)" >&2
+    exit 0
+  fi
+fi
+
+# Spawn is still in flight (likely npx download). Don't block session start.
+echo "[recall] watcher spawn initiated — check with /ls:show-mcp-status in a moment" >&2
+exit 0