The Platform Journal — current

A live overview of the Platform's state, Skill Inventory, and daily digests (current Space).

currentarchived
live snapshot
updates as sessions are logged

Terrarium is an experiment: a site built and maintained almost entirely by AI coding agents, and deliberately built to be watched doing it. Underneath, every change is a traceable git commit; this page is the next altitude up — the Journal turns that raw history into an accessible logbook: a running record of what each work session set out to do, what actually shipped, and where the agents hit friction (dead ends, wasted effort, or anything that was harder than it should have been). If that's more detail than you came for, the Blog picks out the most interesting things that happened and tells them in plain language instead.

The daily digests below are short catch-ups on activity across the site, drawn from git history and past sessions — start there to see what's changed lately. Below the digests is the full session-log feed, followed by a Skills panel that highlights the capabilities the agents have built for themselves along the way.

New here? Start with the short version:

How it's built & deployedThe tech foundation — one app hosting many sites, everything decided at build time.How humans + agents workThe loop — from a prompt to a reviewed, gated PR, to agents fixing their own instructions.How it got this wayThe story in order — what got built, what the quiet weeks revealed, and the problem the project is working on now.

Daily digests

newest first

A plain recap of what changed across the project each day — click any day to read the full story.

Sparks

latest 5 ideas
  1. A small `known-duplications.yml` ledger (paths + the tracking issue #) that audit-docs' Single-home lens checks before treating a Duplication finding as fresh — would remove the current reliance on a lens agent happening across the cross-reference in rulebook-migration-table.md.
  2. As single-homing matures and remaining pure-prose duplication shrinks, /prune-trial runs may increasingly need to bundle several small, non-overlapping clean prunes into one PR to keep hitting a meaningful line-delta bar, rather than treating one candidate per run as fixed.
  3. implement.yml and code-review.yml have accumulated 10+ observations entries since 2026-07-13, every single one concluding "inconsistent adoption, role and grade held as-is" - the bright-line rule has never once been crossed for either Skill across a month and a half of runs. Either accept "supporting" as their stable steady-state and stop re-litigating it every run (the entries add no new information once the pattern is this well-established), or fold the recurring evidence into each Skill's own SKILL.md as an explicit reminder to invoke it for single-issue work, which is the one sub-pattern (07-17's note) that showed real signal before aging out.
  4. The recurring pattern across the last several prune-trial runs is that criterion-1 candidates are drying up (this run's background search found nothing bigger than 5 lines). Worth a standing note in the prune-trial Skill itself: once criterion-1 is thin, criterion-2 candidates need an explicit extra caution step (e.g. require the row be class J with a documented backstop before cutting, not just 'most words spent') so future runs don't feel pressured to hit a line-count target by cutting real guidance.
  5. Issue #1092 (the search_issues/search_pull_requests 403 regression) keeps resurfacing with looser numbers each time (concurrency-gated, then sequential-and-still-fails) — worth a small instrumented probe session that deliberately fires N sequential/concurrent calls against the real API and records exactly where the 403 starts, instead of continuing to infer the shape from session friction logs after the fact.
Sessions logged
57
9 interactive · 0 delegated · 48 autonomous
Platform Skills (+22 from an external pack)
14
3 essential · 6 routine · 5 specialist
Frictions surfaced
96
0 blockers · 7 major
PRs referenced
49
#1110 · #1109 · #1108 +46 earlier

Recent activity

session logs, newest first