Your Project Documents Itself

New

• Agents document every package in its own repository

  When a story finishes, the agent that wrote it documents what it built in the package's .trinity/docs/ folder, committed with the code in the same pull request. Each package gets an index that links everything, the rules every change to it follows, a page per technology it relies on with the pitfalls agents actually hit, a tech guide on how the code works, and a user guide on what people see and do. Every page is checked before it's committed: links and headings resolve, nothing sits outside that structure, and pages describe how things are rather than how they got there. Quality checkpoints then tidy the docs across stories, merging duplicates, correcting pages that drifted from the code, and removing ones the code no longer supports. Because the docs live in your repository, any person or tool working in the code reads the same thing your agents do.
• Every AGENTS.md points to its documentation

  Trinity keeps a short generated section in the AGENTS.md at your workspace root, in each repository, and in each package, pointing to where that package's documentation starts, so any coding agent that opens the code finds it. Everything you write around that section stays as it is, and a CLAUDE.md that points to AGENTS.md is added beside it where you don't have one. A package a story creates gets its section in that story, and a repository the story didn't otherwise change never gets a pull request just for the section.
• Importing a project opens a pull request of starter docs

  When you import an existing codebase, Trinity drafts four starter pages for each package (architecture, tech stack, setup, and features) from the code and the docs already in it, then opens one pull request per repository into your dev branch, committed as you. Nothing is committed to your branches directly, so the pull request is where you review and correct the pages. A package that already has a .trinity/docs/ folder keeps it, a package whose pages fail the documentation check is left out and listed with what was found, and the Done screen links each pull request or says why a repository got none, such as a starter-docs pull request from an earlier import that is still open.
• See what changed after every update

  The first time you open Trinity after an update, a What's new card shows that version's highlights, with a link to the full changelog. It shows once per machine for each version and waits until you've finished any setup Trinity asks for. A fresh install skips it, going back to an earlier version doesn't bring it back, and a version whose notes aren't published yet shows its card once they are.

Improved

• Trinity keeps its local files out of your commits without touching your .gitignore

  Your decrypted .env files, secret files, and each package's Docker state are ignored through your repository's local git exclude file instead of lines in .gitignore, so none of them can reach a commit and nothing has to be committed to keep it that way. Docker state now lives in each package's .trinity/local/ folder. If your .gitignore still holds the Trinity block that ignored the whole .trinity/ folder, the next story that works in that repository removes the block in its pull request and leaves the rest of the file as it was.
• Every provider's model lineup is current

  Claude Opus 5.5 is the reasoning default on Claude Code, GPT-6 Sol and GPT-6 Luna are the reasoning and micro defaults on Codex, xAI moves to Grok 4.7, Xiaomi to MiMo V2.6 Pro and V2.6 Flash, DeepSeek to V4.1 Flash, and Sakana to Fugu Ultra v2.0. The models they replace leave the model picker, and the cost of work already run on them still shows in your metrics. A tier or story step still set to one of them runs that tier's default and shows the old model as unavailable until you pick another, and it never blocks saving your other settings. Cost figures follow each provider's current published prices too, including GLM 5.3 Flash's list price and Qwen3 Coder Next's prompt-size tiers, which offer no cache discount, and Kimi K3 now uses its full 1,048,576-token context window.
• The architect tells you which edits it didn't apply

  When the architect commits a plan, a change to a story that has already landed or is otherwise protected is left alone. The architect's closing summary now names each change it skipped, with the reason. If any proposed removal can't be applied, nothing is removed, and the message names each story that blocked it by title, with its state.
• Summarizing a long conversation never switches you to a frontier model

  When a conversation grows long enough to summarize, Trinity picks the cheapest of your micro, standard and reasoning models that can hold it, and otherwise uses the conversation's own model. It never moves to a frontier model on its own, so frontier stays a model you choose by hand.

Breaking Changes

• The Knowledge Base is gone — The Knowledge view, its pages and gotchas, its search, its share links and export, and everything stored in it have been removed, and agents no longer read from or write to it. Your project's documentation lives in your own repositories instead, written by the agents that do the work, and an import writes its starter docs there as a pull request rather than into Trinity. Export any Knowledge Base pages you want to keep before you update.
• Comment threads no longer have an AI chat — The assistant you could open inside a story's comment thread, and its button for posting a summary of that chat, have been removed, along with the AI badge those summaries carried. Comments work as before: you and the architect write and resolve them, and the agents building a story still follow its unresolved comments. To talk a story through, use an architect conversation.