@codacy/verity-cli 0.31.3 → 0.32.0-experimental.5e53cb9

package/CHANGELOG.md

@@ -24,6 +24,16 @@ installs and updates it for you.
   plugin is present it owns the hooks, and the settings.json copy stands down.
   `verity init` detects the plugin and removes the duplicate wiring.
 
+### 🚪 A project that was never set up is left alone
+
+Every hook now asks the same question the same way. `verity analyze` used to run
+in a project that had never seen `verity init`, create `.verity/` there, and then —
+with no baseline to compare against — review nothing. It now stands down like the
+other hooks always have, so installing Verity no longer scatters state through
+directories you merely opened. On the first session in such a project, Claude is
+told once that the gate is off here and can offer `/verity:setup` (or `verity init`
+on an npm install). Works correctly from linked git worktrees.
+
 ### ⚙️ Git-moment gating moved into the project
 
 `verity guard` now reads `.verity/config.json` instead of taking its moments from
@@ -32,6 +42,148 @@ default gates nothing** — set it with `verity config git-moments commit,push`,
 answer the question in `verity init`. An explicit `--on` still wins, so existing
 installs are untouched.
 
+Linked git worktrees inherit the setting from the main checkout: `.verity/` is
+gitignored, so a fresh `git worktree add` had no config of its own and the guard
+there gated nothing while `verity hooks check` said "wired but gating nothing".
+A worktree's own `.verity/config.json`, when present, still wins — including an
+explicit `none` — and `hooks check` names the file it inherited from.
+
+### 🎯 Setup finishes in one command
+
+- **`verity init` now derives the Standard itself.** When the service has nothing
+  for this repository, the CLI reads the codebase — languages counted, frameworks
+  read from the manifests (including nested ones, so a monorepo works),
+  architecture, build system, test framework — and assembles
+  `.verity/standard.yaml`, `.codacy/codacy.config.json`, Verity's own ESLint
+  config and `VERITY.md`. Then it pushes them. No Claude Code session, no model
+  turn, about two seconds, and it works offline.
+- **This closes a real hole.** Without a Standard, `analyze` answers
+  `400 STANDARD_NOT_FOUND` — so a user who ran `verity init`, started working and
+  never ran `/verity-setup` got an error on every agent turn and static-only
+  findings, in a project init had just called set up.
+- **The service still has first refusal.** If this repository already has a
+  Standard it is offered and adopted exactly as before; derivation is strictly
+  what happens when there is nothing to adopt. A local `standard.yaml` is never
+  overwritten without `--force`.
+- **An adopted Standard with no analysis config now gets one**, derived from the
+  Standard's own declared languages and mode — filling the gap without
+  re-authoring the team's rules as a competing version.
+- **New: `verity standard synthesize`** (`--intensity`, `--force`, `--push`) — the
+  same derivation on demand.
+- **`--config-only` rewrites just the analysis config** from the Standard already
+  in place. Existing projects need it: a stale config is common, and the only
+  other way to rewrite one was `--force`, which also replaces the Standard —
+  deleting hand-written `custom_patterns` to fix a file that was not the problem.
+- `verity doctor`'s advice is a command now, not "open Claude Code".
+
+**What is NOT derived:** `custom_patterns` stays empty. Project-specific rules are
+the one part of synthesis that reads for intent rather than for facts, and
+plausible-sounding rules invented from a dependency list would be enforced on
+every turn without anyone having agreed to them. `/verity-setup` remains for
+exactly that, and a later pass will propose them server-side.
+
+**The catalogue is re-derived, and an audit found more than two lists wrong.**
+Checking every curated list against the installed adapters: ESLint9 (25) and
+shellcheck (14) were already exact; **Ruff** (20) needed the adapter's slug,
+**Bandit** (10) and **Hadolint** (8) were missing their tool prefix — all 38 are
+now written as the adapter spells them. **PMD7's 12 cannot be fixed
+mechanically**: they are bare rule names and the adapter's are
+category-qualified, and the suffix is ambiguous across languages
+(`UnusedLocalVariable` exists under both `_apex_` and `_java_`), so picking one
+would enable a rule that can never fire. That is recorded in the catalogue the way
+Semgrep's gap already was, and the CLI drops PMD7 rather than configuring it.
+
+**A pinned slug still survives a rename.** Full spellings are right for a model
+copying from the catalogue, but a slug is the adapter's prose and changes between
+versions — so an id also resolves by its stable head (`Ruff_F401`), and a pinned
+long form that stops matching is not silently dropped.
+
+**Your analysis config heals itself on upgrade.** `verity init` now validates an
+existing config's ids and re-derives it from your Standard when the validator says
+they no longer resolve — and only then: a config that cannot be checked (no
+analysis adapter on the machine, which is an ordinary state since that install is
+allowed to fail) is reported as unverified and left exactly alone, never rewritten
+on a guess — the Standard is never touched, because it may carry hand-written
+`custom_patterns` and it is not the file with the problem. `verity doctor` reports
+the same state read-only (`⚠ ids do not resolve`) so it is visible without running
+anything. This is the path that matters for existing projects: an id that matches
+nothing disables its whole tool while reporting zero issues.
+
+**Carried into code, and now tested.** The analysis-config knowledge used to live
+in the skill's markdown for a model to follow: `patterns: []` means "all 2,900
+rules" rather than "none"; a mistyped pattern id disables a tool while reporting
+zero issues; ESLint must not be pointed at the project's own config or Verity's
+rule list degrades into a filter over it (VRT-108); Semgrep's ids are deliberately
+not derived yet, so the tool is dropped rather than configured empty. Every one of
+those is now an assertion.
+
+### ⌨️ The setup questions answer to arrow keys
+
+- **`verity init` no longer asks you to type a number.** Analysis intensity and
+  the review moments are arrow-key lists: `↑↓` to move, `space` to toggle a
+  moment, `enter` to confirm — with the recommended answer already under the
+  cursor and the default set already ticked, so **Enter alone still gives exactly
+  what it gave before**.
+- **Digits still work.** This prompt used to be "type a number", and muscle memory
+  should not be punished for an interface improvement — a digit moves the cursor
+  rather than confirming, so it composes with the arrows instead of being a
+  second, hidden way to answer. `j`/`k` move too.
+- **An empty moment selection is refused, not accepted.** Unticking everything and
+  pressing Enter says so instead of installing a review tool that reviews nothing
+  — the same invariant the typed prompt held by falling back.
+- **Three rungs of degradation, same default at each.** Arrow keys on a real
+  terminal; the typed number prompt when the terminal cannot do raw mode; the
+  default when there is no terminal at all or stdin ends. An interface improvement
+  must not become a new way for a setup to get stuck — CI, pipes and agent Bash
+  calls behave exactly as before.
+- **The terminal is restored on every exit,** including Ctrl+C, which restores
+  before exiting: raw mode left on outlives the process and makes the user's next
+  shell prompt unusable.
+
+
+### 🤝 Joining a project that already has a Standard
+
+- **`verity init` now offers the Standard the service already holds** for this
+  repository, instead of asking a model to invent a second one. Everyone after the
+  first person on a project — a teammate cloning the repo, the same person on
+  another machine, a CI box — gets the team's actual configuration
+  (`standard.yaml`, the analysis config, `.verityignore`, `VERITY.md`) written
+  straight to disk, and the model phase is skipped entirely.
+- **This is a correctness fix as much as a speed one.** `verity standard push`
+  auto-versions, so a re-synthesis does not produce a private copy — it produces
+  v4, and v4 is what the team is held to from then on.
+- **Nothing about it can block a setup.** No token, offline, a 404, a service that
+  errors: every one of those falls through to the regular flow. An unreliable
+  answer is never reported as "no Standard stored" — that would offer a fresh
+  synthesis over one the team already agreed.
+- Unattended runs (`--yes`, CI) adopt without asking, for the same reason: a CI
+  box quietly authoring a new version of the team's Standard is not an outcome
+  anyone would choose on purpose.
+- **`--no-adopt` opts out**, for a script that wants a fresh synthesis on purpose.
+  It skips the request as well as the write: asking a question whose answer is
+  discarded is a network call the user declined, and in a locked-down CI it is one
+  that can fail loudly for no reason.
+- **Declining is remembered per VERSION, never as a mute.** Say no and init stops
+  asking about *that* Standard — and offers the next one, because a new version is
+  new information. A boolean "never again" would have been the familiar
+  silent-forever failure: decline on Monday meaning to synthesize later, forget,
+  and every later run stays quiet while the project has no local config at all.
+
+### 🔧 Fixed
+
+- **An upgrade no longer removes the gates you chose.** `.verity/setup.json` only
+  exists from this release, so every project configured before it had no recorded
+  answer — including everyone who picked commit/push gates through the old
+  `/verity-setup`. The first upgraded `verity init` fell back to the shipped
+  default and reconciled those gates away, turning Stop back on. What you chose is
+  still legible in `.claude/settings.json`, so init reads it.
+- `verity doctor` names the artifact that is actually missing instead of telling
+  you to run a phase that will decline: with a Standard adopted and no analysis
+  config, `/verity-setup` would have answered "already configured".
+- The setup skill learned the same case — Standard present, analysis config
+  missing — and writes only the config rather than re-synthesizing the Standard.
+
+
 **Setup is one command.** `verity init` and `/verity-setup` were two half-flows
 that overlapped — and the overlap was not harmless: init wired the Stop hook,
 then the skill reconciled the hooks to a selection it asked for afterwards,
