feat(collaboration): Profile/Chat product UI and Home window chrome

.github/workflows/ci.yml

@@ -30,6 +30,10 @@ jobs:
           bash scripts/check-wci-alignment.sh
           node scripts/home-entropy-check.mjs
           node scripts/browser-entropy-check.mjs
+      - name: product UI source proofs
+        run: |
+          node scripts/home-shell-regression-smoke.mjs
+          node scripts/people-discovery-smoke.mjs
       - name: Browser close handshake
         run: node --test scripts/browser-window-close-handshake.test.mjs
       - name: cargo clippy

AGENTS.md

@@ -6,8 +6,8 @@ lives in [state.md](state.md), and open work lives in [TASKS.md](TASKS.md).
 
 ## Branch Roles
 
-- `main` is the stable release line; it currently represents 0.5.0.
-- `upstream/0.6-dev` is the current 0.6 development integration line.
+- `main` is the stable release line; it currently represents 0.6.0.
+- `upstream/0.7-dev` is the current development integration line.
 - Feature and fix branches remain unpublished working lines until they are
   explicitly pushed for review.
 - Do not assume a `review/*` or `live` ref exists. Identify the exact public

DEBUG.md

@@ -80,12 +80,21 @@ refresh and preflight must fail when the rootfs bridge does not support
 `elastos.browser.vm-guest-control-bridge.config/v1`,
 `control_socket_ready_timeout_ms`, and `control_request_timeout_ms`.
 
-## People Discovery Invariant
-
-People discovery is opt-in, short-lived, and principal-rooted. UI and API
-summaries must derive visible state from the discovery expiry, not just a
-persisted boolean. Expired discovery must not publish presence until explicitly
-enabled again.
+## People Discovery And Presence Invariant
+
+People Discovery is explicit and opt-in. It projects a bounded set of signed,
+TTL-bound advertisements plus exact recipient contact requests and acceptances
+for the configured signed collaboration network. The seed/relay may help
+delivery, but it is never identity, contact, membership, or conversation
+authority.
+
+Signed presence is separate. It is a read-only projection of verified,
+unexpired presence for accepted contacts and active group participants in the
+configured signed collaboration network and default conversation. Presence
+presentation is self-asserted by the signing device key; it is not identity,
+contact, admission, or authorization. Missing collaboration configuration
+yields an explicit empty, unconfigured view, and reading People must not create
+identity, collaboration, or transport state.
 
 ## Service Selection Invariant
 

README.md

@@ -33,7 +33,7 @@ the [Mac staging runbook](docs/MAC.md).
 
 ## Build from source
 
