Researched 2026-11-05 by the session of "The One Place", at the maintainer's request (5974e7c333): "research in the history of [ollama] the planning mechanism we tried to setup on the old ollama trunk, before the "ocx" rename, so that projects could keep a set of rolled-up milestones. in the end, it got too complex for me to keep up, but maybe you can front-end a lot of it and help keep the projects moving along without me, without getting overwhelmed yourself." Times are Detroit time.

What it was

On ollama's trunk, from late August to mid-September 2026:

• The roll-up, Aug 26 (ec3fee88aa, docs/ticket-workflow.md). Plans were tickets, not prose, in four levels: one Program on ollama ordering every project's Plan; one Plan per project ordering its Milestones; each Milestone ordering its Work tickets. Each ticket had one line at its top, OCX-PLAN: parent=HASH seq=N, and the tree was read from those lines. Every Work ticket needed an acceptance check the maintainer could confirm from the ticket alone.
• The activity report and the cross-project board, Aug 27 (e517e508cb): one page over every served project, decisions first: "Needs you", then "In work", then what was done.
• What may reach the maintainer, Aug 28 (30ca230e0a): only a decision only they can make (direction, scope, priority between real options, or something irreversible), written as one plain question, 2 to 4 options with a recommendation, and one line on what it unblocks. Never backlog, never work waiting on other work, never a choice a session can make itself. OCX's later rules for asking (its HISTORY, decisions 89 and 90) say much the same.
• A coordinator session, Sep 12 to 17: it took the plan's upkeep off the maintainer, with a memory wiki page it read each turn, a clock that woke it, and its own audits: tickets without a parent, statuses that disagreed with the code, work done out of order, checks missing.

Why it ended

OCX's HISTORY.md: trunk "did a great deal, but a review listed many problems that made its code hard to read" (198a8b52a6). The ocx branch, from Sep 21, "deliberately set aside trunk's coordinator, vector search and multi-project fan-out", and the reset of Oct 3 rebuilt OCX from empty. The maintainer, now: "it got too complex for me to keep up."

What is left of it, read 2026-11-05

The data outlived the code. Tickets still carry OCX-PLAN lines, and most tickets not yet closed were last changed before the reset:

project	tickets with OCX-PLAN	not closed	of those, last changed before Oct 3
ollama	96	473	455
stone	39	44	43
crystal-robots	41	26	26
bootstrap-qcow2	19	36	32
social-badge	12	10	9
interactor	3	7	7
cleave	0	38	0
swk-ai	0	4	0

"Not closed" is any status but Closed, Fixed, Tested or Deferred. Glint, mechanical-turk and stone-media have no open tickets.

What it suggests, not yet decided

• Keep what was learned, drop the machinery. The roll-up's shape (one plan per project, milestones, an acceptance check per piece of work) and the Aug 28 standard for what reaches the maintainer are worth keeping. The activity report, the board's code, the coordinator's clock and its memory page are what got too complex.
• This session as the front end. It reads every project's tickets and threads (it already can), keeps each project's plan current with that project's own session, and brings the maintainer only what meets the Aug 28 standard, one at a time. Nothing new to build at first: Fossil's tickets and forum hold the data.
• Forgetting. About 570 open tickets across these projects were last touched before the reset. Most are likely done, superseded or no longer wanted. They could be closed or deferred project by project, each project's session checking its own, with the maintainer seeing only the ones in doubt.
• Not bringing the mess back. The maintainer, the same night: "this is the best console so far, so try not to bring back that overwhelming mess." So no board, no dashboard and no new page: what reaches them stays one item at a time in this conversation.
• Not overwhelming this session either. One project at a time, starting with one whose session is active.

First batch: ollama's search and docs tickets, and parity, 2026-11-05

The maintainer, 2026-11-05 (afe721d426): "sorting the tickets would be good. i would add a real consideration of parity of ocx with the old trunk. the search features and documentation support across the projects are what stand out to me at first."

What trunk had and OCX has not

Read from trunk's last check-in before the ocx branch, c63c8afd39 (Sep 20):

