The view is a list of tree nodes that covers the whole chat, oldest
first. Each new message appends its leaf as a line. Once the node text
of the view goes above 128,000 bytes, one batch merges the most due
sibling pairs until it is at most 64,000 bytes. Due is (T - last) / 2^l,
measured from the last message of the pair, and the oldest pair wins a
tie. A batch merges only pairs whose parent is built, and it continues
at each new message until it gets to 64,000 bytes. With the length of
Taelin's push list as the budget, the merges match the push for t = 0 to
20,000.
The memory core logs each message, builds the nodes that need no model
call, appends to the view, and writes view.json atomically after each
change. view.json holds the lines and the batch state, and the start
loads it as it is. The core never builds the view again from the log: a
chat with messages and no view.json does not open. The start only
appends the messages that a crash left out of the view.
A line whose node is not built renders as a pending mark, so the view
never holds a part of an unsummarized message.
The tree stores each built node (l, i) as one JSON line, {l, i, text,
size}, in tree/YYYY-MM-DD.jsonl, and loads all lines again at start.
Node (l, i) covers the 2^l messages from i*2^l on. The tree refuses a
node that is already built and a parent without both children, so each
node is built once and the tree never holds a gap.
A source that fits in 512 bytes is its own node with no model call. A
short message becomes the leaf "kind: text" word for word, and two short
siblings join with a newline into their parent.
The log of one chat stores each message as one JSON line, {i, kind,
text, size, date}, in main/YYYY-MM-DD.jsonl for the local day of the
write. Each append goes to the disk before it returns, and the log loads
all lines again at start. An exclusive lock on the chat makes sure that
only one process writes it. After a failed write the log refuses more
writes, because the end of the file is not known.
The kinds are user, unii, tool, echo, work, and note. Size is the UTF-8
byte length of the text. Tests use testify, so the Nix package gets a
vendor hash.
The development shell sets ONECHAT_DIR to .devenv/onechat at the root of
the checkout, unless the variable is already set. Development data, such
as a copy of an old chat log for a replay, stays inside the checkout,
away from a running service, and Git ignores it. Each worktree has its
own .devenv, so parallel work does not share data.
Issues live in git-bug, inside the Git repository, so they work offline
and travel with the code through git bug push and pull. They are not
files in the checkout, so they stay out of diffs, formatters, and the
rule that files describe only the current state.
The development shell supplies git-bug. The issues skill tells agents
how to read and write issues, and warns that the -F option drops every
line that starts with "#". Commit messages now refer to an issue with an
Issue trailer that holds its git-bug ID, because there are no issue URLs
to link.
git-bug has no links between issues, so relations are Parent and
Depends-on trailers at the end of the body, as in a commit message. git
interpret-trailers can read them, and a search for an issue ID finds the
issues that refer to it.
OneChat is a Go program that prints its name. A Nix flake pins the Go
toolchain and every tool, builds the program with nix build, and runs
the binary in an install check. The development shell supplies the
formatters, the linters, and a pinned Vim, and it turns on the commit
message hook.
AGENTS.md holds the rules that apply to every task, such as the Nix
environment, the current-state-only rule, and the rule against revealing
infrastructure. The skills in .agents/skills hold the procedures for Go
code, documentation and comments, checks, and commits, so an agent loads
each one only for the task that needs it.
bin/format and bin/check cover every Go, Nix, RST, and Markdown file
that Git knows about. bin/reflow wraps comment paragraphs the same way
on every machine because it does not use a personal Vim configuration.
CLAUDE.md and .claude/skills are links to the same files, so Claude Code
reads one copy of the rules and skills.