Record the owner decision: Qonto rotation deferred, not refused

The repository owner declined to schedule the rotation now. Recorded with the
reasoning rather than as a bare status so it is revisited on evidence instead of
re-litigated: nothing indicates compromise, the offer stands open, and one
founder-attended window is already pending for the fail-closed startup changes.

Names what should reopen it -- an actual or suspected exposure, the secret's age
becoming a stated concern, a consumer requiring proof of rotation, or a decision
to prove rotation step 4 before relying on it -- and says plainly that a calendar
date is not one of them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016uV8zoCKpA1WRAxsKRYbdH

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1182213@bnt-lap001
Assistant-Session: 966597b9-ae61-46a4-8b9e-1594ab3ec4ad
This commit is contained in:
tegwick 2026-09-10 09:15:48 +02:00
parent ed67780da8
commit 324b5e056d

View file

@ -309,3 +309,23 @@ If the rotation is scheduled, it is also the first opportunity to close the
`real_predecessor_rotation_tested: false` gap recorded above — `verify-client`
with `-previous-secret-env` is exactly step 4, and the predecessor would finally
be genuinely distinct.
**Decision, 2026-09-10: not yet.** The repository owner declined to schedule the
rotation now. Recorded with the reasoning so it is revisited on evidence rather
than re-litigated from scratch: nothing indicates compromise, the offer stands
open, and the estate already has one founder-attended window pending for the two
fail-closed startup changes. Rotating for hygiene alone, in a second attended
session, against a credential with no incident attached, is work the owner chose
not to spend now.
This is a deferral, not a refusal, and the thing that should reopen it is a
change in evidence rather than the passage of time: an actual exposure or
suspected one (see KEY-WP-0011), the Qonto secret's age becoming a stated concern,
a consumer requiring proof of rotation, or a decision to prove rotation step 4
before relying on it elsewhere. Any of those makes the answer different; a
calendar date does not.
T04 therefore stays `wait` with nothing outstanding from any counterparty. The
authority is answered, the transport named, the CCR offered on request, and
`verify-client` is ready for step 4 whenever a window is chosen. Nobody is waiting
on KeyCape, and KeyCape is waiting on a decision that has now been taken.