ohm-session-history

Full Claude Code session transcripts from the build of the Open Human Model — including the infrastructure work that preceded it (Session 0001: the git.benstull.org personal-Gitea buildout) and every OHM session since.

Canonical location: git.wiggleverse.org/wiggleverse/ohm-session-history. There is no GitHub mirror. The same content is rendered on-site at ohm.wiggleverse.org/docs/sessions (live from rfc-app v0.19.0+).

Where the record begins

OHM started with two vibe-coded prototypes — exploratory passes the operator built to figure out what the project wanted to be. Neither prototype produced a session transcript; the discipline that produced this record didn't exist yet, and the work was more "what does this even feel like to use" than "ship a deployable version."

The first draft of the framework spec (rfc-app/SPEC.md) was written off what those prototypes had taught the operator. From that draft onward, the build switched to spec-driven development: every session reads the spec, advances one feature, lands on OHM, and records what happened. The transcripts here start at that point — not at the very beginning of OHM's existence, but at the beginning of OHM-as-spec-driven-work.

The two vibe-coded prototypes are not represented here. If you're trying to understand how OHM thinks, the spec is the primary text; the transcripts are the day-to-day record of how the spec gets extended in use.

How OHM gets built

OHM is built in the open in the literal sense. Every build session runs in Claude Code, with one human operator (Ben Stull) and one agent (Claude). The session has a goal, the goal gets executed, and when the session closes a transcript captures what happened — every decision, every wrong turn, every recovery, every spec correction. The transcripts land here.

The build follows a few binding rules that show up in every session:

• One feature per session, one commit per gesture. Sessions don't branch into half-finished work. Either it ships (tag + push + deploy
  • verify) or it stays uncommitted until the next session picks it up — but it doesn't live half-on, half-off in a branch nobody owns.
• Paired-session discipline. The operator gates irreversible gestures (DNS edits, IAM changes, secret rotations, force pushes to protected branches). The agent drafts, the operator commits. Secret bytes never enter the conversation; per ohm-rfc-app-flotilla/SPEC.md §3 invariant 1, the build pipeline has no path through which a secret value can touch the model.
• Parallel forked subagents for fan-out waves. When a session has independent shippable items (e.g., three roadmap items targeting three separate rfc-app minor releases), the driver dispatches them in parallel as subagent threads. Each subagent writes its own subsession transcript (numbered .1, .2, …) and the driver folds the cross-reference into the main session transcript.
• Cross-repo coherence. OHM is three repos in lockstep: the framework code (rfc-app), the deployment content (ohm-rfc, including the pin file that names which rfc-app version OHM serves), and the operator CLI (ohm-rfc-app-flotilla). When a session ships across all three, the transcript names all three commit SHAs in the cut-state table. No ambiguity about what landed where.

Why the transcripts are public

The transcripts are the artifact, not a polished retelling. They include the gestures that worked and the ones that did not, the mistakes and their recoveries, the §19.2 candidates surfaced and deferred (the running ledger of "this deserves its own session later"), and the running thread of what the operator and the agent actually did with each other this turn.

The lesson from rfc-app/SPEC.md §19.3 is that the build is the artifact; the cleanup is dishonest. A redacted record reads as if the wrong turns never happened, which makes the path look obvious when in fact the choosing was the work. So no curation. If a session hit a dead end, the dead end stays. If the operator violated a hard rule and recovered, the violation stays and so does the recovery. The only filter is §3 invariant 1: no secret bytes, ever.

The transcripts are the cross-session driver brief. Future sessions read the last session's transcript before opening — that's how context survives the gap between sessions when the operator and the agent are both fresh. The closing block of each transcript includes a paste-ready prompt for the next session.

Oh and Jan, your joke is in there somewhere.

What's in the repo

Layout: one folder per session, keyed by the 4-digit session number, with the full SESSION-NNNN.M-TRANSCRIPT-<start>--<end>.md filename inside the folder (the SESSION- prefix is retained so files remain self-identifying when shared as raw links). Subagent transcripts (.1, .2, …) sit in the same folder as their parent driver transcript.

README.md
sessions.json
0001/
  SESSION-0001.0-TRANSCRIPT-…md
0013/
  SESSION-0013.0-TRANSCRIPT-…md
  SESSION-0013.1-TRANSCRIPT-…md
  SESSION-0013.2-TRANSCRIPT-…md
  SESSION-0013.3-TRANSCRIPT-…md
…

sessions.json is the title manifest — a flat JSON object keyed by the 4-digit session number, with a human-readable title for each. The on-site sessions browser at ohm.wiggleverse.org/docs/sessions reads this file to render the nav. Subagent transcripts inherit their parent session's title; the .N ordinal disambiguates rows under the parent.

Sessions 0001 through 0013 originally shipped under a letter-form naming (SESSION-A through SESSION-M). Roadmap item #23 (executed in session 0014.0) renamed every file to the zero-padded numeric form via git mv so the audit trail shows file-was-renamed rather than file-was-deleted-and-recreated. Initially the file-level rename was filename-only — the bodies still read "Session I" / "Session M.1" internally — but session 0018.0 also rewrote the bodies to use the numeric form throughout, so cross-references inside a transcript match the filename you'd browse to. The legacy mapping table (A → 0001, …, N → 0014) lives in SESSION-PROTOCOL.md §1 on the private-but-referenced ohm-infra working repo, in case you encounter a stray legacy reference in older external links.

How transcripts get added

The pattern at the end of each session: the driver writes SESSION-NNNN.M-TRANSCRIPT-<start>--<end>.md to ~/git/ohm-infra/ locally, the operator reviews, and the one-line publish script copies the file into the matching NNNN/ folder here and pushes:

~/git/ohm-infra/scripts/publish-transcript.sh \
  SESSION-0017.0-TRANSCRIPT-2026-05-28T08-52--2026-05-28T10-30.md

The script is idempotent: re-running on an already-published transcript no-ops; re-running on an updated transcript pushes the diff with a commit message of the form update SESSION-…md. The script also handles the folder placement — it parses the leading NNNN from the filename and routes into the matching folder.

What this repo is not

• Not a place to discuss OHM. Discussion lives on ohm.wiggleverse.org itself, per the PR-less per-RFC discussion surface (rfc-app v0.5.0). Issues opened here will likely go unanswered; the work is the corpus.
• Not the canonical spec. That lives in rfc-app/SPEC.md and ohm-rfc-app-flotilla/SPEC.md on their respective repos under wiggleverse/. Transcripts reference spec sections; the spec is authoritative when the two disagree.
• Not a curated retelling. Beyond the audit pass documented in ohm-infra/TRANSCRIPT-PUBLISHING-PLAN.md (kept private, no secret bytes), nothing has been redacted. Wrong turns stay in. Operator quirks and self-corrections stay in.

Related repos

• wiggleverse/ohm-rfc — the OHM content repo (RFCs, deployment pin, roadmap).
• ben.stull/rfc-app — the framework code OHM runs.
• wiggleverse/ohm-rfc-app-flotilla — the operator CLI for OHM deploys.

License

CC BY 4.0. Copy, modify, redistribute freely; credit the author. Same license as the OHM content repo.