@aopslabs/aops 0.3.9 → 0.3.10

package/assets/agent-assets/core/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/assets/agent-assets/core/user-guides/chatv3.md

@@ -1,113 +1,98 @@
-<!-- Public packaged snapshot from canonical slug:aops ChatV3 guidance. Read only the relevant section; installed command --help and live schema win on drift. -->
+<!-- Public packaged snapshot from canonical slug:aops ChatV3 guidance. Installed command --help and live schema win on drift. -->
 
 # ChatV3 User Guide
 
-## 1 Encryption Modes And Invite Shapes
+## 1 Canonical CLI surface
 
-### 1.1 Overview
-
-ChatV3 channels declare `encryptionMode`:
-
-| Mode | Cipher suite | Invite fragment | Content access model |
-| --- | --- | --- | --- |
-| `e2e` | `v0-shared-epoch` | `#<keyId>.<accessSecret>.<wrapSecret>` | server-blind content; every browser needs the invite wrap secret or a recovery package |
-| `server-encrypted` | `v1-server-managed` | `#srv.<keyId>.<accessSecret>` | server-managed content encryption; the server can access message content and can reissue access for active AuthV2-bound members |
-
-Cockpit creates new channels as `server-encrypted` by default and offers `e2e`
-as the stricter client-managed option. The UI and documentation must keep the
-copy honest: `server-encrypted` is encrypted by server-managed keys, not E2E.
-
-`server-encrypted` joins use the `srv` invite form, then fetch server-managed
-epoch keys for the active member. A fresh AuthV2 login can reopen a
-server-encrypted channel by re-minting the member token when the principal is
-still bound to an active membership. `e2e` channels cannot use server remint;
-they stay locked until the browser has the invite wrap secret or account
-recovery material.
-
-Removing a member blocks future member-auth reads, remint, and server-managed
-epoch-key reads. It does not delete any raw epoch keys or messages already
-fetched by that browser before removal; use a rotate follow-up when stronger
-post-removal secrecy is required.
-
-## 2 Agent CLI Contract
-
-### 2.1 Overview
-
-Agents should use `aops chatv3` when they join or operate inside a ChatV3
-product channel.
+`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 chatv3 join "<invite>" --handle <agent> --save-session --json` |
-| Send text | `aops chatv3 send --session <id> --room <slug> "<text>" --mark-delivered --mark-read --json` |
-| Read once | `aops chatv3 read --session <id> --room <slug> --after-seq <n> --json` |
-| Wait for new messages | `aops chatv3 listen --session <id> --room <slug> --after-seq <n> --timeout-sec <n> --json` |
-| Roster | `aops chatv3 member list --session <id> --json` |
-| Presence | `aops chatv3 presence set --session <id> --room <slug> --state working --json` |
-| Leave | `aops chatv3 leave --session <id> --json` |
-| Local sessions | `aops chatv3 session list|get|forget ... --json` |
-
-`read` and `listen` always return explicit cursor state:
+| 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
 
-- `messages`, including `[]` when no new messages exist
-- `messageCount`
-- `latestSeq`
-- `caughtUp`
-
-`listen` exits with `0` when messages are found and `22` on timeout. It is a
-polling primitive; server-sent events remain a UI/runtime concern.
-
-`join` uses the server URL embedded in the invite by default. `--api-base-url`
-is an explicit override for controlled local smoke tests. Join output includes a
-short orientation summary with channel, active room, room count, member count,
-recent message count, and the parsed invite mode (`e2e` or
-`server-encrypted`). When `--save-session` is used, the local session store keeps
-the member token plus either the `e2e` wrap secret or the imported
-server-managed epoch keys encrypted at rest.
-
-## 3 Member And Presence Model
-
-### 3.1 Overview
-
-Members use `MEMBER_STATUSES = active | removed` and
-`MEMBER_ROLE_KEYS = owner | member | operator | observer`.
-
-Presence uses `active | idle | working | reviewing | blocked | offline`.
-Presence is scoped to a room and is safe to expose in roster surfaces because it
-contains only member id, state, note, update time, and expiration state.
-
-## 4 Self Leave And Admin Cleanup
-
-### 4.1 Overview
-
-`chatv3.member.update` is callable with member auth but the service keeps the
-authorization boundary narrow:
+| 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 |
 
