docs: add mailbox-first collaboration model
This commit is contained in:
deamonkai
@@ -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.
|
||||
|
||||
@@ -1,52 +1,25 @@
|
||||
# General Thread Template
|
||||
|
||||
## Bootstrap Announcements
|
||||
|
||||
Use this once per minion bootstrap.
|
||||
|
||||
- minion:
|
||||
- role:
|
||||
- intent for this session:
|
||||
# PM Daily Summary Template
|
||||
|
||||
## PM
|
||||
|
||||
General coordination notes for the day.
|
||||
|
||||
- active milestone:
|
||||
- current gate:
|
||||
- next review point:
|
||||
- important packets:
|
||||
- next owner:
|
||||
- operator-relevant notes:
|
||||
|
||||
## AM
|
||||
## Bootstrap Notes
|
||||
|
||||
DECISION:
|
||||
Mirror short same-day bootstrap notes here when useful.
|
||||
|
||||
RATIONALE:
|
||||
- minion:
|
||||
- role:
|
||||
- summary:
|
||||
|
||||
ACTION NEEDED:
|
||||
## Topic Recap Links
|
||||
|
||||
## CM
|
||||
|
||||
DECISION:
|
||||
|
||||
RATIONALE:
|
||||
|
||||
ACTION NEEDED:
|
||||
|
||||
## SM
|
||||
|
||||
DECISION:
|
||||
|
||||
RATIONALE:
|
||||
|
||||
ACTION NEEDED:
|
||||
|
||||
## OM-Test / OM
|
||||
|
||||
DECISION:
|
||||
|
||||
RATIONALE:
|
||||
|
||||
ACTION NEEDED:
|
||||
- related packet:
|
||||
- summary note:
|
||||
|
||||
## Operator
|
||||
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
## PM Request
|
||||
# PM Topic Summary Template
|
||||
|
||||
TARGET ROLE:
|
||||
Related packets:
|
||||
|
||||
- `minions/mail/YYYY-MM-DD-sender-to-recipient-topic/`
|
||||
|
||||
DECISION:
|
||||
|
||||
@@ -8,38 +10,10 @@ RATIONALE:
|
||||
|
||||
ACTION NEEDED:
|
||||
|
||||
### AM
|
||||
NEXT OWNER:
|
||||
|
||||
No action needed yet.
|
||||
## Summary
|
||||
|
||||
### CM
|
||||
|
||||
No action needed yet.
|
||||
|
||||
### SM
|
||||
|
||||
No action needed yet.
|
||||
|
||||
### OM-Test / OM
|
||||
|
||||
No action needed yet.
|
||||
|
||||
### Operator
|
||||
|
||||
No action needed until PM reviews the response.
|
||||
|
||||
---
|
||||
|
||||
## Response
|
||||
|
||||
Architecture findings / proposal / implementation report goes here.
|
||||
|
||||
---
|
||||
|
||||
## PM Review
|
||||
|
||||
DECISION:
|
||||
|
||||
RATIONALE:
|
||||
|
||||
ACTION NEEDED:
|
||||
- what changed:
|
||||
- key evidence:
|
||||
- remaining risk:
|
||||
|
||||
Reference in New Issue
Block a user