v0.5.70

conclave status with no id answers differently in this release. If you drive conclave from
a script, read the first section.

status with no id prefers the run that has not ended

It used to mean the newest session by start time, finished or not. It now means the newest
session that has not ended, falling back to the newest of all when every one has ended.

The case this was wrong for is the one the README's own recipe is written for: a run blocked on a
permission prompt while a newer run has ended — a second run that refused to start, a quick run
beside a long one. status answered with the ended run's record, whose blocked is empty, so

WHO=$(conclave status --json | jq -r .blocked.participant)
echo "/allow $WHO" > ctl

read the string null and the driver wrote /allow null. An unanswered prompt is simply
re-asked, which is the failure the paragraph above that snippet exists to prevent. conclave sessions listed both runs correctly the whole time — the information was on disk and status
was choosing against it.

The skip is now disclosed, because "no id means the most recent" is how this command has been
read since it existed. When a newer ended session is passed over, --json carries
skippedEndedSession with its id and the human form prints a note: line naming it. When
nothing was passed over there is no key and no line, so the presence of it is the signal.

Two details worth knowing if you script against this:

• An abandoned run — one whose record still says running while its process is gone — counts
  as not-ended and is chosen. That is deliberate: it is the run an operator most needs
  surfaced, and status already exits non-zero for it, so a script gating on the exit code still
  gates. This is NOT the rule events --follow uses, which skips abandoned runs because
  following one would end at its first look. status reports rather than follows.
• Naming an id is unchanged. conclave status <id> describes that session, ended or not,
  with no note. resolveSession's refusal of an ambiguous prefix is untouched, and so is
  sessionLock, which asks whether the tree is busy rather than what to show you.

conclave now records WHICH kimi its claims are about

kimi-cli is archived upstream — "[Archived] Legacy Python Kimi CLI, no longer maintained. Use
Kimi Code CLI instead." — and its successor, npm @moonshot-ai/kimi-code, ships a kimi
command of its own. The command name had stopped identifying the program.

It is not a version drift, it is a different program. Measured against 2.3.2 and written up
in spikes/kimi/KIMI-CODE-2.3.2.md: --print, --afk and --config-file do not exist there
(the non-interactive surface is -p, --prompt <value>), config moved to ~/.kimi-code, and a
global install of it removes an existing kimi shim and renames it kimi-legacy. So the
adapter in this release cannot drive the successor, and the install hint now says so instead of
pointing at the archived package without comment.

The test suite records the program's identity — command, ecosystem, package — and tells you when
the installed kimi is not the one the claims were read from:

KIMI IDENTITY DRIFT: the installed `kimi` from npm @moonshot-ai/kimi-code ... is not the
recorded `kimi` from PyPI kimi-cli. Every green in this file about kimi is evidence about
@moonshot-ai/kimi-code, not kimi-cli.

That is a diagnostic and never a failure. Failing would turn the suite red on every machine
whose CLI moved, on a day when nothing is wrong — the same tradeoff the even-terminal pin
makes. Detection reads the filesystem only: no registry is contacted, which is asserted by
trapping sockets, DNS, fetch and every child_process entry point and checking that nothing
tried.

Nothing about kimi was re-graded. The captured end-reason fixtures are recordings of 1.49.0 and
remain exactly that, and a completed -p turn under 2.x is unmeasured — it needs an interactive
re-login — which the findings document states rather than leaving to be inferred.

A rationale that was never true

kimiConfig.ts justified depending on python3 tomllib on the grounds that kimi-cli requires
Python >= 3.12. That never followed: uv tool install gives the tool its own interpreter and
puts none of it on PATH, so a machine can run Kimi with no python3 at all. The code is
unchanged; the reason given for it now says what it actually depends on — a separate python3
on PATH with tomllib — and names the .json config as the way around it.