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.

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.

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.

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).

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."

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.

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.

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).

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.

---