v1.0.11: fleet resume entitlement — pinned-provider materialization fixes the silent turn-running wedge #42

Merged
ClaudiuSchuster merged 1 commit from oss-oo/pinky-e-resume-provider into main 2026-10-01 16:48:07 +00:00
Owner

Addendum to the v1.0.10 hotfix (MasterBrain steer #8, owner-hit ~16:45).

Wedge: a resume steer into a session pinned to a provider outside the station config wedged silently — the entitlement push materialized the CONFIG provider only, the pinned session model never resolved, result stuck at turn-running (send ACKed, zero model activity, no error).

Fix: the push builder is extracted to entitlement.py; it entitles EVERY zhipu-account provider in the registry snapshot and marks the CONSUMER provider current — config provider for creates, the resumed session pinned provider (runtime/model_selection entry) for resumes. The current flag is load-bearing (live-verified: team-pin resume completed only once the pin was current). Plus: resumes may pass a --model outside the config list (session pin is the authority), finish-time verification compares against the dispatched model, and the runtime-headers handshake serves stored plan keys for ANY zhipu-account provider (honest decline + terminal turn error when none is stored).

F10 live proof (env -i PATH HOME): team-plan-pinned resume COMPLETED (exit 0, actual account:zai-team-coding-plan/GLM-5.3, response OK); start-plan-pinned resume reached a terminal error honestly (exit 4, turnStatus error, setModel resolved, 2 real model attempts — no stored start-plan key). No silent wedges.

Gates: full offline suite green (podman-shim tripwire: zero invocations; new entitlement unit legs + fleet-resume dispatcher leg), super-linter slim-v8.7.0 green (6 lanes), live contract canary GREEN 38 pass.

Addendum to the v1.0.10 hotfix (MasterBrain steer #8, owner-hit ~16:45). **Wedge**: a resume steer into a session pinned to a provider outside the station config wedged silently — the entitlement push materialized the CONFIG provider only, the pinned session model never resolved, result stuck at turn-running (send ACKed, zero model activity, no error). **Fix**: the push builder is extracted to entitlement.py; it entitles EVERY zhipu-account provider in the registry snapshot and marks the CONSUMER provider current — config provider for creates, the resumed session pinned provider (runtime/model_selection entry) for resumes. The current flag is load-bearing (live-verified: team-pin resume completed only once the pin was current). Plus: resumes may pass a --model outside the config list (session pin is the authority), finish-time verification compares against the dispatched model, and the runtime-headers handshake serves stored plan keys for ANY zhipu-account provider (honest decline + terminal turn error when none is stored). **F10 live proof (env -i PATH HOME)**: team-plan-pinned resume COMPLETED (exit 0, actual account:zai-team-coding-plan/GLM-5.3, response OK); start-plan-pinned resume reached a terminal error honestly (exit 4, turnStatus error, setModel resolved, 2 real model attempts — no stored start-plan key). No silent wedges. Gates: full offline suite green (podman-shim tripwire: zero invocations; new entitlement unit legs + fleet-resume dispatcher leg), super-linter slim-v8.7.0 green (6 lanes), live contract canary GREEN 38 pass.
v1.0.11: fleet resume entitlement — pinned-provider materialization fixes the silent turn-running wedge
All checks were successful
Checks / Functional checks (pull_request) Successful in 5m28s
4cb6865331
Owner-hit 2026-10-01 ~16.45 (MasterBrain steer #8): a resume steer into
a session pinned to a provider outside the station config (e.g.
account:zai-start-plan/GLM-5.3-Flash on an individual-plan station)
wedged silently — the entitlement push materialized the CONFIG's
provider only, the resumed session's model never resolved, and the
result sat at turn-running forever (send ACKed, zero model activity,
no error).

Fix: the push builder is extracted to entitlement.py and entitles
EVERY zhipu-account provider in the registry snapshot, marking the
CONSUMER's provider current — the config's for creates, the resumed
session's pinned provider for resumes (read from the session's
runtime/model_selection entry, message stamps as fallback). The
current flag is load-bearing: live-verified 2026-10-01 — a
team-plan-pinned resume completed ONLY once the pin was marked
current (entitled-but-not-current pins never materialize).

Accompanying seams: resumes may pass a --model outside the config's
models list (the session's pin is the authority; the resume precheck
still enforces it), finish-time verification compares against the
dispatched model instead of the config list, and the runtime-headers
handshake serves a stored plan api-key for ANY zhipu-account provider
(declining honestly when the store has none — an uncredentialed pin
resolves, attempts, and surfaces as turn status 'error' instead of a
silent hang).

F10 live proof (stripped env, env -i PATH HOME): team-plan-pinned
resume COMPLETED (exit 0, actual account:zai-team-coding-plan/GLM-5.3,
response OK); start-plan-pinned resume reached a terminal error
honestly (exit 4, turnStatus error, setModel resolved, 2 real model
attempts — no stored start-plan key; store one via zcode-cli login to
make such dispatches complete). Offline suite: entitlement push unit
legs (fleet entitlement, pinned-current semantics) + a dispatcher leg
proving a fleet-pinned resume passes the argument gate and reaches the
model-request phase; the fake server captures push providers.
Contract canary stays green (38 pass).
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
OSS-Singularity/zcode-dispatch!42
No description provided.