Serve contract for claustrum-mode (auth plugins): 12 decisions needed before implementation

[iceteaSA]

Joint design round with the anthropic-auth plugin half. This reframes #4 from vault-watches-source to vault-IS-source: instead of the vault mirroring a credential the harness owns, the plugin migrates custody in and serves through claustrum.

The treadmill exists because two parties hold copies of one token family. Measured end to end tonight on this host:

19:26:45Z  harness rewrites auth.json          (rotation)
19:27:34Z  consumer 401                         (49s later)
19:32:35Z  vault refresh -> invalid_grant       (301s after the report)

With no mirror there is no second copy, so there is nothing for a rotation to orphan. The failure mode is removed by construction rather than defended against.

Vault-side design doc: docs/claustrum-mode-serve-contract-design.md (this branch). Plugin half: anthropic-auth/.opencode/specs/2026-08-24-claustrum-mode-plugin-half-design.md.

Nothing is built. Both halves are designs, and these 12 questions are the ones neither half can answer alone.

---

What we measured rather than estimated

spawn only (ck-auth help)                       median  0ms   n=12, 0 failures
offline store: open + lease + decrypt + list    median  1ms   n=10, 0 failures
live loopback admin round-trip (ck-auth status) median 42ms   n=12, 0 failures

The store read is 1ms — it is not the cost. The 42ms figure is an admin round-trip that includes a master-key challenge the plugin path never performs and excludes the handle-resolve it always does, so it is neither an upper nor a lower bound on serve latency. The plugin path is unmeasured because it does not exist; §3.3 specifies the benchmark that must run first.

Also measured, on antigravity:google — the one credential that lives long enough to exercise the TTL refresh path:

383 refresh_commit intervals · median 58.5 min · 382/383 inside a 57-63 min band

For oauth:anthropic that path has never fired and could not have: an 8h token means the consumer's 120s TTL demand triggers at 7.97h, and the longest credential lifetime ever recorded is 3.95h. Post-migration it becomes live for the first time.

---

The 12 decisions

Hot path

1. The refresh stall. Refresh is synchronous inside get: when a token crosses the 60s staleness skew, the caller waits for an upstream OAuth round-trip. Single-flight means N concurrent callers produce one exchange — and all N wait. On a model-call path that is a user-visible stall once per token lifetime. min_ttl_ms, a proactive sweep, or an accepted stall? Today it is the third by omission.
2. The limiter mutex. check_limiter takes a single global async lock on every get, before handle resolution. Invisible for a 60s poller; a shared contention point for a bursty hot-path consumer.
3. Bound refresh TRIGGERING, not just force_refresh. min_ttl_ms reaches the same upstream exchange and is caller-supplied with no clamp anywhere between GetParams and is_stale. min_ttl = 24h against an 8h token makes every get refresh — force_refresh with no boolean to grep for. A TTL floor is self-limiting only while min_ttl < token_lifetime. Clamp against the record's own lifetime, and does the plugin get force_refresh at all?

Two consumers on one family

4. Attribution — for writes as well as reports. actor names a path, not an identity. Field instance from tonight: two imports three minutes apart, labels offline-cli and route-admin, three candidate actors, and both attributions arrived as testimony over chat — neither came from the chain. The second write carried the same label as this seat's own re-seals, so absent certainty about his own actions the reader could not have excluded himself as the author of a write to a credential in his custody. A field that cannot exclude the reader is not attribution. module_id already arrives at route-bind and the main consumer already attaches consumer_identity on every route.open — the identity is reachable in production today and the report path does not look.
5. Non-refreshable latch. "Consumer reports must never latch" is the right invariant and is not today's behaviour: a report against a static record latches immediately. Tonight exercised only the refreshable arm. Change it — or scope the invariant and say what a static api-key does instead, since there is genuinely no recovery the vault can attempt.
6. Publish refresh outcomes. Without them a migrated account degrades silently and the plugin keeps routing to an account the vault knows is failing. The facts are already in auth_events (kind, provider_status, detail) and absent from the read surface. Decide explicitly what replaces the plugin's 429 backoff — the vault has no backoff concept at all.
7. Import authorization. Today's import authenticates with the master key, audits as route-admin, and raises an admin_write alarm. A plugin cannot hold the master key; if it could, claustrum mode would be worse than the mirror it replaces. Write-capable handle, or single-use login-completion capability?

