OSS maintainers are drowning in AI-generated "slop PRs" while simultaneously facing sophisticated supply-chain attacks (xz-utils style). Current solutions (2FA, signed commits, Sigstore) only verify identity — they don't answer "should I trust this person to touch this code?" The cost of contribution review is paid entirely by maintainers, in attention.

NEW EVIDENCE from Graduated Trust cross-links (2026-07-28):

Devin Booking System — real-world proof: 6 AI-authored PRs merged to production in one month. This IS the trust problem today, not hypothetical.

Community Models in Seed — Seed already has the dual trust model (formal communities + informal web-of-trust).

Secure Scuttlebutt — technical precedent: social graph as infrastructure, follow/hops for replication scope.

P2P Trust & Safety knowledge base — foundational primitives: key-based identity, UCAN, capabilities, Sybil resistance.

Combined thesis: The problem is urgent (Devin ships real PRs today), the solution is novel (social-graph distance), and the primitives exist (Seed contacts, capabilities, P2P protocols). Nobody else connects these three dots.

Additional evidence: Graduated Trust proposal, Fix OSS with Seed Hypermedia, Vibe code like a PRO.

OSS maintainers of popular packages (npm, PyPI, crates.io ecosystems)

Foundation security teams (OpenSSF, Apache, Linux Foundation)

Enterprise open source program offices (OSPOs)

CI/CD platform providers (GitHub, GitLab)

A GitHub/GitLab app that computes a trust score for every PR contributor based on their position in a cryptographically verifiable Web of Trust. The score determines friction level:

Hop 0-1 (maintainers + direct vouchees): No friction, normal review

Hop 2 (friend-of-friend): Light checks (key age, single reviewer ack)

Hop 3+ (distant): Proof-of-context questions, observation windows, multiple reviewers

No path: Maximum PoW + canary quarantine

A CLI/server that constructs a trust graph from signed contacts

A GitHub bot that adds a trust-score label + friction checklist to PRs

A simple hop-distance badge in the PR

Publish on a Seed site as the canonical trust-graph viewer.

Ship as a free GitHub App with a "Pro" tier for private repos

Publish the Graduated Trust essay widely (HN, lobste.rs, r/programming)

Partner with one high-profile OSS project (e.g., Homebrew, Tailwind, Vite) as a pilot

Cross-post to OpenSSF, CNCF security channels

Free tier: Public repos, basic hop scoring

Team tier ($99/mo): Private repos, custom friction policies, canary quarantine

Enterprise ($499/mo): SSO, audit logs, EigenTrust-style path quality weighting, integration with existing CI/CD

Sigstore: Verifies identity, not trustworthiness — complementary

Socket.dev: Detects malicious packages, not malicious contributors

GitGuardian: Secrets detection, not trust scoring

EigenTrust (academic): Paper only, no product

Keybase (deprecated): Had proof-of-identity but not scoped vouching

9/10 — The problem is widely acknowledged (xz-utils, slop PRs are daily pain), the solution is novel, and Seed already has the primitives. The Devin case study now provides concrete, documented evidence that the AI contribution problem exists TODAY.

Build a tiny demo: two Seed accounts, one vouch, display hop distance on a mock PR page. Show it to 5 maintainers of popular npm packages. Would they install a GitHub bot that shows this? Would they pay?

MVP: GitHub bot with static hop scoring (week 1-2)

Add vouch creation UI inside Seed (contacts extension) (week 3-4)

Proof-of-context question generation (week 5-6)

Observation windows and quarantine mode (week 7-8)

Self-hosted Enterprise (week 9-10)

---

The web's commenting ecosystem is broken. Disqus is heavy and ad-ridden. Utterances uses GitHub issues as a database. Most comments on the web are unauthenticated, unsignable, and lost when the page changes. Seed users want "the commenting experience to be perfect" — with expand-to-full-window, block-level references, mobile-friendly editors, and no redirects. Seed's content-addressed, cryptographically signed, threaded commenting system solves all of this — but only for Seed-native documents.

Evidence: What I want for the commenting experience to be — 5 explicit UX pain points. Killing the Web Redirect for Commenting — redirect problem solved internally. Discussions Panel Is Confusing.

NEW EVIDENCE (2026-08-07, Pass H): The Experiment: Improve performance in-site interactions — embedded in the Seed Hypermedia project page — benchmarked in-site interactions "specially when try to comment" and shipped real improvements in PR #297. Evidence the commenting interaction path is fast and benchmarked enough to be embedded elsewhere — de-risks the widget's core interaction.

Any website owner who wants better comments than Disqus/Facebook/utterances

Bloggers, indie publishers, documentation sites

Seed site owners wanting embedded discussions on their custom landing pages

P2P/Web3 projects wanting cryptographically verifiable comments

A lightweight JavaScript widget (< 20KB) that any website can embed via a script tag. It renders Seed-powered comments: content-addressed, cryptographically signed, threaded, with block-level linking, no redirect, and optional key-based identity. Comments are stored on Seed's network — the website owner doesn't need infrastructure.

<script src="https://cdn.seed.hm/comments.js" data-account="..." data-path="..."></script> embed tag

A hosted JS bundle that renders comment threads fetched from Seed servers

Inline comment creation with keypair derived from ephemeral or stored seed phrase

Basic moderation: site owner can delete/hide comments via their Seed account

Free tier for personal blogs (5 sites, basic moderation)

Embed on Seed's own docs site first as a reference implementation

Blog post: "Seed Comments Are Better than Disqus — Here's Why"

Launch on ProductHunt, Hacker News as a Disqus alternative

WordPress plugin, Hugo/Eleventy shortcode, generic JS embed

Free: 5 sites, 1,000 comments/month, basic moderation

Pro ($9/mo): Unlimited sites, custom CSS, advanced moderation, export

Enterprise ($49/mo): Self-hosted comment server, SSO, audit logging

Disqus: Heavy, ad-supported, owns your data, not content-addressed

Utterances/Cusdis: GitHub-based, no cryptographic guarantees

Hyvor Talk: Paid, centralized, no P2P

Isso: Self-hosted, Python, minimal features

Remark42: Self-hosted, Go, no block-level linking