@@ -107,6 +259,51 @@ with one entry point.
   terminal (Ctrl+D, a pty that ends) falls back to the default instead of
   crashing init between copying the skills and wiring the hooks.
 
+### 🔒 Fixed — four ways the gate could be off while reporting itself on
+
+- **`git add x && git commit` was never reviewed.** A Claude Code hook runs
+  *before* the command, so the index it read had not had the `add` applied:
+  no files, and the gate's "nothing staged" exit — a silent allow, with no
+  trace that a commit had gone unreviewed. It is the shape an agent writes by
+  default, so it was most of the pre-commit gate's coverage. The gate now works
+  out what the command will stage, using git's own pathspec matching, and
+  handles `git commit -a`. Where it cannot — a pathspec the shell expands,
+  `git add -p` — it says so and lets the commit through **loudly** rather than
+  reviewing a set it guessed at.
+- **Uninstalling the Claude Code plugin left projects with no gate at all.**
+  Whether the plugin owned a project's hooks was decided by whether its install
+  directory existed — and that directory survives an uninstall. Every project
+  the plugin had ever run in went on standing its own hooks down for a plugin
+  that was gone. Ownership now comes from Claude Code's install registry, and
+  `verity init` clears the stale marker.
+- **`verity init` now says which mode it is in before it acts on it** — the
+  plugin's hooks or this project's own — with the install it found and
+  `--no-plugin` to overrule it. It does two opposite things depending on that
+  answer, and it used to make the choice silently.
+- **A plugin installed from a local marketplace is recognised too.** Claude Code
+  runs a marketplace served from a *directory* out of that directory while
+  recording the cache copy it made, so the two paths disagree and a live,
+  gating install read as unverified — every reporter then said "no analysis
+  moment is active" about a project the plugin was gating on every turn.
+- **A repository can no longer switch the gate off by shipping a file.**
+  Ownership was claimed by `.verity/.plugin-active`, which is a file inside the
+  project. One naming any directory that happened to exist disabled every hook
+  in that project. An install Claude Code cannot vouch for is now ignored.
+- **`verity status` and `verity doctor` agree with `verity hooks check`.** Under
+  the plugin both used to report "Stop: off" and tell you to install hooks that
+  were firing on every turn. All three read one answer now, and it is correct
+  from a subdirectory too.
+- **A commit gate on a linked worktree gates what the main checkout gates.**
+  `.verity/config.json` is machine-local, so every `git worktree add` started
+  with no moments and reviewed nothing.
+- **A verdict the client does not understand is no longer rendered as a pass.**
+  An absent or unrecognised gate decision — a truncated response, a proxy error
+  page — reached the "✓ PASS" line. It is reported as unreviewed.
+- **`verity hooks install --moments <typo>` no longer removes every gate.**
+  Unrecognised moments were dropped, so a misspelling reconciled to nothing and
+  reported success. It is an error now; `--moments none` turns them off on
+  purpose.
+
 ## [0.31.3] — 2026-09-03
 
 **After a rebase, Verity reviewed the wrong code.** When a branch was rebased

