[Soushi888]

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

Summary

Each NDO is now a Moss asset, so other tools can point at it. An NDO has a Weave Asset Locator (its clone DNA plus its identity record), getAssetInfo and search answer for it, an NDO linked from another tool opens in Nondominium (alone, in the side panel or window), and the NDO view can add it to the Moss pocket. In the recorded two-agent run, Moss resolved Alice's NDO through our getAssetInfo on Bob's side and openAsset opened it in Bob's side panel. One consequence of the open question on #181: an asset only resolves on a member's machine once that member has joined the NDO's clone, so the tool joins every anchored NDO in the background on load.

Closes #165

Stacked on #181 (#164), in the native stack #179 (#130, #178, #180, #181, this PR). Review only this layer's diff; everything below belongs to the parent PRs.

Intent

Other Moss tools cannot point at an NDO, so an NDO is invisible outside Nondominium. Decided on 2026-11-03: NDOs are exposed as assets (WAL, getAssetInfo, search, openAsset).

Changes

• moss/assets.ts (pure): ndoWal, walToNdo, ndoPath, findAnchorForWal, ndoAssetInfo (name plus an inline icon), searchNdoAssets (name contains the filter, ignoring case).
• moss/anchors.ts: reads the NDO anchors of the instance's group cell through the applet client Moss passes to AppletServices, since search and getAssetInfo run outside the UI's stores.
• moss/applet-services.ts: createAppletServices(source) sets search and getAssetInfo. The service layer builds it (holochain.service) and passes it down through hc-connect to connectMoss, because lib/moss/connect.ts is reachable from components and invariant I1 forbids it importing $lib/services (the architecture check caught the first attempt).
• openAsset. In @theweave/api 0.7.0-rc.3 it is not a method on AppletServices: Moss renders the tool with an asset view, or with the main view on a WAL. moss/view.ts turns either into the NDO route; the layout navigates there; in an asset view AppShell shows the NDO alone, without the sidebar.
• The pocket. Add to Moss pocket in the NDO view (weaveClient.assets.assetToPocket), inside the existing button row, only in Moss.
• joinAnchoredNdoCells (NdoService, with moss/ndo-cells.ts): joins the clone of every anchored NDO in the background, one at a time, a failure never stopping the others. Needed because Moss maps a WAL to a tool through the DNAs in the agent's own conductor, and NDO clones are not public to the Moss group (feat(ui): Moss group context for groups and NDOs #181).
• Docs: moss-integration.md (assets section), ui_architecture.md, IMPLEMENTATION_STATUS.md, CHANGELOG.md.

Decisions

Option	Rejected because
WAL on the group DNA and the NdoAnchor record (resolvable by every member without joining anything)	The anchor's action hash changes with every cached update (lifecycle_stage, name), so it is not a stable locator, and the original hash is not exposed to the UI today. The clone DNA plus the identity record is permanent (ADR-010).
Auto-joining only the NDO a link points at	Moss never routes the link to the tool when the DNA is not in the member's conductor, so the tool is never asked.
Joining all anchored NDOs in parallel	Every join is a source-chain commit, and concurrent commits fail with source chain head has moved.

How to test

git checkout feat/moss-ndo-assets
nix develop -c bun run --filter ui check
nix develop -c bash -c 'cd ui && bunx vitest run --project server'
nix develop -c bun run e2e
nix develop -c bun run tool-dev

Recorded two-agent dev-mode run (2026-11-03, repo config, nested X server, driven through the tool iframes over CDP):

1. Alice creates Moss Seed Library. From Alice's tool, weaveClient.assets.assetInfo(wal) for the NDO's WAL returns Moss Seed Library with an inline icon: Moss resolved the WAL to our tool and called our getAssetInfo.
2. Bob, who neither created nor opened the NDO, reloads. His conductor now holds the NDO's clone (the background join), and the same assetInfo call from Bob's tool returns Moss Seed Library.
3. weaveClient.openAsset(wal, 'side') from Bob's tool opens a side panel titled Moss Seed Library with the NDO detail and no sidebar, the tab showing our icon and the name from getAssetInfo.

