Release/3.15.1#694
Conversation
|
Claude finished @bao-byterover's task in 2m 37s —— View job Claude PR Review — #694 Release/3.15.1
SummaryThis is a clean, narrowly-scoped release PR: a What's good
What's worth a follow-up
Correctness / security
Overall score: 4.5 / 5Solid release PR. Docked half a point only for the long-running lockfile-version drift that this release was a good opportunity to clear. |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| "knowledge-management" | ||
| ], | ||
| "version": "3.15.0", | ||
| "version": "3.15.1", |
There was a problem hiding this comment.
chore (non-blocking): package.json is now at 3.15.1, but package-lock.json still records "version": "3.11.0" at both the top-level and the root packages[""] entry. This drift has carried across the 3.12 → 3.15.1 releases. The published tarball uses package.json, so installs work, but lockfile audit/scan tools key off the lockfile version and will misreport.
Easiest fix during a release: run npm install --package-lock-only after bumping package.json so the lockfile re-syncs.
| ## [3.15.1] | ||
|
|
||
| ### Fixed | ||
| - **Review settings panel restored in `brv webui`.** The on/off toggle for review-before-changes (Configuration → Version Control) went missing in 3.15.0. It is back in the same spot, alongside Identity and Remotes. | ||
| - **`brv update` tidies up old versions.** Each upgrade used to leave previous CLI versions sitting in the plugin cache, slowly eating disk space. The cache now keeps only the version you just installed. |
There was a problem hiding this comment.
praise: Both entries are properly user-facing — they describe the symptom ("toggle went missing", "old versions sitting in the plugin cache slowly eating disk space") and the resolution in plain language, not implementation detail. Consistent with the project's existing CHANGELOG voice.
nitpick (non-blocking): None of the existing release headers carry a date, so the missing - YYYY-MM-DD on ## [3.15.1] is consistent — but adding ## [3.15.1] - 2026-05-22 here (and going forward) would let downstream tooling (Keep-a-Changelog parsers, release notes bots) reliably extract the release timeline. Worth a one-line convention shift the next time a release goes out.
|
|
||
| - `brv settings` (bare = list) / `brv settings get <key>` / `set <key> <value>` / `reset <key>` — user-configurable settings persisted at `<BRV_DATA_DIR>/settings.json`; changes apply after `brv restart` | ||
| - Categories: `concurrency`, `llm`, `task-history`. Initial keys: `agentPool.maxSize`, `agentPool.maxConcurrentTasksPerProject`, `taskHistory.maxEntries`. Descriptors in `server/core/domain/entities/settings.ts` reference `src/constants.ts` so a constant change updates the setting's default automatically | ||
| - Categories: `concurrency`, `llm`, `task-history`. Keys: `agentPool.maxSize`, `agentPool.maxConcurrentTasksPerProject`, `llm.iterationBudgetMs`, `llm.requestTimeoutMs`, `taskHistory.maxEntries`. Descriptors in `server/core/domain/entities/settings.ts` reference `src/constants.ts` so a constant change updates the setting's default automatically. Agent process consumes them via `agent/infra/settings/agent-settings-snapshot.ts` forwarded by `server/infra/daemon/agent-process.ts` |
There was a problem hiding this comment.
praise: Verified the referenced paths against the worktree — src/agent/infra/settings/agent-settings-snapshot.ts exists, and the new llm.iterationBudgetMs / llm.requestTimeoutMs keys are now called out alongside the existing concurrency/task-history keys. The added "Agent process consumes them via …" clause closes a real documentation gap (previously the settings doc only mentioned the daemon side).
The matching edit was correctly mirrored into AGENTS.md — these two files are kept in sync per the repo's shared-rules connector convention, and this PR honored that.
1 participant
No description provided.