Why this project exists in its own words, and the longer-range picture behind the terse intro in README.md. Definitions and seams live in docs/architecture.md; the axioms live in the README. This file is the "why," not the "how."
The workbench model
Ollama-Codex is not just a chat interface and not just a task runner. It is a workbench: a structured place where code, storage, contributors, evidence, review, replacement, and improvement can meet.
The workbench should make it natural to:
- state a purpose,
- generate or change code,
- attach evidence,
- record weaknesses,
- review the result,
- improve the part or the purpose,
- repeat with better judgment.
This is similar to a real free market in the deeper sense: not laissez-faire, not "anything goes," but a setting where comparison, exchange, replacement, and correction are possible because claims and responsibilities are clear.
On the surface, the simpler image is enough:
A coding workbench whose parts become clearer, more interchangeable, and more accountable over time.
The goal is not blind autonomy. The goal is supervised improvement: model and human contributions should be visible, bounded, testable, reviewable, and replaceable.
Plain-language causes
This project can be described through four causes:
| Cause | Plain-language answer |
|---|---|
| Material cause | A computer needing code and storage to become useful; currently Linux, Crystal, and Fossil. |
| Formal cause | An ever-improving coding workbench whose parts become clearer, more interchangeable, and more accountable over time. |
| Efficient cause | Reasonable human and model contributors acting through built-in pressures toward clarity, interchangeability, and accountability. |
| Final cause | To be an ever-improving coding tool. |
The causes do not prove the goal from neutral facts. The goal is chosen. Once chosen, the axioms guide whether the workbench is becoming more robust or drifting toward failure.
Priority and pacing
The workbench should become useful before it becomes general. Interchangeability is an ideal, but the priority of replacing any current choice is dictated by whether the current state has enough efficiency to support that replacement.
The current visible direction is to replace fragile coordination through external chat, CLI sessions, and tmux panes with a Fossil-hosted web UI that can preserve context, coordinate model-backed tasks, show progress, and support review. See TODO.md for the active milestone and BACKLOG.md for deferred direction.