Bunya-Jido: One Semantic Map

For codex: it increase work-efficiency

Inspiration

I work on an AI-based research automation harness. Two problems grew with it.

First, the project got big enough that I could no longer hold it in my head. Second, when an AI agent needed to notice something broken in the harness and repair it, my only option was stuffing the whole codebase into the context window — most of those tokens spent on files that had nothing to do with the problem.

Bunya-Jido started as one fix for both: a single reviewed semantic map of the repository. I read the map to understand my own project again; the agent reads the same map to locate the broken region and pulls only that region into context. The token savings during maintenance were never the goal — they were a byproduct I noticed later and then started measuring properly.

The name comes from Cheonsang Yeolcha Bunyajido, the Korean star chart that reads the sky through regions and relationships. That is exactly how I wanted a repository to be read.

What it does

The map side existed before Build Week: a scanner and blueprint pipeline that projects a repo into an offline interactive atlas for humans, and compact validated task routes (first reads, relevant tests, edit boundaries) for agents.

What I built during Build Week is the execution half: bunya-jido codex-run. It hands one validated route to the local Codex CLI, lets the route decision pick the sandbox — only a confident MATCH gets workspace-write; everything else runs read-only, with no override flag — then audits every change against the declared boundaries and writes a receipt: route fingerprint, real token usage, elapsed time, changed files, verdict. Open that receipt in the atlas and the same map shows the expected route, the actual changes, and any violations.

How we built it

Codex (GPT-5.6) wrote the ~900-line runner and ~800 lines of tests — guided by Bunya-Jido's own route for that task, which told it what to read first and where it was allowed to edit. The session ID and model metadata are recorded in the repo. My job was the decisions: sandbox mapping, clean-baseline requirement, what a receipt may and may not claim.

Challenges we ran into

Trusting a nested agent. Prompt instructions are not enforcement. The design separates three layers: the OS sandbox enforces, the map instructs, and the post-run audit verifies — write-then-revert still counts as a violation, and a malformed event stream fails the run as audit_incomplete instead of pretending the audit passed.

Testing an agent orchestrator deterministically. You cannot unit-test against a live model, so the suite drives a fake Codex executable through timeouts, malformed JSONL, boundary violations, and injection-shaped input.

A live surprise. Our first live run on native Windows came back with zero changes — Codex reported its OS sandbox as effectively read-only despite the requested workspace-write. The guarded contract held in the restrictive direction, we recorded it as a platform observation, and re-ran under WSL: one docstring edit, inside the boundary, receipt showing 182,823 real input tokens. Both runs are documented.

Resisting a good-looking number. A single run cannot honestly claim "tokens saved," so the receipt refuses to. Savings figures come only from paired map-vs-no-map benchmarks (all 63 synthetic bugfixes preserved, total repair tokens down 19–23%, pre-Build Week, GPT-5.5).

What we learned

A map agents actually follow has to be reviewed evidence, not an auto-generated call graph — and honesty constraints turned out to be a design asset: every number in a receipt is something we can defend.