ciris-client 0.5.206: the floor already resolves it — but the VENDORING §1 emitter pin is twelve releases stale

[emooreatx]

ciris-client 0.5.206 is published — and for the node, there is less to do than usual

pyproject.toml:85 declares ciris-client>=0.5.203,<0.6. That range already resolves 0.5.206, so nothing has to change for a node to pick it up. This issue is two decisions and one overdue chore, stated plainly rather than as work manufactured for its own sake.

One caveat first: 0.5.204 and 0.5.205 do not exist on PyPI. Both were tagged, built every wheel, and then failed the release gate on a vendoring digest, so nothing was uploaded; their GitHub releases carry mobile assets only. Anything that pins either exactly will not resolve. 0.5.206 supersedes both.

---

1. What is actually in it for a node attachment

Most of 0.5.204–0.5.206 is agent-facing (the setup-complete request body) or harness-facing. The part that touches node territory is CIRISClient#40:

The desktop client now waits for :8080, :4243 and :4242 to be bindable — a real bind(), not a pid check — before it launches ciris-server, and again after it stops one. The trigger was a factory reset leaving the previous backend holding :4242/:4243, so the next boot died on Edge transport ports are held by another process. Two measured facts from the agent side shaped it: SIGTERM is accepted and never acted on (CIRISAgent#1152), and SIGKILL releases the ports roughly 2s after the pid is gone.

For you this means: if a node is slow to release its ports, the client now says which ports, and what to run, instead of letting Edge init fail in your words. If you think the client should be asking the node to stop over /v1/system/shutdown rather than signalling the process it launched, say so — I deliberately did not add that, because it reaches into a backend the app may not own.

The /health contract from CIRISServer#548 is unchanged and still relied on exactly as you settled it: 200 means serving, "starting" has no producer, NODE_ONLY_ENDPOINT polls :4243/health.

2. Should the floor move to >=0.5.206?

My recommendation: no, leave >=0.5.203. A floor should encode a dependency, and the node does not depend on anything added since .203 — the setup-complete fix is the agent's surface, and the port wait is client-side behaviour a node cannot observe. Raising it would only make older-but-fine clients unresolvable.

Raise it only if you want the port-release behaviour guaranteed for a bundled desktop node, which is a product call rather than a technical one. Either way, no code change.

3. Nothing to do about localization

Recording this because the compat matrix looks like it says otherwise. The 0.5.203 row states locale_bundle.keys: 3907; 0.5.204 onward states 3923. That is a corrected measurement, not sixteen new ids — the bundle is byte-identical in key set at both tags (3923 flattened keys, 29 languages, verified by packaging/localization_bundle.py). The 3907 was stale. No new message ids since .203, so no --verify pass is needed on your mirror.

4. The actual ask: a §8 pull is twelve releases overdue

client/VENDORING.md §1 records:

Upstream	Last merged state	Pulled
CIRISAI/CIRISServer	v0.5.188 (1b4f377)	2026-08-24

You are at v0.5.200. This is not cosmetic bookkeeping: that recorded ref is what CI checks out as .emitters, and five of the twelve localization checks grade our bundles against the Rust that emits the ids — pinned to the merged state so the grade is against what this tree was reconciled with, not whatever main holds. So any message id your emitters have gained since v0.5.188 is currently graded by nothing on either side.

The current run is honest about its denominator (244 emitted id(s)), which is why this is visible rather than a silent pass. If ids were added in .189–.200, they are unscored today.

The pull is a three-way merge, not a wipe — procedure in client/VENDORING.md §8. Happy to drive it from our side; what I need from you is whether v0.5.200 is the right target or you would rather I wait for a specific release.

What would settle this

1. A decision on the floor (§2) — I expect "leave it".
2. Confirmation on §1 whether the client should ask a node to stop rather than signal it.
3. A target ref for the §8 pull (§4), which is the only item here with a real gap behind it.

Compat row: compat/matrix.json 0.5.206 — node_min unchanged at 0.5.168, node_max_tested 0.5.198.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Db9uHKMfhnANvagjWSo59x

[emooreatx]

Answers to the three, with the one measurement that settles §4.

§2 floor — leave >=0.5.203. Agreed for the reason you give: a floor encodes a dependency, and nothing node-side depends on .204–.206 (the port wait is client behaviour a node cannot observe; setup-complete is the agent's surface). Noted that 0.5.204 and 0.5.205 do not exist on PyPI; nothing here pins exactly, so nothing breaks.

§4 target ref — v0.5.200 (a801ee3), and it is safe today. I ran your client/tools/check_localization_sync.py --server-src against this tree at v0.5.200 from your main (24c1b07, bundle 0.5.206), plain and --strict:

server-id-reachable : 0 findings over 321 emitted id(s)     (244 at the v0.5.188 ref)
server-id-coverage  : 0 findings over 321 emitted id(s)
server-id-text      : 0 findings over 249 emitted id(s)
unlocalized-debt-current: 0 findings over 19 known id(s)   (matches our own guard's 19)
… 12/12 OK, exit 0 both modes

So the pull re-grades 77 ids that have been unscored since .188 and every one already passes — your bundle work through #36/#37 covered them by hand as they arrived. Drive the §8 merge whenever you like; there is no server-side change to wait for, and 0.5.201 is holding for a substrate triple with no date yet, so pinning a release that exists beats pinning one that does not. One hygiene note while you are in that file: your _SERVER_EMITTERS alternation lacks refuse_with( (0.5.198's typed 202 door — contacts.awaiting_key_body is emitted through it). Adding it did not move any count today, so nothing is unscored; it is the two-scrapers-one-rule drift waiting to happen rather than a present gap.

§1 stop vs signal — signal, and use SIGINT. There is no /v1/system/shutdown on the node; the only stop door besides a signal is the in-process ciris_server.shutdown_node() for an embedding host (it signals the serve and waits for :4243 to actually free, CIRISServer#276). Measured from the source rather than remembered: the standalone node's shutdown select awaits tokio::signal::ctrl_c() — SIGINT is handled (graceful: loops joined, listener released, then exit) and SIGTERM is not handled at all: the default action kills the process abruptly, which is where your "ports released ~2 s after the pid is gone" comes from, and it is also what docker stop sends. So for a node the client launched: SIGINT, wait for :4243/:4242 to be bindable (your new check is the right predicate), then SIGKILL on a timeout. Do not add an HTTP stop for this — a route that stops a backend the app may not own is the reach you were right not to take. The server will handle SIGTERM the way it handles SIGINT (small follow-up here); until then SIGINT is the graceful one.

node_max_tested can move to 0.5.200 when the §8 pull lands; the /health contract from #548 is unchanged by 0.5.199 → 0.5.200.