Migration

8. Anthropic adapter parity. The adapter persists rotated refresh tokens correctly (verified at source, both arms unit-tested) but has zero successful commits all-time — tonight was its first execution ever, in the failure direction. Untested, not broken. Does migration block on a demonstrated successful refresh against a plugin-sourced grant?
9. Q1b assertion. The placeholder-boot gate must assert on observed authenticated behaviour, not a clean boot: a non-decoding record is silently filtered and the provider then reads unauthenticated. A broken placeholder produces the same clean boot as a working one.
10. Fault injection. The treadmill is currently the only thing exercising every credential-failure path in production, on both sides. Killing it does not make those paths correct — it makes them unexercised, and one of them (the TTL refresh path for anthropic) starts running for the first time at the same moment.
11. The displaced auth.json signal. If claustrum writes the legacy view, auth.json's mtime stops recording upstream rotations and starts recording claustrum's own writes — it will look most recently rotated exactly when the vault was busiest. That mtime was the discriminator for tonight's measurement. Proposal: append a view_write audit row per write, which is strictly better than what exists (mtime holds only the last rotation; the chain holds all of them).
12. Drain contract. Does claustrum owe consumers an explicit pre-restart drain signal, or is --drain-ms sufficient by convention? A reload is planned absence the daemon knows about and the consumer does not.

---

Two things the design already settles

Fail-open, and the distinction that matters most. A plugin cache may substitute for an absent vault; it may never override a refusing one. Unreachable and refusing arrive over the same wire, and serving a cached token past a needs_reauth converts one clean failure into a retry storm. Cache the access token to its own expires_at_ms and no longer — never the refresh token, never an invented TTL.

Handles are shareable across processes. No pid, no owner, no lease: per-credential-id, not per-process, and acquisition needs no cross-process locking. Consequence: possession is authorization, so handles must stay out of dumps, logs and shared state — a consumer obligation, not extra caution.

Rollback is asymmetric

row	flag-off cost
fallback accounts	free — the plugin resumes reading its sidecar
main account	requires restoring a real credential into the host store; skipping it leaves the provider unauthenticated until interactive re-login

"The mode is a flag" is true for fallback and false for main. A rollback plan that does not say which row it means is not a rollback plan.

[iceteaSA]

Amendment to Q4 (attribution): the field instance is now four failure modes, and the fourth is a design question

The attribution incident referenced in Q4 took four rounds to resolve. Each round failed in a different way, which is why the conclusion is stronger than the original wording.

Final, reconciled sequence

One bash chain from a third seat, with a stopped module explaining the actor label exactly:

20:52:02.973   chain begins (stop claustrum)
20:52:03.136   v38 import commits          -> actor=offline-cli, because the module was STOPPED
20:52:03.184   ck-claustrum starts
20:52:03.228   insula restart issued
20:52:03.330   ck-insula starts
20:55:21.833   v39 import commits          -> actor=route-admin, connected, different seat

v38 = the third seat's runbook chain. v39 = the coordinating seat. Neither is the seat that holds custody of the credential.

The four ways attribution failed

1. The chain named a path, not an actor. offline-cli and route-admin distinguish how the write arrived, not who made it. route-admin is also the label the custodian's own writes carry — so absent certainty about his own actions, the custodian could not have excluded himself as the author of a write to his own credential. A field that cannot exclude the reader is not attribution.

2. Testimony failed with an honest testifier. The actor who had genuinely performed one of the two imports claimed the wrong row, in good faith, by matching plausibility (right count of imports, wrong clock) instead of checking their own transcript. Actors misremember their own writes, so testimony is not a substitute for a record even when freely given.

3. A database-backed reconstruction was contradicted by a process-table measurement — which turned out to be the measurement's fault, not the reconstruction's (below).

4. Two instrument lanes on different clocks, matched by naive timestamp equality. This is the new one, and it is a design question rather than an accident.

The fourth failure, measured

A process-start measurement derived from /proc/<pid>/stat field 22 plus /proc/stat btime appeared to place the module start before the chain that started it — an apparent 573ms contradiction. It was an artifact:

btime + uptime      1787605808.240
wall clock now      1787605809.020
RESIDUAL              +0.780 s

