@lumoai/cli 1.31.0 → 1.32.0

package/assets/skill/references/criteria.md

@@ -64,6 +64,13 @@ must track the size of the work — it is not a fixed ritual:
     HUMAN** — the server rejects checkpointer-less MACHINE criteria rather
     than silently rewriting them. Don't invent a fake checkpointer to keep it
     MACHINE.
+  - **Jest-by-name checkpointers must go through the zero-match guard.** A
+    bare `npx jest -t '<name>'` exits 0 even when the pattern matches **no**
+    test — rename or delete the test and the checkpointer silently fake-PASSes
+    (same trap class as the BSD-grep `-P` incident, LUM-401). Write
+    `npx tsx scripts/jest-t.ts '<exact test name>' [test file path]` instead:
+    it fails unless ≥1 matching test ran and passed. The optional path scopes
+    the run to one file (much faster than name-filtering the whole suite).
 - `evidenceRequired: true` marks criteria whose verdict must point at proof
   (a MACHINE PASS always requires evidence regardless of this flag).
 

package/assets/skill/references/docs.md

@@ -2,6 +2,34 @@
 
 ## Document Management
 
+### Content channels: prefer stdin / `--content`
+
+`doc create` / `doc update` / `doc patch` / `doc append` all take the body from one of three mutually-exclusive channels. **For agent write-back, prefer stdin or `--content`** — pipe the markdown you already hold in memory, or pass it inline:
+
+```bash
+printf '%s' "$body" | lumo doc update cmd_xxx                                 # stdin — best for multi-line / generated content
+lumo doc append cmd_xxx --section "F 待办队列" --content "- [ ] 评估 XYZ 论文"   # --content — short inline edits
+```
+
+`--file` is the **fallback for content that already lives in an authoritative file on disk** (e.g. a repo-tracked `docs/live-docs/<file>.md` source you are editing). It is **not** the default channel: `--file` is sandboxed — the CLI rejects any path outside the current project directory or matching the sensitive-file denylist (`.env*`, keys, `credentials`, …), with no override. So feeding it generated content forces you to first write a scratch file _inside the repo_ just to pass it — an extra step that is the real-world friction that gets `--file` rejected. Pipe via stdin instead and skip the temp file; reach for `--file` only when the file _is_ the source of truth you're editing.
+
+### Markdown tables: keep them compact (no alignment padding)
+
+When you author or edit a markdown doc that contains tables (live-docs, registers, reports), write the cells **compact — one space around each pipe, no column-alignment padding**:
+
+```
+| col | meaning |
+| --- | --- |
+| a | first |
+```
+
+not the aligned form (`| col   | meaning |` padded so columns line up). Two reasons, both about local editability:
+
+- **prettier re-pads tables.** A compact table gets re-aligned and a padded one churns the diff on every prettier run — so repo-tracked live-doc sources under `docs/live-docs/` are in `.prettierignore` to stay byte-stable (see the live-docs README).
+- **the Edit tool's exact-match fails on padding.** Incremental edits match on exact cell text; alignment whitespace makes that match fragile (measured to fail). Compact cells edit reliably.
+
+This is a pure authoring convention — the server stores your markdown **byte-for-byte** (`sourceMarkdown`), so `doc show --raw` and `doc diff` stay byte-exact (LUM-408); there is **no** server-side table normalization to lean on. The structure guard (LUM-410) compares _rendered_ structure and is whitespace-insensitive, so compactness buys local editability, not a verify pass.
+
 ### `lumo doc create [title] [flags]` — create a new document
 
 Use this when the user wants to write a new document from the terminal. Title is positional and optional. When omitted, the doc title defaults to empty (server renders as "Untitled" via i18n).

package/assets/skill/references/worktree.md

@@ -10,9 +10,11 @@ there); `list` is read-only and runnable from anywhere.
 
 Creates `.worktrees/<LUM-N>[-slug]` on branch `lumo/<LUM-N>[-slug]`, branched off
 `origin/main` (after a fetch), and symlinks its `node_modules` to the main
