@codacy/verity-cli 0.34.4 → 0.34.5-experimental.2aa3da8

package/CHANGELOG.md

@@ -64,30 +64,6 @@ installs are untouched.
   which is the ordinary case for someone whose first Verity install *is* the
   plugin.
 
-## [0.34.4] — 2026-10-26
-
-**A formal finding is checked before it blocks a push, and formal looks for security bugs.**
-
-### 🛡️ Formal verification
-
-- **A reproduced counterexample is checked before it blocks.** A replay proves
-  that a failing order runs against stubs of your code. It does not prove that
-  the order can happen in production. Verity now investigates each reproduced
-  counterexample with the read-only tools of the agent review. It follows the
-  code to its entry point and looks for what prevents the order: a lock, a
-  unique constraint, a transaction, an idempotency key. Two independent checks
-  run, and the more cautious answer governs. A finding is lowered only when
-  every quote of the check appears in your code: PREVENTED and ARTIFACT show as
-  checked and never block, and REAL-LOW is reported without blocking. A check
-  that does not finish leaves the finding as it was.
-  `VERITY_FORMAL_VERIFY=off` turns the check off.
-- **Formal looks for security bugs.** The ranker gives each target a lens
-  (security or reliability) and up to three concrete hypotheses. A security
-  target is modelled from the attacker's side: isolation between tenants,
-  revocation, flow binding, event order, and check-then-use.
-- **Generation sees the push.** The lines that your push changed are marked in
-  the code that formal models, so it looks first for a bug that the change made.
-
 ## [0.34.3] — 2026-10-21
 
 **`verity usage` shows the reviews of each member of your org.**

package/README.md

@@ -10,75 +10,103 @@ cd your-project
 verity init
 ```
 
-`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.
+`verity init` is the whole setup. It asks two things, and every other choice is
+a default that it states in one line:
 
-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.
+```
+┌  Verity · acme/payments
+◇  Looked at your repository
+◇  Verity reviews every turn, every commit and every push
+│  To change it, run verity config moments, or just ask Claude.
+◇  Hooks here: this project's .claude/settings.json
+◇  Signed in as you@example.com                         ← question 1
+◇  Profile sent · no source code                        ← question 2
+◇  6 rules for this repository · from 500 commits and 2 docs · 14s
+◇  Standard v1 saved
+└  Ready in 41s.
+```
+
+1. **Sign in.** Enter opens GitHub's device page in your browser with the code
+   already on your clipboard. If the Verity GitHub App cannot see the repository,
+   init opens the install page and waits for it. Press `s` to skip: then only the
+   local security scan runs, because AI review needs sign-in.
+2. **Send a repo profile?** Only asked when you are signed in and the repository
+   has no Standard yet. The profile holds languages, frameworks and dependency
+   names, folder names, commit subjects with the paths they changed, and
+   CLAUDE.md and AGENTS.md without their code blocks. This step sends no source
+   code, diffs or author names, and Verity does not store the profile. Read it
+   first: init writes it to `.verity/repo-profile.json`, and `v` shows it. The
+   service writes review rules for this repository from it. Later, each review
+   sends the code that changed.
+
+When it ends, start a new Claude Code session: Claude Code reads hooks when a
+session starts. Under the plugin, Verity reviews from your next turn.
 
 ### 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 |
+| `.verity/standard.yaml` already exists | keeps it, and shares it if the service has none |
+| The service has a Standard for this repo | uses it, without asking: the team's Standard wins |
+| Neither, and you send the profile | the service writes project rules into v1 |
+| Neither, and you do not (or you are not signed in) | builds one from Verity's catalogue for your languages |
 
-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.
+The catalogue Standard is a lookup, not a guess: languages and frameworks are
+counted and read from your manifests. Add project rules to it later with
+`verity standard generate`, or edit `.verity/standard.yaml` and run
+`verity standard push`.
 
