liteagents 3.5.0 → 3.7.0

package/packages/claude/skills/release/SKILL.md

@@ -126,19 +126,49 @@ confirmed in Phase 0.5.
   summarize, escalate. Do not weigh it yourself.
 - **All clean** → continue.
 
-## Phase 2 — Docs sweep
-Update what this feature actually changed, wherever those docs live in this
-project — match each file's existing format, touch nothing unrelated. Use
-`docs/index.md` when the project has one to find what exists.
-
-- **CHANGELOG.md** — new entry.
-- **README.md** — only if user-facing usage changed.
+## Phase 2 — Docs sweep (required — no skipping, no sampling)
+Update what this branch changed, wherever those docs live in this project —
+match each file's existing format, touch nothing unrelated. Use
+`docs/index.md` when the project has one to find what exists. **All three
+passes run on every release**; the size of the branch or the change never
+cuts one.
+
+1. **List every change.** Read `git log --format='%h %s%n%b'
+   origin/main..HEAD` — the bodies, not just the subjects — and the diff.
+   Write one line per user-visible change: feature, command, flag, behaviour,
+   fix, dependency bump. A subject is a summary; the body is the list, and a
+   sweep built from subjects drops whatever only a body mentions.
+2. **CHANGELOG.md** — a new entry holding every line from pass 1, each under
+   the heading the file already uses for its kind (Added / Changed / Fixed /
+   Security). A new capability is **Added** even when it shipped in a `fix:`
+   commit. Then check it back: every pass-1 line maps to an entry, and the
+   semver level in Phase 3 agrees with the headings (an Added entry means at
+   least minor).
+3. **Grep for stale text.** For every string the diff removed or replaced
+   that a reader might have copied — a command line, flag, file name, recipe,
+   env var, printed message — search the docs for the old form:
+   `grep -rnF "<old string>" --include='*.md' .` (past CHANGELOG entries are
+   history; leave them). Every other hit is stale **because of this branch** —
+   update it. "It was already stale before this branch" is a claim: prove it
+   with `git show $(git merge-base origin/main HEAD):<source path>`. If the
+   base code already disagreed with the doc, report it as out of scope;
+   otherwise it is yours to fix.
+
+Then judge each of these against the pass-1 list:
+- **README.md** — if user-facing usage changed.
 - **PRD** — the feature's entry / status.
 - **Guide / context docs** — the project's standing context.
 - **Findings / learnings** — where the project keeps them.
 - **Any other frequently-updated doc** this change makes stale.
 
