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

docs/PRD.md

@@ -139,8 +139,10 @@ custody rule in §7.
   and similar) live in the **user's own brain ONLY**. PostgreSQL holds
   structural data, consent records, and pointers — never the content. "User
   data does not leak" is enforced by architecture, not policy (D14).
-- Standalone (one user, one brain) keeps the same split for
-  forward-compatibility with the one-way Enterprise conversion (D3).
+- Standalone (one user, one brain) **may** keep the same split — D14 makes it
+  optional in Standalone, not required. Keeping it is the recommended default
+  because it preserves forward-compatibility with the one-way Enterprise
+  conversion (D3).
 - Estate brains hold operational records. Only product-relevant material
   migrates into this repository's docs; operational records stay in their
   brains and are linked (D6).
@@ -155,8 +157,9 @@ directly.
 
 Consequence for planning: when a desired webUI operation has no backing tool,
 the gap is scored **"blocked on tooling"** and the tool is built first. The
-product baseline therefore always includes the tool inventory and the
-webUI→tool mapping.
+product baseline therefore always includes all three D8 inputs: the tool
+inventory (what exists and what is missing), the webUI→tool mapping, and the
+measured current state of the `next` branch.
 
 ### 9. v1 slice (D11)
 
@@ -181,8 +184,11 @@ agent fleet that builds and operates the system should run (NS-1..NS-10,
 workstreams A–L). This PRD is the **product** north star. They are not
 competitors: the fleet north star is subordinate product-wise — its workstream
 J ("Web control plane") is one consumer of this PRD's D8/D12 gate — and this
-PRD does not redefine fleet invariants. A change that would put the two in
-conflict must amend one of them explicitly, never fork a third document.
+PRD does not redefine fleet invariants. The subordination rule is ratified in
+the frozen audit-input baseline (T2 operator freeze, 2026-08-25: "the PRD must
+cite and subordinate it, never fork it"). A change that would put the two in
+conflict must amend one of them explicitly, never fork a third document
+(drafting addition — see §12.1).
 
 ### 11. Explicit non-goals
 
@@ -201,7 +207,7 @@ conflict must amend one of them explicitly, never fork a third document.
 | D4  | Re-runnable, extensible, per-mode onboarding wizards                                                               |
 | D5  | North star = this rewrite of docs/PRD.md; stack docs/ = product SSOT                                               |
 | D6  | Only product-relevant material migrates from brains; operational records stay and link                             |
-| D7  | Spec-inventory sweep launched immediately (executed; frozen INPUTS baseline in the audit lane)                     |
+| D7  | Spec-inventory sweep launched immediately (executed; INPUTS baseline frozen by operator ruling T2, 2026-08-25)     |
 | D8  | webUI sits over official framework tooling; CLI primary                                                            |
 | D9  | Not a hosted business; company = organizational separation for one operator                                        |
 | D10 | better-auth is the account system of record; external IdPs via OIDC                                                |
@@ -213,6 +219,23 @@ conflict must amend one of them explicitly, never fork a third document.
 The full decision texts are recorded in the operator decision log (USC estate
 brain, webui-audit lane, `GRILL.md`).
 
+### 12.1 Drafting additions beyond D1–D14
+
+Independent review of this rewrite identified rules in this document that are
+not present in the D1–D14 record or the frozen T2 baseline. They are listed
+here so their ratification is explicit: approval of the PR that introduces
+this document, by the decision owner, ratifies them. If any is rejected it is
+removed, not silently kept.
+
+1. **Federation forward-compatibility gate:** "nothing in v1 may foreclose
+   federation" (§3), and scoping federation later requires its own PRD plus
+   threat model ([ROADMAP](./ROADMAP.md) P5). D3 defers federation; these
+   protective gates are additions.
+2. **North-star amendment rule:** a product/fleet north-star conflict must be
+   resolved by amending one of the two documents explicitly, never by forking
+   a third (§10). The subordination itself is T2-ratified; this amendment
+   procedure is an addition.
+
 ---
 
 ## Part II — Active workstream contracts (preserved unchanged)

docs/ROADMAP.md

@@ -20,7 +20,7 @@ and are prerequisites where noted.
 | ----- | ------------------------------------------------------------------------------ | ----------------------------------------- |
 | P0    | Current state on `next`: read-only dashboard, chat, auth/SSO login, admin tabs | shipped, evolving                         |
 | P1    | **v1 slice** (PRD Part I §9)                                                   | next up                                   |
-| P2    | Connectors + comms                                                             | placeholder                               |
+| P2    | Connectors + comms + wizard expansion                                          | placeholder                               |
 | P3    | Full onboarding profile + M365                                                 | placeholder                               |
 | P4    | Enterprise mode + one-way conversion                                           | placeholder                               |
 | P5    | Federation                                                                     | placeholder (deliberately undesigned, D3) |
@@ -45,17 +45,23 @@ P1.
 Prerequisites: KBN-100/101 schema foundation; the D8 tool inventory and
 webUI→tool mapping (any missing tool is built first, D12).
 
-## P2 — connectors + comms (placeholder)
+## P2 — connectors + comms + wizard expansion (placeholder)
 
 Email and drive connectors (Gmail/IMAP, Google Drive/OneDrive/Dropbox) with
 granular agentic-access consent; comms integrations (Matrix/Discord/Slack)
-including agent auto-enroll. Wizard gains the corresponding tabs (D4).
+including agent auto-enroll. Wizard gains the corresponding tabs (D4), plus
+the D4 capabilities deferred out of P1's minimal slice: expanded agent
+enrollment (OAuth login, multi-account, model choice with recommendation,
+account assignment, comms auto-enroll) and the Standalone SSO/OIDC
+configuration tab.
 
 ## P3 — full onboarding profile + M365 (placeholder)
 
 Complete user onboarding profile (communication-style capture, optional
-voice-matching interview) under the D14 custody rule; M365 integration for
-Enterprise-leaning deployments.
+voice-matching interview) under the D14 custody rule; M365 connectors,
+available to both deployment modes as ordinary connectors (same consent model
+as the P2 connector class). The Enterprise install flow's M365 prominence
+(D4) arrives with the Enterprise phase, P4.
 
 ## P4 — Enterprise mode + conversion (placeholder)
 

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)