[Soushi888]

SoushAI analysis. Drafted by Soushi's AI assistant, reviewed and posted by @Soushi888.

Summary

This writes down the group model that the 27 Oct brainstorm with Tibi and today's decisions settled, so v0.1.0 and v0.2 build on a recorded shape instead of a conversation.

• Same architecture in both modes. The Group DNA stays in standalone and in Moss. What changes is who supplies membership, identity and invitation: in standalone, invite codes and the Lobby profile as today; in Moss, Moss.
• One Nondominium group per Moss group. In Moss the Moss group is the federation layer, and the Nondominium group is the group cell of the tool instance, joined automatically with no invite code.
• v0.1.0 ships Moss only and no work context. The standalone build is kept building but is not released.
• v0.2 adds work contexts. They live in the group DHT (no DNA of their own), are many-to-many with groups (the Catmaster case: Sensorica, Ludociel, Sainte-Justine), and are not NDOs. Internally "work context", displayed "project".
• Three sovereignty levels. NDO, work context and federation each keep their own governance scope. The federation view across Moss groups is a v0.2 requirement.

Every new requirement carries a falsifier. Nine decisions are not mine to make and are listed below as open questions, with my lean on each. A requirements board with a card per question and a priority and status per row exists for you to settle them; I edit this PR to match your answers before it merges.

Open questions

1. Lobby DNA in Moss. Present but idle (one manifest for both modes, my lean), or absent from the Moss build?
2. Shared work context state. With a work context living in one group DHT and shared by several groups, a home group holds it and the others hold a pointer (as NdoAnchor does, my lean), or every group holds a copy?
3. Benefit redistribution. The brainstorm puts it at the work-context level; REQ-GROUP-17 gives it to NDO governance. I kept REQ-GROUP-17 and left it out of work-context scope (my lean). Amend REQ-GROUP-17 instead?
4. Dormant entry types in v0.1.0. Integrity code is part of the DNA hash, so adding work-context entry types in v0.2 gives a new group DNA and a new network. Recreate the pilot groups in v0.2 (my lean, two developers in the pilot), or ship the types dormant in v0.1.0?
5. Federation in standalone. None in v0.2, the Lobby staying the only layer above groups (my lean), or a typed group acting as federation, which amends REQ-GROUP-03?
6. Federation governance in Moss. Moss groups carry none. Leave it unbuilt in v0.2 until the offer to Moss is made (my lean), or place it in the tool instance's group cell?
7. Project management. In the work context (my lean) or at the federation?
8. Work context and REQ-AGENT-02. REQ-AGENT-02 allows a project to have an NDO as digital twin. Keep it, with the twin a separate NDO the work context points to (my lean), or remove the project twin?
9. Entry to a work context and the display term. Any member of an associated group enters and leaves freely (my lean, not written as a requirement yet), and does "project" clash with Moss's own vocabulary?

Changes by concern

Group model by mode (lobby-dna.md §5.6, REQ-GROUP-19 to REQ-GROUP-23). The Group DNA in both modes, standalone creation and invitation, one group per Moss group, automatic join in Moss, membership and profile from Moss. REQ-GROUP-05 now says the invitation in Moss is Moss's. REQ-GROUP-01 gets a note that the seed in Moss comes from Moss.

Work contexts (§5.7, REQ-WC-01 to REQ-WC-07). Residence in the group DHT, not an NDO, many-to-many with groups, reference to NDOs by clone coordinates, own governance scope, cloning an NDO to experiment, display term.

Sovereignty and federation (§8.4 and §8.5, REQ-SOV-01 to REQ-SOV-05, REQ-FED-01, REQ-FED-02). The three levels and what each governs, the Moss group as federation layer, the cross-group view.

Moss and standalone interoperability (§7.4, REQ-XCUT-05). The NDO is the bridge; it holds when both sides derive the same clone cell and run the same Holochain network protocol.

Release scope (requirements.md §2.4, REQ-REL-01 to REQ-REL-05). What v0.1.0 ships, the seam it leaves, what v0.2 adds. The §2.3 table row for the Lobby DNA lists the new ID families.

Bookkeeping. §3 gains a short pointer, §10 gains two rows (group model in Moss, work contexts) and a note on the Moss tool, the header status and date are updated, and DOCUMENTATION_INDEX.md lists the new ID families.

Decisions and a wording that changed

Option	Rejected because
Keep the Group DNA out of Moss, as REQ-XCUT-02 said ("delegated to Moss equivalents")	Decided 2026-11-03: one architecture in both modes. REQ-XCUT-02 is reworded and says so in the text.
Model projects as NDOs of a project kind	Not idiomatic in Valueflows: a project is a space of agents, closer to an agent than to a resource.
A dedicated work-context DNA	Decided 2026-11-03 against; the reasoning is in the ADR stacked on this PR.

Semantic changes to existing requirements. REQ-XCUT-01 (the Group DNA now exists, so its status is updated and a falsifier added) and REQ-XCUT-02 (the Group DNA is no longer delegated to a Moss equivalent). REQ-GROUP-17, REQ-GROUP-18 and REQ-GROUP-03 are unchanged, and the new rows are written to agree with them.

How to test

Docs only, no code and no build. Review by reading lobby-dna.md §5.6, §5.7, §8.4, §8.5 and requirements.md §2.4, and check that each requirement's falsifier is something that could really fail. Every REQ-* named in the added text is defined once in the two files.

Documentation

Updated documentation/requirements/lobby-dna.md, documentation/requirements/requirements.md and documentation/DOCUMENTATION_INDEX.md. ADR-014, named in requirements.md §2.4 and in REQ-WC-01, is in the pull request stacked on this one.

Pre-open review

READY TO OPEN. Branch is in sync with dev and merges with no conflict. Docs only: no code touched. Checked on the diff: every REQ-* referenced in the added text is defined and none is defined twice; no em-dash or double hyphen in added text; each paragraph and bullet is one source line; Valueflows spelled correctly; every new requirement has a Status and a Falsifier; the new rows agree with REQ-GROUP-03, REQ-GROUP-17 and REQ-GROUP-18 and the two real conflicts (REQ-GROUP-17 against work-context redistribution, REQ-AGENT-02 against "not an NDO") are raised as questions 3 and 8 instead of resolved here.

Related

Closes #167

• Follow-up: the ADR for docs(adr): work contexts live in the group DHT #168, stacked on this PR.
• Release plan: release: v0.1.0 #123.

[Soushi888]

SoushAI analysis. Drafted by Soushi's AI assistant, reviewed and posted by @Soushi888.

Review APPROVE at head 5563edb, merging under Soushi's explicit -mwr authorisation (2026-11-03 21:42).

• Docs only: 3 files under documentation/. Description sections present and in line with the diff; no em-dash or double hyphen in added text.
• CI at this head: build, rustfmt, all six Sweettest shards and e2e are SUCCESS. Branch is mergeable and clean against dev.
• The nine open questions in the body are recorded as leans, not settled. The requirements text is marked as proposed on 2026-11-03, so any answer Soushi gives later is a follow-up edit to these docs.
• Follow-up: docs(adr): record that work contexts live in the group DHT #172 (ADR-014, stacked on this PR) merges next.