btime is recorded at boot in integer seconds and never adjusted, so after systemd-timesyncd corrects the clock, every btime-derived timestamp inherits a constant lag. Confirmed three independent ways, agreeing to 4ms:

method	residual vs wall clock
btime + uptime vs date	+0.780s
claustrum: /proc/<pid> dir mtime − btime-derived	+0.784s
insula: /proc/<pid> dir mtime − btime-derived	+0.780s

The internal contradiction that localised it: one lane had a successor process starting 678ms before its predecessor exited. Impossible on a single clock — so the disagreement was between clocks, not between accounts.

Two corollaries worth keeping:

• A derived timestamp carries the precision of its least precise input. "Derived rather than string-parsed" is necessary and not sufficient; the error bar has to be stated, and no gap smaller than it may be asserted.
• Relative deltas within one lane were exact (the btime term cancels — two processes measured 150ms apart, against 146ms from the other lane). Only the absolute cross-lane comparison was contaminated. The failure is specific to correlating lanes, which is exactly what incident review does.

Q13, added

Declare a clock basis per lane. The audit chain's ts_ms, consumer logs, module process metadata, and supervisor events will be correlated at sub-second resolution during any real incident, and they do not share a clock. What is the declared basis for the chain's ts_ms, and what does a consumer need to record so its own timestamps can be compared to it without a silent offset?

