diff --git a/docs/PRD.md b/docs/PRD.md index 5bb92408..016165f9 100644 --- a/docs/PRD.md +++ b/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) diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index d1bd21ef..306f9f78 100644 --- a/docs/ROADMAP.md +++ b/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) diff --git a/docs/requirements/native-kanban-sot.md b/docs/requirements/native-kanban-sot.md index da9865ff..9ba524fe 100644 --- a/docs/requirements/native-kanban-sot.md +++ b/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)