-- a member may only update its own member row to `status: "removed"`
-- that self-leave path must not include `roleKey` or `displayName`
-- every other member update still requires `owner` or `operator`
+Cockpit creates `server-encrypted` channels by default and offers `e2e` as the
+stricter client-managed option. Documentation must not describe
+`server-encrypted` as E2E.
 
-The CLI exposes the self path as `aops chatv3 leave`. Cockpit exposes both
-member self-leave and owner/operator cleanup, but the domain service remains the
-source of truth for authorization.
+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.
 
-No migration is required for self-leave because `removed` is already the
-canonical member status.
+## 5 Coordination boundaries
 
-## 5 Cockpit Expectations
+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.
 
-### 5.1 Overview
+Room summaries expose source messages only as summarization input. Persist an
+abstractive digest plus refs and sequence range, never a verbatim transcript.
 
-ChatV3 cockpit clients should make the agent-oriented state visible:
+## 6 Membership and Cockpit
 
-- channel/room orientation: active channel, active room, room count, member
-  count, message count, channel guidance, and room guidance
-- roster and presence: active/removed members, role, presence state, read/deliver
-  cursors, and directive ACK rollup
-- membership controls: current member can leave; owners/operators can remove
-  other active members
+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`.
 
-ChatV3 UI must not store bearer tokens in local storage, must not expose member
-tokens in visible text, and must preserve the server-blind message-content
-boundary for `e2e` channels. For `server-encrypted` channels, UI copy must
-state that the server can access message content.
+`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.

package/assets/agent-assets/core/user-guides/docman.md

@@ -80,6 +80,22 @@ Versions are immutable snapshots of authored content. To revise content:
 This preserves what readers and agents saw previously and makes publication
 history auditable.
 
+### Review evidence for mutable drafts
+
+Before requesting review, compose or materialize the exact candidate and keep
+the returned version identifiers and `contentHash`. Record one complete
+immutable evidence reference in the Projectman review request, for example:
+
+```text
+docman:page-version:<id>#contentHash=sha256:<digest>
+```
+
+An approved review result repeats the exact same reference. Saving the draft
+again changes the content hash; the earlier result remains historical evidence
+for the old content and a linked re-review is required for the new hash. A
+mutable page-version id without its content hash is not sufficient approval
+evidence.
+
 ## Sections and Pages
 
 Sections provide navigation and grouping. Pages hold readable content. Ordered

package/assets/agent-assets/core/user-guides/projectman.md

@@ -151,6 +151,13 @@ A reviewer can approve, comment, or request changes. When changes are requested:
 3. record the new evidence
 4. create or continue the linked re-review flow
 
+When the reviewed candidate is a mutable Docman draft, the review request must
+carry the exact composed evidence reference: document/page version ids together
+with `contentHash=sha256:<digest>`. An approved result repeats that full
+reference exactly. If the draft is edited, its hash changes and the previous
+approval no longer covers the new content; keep the old result and open a
+linked re-review.
+
 Chat can wake or coordinate participants, but Projectman remains the review and
 execution source of truth.
 

package/assets/agent-assets/core/user-guides/working-disciplines.md

@@ -357,7 +357,7 @@ aops pm review-request create \
   --target-agent <reviewer> \
   --apply --json
 
-aops chatv3 send --session <session> --room general \
+aops chat send --session <session> --room general \
   --text "REVIEW READY: PM RR <id> ..." --json
 
 # reviewer appends result
@@ -513,7 +513,7 @@ aops pm ktask create --board <board> --column Doing --title "<task>" --apply --j
 aops plan create --task <task-id> --name "<plan>" --goal "<goal>" \
   --scope-item "S1 ..." --scope-item "S2 ..." --apply --json
 aops mission update --id <mission-id> --active-plan <plan-id> --apply --json
-aops chatv3 send --session <session> --room general \
+aops chat send --session <session> --room general \
   "GOREV ATAMASI: mission <id> / ktask <id> / plan <id> - S1'den basla, slice basina RR" --json
 
 # implementer: per slice