7/10 — The UX pain is documented (5 specific points + redirect solution). The technology exists (Seed's existing commenting infrastructure). The challenge is packaging for non-Seed sites and competing with established alternatives. Strong Seed ecosystem benefit: more Seed identities in the world.

Embed a Seed comment thread on a simple static HTML page. Ask 3 Seed users: "Would you switch to this for your blog?" Time how long it takes to set up (target: under 2 minutes).

---

The Graduated Trust proposal is intellectually compelling but abstract. OSS maintainers, OSPO teams, and foundation security staff need practical guidance on implementing graduated trust — how to construct trust graphs, author vouch policies, configure friction levels, integrate with GitHub/GitLab, and handle edge cases (Sybil clusters, compromised accounts). Without a structured learning path, the concept stays theoretical.

Evidence: Graduated Trust — Strategist agent flagged "Graduated Trust in Practice" as #1 content priority. The document has 5 open questions (reputation calibration, Sybil resistance, privacy, scope governance, compromise recovery) that are perfect course modules. Fix OSS with Seed Hypermedia — embeds the full proposal with "Hope y'all can read it and give some feedback!" signaling demand.

OSS maintainers of popular packages

Open source program office (OSPO) managers

Foundation security engineers (OpenSSF, CNCF, Apache)

Platform engineering teams considering trust scoring

Security researchers studying supply-chain attack mitigation

A 4-week cohort-based course teaching the full graduated trust toolkit: trust graph construction and hop distance calculation, vouch policy authoring (scopes, expiration, revocation), friction level configuration (proof-of-context, observation windows, canary quarantine), integration with existing CI/CD (GitHub Actions, GitLab CI), advanced topics (Sybil resistance, EigenTrust weighting, compromise recovery).

A single cohort (10-15 participants) run live over 4 weeks

4 modules released weekly: Theory → Graph Construction → Policy Configuration → Production Deployment

Each module: pre-recorded video (30 min), live Q&A (60 min), hands-on exercise

Graduates receive a signed Seed capability certificate verifiable on the trust graph

Announce on HN when the Graduated Trust essay drops (this is the "take the next step")

Cross-post to OpenSSF, CNCF, and OSPO mailing lists

Offer free seats to maintainers of top-1000 npm packages

Seed community announcements

Conference talk: "We Built a Trust Graph for Open Source — Here's How" (lead gen)

Individual ($299): Full course, exercises, certificate, trust graph badge

Team ($999): Up to 5 seats, private cohort option, Slack support

Enterprise ($2,999): Private cohort, custom friction policies, integration support

OpenSSF Best Practices Badge: Self-serve checklist, no curriculum

Linux Foundation courses: Broad, not focused on trust/contribution gating

Sigstore workshops: Focus on signing, not on trustworthiness

Conference workshops (KubeCon, Open Source Summit): One-off, no follow-through

7/10 — The content exists (proposal + 5 open questions). The Strategist flagged this as the #1 content action. Risk: building the cohort format and exercises from scratch. Low cost to test (single cohort).

Create a single module: "Building Your First Trust Graph." Run it as a free lunch & learn for 5 maintainers. Record it. Ask: "Would you pay $299 for the full course?"

---

The Agents document defines a formal model: Agent Specifications, Instances, Sessions (sequential logs), Completions, and Triggers. But there is no standard library for agents to automatically persist their sessions as Seed documents. Every agent implements ad-hoc logging: the Gardener writes activity reports, the Product Scout updates the backlog, the Knowledge Manager tracks topics. None are machine-readable, queryable, or auditable. Teams running multiple agents have no unified audit trail.

Evidence: Agents — full formal model: Specification, Instance, Session, Completion, Trigger. The agents in this repository (Gardener, Product Scout, Content Strategist, Knowledge Manager) each implement ad-hoc logging. No standard format exists.

Developers building Seed-native agents (Seed team, external agent builders)

Teams running multiple autonomous agents needing audit trails

Site owners who want to see what agents did in their spaces

Researchers studying agent behavior patterns

An npm package (@shm/agent-logger) that provides a simple API: createSession(), logCompletion(), logToolCall(), logError(). Each call creates or updates a Seed document under /_logs/agent-name/session-id/ with structured content (timestamps, states, inputs, outputs, errors). Documents are content-addressed, signed, and queryable via Seed's existing search.

createSession(spec): DocumentRef — creates a new log document at /_logs/agent-name/session-timestamp

logStep(sessionRef, step): void — appends a completion block to the session document

logToolCall(sessionRef, tool, args, result): void — logs tool invocations as sub-blocks

A Seed query block (/_logs) that shows recent agent activity across all agents

Open-source npm package, documented in the Agents project

Package as part of the Seed Agent SDK (#9)

Blog post: "How to Know What Your Agents Are Doing — Agent Logging for Seed"

Reference implementation: instrument the Product Scout and Gardener agents themselves

Free: Open-source core library, local-only logs

Pro ($9/mo): Cross-agent dashboard, log search, retention policies

Enterprise ($49/mo): Centralized log collector, compliance export, audit trails

LangSmith/LangFuse: LLM observability for prompts/responses, not agent session lifecycle

AgentOps: Agent monitoring, but not Seed-native, no content-addressed storage

Custom code (status quo): Every agent reimplements logging, no standard format

Seed activity feed: Shows events, but not structured by session/completion

8/10 — The formal model already exists in the Agents document. The need is immediate (4+ agents operating today with no unified logging). Low implementation risk (thin wrapper around Seed document creation API). Every agent in the ecosystem benefits.

Instrument the Product Scout agent with @shm/agent-logger during this backlog update. Verify the log document appears at /_logs/product-scout/session-timestamp with structured blocks. Show to other agent operators.

---

Self-hosted AI servers expose two valid deployment modes behind a tailnet that are "easy to mix up": bind to 127.0.0.1 and publish through Tailscale Serve, or bind directly to the tailnet IP. Symptom: Web Access works in the browser but the native app, phone, or another tailnet device cannot connect. Debugging is fully manual — run /readyz, run /api/auth?token=..., inspect JEAN_HOST, restart Tailscale Serve. Every self-hoster of AI services (Jean and the growing stack of self-hosted agent servers) hits this class of state-confusion.

Evidence: Jean Web Access behind Tailscale — the field note itself documents the two modes, the exact failure symptom (browser works, native/phone fail), the manual checks, and concludes "the modes are easy to mix up". See especially the two-modes breakdown and the gotcha summary.

NEW EVIDENCE (2026-07-31 incremental): (1) The pattern already has first-party precedent inside Seed: the deploy guide's seed-deploy doctor command performs exactly this kind of config+health verification for self-hosted Seed sites (see the verify step). (2) Jean is not an isolated toy: the Seed team itself uses Jean as its Claude Code GUI in the 2026-03-19 Tech Sync, so the author's dogfooding audience is real and internal. (3) The post is now listed in the Short Posts index, giving the tool a distribution anchor.

FINAL-REVISION EVIDENCE (2026-07-31, trigger): The post's final revision adds an explicit "Is this a Jean issue?" diagnosis (two-modes breakdown, gotcha summary) concluding the modes "are easy to mix up" — the exact failure class jean-doctor automates. The Quick checks section (curl probes + expected /readyz body) is now a ready-made CLI test suite. Cross-account validation: the post's Related section links the Seed team's Tech Sync ("Jean for claude-code GUI") — Jean is internal Seed tooling, so the dogfooding audience is confirmed first-party.

NEW EVIDENCE (2026-08-11, Pass I): The Devin Ambassadors post notes Jean is gaining official Devin ACP integration — "Pronto podremos usar Devin ACP en Jean cuando esta PR se incluya!" (#S1SAujt_, coollabsio/jean PR #583) — so the self-hosted AI server stack now includes Devin as a first-class client, widening the audience for a tailnet connectivity doctor beyond Jean's own native clients.

Self-hosters running jean-server (native desktop app + phone + browser clients)

Homelab operators running Open WebUI, Ollama, LibreChat, or agent servers behind Tailscale

Cursor background-agent / self-hosted agent users (see How to Background Agents)

Anyone who hits the "works in the browser, fails everywhere else" mystery

The Seed team itself (Jean = Claude Code GUI in their tech sync)

jean-doctor — a single static-binary CLI (Go) that reads the server env, determines the bind mode, probes /readyz and /api/auth?token=... over both the Tailscale Serve URL and the direct tailnet IP, then outputs a pass/fail matrix plus the exact fix commands from the field note. Later generalizes to serve-doctor for any service behind tailscale serve.

doctor — read /etc/jean-server.env, run the two curl probes, print diagnosis (mode detected, which clients will work, what's broken)

fix — apply the recommended Serve config (restart jean-server, tailscale serve --bg http://127.0.0.1:3456)

url — print the canonical https://<machine>.<tailnet>.ts.net/?token=... URL for each client type

Open source on GitHub + Homebrew/npm tap

Publish the canonical page on a Seed site, cross-linked from the field note

r/selfhosted, HN, Tailscale community

Extend to generic tailnet services for reach beyond Jean users

Model the UX on seed-deploy doctor so Seed self-hosters recognize it instantly

Free: OSS core CLI

Pro ($5/mo): fleet checks — multiple tailnet services, config-drift alerts, uptime checks

Sponsorware/enterprise: private tailnet dashboards

Tailscale Serve docs / troubleshooting pages: generic, manual, not service-aware

Uptime Kuma / healthchecks.io: uptime only, no config-mode diagnosis

Ad-hoc curl scripts (status quo): exactly what the field note replaces

8/10 — First-party documented pain, trivially small build, growing niche (self-hosted AI). The Seed-team dogfooding angle and the seed-deploy doctor precedent raise confidence. Monetization is the open question; the CLI is a wedge into the self-hosting audience.

Port the field-note checks into a 100-line script, run it against the real jean-server, and ask 5 self-hosters in Tailscale/selfhosted communities whether they would install a binary for this.

---

Seed spaces accumulate documents over months but knowledge stays fragmented. No layer connects them.

Evidence: LLM Wiki project — 3,000-word spec.

NEW EVIDENCE (2026-08-04): The Osteoarthritis Research Hub is the LLM-Wiki pattern running in production on the network: hub doc (title) with "Last updated" stamps (#j1C_TDp_), reference tables (#uImgWa_W), methodology notes (#rmtdJSw3), and sub-hubs (guidelines, surgical advances) — both sub-docs updated 2026-08-04. The concept is validated in production; what's missing is the packaged, reusable template — see #33.

Seed users with 50+ accumulated documents

Teams using Seed for collaborative knowledge management

An LLM-powered background agent that maintains a persistent wiki at /_wiki/.

A TypeScript background process that reads documents, sends to LLM, creates wiki pages.

8/10 — 3,000-word spec ready.

---

Site owners on Seed want to sell access to private content with no way to do it.

Evidence: Paid Content project.

Seed site owners who want to monetize content

Independent creators publishing courses or premium research

Document-level restriction metadata + Read Capability grants + Stripe payment flow.

6/10 — High complexity but also high strategic value.

---

Seed sites lack a forum/discussion surface. Users paste Seed links into Discord.

Evidence: Forum Style Query Block. Seed Discord workflow is tiring.

NEW EVIDENCE (2026-08-07): The Query Block Table View Implementation Plan is the same Query-block extension surface — Table joins Card/List as a third view with per-block config, filters, and search (#vteFjfi3, #I90lSBZM). A forum view is the natural next sibling; the author's Projects page already dogfoods the Table view.

NEW EVIDENCE (2026-08-07, Pass H): The Experiment: Forum view — embedded in the Seed Hypermedia project page — is a working prototype: root conversations rendered large (like query-block children), each thread showing author, reply count, and all participant avatars (#UUPytiGL). Crucially it introduces the document type concept: "I believe the document 'type' is something authors should select, so a 'Forum' document type can enable this view or let users customize it" (#_BwM7vQm) — typed documents with special views is a broader wedge than a single forum block.

Seed site owners wanting community discussion on their site

Enhanced query block showing documents + latest comments, with inline Reply.

7/10 — Direct user pain, low build cost.

---

Each agent requires custom infrastructure, charters, and tool integration.

TypeScript SDK + CLI for building Seed-native agents.

7/10 — Clear internal need.

---

AI patches compile but contributors can't answer basic questions.

Service generating comprehension questions from PR diffs.

6/10 — LLM quality dependency.

---

Graduated trust is abstract — maintainers need to _see_ the graph.

Embeddable Seed document block rendering force-directed trust graphs.

7/10 — Straightforward, high narrative value.

---

8+ web remodeling documents with no structured learning path.

NEW EVIDENCE (2026-07-31): The Short Posts directory now has a formal Web & Hypermedia cluster (Remodeling the web + What I want for the commenting experience to be) — the cluster formalization makes a curriculum structure explicit.

Structured curriculum with completion badge.

6/10 — Low cost, indirect monetization.

---

Users report unusable export format. Lock-in perception blocks adoption.

CLI and desktop export to Markdown, ZIP, PDF, JSON-LD.

8/10 — Direct user pain, low risk.

---

4+ agents operating with no coordination — risk of conflicts and redundant work.

Document-level lease system + activity broadcast.

7/10 — Growing need.

---

State machines are "hard to establish" — debugging is painful without visual tooling.

Evidence: State machines are great, but hard to establish.

NEW EVIDENCE (2026-07-31): The State Machines Knowledge Map now links this opportunity from its Product Backlog section and its UI State Machines learning path — the cluster's flagship tooling gap. The Short Posts State Machines cluster (5 posts: agent visualization, adoption challenges, resizable panels, document machine, background agents) gives the inspector a concrete showcase target.

Interactive XState v5 inspector with real-time state display and time-travel.

6/10 — Niche but high-value.

---

"State machines to visualize agents" has no implementation for running agents.

NEW EVIDENCE (2026-07-31): The Short Posts directory now hosts a formal State Machines cluster (State machines to visualize the work of agents, Modeling resizable panels using State Machines, Notes about how the document machine should work) linked to the State Machines Knowledge Map — the cluster now has critical mass for a reference implementation.

Lightweight event format + real-time observability dashboard.

7/10 — Formal model exists, achievable in a week.

---

25 formal invariants defined for agents — no verification tool exists.

CLI checking agent traces against formal invariants.

8/10 — Invariants already peer-reviewed.

---

Step 2 of the vibe coding pipeline (expanding issues into codebase-aware specs) is the missing link. Devin case study proves end-to-end viability.

NEW EVIDENCE (2026-07-31): The community guide — download Linear bugs into Seed with Cursor + Python provides a working MCP template (mcp.json, linear-fetcher tool, assign/@Cursor delegation) that de-risks the fetch step. The AI & Agent Workflows cluster in Short Posts now formalizes the full arc: vision (Vibe code like a PRO) → reality (Devin case study) → practice (How to Background Agents).

NEW EVIDENCE (2026-08-11, Pass I): The Devin Ambassadors post upgrades the author from interested power-user to official ambassador (#-SUqTr1I) and names the two facts that make the pipeline mainstream: Devin is used daily in production on real projects (Seed front, GymClass, Jean) and the author's primary Devin usage is from mobile ("seguir programando desde el móvil, que es mi uso principal de Devin") — the async fetch→expand→spawn→PR loop (#18) is exactly what makes phone-driven development work. See also #41.

NEW EVIDENCE (2026-08-11, Pass J): The booking-system post documents the executed loop at full scale: "work the issue → open PR → wait for CI → test → ask me to merge → move to next. Six PRs, all merged, all building on each other correctly" (#mz8xVVg7) and the stability sweep that found 15 problems across 3 priority tiers and produced 14 PRs (#ekmOOcoM) — plus the PRD-driven parent-child feature build (6 issues, schema → booking delegation → parent UI → admin migration, #bCUm42Rj). This is the strongest public proof that the expand→execute→verify loop scales beyond toy projects.

CLI expanding Linear issues into structured task specifications.

9/10 — Devin validation, explicit gap.

---

No way to find images across a Seed site. User requested a "media view."

Query block showing all image blocks in a responsive grid.

7/10 — Direct user request.

---

"Creating a Server, running a new branch, and building takes 80% of my Vibe Coding time."

CLI handling entire dev environment bootstrap in one command.

8/10 — Pain quantified.

---

Developers can't inspect the protocol in real-time.

DevTools-like panel for blob stream, verification, and inspection.

7/10 — Direct developer request.

---

Users discover activity via Discord. "This is so tiring!"

NEW EVIDENCE (2026-08-04): Lobby thread on comment-edit notifications (thread root on the Lobby) — consensus that comment edits should NOT re-notify (X and GitHub don't notify twice for edited mentions), except when an edit adds a NEW mention. Eric: "it should be pretty easy to disable all notifs for comment edits. the only problem is if somebody edits a comment and adds a mention" (comment); Horacio: "this is not a problem anyone has solved. other systems does this pretty well" (comment). This gives #22 a concrete event-rule spec: create-vs-edit semantics for mentions.

In-app notification badge + email digest from activity feed.

8/10 — Direct pain, existing data.

---

"High risk for Users with local keys to lose them."

NEW EVIDENCE (2026-08-07): Iskak, while building the password flow, challenged the recovery-code design first-party: "I think the recovery code here is more confusing than it's helping... If we believe people can't remember their password, how can we think they'll remember a random string of characters or keep it securely in any way at all?" (comment). The UX decision (secret credential vs 6 recovery words vs generated passphrase) is open and being resolved inside the password identity story. Recovery UX is the make-or-break adoption step for self-custody.

Shamir Secret Sharing social recovery + Seed escrow.

7/10 — Documented product issue.

---

The Seed desktop connect flow always sets the first account after connecting, and the selected account is not carried in the connect payload — so the desktop app cannot know which account the user chose in the browser. Multi-account users are silently logged into the wrong identity; fixing the account picker requires backend changes.

Evidence: Identity Activity design story; Eric's comment — "the selected account is not set in the connect payload, so the desktop app can't know which one was chosen... would need backend changes"; Iskak's reply — communicate that the user is logging into all accounts, let them pick the active one when returning to desktop.

Seed users with multiple identities

Seed desktop app + remote vault users

The Seed core team (design/backend)

Include the selected account in the connect payload; after connecting, show an account picker in the desktop app; backend support for remote vault account selection.

Extend connect payload with the chosen account id

Desktop account picker on post-connect return

Clear copy: "You're signed in to all accounts — choose the active one"

Core Seed product fix — ships inside Seed, driven by the Identity Activity design story.

N/A (product improvement).

N/A (internal).

7/10 — Clearly documented bug/gap with a design story and two designer comments; requires backend scope, hence not a one-day fix.

Reproduce with two accounts: confirm the connect payload lacks the selected account; spec the backend change with the Identity Activity owners.

---

Self-hosted AI is growing fast but practical gotcha documentation is scarce — the Jean/Tailscale field note exists precisely because this pain is real and undocumented. Every self-hoster re-learns the same systemd/env/Tailscale Serve/auth patterns the hard way.

Evidence: Jean Web Access behind Tailscale (first practical self-hosting field note on the account); Short Posts AI & Agent Workflows cluster (Vibe code like a PRO, How to Background Agents, Devin Booking System) — the audience is already being built.

NEW EVIDENCE (2026-07-31 incremental): The Gardener's Emerging Topics now tracks Self-hosting / Personal Infrastructure as a new watch item (Jean Tailscale note + Deploy a Seed Site From Your Own Fork, plus cross-account homelab docs in Spanish from Algineer) — the demand cluster is real, not just one post. The Content Strategist independently cited the Jean post as a new opportunity seed ("new-opp-jean-why"), and the post now has 3 Related links (deploy guide, tech sync, dev-docs note) forming a self-hosting series funnel.

FINAL-REVISION EVIDENCE (2026-07-31, trigger): Cross-account validation is now explicit in the post's Related section (rel-jean-2, rel-jean-3): the Seed team's Tech Sync records "Jean for claude-code GUI" and the team's dev-docs note shows it admires Jean's docs — "we run this stack" is now linked, not implied. Strongest internal-validation signal for the playbook yet.

NEW EVIDENCE (2026-08-11, Pass I): The Devin Ambassadors post confirms Jean is part of the author's production stack with Devin ACP integration inbound (#S1SAujt_, PR #583) — the playbook's target stack (self-hosted AI servers + agent clients) is now explicitly Devin-connected, not just Cursor/LibreChat. The post also names marketing as an agent task ("Devin entra también... con algunas tareas de marketing" on GymClass), broadening the playbook's scope beyond code.

Self-hosting hobbyists and homelab operators

Indie devs running AI servers for personal/team use

People following the agent-workflow content who need deployable setups

A paid playbook + copy-paste config templates (systemd units, env files, Tailscale Serve presets, /readyz conventions, token auth patterns) for Jean and the wider self-hosted AI stack, updated as field notes accrue.

Gumroad/Leanpub ebook (80-120 pages) + GitHub template repo

3 config packs: Jean behind Tailscale, agent server + background agents, health-check/auth conventions

Via the field-notes series and the AI & Agent Workflows cluster

Newsletter + HN/r/selfhosted launch

Seed site as the canonical hub

$29 one-time ebook

$99 with updates + template repo access

Tailscale blog/docs: generic, not AI-stack focused

Self-hosting YouTubers/blogs (DB Tech, Techno Tim): video-first, not copy-paste playbooks

Open WebUI/LibreChat docs: per-project, not cross-stack

7/10 — Demand is now backed by a tracked emerging cluster and a second agent's independent signal, not just a single post; monetization still unproven but low cost to test.

Collect 3 more field notes; gauge waitlist signups from the Jean post traffic before writing.

---

State machines are "great, but hard to establish." The single worst pain named in the field notes: "some app logic is inside the state machine and some is outside. Is really hard to follow what is actually happening when there's this mix of state logic in the same app/feature." No tooling currently detects logic leaking outside the machine — teams discover it by debugging, not by linting.

Evidence: State machines are great, but hard to establish — the "worst scenario" quote (#XjOJlPXm) and the team-adoption frustration (#3ricRPJo). The State Machines Knowledge Map formalizes the cluster this fits into. Referenced in that post as "Split Logic Detector (Opportunity #24)" — the number is stale, the need is real.

Frontend teams adopting XState / state machines in production

Teams with mixed state logic (the author's own team is the first user)

Engineering leads reviewing PRs where transitions happen outside the machine

eslint-plugin-state-machine: static analysis rules that flag state logic living outside the machine — external mutations of machine state/context, conditional branching on machine state in components, ad-hoc transitions not declared in the machine, and duplicated guards/actions. Ships with --fix codemods for common leaks.

3 rules: (1) no external mutation of machine state, (2) no branching on state values outside the machine, (3) no ad-hoc transition dispatch

A small XState demo repo showcasing violations

README + install via npm

Open-source npm package + GitHub repo

Blog post "Your state machine is leaking" cross-linked from the State Machines cluster and Knowledge Map

r/reactjs, XState Discord

Free: OSS core

Pro ($19/mo): team policy config, CI report, codemod library

Sponsorware model to start

XState's built-in type safety: catches some, not leakage into components

Generic static analysis (SonarQube, CodeRabbit): not state-machine-aware

No dedicated state-machine linter exists (gap)

7/10 — First-party documented pain, tiny build, but niche audience and modest monetization. High strategic fit: makes the adoption story of #15/#16 credible.

Write one rule ("no external mutation of machine state"), run it against the Seed document machine codebase, show the leak report to 5 XState users. Would they install it in CI?

---

"The most hard thing to do with it is to convince your team that they are great" — the #1 blocker for state machines is organizational, not technical. Teams underuse state machines even when they agree they help.

Evidence: State machines are great, but hard to establish — #3ricRPJo (convincing the team is the hard part), #Xkwq8A8z (invites the debate). Why aren't we using state machines more in our complex application? — same problem from the product-team angle. Referenced in the post as "State Machine Adoption Kit (Opportunity #25)" — stale number, real need.

Senior/lead frontend devs who want to introduce state machines

Engineering managers deciding on architecture standards

Consultants/educators teaching state-driven UI

A packaged "State Machine Adoption Kit": audience briefs (engineers, PMs, managers), before/after metrics templates, counter-argument answers, migration plan template, and a 20-slide brown-bag deck. Turns the cluster's arguments into reusable persuasion assets.

Landing page with 3 one-page briefs + slide deck (PDF), free for email

Migration checklist template

Case-study template (like Modeling resizable panels and document machine notes)

Via the State Machines Knowledge Map and Short Posts cluster

HN/blog post "Why your team doesn't use state machines"

XState community channels

Free briefs (lead magnet)

Paid workshop ($199/team, live)

Paid migration audit ($499)

XState docs: free but not persuasion-focused

Blog posts: scattered, no packaged kit

No structured adoption playbook exists (gap)

6/10 — Real documented pain, very low build cost, but willingness to pay uncertain. Strongest when bundled with #26/#28.

Publish the "convince your engineer" one-pager; measure signups and asks. Offer the workshop to one team; observe conversion.

---

The Seed document machine (loaded → editing → publishing → rebase) is real, production code — XState v5, ~465 lines — but it lives inside Seed's codebase. Collaborative editors and publishing apps outside Seed face the identical lifecycle complexity (version history, draft conflicts, rebase guards, publish guards) and have no reusable reference implementation. The notes post is literally "some unstructured ideas I shared with my coding agent" — a spec in search of a package.

Evidence: Notes about how the document machine should work — the state list (#MUYKK7u5: enter doc → fetch → loaded → editing → publishing → version history → rebase guards, discard-draft rules, no-rebase-while-saving). Project Plan — No more Edit mode — XState v5 implementation, 465 lines. Publish Guard and Draft Publishing Chain — the guards already built. Document Web Editing — a second implementation flavor. Referenced in the notes post as "Opportunity 14: Document Machine OSS Package" — stale number, real gap.

NEW EVIDENCE (2026-08-07): The Chief of Staff's Briefing #8 names the Document Machine OSS Package the top product opportunity — "the highest-confidence build in the Product Backlog" (#Nm-sjK-D) — and flags the convergence: Research Roadmap #11 + Content Roadmap #22 + Product #28 all point at the same 465-line XState v5 artifact (#ZtEAqvm6). Horacio's 8/04 comment on the Design page — "a lot of bad feedback about Notion in this thread" (comment) — is the competitive signal: the Document Machine is Seed's architectural answer to collaborative-editing pain.

NEW EVIDENCE (2026-08-07, Pass H): Improving Editor Block Rendering — embedded in the project page — shows the editor's rendering layer getting the same invariant-driven treatment as its state layer: five visual defects (uneven vertical rhythm, shrinking text at depth, misaligned list markers, flat heading spacing, drifting drag handle) unified under one content-start alignment principle (#iHLUUVrM), shipped in PR #399. "Consistent rendering is a form of trust" (#xj9Jzlll) — the same trust thesis as the document machine. The OSS package's story includes not just the state machine but the rendering invariants that make an editor feel trustworthy.

Seed core team (immediate consumer, stops re-implementing)

Teams building collaborative/versioned document editors

XState learners wanting a real-world case study

Extract the document machine into an open-source npm package @shm/document-machine (XState v5): typed states/events, persistence middleware, publish/rebase guards, and a demo editor showing loaded → editing → publishing → rebase. Document every state from the notes post.

Extract the machine + typed events + minimal React demo

README documenting all states and transitions

Publish to npm, wire into Seed web editing

npm + GitHub, linked from Knowledge Map and notes doc

Blog post "The document machine: a state machine for collaborative editing"

XState Discord + r/reactjs

Free: OSS core

Pro ($29/mo): hosted observability dashboard for the machine

Consulting: custom machine extraction

ProseMirror/Tiptap: editor internals, not lifecycle orchestration

XState examples: snippets, not packaged libraries

No packaged document-lifecycle machine exists (gap)

8/10 — Implementation exists and is in production; extraction is mechanical; huge ecosystem payoff (reference implementation for the cluster's flagship example).

Extract the machine into a standalone repo with a demo editor; run it against the Seed web-editing codebase; ask 3 Seed contributors to dogfood. If extraction takes < 1 week, ship it.

---

Indie developers who build self-hosted, local-first apps hit the same distribution gauntlet on every project: how do I sign my desktop app so Windows trusts it, how do I ship updates in the field, how do I let people self-host my server, and how do I make the service reachable from phones and other devices? Each step is a rabbit hole of vendor docs and forum threads, and the pieces are never connected into one lifecycle.

Evidence: The author's own writing already forms the missing lifecycle, now cross-linked from the Related reading section of the Jean post: Deploy a Seed Site From Your Own Fork (self-hosting + rollback), Codesign your Electron Application for Windows (distribution trust), Velopack: Delta Updates for Electron Apps (in-field updates), Jean Web Access behind Tailscale (secure tailnet access). That is a complete build → sign → update → deploy → access series, written from real experience.

FINAL-REVISION CORRECTION (2026-07-31, trigger): The Related reading link above previously cited block #At6BPILe; in the post's final revision the Related heading block is rel-jean (see Related section), which links Deploy a Seed Site From Your Own Fork (rel-jean-1), the Tech Sync, and the dev-docs note. The series funnel is now explicit in the post itself.

Indie hackers and local-first startups shipping desktop + server combos

Self-hosters who want their apps installable by non-technical users

Developers following the Electron/Velopack/deploy how-tos

A paid playbook + template repo covering the full self-hosted distribution lifecycle: codesign CI, Velopack update pipeline, fork-based Docker deploys with rollback tags, and Tailscale Serve access. Each chapter is anchored in the published how-tos; buyers get the glue that connects them.

A "Ship Local-First" landing page on the Seed site collecting the 4 how-tos as a series

GitHub template repo: Electron codesign workflow + Velopack release + docker-compose with sha-tag rollback + tailscale serve preset

5-chapter ebook (~60 pages) walking the lifecycle end-to-end

The Related reading series itself is the funnel: each new how-to links the others

HN/r/electron/r/selfhosted launch; newsletter drip of each chapter

Bundled with #25 Self-Hosted AI Stack Playbook for the AI audience

$19 ebook

$59 ebook + template repo + updates

$99 bundle with #25 AI Stack Playbook

Electron/Velopack/Tailscale docs: per-tool, never the connected lifecycle

Electron Forge tutorials: build-focused, no self-hosted update/deploy story

Self-hosting YouTubers: video-first, not copy-paste playbooks

7/10 — The content moat is already built (4 linked how-tos from real shipping experience); the gap is packaging and distribution. Asymmetric upside: the series strengthens the author's expertise brand and cross-promotes Seed self-hosting.

Add a landing page linking the 4 how-tos as a series; collect waitlist emails from the Jean post + Codesign/Velopack traffic for one week. If signups clear 50, write the ebook.

---

A mini-cluster formed around the "Pause Subscription" UX pattern: Great product features in the wild: Canva Pause Subscription ↔ Feature request: Pause Subscription, bidirectionally linked across accounts. The Canva post names the core user need: "My daughter uses canva a lot for school and we wanted to pause the subscription for summer" — seasonal users don't want to cancel, they want to pause. The author explicitly wants Seed users to feel this understood: "This is something I would love to have and make our users feel when they use Seed! ❤️". No reusable pattern guide exists for pause-subscription flows.

Restoration note (2026-07-31): This opportunity was originally logged as Opportunity 37 (ranked #16 on 2026-07-13, with implementation plan, Stripe integration notes, and churn-reduction analysis) but was dropped during the 2026-07-31 renumbering merge. The Canva post's See Also section still referenced it, exposing the gap. Restored with the same evidence, renumbered #30. The Content Strategist's Content Roadmap lists Canva Pause Subscription as a content source, signaling this UX pattern as evergreen content.

SaaS product managers designing subscription flows

UX designers building billing/pause experiences

Seed product team (future paid plans / billing layer)

Seasonal-use subscribers (students, families, hobbyists) — the Canva post's own persona

Pattern guide: (1) analyze Canva's pause UX, (2) state machine for the pause flow (Active → Paused → Reactivating → Active), (3) reusable XState machine template, (4) React components, (5) business logic discussion: Stripe pause-collection integration, churn-reduction analysis, when to offer pause vs cancel.

Analysis doc + XState machine template + React demo. 3-5 day build.

Blog post: "Why Canva's pause subscription UX matters"

Pattern guide on the UI with State Machines hub

Cross-links from both existing docs (Canva post + feature request note)

Referenced in the Content Strategist's roadmap as evergreen content

Free OSS pattern (guide + machine template)

Consulting: custom pause subscription implementation ($3k–$8k)

Subscription management SaaS (Recurly, Stripe): APIs, not UX patterns

SaaS blogs: scattered pause-vs-cancel advice, no implementation artifacts

Differentiation: first UX-pattern-focused guide for pause subscription with a state machine implementation

6/10 — Small cluster (2 docs), niche topic, but the Canva pattern is widely praised; strengthens Seed's future billing-layer UX story (#7 Paid Content Engine).

Write a 500-word teardown of Canva's pause flow (what it costs Canva vs cancel-and-resubscribe, what the user gains); show to 5 SaaS PMs / subscription UX designers; measure how many would reuse a pause-flow XState template.

V0 (3-5 days): analysis doc + machine + demo; blog post

V1 (week 2): React components + Stripe pause-collection integration notes

V2 (month 1): fold into Seed billing/paid-content discussions (#7 Paid Content Engine)

---

Every Seed site ships troubleshooting knowledge as unstructured prose, and the Seed team itself says it wants to copy Jean's docs patterns. The Jean post is the pattern made concrete — symptom → recommended setup → why-the-obvious-fix-fails → quick checks → "is this a bug?" diagnosis — but nothing in Seed encodes that structure. Each doc re-invents it, and quick-check commands can't be verified or re-run by readers.

Evidence: This developer docs are amazing and we should copy this patterns — "I hope we can move towards something like this in Seed." The Jean Web Access behind Tailscale post is the template in the wild — see the symptom opener, recommended setup, why the direct IP may stop working, quick checks, and the diagnosis. The Tech Sync confirms Jean is Seed's Claude Code GUI — first-party demand for the pattern. The Content Strategist independently flagged this as #15 (Jean-Style Troubleshooting Template) — two agents, same gap.

Seed site owners and the Seed docs site (immediate internal consumer)

Self-hosters documenting tailnet/AI deployments

Devtools/docs engineers who want Jean-quality troubleshooting docs

A Seed "Troubleshooting" block template that encodes the Jean structure: symptom, recommended setup, failure mechanism, quick checks (executable code blocks), and diagnosis. Ships as a block schema + template gallery entry + one reference implementation (re-document Jean with it).

Block schema for the 5-part structure with typed fields

Reference implementation: convert the Jean post into the template on a Seed docs page

"Insert troubleshooting doc" flow in the editor

Seed docs + template gallery; cross-link from the Jean post's Related section and the Short Posts self-hosting cluster

HN/blog post "The anatomy of a troubleshooting doc" (pairs with the Strategist's content item #18)

Bundles with #5 (jean-doctor renders into the quick-checks block) and #25/#29 (playbook templates)

Free: the block itself (OSS, part of Seed)

Pro ($9/mo): template library, quick-check auto-run (renders curl results live), docs analytics

GitHub/StackOverflow answer templates: unstructured, not content-addressed, not executable

ReadMe.io/developer docs platforms: page-level structures, no block-level reusable schema

No block-level troubleshooting template exists in Seed (gap)

7/10 — Internal demand documented verbatim ("we should copy this patterns"); the pattern is proven in production (Jean docs + this post); adoption is the open question. Strengthens Seed docs quality and feeds #5 (jean-doctor) and #25/#29 (self-hosting playbooks).

Build the block in one docs page using the Jean post as content; ask 3 Seed team members (including the author of the dev-docs note) to dogfood. If they replace their next troubleshooting section with the template, ship it to the gallery.

---

The author explicitly wants to start newsletters — "I got like 4 topics I want to start writing about and I will use @Seed Hypermedia to write about them!" — but Seed has no email distribution layer: no subscribe block, no digest, no send pipeline. Writers must copy Seed content into generic newsletter tools by hand, breaking the content-addressed source of truth (versions, comments, embeds, signed authorship all get lost in the copy). The newsletter-ideas post is the intent; the steady stream of short posts (Pure CSS Scroll Shadows — "4 lines of background", state-machine notes) and republished evergreen writings (week organization, morale essay) is the supply.

Evidence: 10 (Profitable) Newsletter Business Ideas To Start In 2025 by Greg Isenberg — "I got like 4 topics I want to start writing about and I will use @Seed Hypermedia to write about them!" (#KCX62BwU); Pure CSS Scroll Shadows — dev-tip content stream (#l2yD7gZy); the Short Posts index now formalizes content clusters (State Machines, AI & Agent Workflows, Web & Hypermedia) that map directly to newsletter topics. Ties to #7 Paid Content Engine (paid newsletters) and #22 (digest notifications).

NEW EVIDENCE (2026-08-11, Pass I): The Devin Ambassadors post names the single biggest content gap the newsletter engine should target first: "Todos los contenidos de dev tools que me encuentro están en inglés, y el español es un hueco enorme" (#jqN1KpTs) — the author is committing to a Spanish-language dev-tools content stream (see #40), which needs exactly the Seed→email pipeline #32 builds.

The author (4 newsletter topics, first user)

Seed site owners publishing regularly who want email reach

Indie writers who want signed, content-addressed posts + email distribution

Course/paid-content creators on Seed (bundle with #7)

A Seed-native newsletter pipeline: (1) a "Subscribe" block on Seed sites that stores subscribers as contacts; (2) @shm/newsletter CLI/script that takes a document path and renders blocks → clean HTML email and sends via an ESP API (Buttondown/Resend); (3) a scheduled digest of new documents in a path; (4) paid tiers later via #7 Paid Content Engine. Source of truth stays in Seed; the email is a render.

"Subscribe" block (contact capture + seed phrase signing)

seed-newsletter send <doc-path> using Buttondown API

Weekly digest of new docs in a folder

The author's own newsletters as the reference implementation

Blog post "Write once in Seed, publish everywhere"

Cross-link from the newsletter-ideas post and the Short Posts clusters

HN / r/newsletters launch

Free: OSS core (CLI + block)

Pro ($9/mo): hosted digest + subscriber analytics

Bundle: paid newsletters via #7 later

Buttondown / beehiiv / Ghost / Substack: excellent email tools, but none read content-addressed docs or preserve signed authorship and block-level comments

RSS-to-email services (Kill the Newsletter, Fetchrss): generic, no Seed-native compose

Differentiation: Seed as source of truth; email as a render; comments/versions/embeds preserved

6/10 — First-party stated intent (4 topics) + proven content stream; low build cost; but email infra is outside Seed's core and ESP competition is fierce. Monetization unproven — treat as a distribution wedge for the author's own writing and for Seed adoption.

Pick one topic; hand-write 3 issues as Seed docs and send them via Buttondown API manually; measure authoring-to-send time and subscriber growth. If the manual loop is painful, build the CLI.

---

Keeping a domain knowledge hub current (guidelines, trials, releases, security advisories) is manual drudge work — and it stops the moment attention lapses. The network already runs a production example: the Osteoarthritis Research Hub (hub doc + per-topic sub-docs, "Last updated" stamps, reference tables, methodology notes, medical disclaimer) with two sub-docs updated the same day (2026-08-04: guidelines, surgical advances). Nothing packages that pattern into a reusable Seed template + monitoring agent, so every hub is rebuilt from scratch.

Evidence: Osteoarthritis Research Hub — hub title, last-updated stamp, publications summary, methodology notes; guidelines doc — stamp, summary table; surgical advances — stamp, summary table. Same family as #6 LLM Wiki — #33 is the packaged, vertical, sellable template.

MedResearch (existing operator — first user)

Researchers/analysts who must track a domain continuously

Clinicians and guideline consumers

Domain newsletter writers (feeds #32) and OSS maintainers tracking releases/security

A "Research Hub" Seed template (hub doc + per-topic docs + last-updated stamp + summary tables + methodology + disclaimer) plus an evidence-monitoring agent charter that watches sources (PubMed RSS, journal TOCs, society guideline pages, release feeds) and appends citable updates as new versions. Content-addressing gives verifiable, versioned updates — every claim links to its source document.

Template repo mirroring the OA hub structure

One agent script watching a single RSS feed, appending a reference row + bumping the stamp

Demo: fork the OA hub as the canonical example

Seed template gallery + docs

Case study "How a living research hub runs on Seed" with MedResearch as flagship

r/medicine, r/datascience, research-tooling communities

Cross-post with #32 (domain newsletters need the same monitoring)

Free: template

$29/mo: hosted monitoring agent per hub

Enterprise ($199+/mo): white-label evidence monitoring (pharma/medtech)

UpToDate / DynaMed: manual, institutional pricing, not versioned/verifiable

Litmaps / Scite / Semantic Scholar alerts: discovery tools, not maintained hubs

Generic RSS-to-doc bots: no structure, no citations, no tables

Differentiation: content-addressed, versioned, low-cost, Seed-native

7/10 — The pattern is running in production on the network today (two sub-doc updates on 2026-08-04); the gap is packaging into a template + agent. Willingness-to-pay is unproven but cheap to test. Strengthens Seed's positioning as a knowledge-platform and showcases #6 LLM Wiki in the wild.

Fork the OA hub as a template; run a week of automated updates on a second domain (e.g., GLP-1 agonists or radiology); ask MedResearch and 3 domain experts whether they'd pay for a hosted version.

---

Seed documents already carry open-ended metadata attributes, but query blocks are "closer to 'show me the children of this document' than a real database view" (Query Blocks and Databases). Hub pages degrade into flat link lists or Card walls as content grows, and readers can't filter/sort/search collections by attribute (status, tags, dates). The team has been converging on this for months — Database View, Query Blocks and Databases, Tables and Databases — and on 2026-08-07 the first concrete implementation plan landed and was dogfooded the same day on the author's own /projects page.

Evidence: Query Block Table View Implementation Plan — "Add a read-only Table view to the existing Query block so documents can render query results as configurable data tables" (#jzKAQFR); Option 1 selected — extend the existing Query block and payload (#gxtggcB_); per-block column config persists (#aPVqfnXN); TanStack Table already installed and used by All Documents (#I90lSBZM). The Projects page now renders a Table-style Query block (updated 2026-08-07T16:22:24Z). Prior art: Database View ("A Query block View as a List", #IJrTBLz-), Query Blocks and Databases (attribute types, backend query execution, "like Obsidian Bases", #8o_S9t21), Tables and Databases ("we will also want Tables to be a query block view", #mDxud_-8).

NEW EVIDENCE (2026-08-07, Pass H): The All Documents - directory idea (embedded in the project page) is now SHIPPED: the June 3–9 weekly review records the All Documents site view in PR #728 — "a searchable, sortable, expandable document tree across desktop and web" (#ye7oQP0f) — and the demo mockup's features (filter by name, sort, move, rename, delete, bulk actions; #egre1TpP) are the direct roadmap for the directory surface. Query block author filters also shipped (PR #731, #ZXKP1vgM). #34's execution evidence keeps compounding.

NEW EVIDENCE (2026-08-07, Pass H2 — concurrent /projects evening re-update): The Projects page now pairs the Table firehose with curated Card embeds (Seed Hypermedia card) — the hybrid index (live query + curated highlights) is the reference pattern for #34's gallery templates and closes the "public page surfaces none of the author's own work" gap.

Seed site owners building directories/hubs (Joel Serrano's ~45-link home, Tech flat list, Design hub)

Knowledge managers running research hubs (OA hub → #33)

Teams evaluating Seed against Notion/Airtable/Obsidian Bases

The Seed core team (immediate consumer)

When the in-flight Table view ships (Option 1), package the pattern as Structured Collections: a template gallery of database-style pages (Directory, Research Hub, Project Index), a saved-views path (per the plan's Option 2/3: reusable databases, schemas, relations, formulas, aggregations, inline editing), and a backend attribute-query API (per Query Blocks and Databases). Seed documents become queryable rows; content stays content-addressed and versioned.

Table view per the implementation plan (read-only, per-block column config, client-side filter/search)

Three gallery templates built from reference implementations: the /projects page, the OA Research Hub, All Documents

One "insert structured collection" flow in the editor

Case study: "My /projects page runs on a Table query block"

Seed template gallery + docs

Case-study posts (pairs with #33 Living Research Hub + #6 LLM Wiki + #8 Forum View)

The Notion-criticism thread (8/04) → "databases without the lock-in" narrative

HN / r/Notion comparison content

Free: core Table view (Seed feature)

Pro ($9/mo): saved views + template gallery + advanced filters

Enterprise ($199/mo): backend attribute-query API, white-label collections (with #33)

Notion databases, Airtable, Obsidian Bases, Tana, TiddlyWiki: centralized or local-only, not content-addressed

Differentiation: versioned, signed, queryable across spaces with citations/comments; the "read-time lens" philosophy from Query Blocks and Databases

8/10 — Implementation plan exists and is in flight (created 08-07), dogfooded in production the same day on /projects; long-standing cluster of design docs (Database View, Query Blocks and Databases, Tables and Databases); execution and adoption are the risks.

Turn the /projects page into a reusable "Project Index" template; ask 3 Seed users with flat hub pages to adopt it; measure whether Table view replaces Card/List for hubs.

---

The npm package @seed-hypermedia/client "currently looks like an internal package that happens to be public, not like a product developers are being invited to adopt": no README, no five-minute success path, unclear what it connects to (browser? daemon? read-only? write?), 0.0.x versioning, no external reference applications, internal mental model leaking (hm-types imports). The metric that matters: "How many external developers reach their first successful document read or write without speaking to the Seed team?" — currently effectively zero.

Evidence: Why are developers not using www.npmjs.com/package/@seed-hypermedia to build software? — no README (#O-_q0UEc), no five-minute success (#uojTjT9A), wedge: "A versioned, user-owned knowledge backend for agents and collaborative applications" (#rkLNXzWi), metric (#W41TAC99), three reference apps: Seed Reader, Research Agent, Knowledge Board (#tiucBdTI). HM Writes: TS SDK, CLI, Agent Skills — "TS developers currently have no way to programmatically interface with SHM servers" (#BxlUay5n), agents must write documents (#H_hwUNle), CLI cannot publish (#6bTZnS64), plan: standalone NPM package + CLI upgrades + CreateBlobs HTTPS endpoint + skills repo (#dkUjsY36). Developers want to build software, not create content.

TS/JS developers building collaborative knowledge apps, local-first apps, agent backends

Seed's own web frontend team (SDK used inside CLI + web)

Agent builders needing write access (Agent Skills)

Decentralized/CMS-curious devs searching "decentralized CMS TS", "local-first knowledge graph SDK", "versioned document API"

Repackage as a deliberate developer product: small public API (createClient, documents.get/create/update/query, accounts, comments, queries, subscriptions), internals moved to @seed-hypermedia/protocol, /types, /editor, /client/internal; README with the wedge; three reference apps (Seed Reader in Next.js, Research Agent monitoring a space, Knowledge Board query→cards); stability promise at 0.1.x.

README with install + executable example (documents.get → documents.create)

One deployed reference app (Seed Reader) on the network

Versioning bump + API surface freeze on the small domain API

npm + GitHub; docs site (team already wants to copy the dev-docs pattern)

Blog posts in problem spaces: decentralized CMS TS, local-first knowledge graph SDK, versioned document API, knowledge base for AI agents

Reference apps as living examples; HN launch

Feeds #9 Seed Agent SDK and the HM Writes roadmap

Free: OSS core client

Pro ($29/mo): hosted endpoint / managed daemon + support

Enterprise: white-label managed nodes

Notion API: hosted, no versioning/citation semantics

Git-based CMS: no live query model

Firebase / IPFS / OrbitDB: no document model with links, comments, and queries

Differentiation: content-addressed, versioned, user-owned docs + permanent links/citations + agent-ready writes

8/10 — The gap is documented in detail by first-party analysis; the HM Writes project plans the implementation; success is measurable (first-read-without-support). Effort is packaging + docs, not new protocol work.

Write the README + five-minute example; hand it to 5 developers (not Seed users); measure time-to-first-successful-read and whether they reach write without asking questions. Target: < 10 minutes.

---

The same two hub-page anti-patterns replicate across accounts: oversized hub pages with inline Content embeds (Design hub, Stories, Joel Serrano articulos) and flat, undifferentiated link lists (Tech document, Joel Serrano home ~45 links). The Librarian's 2026-08-06 sweep confirmed zero movement on these for 8 weeks and found the pattern on a third account. Readers can't distinguish content types without clicking. There is no template-level guidance in Seed for when to use Card embeds vs Content embeds vs links, or how to group links into thematic sections.

Evidence: Today's Briefing — sweep findings (#EibYf3nA), Theme 3: "Anti-Patterns Are Replicating Across Accounts... argues for a template-level solution rather than per-account fixes: a 'Hub Page Best Practices' guide" (#CCzUuKMI, #PAMWMrM2), 21-item unfinished-work table (#5iMfsyOd). Joel Serrano home and Artículos. Tech document. Design.

NEW EVIDENCE (2026-08-07, Pass H): The Embeds Design Proposal — embedded in the project page — documents exactly why naive embeds degrade hubs: the current green-bar treatment "looks like a blockquote," is "not informative about the source," and "disrupts reading flow" (#IRGeXoLf). Its Option A (attribution header, #Ns8OVHVk) is the block-level remedy the Hub Page template should standardize on — embeds with source attribution instead of anonymous borders.

NEW EVIDENCE (2026-08-07, Pass H2 — concurrent /projects evening re-update): The Projects page hybrid index is the counter-example to the anti-patterns: curated Card embeds + one Table query instead of dozens of inline Content embeds; it also shows hub pages curating sites, not just documents (UI with State Machines, Fullstack Electron) — a curation role the Hub template should cover.

Seed site owners and knowledge managers

Agent-operated accounts (Librarian, Gardener) that audit hubs

Docs writers and onboarding guides

The Seed team itself (its own hubs are flagged)

A "Hub Page Best Practices" guide + reusable Hub Page template: decision rules (Card embed vs Content embed vs link; thematic grouping; query-block-driven indexes — feeds #34), checkable criteria (no >N inline embeds, no >M undifferentiated links), and an agent-auditable checklist the Librarian can run. Ships as a docs page + template gallery entry + one reference conversion.

One docs page "Hub Page Best Practices"

One Hub Page template document in the gallery

Reference conversion of one flagged account (Joel Serrano home or Tech)

Librarian checklist updated to check the new criteria

Seed docs + template gallery

Librarian / Chief of Staff adopt the checklist (agents dogfood, measurable)

Blog post "The anatomy of a hub page"

Bundles with #34 (query-driven indexes) and #31 (troubleshooting block template)

Free: guide + template (Seed docs)

$299/site: hub audit + conversion service (via the maintenance-blitz pattern)

Notion templates, Obsidian Publish guides, Hugo docs themes: page-level advice, not Seed-native blocks

Differentiation: block-level decision rules + query-driven structure + agent-auditable

7/10 — Anti-pattern documented across 3 accounts by an independent agent sweep; fix is low-cost; the agent governance loop makes adoption measurable (next Librarian sweep).

Convert one flagged account into the template; verify the next Librarian sweep marks it resolved; ask the account owner if they'd pay for conversion of the rest.

---

Electron teams quietly accumulate IPC abstraction tax: the developer picks a type-safe RPC layer (tRPC/electron-trpc) for DX, and users pay the runtime cost on every launch. Seed's own desktop app measured the damage: 109 tRPC procedures across 26 modules totaling 3,615 lines (≈40% of the desktop codebase), 42 of them trivial getters/setters, 28KB of extra startup JS, a 133% complexity tax over plain IPC, eager loading of every router, and a startup sequence that blocks window creation on daemon readiness (up to 10s). The judgment call — "which calls deserve the heavy machinery and which are 'shotgun to kill a fly'" — is currently made by hand, if at all. There is no tool that quantifies IPC over-abstraction before it compounds.

Evidence: The Case Against electron-trpc: When Type Safety Becomes a Performance Tax — embedded in the Seed Hypermedia project page — is a complete, quantified case: the seven-layer vs three-layer stack (#P1K-EUgc), the 109/42 procedure census (#dtRXYnh0), the 28KB bundle and per-call SuperJSON serialization (#uHzo1lTK), the 2s vs 5s startup estimate (#ZU4ZlRQz), and the explicit playbook: migrate trivial procedures to contextBridge IPC, lazy-load remaining routers, decouple daemon readiness from window visibility (#w6AEuv8L, #IcUzDYbF, #wpeUixFL). The author's own rule of thumb is the product spec: "measure before migrating" (#6VqWIsKJ).

Electron/Tauri desktop app teams using tRPC-style IPC bridges

The Seed team itself (immediate consumer — the migration is in flight)

Local-first / desktop tooling maintainers optimizing startup time

Engineering leads reviewing "one more RPC library" PRs

ipc-audit — a CLI that statically analyzes an Electron codebase's IPC layer and emits a quantified over-abstraction report: procedure census (total / trivial / complex), per-call serialization overhead estimate, eagerly-loaded router bundle weight, and a prioritized migration list (the "42 getters" class first) following the electron-trpc teardown's own playbook. Includes a baseline measure command (startup time, time-to-first-render, bundle size) so teams can prove impact. No framework replacement — it is a diagnostic that tells teams where the shotgun is being used on flies.

audit — walk the router tree, classify procedures (getter/setter vs complex), print the trivial-first migration list with per-call overhead estimates

measure — baseline startup / TFFR / bundle-parse timings (the doc's own "don't guess" rule)

README + example report generated from Seed's own codebase (dogfood)

OSS npm/Go binary on GitHub + Homebrew tap

Blog post "Your Electron app is paying a 133% IPC tax" built from the tech talk

HN / r/electron / Electron Forge community; XState/desktop perf circles

The Seed desktop migration as the reference case study (numbers before/after)

Free: OSS core CLI

Pro ($19/mo): CI report, trend tracking, multi-repo dashboards

Consulting: IPC migration audit + execution ($3k–$8k, follows the doc's playbook)

tRPC/electron-trpc docs: advice, not measurement

Chrome DevTools / Electron perf tools: runtime profiling, not architectural over-abstraction detection

Bundle analyzers (webpack-bundle-analyzer): bundle weight, not per-call overhead or procedure classification

No dedicated IPC-bloat auditor exists (gap)

8/10 — The pain is quantified first-party with a complete migration playbook; the build is a thin analyzer over data the team already measured; dogfooding target is the author's own repo. Monetization modest but real (CI tier + consulting).

Run the classification algorithm against Seed's desktop codebase; reproduce the 42-trivial-procedures list as a generated report; show it to 5 Electron maintainers — "would you run this in CI to stop IPC bloat from compounding?"

---

Hypermedia links documents, but meaning lives in passages. Seed's own roadmap says documents "should not just link to other documents; they should be able to point at exact pieces of meaning inside them" (June 3–9 weekly review). Today, citing a specific claim forces writers to quote-and-paste or link a whole page; there is no durable, versioned, addressable unit below the document. For the Graduated Trust story (#1), verification requires citing the exact passage — "this claim lives here, in this version" — and the web has no such primitive for P2P content.

Evidence: The June 3–9 weekly review records the direction and the implementation: ranged comment quotes (previous week) plus inbound citation fragment highlights in PR #726 — overlapping highlight handling, hover states, popover for multiple citations, and navigation disabled while editing because "I clicked text to edit it and got navigated away" is a UX betrayal (#Kyoqkx82). The seed-hypermedia project page documents fragment-level knowledge as a core direction. Pairs with #1 (verifiable citations for trust scoring) and #2 (comments that reference exact passages).

Seed writers and researchers citing sources precisely

OSS maintainers reviewing contributions (with #1 — cite the exact claim being vouched)

Knowledge-base and research-hub operators (with #33 — every claim links to its source passage)

Commenters who want block/passage-level discussion (with #2)

Surface Seed's ranged-citation primitives as a packaged capability: (1) stable fragment references (doc#start-end ranges) that survive document versioning; (2) inbound citation highlight rendering with overlap handling and hover attribution; (3) a "cited-by" view on a passage; (4) an embeddable citation widget for non-Seed pages (feeds #2). Content-addressed passages make "cite the passage, not the page" real.

Ship PR #726's inbound highlight + ranged quote as a documented feature (close the open PR)

A reference page: one document with several cited passages, showing highlights, hover attribution, and a cited-by list

A short public spec: fragment URI scheme + versioning semantics

Seed docs + blog post "Cite the passage, not the page"

Cross-link from the state machine / document machine cluster (the editor is where fragments render)

Feeds #1 Graduated Trust (verifiable citations) and #2 Commenting Widget (passage-level comments)

HN / r/P2P_HTML / research-tooling communities

Free: core feature (Seed) + OSS spec

Pro ($9/mo): hosted cited-by analytics, fragment link shortening

Enterprise: citation graph for research/legal/regulatory use (with #33)

Hypothesis / web annotations: overlay annotations, not content-addressed document versions

Citation managers (Zotero): bibliographic, not passage-level linking into live documents

Quote tweets / social quoting: unstructured, no durable address

Differentiation: versioned, content-addressed, native to the document model, bidirectional

7/10 — Direction is first-party stated and implementation is already started (PR #726 open); the remaining work is packaging, shipping, and a spec. High strategic fit: it is the substrate for #1's verification story and #2's passage-level comments.

Take one Seed document with several inbound citations; render the highlight + hover + cited-by surface; show 3 writers and 3 researchers — "does citing an exact passage change how you reference sources?"

---

The author is Seed's Electron desktop owner with deep, documented Electron pain — the electron-trpc performance-tax essay, the Windows codesign nightmare, the Velopack delta-update writeup — but the Electron knowledge is spread across separate docs with no consolidated home. On 2026-08-07 a bare account named "Fullstack Electron" appeared on the author's Projects index: a scaffold with intent and no content yet.

Evidence: Fullstack Electron account (name only, no content), linked from Projects (block lNVBMnJf, 2026-08-07T18:46Z revision); the author's Electron content cluster: The Case Against electron-trpc, Windows Code Signing Nightmare, Velopack: Delta Updates for Electron Apps.

Electron app developers (build → sign → update → distribute lifecycle)

The author (consolidates his own expertise into a flagship site)

The Seed desktop team (shared patterns)

A "Fullstack Electron" Seed site: consolidate the existing Electron posts into a structured series (architecture → performance → signing → updates → distribution), each doc content-addressed and cross-linked; optionally a paid playbook bundled with #29.

Populate the bare account with the 3-4 existing Electron docs as a series hub + landing page; cross-link from /projects.

Via the /projects link (already live), the Short Posts Electron content, r/electron, HN; pairs with #29/#35 distribution.

Free site; paid playbook ($19-29) bundling with #29 Ship Local-First Playbook.

Electron Forge / electron-builder docs, scattered dev.to and blog posts; no consolidated "fullstack Electron" narrative from a working practitioner.

4/10 — Scaffold only; intent inferred from the /projects link and the author's Electron expertise. Watch item: if the account gains content, revisit with full treatment.

Populate one page (e.g., the electron-trpc case study) on the account; check whether the /projects link persists and whether the author adds more. If yes, escalate to a full playbook.

---

The author states the gap first-party and commits to filling it: "Todos los contenidos de dev tools que me encuentro están en inglés, y el español es un hueco enorme" (#jqN1KpTs) — and the whole point of his new ambassador role is to "compartir esa experiencia abiertamente con la comunidad... mostrar cómo lo uso de verdad, en proyectos reales" (#sWp3k-Au). Spanish-speaking developers (LatAm + Spain) have no production-grade, Spanish-language source for AI-assisted development — no "how I use Devin daily, with wins and limits" content in their language. He is now an official Devin Ambassador with a built-in audience and credibility.

Spanish-speaking devs (LatAm + Spain), indie hackers, side-project builders

Devs evaluating AI coding agents who can't follow English-first content

Mobile-first / time-constrained builders (the author's own persona)

The Barcelona meetup audience (#42) and newsletter readers (#32)

A Spanish-language content engine built on the ambassador commitment: short-form videos with real screen recordings ("Nada de pdf-presentation-vibe: ejemplos reales, pantalla real", #jqN1KpTs), a Spanish newsletter (needs #32), and a paid mini-course/playbook "Devin en producción" using the Seed/GymClass/Jean case studies. Seed is the source of truth; videos and email are renders.

First 10 Spanish shorts: features + tricks learned from daily production use (booking system, refactors, mobile orchestration)

A landing/subscribe page on the Seed site (feeds #32)

Cross-post each video to YouTube (channel exists), X/Bluesky, and the Seed site

YouTube + X/Bluesky in Spanish; ambassador program channels

The Barcelona meetup (#42) as the in-person funnel

Newsletter (#32) as the owned audience; Seed site as the hub

The booking-system and ambassador posts as seed content

Free: videos + newsletter (lead gen)

$49: mini-course "Devin en producción" (5 modules, Spanish)

$29: playbook ebook (bundles with #41/#25)

Sponsorships later (dev-tool vendors targeting LatAm/Spain)

English content (Cognition docs, AI-dev YouTubers): excellent but English-only — the author names the gap

Spanish generic tutorials: surface-level, no production workflows, no real projects

Differentiation: official ambassador + real production usage across three products + mobile-first angle

9/10 — First-party stated gap, official ambassador status, existing content stream and channel; low cost to start; monetization unproven but the content compounds into #41/#42 and Seed adoption.

Publish 3 Spanish shorts from the booking-system experience (refactor story, phone-orchestration loop, one gotcha); measure watch-through and subscribe conversion; ask viewers what they'd pay for a course.

---

The author's primary Devin usage is from mobile — "seguir programando desde el móvil, que es mi uso principal de Devin" (#BATSkROG). The booking-system post documents the full loop: Devin works an issue → opens a PR → records a video of the running app → the author reviews "2-sentence summary + 30-second video" and taps merge — from his phone, between meetings or while waiting for his daughters (#nIDDaiRl, #yQG4gips). This workflow — async agent + phone review — is the reason Devin's math works for busy founders, but it is undocumented as a repeatable system. Most devs assume agentic coding requires a desktop IDE.

NEW EVIDENCE (2026-08-11, Pass J): The same post makes the review cadence explicit: "I'm not sitting at my laptop reviewing diffs for hours. I'm reading a 2-sentence summary, watching a 30-second video, and tapping 'merge'" (#yQG4gips) and "I did entire multi-PR features this way while commuting or waiting for my daughters outside their activities" (#oU8oCNCA) — the playbook's core loop (issue → PR → video → merge) is now captured verbatim with the exact time-boxes. The post's "What I got done in a month" list (#ciK0QxY7) is the playbook's reference case study.

Side-project builders with full-time jobs (the author's own case)

Founders, commuters, parents with fragmented time

Devs new to AI agents who think it requires a big IDE setup

A playbook + template pack encoding the phone-driven agent loop: project kickoff prompts, issue-splitting patterns (vertical slices, per the booking post), the PR-video-review-merge loop, repo/CI setup for agent-driven development, and guardrails (what to ask, what to avoid — "Good prompting is essential", #zXN0M3mh). Bundles with #18 (linear-agent) and #20 (dev-env).

Ebook (~50 pages) "Ship From Your Phone" + prompt template repo

Reference case study: the GymClass month (what got shipped, week by week)

Landing page with the 5-step loop diagram

Blog post + YouTube (feeds #40); HN, r/SideProject, r/DevinAI

The Barcelona meetup (#42) as live workshop venue

Bundles with #40 (Spanish) and #25/#29 (self-hosting)

$29: ebook

$59: ebook + templates + updates

$199: live workshop (with #42 community)

Devin/Cognition docs: tool documentation, not operator workflow

"Vibe coding" content: desktop-first, no async phone loop, no PR-video-verification

No mobile-first agent operator playbook exists (gap)

8/10 — Fully documented first-party workflow across two posts; low cost (writing + templates); asymmetric upside as the flagship use-case story for #18/#20 and the author's brand.

Publish the loop as a blog post + template repo; collect emails; ask 5 side-project devs to run the loop for a week and report whether they shipped more.

---

The author commits to starting an in-person community: "Quiero empezar una pequeña comunidad de Devin users en persona aquí mismo en Barcelona... Si te suena, escríbeme y vamos dándole forma" (#tLFqxwQx). Barcelona has no local meetup focused on AI coding agents; generic dev meetups (BarcelonaJS etc.) don't cover agent workflows; online-only communities don't provide the hands-on exchange the author wants ("intercambiar workflows y soluciones a problemas reales").

Barcelona devs using or curious about Devin and AI agents

The author (community lead; also distribution for #40/#41)

Dev-tool vendors targeting the Spanish/European market (sponsors)

"AI Agents Barcelona": a monthly meetup + a Seed-powered hub (agenda, talks, recordings, RSVP via comments) + a reusable meetup-in-a-box kit (sponsor deck, speaker guide, agenda template, recording workflow) that other cities could copy — the Seed-native answer to "community needs a home".

First meetup (20-30 people) — venue, RSVP, agenda, 2 talks + open mic

Hub document on Seed with RSVP + past-talks index (dogfoods #8 Forum View / #34)

Recordings published (feeds #40's content supply)

Ambassador channels, X/LinkedIn, Barcelona dev communities, meetup.com

The ambassador post is already the invitation ("Si te suena, escríbeme")

Seed site as hub; cross-promotes #40/#41/#32

Free: community meetups

Sponsor slots: €200-500/event (venues, coffee, recording)

Paid workshops later (with #41)

BarcelonaJS / local dev meetups: generalist, no AI-agents focus

Online-only AI communities: no in-person exchange

No local AI-agents community exists in Barcelona (gap)

7/10 — First-party commitment with a public call-to-action; demand is real but proving it needs the RSVP test; execution risk is organizer time. Strong distribution value: it feeds #40/#41 and gives Seed a live community showcase.

Count responses to the post's open invitation; if 15+ sign up, book a venue and run the first meetup; measure repeat-attendance and sponsor interest.

---

Small martial arts academies run scheduling, attendance, membership plans, and family accounts on paper, spreadsheets, and WhatsApp. The enterprise booking platforms (Mindbody, ClassPass) are built for large fitness chains, are expensive, and don't fit independent martial arts schools; the author's coach's academy is the reference user. The booking-system post describes the product as "a full-stack booking system for martial arts academies" (#awEgsWUx) and states "This isn't a toy project. It's a real app with real users at our academy" (#TuKJ2FIM) — a production system with a waiting list of academy needs.

Restoration note (2026-08-11): This opportunity was originally logged as Opportunity 14 on 2026-07-28 ("GymClass — Martial Arts Academy Booking") but was dropped during the 2026-07-31 renumbering merge. The booking-system post — now with a See also section linking the backlog — is the restored evidence base. Same spirit as the #30 restoration.

Independent martial arts academies (BJJ, karate, judo, boxing) — the coach's academy first

Coaches/owners who manage scheduling, attendance, memberships

Parents managing family accounts (bookings for kids)

Trial-class prospects (acquisition funnel)

Productize the existing GymClass app as a vertical SaaS for martial arts academies: multiple user roles (admins, coaches, students, parents), class scheduling, attendance tracking, trial bookings, family account management, and membership plans with booking limits (#awEgsWUx; shipped items: class materialization #0xm8GYBE, family accounts #JNdz0LHV, membership plans with limits #Y-AKUOi-). The agent-built cost structure (built by Devin as a side project) is the moat: feature depth at a fraction of enterprise cost.

Already built — the app is live at the academy. The productization MVP is: multi-academy tenancy + onboarding flow + billing (Stripe), then a second pilot academy. Stack is production-ready (TypeScript, Bun, React, Hono, tRPC, Drizzle, Neon, Cloudflare, #awEgsWUx).

The coach's academy network (first 5 academies are reachable through the author's own training community)

Spanish-speaking markets (LatAm + Spain) — pairs with #40's Spanish content engine

WhatsApp trial-booking connector (#44) as the acquisition wedge

The booking-system post itself is the case study; ambassador channels amplify

Per-academy SaaS: $49–99/mo tiered by size (vs Mindbody's enterprise pricing)

Setup/onboarding fee: $199–499

Trial-class tier: free for the first academy month (funnel via #44)

Mindbody, ClassPass, Pike13, ZenPlanner, TeamUp: established but enterprise-priced, US-centric, heavy for independent academies; weak WhatsApp/mobile-first flows in LatAm

Spreadsheet/WhatsApp (status quo): what GymClass replaces

Differentiation: martial-arts vertical fit (family accounts, trial bookings, class limits), agent-built cost structure, WhatsApp-first acquisition, Spanish-language market

7/10 — Real product with real users is documented first-party; the author has domain access (his coach, his academy); the market is real but crowded at the top. Risk is distribution and willingness to pay outside the pilot academy.

Run a second academy as a paid pilot at $49/mo (coach's network); measure onboarding time, weekly active usage, and whether the academy renews. If 3 academies convert, productize multi-tenancy.

---

Trial classes are the #1 acquisition channel for martial arts academies, but the booking flow is manual WhatsApp back-and-forth — no schedule check, no confirmation, no reminder, no CRM record. The booking-system post lists "A WhatsApp trial class booking connector (research phase)" among the shipped/planned work (#jtfPPblO) — first-party confirmation the need is real and the author is already building toward it.

Academy owners/coaches (prospects message them on WhatsApp daily)

Trial-class prospects and parents (WhatsApp is the default channel in Spain/LatAm)

GymClass (#43) customers — the connector is the acquisition wedge

A WhatsApp Business API connector that lets a prospect book a trial class in chat: checks availability, books the trial, creates the student record in GymClass, sends confirmation + reminders. Later generalizes to class bookings and membership inquiries for the whole #43 product.

Single-academy flow: WhatsApp number → availability lookup → trial booking → CRM record + confirmation message

Reminder automation (24h before trial)

Deploy against the pilot academy (#43 experiment)

Bundled with GymClass (#43); standalone $19/mo for non-GymClass academies

The #40 Spanish content engine can demo the flow (Spanish-language video)

WhatsApp Business API ecosystem communities

$19/mo standalone, or included in GymClass's $49–99/mo

Per-trial fee option (e.g., $1/trial) as usage-based alternative

Manual WhatsApp (status quo): what the connector replaces

Generic WhatsApp Business apps: no schedule/booking integration

Mindbody/ClassPass trial funnels: web-first, not chat-native, not Spanish-market-first

6/10 — First-party research-phase signal; the funnel problem is universal in the vertical; WhatsApp Business API cost/complexity and platform policy are the main risks.

Prototype the flow with the pilot academy's WhatsApp number for one month; measure trials booked without manual coordination and prospect response rate.

---

Routine migrations (test runners, hosting, ORMs, package managers) are audit → classify → plan → sequence → verify work that teams do by hand or trust agents to do blindly. The booking-system post documents two full agentic migrations with numbers: the Vitest→Bun migration — Devin audited first ("You're already 87.5% done — 42 of 48 test files already import from bun:test"), classified trivial swaps vs mock rewrites, executed, rebased cleanly on a merge conflict, and got CI green (#_DlPFXEO) — and the hosting migration from Coolify-on-Contabo to managed services, where Devin researched the architecture, proposed a phased plan with rollbacks, answered latency trade-offs (US/Panama/Spain), and created tracked issues (#kB5QjMO9). The pattern — audit, classify, plan in dependent PRs, verify — is the product.

Engineering teams with migration backlogs (test runners, hosting, ORMs)

Indie devs who want migrations done safely while they work elsewhere

The author's own next migrations (and #37's IPC migration is a perfect first dogfood)

A playbook + template repo encoding the audit→classify→plan→sequence→verify loop as repeatable prompts and scripts: audit commands per migration type, classification rules (trivial vs complex), PR sequencing with CI gates, rollback plans, and a verification checklist. Optional CLI (migrate-plan) that produces the migration plan from a repo scan.

The playbook document (audit → classify → plan → sequence → verify) with the two case studies as reference

Template repo: Vitest→Bun migration pack (audit script, classification, PR template)

Blog post "Devin is really good at refactors — here's the loop"

Blog series tied to #18 (linear-agent) and #41 (ship from your phone)

#40 Spanish version (the booking post is already Spanish-adjacent content)

r/typescript, r/node, HN; pairs with #37's IPC audit as a concrete companion

Free: playbook + one template pack

$29: full template library (per-migration packs)

Consulting: $500+ per migration audit using the loop

Manual migrations (status quo): exactly what this replaces

Generic agent prompts/docs: not migration-specific, no audit→classify→verify structure

No structured agentic-migration playbook exists (gap)

7/10 — Two fully documented first-party case studies with concrete numbers; the loop is proven; cost is writing + templates. Overlaps #18/#41 but is a distinct, sellable artifact.

Write the Vitest→Bun audit script from the post's described steps; run it against an open-source Bun repo; ask 5 maintainers if they'd use the plan output to delegate the migration to their agent.

---