-The workspace requires Rust 1.89 or newer.
+The workspace requires Rust 1.91 or newer.
 
 ```bash
 cargo install just

ROADMAP.md

@@ -232,6 +232,16 @@ Executable capsule isolation remains governed by
 [Principle 18](PRINCIPLES.md#18-executable-capsules-are-isolated-execution-environments)
 and [Capsule model](docs/CAPSULE_MODEL.md).
 
+The gateway already serves read-only content by CID at `/s/<cid>/`. Once
+capsule packages are signed and content-addressed, opening a capsule's CID
+should load the capsule itself: the gateway resolves the package, verifies
+it, and boots it with whatever host it declares — a game capsule loads its
+emulator, and the Home GUI capsule loads the Home host first, the same way
+today's launch path binds a viewer to its executable actor. A capsule's CID
+then works as a shareable link to the running thing, not just to its files.
+This depends on the signed package contract above; an unsigned directory
+served by CID must stay inert content.
+
 ### 7. Keep Home as the Runtime-owned front door
 
 Home is the default user surface. Runtime owns identity, object access,
@@ -307,11 +317,21 @@ operator commands; current acceptance and known limits belong in
 
 People is the trust surface for profiles, contacts, requests, device bindings,
 and service discovery. Chat owns direct, group, and public conversations.
-Inbox owns review of contact, pairing, conversation, and capability requests.
+Inbox owns review of contact, conversation, and capability requests.
+
+The identity split must stay explicit:
+
+- passkeys authorize a local principal; they are never the network identity;
+- a principal-owned Profile DID is the stable person/contact identity;
+- a device DID is endpoint and signing identity only;
+- signed profile documents authorize the current delivery device bindings and
+  must be retained by highest accepted revision plus previous-hash linkage;
+- direct conversations are scoped to Profile DIDs, not to device rotation.
 
 The product must distinguish people from devices and contacts from
 conversations. Discovery is opt-in and describes its actual network scope.
-Deterministic signed invites remain available when discovery is unavailable.
+Deterministic signed invites remain available as an explicit alternate
+onboarding path.
 Stable transport identifiers stay out of ordinary UI.
 
 Service offers can arrive through trusted People and Carrier relationships, but
@@ -325,15 +345,28 @@ Direct messages cannot be presented as private unless their transport and
 storage enforce that claim. Local composition and reading should remain usable
 without waiting for remote transport.
 
+Profile identity and transport routing must not drift:
+
+- the signed public profile document is the public identity truth;
+- older or conflicting profile revisions must fail closed once a newer accepted
+  revision is retained;
+- device revocation becomes effective when the newer signed profile revision is
+  observed, not by transport metadata alone;
+- direct messages need both proofs: the device signature proves the sending
+  endpoint, and the retained signed profile document proves that device is
+  currently authorized for the participant Profile DID;
+- Carrier/bootstrap configuration remains connectivity only and never becomes
+  person, contact, or conversation authority.
+
 The target contract carries authenticated messages, object updates, presence,
 and attachments between runtimes. Runtime must verify the sender, capability,
 replay policy, and destination object. Unauthenticated raw gossip does not meet
 that contract. Compatibility bridges may map external systems into the target
 contract, but they do not define the native model.
 
-See [People and conversations](docs/PEOPLE_CONVERSATIONS.md) for implemented
-behavior and [Tasks](TASKS.md#collaboration-and-messaging) for open
-outcomes.
+See [People and conversations](docs/PEOPLE_CONVERSATIONS.md) for the target
+model and ordered implementation slices, and
+[Tasks](TASKS.md#collaboration-and-messaging) for open outcomes.
 
 ### 10. Keep release, install, share, and sites on truthful paths
 

SECURITY.md

@@ -22,14 +22,6 @@ key and revocation state are committed atomically, operators must verify the
 persisted key and restart result instead of treating command completion as a
 durable rotation receipt.
 
-### No replay protection in chat signatures
-
-**Severity:** Medium
-**Files:** `capsules/chat/src/session.rs`, `capsules/chat/src/app.rs`
-**Status:** Open
-
-The signing payload is `SHA256(sender_id:ts:content)` with no nonce, topic binding, or timestamp freshness validation. The same signed message is valid on any channel and can be replayed indefinitely.
-
 ### Empty capability tokens in carrier service
 
 **Severity:** Medium
@@ -42,26 +34,6 @@ Host-plane Carrier service providers receive empty capability tokens on all requ
 
 These findings are fixed in the current branch but remain listed as security history because they shaped the runtime contract.
 
-### Chat message verification enforcement
-
-**Severity:** Medium (reduced from High)
-**Files:** `capsules/chat/src/main.rs`, `capsules/chat/src/main_stdio.rs`, `elastos/crates/elastos-server/src/chat_cmd.rs`
-**Status:** Fixed (2026-03-28)
-
-All chat surfaces (native, WASM, agent) now sign outgoing messages via the DID provider and verify incoming messages. Unknown senders with unverified or unsigned messages are dropped before display, nick recording, or peer attachment. The shared verification logic lives in `elastos_common::chat_protocol`.
-
-**Residual risk:** Chat is still a pre-release surface. The signing payload lacks replay protection (see open finding above).
-
-### Presence announcement signing
-
-**Severity:** Medium (reduced from High)
-**Files:** `capsules/chat/src/session.rs`
-**Status:** Fixed (2026-03-28)
-
-Presence announcements are now signed via the DID provider. Unsigned presence messages are dropped on receive. This prevents fake presence injection with arbitrary tickets.
-
-**Residual risk:** No freshness check on presence signatures — replay of valid presence is still possible.
-
 ### Bridge line length limits
 
 **Severity:** Low (reduced from Medium)