Finding
ValidationPrincipal is structurally immutable when created through its public constructor, but predecessor #235 head a04c8b4cd58145f9e74a085d3fdb037d90966012 trusted type(principal) is ValidationPrincipal and read tuple slots directly into PurposeBoundAccessRequest without reconstructing/revalidating those stored scalars.
Low-level tuple.__new__(ValidationPrincipal, (...)) can manufacture an exact runtime instance while bypassing ValidationPrincipal.__new__. A forged exact instance can therefore carry a UUID subtype or other non-canonical identity evidence. The protected Keyverse adapter deliberately remains subclass-compatible; its UUID validation uses isinstance(..., UUID) and then reads .int. A caller-defined UUID subtype could therefore execute behavior before the workforce-validation owner boundary established inert canonical identity evidence.
Test-first repair lineage
60f5ba9d1b43ba75fd2d7f042153f7b43eff902b: causal regression constructing an exact principal through tuple.__new__ with an executable UUID subtype. The owner read boundary must reject it before subtype behavior or persistence. Hosted RED is not claimed because the branch advanced before this head executed.4ef7ad130e4d0aa314ea59de3dafaea79cc0630c: minimal production repair. read_validity_study(...) reconstructs the exact outer principal through canonical ValidationPrincipal(...) validation and uses only that reconstructed principal for authorization attributes. CodeRabbit reviewed exact 4ef7ad1... against protected develop@eb9757f... and reported no blocking issue in this requested scope.
The canonical #235 branch subsequently advanced ordinarily through #240 to exact ccb5c0c58dc74c1d7eee59431e6337c207fcac35. #240 changes only repository-capability validation before authorization; the #239 principal reconstruction remains intact and still occurs before PurposeBoundAccessRequest/Keyverse evaluation.
Acceptance state
Current exact-head Foundation 33954469089 / Repository quality 101275139627 is queued before checkout (steps=[], ubuntu-24.04, no runner assigned). Security 33954468968, SAST 33954468946, and CodeQL PR 33954468879 are non-terminal. No hosted GREEN/100% coverage/PostgreSQL/security completion is claimed. A fresh CodeRabbit review is pending on current #240 successor; predecessor review evidence is not used as current-head merge authority.
Keep this issue open until the canonical successor exact head has hosted Foundation/PostgreSQL/security acceptance and normal protected integration evidence. Preserve #236/#237 structural immutability, #238 owner-role semantics, #240 fail-fast inert repository-capability validation, purpose-bound authorization-before-persistence, field minimization, and the owner-port contract.
Finding
ValidationPrincipalis structurally immutable when created through its public constructor, but predecessor #235 heada04c8b4cd58145f9e74a085d3fdb037d90966012trustedtype(principal) is ValidationPrincipaland read tuple slots directly intoPurposeBoundAccessRequestwithout reconstructing/revalidating those stored scalars.Low-level
tuple.__new__(ValidationPrincipal, (...))can manufacture an exact runtime instance while bypassingValidationPrincipal.__new__. A forged exact instance can therefore carry a UUID subtype or other non-canonical identity evidence. The protected Keyverse adapter deliberately remains subclass-compatible; its UUID validation usesisinstance(..., UUID)and then reads.int. A caller-defined UUID subtype could therefore execute behavior before the workforce-validation owner boundary established inert canonical identity evidence.Test-first repair lineage
60f5ba9d1b43ba75fd2d7f042153f7b43eff902b: causal regression constructing an exact principal throughtuple.__new__with an executable UUID subtype. The owner read boundary must reject it before subtype behavior or persistence. Hosted RED is not claimed because the branch advanced before this head executed.4ef7ad130e4d0aa314ea59de3dafaea79cc0630c: minimal production repair.read_validity_study(...)reconstructs the exact outer principal through canonicalValidationPrincipal(...)validation and uses only that reconstructed principal for authorization attributes. CodeRabbit reviewed exact4ef7ad1...against protecteddevelop@eb9757f...and reported no blocking issue in this requested scope.The canonical #235 branch subsequently advanced ordinarily through #240 to exact
ccb5c0c58dc74c1d7eee59431e6337c207fcac35. #240 changes only repository-capability validation before authorization; the #239 principal reconstruction remains intact and still occurs beforePurposeBoundAccessRequest/Keyverse evaluation.Acceptance state
Current exact-head Foundation
33954469089/ Repository quality101275139627is queued before checkout (steps=[],ubuntu-24.04, no runner assigned). Security33954468968, SAST33954468946, and CodeQL PR33954468879are non-terminal. No hosted GREEN/100% coverage/PostgreSQL/security completion is claimed. A fresh CodeRabbit review is pending on current #240 successor; predecessor review evidence is not used as current-head merge authority.Keep this issue open until the canonical successor exact head has hosted Foundation/PostgreSQL/security acceptance and normal protected integration evidence. Preserve #236/#237 structural immutability, #238 owner-role semantics, #240 fail-fast inert repository-capability validation, purpose-bound authorization-before-persistence, field minimization, and the owner-port contract.