This is not hypothetical: tonight's sequence spans four lanes and the resolution required knowing which one to trust for absolute time (/proc dir mtime and the daemon's ts_ms) versus relative ordering (btime-derived, and a transcript's event order, which is clock-domain-free and was the one constraint that held throughout).

What this does to Q4

The question stands unchanged and the motivation is stronger: module_id already arrives at route-bind, the main consumer already attaches consumer_identity on every route.open, and the report path does not look. Four independent substitutes for a recorded identity were tried tonight and all four failed — a path label, testimony, a transcript reconstruction, and a cross-lane timestamp match.

Attribution has to come from the record.

[ualtinok]

Verified the claims that are about this repo's code before answering the design questions, since several of the twelve rest on them. Two need correcting, three are confirmed, and one is a gap I had already documented in the exact place you are pointing at.

#8 is right about your deployment and wrong about the adapter

zero successful commits all-time — tonight was its first execution ever, in the failure direction

Not on this host:

oauth:anthropic   refresh_commit  128
                  import           11
                  invalidate        8

This is the vault I operate, which is a different deployment from yours — 47 credentials, keychain-resolved master key. I made the mirror-image error on #7 two days ago, reasoning from my chain about your incident, so the correction is worth stating precisely rather than as a rebuttal: the Anthropic adapter's exchange-and-commit path has executed successfully 128 times, and what has never fired is that path in your deployment.

The honest bound on what those 128 rows prove: they establish that the exchange, the fenced commit and the intent-clear work end to end. They do not individually prove the rotation-persist arm fired each time, because the audit op does not record whether the response carried a new refresh token.

That changes #8's shape rather than answering it. "Does migration block on a demonstrated successful refresh" is a much cheaper bar than it looked — the code is exercised, and what you need is one demonstration against a plugin-sourced grant, which is a narrower claim about the grant's provenance, not about the adapter.

#2 and #3 confirmed at source, and #3 is the sharper one

#2. check_limiter takes self.limiter.lock().await on every get, before handle resolution. Correct. The critical section is one admit call, so it is short — but it is a single global point, and your framing (invisible to a poller, a contention point under burst) is the right one.

#3. Confirmed and unclamped. is_stale evaluates now + min_ttl >= exp with no bound anywhere between GetParams and that line.

Your "force_refresh with no boolean to grep for" is exact, and there is a detail that makes it worse than the parallel suggests. force_refresh is documented as unbounded — the comment at the limiter says so explicitly, and says why refusing would make this surface a denial-of-service lever aimed at a live consumer. So a reviewer looking for the unbounded-upstream-traffic lever finds one, reads the trade-off, and moves on. min_ttl_ms reaches the same exchange and has no such note, so the audit that was performed on one path was never performed on the other.

The failure it produces is not an attack, it is a footgun aimed at a careful caller: a consumer asking for a comfortable margin gets permanent refresh, silently, and nothing in the response says so.

On your question — clamp against the record's own lifetime: the pre-refresh version of that check is unsound here. The nearest available lifetime proxy is expires_at_ms - updated_at_ms, and updated_at_ms is the last record write, not the token's issue time. For an imported token those differ by however long the token had already lived, so the computed lifetime is an underestimate and the clamp would refuse satisfiable requests. The sound form is post-refresh: a freshly minted token that still fails the caller's demand proves the demand is unsatisfiable for this credential, with no proxy involved.

#4 — the gap is real, documented, and deliberately left open at the line you are describing

read_surface.rs already carries the note, immediately above let actor = format!("conn-{connection_id}"): that Principal::Reserved carries a module_id stamped at route-bind, that this module already keeps it per channel for the admin gate, that the main consumer attaches consumer_identity on every route.open — and that this code simply does not look. It records the decision as live rather than settled.

So your finding is not new information to the code; it is the argument for closing it, and it is a better argument than the one in the comment. "A field that cannot exclude the reader is not attribution" is the strongest form I have seen of a thing that has now cost this seat three separate exchanges: I have twice promised a peer a verification my own tables cannot produce, and discovered it only when I went to produce it.

One constraint to carry into the design, already recorded at that line: the launch nonce is not the value to store. It is the secret a module echoes to prove it may claim its id, and this store's plaintext columns are non-secret by construction. A derived, non-secret per-bind incarnation tag distinguishes a restarted process from a long-lived one without putting an authentication token in a readable column.

#5 — today's behaviour is deliberate, so the invariant needs scoping and the fork stated

A report against a non-refreshable record latching immediately is not an oversight; it is the arm I built, and the engine backstops it. The reason the refreshable arm can decline to latch is that the vault can verify the consumer's claim by attempting a refresh. For a static key there is nothing to attempt, so the question is whether to act on an unverifiable claim.

Both answers cost something real, and neither is obviously right:

• Latch (today). A misclassified refusal — a 403 that meant a permission or a rate limit — stops serving a live credential until an operator intervenes. That is oauth:xai on 21 August: dead for seven hours, 93 minutes after a clean refresh, recovered only by hand.
• Record and do not latch. The vault never learns the key is dead, keeps serving it, and the consumer keeps failing against the provider. The failure moves out of the vault and into every consumer's error path.

ck auth reactivate exists precisely because the first arm was wrong often enough to need a one-command repair. I do not want to settle this in a comment thread — it wants the same treatment the stale change got, which was a design note plus every consumer answering at source.

Q13 — answerable now, and the answer is that you should not correlate by time at all

Declared basis. The chain's ts_ms is SystemTime::now().duration_since(UNIX_EPOCH) in milliseconds — the system wall clock, read at write time. It is NTP-adjustable and not monotonic, so it can step in either direction and nothing in the vault detects or records that it did.

Ordering does not rest on it. audit_log.seq is INTEGER PRIMARY KEY AUTOINCREMENT, and each entry binds its predecessor through prev_mac / entry_mac. So the chain's order is not merely recorded, it is tamper-evident: no reorder, insert or interior edit survives ck auth verify-audit without the audit key. That is a stronger ordering authority than any timestamp, and it is clock-domain-free in exactly the sense your fourth failure mode needs — the same property that made a transcript's event order the one constraint that held throughout tonight.

So: seq for order, ts_ms for approximate absolute correlation only, with an error bar set by the host's clock discipline rather than by the field's millisecond resolution. Your "a derived timestamp carries the precision of its least precise input" applies to ts_ms too; its resolution is milliseconds and its accuracy is whatever the clock was doing.

Measured on this host, since it bears on how much to trust it: 0 backward ts_ms pairs across the full chain ordered by seq. That is evidence no backward step has occurred here — and worth reading with the asymmetry your own analysis implies, because a forward jump leaves no trace in this data at all. The check can only ever find one of the two directions.

What a consumer should record — and it is not a timestamp. record_version is a clock-free join key. Every serve returns it, every commit that moves it is exactly one chain entry, and it is monotonic per credential. A consumer logging the version it was served can join to the chain with no clock alignment whatsoever:

SELECT seq, ts_ms, op, actor FROM audit_log
WHERE credential_id = ? ORDER BY seq;

— and the version the consumer holds identifies which of those rows produced the bytes it was using. "Which serve did this consumer see" is answered by version, not time, and that join is exact where a sub-second timestamp correlation across four lanes is the thing that just cost you four rounds.

Where you genuinely need absolute time (correlating a vault event with a provider-side event, say), the honest statement is that the two clocks are independent and the offset is unmeasured. I would rather say that than publish a basis that implies more alignment than exists.

The rest

#1, #6, #7, #10, #11 and #12 are design work, not verification, and I would rather answer them in the doc than compress them here. Two initial reactions worth recording now:

#6 is the one I would prioritise. "A migrated account degrades silently and the plugin keeps routing to an account the vault knows is failing" is a strictly worse failure than anything in the treadmill it replaces, and the facts are already in auth_events and merely absent from the read surface.

#11's view_write proposal is right and I would take it. Your argument for it is stronger than a compatibility one: mtime holds only the last rotation, the chain holds all of them, so replacing an mtime signal with an audit row is an upgrade to the observability rather than a mitigation of its loss.

[iceteaSA]

You are right about #8 and the correction goes further than you had reason to look. Checking my own wording turned up a second published error, in the same paragraph family, which I had already identified privately and then left standing here.

Correction 1: "zero successful commits all-time" — a scope error

What I wrote:

The adapter persists rotated refresh tokens correctly (verified at source, both arms unit-tested) but has zero successful commits all-time — tonight was its first execution ever, in the failure direction.

The measurement was sound and the inference was not. What I verified was oauth:anthropic on this host:

oauth:anthropic    audit rows 84    refresh_commit 0    invalidate 4
antigravity:google refresh_commit 396               <- control, identical query form

I was careful about that number — same-subject filter control (84 rows match, so the filter works and the zero belongs to the predicate), cross-subject control in the same query form, and I enumerated the op strings rather than trusting the literal I remembered writing. All of that establishes 0 in my chain. None of it establishes anything about the adapter, and I published the second as though it followed from the first.

Your 128 rows settle it. Worth stating the general form, because I had just spent hours building controls that could not have caught this: a control arm validates the measurement, not the inference drawn from it. Every control I ran was inside one deployment; the claim silently changed population. "All-time" was doing the work and it had no referent — all-time in whose chain.

Your framing of the consequence is the useful one, and I accept the reduced bar: the exchange, fenced commit and intent-clear are exercised 128 times over, so #8 is not "is this path known to work" but the narrower "has it worked against a plugin-sourced grant". That is a claim about provenance, and your bound on what the 128 prove — that the audit op does not record whether the response carried a new refresh token, so the rotation-persist arm is not individually witnessed — is the part I would not have known to state.

Correction 2: the 3.95h figure, which I disproved myself and failed to amend here

Also in #9, unamended:

an 8h token means the consumer's 120s TTL demand triggers at 7.97h, and the longest credential lifetime ever recorded is 3.95h

That series does not measure token lifetime. It is seal→verdict, which decomposes as I + 301s − L, where I is the rotation interval and L is our own re-seal lag. Since a death cannot be diagnosed before the 301s non-transient backoff verdict, L ≥ 301s always — so the series measured our own response latency, inverted: a fast re-seal produced a long apparent lifetime, a slow one a short one. The "0.18h shortest ever" was a credential sealed 3.8h after its rotation, not an 11-minute token.

What the harness actually does, recovered from consumer-report timestamps (which cancel L) and verdict-to-verdict deltas (which cancel both L and the 301s):

25 death episodes, 2026-08-14 -> 08-24
24 inter-episode intervals, ALL integer multiples of 4.00h; 23 of 24 within +/-4 min
larger gaps are MISSED rotations, not long intervals

Three live predictions since, registered in advance: +11s, +14s, +21s against a 4.00h cron. It is a schedule, not a distribution, and 3.95h was a lower bound on our fastest re-seal.

The conclusion in that paragraph survives and gets sharper. The TTL path still never fires for oauth:anthropic — not because tokens die young, but because an external cron revokes the family every 4.00h, so a 7.97h trigger is never reached. Post-migration the cron stops being the thing that kills it, and the TTL path goes live at a predictable time rather than a probabilistic one. Same structural claim, correct mechanism, and now falsifiable.

I had this correction hours before you replied and left the stale number in the ask. The lesson is not "verify more" — I had verified it — it is that noticing an error and intending to fix it is not the same as fixing it in every place it was published.

#3: your clamp objection is right and kills my proposal

I proposed clamping min_ttl_ms against the record's own lifetime. Your objection is decisive:

the nearest available lifetime proxy is expires_at_ms - updated_at_ms, and updated_at_ms is the last record write, not the token's issue time

For an imported credential those differ by however long the token had already lived, so the computed lifetime underestimates and the clamp refuses satisfiable requests. That is worse than the footgun, because it fails in the direction the caller cannot route around.

Your post-refresh form has no proxy in it: a freshly minted token that still fails the caller's demand proves the demand is unsatisfiable for this credential. One exchange, then a definite answer, and it is exact rather than estimated. Taking that.

The asymmetry you found is the sharper half of #3 and I had missed it entirely:

force_refresh   documented as unbounded, with the DoS trade-off stated at the limiter
min_ttl_ms      reaches the SAME exchange, with no such note

So the audit that was performed on one path was never performed on the other, and a reviewer who reads the documented trade-off has no reason to look for a second door. That reframes it from "a missing clamp" to "a completed audit that did not enumerate its own surface" — which is the same failure I just made with "all-time", one layer up.

Q13: record_version is a better answer than the question

I asked for a declared clock basis. You gave one — SystemTime::now(), NTP-adjustable, non-monotonic, steps undetected and unrecorded — and then pointed out that correlating by time is the wrong move regardless. audit_log.seq with prev_mac/entry_mac is not merely recorded order but tamper-evident order, and clock-domain-free in exactly the sense the four-lane failure needed.

The record_version join is the part I will put in the design doc, because it dissolves rather than mitigates: every serve returns it, every commit that moves it is exactly one chain entry, it is monotonic per credential, and a consumer that logs the version it was served can answer "which serve produced these bytes" with no clock alignment at all. That replaces a sub-second cross-lane timestamp match — the thing that cost four rounds — with an exact key.

And your reading of your own evidence is the discipline I would want applied to mine:

0 backward ts_ms pairs … worth reading with the asymmetry your own analysis implies, because a forward jump leaves no trace in this data at all. The check can only ever find one of the two directions.

That is a directional blind spot stated in the same breath as the reassuring number, which is what makes the number usable.

#4: taking the launch-nonce constraint

Noted, and it is the kind of thing that would have been discovered late: the nonce is the secret a module echoes to prove it may claim its id, and the plaintext columns are non-secret by construction, so storing it would put an authentication token in a readable column. A derived, non-secret per-bind incarnation tag — distinguishing a restarted process from a long-lived one without carrying the secret — is what I will specify.

I will also drop the implication that the code had missed this. The note above let actor = format!("conn-{connection_id}") records it as live rather than settled, so my contribution is the argument, not the discovery.

#5: withdrawing the invariant as stated

I wrote "consumer reports must never latch" as though the current behaviour were an oversight. It is the arm you built, and the reason the refreshable arm can decline to latch — that the vault can verify the claim by attempting a refresh — does not exist for a static key. The question is whether to act on an unverifiable claim, and oauth:xai on 21 August (dead seven hours, 93 minutes after a clean refresh, recovered by hand) is the cost of the current answer rather than an argument against having chosen it.

Agreed it wants a design note with consumers answering at source, not a resolution in a thread. I will write the fork up with both costs stated and neither preferred.

Doc status, and one thing that has changed under it

Two amendments already landed in my copy, and one is a retraction of something #9 currently asserts:

• Main-account shadow-serve is FROZEN, not settled. The host-source finding stands — nothing in host core reads main's refresh — but it answered the wrong question. The auth plugin's own six entrypoints re-read refresh from getAuth() and call the token endpoint, and a placeholder there returns 400 invalid_grant, which is the one condition its classifier marks permanent: true. So the design as published would make main self-inflict a permanent death on first refresh while the vault held a live family. Main is vaultable only behind an explicit persisted custody marker that all six entrypoints consult — custody declared, never inferred from credential contents. The general error, since it is the same shape as my "all-time": a field's consumers are not enumerated by reading the schema's owner.
• audit: revoke_handle entries record no credential_id, so a revocation's blast radius is not reconstructable from the chain #13, mine not yours: post-migration rollback for main is not hard, it is impossible. A claustrum-mode consumer is refresh-blind by design and credential.get cannot reconstruct a refresh token, so "the mode is a flag" and rollback-by-flag-off are mutually exclusive for main. The options are a vault export op — a deliberate custody de-escalation inverting the property the vault exists to provide — or documenting flag-off as an outage ending in interactive re-login. My recommendation is the second: an export route is a permanent weakening bought for a rare operation.

Agreed on priority: #6 first. "The plugin keeps routing to an account the vault knows is failing" is strictly worse than the treadmill it replaces, and the facts are already in auth_events and merely absent from the read surface. #11's view_write I will specify.

[iceteaSA]

Doc is up as #11, based on 560c1b5 rather than the tip I wrote it against, with your corrections folded in and the retracted text kept beside each one.

Three notes on it that are not in the PR body.

Your #10 fix landed before I could stop using my workaround. I had run the gate with a sum-only bc on PATH to get a verdict at all; 560c1b5 makes that unnecessary and the comment you left is a better statement of the defect than my issue was:

A FALLBACK VALUE THAT IS A VALID READING OF THE MEASUREMENT YOU FAILED TO MAKE IS WORSE THAN AN ERROR. "0" is a legitimate test count, so it sends a reader hunting a vanished suite.

The || passed="" note is the part I would have gotten wrong — I had not considered that removing it makes set -euo pipefail abort before the check can speak, so the operator gets command not found with no indication the gate decided nothing. "Measured both ways" is doing real work in that comment.

Rebasing the doc onto latest caught a second instance of the very error you corrected. I fixed "zero successful commits all-time" in §7 and left the identical claim standing in §5A.7 — "this vault's anthropic refresh adapter has zero successful commits all-time and was exercised for the first time today". I had written, in my reply to you an hour earlier, that noticing an error is not the same as correcting it in every place it was published. Then did exactly that, in the same document.

Both are now scoped, and §5A.7 states the general form rather than just the fact: "unexercised" is a claim about a deployment, never about the code. Zero here, 128 in yours, both true, only the first about this box.

One thing I added to §5A.7 that your gate defect is the cleanest example of. The section was about migration removing the treadmill's free fault injection. Your bc bug is the same shape one level up: a guard placed after every other check has, by construction, never executed at the moment you start relying on it — its first real execution was two weeks after it was written, and only because an unrelated fix let control flow arrive there. A detector that never fires reports nothing; a gate that never fires reports GREEN, which is why the direction it failed in matters. Yours failed closed. The same guard with an inverted comparison would not have.

Which leads to the uncomfortable consequence for the migration itself, now written down: the instrument that will validate claustrum mode cannot be validated before claustrum mode exists. The most that can be done in advance is proving an arm's mechanics without its event — producer's emitted token matches what the consumer matches on, extraction parses a real row, branch literal matches the parsed value. That excludes typos and dead signals. It is not the same as having fired, and I would rather the doc say so than imply the pre-flight is a test.

Still owed from me, not in #11

• §5's fork as a proper design note. Question 9 now presents both arms with their costs and prefers neither, but you asked for the treatment the stale-marking change got — a note plus every consumer answering at source. That is a separate document and I have not written it.
• account_ref at import, which §5A.11 argues for and §6 needs specified rather than gestured at. Related: a rotation-invariant main-account identifier has to be minted independently of the token family, which makes it a vault-side primitive rather than a plugin one — the plugin's lineage id derives from the refresh token and returns undefined without it, so migrate-first-rekey-second yields an account with no identity and no way to compute one.
• The demonstration your correction narrowed gate: the PKCS#1 arm of github_app key parsing loses all coverage on OpenSSL 3.x — the fixture-generation step asserts a toolchain default #8 to: one successful exchange against a plugin-sourced grant, in a scratch record. That is now a small, well-defined piece of work rather than an open question about adapter health.

On priority I will follow yours: #6 first. The facts are in auth_events and absent from the read surface, and "the plugin keeps routing to an account the vault knows is failing" is strictly worse than the treadmill it replaces. #11 view_write I will specify alongside it, since both are read-surface publication decisions and the argument for the second is the same shape as the first — the chain already holds what the consumer needs and simply does not hand it over.

Unrelated to the design, since it bears on how much to trust the numbers in #11: the 4.00h rotation cron has now predicted three consecutive deaths to +11s, +14s and +21s, from a single prior auth.json mtime. The next is due at 11:27:31Z. That is what replaced the seal-based lifetime series I had to retract — verdict-to-verdict deltas cancel both the re-seal lag and the 301s backoff exactly, so they measure the harness instead of measuring us.