From bf3bd6c477d30470e7313fd8436656bd43271b63 Mon Sep 17 00:00:00 2001 From: fred Date: Wed, 26 Aug 2026 19:09:00 -0500 Subject: [PATCH] =?UTF-8?q?docs:=20hierarchy=20schema=20revision=207=20?= =?UTF-8?q?=E2=80=94=20infrastructure=20register=20for=20legitimate=20non-?= =?UTF-8?q?hierarchy=20raw=20execution=20(terra=20F9)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/requirements/hierarchy-schema.md | 32 ++++++++++++++++++++++----- 1 file changed, 27 insertions(+), 5 deletions(-) diff --git a/docs/requirements/hierarchy-schema.md b/docs/requirements/hierarchy-schema.md index 3df5015d..68425f7c 100644 --- a/docs/requirements/hierarchy-schema.md +++ b/docs/requirements/hierarchy-schema.md @@ -50,6 +50,14 @@ runtime code-construction primitives; the detection claim is scoped honestly to the stated syntactic forms, with evasions beyond static reach assigned to §5.1 review/audit rather than claimed for CI. +Revision 7 (terra r6 new F9): the false-positive remedy no longer +contradicts the composition rules — legitimate non-hierarchy raw +execution (e.g. the db package's migration runner) is dispositioned +onto a second closed enumerated list, the infrastructure register, +exempt from prong (iii) only, still bound by prongs (i)/(ii), barred +from the writer allowlist, and importable only by registered modules +or the operational entry points. + Scope: the tenancy/authorization structure record class — companies, estates, platform-projects, workspaces, hierarchy grants, their parentage, and constraints. Out of scope: the RBAC grant vocabulary and evaluation @@ -271,14 +279,28 @@ Binding on the implementing PRs (extends A1 §8.3): allowlisted; and an allowlisted module MUST NOT export a function that executes caller-supplied SQL (such an export is itself a raw-execution primitive, and the exporting module is treated as - unallowlisted for prong (iii) if it does). Runtime code-construction + unallowlisted for prong (iii) if it does). Legitimate raw execution + that is not a hierarchy writer — e.g. the migration runner in the + db package — lives on a second, separately enumerated + **infrastructure register**, distinct from the writer allowlist and + equally closed. A registered module is exempt from prong (iii) only: + prongs (i) and (ii) apply to it with no exemption, so it can hold no + class-table schema symbol or class-table SQL literal, and it can + never appear on the writer allowlist. To close the laundering path, + the same assertion checks imports: a module on the infrastructure + register may be imported only by other registered modules or by the + enumerated operational entry points (migration/bootstrap CLI), never + by Gateway or application sources — an import from anywhere else + fails the assertion. Runtime code-construction primitives (`eval`, `new Function`) anywhere in the scanned sources fail the assertion outright, allowlist or not. Schema definitions and generated migrations are excluded from the literal prong; a - false positive (e.g. a table name in a non-write query string, or a - legitimate raw query elsewhere in the codebase) is resolved by - extending the allowlist in the same PR, never by weakening the - assertion. The allowlist is closed, and the assertion's detection + false positive is resolved in the same PR by adding the module to + the one enumerated list its role permits — the writer allowlist for + a hierarchy command/repository module, the infrastructure register + for non-hierarchy raw execution — never by weakening the assertion, + and neither list may take a module the composition rules bar from + it. Both lists are closed, and the assertion's detection claim is exactly its prongs: it statically surfaces every writer expressed as a schema-symbol reference, a class-table SQL literal, a raw-execution call site, or runtime code construction. An evasion