feat(team): Bot visibility, shared Bots and Role Policy (M7)

changes/4150-principal-proactive-dm.md

@@ -0,0 +1,11 @@
+---
+section: Fixed
+---
+
+## en
+
+- Kept proactive messages to a Bot’s current owner working when proactive audience DMs are off or the owner has opted out, including Owner-only Hosts and ownership transfers ([#4150](https://github.com/BotHarness/DeepSeekBot/issues/4150)).
+
+## zh
+
+- 修复 Bot 主动向当前所有者发送消息时被受众主动私信开关或退出设置误拦的问题，兼容仅所有者的 Host 及所有权转移（[#4150](https://github.com/BotHarness/DeepSeekBot/issues/4150)）。

docs/adr/0336-hosts-have-members.md

@@ -45,3 +45,37 @@ First delivery is **permission isolation among colleagues, not OS isolation agai
 Deliver as tracer bullets under a dedicated spec and hub, parallel to the Environment hub. M0 threads explicit Human context through Host methods with no behavior change. M1 is the first end-to-end slice: enable Team mode, set the Owner password, create a member, sign that member in from a LAN browser over HTTPS, show only the Tobs Client, join a public Channel and exchange messages with the Owner, with matching CLI. Seek Human feedback before broadening. Every slice proves refusals as well as successes: a member cannot read another member's private Bot, Channel, DM, Workspace root or approval content through the Client, the Gateway, the CLI with `--as`, or a Bot tool call.
 
 The design narrative and question log live in [Team mode design](../architecture/team-mode.md).
+
+## Bot access amendment — 2026-11-15
+
+The Human amendment on spec #4137 supersedes the Bot audience-containment rule above. A Bot acts
+for its current principal (`owner_human_id`); group access intersects that principal's current
+membership, roles and active status with Bot restrictions. Reading does not require Bot membership;
+writing does. Private/public visibility determines who may DM or add a Bot, without requiring every
+Channel occupant to belong to its audience. Public audiences may be everyone, roles or named members.
+
+The M7 task explicitly confirms participant authority as the DM exception: each Human's DM with a
+public Bot is readable by that Human and the Bot, while its principal needs Human-only M11 audited
+viewing. The public side of a private-to-public Bot DM uses the private Bot's principal as its
+participant. Public Bots cannot initiate contact with private Bots. Current principal status and
+current participant audience qualification still gate every Bot read/write; former audience members
+retain read-only DM history. No Bot can inherit M11.
+
+Hard permissions remain unioned across roles. Advisory policy uses admin-set topic tags, Deny wins
+and assignment conflicts identify both roles. Speaker context is append-only message metadata, with
+revisioned policy attachments on first role appearance or change and a current-policy Bot tool;
+per-speaker changes never rewrite the cached system prompt. The implementation contract and M6
+shared Memory integration boundary are in [M7 runtime notes](../architecture/team-mode-m7-runtime.md).
+
+M7 public Memory placement uses one dedicated hidden M6 shared space per public Bot, deterministically
+`shared/.bot-<slug>`, with exactly that Bot's current audience. Existing visible folders are not reused.
+This keeps `bots/<slug>/memory` outside grantable `files/` and avoids changing any Human folder's
+meaning. Audience changes retarget the space; private visibility moves Memory to the current
+principal's account. Relocation reuses M6's durable journal, ownership proofs, rollback before commit
+and resumable source retirement. The hidden space is omitted from folder/Workspace APIs and is not
+an independently managed folder. This implements the spec's shared-Memory requirement in M7.
+
+M7 shared discovery uses an explicit metadata projection for non-principals, including the Host
+Owner. Arranging a reachable Bot does not grant management or transcript access. Per-Human roster
+arrangements reuse the existing RosterStore domain schema in independent operational rows; the
+legacy local-Human row remains that Human’s arrangement across Host ownership changes.

docs/architecture/botharness-architecture.md

@@ -1705,6 +1705,25 @@ The Team usage and Role model policy runtime is described in [M10 Host and CLI l
 
 The [M5 approval logic](team-mode-m5-runtime.md) adds caller-scoped masking across Channel projections, Activity and push, Human decision attribution and unattended routing to the Bot owner. Member-owned Sessions refuse full access, suppressed asks and escalation. Team status and invitation responses identify the current isolation as `trial`; M12 owns enforcement qualification.
 
+### Team mode M7 runtime access
+
+The application-defined Bot visibility/principal checks and append-only speaker policy are
+specified in [M7 runtime boundaries](team-mode-m7-runtime.md). Group Channels intersect current
+principal access with Bot restrictions. A Bot's own Human–Bot and established private-to-public
+Bot DMs explicitly use participant authority; this does not give the principal private DM
+content or delegate M11 audited viewing to Bots. M6 remains the shared Memory placement authority: public Bots use audience-matched, hidden
+`shared/.bot-<slug>/bots/<slug>/memory` repositories, with journaled relocation on publication or
+return to private and atomic audience retargeting. These spaces are never grantable folders.
+
+M7 shared discovery projects reachable non-owned public Bots as metadata-only roster entries;
+full Bot records remain principal-scoped. Per-Human arrangements persist independently in the
+operational database, and shared Bot attention is restricted to the participating Human DM.
+See [M7 runtime](team-mode-m7-runtime.md#shared-discovery-and-participant-arrangement).
+
+M7 participant DM history keeps metadata-only, read-only Bot entries after audience loss; these
+entries grant no reach or management. Online CLI Bot-DM commands resolve the caller’s actual
+Channel through the Host and preserve that ID in send receipts and lookups.
+
 ## Tool effect declarations (E1)
 
 The public application-defined `ToolEffects` model describes `changes` (`none`, `reversible`,

docs/architecture/team-mode-m6-runtime.md

@@ -52,3 +52,12 @@ All commands use the existing online CLI path; `--as` goes only through the exis
 ## Performance guard
 
 No dependency, worker or timer is added. Ordinary path checks read Bot/space metadata and current role assignments in a fixed number of queries. Metadata work scales with retained Bots and spaces; hard-link inode scans occur only for multiply linked files. Directory searches reuse one synchronous permission snapshot across their preflight tree rather than querying for each file. Tests hold listing and path-check query counts constant while adding 1,000 Humans and additional role-scoped spaces. Transfer/purge filesystem manifests are explicit cold-path work. These are structural guards, not an end-to-end latency or OS-isolation claim.
+
+## M7 public Bot Memory integration
+
+Public Bot publication now uses M6's existing move journal and verified copy/rollback/retirement
+protocol. A dedicated hidden `shared/.bot-<slug>` space contains only `bots/<slug>/memory`, has the
+Bot's exact audience, and is never listed or grantable as a folder. Audience changes retarget this
+space; principal transfer leaves public Memory there, and returning to private moves it into the
+current principal's account space. Startup recovers the existing journal before reconciling older
+public Bots. See [M7 runtime notes](team-mode-m7-runtime.md) for preview and lifecycle details.