perf T4-W1 (speculative): evaluate skipping the cached-session verify round trip — every authed invocation pays ~2.5 s (GET /chip/sync) before doing its actual work

[JavaGT]

Evidence

On a cached, unexpired session, authenticate always calls verify() (src/auth.mjs:60) = GET /chip/sync (src/auth.mjs:150-157). Measured share on this machine: libby archive (no flags — all bootstrap, no work) median 2596 ms vs libby help 26.1 ms; buildConfig + session load + JWT decode are single-digit ms, so the network verify is essentially the entire delta.

If verify() were skipped (trust the JWT exp locally, let the command's first real API call surface an invalid session), every authed invocation — list, archive --all, auth, borrow, … — would start ~2.5 s sooner on this network.

The tradeoff (why evaluate, not implement)

• verify() gives the clean "Cached session no longer valid; re-bootstrapping" path (src/auth.mjs:62). Skipping it turns invalid-session detection into a mid-command failure (e.g. after partially archiving), with a messier recovery story.
• An invalid session would also pay a failed call before re-bootstrap (one extra round trip in the bad case, to save one in the good case).
• libby auth exists to verify authentication only — it presumably keeps an explicit verify regardless.

Question for evaluation

Measure the real invalid-session frequency and the failure UX both ways; decide whether verify should be dropped, deferred (verify only when the command's first API call fails), or kept. Implementation is explicitly NOT the todo until that call is made.

Related: #10, #11.

[JavaGT]

Post-#17 refresh of the owner-decision input (0300 run 2026-09-13, measured on the current tree d5a9e6d):

Numbers today (9 interleaved spawnSync rounds, session COPY, isolated XDG config, per-side outputs byte-identical, owner files sha-verified untouched — probe: artifacts/automation-receipts/2026-09-13/ab-probe-0300.mjs):

• libby auth (cached-verify journey) median 1929.5 ms — spawn+module load is ~28 ms (node floor), so the GET /chip/sync verify is essentially the whole journey on this network (historical probe range ~70 ms–1.9 s; this endpoint's latency varies a lot).
• libby return <fake-id> median 1956.6 ms → marginal delta 27.1 ms over auth, i.e. after perf: list/archive/return fetch /chip/sync twice per invocation — authenticate's verify already holds the payload (~568 ms measured) #17 the sync payload is reused and list/archive/return pay no second round trip.

What this changes in the ticket's framing: the body's "every authed invocation pays ~2.5 s before doing its actual work" is no longer the right shape. After #17 (and #15's periods kick, #13's format-lookup kick), the cached-session /chip/sync is not pure overhead for list/archive/return — it is their loan-data fetch. The remaining addressable surface for skipping the verify is only the commands that need no loan data: borrow/hold/unhold (auth keeps verify by definition; the hold/unhold no-sync variant was inspected and declined with evidence in the 0800 run).

Tradeoff unchanged: skipping the verify trades the clean "Cached session no longer valid; re-bootstrapping" path for a mid-command failure plus one extra failed round trip in the bad case. Owner decision stands — no code change made. Evidence files: artifacts/automation-receipts/2026-09-13/bench-quick-0300.json (regression sweep clean, 100/100 tests).

[JavaGT]

External consultation (Grok 4.6): recommends C — drop the pre-verify everywhere, let the first real API call carry the failure. Confidence: high. Two of its supporting claims verified against the code:

1. The local expiry check already exists — isExpired (5-minute skew, src/auth.mjs:192) runs BEFORE the verify round trip, so the GET only hedges "locally-live token the server rejects" (revoked chip — no observed frequency data).
2. Post-perf: list/archive/return fetch /chip/sync twice per invocation — authenticate's verify already holds the payload (~568 ms measured) #17 framing correction: for list/archive, /chip/sync is the shelf fetch regardless (src/loans.mjs:14-17 fetches when no reused payload) — dropping the pre-verify moves the GET, it doesn't remove it. The ~1.9 s saving therefore applies to commands that don't sync — chiefly auth — not "every authed invocation" as the original framing had it.

Grok's risk note: if dropped, the clean "Cached session no longer valid; re-bootstrapping" message must move onto the first failed authed call, or a rare dead chip surfaces as a raw API error.

Recorded as advisory. Owner decision pending.

[JavaGT]

Implemented per the owner-accepted consultation (Grok verdict C): landed in 6c80297, v0.7.0.

What changed: authenticate serves a locally-unexpired cached session with zero round trips (the ~1.9 s verify GET is gone). The command's first real authed call is now the liveness proof; a 401/missing_chip there triggers exactly one transparent re-bootstrap + retry, printing the same "Cached session no longer valid; re-bootstrapping" message the old pre-verify path produced. credentials_rejected and whoa deliberately never retry. loans.sync now always owns the invocation's single /chip/sync fetch (the #17 one-sync budget holds by construction — the reuse envelope had no producer left and was removed with it). libby auth on a cached session reports Authenticated (cached session, valid until <date>) truthfully with zero requests.

Measured (same A/B methodology as the 0300 receipt — 9 interleaved spawnSync rounds, isolated XDG config, session copy, owner files sha-verified untouched): libby auth cached median 1929.5 ms → 50.2 ms (−97.4%; residual is process startup). list/archive/return keep exactly one sync round trip — that fetch is their shelf data, per the framing correction recorded above.

Tests: 102/102 — the #17 request-log pins restated for the new mechanism, plus new pins: dead-session recovery (exact request set incl. the bootstrap chain between the two syncs), zero-request auth, and an isAuthFailure unit pin.