Headless lease claim succeeds but the next call lists no live leases #287

Observed behavior

With Homebrew spectackle 0.10.0 on macOS/darwin-arm64, a stable agent in its open work op=start worktree sees a successful explicit lease refresh, but an immediately following headless call lists no live leases. The worktree remains open and bound to the same identity.

These are separate spectackle call processes using the default stdio transport, not a resident -http server. The cwd is the server-returned nested worktree (PRIMARY/.spectackle/wt/T-01M26474J0EDXBCHDKB9PH1C03). No source editing, abort, release, or submit occurred between the calls.

SPECTACKLE_AGENT=vjp-qualify-implementer spectackle call lease '{"op":"claim","item":"T-01M26474J0EDX","paths":["T-01M26474J0EDX",".github/workflows/ci.yml"],"ttl":1800}'

Observed output:

c . journal 1125 events since last compact
ok claimed T-01M26474J0EDXBCHDKB9PH1C03 .github/workflows/ci.yml

Immediately afterward, with the same cwd and identity:

SPECTACKLE_AGENT=vjp-qualify-implementer spectackle call lease '{"op":"ls"}'

c . journal 1125 events since last compact
ok no live leases

work status still reports:

wt T-01M26474J0EDXBCHDKB9PH1C03 open vjp-qualify-implementer PRIMARY/.spectackle/wt/T-01M26474J0EDXBCHDKB9PH1C03

PRIMARY above substitutes the local scratch checkout path; the item, identity, commands, and status are otherwise the observed values. The author retried the refresh once with the same result, then stopped retrying and preserved the observation.

Expected behavior / clarification needed

The lease tool describes a scope reservation with a TTL and auto-refresh on each call. A successful 1800-second claim should either remain discoverable across the documented headless calls, or explicitly report that it expires when that stdio session ends and explain the required resident/single-session workflow.

If leases are deliberately session-local, this may be a headless CLI/documentation ambiguity rather than a persistence defect. I have not inspected lease storage or isolated the cause, and have not compared a resident HTTP session. The persistent open worktree may still provide an independent collision guard; this report does not claim that a competing writer was admitted.

Impact and boundaries

An orchestrator cannot distinguish an effective refresh from an already-ended claim using the success response alone. We kept the original-source checkpoint frozen, with a single known writer and read-only verifier; did not abort the worktree or manipulate server-owned files. No code fix is proposed here.

Searched existing issues for lease, lease claim, and stdio lease; #27 concerns older nested-worktree root resolution and is closed, while #283 concerns validation verdict attribution. Neither directly documents this observed claim/list sequence.