Code, comments, and tests refer to the reference design and its rollback
push list by their function, not by the names of their author or their
system. The view comment, the push-order test, and the prompt comment
use "the reference design".
The prompt test keeps its check that the prompt holds no old agent name.
It builds the word from parts, so the source does not spell it.
The system prompt of the UniiChat design and the zoom and date tools
live in prompt.go, so the turns and the compactions send the same bytes
and share one prompt cache. The prompt is the spec text with the agent's
name in place of Unii and the kind reply in place of unii. It holds no
date and no state.
The prompt describes only what OneChat can do, so it leaves out the spec
text on images, the name form of zoom, subagents, background tasks, the
user's computers, and the user's instructions. Each part returns with
the issue that adds its feature. The tool schemas are strict, with every
property required, and encode to the same bytes on each call.
The model client and the ChatGPT authorizer read the time with time.Now
instead of a clock field. No caller set the field, so it was an
injection with no user. A test that needs fake time can run in a
testing/synctest bubble, where the time package uses a fake clock.
writeFileAtomic moves from memory.go to file.go with no change, because
the token file of the login uses it too, and a helper in the file of its
first user hides the dependency of the other. The test clock moves from
log_test.go to clock_test.go for the same reason: the memory, tree, and
replay tests use it only as a clock.
A search of every cross-file use finds no other helper with an unrelated
user. The other shared declarations are parts of the memory core or of
the model client that compose for one purpose.
Code that gets a user in another file for an unrelated purpose moves to
a file named for its function in the same change. The file rules covered
only new code, and the rule against unrelated changes made an agent
leave a shared helper in the file of its first user, where it hid a
dependency of the new caller.
onechat login runs the device code login of the Codex client. It shows
the link and the code, polls until the user approves the code on any
device, trades the grant for tokens, reads the account ID from the auth
claim of the token, and writes auth.json in the data directory with mode
0600. The command needs no browser on the machine.
Before each call to the ChatGPT backend, the authorizer reads the expiry
from the access token. Within 60 seconds of the expiry it refreshes the
tokens, keeps a new refresh token when one comes, and replaces the file
atomically. A mutex lets one refresh run at a time. A missing file or a
failed refresh gives errLoginNeeded and leaves the file as it is. Errors
hold the HTTP status but never an answer body, so no token reaches a
log.
The endpoint in config.json selects the ChatGPT backend with this
authorizer or the OpenAI API with OPENAI_API_KEY, with no fallback from
one to the other. OneChat keeps its own token file, because the Codex
CLI rotates the same refresh token and two programs with one file log
each other out.
The test cases of the configuration and the data directory set their
fields by name, with one field on each line, as the go-code skill
requires. A case then shows which value is the XDG directory and which
is the home directory without a look at the struct.
A search of the rest of the code finds no other positional struct
literal. The node keys stay positional, because the skill allows a small
two-field type that acts as one value.
One client sends every model call of an agent. The ChatGPT backend and
the OpenAI API take the same request body, so the client differs between
them only in its URL and its credentials. Each request sets store to
false and stream to true, sends the input as a list, asks for the
encrypted reasoning, and carries the fixed cache key of the agent, so
the turns and the compactions share one prompt cache. It never sends
max_output_tokens or metadata, which the ChatGPT backend refuses.
The client reads the event stream until the response completes and fails
on a failed, incomplete, or cut stream. Each call, also a failed one,
adds a line to usage.jsonl with the model, the input, cached, and output
tokens, the HTTP status, and the x-codex-* quota headers.
Struct literals use field names, with one field on each line when more
than one field is set, and table-driven test cases follow the same rule.
The old rule applied only to keyed literals, so positional test cases
with many fields on one line passed it. A small two-field type that acts
as one value, such as a node key, can still use a positional literal.
OneChat finds its data directory in ONECHAT_DIR, then in an absolute
XDG_DATA_HOME, then in ~/.local/share/onechat, and creates it with mode
0700. config.json in that directory selects the model endpoint and the
compactor model and effort. A missing file or field takes the default,
and an unknown field or an invalid value is an error, so a typo never
becomes a silent default.
The endpoint is a name, chatgpt or api, not a URL, so the configuration
cannot send a token to another host.
The memory core no longer holds the whole log, which grows by about 200
MB a month. The log and the tree read each message and node from its day
file at the position in an index. index/main.idx holds the position of
message i in record i. index/tree.idx lists the node lines in file
order, and index/tree-L.idx holds the position of node (L, i) in record
i, with a zero record for a node that is not built. A read is one read
of the index and one of the day file.
At open the log and the tree index the lines after their last indexed
line, so a missing index is built again from the day files, and the
lines that a crash left out of an index join it. A partial record at the
end of an index is cut. The last node of the tree gets its level record
again, because a crash can stop an add between the two index writes.
The views keep the nodes of their own lines, and a running build keeps
its task. Nothing else stays in memory: after the 100,000-message
synthetic log the heap in use is about 3.4 MB.
The queue starts the node whose context ends first: a leaf ends before
its message and a merge after its last message, and at a tie the merge
starts first. With leaves before all merges, a backlog of long messages
kept back the merges that a batch needs, so the view could not shrink.
The merges wait in a heap by the end of their context, so the next build
is found without a scan. The leaf window of 8 unbuilt leaves and the
limit of 8 builds stay as they are.
The build limit test opens the gate of the fake summarizer only after
all 8 builds run, so its peak count no longer depends on goroutine
timing. The synthetic log test measures each view as the append did,
with the newest line as the pending mark, because the leaf of the new
message can be built before the check reads the view.
The exit check of the memory core runs a synthetic log of 100,000
messages through the core with the fake summarizer. The log mixes short
user lines, replies, notes, reports, tool calls, and tool output, and
one output in a hundred is over 30 KB. The core has no reader of the
optchat log, because that belongs to the history import.
After each message the test checks that the chat view is at most 128,000
bytes and the compaction view at most 32,000, and that a batch merges
the chat view to 64,000 bytes or less. It checks each rendered line: a
built line holds its node, a long message has a summary and not its
text, and an unbuilt line holds only the pending mark. A restart in the
middle and at the end loads the same views and view.json byte for byte.
Each log line and each node goes to the operating system with one write
and no buffer before the call returns, so a crash of the process loses
nothing. view.json stays atomic through a temporary file and a rename.
An fsync on each write cost about 96 ms per message on a typical disk,
which made a long replay take hours. Durability against a power loss is
a later group commit, with one background sync that makes all earlier
writes durable.
The core keeps the nodes that are ready for a model build in a queue and
never scans the tree for work. A leaf joins the queue when its message
is too long to be its own node. A merge joins when both of its children
are built and their texts do not fit in one node. A parent that fits is
built at once, up the tree.
At most 8 builds run at once. A leaf starts once fewer than 8 leaves
before it are unbuilt. Leaves start before merges, oldest first, because
a turn waits for the leaves of all earlier messages. A failed build
starts again at the next message. Each build gets its compaction view
and its input, the source of a leaf or the two child lines of a merge.
The model stays behind a small Summarizer interface, and the tests use a
fake one. The start reads the log and the tree once to fill the queue
again, and builds the free nodes that a crash left out.
A compaction reads the chat view merged further, at the limits of 16 to
32 KB, so that it has context to resolve references without the whole
chat. The compaction view takes each new line of the chat. It merges in
one batch from above 32 KB down to 16 KB, and again when the chat view
merges: then it first takes each merge of the chat view, so it stays the
chat view merged further. Compactions share its prefix and so read each
other's view from the prompt cache. view.json saves it with the chat
view, and a restart loads both as they are.
The context of a build ends at its node: before the message of a leaf,
or after the last message of a merge. It stops at the first line that is
not built, so a compaction never sees a pending mark or a part of a
message.
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.
projects / onechat / log