189 lines
8.6 KiB
Markdown
189 lines
8.6 KiB
Markdown
# ohm-session-history
|
|
|
|
Full Claude Code session transcripts from the build of the
|
|
[Open Human Model](https://ohm.wiggleverse.org) — 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`](https://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`](https://ohm.wiggleverse.org/docs/sessions)
|
|
(live from rfc-app v0.19.0+).
|
|
|
|
<!-- operator: rewrite this section in your voice -->
|
|
## 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`](https://git.wiggleverse.org/ben.stull/rfc-app/src/branch/main/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.
|
|
|
|
<!-- operator: rewrite this section in your voice -->
|
|
## 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.
|
|
|
|
<!-- operator: rewrite this section in your voice -->
|
|
## 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.
|
|
|
|
<!-- operator: rewrite this section in your voice -->
|
|
## 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:
|
|
|
|
```bash
|
|
~/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](https://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`](https://git.wiggleverse.org/wiggleverse/ohm-rfc)
|
|
— the OHM content repo (RFCs, deployment pin, roadmap).
|
|
- [`ben.stull/rfc-app`](https://git.wiggleverse.org/ben.stull/rfc-app)
|
|
— the framework code OHM runs.
|
|
- [`wiggleverse/ohm-rfc-app-flotilla`](https://git.wiggleverse.org/wiggleverse/ohm-rfc-app-flotilla)
|
|
— the operator CLI for OHM deploys.
|
|
|
|
## License
|
|
|
|
[CC BY 4.0](./LICENSE). Copy, modify, redistribute freely; credit
|
|
the author. Same license as the OHM content repo.
|