From 7810d6e337e3b664526bb8017f0f80e12ad2b312 Mon Sep 17 00:00:00 2001 From: LogicDuke Date: Thu, 20 Aug 2026 19:43:09 +0200 Subject: [PATCH] docs: allow identity-preserving provider resolution Co-Authored-By: Claude Opus 4.8 --- docs/architecture/C1-repair-job-authority.md | 20 +++++++++++++------- src/domain/repair-job.ts | 9 +++++---- 2 files changed, 18 insertions(+), 11 deletions(-) diff --git a/docs/architecture/C1-repair-job-authority.md b/docs/architecture/C1-repair-job-authority.md index 51b16c8..7d07781 100644 --- a/docs/architecture/C1-repair-job-authority.md +++ b/docs/architecture/C1-repair-job-authority.md @@ -286,13 +286,19 @@ established. Because this operation performs no ref update to guard, the boundar that consumes these identities is the change-request/provider creation — or update — request itself, and the established source and target identities must be **bound through to that provider request**: the provider must create the request -from exactly the authorized effective source and target, and must not -independently re-resolve the ref names, derive the source or target from ambient -repository state, or otherwise act on an identity that has changed since it was -established. If that authorized source-to-target relationship cannot be maintained -through to the provider request — because an effective identity has changed, or -cannot be safely re-established at that boundary — the boundary must fail closed -and create no change request. +from exactly the authorized effective source and target. Provider-side resolution +of the supplied ref names is not itself forbidden — a create/update API may have +to resolve the source and target names against its own authoritative repository +state — but it must yield exactly those authorized effective identities: it must +not let re-resolution, ambient repository state, or any substitution cause the +request to be created from, or to consume, a **materially different** effective +source or target than the one authorized. Resolution that preserves the exact +authorized source-to-target relationship conforms; resolution that would consume +a materially different effective identity does not. If that authorized +source-to-target relationship cannot be maintained through to the provider +request — because an effective identity has changed, cannot be safely +re-established, or cannot be shown equivalent to the authorized one at that +boundary — the boundary must fail closed and create no change request. *Concurrency is not closed by a pre-check.* A resolve-then-check-then-act sequence is **not** an atomic security guarantee: an effective ref or referent can diff --git a/src/domain/repair-job.ts b/src/domain/repair-job.ts index a1a5e31..8287b5b 100644 --- a/src/domain/repair-job.ts +++ b/src/domain/repair-job.ts @@ -538,10 +538,11 @@ function endsWithDotLockSuffix(value: string, start: number, end: number): boole * the protected parent ref, and fails closed when it reaches anything else. Because * that operation mutates no ref, the identity it consumes is bound at its provider * create/update request: the effective source must remain the authorized repair ref - * and the effective target the protected parent ref through to that request, the - * provider must not independently re-resolve those refs or derive them from ambient - * repository state, and the boundary must fail closed if that relationship cannot be - * maintained there. + * and the effective target the protected parent ref through to that request. The + * provider may resolve those ref names at its own boundary, but must not let + * re-resolution or ambient repository state substitute a materially different + * effective identity for either end, and the boundary must fail closed if the + * authorized relationship cannot be maintained or shown equivalent there. * Nothing here acquires git invocation, filesystem access, a subprocess, or * network to decide it. See `docs/architecture/C1-repair-job-authority.md`, * "What canonical ref names do and do not prove".