-If a doc needs no change, **say so** rather than editing it for its own sake.
+Report **one row per doc**: file · changed / no change · the evidence (the
+grep or diff you ran). A "no change" with no evidence is a skip, and a skip
+fails this phase — it is not a pass. If a doc truly needs no change, say so
+with the evidence rather than editing it for its own sake.
+
+**The sweep is the worker's job, start to finish.** The orchestrator checks
+the report; it does not redo or patch the sweep. A gap it finds goes back to
+the worker, and it counts as a failed sweep, not a small follow-up.
 
 ## Phase 3 — Cut (local only)
 1. **Version bump** — pick the semver level from the change (patch / minor /

package/packages/claude/skills/security/SKILL.md

@@ -23,9 +23,12 @@ These show up in nearly every quickly-built app regardless of stack:
 
 1. **Secrets in the repo.** Tokens / API keys / `.env` files committed to
    tracked files or anywhere in git history. Verify `.env` is gitignored and
-   only a value-less `.env.example` is tracked; scan history (`git log -p`,
-   `git grep`) for leaked keys. Secrets must load from env / a secret store at
-   runtime — never hardcoded, never logged.
+   only a value-less `.env.example` is tracked. Scan ALL history, every
+   branch — a range or target never narrows this — with:
+   `git log --all -p | grep -nE '(sk-[A-Za-z0-9_-]{16,}|AKIA[0-9A-Z]{16}|gh[pousr]_[A-Za-z0-9]{30,}|xox[abprs]-[A-Za-z0-9-]{10,}|AIza[0-9A-Za-z_-]{35}|-----BEGIN [A-Z ]*PRIVATE KEY)'`
+   plus any key shape specific to this project's providers. Report each hit
+   as real or a known test fixture. Secrets must load from env / a secret
+   store at runtime — never hardcoded, never logged.
 2. **Data-access authorization (tenant isolation).** Every record read or
    written must be scoped to the requesting principal — via DB-level rules
    (RLS / row policies) and/or application-layer ownership checks. Flag any

package/packages/droid/commands/branch-review.md

@@ -97,6 +97,20 @@ was actually read rather than assuming.
 you owe an answer on — take both from the file, never from the orchestrator's
 recollection, for the same reason `/release` does. Then:
 
+- **First, check the record belongs to this branch.** There is one record file
+  per repo, not one per branch. Validate `<that sha>` first with
+  `git rev-parse --verify <that sha>` — a value that fails this (e.g. a
+  corrupted or hand-edited record, or one starting with `-`, which git would
+  otherwise parse as an option) is a malformed record; treat it exactly as
+  **No file** below. If it validates, and its `branch:` line differs from the
+  current branch, or `git merge-base --is-ancestor <that sha> HEAD` exits
+  non-zero, the record describes a different or rewritten history — treat it
+  exactly as **No file** below and review the whole branch. Skipping this
+  resolves `<that sha>..HEAD` against a merged, renamed, or rebased sha, which
+  is not a subset of this branch but a range that never existed. Check both:
+  the branch name catches a switch, the ancestry check catches a rebase or
+  squash under the same name. Otherwise:
+
 - **`sha:` ≠ HEAD** → this is a re-review. Target the range
   `<that sha>..HEAD`. Stage 1 reads only the commits since, and stage 3
   re-verifies each recorded blocker as fixed, unfixed, or dismissed with a
@@ -123,6 +137,13 @@ governs **stage 1 only**:
 - **high / max** — broader coverage; uncertain findings are allowed, but each
   must be labelled uncertain.
 
+**No shortcuts.** The level decides how many findings you report, never which
+checks you run. Every check this file calls required runs at every level —
+never cut or sample one "given the effort level", the branch size, or time. If
+a check truly cannot run, write `NOT RUN: <reason>` for it on the `checks:`
+line of the report and the review record. That is a visible gap, not a
+blocker and not a pass.
+
 **Stage 2 (security) always runs full, at every level.** A shallow security
 pass is worse than none — it reads as coverage while missing the class of bug
 that costs the most.
@@ -172,7 +193,10 @@ carries the reproduction.
   location outside the repo; the tree must still be clean at exit. A test that
   passes against both the buggy and the fixed source is a tautology and proves
   nothing. Flag every one you find, and say so explicitly when the tests are
-  the branch's only evidence for its claims.
+  the branch's only evidence for its claims. **Required, every test file the
+  diff adds or changes — one red run per file is enough; checking a sample of
+  the files is a skip.** Count them as `fail-first N/M files` on the
+  `checks:` line.
 - **Maintainability.** Complexity, naming, duplication — only when material.
 
 ## Stage 2 — Security (always full)
@@ -187,7 +211,10 @@ If `security.md` cannot be found, run what you can from the list above and
 
 This stage is repo- and history-scoped, not diff-scoped: a key committed forty
 commits ago, an unbounded route the diff never touched, or a missing row
-policy on a table the new code now reads are all in scope.
+policy on a table the new code now reads are all in scope. **The review range
+never narrows this stage** — even when you were handed `main..HEAD`, the
+secrets scan covers every commit on every branch (`security.md` item 1 has
+the command).
 
 ## Stage 3 — Verify (adversarial)
 Findings are claims, not facts. **Try to break each one, not to confirm it** —
@@ -275,7 +302,10 @@ uncertain).
 
 Then a coverage line: stage 1 at level `<level>`, stage 2 full, stage 3 —
 each `ran ✓/✗` with its evidence. A stage you did not actually run is a **✗**, never an
-assumed pass.
+assumed pass. Then a `checks:` line for the two checks most often cut short:
+`fail-first N/M files` and `secrets-history all-branches` (or `NOT RUN:
+<reason>` for either). An N below M, or a NOT RUN, is reported as-is — it
+does not block.
 
 **Write the review record** to `.factory/remember/last-review.md`, overwriting
 it. `/release` reads this file; a SHA that lives only in a chat message is
@@ -294,6 +324,7 @@ level: <low | medium | high | max>
 verdict: <ready | blocked>
 date: <YYYY-MM-DD>
 coverage: stage1 <ran|NOT RUN>, stage2 <ran|NOT RUN>, stage3 <ran|NOT RUN>
+checks: fail-first <N/M files|NOT RUN: reason>, secrets-history <all-branches|NOT RUN: reason>
 blockers:
 - <file:line> · <one-sentence claim, no scenario, no suggested fix>
 ```