@aopslabs/aops 0.3.9 → 0.3.11

package/agent-assets-release/agent-assets/core/{0ffc854a8e32500f3d82c10a1e1ee6376d57e616201a323638f0f9caf8fb2706 → 070b0d3126c645890845791b67157fdd9f43a482fda66583e84fb159b30689a5}/files/SKILL.md

@@ -24,16 +24,15 @@ this gateway loaded.
 | durable session intent and resume packs | `references/mission/SKILL.md` |
 | boards, tasks, sprints/plans, issues, feedback, reviews, handoffs | `references/projectman/SKILL.md` |
 | versioned documents, sections, links, search, answer, mirrors | `references/docman/SKILL.md` |
-| hosted coordination rooms, messages, inbox/listen/catchup | `references/hosted-chat/SKILL.md` |
+| encrypted coordination rooms, foreground listen, messages, membership | `references/chatv3/SKILL.md` |
 | structured multi-agent decision/consensus topics | `references/discuss/SKILL.md` |
-| encrypted ChatV3 product channels, invites, sessions, membership | `references/chatv3/SKILL.md` |
 | counters, countries, event store, rate limits | `references/sys/SKILL.md` |
 | choose or explain a working method | `references/working-disciplines/SKILL.md` |
 | run the full optional collaborative session playbook | `references/collaborative-work/SKILL.md` |
 | another installed/custom domain | `aops agent tools --domain <domain> --summary --json` |
 
-`aops chat` is hosted coordination. `aops chatv3` is the encrypted product
-channel surface. Do not merge those models. Fileman, Tasker/Runner, and the
+`aops chat` is the canonical ChatV3 surface; `aops chatv3` is a compatibility
+alias for the same command tree. Fileman, Tasker/Runner, and the
 interactive loop are not part of the default Community capability closure;
 discover them only if the connected server actually advertises them.
 

package/agent-assets-release/agent-assets/core/{0ffc854a8e32500f3d82c10a1e1ee6376d57e616201a323638f0f9caf8fb2706 → 070b0d3126c645890845791b67157fdd9f43a482fda66583e84fb159b30689a5}/files/references/agentspace/SKILL.md

@@ -7,7 +7,7 @@ description: Use for durable memory, synopsis, reusable prompts/skills/resources
 
 Agentspace owns durable agent/operator context and reusable hosted assets.
 Project execution belongs to Projectman; versioned documents belong to Docman.
-Hosted coordination and structured decisions have their own references.
+ChatV3 coordination and structured decisions have their own references.
 
 Read only the needed section of `../../user-guides/agentspace.md`. Exact flags
 come from live nested help.
@@ -53,7 +53,7 @@ context. Artifact records are metadata/pointers, not a large binary store.
 
 For durable session intent and resume packs, load `../mission/SKILL.md` rather
 than the full Agentspace guide. For rooms/messages load
-`../hosted-chat/SKILL.md`; for structured consensus load
+`../chatv3/SKILL.md`; for structured consensus load
 `../discuss/SKILL.md`.
 
 ## Raw discovery fallback
@@ -72,7 +72,7 @@ supported. Read back the exact record after mutation.
 
 - Planning, tasks, sprints, issues, feedback, reviews: Projectman.
 - Document graphs, page content, publish/search/answer: Docman.
-- Hosted coordination/wake: `aops chat`.
+- ChatV3 coordination/wake: `aops chat`.
 - Structured decision transcript: `aops discuss`.
-- Encrypted product channel: `aops chatv3`.
+- `aops chatv3`: compatibility alias for `aops chat`.
 - Repo `.aops/**`: derived cache, never the canonical authoring source.

package/agent-assets-release/agent-assets/core/070b0d3126c645890845791b67157fdd9f43a482fda66583e84fb159b30689a5/files/references/chatv3/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: aops-cli-chat
+description: Use for ChatV3 encrypted channels, invitations, agent-owned local sessions, membership, presence, bindings, messages, cursors, and foreground listening through aops chat.
+---
+
+# AOPS Chat (ChatV3)
+
+`aops chat` is the canonical encrypted ChatV3 channel/room surface for agent
+coordination and product-room work. `aops chatv3` is a compatibility alias for
+the same command tree; it is not a second messaging system.
+
+Read only the relevant section of `../../user-guides/chatv3.md`. Exact flags
+come from nested help; direct payloads come from live schema.
+
+## Common entry points
+
+```bash
+aops chat --help
+aops chat channel --help
+aops chat session --help
+aops chat member --help
+aops chat send --help
+aops chat read --help
+aops chat listen --help
+```
+
+Typical foreground coordination:
+
+```bash
+aops chat session list --json
+aops chat listen --session <id> --room general --after-seq <n> --timeout-sec 60 --json
+aops chat send --session <id> --room general "<message>" --json
+aops chat read --session <id> --room general --after-seq <n> --mark-delivered --mark-read --json
+```
+
+Keep foreground listening active while work remains. A listen timeout means
+only “no message in this bounded interval”; it does not end the task.
+
+Local sessions are isolated by detected agent owner (for example a Codex
+thread), or by `AOPS_CHATV3_SESSION_OWNER` / `--session-owner`. Session ids,
+member tokens, and room keys must never be copied between agent owners or
+pasted into chat, logs, source, or shell history. Legacy shared stores are
+claimed once and migrated into the first local owner that uses that session.
+
+`send --mark-read` and `send --mark-delivered` advance cursors only when the
+pre-send cursor is exactly caught up. If another message arrived first, the
+send succeeds but the cursor advance is skipped; read the gap explicitly.
+
+For a write not exposed by sugar, inspect the exact live schema first:
+
+```bash
+aops agent tools --domain chatv3 --summary --json
+aops agent schema --tool chatv3.<operation> --summary --json
+aops agent invoke --tool chatv3.<operation> --input '@payload.json' --preview --json
+```
+
+ChatV3 is coordination/wake truth, not the durable Projectman review record or
+the structured `discuss` transcript. Bind or summarize outcomes into the
+correct owner when durability matters.

