docs: add mailbox-first collaboration model

minions/chat/README.md

@@ -1,54 +1,52 @@
 # Chat Threads
 
-Use this folder for durable, git-backed discussion.
+Use this folder for PM-owned summaries and historical continuity.
+
+This is not the primary role-to-role request/response surface anymore.
+Actionable minion communication should default to `minions/mail/`.
 
 ## Recommended Files
 
-- `YYYY-MM-DD.md` for general daily notes
-- `YYYY-MM-DD-topic-name.md` for substantive topics
+- `YYYY-MM-DD.md` for PM daily summary notes
+- `YYYY-MM-DD-topic-name.md` for PM topic summaries or historical recap
 
 ## Required Workflow
 
-- when a minion is bootstrapped, it must post a short role/intention announcement in the current `YYYY-MM-DD.md` general thread
-- all chat-thread changes are commit-by-default to keep the coordination trail durable
+- `PM` owns the daily chat thread by default
+- when a minion is bootstrapped or a packet closes, `PM` should mirror a short
+  same-day summary into the current `YYYY-MM-DD.md`
+- all chat-thread changes are commit-by-default to keep the continuity trail
+  durable
 - default commit message format for chat-thread updates: `chat: YYYY-MM-DD thread update`
 
 ## When To Break Out A Topic Thread
 
-Create a dedicated thread when:
+Create a dedicated PM topic summary when:
 
-- a discussion lasts more than a few exchanges
-- a design or review topic has its own decisions
-- bug scrub findings need separation from the daily thread
-- a deploy / runtime topic needs clear history
+- a mailbox packet series needs a condensed historical recap
+- a design or review topic has enough history that a summary helps humans
+- bug scrub findings need a clean summary separate from the daily thread
+- a deploy / runtime topic needs a durable operator-facing recap
 
-## Required Format For Actionable Handoffs
+## Summary Format
+
+Daily or topic summaries should usually include:
+
+- current gate
+- important packet links
+- current next owner
+- operator-relevant context
+
+## Required Format For Summary Decisions
 
 ```text
 DECISION:
 RATIONALE:
 ACTION NEEDED:
+NEXT OWNER:
 ```
 
-## Completion Handoff Contract (ADHD-Friendly)
+## Important Rule
 
-All minions must close work with a clear handoff packet in the active daily thread.
-
-Required structure (in this exact order):
-
-1. `DECISION:` what is now true
-2. `RATIONALE:` why this is the right state
-3. `SCOPE COMPLETED:` what was done
-4. `OUT OF SCOPE:` what was not done
-5. `EVIDENCE:` files, commands, runtime outputs, timestamps as applicable
-6. `BLOCKERS/RISKS:` anything that could stop the next step
-7. `ACTION NEEDED:` explicit next steps with owner labels
-8. `NEXT OWNER:` exactly one of PM, AM, CM, SM, OM-Test, OM, Operator
-9. `READY CHECK:` pass/fail statement for handoff readiness
-
-Hard rules:
-
-- No minion may mark work complete without naming the `NEXT OWNER`.
-- No minion may accept handoff with ambiguous ownership.
-- If blocked, handoff is still required with a blocker packet and explicit owner for unblock.
-- PM must reject handoffs that do not include evidence and clear next-owner assignment.
+Use `minions/mail/` for primary handoffs and packet exchanges. Use
+`minions/chat/` to summarize them.