@launchsecure/launch-kit 0.0.31 → 0.0.33

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

@@ -0,0 +1,274 @@
+---
+description: End-to-end ship flow — runs /kit:deploy-check, prints the exact commit list, pushes the named branch only after explicit confirmation, then appends a structured entry to .launchsecure/ship-log.ndjson describing what shipped. Pushing to a deploy-tracked branch (default master) triggers Vercel automatically; this skill never calls `vercel deploy` directly. No LS Comm Hub post — the local log is the source of truth and can be republished later by a separate skill.
+---
+
+# /kit:ship
+
+Compose `/kit:deploy-check` + `git push` + local ship-log append into one gated workflow. The skill is the human checklist for "I'm shipping now" — same checks a careful human would run, encoded so they cannot be skipped or reordered.
+
+The ship log at `.launchsecure/ship-log.ndjson` is the durable record of what shipped, when, and by whom. Each successful ship appends one JSON object. A future skill (`/kit:ship-publish` or similar) can tail this log and emit an internal activity update / Comm Hub post / changelog page — but that's a separate concern. This skill writes the log; it does not publish.
+
+Hard rule from project memory: **never push commits the user didn't explicitly name**, and **pushing to master = auto-deploy** — so this skill always asks per-action before pushing, even when invoked with arguments. There is no `--yes-i-mean-it` flag.
+
+Parse `$ARGUMENTS`:
+
+- (empty) — full flow on the current branch → its upstream (resolved via `git rev-parse --abbrev-ref @{u}` or, missing that, `origin/<current-branch>`).
+- **--to=&lt;branch&gt;** — push to a different remote branch (e.g. `--to=staging-mirror`). The skill never creates a new remote branch silently — if the target doesn't exist on origin, surface that and ask.
+- **--dry-run** — run deploy-check + build the ship-log entry preview, but do NOT push and do NOT append to the log. Useful for "what would shipping look like right now?".
+- **--note=&lt;text&gt;** — free-form human note attached to the log entry's `note` field. Useful for hotfix context, rollout caveats, or named reviewer.
+- **--skip-check=&lt;list&gt;** — forwarded verbatim to `/kit:deploy-check --skip=<list>`. Surface skipped checks in the final report; do not let `--skip-check=build` slip through silently.
+- **--quick** — forwarded to deploy-check (skips the slow `build` step). Refuse if the target is a deploy-tracked branch (`master` or whatever the repo's default is) — for prod, build must run.
+
+Examples:
+
+- `/kit:ship` → check, confirm, push current branch to its upstream, append ship-log entry.
+- `/kit:ship --dry-run` → check + preview the log entry only; no push, no log write.
+- `/kit:ship --to=master` from `implementation` → cross-branch merge-and-deploy flow (see "Cross-branch ship" below).
+- `/kit:ship --note="hotfix for feedback widget 500s"` → push + log entry with the note attached.
+
+## Preflight
+
+1. `git rev-parse --is-inside-work-tree` — abort if not a git repo.
+2. Resolve current branch and the **deploy-target branch**:
+   - If `--to=` given, use it.
+   - Else `git rev-parse --abbrev-ref @{u}` (the branch's tracked upstream).
+   - Else fall back to `origin/<current>` and warn that no upstream is set.
+3. Resolve the **deploy-tracked branch list** for "is this a prod push?" gating:
+   - Read `git symbolic-ref refs/remotes/origin/HEAD --short` (strip `origin/`) → that's the repo's default; treat as deploy-tracked.
+   - Always treat `master` and `main` as deploy-tracked if they exist on origin.
+   - If the resolved target is in this list, set `IS_PROD_PUSH=true`. Used to escalate confirmations and refuse `--quick` / `--skip-check=build`.
+4. Print the scope upfront — the user should never wonder what's about to happen:
+   ```
+   ship: <current-branch> → <target-branch>   (prod: yes|no)
+   ```
+5. Stash check — if `git status --porcelain` shows uncommitted changes, refuse with `✗ working tree not clean — commit, stash, or discard before shipping`. Shipping with dirty state is never the right move; the deploy-check skill is lenient about it because it's read-only, this skill is not.
+
+## Step 1 — Gate (run /kit:deploy-check)
+
+Invoke `/kit:deploy-check` against the resolved target. Forward `--quick` / `--skip-check=` / `--target=`. Do NOT re-implement any check here — single source of truth lives in `deploy-check/SKILL.md`.
+
+Verdict handling:
+
+- **NO-GO** → abort the ship. Print the failing checks verbatim from deploy-check. Tell the user what to fix. Do not offer to "force ship".
+- **GO WITH CAVEATS** → surface the warnings, then ask:
+  > "deploy-check returned GO WITH CAVEATS (<N> warnings listed above). Continue with ship? Reply `yes` to continue, `cancel` to abort."
+- **GO** → continue silently to step 2.
+
+Hard rules:
+
+- If `IS_PROD_PUSH=true` and the user passed `--quick` or `--skip-check=build`, refuse before running deploy-check: `✗ --quick / --skip-check=build are not allowed for prod pushes. Re-run without them.`
+- If deploy-check's `migration_safety` row is anything other than ✓, treat as NO-GO regardless of overall verdict. Migration corruption incidents are why the project has the three-layer migration rule in CLAUDE.md — this skill enforces it.
+
+## Step 2 — Show the exact push payload
+
+Print, verbatim, what's about to be pushed. This is the user's last chance to recognise an unexpected commit (per project memory: `push X` never includes other local commits).
+
+```
+About to push <current-branch> → origin/<target-branch>:
+
+  <sha>  <subject>     <author-relative-time>
+  <sha>  <subject>     <author-relative-time>
+  …
+
+<N> commits, <M> files changed (<+adds>/<-dels>)
+```
+
+Generated from:
+
+- `git log --pretty=format:'  %h  %s   (%ar, %an)' origin/<target>..HEAD`
+- `git diff --shortstat origin/<target>...HEAD`
+
+If the list is empty → abort: `nothing to push — local branch is at or behind origin/<target>`.
+
+If any commit author is not the current `git config user.email`, surface a `⚠ <N> commits authored by someone else (<emails>)` line — common in shared branches but worth flagging once.
+
+## Step 3 — Migration backup gate
+
+If `git diff origin/<target>...HEAD --name-only -- prisma/migrations/` returns any files, surface:
+
+```
+⚠ This push includes <N> new migration(s):
+  - prisma/migrations/<dir>/migration.sql
+  …
+
+Backup story:
+  - CI: .github/workflows/backup-on-migration.yml runs pg_dump server-side once the migration lands on <target-branch>.
+  - Local: if you have already applied locally, you've used scripts/migrate-with-backup.sh (per CLAUDE.md). If not, the CI workflow is the safety net.
+```
+
+Then ask:
+
+> "Migration push detected. Type `understood` to continue, or `cancel` to abort."
+
+This is a deliberate friction point — typing a word is more honest than `y`. Do not accept `yes` here; require `understood`.
+
+## Step 4 — Push confirmation
+
+Ask **exactly**:
+
+- If `IS_PROD_PUSH=false`:
+  > "Push <N> commits to origin/<target-branch>? Reply `yes` to push, `cancel` to abort."
+- If `IS_PROD_PUSH=true`:
+  > "Push <N> commits to origin/<target-branch>. This is a prod-tracked branch — Vercel will deploy automatically. Reply `ship it` to push, `cancel` to abort."
+
+Accept exactly `yes` / `ship it` (case-insensitive). Anything else → treat as cancel. **Never** accept silence, `ok`, `sure`, free-form approval. If `--dry-run`, skip this step entirely.
+
+On confirm: `git push origin <current-branch>:<target-branch>`. Stream stdout. If the push fails (non-fast-forward, hook reject, auth) — surface the error verbatim, do not retry, do not `--force`.
+
+After a successful push to a deploy-tracked branch, surface the Vercel deployment lookup hint:
+
+```
+Pushed. Vercel deploy will pick up the latest commit on <target-branch>.
+  → check status: `vercel ls --prod` or watch the Vercel dashboard
+  (do NOT run `vercel deploy` from here — that bypasses the GitHub→Vercel flow and double-deploys)
+```
+
+## Step 5 — Append ship-log entry
+
+After a successful push, append exactly one JSON line to `.launchsecure/ship-log.ndjson`. This is the durable record of the ship event — the source of truth a future `/kit:ship-publish` (or any reader) consumes to emit activity feeds, changelogs, or Comm Hub posts.
+
+If `--dry-run`, build the entry and show it in a fenced block but do NOT write it. If the push failed in step 4, do NOT write the entry (the log only records successful ships).
+
+### File location & format
+
+- Path: `.launchsecure/ship-log.ndjson` (sibling of `.launchsecure/graphs/`, `.launchsecure/beacon-*.ndjson`).
+- Format: NDJSON — one JSON object per line, append-only, never rewrite or compact.
+- If the file does not exist, create it. Do NOT add a header line; readers should tolerate empty file = zero ship events.
+- Ensure `.launchsecure/ship-log.ndjson` is gitignored — on first run, check `.gitignore` for `.launchsecure/ship-log.ndjson` or a covering pattern (`.launchsecure/*.ndjson`); if absent, surface a one-line warning suggesting the user add it. Do NOT silently edit `.gitignore` — that's a separate user decision per project memory on extending vs adding things.
+
+### Entry schema
+
+Every entry conforms to schema `v: 1`. Forward-compatible reader rule: ignore unknown fields, never break on missing optional fields.
+
+```json
+{
+  "v": 1,
+  "shipId": "<ulid or `${ts}-${shortSha}`>",
+  "ts": "2026-05-29T12:45:00.000Z",
+  "branch": "implementation",
+  "target": "master",
+  "isProdPush": true,
+  "author": { "name": "Prajyot", "email": "prajyot@automatewith.us" },
+  "commits": [
+    { "sha": "abc1234", "subject": "feat(ship): add ship skill", "author": "Prajyot", "ts": "2026-05-29T12:30:00.000Z" }
+  ],
+  "stats": { "files": 3, "insertions": 187, "deletions": 0 },
+  "migrations": ["prisma/migrations/2026_05_29_add_ship_log/migration.sql"],
+  "envVarsAdded": ["FEED_BACKEND_URL"],
+  "deployCheck": {
+    "verdict": "GO",
+    "warnings": ["lint: 12 warnings"],
+    "skipped": []
+  },
+  "themes": [
+    { "scope": "ship", "outcomes": ["End-to-end ship skill with deploy-check gate and append-only ship log"] }
+  ],
+  "summary": "Shipped 1 commit to master — ship skill scaffold",
+  "note": "<--note value, or null>",
+  "pushedAt": "2026-05-29T12:45:00.000Z",
+  "vercelDeployHint": "auto-triggered on push to master"
+}
+```
+
+Field sources:
+
+- `shipId` — generate `${pushedAt-as-yyyymmdd-hhmmss}-${shortSha-of-HEAD}` for human-greppable IDs. ULID is fine if a generator is available.
+- `ts` / `pushedAt` — current ISO timestamp at the moment the entry is written (just after `git push` succeeds).
+- `branch` / `target` / `isProdPush` — from preflight (step 1).
+- `author` — `git config user.name` + `git config user.email`.
+- `commits` — `git log --pretty=format:'%H%x09%s%x09%an%x09%aI' origin/<target>..HEAD` (use the pre-push range — these are the commits that just landed).
+- `stats` — `git diff --shortstat origin/<target>...<sha>` where `<sha>` is the new HEAD.
+- `migrations` — `git diff --name-only origin/<target>...HEAD -- prisma/migrations/` (if step 3 fired, surface those exact paths; else empty array).
+- `envVarsAdded` — pulled from deploy-check's `env_coverage` row, parsed from its `detail`. If deploy-check was skipped or didn't run that check, `[]`.
+- `deployCheck.verdict` / `warnings` / `skipped` — from the deploy-check report in step 1.
+- `themes` — group commits by conventional-commit scope (same default rule as `/kit:standup` step 3). Each theme: `{ scope, outcomes: [<outcome-bullets translated from commit subjects>] }`. Outcomes are short product-facing sentences, NOT raw subject lines. If commits lack scopes and there are ≥20 changed files across ≥5 dirs, escalate to launch-chart module grouping (same rule as standup step 3); otherwise bucket into `{scope: "misc", outcomes: […]}`.
+- `summary` — one-line human-readable. Format: `Shipped <N> commit(s) to <target>${migrations ? " — includes migration" : ""}${themes ? " — " + topTheme : ""}`.
+- `note` — verbatim `--note=` value, or `null` if absent.
+- `vercelDeployHint` — `"auto-triggered on push to <target>"` if `isProdPush`, else `"no auto-deploy (target is not deploy-tracked)"`.
+
+### Preview + confirm
+
+After step 4's push succeeds, build the entry and show it pretty-printed in a fenced code block:
+
+```
+About to append to .launchsecure/ship-log.ndjson:
+
+{
+  "v": 1,
+  "shipId": "20260529-124500-abc1234",
+  …
+}
+
+Append? Reply `yes` to write, `edit summary` to tweak the summary or themes, `skip` to ship without logging, or `cancel` to abort the append.
+```
+
+- `yes` / `y` → append the entry as a single minified line (`JSON.stringify(entry) + "\n"`) using `>> .launchsecure/ship-log.ndjson`. Confirm with `appended shipId=<id>`.
+- `edit summary` → ask what to change (summary text, theme grouping, note), redraft the entry, re-show, re-ask.
+- `skip` → do not write. Print the entry once more so the user can manually save it elsewhere if they want. Ship is still considered successful — the push landed.
+- `cancel` → do not write. Same as `skip` but no echo. **Do not** attempt to revert the push — surface clearly: `Push already landed on origin/<target>; cancel only stops the log append.`
+
+### Atomicity
+
+Append must be atomic — partial writes corrupt the NDJSON file. Use:
+
+```
+echo "<minified-json>" >> .launchsecure/ship-log.ndjson
+```
+
+NOT `cat ... > tmp && mv tmp ...` (rewrite is wrong for an append-only log). NOT multi-line JSON. One line, one ship, one append.
+
+If the write fails (disk full, permission), surface the entry verbatim in chat so the user can save it manually, and exit non-zero. Do NOT retry.
+
+## Cross-branch ship (--to=master from a feature branch)
+
+When the user runs `/kit:ship --to=master` from a non-master branch, the flow is **push the current branch's commits onto master**, which is a fast-forward / merge, not a normal push. Handle this carefully:
+
+1. After deploy-check passes, before step 2, verify the current branch is ahead of `origin/master` (`git rev-list --left-right --count origin/master...HEAD` → left=behind, right=ahead). If behind, abort: `✗ <current> is behind origin/master by <N>; rebase or merge master first`.
+2. The push command becomes `git push origin <current-branch>:master`. Make sure step 2's "About to push" preamble shows this asymmetric refspec so the user sees it.
+3. On non-fast-forward reject from origin, do NOT suggest `--force`. Surface and stop.
+
+## Constraints
+
+- **Never auto-push and auto-log in one breath.** Always two explicit confirmations (step 4 push, step 5 append). The `--dry-run` flag exists instead of bundling.
+- **Never call `vercel deploy` CLI.** Deploys come from Vercel's GitHub integration on push to deploy-tracked branches. Calling the CLI double-deploys and bypasses the gate.
+- **Never `git push --force` / `--force-with-lease`.** If a push fails, the user investigates.
+- **Never `git push <branch>` without an explicit refspec.** Always `<local-branch>:<remote-branch>` so the destination is unambiguous in the printed command (and in shell history).
+- **Never bypass migration_safety.** A ✓ on the deploy-check migration_safety row is the gate; anything else is NO-GO even if the overall verdict isn't.
+- **Single source of truth for checks.** Do not duplicate `/kit:deploy-check` logic inline; invoke it.
+- **Append-only log.** Never edit, delete, or rewrite past entries in `ship-log.ndjson`. Corrections happen via a new entry referencing the previous `shipId` (e.g. `correctionOf: "<prev shipId>"` — readers handle the merge).
+- **Log only successful ships.** If `git push` fails, do NOT write an entry. The log records what actually landed on the remote, not what was attempted.
+- **No publishing from this skill.** This skill writes the log; it does NOT post to LS Comm Hub, does NOT update activity feeds, does NOT trigger webhooks. Those are downstream consumers (future `/kit:ship-publish` or a server-side tailer).
+- **Honest about deploy state.** This skill ends when the push completes and the log entry lands. It does NOT wait for Vercel to finish building, does NOT verify the prod URL is up, does NOT roll back. If the user needs deploy-monitoring, point them at `vercel ls --prod` or the Vercel dashboard.
+- **Dry-run is truly dry.** `--dry-run` must NOT call `git push`, must NOT write to `ship-log.ndjson`. The preview is shown in chat only.
+
+## Idempotency
+
+Re-running `/kit:ship` after a successful run:
+
+- Step 2 will show "nothing to push" if the previous push landed cleanly — the natural no-op. No new log entry results.
+- Each successful ship is a separate line in `ship-log.ndjson`. There is no per-day or per-branch coalescing — that's a reader's job. If a hotfix ships 10 minutes after a feature, both entries exist independently.
+- The preview is never persisted before confirmation; cancelling at any step leaves no partial entry behind.
+
+## Reading the log
+
+For ad-hoc inspection while the publisher skill doesn't exist yet:
+
+```
+# last ship
+tail -n 1 .launchsecure/ship-log.ndjson | jq
+
+# ships to master in the last 7 days
+jq -c 'select(.target == "master" and (.ts | fromdateiso8601) > (now - 7*86400))' .launchsecure/ship-log.ndjson
+
+# count ships per day
+jq -r '.ts[:10]' .launchsecure/ship-log.ndjson | sort | uniq -c
+```
+
+These are documented for the user, not for this skill — `/kit:ship` itself never reads back the log.
+
+## Notes for the assistant
+
+- The user has explicit project-memory rules against unauthorised pushes and dumb reverts. Treat every confirmation as load-bearing — don't paraphrase the prompt wording, don't accept ambiguous approval.
+- "Ship" is the user's verb for "I want this in production." If the target isn't actually deploy-tracked, the skill should still work but should say so clearly in the scope line (step 4 phrasing changes).
+- The ship log is the durable artifact. Future skills will read from it — keep the schema stable, additive only. Bump `v:` when you make a breaking schema change and update this file's schema block in the same commit.
+- This skill assumes `/kit:deploy-check` exists. If missing (older launch-kit install), surface that as a preflight error pointing to `npx @launchsecure/launch-kit init`. No dependency on `/kit:standup` anymore — the log replaces the Comm Hub post.

package/scaffolds/statusline/statusline-mcp.sh

@@ -4,11 +4,17 @@
 # Composes into any existing statusline via the launch-kit wrapper.
 #
 # Usage:
-#   statusline-mcp.sh                       # all known chips (recall, chart, deck, council)
+#   statusline-mcp.sh                       # all known chips (recall, chart, deck, council, secure)
 #   statusline-mcp.sh --show=recall,chart   # only the listed chips
 #   statusline-mcp.sh --compact             # collapse to `mcp <up>/<total>`
 #                                             green when all up, red if any down
 #
+# `secure` differs from the others: recall/chart/deck/council are local
+# daemons probed via a pidfile/lockfile/freshness file, but launch-secure is
+# the hosted MCP. Its chip is a reachability probe (curl) against the active
+# profile's serverUrl, cached for SECURE_CACHE_TTL seconds so the statusline
+# never blocks on the network on every render.
+#
 # Project root is inferred from $LK_STATUSLINE_CWD (set by the wrapper) or
 # $PWD by walking up until a `.launchsecure` dir is found. Silent exit when
 # the cwd is not inside a launchsecure project.
@@ -22,7 +28,12 @@ for arg in "$@"; do
     --compact) compact=1 ;;
   esac
 done
-[ -z "$show" ] && show="recall,chart,deck,council"
+[ -z "$show" ] && show="recall,chart,deck,council,secure"
+
+# TTL for the cached launch-secure reachability probe (seconds). The statusline
+# re-renders far too often to curl on every paint; one live probe per window is
+# plenty for an "is the host up" signal.
+SECURE_CACHE_TTL=30
 
 GREEN=$'\033[32m'
 ORANGE=$'\033[33m'
@@ -173,6 +184,74 @@ chip_council() {
   _state="orange"; _display="${ORANGE}council${RESET}"
 }
 
+# Pull the active profile's serverUrl out of .launch-secure.cred.config without
+# jq (the chip script stays coreutils-only). Handles both shapes the cred file
+# can take — profiled ({active, profiles:{<name>:{serverUrl}}}) and flat
+# ({serverUrl}) — mirroring the .mcp.json headersHelper's own fallback.
+extract_secure_url() {
+  local cred="$1" active
+  active=$(grep -o '"active"[[:space:]]*:[[:space:]]*"[^"]*"' "$cred" 2>/dev/null | head -1 | sed 's/.*"\([^"]*\)".*/\1/')
+  awk -v prof="$active" '
+    function opens(s){ return gsub(/{/,"&",s) }
+    function closes(s){ return gsub(/}/,"&",s) }
+    BEGIN { inprof = (prof == "") ? 1 : 0; depth = 0 }
+    {
+      if (prof != "" && !inprof) {
+        if (index($0, "\"" prof "\"") > 0 && index($0, "{") > 0) { inprof = 1; depth = opens($0) - closes($0) }
+        next
+      }
+      if (match($0, /"serverUrl"[[:space:]]*:[[:space:]]*"[^"]*"/)) {
+        s = substr($0, RSTART, RLENGTH)
+        sub(/.*:[[:space:]]*"/, "", s); sub(/".*/, "", s)
+        print s; exit
+      }
+      if (prof != "") { depth += opens($0) - closes($0); if (depth <= 0) exit }
+    }
+  ' "$cred" 2>/dev/null
+}
+
+_render_secure() {
+  # $1 = state (green|red|unknown), $2 = label (active profile name)
+  case "$1" in
+    green)   _state="green";  _display="${GREEN}secure(${2})${RESET}" ;;
+    unknown) _state="orange"; _display="${ORANGE}secure(${2})${RESET}" ;;
+    *)       _state="red";    _display="${RED}secure(${2})${RESET}" ;;
+  esac
+}
+
+chip_secure() {
+  local cred="$PROJECT_ROOT/.launch-secure.cred.config"
+  if [ ! -f "$cred" ]; then _state="orange"; _display="${ORANGE}secure(?)${RESET}"; return; fi
+
+  local active url label
+  active=$(grep -o '"active"[[:space:]]*:[[:space:]]*"[^"]*"' "$cred" 2>/dev/null | head -1 | sed 's/.*"\([^"]*\)".*/\1/')
+  url=$(extract_secure_url "$cred")
+  if [ -z "$url" ]; then _state="orange"; _display="${ORANGE}secure(?)${RESET}"; return; fi
+  label="${active:-secure}"
+
+  # Cache keyed on the URL so a course-switch (prod↔local) invalidates instantly.
+  local cache="$PROJECT_ROOT/.launchsecure/.statusline-secure.cache"
+  local now; now=$(date +%s)
+  if [ -f "$cache" ]; then
+    local c_ts c_url c_state
+    IFS='|' read -r c_ts c_url c_state < "$cache" 2>/dev/null || true
+    if [ -n "${c_ts:-}" ] && [ "${c_url:-}" = "$url" ] && [ $((now - c_ts)) -lt "$SECURE_CACHE_TTL" ]; then
+      _render_secure "$c_state" "$label"; return
+    fi
+  fi
+
+  # Live probe. Any HTTP status — including 401/403/404/405 — means the host is
+  # reachable; only a transport failure (curl writes 000) counts as down. No
+  # curl on PATH → unknown (orange), never a false red.
+  local state="unknown" code
+  if command -v curl >/dev/null 2>&1; then
+    code=$(curl -s -o /dev/null -m 2 -w '%{http_code}' "$url" 2>/dev/null || echo 000)
+    if [ -n "$code" ] && [ "$code" != "000" ]; then state="green"; else state="red"; fi
+  fi
+  printf '%s|%s|%s\n' "$now" "$url" "$state" > "$cache" 2>/dev/null || true
+  _render_secure "$state" "$label"
+}
+
 show_list=$(echo "$show" | tr ',' ' ')
 total=0
 up=0
@@ -183,6 +262,7 @@ for d in $show_list; do
     chart)  chip_chart ;;
     deck)   chip_deck ;;
     council) chip_council ;;
+    secure) chip_secure ;;
     *) continue ;;
   esac
   total=$((total + 1))

package/scaffolds/statusline/statusline-wrapper.sh

@@ -40,7 +40,14 @@ if [ -x "$HOME/.launchsecure/statusline-mcp.sh" ]; then
   fi
 fi
 
-sep=$'\033[2m | \033[0m'
+# Layout: by default the chips go on their OWN line below the user's original
+# statusline (Claude Code renders each stdout newline as a new row). Set
+# LK_STATUSLINE_INLINE=1 to keep the old single-line ` | `-joined layout.
+if [ "${LK_STATUSLINE_INLINE:-0}" = "1" ]; then
+  sep=$'\033[2m | \033[0m'
+else
+  sep=$'\n'
+fi
 if [ -n "$original_output" ] && [ -n "$chips" ]; then
   printf '%s%s%s' "$original_output" "$sep" "$chips"
 elif [ -n "$original_output" ]; then