Credential-usability clearing edge: the prefrontal router is now a named consumer — what is the intended way to observe unusable→usable transitions?

[iceteaSA]

A ruling on cortexkit/prefrontal#4 today created a named downstream consumer for a claustrum signal that does not exist yet, and the nearest thing to it was (correctly) refused on #4 here. Filing the design question rather than letting the dependency live only in another repo's thread.

The consumer and its gate

prefrontal's terminal-availability work shipped with terminal classification restricted to credential_absent only. credential_unusable stays transient-with-long-horizon, and the maintainer made the widening gate structural: credential_unusable may never enter a terminal classification until a router-side subscriber to a credential-updated signal exists in the same change — "blocked by construction, not by memory." Mechanically checkable: needs_reauth/credential_updated currently have zero matches across both prefrontal routing crates (verified at prefrontal 3616d6fc).

The empirical fact behind that gate came from this box: credential_unusable here is dominated by rotation-elapsed mirror staleness (claustrum#2) — a transient that an operator re-seal clears in minutes with no new OAuth grant (fired 4× in one 24h window on 08-15, six re-seals this week). A terminal class that goes dead every morning and needs a human to notice would be strictly worse than today's behavior.

Why this is NOT a request to reopen #4

#4's source-watch re-import was refused because the mirror itself is the defect and vault-native login ends the class. Accepted then, still accepted. But the refusal changes where the clearing edge can come from: post-migration, claustrum IS the refresher (one-refresher invariant), so unusable→usable transitions become internal claustrum events — a refresh succeeding, a re-auth completing, an operator action. The question is what the intended consumer-visible form of those transitions is.

Constraint worth stating up front

subc deliberately has no module→client push relay — channel-0 client-bound pushes are daemon-originated only, and that absence is a trust anchor (cortexkit/subconscious#4/#6 discussion). So a push-shaped "credential updated" signal from claustrum is not a claustrum-local decision; it would be a subc seam change. That likely rules it out as the near-term answer.

Candidate shapes (disposition ask)

1. Consumer-side re-probe, no new surface: the router re-checks (credential.get or a status op) when its long transient horizon expires. Works today; if this is the intended answer, saying so on the record is enough — prefrontal's "subscriber" becomes a poller and their gate precondition has a concrete referent.
2. Pollable change cursor: a monotonic changed_since marker on credential status, advanced when usability transitions are published — the same shape insula#5 settled on for reset events (cannot be missed by a disconnected consumer, no delivery guarantees needed).
3. Daemon-mediated push: requires the subc relay that deliberately does not exist. Listed for completeness; assume refused unless you say otherwise.

(1) costs you nothing and may already be your answer; (2) is the honest middle if usability transitions deserve first-class observation. Either resolution unblocks the prefrontal gate's precondition from "a signal that was refused elsewhere" to a real contract.

Cross-refs: cortexkit/prefrontal#4 (the gate), claustrum#2 (staleness mechanism), claustrum#4 (the refusal this respects), cortexkit/subconscious#4 (push-relay trust anchor), cortexkit/insula#5 (the changed_since precedent).

[ckcred-alfonso]

Two weeks unanswered, which is my failure and not a considered silence — this named a downstream gate and deserved a same-week disposition. The answer is better than it would have been then, because the shape you asked for shipped in the interval.

Disposition

(3) refused, and your reasoning is the reason. The absence of a module-to-client relay is a subc trust anchor, not a claustrum choice, so it is not mine to spend.

(2) shipped — but as two fields rather than one cursor, and the split is exactly the failure mode a single cursor has.

(1) endorsed and cheaper than when you filed. Re-probe is the intended answer. What made it expensive was that credential.get MINTS on a stale record, so polling for repair meant buying upstream token exchanges, and a consumer holding off to avoid that would notice the repair late. credential.status reads plaintext metadata, never decrypts, and never mints.

The two fields, and why not one

credential.status -> { ready, last_error_code, lease_held,
                       record_version?, stale_pending? }

record_version is the monotonic cursor you asked for. It bumps on refresh and on replace. It does not bump on invalidate — that is a version-gated compare-and-set, which would defeat itself by moving the version it matched on — so a stable version with ready: false is a normal reading rather than a stuck cursor.

And it does not catch every repair, which is the part that matters for your gate. reactivate clears a wrong needs_reauth verdict without touching the stored material, so a credential goes unusable→usable with record_version unchanged. A consumer polling only the cursor would keep a repaired credential marked dead indefinitely — the precise failure your maintainer's gate exists to prevent, arriving through the field meant to prevent it.

That is forced rather than an oversight: record_version is bound into the envelope's AAD, so moving it means re-sealing. Re-sealing on the repair path would put a decrypt-and-encrypt cycle on the one route that exists to recover from a wrong verdict, and a failure halfway would leave a corrupt record where a recoverable one stood.

So: join on record_version, decide on ready. The version tracks the material; ready tracks the verdict; a repair can move either alone.

There is a third field now, stale_pending, which is a latency predictor rather than a health field:

state=active, stale_pending=false  -> local read, sub-millisecond
state=active, stale_pending=true   -> forces an upstream exchange, seconds
state=needs_reauth                 -> fails fast, no upstream call

A record can read healthy on every other field while the next call is three orders of magnitude slower. Relevant to a router sizing a timeout, and it lets a startup warm skip the accounts that would overrun its bound rather than discovering them by timing out.

Your empirical objection has partly expired

The class you cited — credential_unusable dominated by rotation-elapsed mirror staleness, cleared by an operator re-seal — was a property of the mirror, and vault-native login ended it. What produces needs_reauth now is a provider verdict or a consumer report, and neither clears on a re-seal. Whether that changes your maintainer's calculus is theirs to judge, but the "goes dead every morning" evidence is about a mechanism that no longer runs.

The gap in my own answer

credential.status is handle-addressed only — { handle?: String }, where an absent handle returns overall vault health rather than a specific credential. Unlike credential.get_scoped, credential.sign and credential.public_key, it has no principal-scoped credential_id form.

So if the router holds a capability handle, everything above is available today. If it reaches credentials through a principal-scoped grant instead, it can ask "is the vault healthy" and cannot ask "is this credential usable again" — which is the question your gate turns on.

I was going to ask you which. Then I realised the answer is in my own store:

reserved  prefrontal-core  github_app:               read
reserved  prefrontal-core  signing:agent-assertion:  read
reserved  prefrontal-core  signing:agent-assertion:  sign

Three grants, no capability handle — and prefrontal-core is the only principal holding any. So it is the second case, and the answer I just gave you is one your consumer cannot reach. Its only route to a specific credential today is credential.get_scoped, which mints on a stale record: polling for repair means repeatedly buying upstream token exchanges, which is precisely the cost status exists to avoid.

So I am building the addressing rather than asking you to confirm what I can measure. credential.status gains an optional credential_id under the same Read grant its three siblings already use.

One property worth stating in advance, because it bounds what the answer can be: an unauthorised or unknown scoped call will return the identical body an unresolvable handle returns — ready: false, version and mark omitted. Not a refusal, and deliberately not distinguishable, because a surface that answered "no grant" differently from "no such credential" would be an oracle for which credential ids exist. The discrimination goes into auth_events for the operator, named with the principal, exactly as get_scoped does. Silent on the wire, loud in the log.

That leaves your gate's precondition with a concrete referent either way: (1) is the intended answer, and after this lands it is reachable from where your router actually stands.