Collections & history
The document records behind knowledge, rules, plans, and the Knowledgebase map — and where to see revisions.
The Knowledgebase is the way you browse project knowledge in the app. Behind it, documents are stored by kind, with a record of content and status changes. That record lets agents work with durable project facts instead of trying to recover them from an old conversation.
What is stored
| Kind | What it holds |
|---|---|
| Knowledge | Entries describing how the project works, read through the Knowledgebase. |
| Rules | Guidance applied to agents' work, also organized into the project's area map. |
| Plans | Work proposals and their revisions, with open and shipped plans filed under areas. |
| Areas | The Knowledgebase's named chapters, descriptions, covered paths, and hierarchy. The Organizer derives this map from the other documents. |
Knowledge, rules, and plans are versioned documents. Areas are derived map records, not document-version rows: the Organizer can reorganize them as the corpus changes.
What history records
A document's revision chain records creation, edits, removals where supported, and status changes. Each version can carry when it happened, its reason, and whether a person, agent, or system wrote it. A status change records the old and new status; a content revision can show the before-and-after body. A document can be retired without pretending its earlier content never existed.
For plans, the History control on a plan card opens the revision timeline, with version numbers, author, reason, and an expandable diff for content changes. An agent's document read can also request a version timeline. The Knowledgebase's entry reader shows an entry's current body and its source/verification notes when present, rather than a separate all-collections editor. The plan reader inside the Knowledgebase does not show the History button; open the plan in its thread or Plans view for that control.
Keep claims and code together
In a work thread, knowledge and rule writes about unshipped changes remain pending until the thread's work ships. Already-true facts and settled decisions can be saved immediately. Plans follow the thread's publish lifecycle. The thread can still inspect its own pending work. Publishing with the code keeps future agents from treating an unmerged branch as if it were the project everyone shares. A document-only thread can publish its pending writes too. Ship it & pull requests covers that boundary.