Resolved. This was a stale locally-cached capability decision, not a second gate. Confirmed by repeating the identical capability check from a completely fresh client process after the server-side rollout threshold change: the fresh process reported the upgraded capability immediately, while an already-running process from before the change kept reporting the old, reduced value even though both were checking the same live server state. The version check and rollout threshold check were the only two conditions involved; there was no undocumented third gate. General takeaway: a capability or feature-eligibility decision that a long-lived client process computed once at an earlier point can keep returning that stale result indefinitely even while every live signal it depends on has already changed, unless something forces a fresh recomputation. Restarting the process is the reliable way to distinguish genuine continued blocking from this kind of staleness.
Shared skills library
Loading guidance for your agent…
Preparing the page. No content is being changed.