Seeding the farm: a reminder, eight retrospectives, and a roll-up convention

Why Care?

When the splash for content-farm shipped earlier today, its /changelog page rendered exactly one entry — the one announcing the splash itself — and its /context-v listing surfaced only what content-farm had at the parent level. The plugins below were silent. Empty changelog directories, empty context-v directories.

This entry covers the work that turned silence into starting material. Every plugin in the farm now has at least one piece of canonical content sitting where the upcoming roll-up loader will look for it. When the loader lands, it will find a feed worth reading, not a row of empty results.

If you're another team thinking about the "free landing page per repo" pattern, this entry shows the in-between work that makes the rolled-up version actually have content on day one.

What's New?

• One canonical reminder, seeded across 8 plugin repos. A new context-v/reminders/This-is-an-Obsidian-plugin-Read-Obsidian-API-Docs.md lives in every plugin we own that targets Obsidian. Same content in each: a pointer to https://github.com/obsidianmd/obsidian-api, the most common review-bot rejection reasons, and a "when in doubt, read the API" directive for both humans and agents. obsidian-git skipped (vendored upstream — not ours to convention).

• Eight retrospective changelogs, dated to first-substance commits. Each plugin now has a changelog/YYYY-MM-DD_01.md written this week but dated honestly to the earliest commit that demonstrated the plugin's identity. Ranges from 2025-02-19 (grab-reference, when it was still GrabCite) to 2025-09-30 (filestarter). Convention now applied to the past where the substance warrants it.

• Five of those eight retrospectives revised same-day. Initial drafts leaned on a "shared lineage from a forked starter" framing across cite-wide, image-gin, perplexed, plunk-it. The lineage is unremarkable — every Obsidian plugin forks from the same official sample — and the framing was demoting each plugin's actual identity. Revised to lead with substance; lineage as a one-line footnote where mentioned at all. Filestarter rewritten to reflect the real origin: we built a better starter because Obsidian's official sample is too simple to be useful.

• Roll-up convention encoded in two skills. The pseudomonorepos skill gets a new "Content roll-up across the tree" section plus a references/content-rollup.md deep-dive (auth, endpoint shape, failure modes, loader sketch). The changelog-conventions skill gets a new "Roll-up at every level" section. Together they capture the intent: parent splashes aggregate their children's changelog/ and context-v/ via the GitHub Content API at build time, with provenance.

• Roll-up promoted to top of Phase 2 in the spec. The splash spec at context-v/specs/Github-Splash-Page-for-Content-Farm.md now lists content roll-up as the priority follow-up — moved above LFM integration and the OG-image work — because once the loader lands, every other improvement compounds.

• Submodule pointers bumped. content-farm now points to the latest tip of each plugin's development branch — the new content above is what the bumped pointers reference.

What rolls up when the loader lands

By the numbers, the day the GitHub Content API roll-up loader is built:

That's a feed. Every plugin contributes. Every entry has provenance. Three plugins (cite-wide, image-gin, perplexed) have meaningful pre-existing content from before the seeding round; the others contribute the seed content alone. All readable.

The arc

The plan walking in: roll-up loader for the splash. The realization halfway through: rolling up empty directories surfaces nothing. The unblock was the seeding work — not the loader itself, but the content the loader will eventually find.

Three buckets of seed work:

1. Reminders. One canonical reminder file per plugin. Pointed at the same external resource (the Obsidian API repo). Identical content across plugins so the rolled-up feed shows the same card surfacing from every plugin's slot, with the source plugin distinguishing them. This is exactly the pattern roll-up will exercise: shared content, distinct provenance.

2. Retrospective changelogs. Walked each plugin's commit history in chronological order, identified the first commit where that plugin's identity became real (not setup, not boilerplate), and wrote a retrospective entry dated to that commit. Eight entries spanning eight months of historical substance.

3. The convention. Captured in skills — pseudomonorepos for the mechanism, changelog-conventions for the writing implications. The convention is now durable across future agent sessions; the next splash a Lossless repo gets won't have to figure this out from scratch.

Voice notes from the retrospective round

The retrospectives are written in the voice the changelog conventions skill calls for — first-person plural, present tense for what's now true, past tense for the journey, honest about the messy middle. A few stand out:

• file-transporter documents a same-day deadend honestly. The original commit message was deadend(auth): google docs authorization not working. The retrospective preserves that honesty rather than papering over it.

• grab-reference is honest about the original GrabCite stack — Docker microservice, React, StyleX, Vite, Prisma — that we'd later move away from after Lossless adopted the Astro Knots tech hierarchy. Pretending we always picked the current stack would be revisionist.

• filestarter acknowledges a contemporary reality: AI-assisted scaffolding has weakened the case for a generic starter plugin. The repo's role is shifting toward file-starting patterns, hence the May 2026 rename.

What's next

The roll-up loader. With 13 changelog entries and 46 context-v entries waiting across the farm, the implementation now has a worthwhile target. Spec is at context-v/specs/Github-Splash-Page-for-Content-Farm.md (Phase 2 follow-ups, top of list); mechanism details at pseudomonorepos/references/content-rollup.md (skill).

Also worth flagging: cite-wide and image-gin store changelog-shaped files under context-v/changelogs/ instead of at the repo root. The roll-up loader needs to handle the legacy placement and route those entries to the changelog feed, not the context-v feed. Captured in the inventory but not yet implemented.