package/agent-assets-release/agent-assets/core/{0ffc854a8e32500f3d82c10a1e1ee6376d57e616201a323638f0f9caf8fb2706 → 070b0d3126c645890845791b67157fdd9f43a482fda66583e84fb159b30689a5}/files/references/collaborative-work/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: aops-collaborative-work
-description: Use when the operator explicitly wants the full AOPS session playbook for solo work, async review, or hosted chat-room collaboration with Projectman-backed execution.
+description: Use when the operator explicitly wants the full AOPS session playbook for solo work, async review, or ChatV3 room collaboration with Projectman-backed execution.
 ---
 
 # AOPS collaborative work
@@ -53,23 +53,20 @@ The reviewer records the result in Projectman. Material findings become
 Projectman issues or bounded fix slices; chat is only the optional wake channel.
 Do not claim review completion from a message alone.
 
-## Mode 3: hosted chat room
+## Mode 3: ChatV3 room
 
 ```bash
-aops chat room create --slug <slug> --title "<purpose>" \
-  --created-by <lead> --member "<lead>:<role>" \
-  --member "<peer>:<role>" --apply --json
-aops chat binding add --room-id <id> \
-  --binding-type projectman.board --ref-id <board-id> \
-  --created-by <lead> --apply --json
-aops chat room brief --room-id <id> --for <peer>
-aops chat listen --for <agent> --room-id <id> --timeout-sec 570 --json
+aops chat join "<invite>" --handle <agent> --save-session --json
+aops chat binding add --session <id> --room general \
+  --binding-type projectman.kanban-task --ref-id <task-id> --json
+aops chat room brief --session <id> --room general --for <peer> --json
+aops chat listen --session <id> --room general \
+  --after-seq <last-seq> --timeout-sec 60 --json
 ```
 
 Each participant owns a non-overlapping slice and reports completion with
-validation evidence. Use `aops discuss` only for a material consensus decision;
-use `aops chatv3` only when encrypted product-channel behavior is the actual
-task.
+validation evidence. Use `aops discuss` only for a material consensus decision.
+`aops chatv3` remains an alias for this same ChatV3 surface.
 
 ## During work
 

package/agent-assets-release/agent-assets/core/{0ffc854a8e32500f3d82c10a1e1ee6376d57e616201a323638f0f9caf8fb2706 → 070b0d3126c645890845791b67157fdd9f43a482fda66583e84fb159b30689a5}/files/references/discuss/SKILL.md

@@ -6,7 +6,7 @@ description: Use for a structured server-canonical design decision or consensus
 # AOPS Discuss
 
 `aops discuss` owns a durable decision transcript and conclusion. Use hosted
-`aops chat` to wake/coordinate peers and Projectman to track review/execution.
+`aops chat` (ChatV3) to wake/coordinate peers and Projectman to track review/execution.
 Do not start a discussion ritual for a small reversible implementation choice.
 
 The complete owner and troubleshooting model is in the Discuss sections of
@@ -52,7 +52,7 @@ reports no missing final stances. Outputs must contain real decisions and
 follow-ups, not `_TBD_` placeholders.
 
 There is no automatic bridge: explicitly reference the concluded topic from a
-Projectman task/review/issue or durable memory, then send a short hosted-chat
+Projectman task/review/issue or durable memory, then send a short ChatV3
 wake if another agent must act.
 
 For raw operations:

package/agent-assets-release/agent-assets/core/{0ffc854a8e32500f3d82c10a1e1ee6376d57e616201a323638f0f9caf8fb2706 → 070b0d3126c645890845791b67157fdd9f43a482fda66583e84fb159b30689a5}/files/references/docman/SKILL.md

@@ -40,6 +40,12 @@ import for intentional bulk import, not for a one-page edit. Every mutation is
 preview/apply guarded where supported; read back the current version after
 publishing.
 
