Repository navigation
Release 1.6.0 #6
Description
What
1.6.0 is a minor bump, not a patch: lumen doctor, lumen show and the in-app degraded banner are new user-facing features, so shipping this under a patch number would understate it. This issue is the release checklist. It also carries a problem: two of the statements that will appear in the CHANGELOG and README are absolute claims with no check behind them, so the released wording may promise more than the code enforces.
Evidence
Shipping in 1.6.0, from the source tree:
- Release-build logging. The logger was previously registered only under
cfg!(debug_assertions), so every log call in a shipped binary went to a no-op sink. - The persisted hidden-icon preference is cleared and announced.
- Post-build tray visibility verification with a bounded re-check.
- No
?orexpectanywhere in startup. - The leak-versus-scope metric.
- A universal guard preventing any tool from returning more than the file it was asked about.
No counts, ratios or percentages were measured for this release, so none are stated here.
The last two items are universally quantified ("anywhere", "any tool") and nothing currently fails when they are violated. That is the weak point of this release, not a detail.
Release tooling present in the repo: scripts/release.sh, scripts/verify-install.sh, .github/workflows/verify-install.yml.
Acceptance criteria
- Every gate command below exits 0, with clippy emitting no warnings.
- A test fails if
?orexpectis reintroduced in startup — or the CHANGELOG/README wording is narrowed to what is actually checked. - A test asserts a tool asked about one file cannot return content from another file — or the "any tool" wording is narrowed.
- A release-profile binary writes log output (not a debug build).
- Clearing the hidden-icon preference produces a visible announcement.
- Tray re-check terminates after its bound rather than retrying indefinitely.
-
./scripts/verify-install.sh --expect 1.6.0exits 0. - The published-artifact workflow is green against the
v1.6.0tag. - This issue stays open until the two unverified claims are settled.
How to test
The local gate must be green before pushing. A red main ships broken versions.
cargo fmt --all --check
cargo clippy --workspace --all-targets --exclude Lumen -- -D warnings
cargo test -p lumen-core -p lumen-cli -p lumen-daemon -p lumen-mcp -p lumen-stats --all-targets
node --version # must be >= 22.22.3 (Angular 22's floor)
cd lumenator && pnpm install --frozen-lockfile && pnpm build && pnpm test && cd ..
bash lumenator/build-sidecar.sh # the Tauri crate's build script needs the sidecars
cargo clippy -p Lumen --all-targets -- -D warnings
./scripts/release.sh minor # requires main and a clean tree; tags v1.6.0
./scripts/verify-install.sh --expect 1.6.0The Tauri crate (Lumen) is excluded from the workspace clippy and test runs on purpose — its build script resolves the four externalBin sidecars, so it is checked separately after build-sidecar.sh.
Expect: cargo fmt prints nothing; both clippy runs finish with no warnings; cargo test reports zero failures; pnpm build and pnpm test exit 0; release.sh minor bumps 1.5.1 to 1.6.0 and produces the v1.6.0 tag; verify-install.sh reports the installed version as 1.6.0 and exits 0, and exits non-zero on any mismatch. After publishing, run the Verify install workflow via workflow_dispatch with tag: v1.6.0 so it checks the published artifacts, and confirm it passes.
Activity
fix(mcp): compress_logs never costs more than its log; settle #6 (#53)
HackPoint commentedon Oct 12, 2026
Settled by #53 (merged as 9e79bfd). 1.6.0 shipped on 2026-10-10, so the release steps in the checklist are history. What this issue was held open for, the two unverified claims, is now checked or narrowed:
?orexpectanywhere in startup"crates/lumen-core/tests/startup_scan.rsfails if a?or anexpectreturns to the.setupclosure or to a function it reaches by name (8 mutations of the real app files and manifests each fail it).unwrapis not claimed.compress_logswas outside the guard: 31 of 56 synthetic logs cost more than the log. It now returns the log itself when its reply would cost more. Corpus tests count the text each reply sent: 70 repo files x every request shape, 8 small files, 56 logs. The README,docs/efficiency.mdand the changelog say where the guard sits and what it does not check (error replies, repeat-read replies, the JSON-RPC envelope, non-UTF-8 files, files over 50,000 tokens).recall_fileranges that start after they endmax_level_*feature). That a release binary actually writesLumen.logis not checked at run time, and the wording says so. Not a blocker for 1.8.0.Closing. The run-time check of the release log is the one thing left; say if you want it as its own issue.