docs(ndo): add NDO Prima Materia specification and integrate across docs (#66)

* NDO prima materia requirements, Flowsta/Unyt stubs, and doc/zome updates

- Expand ndo_prima_materia and requirements; add flowsta-integration stub
- Refresh governance, resource, person zome docs and architecture index
- Align integrity zomes (gouvernance, person) with documented model
- Update CLAUDE.md, README, archives, and cross-zome governance specs

Made-with: Cursor

* docs(governance): update PPR_Security_Implementation to include inspiration source

- Added a note referencing Mark Lizar's work on Digital Notice Consent at the OPN lab as an inspiration for the PPR system.

Author: TiberiusB

CLAUDE.md

@@ -87,6 +87,13 @@ nondominium is a **3-zome Holochain hApp** implementing ValueFlows-compliant res
 - **ValueFlows Compliance**: EconomicResource, EconomicEvent, Commitment data structures
 - **Embedded Governance**: Resources contain governance rules for access/transfer
 
+### Documentation (NDO & post-MVP integrations)
+
+- **Normative NDO / capability requirements:** `documentation/requirements/ndo_prima_materia.md` (REQ-NDO-*, §6.6 Unyt, §6.7 Flowsta)
+- **Master index:** `documentation/DOCUMENTATION_INDEX.md`
+- **Integration stubs:** `documentation/requirements/post-mvp/unyt-integration.md`, `documentation/requirements/post-mvp/flowsta-integration.md`
+- **Ontology archives:** `documentation/archives/resources.md`, `agent.md`, `governance.md`
+
 ## Key Development Patterns
 
 ### Entry Creation Pattern

README.md

@@ -49,6 +49,8 @@ nondominium implements a modular governance-as-operator architecture that separa
 - Testing: Vitest 3.1.3 + @holochain/tryorama 0.18.2
 - Client: @holochain/client 0.19.0
 
+**Documentation map:** See [documentation/DOCUMENTATION_INDEX.md](documentation/DOCUMENTATION_INDEX.md). Post-MVP **NDO** model and optional **Unyt** / **Flowsta** integrations are specified in [documentation/requirements/ndo_prima_materia.md](documentation/requirements/ndo_prima_materia.md) and the stubs under [documentation/requirements/post-mvp/](documentation/requirements/post-mvp/).
+
 ## Environment Setup
 
 > **PREREQUISITE**: Set up the [Holochain development environment](https://developer.holochain.org/docs/install/).

dnas/nondominium/zomes/integrity/zome_gouvernance/src/lib.rs

@@ -14,7 +14,8 @@ pub enum VfAction {
   // Standard ValueFlows production/consumption actions
   Use, // Use a resource without consuming it
 
-  // TODO: No consumable in the PoC, but we have to think about hte end of life of a resource.
+  // TODO: No consumable in the PoC, but end-of-life / Consume flows need design alignment with
+  // lifecycle stages — see `documentation/requirements/ndo_prima_materia.md` §5.3, REQ-GOV-11–13.
   Consume, // Consume/destroy a resource
   Produce, // Create/produce a new resource
   Work,    // Apply work/labor to a resource

dnas/nondominium/zomes/integrity/zome_person/src/lib.rs

@@ -27,11 +27,14 @@ use std::{fmt::Display, str::FromStr};
 //
 // TODO (G15 — CapabilitySlot on Agent): The `Person` entry hash should serve as a stigmergic
 // attachment surface for external capabilities — analogous to the NondominiumIdentity
-// CapabilitySlot in ndo_prima_materia.md §6. Add a `PersonCapabilitySlot` link type:
+// CapabilitySlot surface in `documentation/requirements/ndo_prima_materia.md` §6. Add a
+// `PersonCapabilitySlot` link type:
 //   PersonCapabilitySlot: Person hash → capability target (DID document, credential wallet,
 //                                                           reputation oracle, external registry)
 // Implement `attach_agent_capability_slot` and `get_agent_capability_slots` coordinator
-// functions. See `REQ-AGENT-11` and `ndo_prima_materia.md` §6.5.
+// functions. See `REQ-AGENT-11`, `ndo_prima_materia.md` §6.5 (Person attachment surface),
+// §6.7 + REQ-NDO-CS-12–CS-15 (Flowsta `FlowstaIdentity` / `IsSamePersonEntry`), and
+// `documentation/requirements/post-mvp/flowsta-integration.md`.
 
 /// Represents a person's public profile with basic information
 #[hdk_entry_helper]

documentation/ARCHITECTURE_COMPONENTS.md

@@ -121,7 +121,7 @@ graph TB
         end
 
         subgraph "Private Data Sharing"
-            DataReq["DataAccessRequest<br/>7-day Expiration"]
+            DataReq["DataAccessRequest<br/>time-limited (max 30d)"]
             DataGrant["DataAccessGrant<br/>Field-specific Control"]
             PrivateData["PrivateDataEntry<br/>Encrypted Info"]
         end
@@ -157,7 +157,7 @@ graph TB
 │ └── Access Control Lists (resource permissions)             │
 │                                                             │
 │ 1.3 PRIVATE DATA SHARING                                    │
-│ ├── DataAccessRequest Entry (7-day expiration)              │
+│ ├── DataAccessRequest Entry (time-limited; max 30-day grants) │
 │ ├── DataAccessGrant Entry (field-specific control)          │
 │ └── PrivateDataEntry (encrypted personal information)       │
 │                                                             │
@@ -582,12 +582,12 @@ fn authorize_process_data_access(
         .find(|r| r.matches_process_requirements(&process))
         .ok_or(DataAccessError::InsufficientRole)?;
 
-    // Create time-limited grant (7-day expiration)
+    // Illustrative pseudocode — align grant duration with zome_person capability rules (30-day max).
     let grant = DataAccessGrant {
         requesting_agent,
         granting_agent: process.resource_owner,
         accessible_fields: required_fields,
-        expires_at: sys_time()? + Duration::from_secs(7 * 24 * 60 * 60), // 7 days
+        expires_at: sys_time()? + Duration::from_secs(7 * 24 * 60 * 60), // example: 7 days; cap 30 days in MVP metadata
         purpose: format!("Data access for {} process", process.process_type),
         process_context: process.hash,
     };
@@ -694,7 +694,7 @@ Reputation Derivation:
 ```
 Data Access Control:
 ├── Field-Level Granularity (specific data elements)
-├── Time-Limited Grants (7-day maximum)
+├── Time-Limited Grants (30-day maximum per capability metadata)
 ├── Purpose Binding (process-specific usage)
 ├── Automatic Expiration (system-enforced)
 ├── Audit Trail (access logging)

documentation/DOCUMENTATION_INDEX.md

@@ -95,7 +95,7 @@ nondominium implements a **Governance-as-Operator** architecture that separates
 - **🔐 Capability-Based Security**: Progressive trust model (Simple → Accountable → Primary Accountable Agent)
 - **📋 Private Participation Receipts (PPRs)**: Cryptographic reputation tracking across 16 categories
 - **🔄 Economic Processes**: Structured workflows (Use, Transport, Storage, Repair) with role-based access
-- **🛡️ Private Data Sharing**: Request/grant workflows with field-level control and 7-day expiration
+- **🛡️ Private Data Sharing**: Request/grant workflows with field-level control and time-limited grants (30-day maximum per `PrivateDataCapabilityMetadata`; shorter defaults may apply in UI flows — see [person_zome.md](documentation/zomes/person_zome.md))
 
 ---
 
@@ -152,7 +152,7 @@ nondominium implements a **Governance-as-Operator** architecture that separates
 **Private Data Sharing**
 
 - `request_private_data_access()` - Request access to specific fields
-- `grant_private_data_access()` - Grant time-limited access (7-day expiration)
+- `grant_private_data_access()` - Grant time-limited access (subject to 30-day maximum enforced in capability metadata)
 - `get_private_data()` - Retrieve authorized private data
 - `revoke_private_data_access()` - Revoke granted permissions
 
@@ -276,7 +276,7 @@ bun run test:debug           # Verbose test output for debugging
 
 ### ✅ Phase 2 Complete: Advanced Governance & Reputation
 
-- **Capability-Based Sharing**: Complete request/grant workflows with 7-day expiration
+- **Capability-Based Sharing**: Complete request/grant workflows with time-limited grants (30-day cap; see person zome docs)
 - **PPR System**: 16-category reputation tracking with cryptographic signatures
 - **Economic Processes**: Four structured processes (Use, Transport, Storage, Repair)
 - **Multi-Reviewer Validation**: 2-of-3, N-of-M, and simple majority validation

documentation/archives/IMPLEMENTATION_STATUS.md

@@ -425,6 +425,22 @@ bun run package          # Final .webhapp distribution
 
 ---
 
+## Post-MVP design specifications (not in shipped DNA yet)
+
+The following are **documented and traceable** to REQ-NDO-* in `documentation/requirements/ndo_prima_materia.md` but **not implemented** in the current MVP codebase unless noted otherwise:
+
+| Track | Design sources | Implementation status |
+| ----- | -------------- | ---------------------- |
+| **NDO three-layer model** | `ndo_prima_materia.md` §§4, 8, 10; `resources.md` §3 | Not started — MVP uses flat `ResourceSpecification` + `EconomicResource` |
+| **Lifecycle vs operational state split** | `ndo_prima_materia.md` §5, §9.4 (`REQ-NDO-OS-01`–`06`) | Not started — `ResourceState` still conflated (see zome_resource TODOs) |
+| **Unyt (EconomicAgreement, RAVE)** | `ndo_prima_materia.md` §6.6, §11.5; `unyt-integration.md`; REQ-NDO-CS-07–CS-11 | Not started — no Unyt cell / RAVE validation in governance zome |
+| **Flowsta (agent linking, IdentityVerification)** | `ndo_prima_materia.md` §6.7, §11.6; `flowsta-integration.md`; REQ-NDO-CS-12–CS-15 | Not started — `flowsta-agent-linking` zomes not bundled; `GovernanceRule` remains untyped strings |
+| **Person capability slot (G15)** | `agent.md` §3.2; `person_zome.md`; REQ-AGENT-11, REQ-NDO-AGENT-07 | Not started — no `FlowstaIdentity` links on `Person` hash |
+
+See `documentation/archives/implementation_plan.md` §10 for a phased checklist aligned with prima materia.
+
+---
+
 ## Conclusion
 
 The nondominium hApp represents a **complete, production-ready implementation** of a sophisticated ValueFlows-compliant resource sharing ecosystem with advanced privacy controls and revolutionary reputation mechanics. All major components are fully implemented, thoroughly tested, and ready for deployment.