The console is a chat page where a maintainer, the person who looks after a set of software projects, talks with an AI session about all the work going on across them. The session is an AI agent that keeps running between messages, reads every post and acts on the projects' records. The conversation is the session's own thread in this repository's forum, so every message and answer stays in Fossil, the version-control system that also holds the project's wiki, forum and tickets. The page is served by this repository as a Fossil extension (a program Fossil runs to answer a web page) at /ext/console.

What it's for

The console is one app in a larger set of projects, described on The Big Picture. It is built on OCX, the shared layer that lets people and AI agents work on those projects together through Fossil. The console shows three things:

• A vendor's chat can be replaced. Talking with a session needs no company's messaging service. The conversation is ordinary forum posts that anyone with access can read later.
• One place can keep every project moving. The session behind the page knows OCX and the conventions these repositories share, such as the wiki page named Status that each project keeps, listing what's done, in progress and waiting. So it can check where each project stands, bring the maintainer only the decisions that are theirs, and hand the rest to each project's own session.
• The same help can go beyond the page. OCX offers its tools through MCP, the protocol AI agents use to call tools. A voice assistant has already posted in the console's thread that way, on November 6, 2026 (post 094140e61c). The plan is for the whole service to work through voice and other apps too.

DESIGN.md says how it works and the rules it keeps; HISTORY.md what happened and what it taught; SETUP.md every step used to enable the project.

Test

shards install
crystal run ci.cr                 # both builds' specs, as OCX's release route asks
crystal spec                      # reads through SQLite (the default build)
crystal spec -Dfossil_command     # reads by running fossil

Both use a throwaway repository. The browser test bench serves one with the console as its extension and drives this session's Chromium (tools/browser-rootfs) as a person would:

crystal run tools/bench/bench.cr -- OCX2 [ROOTFS] [SHOTS]

OCX2 is an ocx2 to post with, such as the agents daemon's release.

Build

The server runs a static x86_64 binary. Alpine's static libraries come from the Alpine root that tools/browser-rootfs makes (./browser_rootfs make), at $HOME/browser-rootfs:

crystal build --release --static --no-debug \
  --link-flags "-L$HOME/browser-rootfs/usr/lib -llzma -s" \
  src/main.cr -o bin/console-static

-s strips it. Build with -Dfossil_command to read by running fossil.

crystal run ci.cr -- build OUT x86_64 runs the specs and, only if all pass, makes the same binary into OUT with gate.txt and release.txt (each file's SHA-256), as OCX's release route will take it from a client once that route opens to other projects; crystal run ci.cr -- programs says what it builds.

Install on the server

As swk-ai is installed (its HANDOFF.md, "How to change it"): the session commits the source and posts, in its thread, the check-in, the binary's fossil sha3sum and where it is. An admin checks the hash, copies the build into the server's extension directory as console.new, then renames it to console (a plain copy over a running binary fails with "Text file busy"). It is then served as /ocx-console/ext/console, and refuses every other repository.