-checkout so jest/tsc work immediately. With no slug, the dir and branch use the
-bare `LUM-N` form. Prints next-step guidance plus the two gotchas it can't fix
-for you (shared prisma client, jest cwd).
+checkout so jest/tsc work immediately. In the same scaffold step it copies the
+main checkout's `.husky/_` hooks shim into the worktree so git hooks actually
+fire there (see below). With no slug, the dir and branch use the bare `LUM-N`
+form. Prints next-step guidance plus the two gotchas it can't fix for you
+(shared prisma client, jest cwd).
 
 ```bash
 lumo worktree add LUM-267 worktree-scaffold   # → .worktrees/LUM-267-worktree-scaffold
@@ -36,6 +38,19 @@ do `generate + tsc` atomically once at the end.
 in first) — `cli/` has no jest config, and running from the main checkout hits
 the `cli/package.json` haste collision and silently runs the wrong tests.
 
+**The husky hooks it copies in:** husky owns git hooks via
+`core.hooksPath = .husky/_`, a relative path git resolves against each
+worktree's own root. That `_` shim dir is **untracked** (husky regenerates it on
+the main checkout's `npm install`/`prepare`), so a fresh worktree would lack it
+and git would **silently skip every hook** — pre-commit (lint-staged) and
+commit-msg (LUM-405 drift-check) included. Since this repo has no GitHub CI,
+husky is the only deterministic quality gate, so `add` copies `.husky/_` into the
+new worktree (copy, not symlink — the shim is tiny and the hooks it invokes
+resolve relative to the worktree). If the main checkout itself has no `.husky/_`
+(husky never installed there), `add` prints a warning telling you to run
+`npm install` in the main checkout to regenerate it, rather than skipping
+silently.
+
 **Never run `npm install` / `npm ci` inside a worktree.** The worktree shares
 the main checkout's `node_modules` via a symlink; npm does not respect the link
 — it deletes it and reifies a full standalone `node_modules` (thousands of

package/dist/cli/src/commands/worktree-add.js

@@ -96,6 +96,23 @@ async function worktreeAdd(rawId, slug, opts) {
     else {
         console.log('Warning: main checkout has no node_modules; run `npm install` there, then symlink manually');
     }
+    // husky owns git hooks via `core.hooksPath = .husky/_` (a relative path git
+    // resolves against each worktree's root). That `_` shim dir is untracked
+    // (generated by husky on the main checkout's `npm install`/`prepare`), so a
+    // fresh worktree lacks it and git SILENTLY skips every hook — pre-commit
+    // (lint-staged) and commit-msg (LUM-405 drift-check) included. This repo has
+    // no CI, so husky is the only deterministic gate; copy the shim in so hooks
+    // fire. Copy (not symlink) is the stable choice: the shim is tiny, rarely
+    // changes, and the hooks it invokes resolve relative to the worktree.
+    const srcHusky = path.join(root, '.husky', '_');
+    if (fs.existsSync(srcHusky)) {
+        fs.cpSync(srcHusky, path.join(dir, '.husky', '_'), { recursive: true });
+        console.log('  git hooks:     husky shim copied (pre-commit + commit-msg active)');
+    }
+    else {
+        console.log('Warning: main checkout has no .husky/_ shim; git hooks will NOT run in this worktree.');
+        console.log('          Run `npm install` in the main checkout to (re)generate husky, then re-run `lumo worktree add`.');
+    }
     printGuidance(dir, branch);
     if (opts.verify) {
         console.log('Running baseline jest …');

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lumoai/cli",
-  "version": "1.31.0",
+  "version": "1.32.0",
   "description": "Lumo CLI — manage tasks and sessions from the terminal",
   "license": "MIT",
   "author": "cli@uselumo.ai",