stack/docs/plans/reviews/2026-09-10_gate7-final-verdict.md

GATE7-FINAL-FILBERT-1 — verdict

Reviewer: Filbert (independent). Author of the draft edits: Darkwing; investigation author: Rocko (PI-REFRESH-ROCKO-1). Frozen snapshot /tmp/gate7-final-znmnih6v at manifest SHA-256 ea9c539d4ca030278440332fe3f1291e2494e50b475f4a2c46b35b39c290b628, pin 224147ec…; all four hashes verified before and after review; snapshot unchanged. Read-only: no live pi commands, no package fetches, no private reads.

Verdict: APPROVED

Committing exactly these four reviewed files is approved. This closes gate 7 as documentation; it authorizes no implementation, package change, or credential operation.

Findings by assigned check

1. Draft deltas confined. Against pin 224147ec…, the registry draft changes only: the mechanics-section sentence resolving the refresh trigger via PI-REFRESH-ROCKO-1 with owner approval; the refresh-driver paragraph inside the verification/suites bullet list; gate 7 moving PARTIALLY RESOLVED → RESOLVED (owner, 2026-09-10, mechanism (a)); and the remaining-open-item text. Nothing else moved.

2. Investigation consistent, cited, and corroborated. The 0.85.1 claims are internally consistent (shasum 4cd00f65… appears identically in three places; the refresh: false function default vs refresh: !noRefresh CLI wiring contradiction is explicitly reconciled; the two independent 5-minute layers — stored-value safety margin and read-time validity window — are explained coherently; the browser/PKCE login flow is correctly separated from the POST-only refresh). Citations name concrete files and unique anchors. Because the investigation itself establishes the capability as pre-existing since 0.83.0/0.84.1, I corroborated read-only against this repository's pinned 0.84.4 install: the same command set (check/print-api-key/print-bearer-token/--no-refresh), the verbatim help sentence, the 0o600/proper-lockfile/read-only-refusal anchors in auth-storage.js, the refresh timeout constant, and the Anthropic token URL all exist locally as described. One claim the investigation supports only by inference — that pi auth check produces no credential output — is corroborated by the pinned package's own help text: "--credentials emits the credential," i.e. only on explicit opt-in. Limit recorded honestly: I could not re-derive the 0.85.1-specific evidence (no fetches permitted); the tarball identity rests on the investigation's recorded npm outputs, and my corroboration covers the shared pre-existing behavior.

3. Mechanism (a) matches the findings. The owner-selected pi auth check --provider <p> is exactly the entry point the investigation verifies as noninteractive, refresh-if-expiring (5-minute default window), no browser/TTY, with the in-place locked auth.json rewrite; print-* exclusion matches their documented credential-export semantics.

4. No gate silently moved. Gates 1–6 and 8–10 read RESOLVED at the pin and are unchanged; only gate 7 changed, per the owner's Q15(a) ruling. The new remaining-open text ("none — all gates resolved; implementation needs a separately chartered increment") states the boundary correctly and infers no implementation authority.

5. No credential material or new identifiers. The candidates contain no secrets; the investigation records only a public token URL, package digests, and code anchors. The UUID hits in SESSIONS.md are baseline published history; the added registration line carries none.

Condition

Commit exactly the four reviewed units at manifest ea9c539d…. Any byte change, including any later 0.85.1 pin bump or refresh-service work, requires its own chartered and reviewed increment.