+Compose or materialize the exact candidate before review and retain its
+version ids plus `contentHash`. Put the complete immutable evidence reference
+in both the Projectman review request and an approved review result. Saving a
+mutable draft changes its hash and requires a linked re-review; a page-version
+id alone is not approval evidence.
+
 ## Search, answer, publish, and mirrors
 
 ```bash

package/agent-assets-release/agent-assets/core/{0ffc854a8e32500f3d82c10a1e1ee6376d57e616201a323638f0f9caf8fb2706 → 070b0d3126c645890845791b67157fdd9f43a482fda66583e84fb159b30689a5}/files/references/projectman/SKILL.md

@@ -65,6 +65,12 @@ Use an issue for a material blocker/defect, feedback for observations or
 suggestions, and review-request/result for an auditable review gate. A chat
 message may wake a reviewer but is not the review record.
 
+For mutable Docman drafts, bind the review request to the exact composed
+evidence reference containing the page/document version id and its
+`contentHash=sha256:<digest>`. An approved result must repeat that complete
+reference exactly. A later draft edit changes the hash, so the earlier approval
+does not cover the new bytes; open a linked re-review.
+
 ## Status discipline
 
 1. Inspect the record before changing status.

package/agent-assets-release/agent-assets/core/{0ffc854a8e32500f3d82c10a1e1ee6376d57e616201a323638f0f9caf8fb2706 → 070b0d3126c645890845791b67157fdd9f43a482fda66583e84fb159b30689a5}/files/references/working-disciplines/SKILL.md

@@ -50,7 +50,7 @@ aops mission create --objective "<objective>" \
 1. Put every implementation slice in Projectman before or at kickoff.
 2. Read live help/schema instead of guessing flags or payloads.
 3. Validate in proportion to risk and record only evidence actually produced.
-4. Use hosted chat for coordination/wake, Discuss for consensus, and
+4. Use ChatV3 (`aops chat`) for coordination/wake, Discuss for consensus, and
    Projectman review-request/result for review truth.
 5. Keep scope changes and blockers explicit; do not fabricate peer approval.
 6. Ordinary stop writes status/handoff and keeps mission/board/room open.

package/agent-assets-release/agent-assets/core/070b0d3126c645890845791b67157fdd9f43a482fda66583e84fb159b30689a5/files/user-guides/agentspace.md

@@ -0,0 +1,198 @@
+<!-- Public packaged Agentspace guide. Current nested help and live schema win on drift. -->
+
+# Agentspace User Guide
+
+## 1 Ownership model
+
+Agentspace owns durable agent/operator context and reusable hosted assets:
+memory, synopsis, prompts, skills, resources, artifacts, activity, experience,
+agent profiles, missions, and structured discussion topics.
+
+It does not own every part of a work session:
+
+| Need | Canonical owner |
+| --- | --- |
+| task, sprint, issue, review request/result, handoff | Projectman |
+| versioned page/document content and retrieval | Docman |
+| encrypted coordination room, messages, cursors, foreground listen | ChatV3 via `aops chat` |
+| structured decision stances and conclusion | Agentspace Discuss via `aops discuss` |
+| repository files and commits | Git/source repository |
+
+The former Agentspace hosted-chat sugar and its `room/inbox/catchup` command
+shape are retired from `aops chat`. Existing server data may remain for
+historical readback, but new coordination uses ChatV3. `aops chatv3` is only a
+compatibility alias for `aops chat`.
+
+## 2 Startup and resume ladder
+
+Prefer small, token-efficient reads:
+
+```bash
+aops mem brief --subject project --json
+aops mem search --q "<decision or constraint>" --limit 10 --json
+aops mission resume --id <mission-id> --json
+aops view digest --task <task-id> --depth shallow
+aops pm review-request list --status open --json
+aops chat session list --json
+```
+
+Do not preload every memory, guide, room transcript, or PM record. Resolve
+references only when the current task needs them.
+
+## 3 Durable memory and synopsis
+
+Memory is for facts that must survive the current context: decisions,
+constraints, bounded handoffs, blockers, validation state, and the next safe
+action. It is not a duplicate task tracker and must not contain secrets, large
+logs, raw chat transcripts, or full documents.
+
+```bash
+aops mem list --durability sticky --json
+aops mem search --q "migration decision" --limit 10 --json
+aops mem write --mode decision --subject project \
+  --content "<bounded evidence and decision>" --apply --json
+aops mem checkpoint --help
+aops mem synopsis --subject project --json
+```
+
+A good checkpoint contains the request/purpose, PM and repository refs,
+concrete outcome, validation/review evidence, open risk, and next action.
+Write at meaningful milestones—not after every message or small edit.
+
+Generated synopsis is a read model over durable context. Rebuild/read it when
+resume quality is poor; do not treat it as an independent source of truth.
+
+## 4 Reusable hosted assets
+
+```bash
+aops prompt list --json
+aops skill list --json
+aops resource list --json
+aops artifact list --json
+aops exp list --json
+```
+
+Prompts and skills are versioned server records. Resources point to knowledge;
+artifacts describe or reference outputs and are not an unlimited binary store.
+Create/update/version/publish commands are guarded writes. Inspect help first,
+use idempotency for retries, and read back the exact version after mutation.
+
+```bash
+aops skill version create --help
+aops prompt version create --help
+aops resource create --help
+aops artifact create --help
+```
+
+Never put credentials, private keys, bearer/member tokens, or machine-local
+secret paths into hosted assets.
+
+## 5 Structured discussions
+
+Use `aops discuss` only when a material decision needs independent stances and
+a durable conclusion. Small reversible implementation choices do not need a
+discussion ritual.
+
+```bash
+aops discuss start --title "<decision>" --question "<question>" \
+  --participant <agent-a> --participant <agent-b> --apply --json
+aops discuss turn --topic <topic> --agent <agent> \
+  --kind statement --from-file ./turn.md --apply --json
+aops discuss wait --topic <topic> --agent <agent> \
+  --timeout-sec 540 --interval-sec 5 --json
+aops discuss turn --topic <topic> --agent <agent> \
+  --kind final-stance --from-file ./final.md --apply --json
+aops discuss conclude --topic <topic> --apply --json
+```
+
+Never invent another participant's stance. Conclude only after every required
+participant recorded a final stance and the status readback reports no missing
+finals. Link the conclusion into Projectman or memory.
+
+Discussion waits and ChatV3 listeners are separate mechanisms. A Discuss turn
+does not wake a ChatV3 listener automatically. Send a short `aops chat send`
+message with the topic/turn reference when a peer must act.
+
+## 6 ChatV3 coordination
+
+ChatV3 owns coordination and wake traffic:
+
+```bash
+aops chat join "<invite>" --handle <agent> --save-session --json
+aops chat binding add --session <session> --room general \
+  --binding-type projectman.review-request --ref-id <rr-id> --json
+aops chat send --session <session> --room general \
+  "REVIEW READY: <rr-id>" --json
+aops chat listen --session <session> --room general \
+  --after-seq <last-seq> --timeout-sec 60 --json
+aops chat read --session <session> --room general \
+  --after-seq <last-seq> --mark-delivered --mark-read --json
+```
+
+Keep foreground listening while room-owned work remains. Timeout exit `22`
+means only that the bounded interval was quiet. Read PM/RR/Docman/Discuss refs
+before acting, post a short ACK, and advance cursors only for messages actually
+consumed.
+
+Session credentials are isolated by local agent owner. Do not share a session
+id or store between agents. See the ChatV3 guide for migration and cursor-gap
+rules.
+
+## 7 Review pairing
+
+Projectman is the review truth:
+
+```bash
+aops pm review-request create --help
+aops pm review-request get --id <rr-id> --json
+aops pm review-request result --help
+```
+
+Use ChatV3 only to wake the reviewer and point to the canonical RR. Material
+review findings become Projectman issues. Re-review is a child RR, not an edit
+of the prior immutable result.
+
+For Docman drafts, include document/page identifiers plus the compose or
+materialize `contentHash` in the RR reference. The result must repeat the exact
+same evidence reference. If the draft hash changes, the old acceptance covers
+only the old bytes and a new re-review is required.
+
+## 8 Missions and closeout
+
+Missions preserve objective and policy; Projectman preserves implementation
+state. Ordinary stop writes a bounded handoff and keeps the mission/task/room
+open. Operator-approved closeout verifies:
+
+1. source and PM state are consistent;
+2. requested tests and independent reviews are recorded;
+3. material findings are resolved or explicitly deferred;
+4. the final ChatV3 message points to durable records;
+5. only then are task/mission/room lifecycle states closed as authorized.
+
+Do not archive a room merely because one listener timed out. Do not mark a
+review accepted from a chat message alone.
+
+## 9 Raw discovery and troubleshooting
+
+```bash
+aops agent tools --domain agentspace --summary --json
+aops agent schema --tool agentspace.<operation> --summary --json
+aops agent invoke --tool agentspace.<operation> \
+  --input '@payload.json' --preview --json
+```
+
+Use the detail ladder: this guide → nested help → live schema → guarded raw
+invoke. If the connected server advertises capabilities absent from this
+public core, trust the live catalog for availability but keep owner and secret
+boundaries intact.
+
+Common failures:
+
+- quiet listener: continue from the last acknowledged sequence; timeout is not
+  completion;
+- PM record changed but peer slept: send a ChatV3 wake with the PM ref;
+- send succeeded but cursor did not advance: read the reported unseen gap;
+- local session not found after upgrade: load the exact legacy session once so
+  it can be claimed by the current agent owner;
+- owner mismatch: use the correct agent session or explicit owner; never copy
+  another agent's credential store.

package/agent-assets-release/agent-assets/core/{0ffc854a8e32500f3d82c10a1e1ee6376d57e616201a323638f0f9caf8fb2706 → 070b0d3126c645890845791b67157fdd9f43a482fda66583e84fb159b30689a5}/files/user-guides/aops-cli.md

@@ -577,39 +577,38 @@ Kural:
 
 #### 16.2.1 Overview
 
-`discuss`, `chat` ve `pm review-request` ayri koordinasyon yuzeyleridir: karar/konsensus `discuss`, koordinasyon/uyandirma hosted chat odalari (`chat`), review ise Projectman (`pm review-request`). Yanlis yazici/dinleyici eslesmesi sessiz trafik kaybinin en sik sebebi; koordinasyon mesaji ile dinleyici ayni hosted chat odasinda olmali (`aops-cli-chat` skill'ine bak).
+`discuss`, `chat` ve `pm review-request` ayri sahiplik yuzeyleridir: karar/konsensus `discuss`, koordinasyon/uyandirma ChatV3 (`chat`), review ise Projectman (`pm review-request`). `aops chatv3`, ayni ChatV3 komut agacinin compatibility alias'idir; ikinci bir chat sistemi degildir.
 
 | Ihtiyac                                                | Komut                          | Skill            |
 |--------------------------------------------------------|--------------------------------|------------------|
 | Yapilandirilmis karar transcript'i + sonuc kararlari   | `aops discuss start`        | `aops-cli-discuss` |
 | Agent sirasi/lifecycle icin karar dongusu              | `aops discuss wait`, `aops discuss turn`, `aops discuss conclude` | `aops-cli-discuss` |
-| Multi-agent koordinasyon/uyandirma odasi               | `aops chat room create`, `aops chat message send` | `aops-cli-chat` |
-| Agent'in bekleyen oda/mesaj islerini kesfetmesi        | `aops chat inbox --for <agent>` | `aops-cli-chat` |
-| Oda trafigini dinleme / unread okuma                   | `aops chat listen`, `aops chat catchup` | `aops-cli-chat` |
+| Multi-agent koordinasyon/uyandirma odasi               | `aops chat join`, `aops chat send` | `aops-cli-chat` |
+| Oda trafigini foreground dinleme / unread okuma        | `aops chat listen`, `aops chat read` | `aops-cli-chat` |
 | Review iste / sonucla / re-review                      | `aops pm review-request create`, `aops pm review-request result` | `aops-cli-projectman` |
 
-Koordinasyon (uyandirma, oda mesajlasmasi, listener) hosted chat odalarinda yasar; karar ritueli `discuss` tarafindadir. Yapilandirilmis bir karar/stance `discuss turn`/`conclude` ile transcript'e yazilir; karsi agent'i uyandirmak icin ayni isi bagli hosted chat odasina kisa bir `chat message send` ile duyur (oda mesaji uyandirma sinyali, discuss transcript kanonik kayit). Davet/dinleyici beklentisini de chat odasinda netlestir. Detaylar icin `aops-cli-chat` (oda lifecycle, members, `chat send/listen/catchup`) ve `aops-cli-discuss` (karar ritueli, `discuss wait` exit kodlari) skillerine bak. Review akisi (RR/RRR, re-review, material issue) `aops-cli-projectman` tarafindadir.
+Yapilandirilmis stance `discuss turn`/`conclude` ile transcript'e yazilir; karsi agent'i uyandirmak icin bagli ChatV3 odasina topic/RR ref'i tasiyan kisa bir `aops chat send` mesaji yazilir. Chat mesaji wake sinyalidir; karar ve review kaydinin yerine gecmez.
 
 Slug-first operator contract:
 
-1. `discuss start --slug <slug>` topic frontmatter'ina canonical slug yazar. Slug verilmezse title'dan derive edilir ve JSON'da `topicSlug` olarak doner. Hosted chat odalari da `chat room create --slug <slug>` ile slug tasir.
+1. `discuss start --slug <slug>` topic frontmatter'ina canonical slug yazar. ChatV3 channel/room slug'lari join/create sonucu okunur.
 2. Selector'lar artik exact slug'i operator-facing varsayilan kabul eder; legacy folder name ve short id debug/legacy fallback'tir. Operator-facing komut, handoff ve chat ping'lerde slug kullan; raw UUID'i debug/JSON disinda tasima.
 3. Legacy folder-name veya implicit short-id match kazanirsa JSON envelope `cliDeprecationWarnings` dondurur. Debug ihtiyaci disinda bu uyarilar "slug'a gec" sinyali sayilir.
 4. Explicit debug selector gereken yerde `--short-id <8char>` kullan; bu explicit yol warning uretmez, implicit short-id ise `cliDeprecationWarnings` uretir. Ambiguous slug/folder/short-id durumunda yalniz tek active kayit varsa `--prefer-active` onu secer; kalici handoff'larda yine slug yazilir. Discuss komutlarinda `--short-id` topic selector'udur.
-5. Yeni agent bootstrap'i: once `aops chat inbox --for <agent> --json`, sonra bagli odadaki unread'i `chat catchup --for <agent> --apply --json` ile oku; aktif uyandirma icin `chat listen --for <agent> --max-loops 1 --json`. Bekleyen review icin `aops pm review-request list --json`.
+5. Yeni agent bootstrap'i: `aops chat session list`, `room brief`, sonra `listen --after-seq <cursor>`; bekleyen review icin `aops pm review-request list --json`.
 6. `discuss conclude`, `consensus.md`, agent final stance, `disagreement.md` ve `open-questions.md` dosyalarini `_TBD_` placeholder olarak birakmaz. Topic'i baslatan agent output owner'dir; finalize/closeout oncesi bu dosyalari review edip gerekiyorsa zenginlestirir.
 
 ### 16.3 PM window + chat-room baglama ve active window
 
 #### 16.3.1 Overview
 
-Iki ajanli execution pencerelerinde Projectman window'u tek olsun. Board kickoff acildiysa ayni board'un aktif task/sprint'i varsayilan olarak reuse edilir; yeni task ve sprint ancak aktif pencere yoksa olusturulur. (Repo-first `collab pm-bind` komutu emekliye ayrildi; PM penceresi dogrudan `pm` ile yonetilir, koordinasyon ise board'a bagli hosted chat odasinda yapilir.)
+Iki ajanli execution pencerelerinde Projectman window'u tek olsun. Board kickoff acildiysa ayni board'un aktif task/sprint'i varsayilan olarak reuse edilir; yeni task ve sprint ancak aktif pencere yoksa olusturulur. Koordinasyon, PM ref'i baglanmis ChatV3 odasinda yapilir.
 
 ```bash
 aops pm board kickoff --board ops --title "AOPS PM tooling triage" --goal "..." --apply --json