• Semantic search (docs/vector-search.md, src/vec_*.cr): embeddings from a local Ollama model, kept in the repository's own database and shared as unversioned files, over docs, wiki, tickets, forum, code and agent instructions, of this repository and of imported peers, for agents and people alike. Also a staleness check that flagged docs whose summaries disagreed with the code.
• Docs support (src/docs_builder.cr, src/docs_cgi*.cr, src/stdlib_index_builder.cr): crystal docs built into HTML and served, and an index of Crystal's standard library that agents looked symbols up in.

OCX's trunk has neither. Fossil's own full-text search is off on the server too: /ollama/search, /stone/search and /ocx-console/search each answer "Search is disabled".

Draft sort of the 14, for OCX's session to confirm

ticket	what	draft
994b7a1199, a873f87b51	the activity report	drop: the machinery that got too complex
f8ae391019	cross-project activity feed	drop: this console's sessions do it now
21dfd164d6	JSON API over /ext/ for remote clients	in doubt: near the MCP-for-voice idea in IDEAS.md
7fa610f39a	trunk's Claude runner refusing a docs-gate card	drop: that runner is inactive
cf651911d2	document trunk's chat/task split	drop: that split is inactive
7bea545ac1	trunk's write-topology guard	drop: that guard is inactive
5667eb44d6, 8150605d31, 98640d84c4	docs staleness, Ollama models for embeddings	wait on the search decision
0b8d03b94e, d471b16d75, f3778c55ab	Crystal language server from the stdlib index	wait on the docs decision
27ca3ef247	"Lab" doc protocols	in doubt

Nothing is closed yet.

The parity record that already exists

The maintainer, 2026-11-05 (369d052bb7): "don't miss the existing parity check documentation." OCX keeps parity in docs/parity-v1.md (last changed Oct 31), from the parity audit of Oct 18 (tech-note bb2af9185e); its first form is docs/slices-parity.md. Its baseline is the ocx branch's tip (a46d73f5bf), not trunk before the fork, and the ocx branch had already set aside trunk's vector search. So semantic search and docs support have no row there; only "embeddings" and the tool search_context appear, under "Not copied", among the pre-fork tools that "justified no place in ocx2". What it lists as still to build: steps 2, 3, 4, 12, 21, 9 and 16, Stone showing the questions, live streaming, and run/gemma. The rows above belong in parity-v1.md, as its OCX session decides, not in this file.

Weighed by the virtues

The maintainer, 2026-11-05 (cf700ded6b): "if writing tickets, be sure to evaluate against the virtues." So, for this batch:

• The seven drops serve Parsimony. Each ticket asks for work on code that OCX no longer runs: inactive, not gone. Closing it removes state that nothing needs, and gives each project's list Clarity.
• Search option 1 serves Parsimony and Loose Coupling. It's a setting on Fossil's own search, with no new code, and semantic search can replace or sit on it later. It's demonstrable by one search on each project's /search page that finds what it should.
• Search option 2 costs Parsimony. It needs embeddings, a local model, unversioned stores and a staleness job, which is the scale of what got too complex before. It needs a contract stating what it must find that full-text search cannot, before it is built.
• Any ticket this sort writes, and any it asks a session to write, states the virtue it serves and how it will be demonstrated.

Decided: full-text search first

The maintainer, 2026-11-05 (6cc72ec13b): "i think we start with full text search, but i think getting you a good semantic search will make you better. as long as you can strip out the jargon." Tried on a copy of stone's repository with Fossil 2.27: fts-config enable all, tokenizer porter, index on indexed 1,055 documents in 4.6% of the repository's size, and the /search page found the links bug's forum posts for "clicking". Semantic search stays wanted, for this session's use, with results put to the maintainer in plain words.

The maintainer, 2026-11-05 (ca5db6dcd0): "the code never goes away, just becomes inactive." So a drop here means the ticket's work is not wanted on the active code. Trunk's code stays in the history, and a dropped ticket can be read again if that code comes back.