search and the Moss pocket are covered by unit tests; I did not drive the Moss search dialog by hand.

Documentation

Updated in this PR: moss-integration.md, ui_architecture.md, IMPLEMENTATION_STATUS.md, CHANGELOG.md.

Related

• Closes feat(moss): NDOs as Moss assets #165
• Depends on: feat(moss): Moss group context for groups and NDOs #164 (feat(ui): Moss group context for groups and NDOs #181), feat(moss): Moss tool scaffold #163 (feat(ui): run Nondominium as a Moss tool in weave dev mode #180), chore(deps): upgrade to Holochain 0.7.1 #130, research: Moss spike, install the happ in weave dev mode and clone one NDO #162 (research: Moss spike, install the happ in weave dev mode and clone one NDO #162 (comment))

Open questions for Soushi

1. Group-public NDO clones (from feat(ui): Moss group context for groups and NDOs #181): with publicToGroupMembers = false an NDO resolves as an asset only where the member joined the clone, so the tool joins them all in the background. Every member then hosts every NDO of the group, which is what public clones would have meant anyway; the difference is that wdocker does not do the hosting. My lean: keep, flip PUBLIC_NDO_CLONES when Moss accepts properties.
2. AppletServices.openAsset. The issue lists openAsset next to getAssetInfo and search. In @theweave/api 0.7.0-rc.3 there is none on AppletServices; opening is the asset render view, which this PR implements. Nothing to decide unless a later Moss version adds the method.

Pre-open review

• Description: disclosure line first, visible Summary, details folded, Closes #165, stack position stated. Pass.
• Merge state: in sync with feat/moss-group-context, no conflicts. Pass.
• Code: reviewed the diff. The invariant check (I1) caught a transitive import from lib/moss/connect.ts into $lib/services, fixed by injecting the applet services from the service layer. Standalone paths are untouched (every Moss branch is behind mossStore.isMoss or the host check). No blockers.
• Documentation: the assets section, the architecture note, the status and the changelog. Pass.
• Tests: 26 new unit tests (assets 11, anchors 4, view 4, NDO cells 3, applet services 6 against 4 before, connect 1, hc-connect 1; server project 154 passed). bun run --filter ui check: 0 errors, invariants I1 to I3 hold. The client project still has the one failure that fails on chore/holochain-0.7 too.
• Test exhaustivity: WAL, asset info, search, route from a Moss view, anchor loading through the applet client, the background join, and the service-layer injection are unit tested; the Moss resolution of a WAL and openAsset are covered by the recorded run.
• Suggestions left open: the Moss search dialog and the pocket were not driven by hand.

[Soushi888]

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

Review APPROVE at head 845e07d, merging under Soushi's explicit -mwr authorisation (2026-11-03 21:42). Top of native stack #179.

• This head is the reviewed commit (6c2f083) rebased onto dev after feat(ui): Moss group context for groups and NDOs #181 merged. git range-diff shows it identical. The PR went back to draft while I rebased the stack after a conflict in feat(ui): run Nondominium as a Moss tool in weave dev mode #180, and is marked ready again now.
• Scope as reviewed: NDOs exposed as Moss assets (WAL, getAssetInfo, search), openAsset through the asset render view, the pocket button inside Moss only, and a background join of anchored NDO clones. Applet services are injected from the service layer, so invariant I1 holds. 26 new unit tests.
• CI at this head: build, rustfmt, nine Sweettest shards and e2e are SUCCESS. Retargeted to dev, clean.
• Not driven by hand, as the body states: the Moss search dialog and the pocket (unit tested only).
• Open question 1 in the body (non-public NDO clones, PUBLIC_NDO_CLONES) is merged under the -mwr authorisation with its default. Question 2 needs no decision.