-# Koordinasyon odasini board'a bagla (uyandirma/akis hosted chat'te):
-aops chat room create --slug ops-room --title "Ops" --created-by <agent> --apply --json
-aops chat binding add --room-id <room-id> --binding-type projectman.board --binding-id <board-id> --label "Active board" --created-by <agent> --apply --json
+# Koordinasyon odasini PM ref'ine bagla:
+aops chat binding add --session <session> --room general \
+  --binding-type projectman.board --ref-id <board-id> --title "Active board" --json
 ```
 
 Explicit task/sprint secimi gerektiğinde ilgili `pm sprint`/`pm utask` komutlarini
@@ -621,17 +620,17 @@ aktif board referanslari tercih edilir.
 
 #### 16.4.1 Overview
 
-Operator "tartisin", "Claude ile konusup plan koyun", "beraber arastirin" gibi bir istek verdiginde ana ajan tek basina plan yazip sonradan review istemez. Varsayilan akis iki tarafin da bagimsiz context uretmesi, sonra discuss topic'i (karar) + hosted chat odasi (uyandirma) uzerinden yakinsamasidir. Review tarafi Projectman'dedir.
+Operator "tartisin" veya "beraber arastirin" dediginde iki taraf bagimsiz context uretir, `discuss` topic'inde yakinsar ve ChatV3 ile uyanir. Review tarafi Projectman'dedir.
 
 Ana ajan akisi:
 
-1. `aops discuss start --slug <slug>` ile hedefi/agent'lari tasiyan bir karar topic'i ac; koordinasyon icin `aops chat room create` ile bagli bir oda ac.
+1. `aops discuss start --slug <slug>` ile hedefi/agent'lari tasiyan bir karar topic'i ac; mevcut ChatV3 odasina topic binding ekle.
 2. Operator istegini, repo root'larini, kisitlari ve beklenen deliverable'lari topic'in ilk turn'une (veya odaya context mesaji olarak) yaz.
 3. Karsi ajana net bir directive ver (oda mesaji veya `pm review-request`): "bagimsiz arastir, sadece benim draft'imi review etme" acik olsun. Beklenen ciktida current-state map, oneriler, tradeoff'lar, riskler ve acik sorular yer alsin.
-4. Directive'i odaya `chat message send` ile duyur; karsi ajan manuel baslatilacaksa hangi odayi/topic'i dinleyecegini operator'e bildir.
+4. Directive'i odaya `aops chat send` ile duyur; hangi session/room/topic'in dinlenecegini netlestir.
 5. Ana ajan kendi arastirmasini paralel yapar ve kendi stance'ini `discuss turn` ile topic'e yazar.
-6. Karar turn'unu odaya kisa bir `chat message send` ile duyur; topic id/turn ve karsi ajandan istenen review sorulari yazilsin.
-7. Cevap icin karar dongusunu `aops discuss wait --topic <topic> --agent <agent> --timeout-sec 540 --interval-sec 5 --json`, koordinasyon uyandirmasini `aops chat listen --for <agent> --max-loops 1 --json` ile bekle. Discuss icin `--id` ve `--for` yalnizca geriye uyumlu alias'lardir.
+6. Karar turn'unu odaya kisa bir `aops chat send` ile duyur; topic id/turn ve istenen sorular yazilsin.
+7. Cevap icin `aops discuss wait ...` ve `aops chat listen --session <session> --room general --after-seq <cursor> --timeout-sec 60 --json` dongulerini dogru cursor ile surdur.
 8. Cevap gelince sadece oda TL;DR'ini degil, karsi ajanin full `discuss turn`/scratch dosyasini oku. Agreement, correction, pushback ve operator karari isteyen noktalar icin yeni bir `discuss turn` yaz; odaya ping at.
 9. Ciddi ayrilik varsa bir bounded loop daha ver. Mimari/yuksek etki konularda tek oda cevabindan sonra final plan yazma.
 10. Implementasyona gecmeden once en az iki realtime tur tamamlanmis olmali ve sonuc `discuss conclude` ile final-stance/consensus olarak yazilmali. Direkt implementasyon + sonradan review yalniz operator bunu acikca override/urgent mod olarak isterse uygulanir; override da kaydedilir.
@@ -639,27 +638,27 @@ Ana ajan akisi:
 
 Karsi ajan akisi:
 
-1. Directive'i ele al ve odaya "arastiriyorum, sonuc donecegim" notu yaz; `chat catchup --apply` ile read cursor'u ilerlet.
+1. Directive'i ele al, odaya ACK yaz ve yalniz okudugun mesaja kadar cursor'u `chat read --mark-delivered --mark-read` ile ilerlet.
 2. Istenen kaynaklardan bagimsiz arastirma yap; ana ajanin draft'ini tek truth sayma.
 3. Kendi research/stance'ini `discuss turn` ile yaz ve oda cevabinda topic id/turn ile kisa ozet ver.
 4. Ana ajan kanitli pushback verirse yeni bir `discuss turn` ile hangi noktalari kabul ettigini, hangilerini surdurdugunu ve hangilerini operator'e biraktigini belirt.
 
 Minimum kalite kapisi: iki ajanin da en az bir bagimsiz context/research turn'u olur; ya da ana ajan bounded timeout'u ve "karsi cevap beklenmeden ilerleniyor" notunu operator'e acikca yazar.
 
-### 16.5 ChatV3 product-channel room context
+### 16.5 ChatV3 agent-owned room context
 
 #### 16.5.1 Overview
 
-`aops chatv3`, hosted `aops chat` odasi degildir; encrypted product-channel/session CLI'idir. Invite/session/member token ve room epoch key context'i local ChatV3 session store uzerinden calisir. Hosted AOPS coordination icin `aops chat`, aktif product-room takibi icin `aops chatv3` kullanilir.
+`aops chat` canonical ChatV3 surface'idir; `aops chatv3` ayni komut agacinin compatibility alias'idir. Invite/session/member token ve room epoch key context'i agent-owner bazli local store'da sifreli tutulur.
 
 Common commands:
 
 ```bash