package/README.md

@@ -10,10 +10,52 @@ cd your-project
 verity init
 ```
 
-`verity init` is the whole setup. It asks how deeply to review and when
-(on stop / before commit / before push), wires everything, offers the optional
-GitHub login — then launches Claude Code to finish the half that needs a model:
-reading your codebase and synthesizing the Standard (`/verity-setup`).
+`verity init` is the whole setup, and it finishes on its own — no second tool, no
+model turn. It asks how deeply to review and when (on stop / before commit /
+before push) with arrow-key lists — `↑↓` to move, `space` to toggle, `enter` to
+confirm, and Enter alone takes the recommended answers — wires everything, offers
+the optional GitHub login, and then gets this project a Standard: **the one your
+team already has**, or one **derived from your codebase** if there isn't one yet.
+
+When it's done the gate is live on your next Claude Code session. `/verity-setup`
+is no longer part of setup; it is there when you want a model to propose
+project-specific rules.
+
+### Where the Standard comes from
+
+| Situation | What init does |
+|---|---|
+| The service has a Standard for this repo | offers it, and adopting writes it locally (see below) |
+| It doesn't, or you declined, or you're offline | **derives one from your codebase** and pushes it when signed in |
+| `.verity/standard.yaml` already exists | leaves it alone |
+
+The derivation is a lookup, not a guess: languages and frameworks are counted and
+read from your manifests, and the rules come from Verity's research-backed
+patterns reference — the same catalogue the setup skill uses. The one thing it
+does not invent is **project-specific patterns** ("every route under `api/` uses
+the auth middleware"); `custom_patterns` stays empty until a model proposes them
+or you write them by hand.
+
+### Joining a project that already uses Verity
+
+A Standard belongs to the project, not to your machine. So once you are signed in,
+init asks the service whether this repository already has one:
+
+```
+This repository already has a Standard on Verity: version 3, pushed by claude-code
+on 2026-08-12 · with analysis config and .verityignore
+Use the existing Standard? [Y/n]
+```
+
+Say yes and it writes `.verity/standard.yaml`, `.codacy/codacy.config.json`,
+`.verityignore` and `VERITY.md` straight from the service — no model phase, and no
+second version of your team's Standard (`verity standard push` auto-versions, so a
+fresh synthesis would become the version everyone is held to). Say no and it stops asking about
+that version — and offers the next one, since a new version is new information.
+With no Standard stored yet, the regular flow runs.
+`--no-adopt` opts out of the whole check, including the request. Offline, signed out, or a service
+that cannot answer: also the regular flow — setup has never needed the network and
+still doesn't.
 
 If Claude Code isn't on your PATH, or you're already inside a session, init prints
 the one command to run instead. `verity setup` is an alias for the same command.
@@ -22,6 +64,7 @@ the one command to run instead. `verity setup` is an alias for the same command.
 |------|-----|
 | `--yes` | Take the recommended answer for every question — no prompts at all (CI, scripts, agents). Includes the GitHub login, whose unattended answer is **skip**: the project stays local-only until you run `verity login`. |
 | `--no-setup` | Stop after the deterministic phase; don't launch Claude Code |
+| `--no-adopt` | Don't offer the Standard the service already holds for this repo — synthesize a fresh one. Skips the request entirely |
 | `--force` | Overwrite the installed skills even when they differ |
 
 Run `verity doctor` any time to see prerequisites, which phase is done, the hook
@@ -72,8 +115,10 @@ No re-setup needed: your token, Standard, and run history all carry over.
 | Command | Description |
 |---------|-------------|
 | **Core** | |
-| `verity init` | Set up Verity in this project — asks the setup questions, then hands off to `/verity-setup` (alias: `verity setup`) |
+| `verity init` | Set up Verity in this project, end to end — questions, wiring, and the Standard (alias: `verity setup`) |
 | `verity doctor` | Prerequisites, setup phase, hook wiring, and what is still missing (`--json` for the machine-readable report) |
+| `verity standard synthesize` | Derive the Standard + analysis config from this codebase — no model, no network (`--push`, `--force`) |
+| `verity standard synthesize --config-only` | Rewrite only the analysis config, from the Standard already here — the fix for a stale one |
 | `verity analyze` | Run analysis on changed files (stop hook) |
 | `verity analyze --mode <mode>` | Force analysis mode (standard/plan/debug/skip) |
 | `verity review --files <paths>` | On-demand analysis (advisory) |