Release tooling and one-shot CLI: three small inconsistencies seen while releasing and installing v0.41.49 #572

New issue

Closed

opened 2026-11-11 17:50:47 +01:00 by buildagent · 2 comments

buildagent commented

2026-11-11 17:50:47 +01:00

Member

Observed on 2026-11-11 while releasing v0.41.49 and verifying the installed binaries. None affects the shipped binaries (all four report 0.41.49 (a7ce9603)).

1. The release notes' Build: line names a package tag after a promotion run.
The promoted release says Build: pkg/de.h-dv.php/v0.1.6+2559. The promotion was a workflow_dispatch of release.yml on the tag v0.41.49; the package tag sits on the same commit, and git describe --tags picks it. v0.41.47 shows the same (Build: pkg/de.h-dv.javascript/v0.1.6+2505). The first, tag-pushed run printed Build: v0.41.49+2557.
Expected: the build line names the core tag the run was dispatched for.

2. install.sh --check reports "not installed" beside an existing installation.
As a non-root user with /usr/local not writable, sh install.sh --check answers prefix /home/<user>/.local/bin, installed (nothing at …/.local/bin/code-index), not installed, while code-index 0.41.48 is on PATH in /usr/local/bin. The same script run with sudo then reports installed 0.41.48 and updates it.
Expected: the check also reports a code-index found on PATH outside the chosen prefix, with its version, so "not installed" cannot be read as "no code-index on this machine".

3. code-index query with an invalid .code-index.toml prints no JSON document.
With a daemon serving the project and the config made invalid (for example enabled = ["php", "Ruby"]), code-index query search_symbols … exits 2 with an empty stdout. stderr carries the correct diagnostic (file, accepted form, suggestion), followed by error: the index server closed its output before answering. A long-lived MCP session answers the same situation with the structured refusal index_unavailable / invalid_configuration. After the file is repaired the next query answers normally, and the daemon stayed alive throughout.
Expected: the one-shot CLI prints the same structured refusal as one JSON document on stdout, so a script reading stdout gets the reason. Same family as #570 (one contract across CLI and MCP).

Observed on 2026-11-11 while releasing v0.41.49 and verifying the installed binaries. None affects the shipped binaries (all four report `0.41.49 (a7ce9603)`). **1. The release notes' `Build:` line names a package tag after a promotion run.** The promoted release says `Build: pkg/de.h-dv.php/v0.1.6+2559`. The promotion was a `workflow_dispatch` of `release.yml` on the tag `v0.41.49`; the package tag sits on the same commit, and `git describe --tags` picks it. v0.41.47 shows the same (`Build: pkg/de.h-dv.javascript/v0.1.6+2505`). The first, tag-pushed run printed `Build: v0.41.49+2557`. Expected: the build line names the core tag the run was dispatched for. **2. `install.sh --check` reports "not installed" beside an existing installation.** As a non-root user with `/usr/local` not writable, `sh install.sh --check` answers `prefix /home/<user>/.local/bin`, `installed (nothing at …/.local/bin/code-index)`, `not installed`, while `code-index 0.41.48` is on `PATH` in `/usr/local/bin`. The same script run with sudo then reports `installed 0.41.48` and updates it. Expected: the check also reports a `code-index` found on `PATH` outside the chosen prefix, with its version, so "not installed" cannot be read as "no code-index on this machine". **3. `code-index query` with an invalid `.code-index.toml` prints no JSON document.** With a daemon serving the project and the config made invalid (for example `enabled = ["php", "Ruby"]`), `code-index query search_symbols …` exits 2 with an empty stdout. stderr carries the correct diagnostic (file, accepted form, suggestion), followed by `error: the index server closed its output before answering`. A long-lived MCP session answers the same situation with the structured refusal `index_unavailable` / `invalid_configuration`. After the file is repaired the next query answers normally, and the daemon stayed alive throughout. Expected: the one-shot CLI prints the same structured refusal as one JSON document on stdout, so a script reading stdout gets the reason. Same family as #570 (one contract across CLI and MCP).

buildagent referenced this issue

2026-11-12 05:46:24 +01:00

v0.41.50: module evidence for qualified references, one argument contract, one extraction census #574