From f07b4c73b18f6247418f2ca5fd7e9ab7ff07638e Mon Sep 17 00:00:00 2001 From: fred Date: Wed, 26 Aug 2026 19:18:11 -0500 Subject: [PATCH] =?UTF-8?q?docs:=20hierarchy=20schema=20revision=208=20?= =?UTF-8?q?=E2=80=94=20re-export-aware=20import=20analysis,=20per-module?= =?UTF-8?q?=20importer=20enumeration=20(terra=20F9=20residual)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/requirements/hierarchy-schema.md | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/docs/requirements/hierarchy-schema.md b/docs/requirements/hierarchy-schema.md index 68425f7c..339cba66 100644 --- a/docs/requirements/hierarchy-schema.md +++ b/docs/requirements/hierarchy-schema.md @@ -58,6 +58,13 @@ 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. +Revision 8 (terra r7 residual F9): the register's import rule made +satisfiable by the live tree — imports are checked re-export-aware +(package barrels followed), and each registered module carries its own +closed importer enumeration, which may name operational entry points +such as the Gateway's startup migration hook; named importers stay +subject to prongs (i)/(ii) and gain no writer standing. + 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 @@ -287,11 +294,21 @@ Binding on the implementing PRs (extends A1 §8.3): 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 + the same assertion checks imports, and the import analysis is + **re-export-aware**: it follows package barrels and re-exports, so a + route hidden behind an index module is still a route. A registered + module may be imported only by other registered modules or by + importers named on that module's own closed importer enumeration in + the register — operational entry points such as the + migration/bootstrap CLI or the Gateway's startup migration hook + (the runner's one live importer today, the Gateway database module + reached through the db package barrel, is such an entry point and + is named in the enumeration, not exempted from analysis). Any + import route outside the enumeration fails the assertion. Being a + named importer confers nothing else: the importer stays fully + subject to prongs (i) and (ii), gains no writer-allowlist standing, + and whether it uses the registered module beyond its operational + purpose is a §5.1 review question, not a static claim. 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