-### 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]
-```
+### Defaults, and how to change them
 
-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.
+| Default | Change it with |
+|---|---|
+| Verity reviews every turn, every commit and every push | `verity config moments turn,commit,push` (any of them, or `none`), or ask Claude |
+| Static analysis is the Trivy security scan (its database downloads in the background at init) | nothing to configure |
+| Formal verification at push is on for a new project; Lean 4 downloads in the background | `verity config formal off`, or `VERITY_NO_LEAN=1` before init |
+| Cost & usage telemetry is off | `verity telemetry install` |
 
-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.
+A re-run keeps what you chose before: the recorded moments, a kept Standard, and
+anything you set with `verity config`.
 
 | Flag | Use |
 |------|-----|
-| `--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 |
+| `--yes` | Ask nothing (CI, scripts, agents). Sign-in is skipped unless you are signed in already, and the profile is sent only with `--profile send`. |
+| `--profile send\|skip` | Answer the profile question without being asked. `/verity:init` asks in the Claude Code session and passes it down |
+| `--no-adopt` | Don't use the Standard the service holds for this repo: build a new one. Skips the request entirely |
+| `--moments <list>` | Set the moments for this run instead of the default: `stop,pre-commit,pre-push`, or `none` |
+| `--telemetry on\|off` | Turn cost & usage telemetry on or off (init does not ask) |
+| `--untrack-memory` · `--untrack-state` | Stop tracking the knowledge graph, or committed Verity state, in git (init does not ask) |
 | `--force` | Overwrite the installed skills even when they differ |
-| `--moments <list>` · `--intensity <level>` · `--telemetry on\|off` | Answer that question without being asked. `/verity:init` asks in the Claude Code session and passes these down |
-| `--untrack-memory` · `--untrack-state` | Answer yes to the matching "stop tracking it in git?" question without being asked |
+| `--no-setup` · `--intensity` | Accepted and ignored, for old scripts and plugin skills |
+
+Press Ctrl-C at any point: every step can run again, so nothing is left
+half-written. `verity setup` is an alias for the same command. Run
+`verity doctor` any time to see prerequisites, the hook wiring, and what is
+still missing.
 
-Run `verity doctor` any time to see prerequisites, which phase is done, the hook
-wiring, and what is still missing.
+### What init reports
+
+Once you are signed in, init sends one small event per step to the Verity
+service, so that we can see where setup stops. Each event holds the step, how it
+ended (for the profile step: sent, declined or not asked), and the time since
+init started. A random id links the steps of one run,
+and the events are linked to your account. Init sends no repository name, no
+paths and no machine id.
+
+Before you sign in, nothing is sent. The steps wait in `~/.verity/init-trace.json`
+and go with your next signed-in run. A run that is never followed by a sign-in is
+never sent, and its entry is dropped after 30 days. Set `DO_NOT_TRACK=1` to turn
+all of this off. It is also off in CI.
 
 ### Output
 
-Human output goes to **stderr**; stdout carries only data (`--json`). Colour, the
-wordmark, and the spinners appear only when stderr is a terminal, and honour
-`NO_COLOR` and `TERM=dumb`; `FORCE_COLOR=1` forces them on for a pipe that renders
-ANSI. In CI, in a pipe, or when init runs inside a Claude Code session you get the
-same information as plain lines — no art, no animation, no escape sequences.
+Human output goes to **stderr**; stdout carries only data (`--json`). The
+wordmark, the colours and the motion appear only when stderr is a terminal. In
+CI, in a pipe, or when init runs inside a Claude Code session you get the same
+results as plain lines: no art, no motion, no escape sequences, and no question
+that nobody can answer. `NO_COLOR` and `TERM=dumb` keep the motion and drop the
+colour; `VERITY_REDUCED_MOTION=1` keeps the colour and drops the motion;
+`VERITY_NO_BROWSER=1` stops sign-in from opening a browser.
 
 ### Permission denied?
 
