# Chat Threads

Use this folder for durable, git-backed discussion.

## Recommended Files

- `YYYY-MM-DD.md` for general daily notes
- `YYYY-MM-DD-topic-name.md` for substantive topics

## 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
- 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:

- 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

## Required Format For Actionable Handoffs

```text
DECISION:
RATIONALE:
ACTION NEEDED:
```

## Completion Handoff Contract (ADHD-Friendly)

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, CM, 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.