-aops chatv3 listen --session codex --room general --after-seq <last-seq> --timeout-sec 60 --json
-aops chatv3 binding add --session codex --room general --binding-type projectman.review-request --ref-id <rr-id> --title "Slice review" --json
-aops chatv3 binding list --session codex --room general --json
-aops chatv3 room brief --session codex --room general --for claude --json
-aops chatv3 room summary --session codex --room general --after-seq <last-seq> --json
+aops chat listen --session codex --room general --after-seq <last-seq> --timeout-sec 60 --json
+aops chat binding add --session codex --room general --binding-type projectman.review-request --ref-id <rr-id> --title "Slice review" --json
+aops chat binding list --session codex --room general --json
+aops chat room brief --session codex --room general --for claude --json
+aops chat room summary --session codex --room general --after-seq <last-seq> --json
 ```
 
 Kural:
@@ -669,6 +668,8 @@ Kural:
 3. `room brief` guidance, members, presence, bindings, cursor refs ve recommended next reads iceren read-only onboarding pack'tir.
 4. `room summary` agent-composed narrative digest pack'tir; `sourceRef.type=chatv3.room`, seq range, nextReadRefs, summarization-only sourceMessages ve `NARRATIVE-DIGEST` slot'lu memoryWrite recipe verir.
 5. `sourceMessages` yalniz ozetleme girdisidir; memory'ye aynen yazilmaz. Agent once abstractive narrative digest uretir, sonra digest + refs + seq range'i explicit `mem checkpoint` veya `mem summary` ile yazar.
+6. Default store agent owner'a gore ayrilir. Baska agent'in session/store'unu secmek fail-closed olur; legacy shared session ilk owner tarafindan tek sefer claim edilir.
+7. `send --mark-read/--mark-delivered`, arada unseen mesaj varsa cursor'u ilerletmez; `result.cursorAdvance` gap'i aciklar.
 
 ## 17 Resource sugar
 

package/agent-assets-release/agent-assets/core/070b0d3126c645890845791b67157fdd9f43a482fda66583e84fb159b30689a5/files/user-guides/chatv3.md

@@ -0,0 +1,98 @@
+<!-- Public packaged snapshot from canonical slug:aops ChatV3 guidance. Installed command --help and live schema win on drift. -->
+
+# ChatV3 User Guide
+
+## 1 Canonical CLI surface
+
+`aops chat` is the canonical ChatV3 command tree. `aops chatv3` is retained as
+a compatibility alias and exposes the same behavior. The former Agentspace
+hosted-chat sugar is no longer projected as a second `aops chat` system.
+
+| Need | Command |
+| --- | --- |
+| Join from an invite | `aops chat join "<invite>" --handle <agent> --save-session --json` |
+| Send text | `aops chat send --session <id> --room <slug> "<text>" --json` |
+| Read once | `aops chat read --session <id> --room <slug> --after-seq <n> --json` |
+| Foreground wait | `aops chat listen --session <id> --room <slug> --after-seq <n> --timeout-sec 60 --json` |
+| Bind PM/doc refs | `aops chat binding add --session <id> --room <slug> --binding-type <type> --ref-id <id> --json` |
+| Roster/presence | `aops chat member list ...`, `aops chat presence set ...` |
+| Local sessions | `aops chat session list|get|forget ... --json` |
+
+`read` and `listen` return `messages`, `messageCount`, `latestSeq`, and
+`caughtUp`. `listen` exits `0` when it finds messages and `22` on timeout. A
+timeout is not task completion: continue bounded foreground listening while
+the room still owns active work.
+
+## 2 Agent-owned local session store
+
+ChatV3 session records include encrypted member tokens plus either E2E wrap
+material or server-managed room epoch keys. They are local credentials and
+must never appear in messages, source files, logs, PM records, or shell
+history.
+
+The default store is isolated by local agent owner under
+`~/.aops/chatv3/<owner-hash>/sessions.json`. Owner selection is:
+
+1. explicit `--session-owner <id>`;
+2. `AOPS_CHATV3_SESSION_OWNER`;
+3. detected Codex or Claude session identity;
+4. the local interactive operator identity.
+
+The raw identity is hashed before it is persisted or shown. Each owner also
+has a separate encryption key file. Passing a store owned by a different
+agent fails closed. A legacy `~/.aops/chatv3-sessions.json` session is claimed
+once and copied into the first owner that loads it; another owner cannot claim
+that same legacy session afterward.
+
+`--store-path` remains an advanced exact-path override. Even with that
+override, the store header must match the current owner.
+
+## 3 Cursor safety
+
+Use `read` or `listen` to consume messages and then advance delivered/read
+cursors to the highest message actually returned.
+
+`send --mark-delivered --mark-read` is guarded. Before sending, the CLI reads
+the current member receipt. It advances to the sent sequence only when the
+previous cursor is exactly `sentSeq - 1`. If another message arrived in the
+gap, the message is still sent but `result.cursorAdvance` reports
+`unseen_message_gap` and the cursor is not advanced. Read the missing range,
+then mark it explicitly. This prevents a concurrent sender from making an
+unseen peer message appear read.
+
+## 4 Encryption modes and invites
+
+| Mode | Cipher suite | Invite fragment | Content access model |
+| --- | --- | --- | --- |
+| `e2e` | `v0-shared-epoch` | `#<keyId>.<accessSecret>.<wrapSecret>` | server-blind content; clients require wrap/recovery material |
+| `server-encrypted` | `v1-server-managed` | `#srv.<keyId>.<accessSecret>` | server-managed encryption; server can access message content |
+
+Cockpit creates `server-encrypted` channels by default and offers `e2e` as the
+stricter client-managed option. Documentation must not describe
+`server-encrypted` as E2E.
+
+Removing a member blocks future member-auth reads, re-mint, and managed epoch
+key reads. It cannot erase material already fetched by that member; rotate keys
+when stronger post-removal secrecy is required.
+
+## 5 Coordination boundaries
+
+ChatV3 messages wake and coordinate agents. Durable execution/review truth
+lives in Projectman; structured design stances and conclusions live in
+`aops discuss`; durable narrative handoff belongs in memory. Bind the relevant
+PM, Docman, Discuss, or repository reference to the room, and include the same
+reference in review requests/results.
+
+Room summaries expose source messages only as summarization input. Persist an
+abstractive digest plus refs and sequence range, never a verbatim transcript.
+
+## 6 Membership and Cockpit
+
+Members are `active` or `removed`; standard roles are `owner`, `member`,
+`operator`, and `observer`. Presence is room-scoped and uses `active`, `idle`,
+`working`, `reviewing`, `blocked`, or `offline`.
+
+`aops chat leave` is the self-removal path. Owners/operators may remove other
+active members. Cockpit must keep bearer/member tokens out of local storage
+and visible text, expose room guidance and cursor state, and preserve honest
+copy for each encryption mode.