From 5563edba89c59b1b4c3b77100eedd8529f05391c Mon Sep 17 00:00:00 2001 From: Soushi888 Date: Tue, 3 Nov 2026 17:52:53 -0500 Subject: [PATCH] docs(requirements): add group model requirements for Moss and standalone --- documentation/DOCUMENTATION_INDEX.md | 2 +- documentation/requirements/lobby-dna.md | 119 +++++++++++++++++---- documentation/requirements/requirements.md | 19 +++- 3 files changed, 119 insertions(+), 21 deletions(-) diff --git a/documentation/DOCUMENTATION_INDEX.md b/documentation/DOCUMENTATION_INDEX.md index 61900c17..2ca4dc19 100644 --- a/documentation/DOCUMENTATION_INDEX.md +++ b/documentation/DOCUMENTATION_INDEX.md @@ -158,7 +158,7 @@ nondominium implements a **Governance-as-Operator** architecture that separates | Document | Description | Status | | --- | --- | --- | -| **[Lobby DNA Requirements](requirements/lobby-dna.md)** | Multi-network federation: Lobby DNA, Group DNA, NDO extensions (REQ-LOBBY-*, REQ-GROUP-*, REQ-NDO-EXT-*) | βœ… Lobby + Group DNAs shipped (#103, #107); NDO-level extensions in progress (#112) | +| **[Lobby DNA Requirements](requirements/lobby-dna.md)** | Multi-network federation: Lobby DNA, Group DNA, NDO extensions, group model by deployment mode, work contexts, sovereignty levels (REQ-LOBBY-*, REQ-GROUP-*, REQ-WC-*, REQ-SOV-*, REQ-FED-*, REQ-NDO-EXT-*) | βœ… Lobby + Group DNAs shipped (#103, #107); NDO-level extensions in progress (#112) | | **[Unyt Integration](requirements/post-mvp/unyt-integration.md)** | Economic settlement, Smart Agreements, RAVE proofs, PPR↔RAVE provenance | πŸ”„ Post-MVP | | **[Flowsta Integration](requirements/post-mvp/flowsta-integration.md)** | Cross-app identity (IsSamePersonEntry, FlowstaIdentity, DID, key recovery) | πŸ”„ Post-MVP | | **[NDO Versioning](requirements/post-mvp/ndo-versioning.md)** | DAG-based version graph, fork/merge/repair relations, contribution propagation | πŸ”„ Post-MVP | diff --git a/documentation/requirements/lobby-dna.md b/documentation/requirements/lobby-dna.md index 16ce9985..bf8de6f7 100644 --- a/documentation/requirements/lobby-dna.md +++ b/documentation/requirements/lobby-dna.md @@ -1,9 +1,8 @@ # Lobby DNA: Multi-Network Federation Requirements -**Status**: Partially implemented β€” Lobby DNA and NDO federation extensions landed in PR #103; -Group DNA in progress (#101); MVP UI uses a localStorage group shell until Group DNA ships +**Status**: Partially implemented. Lobby DNA and NDO federation extensions landed in PR #103, Group DNA in PR #107, DHT-backed group UI in PR #111. The group model for Moss and standalone and the work-context layer (Β§5.6, Β§5.7, Β§8.4) are proposed on 2026-11-03 and await review. **Created**: 2026-04-14 -**Last updated**: 2026-05-23 +**Last updated**: 2026-11-03 **Authors**: Nondominium project **Relates to**: `ndo_prima_materia.md`, `flowsta-integration.md`, `unyt-integration.md`, `many-to-many-flows.md`, `../requirements.md Β§2.3`, `../ui_design.md` (MVP Lobby β†’ Group β†’ NDO UI), @@ -17,10 +16,10 @@ Group DNA in progress (#101); MVP UI uses a localStorage group shell until Group 2. [Background: the multi-network problem](#2-background-the-multi-network-problem) 3. [Architecture overview](#3-architecture-overview) 4. [Lobby DNA requirements](#4-lobby-dna-requirements) -5. [Group DNA requirements](#5-group-dna-requirements) +5. [Group DNA requirements](#5-group-dna-requirements), including the group model by deployment mode (Β§5.6) and work contexts (Β§5.7) 6. [NDO DNA extension requirements](#6-ndo-dna-extension-requirements) 7. [Cross-cutting requirements](#7-cross-cutting-requirements) -8. [Governance layers](#8-governance-layers) +8. [Governance layers](#8-governance-layers), including the three sovereignty levels (Β§8.4) 9. [Integration requirements](#9-integration-requirements) 10. [Current state vs planned enforcement](#10-current-state-vs-planned-enforcement) @@ -118,6 +117,10 @@ layers each hold a distinct identity record for the same person: For the full identity-layer diagram and implementer guidance, see `documentation/specifications/post-mvp/lobby-architecture.md Β§2 "Agent identity layers"`. +### Group model by deployment mode and work contexts + +Since 2026-11-03 the Group DNA stays in both deployment modes. In Moss the Moss group is the federation layer and holds exactly one Nondominium group, the group cell of the tool instance. Work contexts, the project layer, live in the group DHT and are many-to-many with groups. They ship in v0.2, not in v0.1.0. See Β§5.6, Β§5.7, Β§8.4 and Β§8.5. + ### Groups vs organization-NDOs Groups and organization-NDOs are **distinct concepts** that must not be conflated: @@ -235,8 +238,7 @@ lifecycle_stage, property_regime, resource_nature) inside each group cell. ### 5.2 Membership -- **REQ-GROUP-05**: Group membership is invite-only. Joining requires a valid invite code - (or, when running inside Moss, the Moss invite system). +- **REQ-GROUP-05**: Group membership is invite-only. In standalone mode joining requires a valid invite code. In Moss the invitation is Moss's: an agent joins the Moss group, and the Nondominium group follows automatically (REQ-GROUP-22). - **REQ-GROUP-06**: A `GroupMembership` entry records the joining agent's Group DHT pubkey and their per-NDO pubkey map (`Vec`), following the Moss `AppletToJoinedAgent` identity pattern. @@ -279,6 +281,54 @@ lifecycle_stage, property_regime, resource_nature) inside each group cell. - **REQ-GROUP-18**: NDO governance supersedes group governance. If an NDO's governance rules conflict with a group's rules, the NDO rules take precedence for any action on that NDO. +### 5.6 Group model by deployment mode + +Decided 2026-11-03. The Group DNA stays in both deployment modes, so standalone and Moss share one architecture. What differs is who supplies membership, identity and invitation. Release scope (what v0.1.0 ships and what v0.2 adds) is in `../requirements.md` Β§2.4 (REQ-REL-01 to REQ-REL-05). + +- **REQ-GROUP-19**: The Group DNA is the group architecture in both deployment modes. A Moss build and a standalone build contain the same `group` role, and a group cell answers the same zome calls in both. + **Falsifier:** a Moss build without the `group` role, or a zome call that exists in one mode's group cell and not in the other's. + **Status:** πŸ”„ Partial. The `group` role exists (PR #107); the Moss build does not exist yet. +- **REQ-GROUP-20**: In standalone mode a group is a cloned Group DNA cell that an agent creates, registers in the Lobby (`GroupAnnouncement`) and opens to others by invite code. REQ-GROUP-01, REQ-GROUP-05 and REQ-LOBBY-10 apply unchanged. + **Falsifier:** an agent joins a standalone group without a valid invite code. + **Status:** βœ… Implemented (PR #107, PR #111). +- **REQ-GROUP-21**: In Moss there is exactly one Nondominium group per Moss group: the group cell of the Nondominium tool instance installed in that Moss group. The Moss group is the federation layer above it (REQ-FED-01). + **Falsifier:** two Nondominium group cells for one tool instance, or a member of the Moss group with no Nondominium group to act in. + **Status:** ❌ Not implemented. The Moss spike confirms that Moss accepts a deferred `group` role before this is built. +- **REQ-GROUP-22**: In Moss an agent joins the Nondominium group automatically when the agent joins the tool instance. No invite code is requested and no Lobby `GroupAnnouncement` is needed to reach the group. + **Falsifier:** a Moss-mode screen that asks for an invite code, or a Moss group member who must take a Nondominium-specific step to reach the group's NDOs. + **Status:** ❌ Not implemented. +- **REQ-GROUP-23**: In Moss, membership and the agent profile come from Moss, and Nondominium does not keep a second copy of either. Standalone keeps `LobbyAgentProfile` and the invite flow unchanged. + **Falsifier:** a profile edited in Moss that reads differently in Nondominium, or a Moss-mode write of a `LobbyAgentProfile`. + **Status:** ❌ Not implemented. + +Annotation to REQ-GROUP-01: in Moss each tool instance in each Moss group receives its own network seed from Moss, so the group's seed is Moss's, not an invite code. + +### 5.7 Work contexts (v0.2) + +A work context is the project layer: the space where agents work with several NDOs towards deliverables. Internally the term is **work context** (Bob Haugen's *context of work*, kept because it describes open collaboration, with no contract and no employment). The interface displays **project**, and a community may use its own word. No work context ships in v0.1.0. + +- **REQ-WC-01**: A work context is stored in the Group DHT, as entries of the group cell, in both deployment modes. It has no DNA of its own. Decision of 2026-11-03, recorded in `../specifications/adr/ADR-014-work-contexts-in-group-dht.md`. + **Falsifier:** a `work_context` DNA or role in `workdir/happ.yaml`, or a work-context entry written outside a group cell. + **Status:** ❌ Not implemented (v0.2). +- **REQ-WC-02**: A work context is not an NDO. It has no `NondominiumIdentity`, no Layer 0 lifecycle and no PPRs. It is a space and an amalgam of agents, closer to an organizational agent than to a resource, and Valueflows keeps the agent and the resource apart. + **Falsifier:** a `NondominiumIdentity` created to represent a work context. + **Status:** ❌ Not implemented (v0.2). +- **REQ-WC-03**: Work contexts and groups are many-to-many. A group holds several work contexts, and one work context may be worked in by several groups. Reference case: Catmaster, one work context with its own set of NDOs, worked in by Sensorica, Ludociel and Sainte-Justine. + **Falsifier:** the Catmaster scenario fails: a work context that three groups each see and work in cannot be set up, or a work context can be attached to one group only. + **Status:** ❌ Not implemented (v0.2). The mechanism that keeps a shared work context's state consistent across groups is open (see the ADR). +- **REQ-WC-04**: A work context works with NDOs by reference, following the pointer pattern of ADR-011: it stores the NDO's clone coordinates (DnaHash, network seed, properties), never a copy of the NDO's data. One NDO may appear in several work contexts. + **Falsifier:** NDO data duplicated inside a work context, or an NDO that cannot be listed by two work contexts at once. + **Status:** ❌ Not implemented (v0.2). `NdoAnchor` (PR #128) is the existing pattern. +- **REQ-WC-05**: A work context governs its own scope only (REQ-SOV-03). Its governance cannot change an NDO's lifecycle or an NDO's governance rules. + **Falsifier:** a work-context rule that blocks or triggers an NDO lifecycle transition. + **Status:** ❌ Not implemented (v0.2). +- **REQ-WC-06**: A work context may clone an NDO to experiment. Disagreements about the clone stay in the clone, and the original NDO and its governance are untouched. This is the fractal sovereignty case of REQ-SOV-05. + **Falsifier:** a governance event or a lifecycle change in a clone that appears on the original NDO. + **Status:** ❌ Not implemented (v0.2). A fork is expressed today by `NdoHardLink` of type `DerivedFrom` (REQ-NDO-EXT-05). +- **REQ-WC-07**: The interface displays a work context as a project by default, and the code and the design documents call it a work context. + **Falsifier:** a code identifier that names the entity `project`, or a default screen that says "work context". + **Status:** ❌ Not implemented (v0.2). + --- ## 6. NDO DNA Extension Requirements @@ -390,16 +440,12 @@ Entry type name: `Agreement` (aligned with VF vocabulary `vf:Agreement`); referr ### 7.1 Dual deployment -- **REQ-XCUT-01**: The Nondominium hApp shall run as a standalone application (Lobby DNA + - Group DNA + NDO DNA, all managed by one conductor) AND as a single Moss/The Weave Tool - applet (Nondominium Lobby appears as one tile in the Moss sidebar; Moss handles agent - invites and identity at the surface level). - **Status:** πŸ”„ Partial β€” standalone bundle includes **lobby** + **nondominium** + **hrea** - roles; Group DNA and Moss WeApplet not yet present. -- **REQ-XCUT-02**: The NDO DNA is not modified between standalone and Moss deployments. The - Lobby and Group DNAs are either used directly (standalone) or delegated to Moss - equivalents (Moss integration). - **Status:** βœ… NDO DNA unchanged; Moss path not implemented. +- **REQ-XCUT-01**: The Nondominium hApp shall run as a standalone application (Lobby DNA, Group DNA and NDO DNA, all managed by one conductor) and as a single Moss/The Weave Tool applet (Nondominium appears as one tool in the Moss group; Moss supplies membership, invitation and agent identity at the surface level). + **Falsifier:** either mode cannot create a group, create an NDO inside it and open that NDO from a second agent. + **Status:** πŸ”„ Partial. The standalone bundle includes the **lobby**, **group**, **ndo**, **nondominium** and **hrea** roles; the Moss tool does not exist yet. +- **REQ-XCUT-02**: The NDO DNA and the Group DNA are not modified between standalone and Moss deployments (REQ-GROUP-19). What Moss replaces is the surface around them: the invite flow, the agent profile and group creation (REQ-GROUP-21 to REQ-GROUP-23). Superseded wording: earlier versions said the Group DNA is delegated to a Moss equivalent in Moss; the decision of 2026-11-03 keeps it in both modes. + **Falsifier:** a Moss build whose `group` or `ndo` DNA differs from the standalone build's. + **Status:** βœ… NDO DNA unchanged; the Moss path is not implemented. ### 7.2 Resources are organization-agnostic @@ -413,6 +459,12 @@ Entry type name: `Agreement` (aligned with VF vocabulary `vf:Agreement`); referr as an individual Agent. Internally, they operate via an auto-created group-of-one. This group-of-one can grow to accommodate new members without any structural migration. +### 7.4 Interoperability between Moss and standalone + +- **REQ-XCUT-05**: The NDO is the bridge between Moss and standalone. An agent in a standalone Nondominium and an agent in Moss reach the same NDO when both derive the same clone cell from the same coordinates (DnaHash, network seed, properties) and run the same Holochain network protocol. Work contexts are managed by Nondominium, not by Moss, so they do not need Moss to be shared. + **Falsifier:** an NDO created in Moss whose anchor coordinates, given to a standalone agent on the same protocol, do not open the same cell. + **Status:** ❌ Not verified. Constraint recorded on 2026-10-27: the Moss 0.16 test builds ran a patched Holochain 0.7.1 that partitions their network from a standard 0.7.1, so the bridge holds only when both sides run the same protocol. Each tool instance in each Moss group also receives its own network seed, so the NDO's coordinates, not the group's, are what cross. + --- ## 8. Governance Layers @@ -445,6 +497,35 @@ The Lobby DHT is permissionless. Any agent may register a profile or NDO descrip The only implicit governance is the requirement that a registered NDO descriptor references an actual deployed DNA (discoverable by peers who attempt to connect). +### 8.4 Three sovereignty levels + +Brainstorm of 2026-10-27, restated here as requirements. Each level is sovereign within its own scope, and each higher level interconnects the lower ones while preserving their sovereignty. The levels are the NDO (hyperlocal), the work context (a social and economic boundary, around what a group wants to obtain from the NDOs it uses) and the federation (the layer that aggregates knowledge and redistributes it across work contexts and NDOs). REQ-GROUP-18 holds inside this model: NDO governance takes precedence for actions on that NDO, because that is the NDO's own scope. + +- **REQ-SOV-01**: Three sovereignty levels exist, NDO, work context and federation, each with its own governance scope, and no level's governance changes another level's. + **Falsifier:** a governance action at one level that alters the lifecycle, the rules or the membership of another level's entity. + **Status:** πŸ”„ Partial. NDO and Group governance exist; work-context and federation scopes do not. +- **REQ-SOV-02**: The NDO governs what it becomes: its lifecycle from idea to design specification, prototype and new versions, including the choice between designs and forking. + **Falsifier:** an NDO lifecycle transition decided by a work-context or federation rule. + **Status:** βœ… Lifecycle implemented (Layer 0, #80); design choice and fork governance partial. +- **REQ-SOV-03**: A work context governs which NDOs it works with, the soft links it makes, the direction it develops in, what it submits to an NDO as a version or update, activity management, and the order of contributions before they reach the NDO. + **Falsifier:** a work-context rule that acts on something outside this list, or something in this list that only the NDO or the federation can decide. + **Status:** ❌ Not implemented (v0.2). Benefit redistribution is deliberately absent from this list: REQ-GROUP-17 places it with NDO governance, and whether work-context contribution tables change that is open. +- **REQ-SOV-04**: The federation governs the list of work contexts, the overall strategy, the link to the macro level and common policies across work contexts. + **Falsifier:** a federation rule that acts on a single NDO's lifecycle or on a work context's internal organization. + **Status:** ❌ Not implemented. Which component holds federation governance in Moss is open: Moss groups carry no governance of their own. +- **REQ-SOV-05**: A work context may clone an NDO and disagree on the clone without touching the original NDO or its governance (REQ-WC-06). + **Falsifier:** a change made on a clone that shows on the original NDO. + **Status:** πŸ”„ Partial. Forks are recorded by `NdoHardLink` of type `DerivedFrom`. + +### 8.5 Federation (v0.2) + +- **REQ-FED-01**: In Moss the Moss group is the federation layer. Nondominium adds no group-of-groups structure of its own, so REQ-GROUP-03 (groups are flat) holds. In standalone mode the Lobby remains the only shared layer above groups. + **Falsifier:** a Nondominium entry type or role that nests a group inside another group. + **Status:** βœ… By design; no code adds a nesting. +- **REQ-FED-02**: In Moss an agent can view the work contexts of all the agent's groups from one place, across Moss groups. + **Falsifier:** an agent in two Moss groups who must open each group's tool instance to learn which work contexts exist. + **Status:** ❌ Not implemented (v0.2). + --- ## 9. Integration Requirements @@ -496,7 +577,9 @@ an actual deployed DNA (discoverable by peers who attempt to connect). | Layer | Status | Notes | |-------|--------|-------| | **Lobby profile UI sync** | πŸ”„ Issue #106 / PR #114 | Profile bar + fire-and-forget `upsert_lobby_agent_profile` | -| **Moss WeApplet** | ❌ | `ui/src/we-applet.ts` contract specified in architecture doc; not in repo | +| **Moss WeApplet** | ❌ | `ui/src/we-applet.ts` contract specified in architecture doc; not in repo. v0.1.0 ships Moss only (REQ-REL-01) | +| **Group model in Moss** | ❌ | One Nondominium group per Moss group, joined automatically (REQ-GROUP-21 to REQ-GROUP-23); proposed 2026-11-03 | +| **Work contexts** | ❌ | v0.2: group DHT, many-to-many with groups (REQ-WC-01 to REQ-WC-07); not in v0.1.0 | | **Facet discovery (nature / regime)** | ❌ | REQ-LOBBY-07 nature and property-regime path anchors not in Lobby DNA (NDO announcements removed; facets now group-scoped via anchors) | | **Governance-as-operator** | ❌ | #41–#44 β€” blocks full AccountableAgent enforcement on Contribution / Agreement / hard links | diff --git a/documentation/requirements/requirements.md b/documentation/requirements/requirements.md index 8f0682fb..2ddea5e7 100644 --- a/documentation/requirements/requirements.md +++ b/documentation/requirements/requirements.md @@ -50,12 +50,27 @@ Optional, pay-as-you-grow integrations and application profiles (communities may | Integration | Role | Normative detail | Design stub | |-------------|------|------------------|-------------| -| **Lobby DNA** | Multi-network federation: entry point (Lobby DHT) + per-group coordination (Group DHT) + NDO-to-NDO hard links, Contributions, Smart Agreements; dual deployment (standalone + Moss applet) | REQ-LOBBY-*, REQ-GROUP-*, REQ-NDO-EXT-* | [lobby-dna.md](lobby-dna.md) / [lobby-architecture.md](../specifications/lobby-architecture.md) | +| **Lobby DNA** | Multi-network federation: entry point (Lobby DHT) + per-group coordination (Group DHT) + NDO-to-NDO hard links, Contributions, Smart Agreements; dual deployment (standalone + Moss applet); group model by deployment mode, work contexts, sovereignty levels | REQ-LOBBY-*, REQ-GROUP-*, REQ-WC-*, REQ-SOV-*, REQ-FED-*, REQ-NDO-EXT-* | [lobby-dna.md](lobby-dna.md) / [lobby-architecture.md](../specifications/lobby-architecture.md) | | **Unyt** | Economic settlement (Smart Agreements, RAVE proofs, PPR↔RAVE provenance) | `ndo_prima_materia.md` Β§6.6, Β§11.5; REQ-NDO-CS-07–CS-11 | [unyt-integration.md](post-mvp/unyt-integration.md) | | **Flowsta** | Cross-app identity (Vault `IsSamePersonEntry`, `FlowstaIdentity` slot, DID, recovery); Tier 1 (Phase 1) vs Tier 2 (Phase 3) | `ndo_prima_materia.md` Β§6.5–6.7, Β§11.6; REQ-NDO-CS-12–CS-15; REQ-NDO-AGENT-07–08 | [flowsta-integration.md](post-mvp/flowsta-integration.md) | | **Source-NDO application profile** | Optional third primitive for applications governing generative ecological or knowledge systems. Not activated for ordinary Project NDOs (e.g. open-hardware design) or mature-resource mutualisation (e.g. sharing a 3D printer) unless the application explicitly needs to govern a generative Source and its boundary effects. | REQ-SOURCE-APP-*, REQ-SOURCE-ONT-*, REQ-SOURCE-GOV-*, REQ-SOURCE-DATA-*, REQ-SOURCE-EVENT-*; REQ-USER-ST-*, REQ-UI-SOURCE-* (Β§4.6) | [source-ndo-requirements.md](post-mvp/source-ndo-requirements.md) / [source-ndo-paper.md](post-mvp/source-ndo-paper.md) | -**Knowledge-base context** (ontology, OVN alignment, gap analysis): [resources.md](resources.md), [agent.md](agent.md), [governance.md](governance.md), [source-ndo-requirements.md](post-mvp/source-ndo-requirements.md). This PRD remains the anchor for MVP user stories and REQ-USER / REQ-RES / REQ-GOV IDs; NDO-wide REQ-NDO-* IDs are defined in `ndo_prima_materia.md` Β§9; Source-NDO REQ-SOURCE-* IDs are defined in `source-ndo-requirements.md` Β§8. +**Knowledge-base context** (ontology, OVN alignment, gap analysis): [resources.md](resources.md), [agent.md](agent.md), [governance.md](governance.md), [source-ndo-requirements.md](post-mvp/source-ndo-requirements.md). This PRD remains the anchor for MVP user stories and REQ-USER / REQ-RES / REQ-GOV IDs; NDO-wide REQ-NDO-* IDs are defined in `ndo_prima_materia.md` Β§9; Source-NDO REQ-SOURCE-* IDs are defined in `source-ndo-requirements.md` Β§8. Group model, work-context, sovereignty and federation IDs (REQ-GROUP-19 to REQ-GROUP-23, REQ-WC-*, REQ-SOV-*, REQ-FED-*) are defined in `lobby-dna.md`; release-scope IDs (REQ-REL-*) are defined in Β§2.4 above. + +### 2.4 Release scope and group model (v0.1.0 and v0.2) + +Decided 2026-11-03. The Group DNA stays in both deployment modes, so standalone and Moss share one architecture. In Moss the Moss group is the federation layer and holds exactly one Nondominium group: the group cell of the tool instance, joined automatically with no invite code. Work contexts (displayed as projects) live in the group DHT and are many-to-many with groups. A work context is not an NDO. Three sovereignty levels (NDO, work context, federation) each keep their own governance scope. The normative detail is in [lobby-dna.md](lobby-dna.md) Β§5.6 (group model by mode), Β§5.7 (work contexts), Β§8.4 (sovereignty levels) and Β§8.5 (federation); the decision that work contexts live in the group DHT is recorded in ADR-014, proposed in the pull request stacked on this one. + +- **REQ-REL-01**: v0.1.0 ships for Moss only. The standalone build is kept building and passing CI, but is not released. + **Falsifier:** a standalone artifact among the v0.1.0 release assets, or a standalone build that fails in CI at the release commit. +- **REQ-REL-02**: v0.1.0 in Moss ships one Nondominium group per Moss group (the tool instance's group cell, joined automatically, no invite code) and NDOs as cloned cells anchored in that group (REQ-GROUP-21, REQ-GROUP-22, ADR-010, ADR-011). + **Falsifier:** in a Moss group with two agents, one agent creates an NDO and the other cannot see and open it. +- **REQ-REL-03**: v0.1.0 ships no work context: no work-context entry type exposed to users, no coordinator function and no interface for it. + **Falsifier:** a work-context screen, function or entry type reachable in the v0.1.0 build. +- **REQ-REL-04**: The v0.1.0 wiring leaves the seam for v0.2: the Moss group cell is the same cell that will hold work contexts, so adding them does not change how a group is created or joined. + **Falsifier:** the v0.2 work-context change requires creating a different group cell or a different join step than v0.1.0 uses. +- **REQ-REL-05**: v0.2 adds work contexts in the group DHT (REQ-WC-01 to REQ-WC-07), their many-to-many relation with groups (REQ-WC-03), and the cross-group view that serves the federation layer (REQ-FED-02). + **Falsifier:** a v0.2 release without one of these, or one that stores work contexts in a DNA of their own. ## 3. nondominium Resource Characteristics