The policies it ships with

People and their agents follow these when they record in a collection made from this template. Its owners can change them.

1. Only Logs belong here: one per chat. What a chat produced goes in the collection that holds that kind of knowledge — a Decision in the Product decisions, Design decisions, Architectural decisions or Security decisions collection (and, when it is about a business process, in Processes too), an idea in Ideas, a bug in the Bug tracker — and the chat's Log points to it.
2. A chat Log is one short line naming who asked for what (the user by name, the agent by its credential label) and what came of it. Pass when one line says both; fail when it runs past one line, recounts the steps taken, or leaves either out.
3. Capture the Log with `verb` "chatted", `happened_at` when the chat began, and `prose` of one short line in the third person, such as "Ana asked Claude Code to fix the sign-in redirect; it opened PR #42." Leave out the steps along the way: what the chat produced carries the detail. Supersede the Log only when what came of the chat changes.
4. List what the chat produced in the Log's `outputs`: the ids of the nodes it captured in other collections (decisions, ideas, bugs, actions) and the pull requests, issues or documents it touched. A chat that produced nothing says so, for example `{ "produced": "nothing" }`.
5. When a chat picks up where an earlier one left off, link its Log to the earlier Log with `relates_to`, so a long piece of work reads as one thread.