Where OCX's building blocks are headed. The roadmap reaches beyond this project: it covers the data, the code and the operating system that OCX, and the work around it, are built on. README.md describes each building block as it is today; PLAN.md holds this project's own phases.

Fossil

We intend to replace our dependency on Fossil's C implementation with an interchangeable Crystal implementation. Direct SQLite work in Crystal is scoped to local workspace clones and offline tools, including metadata inspection. A server-spawned CGI may inspect served metadata query-only. The central served repository remains under the Fossil server's ownership: only that server and programs it spawns to answer requests may open it. Agents reach it through HTTPS sync. A future Crystal server replacement assumes the same ownership and preserves concurrency, locking and rollback-journal invariants. fossil remains a testing tool and fallback component.

For bulk media data, Fossil will still provide the metadata.

An imported project is to keep tracking its upstream, closing the circle (ocx-console post d137333a77). Today project imports once: it seeds the git export from git's and Fossil's marks and never pulls from the upstream again, while each push to Fossil goes on being exported. The goal is to import incrementally from the kept marks as well, so Fossil holds both directions, and to serve projects' source dependencies, such as BQ2's, from Fossil, so builds do not fetch from far away. It would take keeping the upstream clone and both marks files for each imported project, a fetch and git fast-export --import-marks of only the new commits into fossil import --git --incremental, and a rule for an upstream branch that also changed in Fossil. It comes after the release route between the server and x86-1 (ticket 8986816c0b), since a change to project reaches the served repositories only through it; its place among OCX's other open work is in the ordered list on the wiki page Status. BQ2's source dependencies kept as unversioned files need none of it and do not wait on it.

Fossil's file and document views are to render GPCR (below), JSON and other formats a reader would otherwise see as plain text, as they already render Markdown and Pikchr (technote). Fossil 2.27 has the parts to try first: its versionable mimetypes setting maps a file extension to a type, and its th1-docs, th1-hooks and th1-setup settings let TH1 take part in serving pages; Tcl, which the technote's fuller renderer needs, is compiled into this host's fossil but cannot load its library. Where those fall short, a renderer served as an extension page, as OCX's console is, needs nothing of Fossil but its CGI fields. The technote also names mimetype-override and mimetype-tile, which Fossil 2.27 does not have.

Crystal

A visually representable subset of Crystal tentatively called GPCR (gp-crystal) is under development to aid development by LLM agents and reading by human agents.

Work on a Crystal compiler has started in the Crystal Robots project with the intention to make it eventually compatible with the entire GPCR subset of Crystal and to make the compiler interchangeable.

Linux

An EFI-hosted operating system built around the design details provided by Andrew S. Tanenbaum's Operating Systems: Design and Implementation and codified in MINIX is on the long-term roadmap. Initially, Linux would still provide device drivers while the OS acts more as a hypervisor governing only processes, but file system and network drivers will eventually be provided as well. Zephyr may be evaluated to provide broad platform support without code bloat, though its heavy tooling dependency makes it a challenging source base.