wiggleverse/session-history
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

reshape: move OHM transcripts under ohm/ for org-wide multi-app layout; add org-wide root README

Browse Source
This commit is contained in:
Ben Stull
2026-06-03 06:54:38 -07:00
parent bd21825bc2
commit 3713299f08
73 changed files with 200 additions and 181 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+12 -181
View File
@@ -1,188 +1,19 @@
# ohm-session-history
# wiggleverse/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.
Org-wide published **session transcripts** for Wiggleverse apps. Each app's
transcripts live under its own `<app>/` subfolder, numbered per app, one folder
per session:
```
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
…
<app>/sessions.json # per-app title manifest, keyed by NNNN
<app>/NNNN/SESSION-NNNN.M-TRANSCRIPT-<start>--<end>.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.
Apps currently publishing here:
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.
- **`ohm/`** — Open Human Model (the rfc-app deployment).
- **`ecomm/`** — Wiggleverse ecomm.
## 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.
The convention and tooling are the Wiggleverse Session Protocol
(`wgl-session-common` skill); each app declares its sessions home in its
`app.json` (schema: `wiggleverse/engineering/schemas/app.schema.json`).