docs/prd: address independent review findings 1-10 (fidelity, A1 record class + carve-out, roadmap completeness)

docs/requirements/native-kanban-sot.md

@@ -377,9 +377,10 @@ P0–P3 may close only when requirements traceability maps every requirement abo
 
 **Status:** amendment to the ratified canon, added by reviewed PR under
 decision D13 (operator ruling, 2026-08-25; decision owner Jason). It adds
-parent structure ABOVE workspaces. It weakens nothing below this line:
-sections 1–7, every invariant in §3, and every REQ above remain binding
-verbatim.
+parent structure ABOVE workspaces. Sections 1–7, every invariant in §3, and
+every REQ above remain binding verbatim, with exactly one express modification:
+the narrow portfolio-analytics carve-out stated in §8.2.4. Nothing else below
+this line is weakened.
 
 ### 8.1 What is added
 
@@ -387,7 +388,22 @@ verbatim.
    **company/organization → estate → platform-project → workspace**. Each
    workspace belongs to exactly one platform-project, each platform-project to
    exactly one estate, each estate to exactly one company.
-2. The hierarchy is used for exactly two things:
+2. **Record class.** Hierarchy records (company, estate, platform-project,
+   their parentage edges, and hierarchy-level access grants) are a new,
+   explicitly named record class: **tenancy/authorization structure records**.
+   They are not business or orchestration records, so §3 invariant 10 and
+   REQ-TEN-001 do not apply to them and are not weakened by them — those two
+   requirements bind business/orchestration rows exactly as before.
+   Constraints on the new class:
+   - Hierarchy tables MUST NOT carry task, plan, or any other
+     business/orchestration payload — parentage, naming, and grant data only.
+   - A hierarchy record can never be the subject of work: it cannot be
+     claimed, ordered, gated, or referenced as a dependency by any
+     business/orchestration row.
+   - Hierarchy mutations flow through the same sole-writable-SOT, fail-closed,
+     audited mutation path as everything else (§8.2.3).
+3. The hierarchy serves exactly two runtime functions, plus audited
+   maintenance of its own structure:
    - **RBAC evaluation:** access grants are declared per company, estate, or
      platform-project and evaluate down the chain to workspace-scoped
      authorization. Tenant context continues to be derived from authenticated
@@ -395,7 +411,14 @@ verbatim.
      not a bypass of workspace authorization.
    - **Read-only roll-ups:** task and status visualization bubbles up the
      hierarchy as aggregation over workspaces the reader is authorized on.
-3. Naming: this amendment says **platform-project** for the hierarchy level
+   - **Chain maintenance (not a third runtime function):** re-parenting an
+     asset — moving a workspace to another platform-project, a
+     platform-project to another estate, and so on ("assets are transferable
+     subject to the structure", PRD Part I §4) — is an audited edit of the
+     hierarchy records themselves under §8.3. It never modifies
+     business/orchestration rows and never crosses a workspace boundary for
+     them; the workspace's contents move with the workspace untouched.
+4. Naming: this amendment says **platform-project** for the hierarchy level
    above workspaces, because §5 REQ-PLAN-001 already defines `projects` as
    planning entities INSIDE a workspace. The two are different objects. Final
    terminology (rename of one or the other) is an implementation-PR decision
@@ -413,7 +436,15 @@ verbatim.
 3. Fail-closed mutation health (§3 invariants 3–4), sole writable PostgreSQL
    SOT, fencing, audit, and the Coordinator/Certifier authority rules are
    untouched.
-4. Nothing here authorizes the §6 non-goals.
+4. No §6 non-goal is authorized, with one express, narrow carve-out that this
+   amendment makes to the "portfolio analytics" non-goal: the read-only
+   roll-up of §8.1 — per-workspace task counts and statuses aggregated up the
+   parent chain, over workspaces the reader is authorized on — is in scope.
+   Everything beyond that boundary (metrics, trends, forecasting, scoring,
+   dashboards computed across workspaces, any derived analytic that is not a
+   direct count/status aggregation) remains a non-goal. This is an explicit
+   narrowing by amendment, not a claim that §6 is unchanged; every other §6
+   non-goal is untouched.
 
 ### 8.3 Acceptance (binding on the implementing PRs)