@@ -143,10 +171,9 @@ No re-setup needed: your token, Standard, and run history all carry over.
 | Command | Description |
 |---------|-------------|
 | **Core** | |
-| `verity init` | Set up Verity in this project, end to end — questions, wiring, and the Standard (alias: `verity setup`) |
+| `verity init` | Set up Verity in this project: two questions (sign in, send a repo profile), the hooks, 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 standard synthesize` | Derive the Standard from this codebase — no model, no network (`--push`, `--force`). Static analysis is Trivy only and needs no config |
 | `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) |
@@ -167,7 +194,8 @@ No re-setup needed: your token, Standard, and run history all carry over.
 | `verity logout --others` | Sign out every OTHER machine (e.g. a lost laptop) |
 | `verity logout --all` | Sign out everywhere, including here |
 | `verity hooks install` | Wire Claude Code hooks |
-| `verity hooks install --moments stop,pre-commit,pre-push` | Change WHEN Verity reviews (what `verity init` asks for) |
+| `verity config moments turn,commit,push` | Change WHEN Verity reviews: each turn, each commit, each push (all three by default; `none` turns them off) |
+| `verity hooks install --moments stop,pre-commit,pre-push` | The same, in the hook names (kept for scripts) |
 | `verity standard push` | Upload project Standard |
 | **Knowledge** | |
 | `verity reflect` | Trigger knowledge extraction for current task |
@@ -177,8 +205,8 @@ No re-setup needed: your token, Standard, and run history all carry over.
 | `verity memory untrack` | Stop committing `.verity/memory/` — the graph stays on disk and leaves your diffs |
 | `verity memory track` | Commit the graph on purpose, and record that so nothing offers to change it |
 | **Formal verification** | |
-| `verity config formal push` | Opt this checkout in: at push, one risky changed function may get a Lean model, checked and replayed (see below) |
-| `verity config formal off` | Opt out again |
+| `verity config formal push` | Turn it on for this checkout: at push, one risky changed function may get a Lean model, checked and replayed (see below). On by default for a new project |
+| `verity config formal off` | Turn it off |
 | `verity lean status` / `install` / `remove` | The managed Lean 4 toolchain the models are checked with (≈800 MB download, 2.7 GB on disk) |
 | `verity prove candidates [paths]` | Rank the riskiest code from git history and shape signals, no model |
 | `verity prove auto [files]` | Run the push-time phase by hand on the commits ahead of upstream |
@@ -195,7 +223,7 @@ No re-setup needed: your token, Standard, and run history all carry over.
 
 | Skill | Description |
 |-------|-------------|
-| `/verity-setup` | Synthesizes the Standard + analysis config (the half of setup that needs a model; `verity init` launches it) |
+| `/verity-setup` | Proposes project-specific `custom_patterns` from the code (optional; `verity init` already derives the Standard) |
 | `/verity-analyze` | On-demand analysis |
 | `/verity-status` | Project health dashboard |
 | `/verity-feedback` | Feedback (general + per-finding) |
@@ -221,9 +249,17 @@ or plain code stops in under a second with a named reason. Counterexamples can
 only be replayed for **TypeScript, JavaScript and Python**; other languages stop
 before any model is paid for.
 
+For a new project, `verity init` turns this on and starts the Lean 4 download
+in the background (≈800 MB, 2.7 GB on disk; `verity lean status` shows the
+progress). Until Lean is ready, a push reports `formal: skipped (no-toolchain:
+Lean installing, 63%)` and the gate decision does not change. Init does not
+start the download in CI (unless `VERITY_LEAN=1`), with `VERITY_NO_LEAN=1`,
+with formal off, or with less than 3.75 GB free. A re-run of init never turns
+formal on.
+
 ```bash
-verity config formal push     # opt in (verity init asks on an interactive terminal)
-verity lean install           # the toolchain, once per machine
+verity config formal off      # turn it off for this checkout
+verity lean install           # the toolchain, if the background download did not run
 verity prove auto             # try it by hand on what is ahead of upstream
 ```