# AgentNet v0.1.45 communication and collaboration design **Date:** 2026-08-05 **Status:** Approved design; implementation and release evidence not started ## 1. Purpose AgentNet v0.1.45 is the first release intended to make the already-proven communication kernel usable from normal agent conversations. The live v0.1.44 server and laptop exchanged a signed message and reply, but only after operator intervention, opaque harness-ID recovery, and direct CLI use. Both ordinary OMP sessions lacked the packaged `agentnet_send` tool, and the documented `manager-run` fallback created a second Pi session without a usable model. v0.1.45 replaces that fragmented path with one package-owned lifecycle, one canonical local AgentNet interface, and thin adapters for OMP, Pi, Claude, Codex, and Antigravity. A person installs or updates AgentNet, completes understandable browser and passkey steps, explicitly restarts their agent when asked, and then uses AgentNet from the normal conversation. Users do not run shell commands, supply identity paths, copy internal IDs, move state files, or launch a second agent session. The release also exposes the existing conversation, room, task, response-obligation, and artifact semantics as a coherent collaboration surface. It does not claim production certification or promote any non-green must-not-ship gate without the required evidence. ## 2. Approved product decisions The owner approved the following decisions for this release: 1. Use a package-owned lifecycle with thin harness adapters rather than patching individual CLI journeys or building a dashboard-centered authority path. 2. Ship communication plus collaboration: direct messages, replies, conversations, rooms, tasks, handoffs, response obligations, and first-class files. 3. Support full post-enrollment tools in OMP, Pi, Claude, Codex, and Antigravity. 4. Keep the browser surface limited to onboarding, approval, invitation, connection status, tool activation, and recovery. The full administration dashboard remains separate. 5. Wake a separate background agent only for requests carrying a response obligation. Ordinary messages queue quietly. 6. Never restart a user’s harness automatically. AgentNet must explicitly ask the user to restart the agent after first installation or adapter change. 7. Route every message and processing obligation to one exact enrolled agent/harness instance. Sibling agents owned by the same human do not wake, dequeue, acknowledge, process, or answer. 8. When the exact addressee is offline, retain queued custody exclusively for that addressee until the same agent reconnects. Do not fail over to a sibling. 9. Add administrator-created, exact-email-bound, single-use invitation links and QR codes with a 24-hour lifetime. The short link opens a page that renders the current full onboarding prompt and enrolls the invitee only into the chosen collaboration space. 10. Defer Slack human-attention fallback for offline agents. It is tracked in MEL-238 and must not alter the original AgentNet recipient. ## 3. Release boundary ### Included - safe v0.1.44 to v0.1.45 package, setup-marker, service, credential-renewal, and schema migration; - package-owned installation, update, enrollment, authority activation, Manager startup, adapter installation, and recovery; - current-conversation tool registration after an explicit user-approved harness restart; - exact-agent recipient discovery and resolution without user-visible internal IDs; - direct messages, mailbox reads, acknowledgements, replies, conversations, threads, rooms, tasks, handoffs, cancellation, completion, and response obligations; - background request processing in a separate lifecycle; - artifact reservation, encrypted quarantine, maintained scanning, policy release, authorized access, and bounded download; - collaboration scopes that bind membership and resource authority consistently; - administrator invitation links, QR codes, and versioned onboarding prompts; - minimal plain-language browser onboarding and recovery pages; - hermetic, installed-package, cross-harness, live two-host, offline, restart, race, and recovery evidence appropriate to the claim. ### Excluded - the complete Servers, People, Security, Activity, relationship-management, and incident-control dashboard from MEL-230; - automatic sibling-agent failover or shared-consumer aliases; - Slack fallback, which remains MEL-238; - C3 enablement, MLS, federation, contractor access, and future peer-assisted or hubless operation; - closing owner-dependent or external must-not-ship gates without their required evidence; - a privileged Hub identity or a distinct Hub product; - automatic harness restart; - user-facing CLI commands as the normal journey. ## 4. Affected requirements and gates Primary affected stable IDs are: - architecture and harness boundary: `ARC-001`, `ARC-002`, `ARC-003`; - identity and enrollment: `ID-001`, `ID-002`, `ID-004`, `ID-005`, `ID-006`, `ID-007`, `ID-008`, `ID-009`; - authorization: `AUTH-001`, `AUTH-002`, `AUTH-003`, `AUTH-004`, `AUTH-006`, `AUTH-007`; - communication: `COM-001`, `COM-002`, `COM-003`, `COM-004`, `COM-005`, `COM-006`, `COM-007`, `COM-008`, `COM-009`, `COM-011`; - files: `FILE-001`, `FILE-002`, `FILE-003`, `FILE-004`, `FILE-005`, `FILE-006`; - availability: `AVL-001`, `AVL-002`, `AVL-003`, `AVL-005`, `AVL-006`, `AVL-008`; - user experience: `UX-001`, `UX-002`, `UX-003`, `UX-004`, `UX-006`; - security and operations: `SEC-003`, `SEC-004`, `SEC-005`, `SEC-006`, `OPS-002`, `OPS-003`, `OPS-004`, `OPS-005`, `OPS-006`, `OPS-007`. Relevant release gates include `G01`, `G02`, `G03`, `G05`, `G06`, `G07`, `G08`, `G09`, `G10`, `G11`, `G13`, `G14`, `G15`, `G16`, `G18`, and `G19`. This design changes no gate status. Local or live feature evidence must remain labeled by its actual tier. Owner decisions remain authoritative. In particular, PD-002 controls enrollment/OOB, PD-005 controls retention and compromise handling, PD-006 controls room governance, PD-007 controls C1/C2/C3 privacy, PD-009 controls continuity windows, PD-010 controls production topology, and PD-011 controls future attention paths. Safe defaults remain active where owner evidence is absent. ## 5. Actors and trust boundaries ### Human principal The verified human principal remains the source of positive authority. A verified email is an alias and invitation match input, not the durable primary identity and not authority by itself. ### Exact enrolled agent Every running OMP, Pi, Claude, Codex, or Antigravity instance is a separately enrolled harness with its own `harness_id`, credential, credential epoch, process eligibility, and revocation lifecycle. Two Pi instances owned by the same person are two different recipients. ### Ordinary server agent The always-on endpoint is an ordinary enrolled server agent with explicit capabilities. It is not a privileged Hub identity. The same package and actor model apply to laptop and server agents. ### Local Manager and supervisor The package-owned Manager holds the local enrolled credential through the existing protected local composition. It authenticates the parent harness/process, exposes only the canonical AgentNet operations, and runs background queues separately from foreground conversations. The supervisor/model-egress broker remains the only component allowed to hold upstream model credentials. Background workers receive only task-, model-, and budget-bound access. Adapter installation must not reintroduce reusable provider credentials into harness extensions or child processes. ### Harness adapters Adapters translate each harness’s supported extension, MCP, IPC, or tool-registration mechanism into the canonical local interface. They do not define identity, authorization, recipient resolution, mailbox semantics, artifact release, or receipts. ### Browser The browser displays public onboarding, exact approval, invitation, status, and recovery flows. Browser parameters, prompts, email strings, invitation URLs, and display labels are untrusted input. Browser state never becomes caller identity or positive authority. ## 6. Package-owned lifecycle v0.1.45 introduces one resumable lifecycle coordinator built from existing semantic owners rather than a second parallel state machine. It sequences: 1. verify the exact installed package and supported platform; 2. detect the current harness and supported adapter; 3. inspect owner-only AgentNet state without printing secrets; 4. reconcile a supported v0.1.44 installation and state; 5. install or update package-owned local services and adapter configuration; 6. begin or resume identity enrollment when required; 7. open the approved public browser flow; 8. reconcile OIDC, passkey, approval, response loss, expiry, and restart states; 9. activate the exact identity without silently granting unrelated authority; 10. request or resume the approved communication/collaboration scope; 11. start or resume exactly one Manager instance; 12. verify local canonical operations and remote health; 13. tell the user that AgentNet is ready and explicitly ask them to restart the harness; 14. after restart, prove the expected AgentNet tools are registered and bound to the exact enrolled harness; 15. return one plain-language terminal state. The lifecycle is idempotent. Re-running it after interruption must continue the same authorized transaction or create a new explicit transaction only when the previous one is terminal and replacement is allowed. It must never create duplicate identities, duplicate Manager instances, duplicate grants, or orphan browser transactions merely because a local state write failed. ### Plain-language states The normal UI uses: - `Ready to connect` - `Sign in with your work account` - `Approve with passkey` - `Waiting for approval` - `Agent enrolled` - `Access ready` - `Restart your agent to enable AgentNet` - `Connected` - `Expired — start again` - `Wrong work account` - `Could not connect` - `Needs administrator help` Protocol terms and internal IDs appear only in an authorized collapsed technical-details view. ## 7. Exact-agent addressing and delivery ### Address contract Every direct contribution has one or more explicit exact-agent recipients. The protected internal address binds: - trust domain; - durable human principal; - exact `harness_id`; - current recipient eligibility and revocation state; - the authorization/collaboration scope used for resolution; - the sender’s exact authenticated harness; - message or action intent and idempotency key. The durable event retains the original exact harness recipient. Credential rotation changes the accepted credential epoch for that harness; it does not silently change the recipient. Harness replacement creates a new harness identity and requires explicit reassignment or a new message. ### Durable agent-endpoint binding An enrolled agent is a durable endpoint, not whichever process or conversation happens to be active most recently. AgentNet records an owner-only `AgentEndpointBinding` between one exact `harness_id`, one harness installation/profile, one credential lineage, and one private local capability root. Process, session, and conversation identifiers may attenuate that binding; they cannot redirect it. Multiple agents on one host use separate endpoint bindings. Two Pi instances must have different harness identities, credentials, mailbox cursors, adapter generations, and private capability roots even when they run under the same OS user and human principal. OMP, Claude, Codex, and Antigravity receive their own bindings as well. No adapter may fall back to a shared default identity file. One package-owned host supervisor may manage several logical endpoints, but it must isolate them as if they were separate Managers: - every adapter connects through only its endpoint-specific owner-only socket or capability; - the local binding derives the caller from that capability and measured parent/process context, never from a tool argument; - one endpoint cannot list, read, acknowledge, wake, or sign for another endpoint; - restart rebinds the same enrolled endpoint only after executable, profile, generation, credential, and revocation checks; - creating a new agent profile creates a new enrollment rather than silently reusing an existing harness identity; - an ambiguous harness installation or profile association blocks activation instead of choosing the last active agent. Conversation continuity remains owned by the harness. When the harness supports resuming the same conversation after its user-approved restart, AgentNet preserves that normal resume path. If a harness cannot resume, AgentNet must state that limitation before restart; it still preserves the exact enrolled agent endpoint and mailbox, and it never transfers queued work to a sibling conversation or agent. ### No sibling reaction A shared human principal never implies a shared consumer queue. For a direct message addressed to one Pi: - that Pi’s mailbox receives the event; - a second Pi, OMP, Claude, Codex, and Antigravity owned by the same human receive no delivery wake; - siblings cannot race to acknowledge or answer; - a sibling’s foreground conversation is not interrupted; - revoking the target does not transfer the event to a sibling. Human-principal-scoped administrative visibility may show content-free metadata when authorized. Response-obligation visibility follows the existing principal-level inspection rule, but progress, processing ownership, and terminal response remain exact-harness scoped. ### Offline behavior Offline is normal. If the exact recipient is offline: 1. AgentNet records only the custody fact the accepting component can prove; 2. the event remains queued under the exact recipient mailbox; 3. no `delivered`, `acknowledged`, `processed`, or effect fact is fabricated; 4. no sibling or “last active” agent is selected; 5. the same target receives the event after authenticated reconnection and current revocation/policy checks; 6. expiry, cancellation, retention deletion, and legal hold remain separate lifecycle concepts. ### Multi-recipient and rooms One-to-many delivery is explicit fan-out to a fixed set of exact harness recipients. A room membership snapshot resolves to exact harness recipients at the authorized sequencing point. “Everyone owned by this person” is not an implicit recipient expansion. ## 8. Authorized recipient and space resolution The current CLI requires opaque harness IDs. v0.1.45 adds a canonical authenticated, non-enumerating resolver over the caller’s current communication and collaboration scopes. The resolver accepts understandable intent such as: - `the enrolled server`; - `Sergey’s OMP`; - `Sergey’s second Pi`; - `Claude on the work laptop`; - a visible direct conversation or room name. Resolution returns an exact internal address plus a safe display description. The resolver: - searches only peers and spaces already visible under the caller’s current domain, principal authority, exact harness eligibility, policy revision, and scope membership; - never exposes a global directory or unauthorized object existence; - distinguishes multiple agents with the same harness kind or display name; - fails closed on zero, multiple, stale, revoked, cross-domain, or unsupported results; - asks the agent/user to choose from safe disambiguated labels when more than one authorized exact target matches; - revalidates the selected target atomically during submission; - never treats a display name or model-selected string as authority. The canonical send operation consumes the resolver result internally. Harness tools should expose friendly target input or a separate resolve/select operation, not require the model to manufacture UUIDs. ## 9. Canonical local tool surface Every supported harness exposes equivalent operations and semantics. Harness-specific framing may differ, but lifecycle coverage may not. ### Connection and discovery - AgentNet status and recovery state; - list/resolve authorized exact agents; - list visible conversations, rooms, and collaboration spaces; - show content-free pending counts. ### Messages and conversations - send to exact agents; - read this exact harness mailbox; - acknowledge exact event custody; - create direct or multi-party conversation; - read a thread; - post reply, mention, typed action, or request; - create and answer response obligations. ### Rooms and collaboration - create authorized persistent room or temporary meeting; - inspect room and current membership epoch; - add/remove members when current room policy authorizes it; - send against the exact expected room-control sequence; - create, assign, accept, update, cancel, hand off, and complete structured tasks; - preserve directional assignment and custody-only auto-accept rules. ### Files - reserve and upload a file; - attach released artifacts to a message, conversation, room, task, or handoff; - inspect safe artifact status; - request an authorized bounded download; - verify digest and save to an owner-approved path. ### Operator fallback CLI commands remain available for diagnostics, recovery, and bounded operator workflows. They are not displayed as the normal user journey and do not define different semantics. ## 10. Background request processing Ordinary messages and file arrivals do not automatically spend model tokens or create replies. A request requiring an answer carries a durable `ResponseObligation` that names one exact responsible harness. When an eligible exact recipient is online, the supervisor may wake a separate background session only if: - the obligation is current and assigned to that exact harness; - the harness credential, principal, domain, policy, and revocation state are current; - the request’s data class is permitted for the configured model path; - a task/model/budget-bound broker grant exists; - required artifacts have passed release policy; - the wake is idempotently fenced; - no foreground conversation receives injected content. The worker reads only the authorized request context, records progress under the exact harness, and returns a bound response through the canonical conversation operation. If human input is required, it records `pending_human` and emits only the allowed content-free attention indication. Worker crashes, response loss, duplicate wake, and Manager restart reconcile from durable obligation and mailbox state. ## 11. CollaborationScope v0.1.45 implements the versioned `CollaborationScope` contract from MEL-234 so messages, rooms, tasks, and files do not develop independent membership semantics. A scope includes: - immutable scope ID and schema version; - exact trust domain; - type: personal, direct conversation, or shared room/workspace; - verified local human owner principal plus exact owner harness and current lifecycle state; - exact member harnesses, each bound to an explicit authority kind and host-local authority ID; - `principal` membership binds the current local human principal; `guest` membership binds the current host-local guest ID and never a sponsor principal or home-domain identity; - roles and action/resource/data-class limits, with host guests issued the `guest` role; - policy floor and revision; - membership/control sequence; - creation, expiry, revocation, archival, and deletion state; - optional references to canonical conversations, rooms, tasks, obligations, and artifacts. Scope IDs are caller-selected selectors, not authority. Issuance resolves every proposed harness transactionally from current server state and stores `(authority_kind, authority_id, harness_id)`. The member digest binds all three. Every lookup, recipient check, and automatic scope resolution rechecks the same kind-aware identity plus current domain, principal or guest, harness, credential epoch, credential validity, and revocation state. A local principal ID that collides textually with a guest ID remains a different authority because the kind is mandatory. Scope membership never independently grants filesystem, keychain, secret, model, scheduler, sandbox, connector, data-source, business-effect, sponsor-principal, or home-domain authority. Human or host-local guest authority, exact harness eligibility, resource policy, room governance, artifact release, and task/effect grants continue to narrow the operation. Cross-scope references are denied by default. An allowed reference requires a narrow, expiring, revocable, audited grant. Membership changes and protected reads/writes use one coherent policy and control revision to prevent time-of-check/time-of-use leakage. Existing communication scopes migrate to one deterministic v0.1.45 collaboration scope representation. Ambiguous records fail closed and enter a recoverable operator state; migration cannot broaden access. ## 12. Files and artifact lifecycle File sending is not implemented as message-byte embedding. The sender flow is: 1. resolve exact recipients and destination scope; 2. authorize reservation and quota; 3. stream bytes into immutable encrypted quarantine without disclosing them to recipients; 4. compute and bind exact digest, size, manifest, owner, recipients/scope, data class, lineage, and version; 5. run a maintained malware, secret, dangerous-file, archive, and executable scanner producer; 6. verify scanner identity, policy, attestation, and freshness; 7. release or reject atomically under current authorization; 8. create a message/task/room reference only to the policy-released artifact version; 9. require current authorization for every access; 10. issue a single-use or otherwise bounded download capability; 11. verify digest after download and write only to an approved non-symlinked custody path. Unsafe filesystem roots, symlink traversal, path replacement races, stale scanner evidence, archive bombs, secrets, executables, unsupported types, quota races, replayed download capabilities, and cross-tenant references fail closed. C3 remains disabled until its owner and evidence gates pass. An accepted message with a quarantined file must not say the recipient received usable file bytes. Artifact custody, scan, release, message delivery, download, and recipient processing remain distinct facts. ## 13. Email-bound invitation links and QR codes MEL-237 owns this feature. ### Creation An authenticated administrator selects: - one exact verified email address and trust domain; - one destination collaboration scope; - the exact permissions proposed; - an understandable recipient and space label. Core verifies that the administrator may create the invitation and may grant the selected access. It records audit intent and creates a random opaque, single-use invitation secret. Only a verifier or digest is stored where possible. The invitation expires 24 hours after issuance and can be revoked before use. ### Share surface The administrator receives: - one short HTTPS invitation link; - a QR code encoding only that link; - the recipient email, destination space, permissions, expiry, and revocation status; - copy/share controls. The QR does not embed the onboarding prompt. The invitation page renders the current versioned prompt so instructions can be corrected without invalidating the already-shared short link. ### Onboarding prompt The page provides a plain-language, copyable prompt instructing the invitee’s existing supported agent to: 1. inspect the invitation safely without treating it as authority; 2. install or update the exact supported AgentNet package without `sudo`; 3. detect and prepare the current harness adapter; 4. open the approved public sign-in and passkey flow; 5. prove possession of the exact harness credential; 6. verify the invited email through the approved workforce identity path; 7. review the destination space and requested permissions; 8. complete enrollment and scope admission; 9. explicitly ask the user to restart their agent when tool activation requires it; 10. verify AgentNet tools after restart and open the chosen space. The agent resolves package version, origins, callback paths, identifiers, and state paths. The user is not asked for technical values or shell commands. ### Redemption Redemption atomically verifies invitation state, exact email alias, issuer/subject, domain, expiry, use count, proof of possession, independent passkey approval, administrator grant authority, policy revision, and destination scope state. Concurrent redemption permits exactly one success. Wrong-email, forwarded, replayed, expired, revoked, already-used, stale-policy, deleted-scope, and cross-domain attempts return non-enumerating plain-language failures. The invitation URL, QR, prompt, and email do not grant authority. Success creates or binds the exact human and harness only through the canonical enrollment lifecycle and grants only the preapproved destination-scope access. ## 14. Harness adapters and explicit restart Each adapter must implement the same canonical contract while respecting the harness’s supported extension mechanism. ### Installation The package lifecycle detects OMP, Pi, Claude, Codex, or Antigravity; writes only package-owned configuration; validates ownership and permissions; and records a pending tool-activation generation. It must not edit unrelated user configuration or consume reusable model credentials. ### Restart gate If the running harness cannot hot-load the adapter, AgentNet displays: > AgentNet is enrolled and ready. Restart this agent to enable messaging, files, rooms, and tasks. The user must explicitly approve or perform that restart. AgentNet never terminates or restarts the harness automatically. Before restart, the current AgentNet enrollment and queued custody remain valid. After restart, the adapter proves: - the expected package version and adapter generation; - the exact enrolled harness binding; - Manager socket/capability authenticity; - complete canonical tool registration; - no duplicate adapter or Manager instance; - no foreground prompt injection. A failed verification reports a plain recovery state and leaves authority fail-closed. ### Adapter conformance The release matrix covers: - OMP; - two separately enrolled Pi instances under the same human; - Claude; - Codex; - Antigravity. Every adapter must prove exact-agent inbox isolation, send/reply, file flow, room/task operations, response-obligation wake, restart/reconnect, revocation, and absence of sibling reaction. ## 15. Minimal browser surface v0.1.45 ships only these pages: - invitation landing and onboarding prompt; - work-account sign-in; - passkey approval; - exact access review; - enrollment/connection progress; - invitation creation and status for authorized administrators; - tool activation and restart-required status; - recovery for wrong account, expiry, interruption, stale state, or blocked service. The UI uses ordinary language and hides OIDC, proof binding, credential epoch, schema, database, socket, and internal identifier details by default. It is keyboard operable, screen-reader understandable, responsive, and WCAG 2.2 AA compliant. Security state is never communicated by color alone. The browser holds no Core signing credential, Manager capability, private key, reusable approval token, or model credential. Sensitive actions remain proof-bound and freshly authorized through canonical services. ## 16. Failure and recovery behavior ### Installation and upgrade Unsupported platform, package-integrity mismatch, unsafe ownership, unknown future state, or missing rollback evidence blocks before mutation. A supported interrupted step resumes from its journal. ### Enrollment Wrong work account, expired OIDC, passkey failure, broker-auth failure, response loss, and replaced terminal state are typed. Activated identity is derived from authoritative current identity state, not stale enrollment continuations. ### Manager and adapter Manager startup uses owner-only locking and generation fencing. Duplicate processes fail closed. Socket loss causes bounded reconnect and exact outcome reconciliation; it does not guess whether a send committed. ### Recipient resolution Unknown, ambiguous, revoked, offline-only when policy forbids custody, cross-domain, or stale-scope targets do not degrade to a sibling or wildcard. Offline with allowed custody produces an exact queued state. ### Messages and tasks Duplicate idempotency keys return the existing fact. Replay, wrong body/path/audience/purpose, stale policy, expired grant, and wrong harness fail closed. Transport success never fabricates recipient processing or effect completion. ### Files Reservation/write/release crashes reconcile from durable lifecycle state. Missing or stale scanner evidence blocks release. Unknown download outcome does not authorize capability reuse. ### Invitations Only one atomic redemption succeeds. Failure after remote approval but before local state write reconciles against authoritative server state rather than creating another identity or invitation use. ## 17. Storage, migration, and rollback The current contiguous Core catalog is schema v6. Collaboration scopes, invitation lifecycle, adapter generations, and exact-agent routing metadata require one contiguous v6 to v7 migration for SQLite and PostgreSQL. The migration must: - preserve every principal, harness, credential, epoch, revocation, message, mailbox cursor, receipt, room, task, obligation, artifact, audit record, and active communication scope; - map existing communication scopes deterministically without broadening recipients or permissions; - bind existing per-recipient mailbox rows to their original exact harnesses; - reject ambiguous or inconsistent rows before committing; - use the repository’s migration catalog/checksum and N/N-1 rules; - provide pre-migration backup, interruption recovery, postcondition verification, and rollback evidence; - preserve the current enrolled server and laptop without re-enrollment; - upgrade setup markers, units, Manager lifecycle, adapter generation, and renewal timers coherently. Before implementation, the release process must reconcile the repository’s v0.1.43 metadata with the installed/public v0.1.44 source and immutable package evidence. v0.1.45 is built only from the exact authoritative successor source. It does not retain compatibility aliases or migration paths for disposable historical builds beyond the explicit supported predecessor. ## 18. Verification and evidence ### Focused contract evidence Tests cover: - exact-agent address validation and non-enumerating resolution; - two Pi siblings plus OMP/Claude/Codex/Antigravity under one principal; - no sibling read, dequeue, wake, acknowledge, obligation progress, or response; - offline exact-recipient queue and reconnect; - revocation without sibling transfer; - conversation, room membership epoch, task direction, handoff, cancellation, and obligation ownership; - invitation expiry, revocation, wrong email/domain, forwarding, replay, and concurrent redemption; - scanner freshness, malicious files, secrets, executables, archives, symlink roots, download reuse, and crash recovery; - browser/session CSRF, replay, secret exclusion, accessibility, and plain-language errors; - Manager generation, duplicate process, socket restart, response loss, and foreground isolation. ### Installed-package journey A packed npm artifact is installed into clean user-owned prefixes. The journey proves install/update, enrollment, minimal browser flow, explicit restart request, tool registration, message/reply, room/task, obligation background wake, file release/download, offline retry, and cleanup without repository imports or residue. ### Live two-host matrix The current ordinary server and laptop perform: 1. v0.1.44 backup and supported upgrade; 2. server and laptop readiness without re-enrollment; 3. OMP direct message and reply; 4. two Pi instances with one exact target and proof that the sibling remains inactive; 5. Claude, Codex, and Antigravity enrollment and full tools; 6. exact-agent offline queue and reconnect; 7. room message, structured task, handoff, cancellation, and response obligation; 8. safe file send, scan, release, download, and digest verification; 9. invitation link and QR redemption by the exact invited email into the chosen scope; 10. credential rotation/revocation and restart recovery; 11. complete process, socket, temporary credential, and artifact cleanup. Evidence records exact commit, package digests, versions, topology, actor/harness IDs in protected evidence, policy and credential epochs, commands, failure injection, outcomes, operator, and limitations. Public reports redact protected identifiers and content. ## 19. Linear ownership Primary delivery issues: - MEL-236: persistent full-communication enrollment and existing-session tools; - MEL-191: native laptop-to-server post-setup regression; - MEL-216: broker/readiness enrollment failure; - MEL-217: false final setup health/enrollment result; - MEL-234: `CollaborationScope` contract; - MEL-237: exact-email invitation link and QR onboarding; - MEL-193 and MEL-224: maintained scanner and safe artifact custody roots; - MEL-230: full administration dashboard, explicitly deferred; - MEL-238: future Slack human fallback, explicitly deferred. Requirement and gate issues remain the authority for their own evidence status. Implementation completion does not automatically close an evidence gate. ## 20. Definition of done v0.1.45 is complete only when: - a normal user can install or update without `sudo` or manual state work; - the existing enrolled server and laptop survive upgrade without re-enrollment; - the user completes understandable browser/passkey steps and is explicitly asked before harness restart; - OMP, Pi, Claude, Codex, and Antigravity expose the complete canonical tool surface after restart; - understandable recipient selection resolves one exact agent without user-visible IDs; - messages, files, rooms, tasks, handoffs, and obligations behave end to end; - only the addressed exact agent reacts, including with multiple sibling agents online; - an offline target receives queued custody and later delivery only on that same agent; - background request processing remains separate and non-interrupting; - invitation link and QR onboarding enforce exact email, 24-hour expiry, one use, and chosen-scope least privilege; - focused, installed-package, cross-harness, offline/recovery, file-safety, invitation, and live two-host verification pass; - migrations, rollback, cleanup, schemas, user documentation, architecture documentation, and Linear status agree with observed behavior; - release and requirement claims remain bounded to the evidence actually obtained.