What: The Agents and State Machines document defines 12 states and 25 invariants for Pi-sdk-based agents. This is a formal model — it needs to be validated against real agent traces.

Open questions:

Do all 25 invariants hold in practice, or are some unreachable/redundant?

Are there states missing from the model that real agents exhibit?

How does the model map to non-Pi-sdk agents (LangChain, CrewAI, custom)?

Evidence: State machines to visualize the work of agents, How to Background Agents, State Machines — Knowledge Map (learning paths now sequence the agentic-coding arc)

Next step: Collect state traces from Product Scout, Gardener, and any other running agent. Compare observed transitions against the formal model. Report violations.

---

What: The Graduated Trust essay proposes a Web-of-Trust-based hop-distance scoring system for OSS contributions. But the real-world topology of OSS trust graphs is unknown.

NEW substrate evidence (2026-07-28): The Community Models in Seed document provides the actual Seed infrastructure for two trust models — formal communities (mutual membership, role-based permissions for contribution scoring) and user web of trust (one-way follows for discovery/filtering). This gives us a concrete architecture to map the research against:

Formal community membership → hop-0 (maintainers) and hop-1 (vouched contributors with role-based permissions)

Web of trust → hops 2+ (discovery paths through followed accounts)

The research question becomes: what's the empirical hop distribution of the web of trust for a typical Seed space?

Open questions:

What does the trust graph of a typical OSS ecosystem look like? (npm, PyPI, crates.io)

How many hops between a random contributor and a core maintainer?

Does the small-world property hold? Are there bridging nodes?

What path quality weighting makes sense empirically?

NEW: How do Seed's formal community boundaries map to hop-distance zones? Is a community member always hop-0, or are there sub-roles?

How would graduated trust scoring apply to the Devin case study? Would Devin have a trust path to a project maintainer? What friction level would it encounter at each hop distance?

Evidence: Graduated Trust proposal, Community Models in Seed, Devin Booking System

Next step: Map the Devin case study to Seed's community models — what would the trust path look like through formal communities vs. web of trust? Which model would Devin's contributions route through?

---

What: Multiple agents writing to the same content-addressed document store is a novel pattern.

Open questions:

Do document-level leases work in practice, or do we need block-level leases?

How does content addressing simplify or complicate conflict detection?

What's the minimum viable coordination protocol for 2-5 agents?

Evidence: Product Backlog — Opportunity 7 — Multi-Agent Coordination Protocol.

Next step: Run a conflict experiment: two agents edit the same document simultaneously. Measure result. Design lease protocol.

---

What: The LLM Wiki spec defines three self-healing mechanisms: version tracking (detect source changes, patch incrementally), deletion handling (remove dependent content when source is deleted), and periodic regeneration (full rebuild after N cycles to prevent drift). These form a reusable pattern language for LLM-maintained knowledge bases.

Open questions:

What is the optimal N for periodic regeneration? Too frequent = expensive, too infrequent = drift.

How do you detect and measure "knowledge drift" — the gradual divergence between wiki content and source documents?

Can the contradiction log serve as a drift metric? (More contradictions = more drift = regeneration needed sooner.)

Do the self-healing patterns generalize to other domains (code documentation, scientific literature review, legal research)?

The human-curated flag creates an append-only mode. Does this work in practice, or do humans need more granular override?

Evidence: LLM Wiki project document — self-healing section, human-override section, contradiction log section

Next step: Prototype a minimal wiki pipeline with one source document. Measure drift over 10 incremental LLM edits. Determine optimal regeneration frequency.

---

What: State machines are great, but hard to establish documents adoption friction.

Hypothesis: The lack of good debugging/visualization tools is the primary barrier.

NEW evidence (2026-07-31): The Jean Web Access behind Tailscale field note documents a real configuration failure — two deployment modes "easy to mix up" — a concrete instance of state confusion in the wild, supporting the tooling/debuggability hypothesis beyond UI code.

Next step: Survey XState community on adoption pain points.

---

What: How do we measure whether an AI-generated contribution is genuinely useful vs. plausible but wrong?

Open questions:

Can we detect "slop PRs" by analyzing code patterns (test coverage, dead code, unnecessary abstraction)?

What signals distinguish a thoughtful AI contribution from a noisy one?

The Devin case study is a rare documented example of high-quality AI contributions (6 merged PRs). What patterns in the Devin workflow produce quality? Can those patterns be formalized into metrics?

Evidence: Graduated Trust proposal, Devin Booking System

Next step: Collect 10 real slop PRs from open source. Analyze patterns against the Devin case study patterns. Propose detection heuristics.

What: The Community Models in Seed document defines two trust models, but doesn't specify how they interact. Can a user be in both a formal community and a web of trust simultaneously? Which model takes priority for hop-distance calculation when both apply?

Open questions:

When a user is both a formal community member (hop-0) and a web-of-trust follower (hop-2 from a maintainer), which distance wins? Minimum? Average?

Can web-of-trust edges override formal community role distance? (Example: a maintainer follows someone outside the community — does that give them hop-1 access?)

What happens when formal community permissions conflict with web-of-trust signals? Who decides precedence?

Evidence: Community Models in Seed — the two models defined; Graduated Trust — where they'd be applied

Next step: Model the interaction between the two trust models. Propose a precedence rule: formal community membership wins for permission gating, web of trust for discovery/relevance. Test against a hypothetical Seed space with 3 community members and 10 followers.

What: The Jean Web Access behind Tailscale field note describes two valid modes (Tailscale Serve vs direct tailnet HTTP) whose misconfigurations produce confusing failure modes. This looks like a small state machine: host binding (127.0.0.1 vs tailnet IP) × proxy mode (Serve vs direct) → reachability matrix.

Open questions:

Can deployment topologies be modeled as state machines where misconfiguration = invalid transitions?

Would a config-state visualization have prevented the "works in browser but not in native app" class of bugs?

Does this generalize to other self-hosted services (reverse proxies, auth origins, WebSocket endpoints)?

What are the other recurring failure modes of self-hosted apps (TLS/proxy ordering, websocket proxying, token leakage in URLs)?

Evidence: Jean Web Access behind Tailscale; State machines are great, but hard to establish

Next step: Formalize the Jean/Tailscale config as a 2-3 state machine; enumerate invalid transitions; check whether the documented failure modes all correspond to invalid states.

What: The final Jean Web Access behind Tailscale revision makes its diagnostic structure explicit: Recommended setup → Why the direct IP may stop working → Quick checks (/readyz, auth probe with expected bodies) → "Is this a Jean issue?" diagnosis. Question: can this troubleshooting-doc structure be generated mechanically from a config state machine (enumerate valid states → emit checks + expected outputs for each)?

Open questions:

Can the readyz body ({"http":true,"ok":true,"websocket_broadcaster":true}) be treated as an invariant of the valid state, checked automatically?

Which parts of a troubleshooting guide are derivable (checks, expected outputs, decision tree) vs. craft (narrative, "why" sections)?

Would a generated template reduce the "easy to mix up" class of errors across self-hosted services?

Evidence: Jean Web Access behind Tailscale (Recommended setup + Quick checks + "Is this a Jean issue?"); the Seed team's dev-docs pattern note — this structure is the admired pattern; Opportunity Backlog #12 (Jean-Style Troubleshooting Template)

Next step: Formalize #8's state machine, then derive the quick-check matrix from valid states and compare against the post's manual checks. This becomes the core of the Troubleshooting Template opportunity.

_Final-revision pass 2026-07-31: appended cross-account evidence to #5/#8 evidence sets implicitly via the post's Related links; added Proposed Investigation #9 (Diagnostic Template Generation). Prior content preserved._

What IA patterns exist across P2P and local-first tools worth borrowing?

What: The Vibe code like a PRO pipeline spec (fetch → expand → spawn → PR) ends at "create PR". The open question is what makes that PR trustworthy: what evidence should a background agent return when it closes a Linear issue, and can that evidence be machine-checked before a human reviews?

Open questions:

What is the minimal evidence bundle for an autonomous PR (diff, test output, state trace, task-to-code mapping)?

Can task acceptance criteria be encoded as states (assigned → in_progress → ready_for_review → merged) with guard conditions, extending the 12-state agent model (Investigation #1)?

How do you timebox/loop-guard an agent that fails repeatedly on the same issue (prompt thrash → backoff → escalate to human)?

Does the state-machine visualization approach (state machines post) make pipeline failures diagnosable at a glance?

Evidence: Vibe code like a PRO — 4-step spec; How to Background Agents; community MCP template; Agents and State Machines

Next step: Model the pipeline as a small state machine (assigned → in_progress → ready_for_review → merged, with failed/escalated traps); enumerate the evidence bundle per transition; compare against how the community MCP template currently reports results.

_Updated: 2026-07-31 (Vibe code trigger, second pass) — refreshed source fragments to the live revision of the source post; noted its new Graduated Trust cross-link in #6 evidence. All prior content preserved._

What: The document machine spec enumerates events/lifecycles that update document content. This is a small, well-specified state machine: loaded → editing → publishing, plus version-history viewing (render old version WITHOUT applying current draft data), discard-draft (only when a draft exists), and a rebase flow that must not run while saving or during another rebase.

Open questions:

Can the "no draft data when rendering an old version" and "no editing from an old version" rules be enforced structurally (state + render guard) rather than by convention?

Does the 12-state agent model (Investigation #1) generalize to document editing — same invariants, different events?

Can rebase conflicts be modeled as trap states with explicit recovery (currently "ignore and transition to rebase idle")?

Which transitions are observable from outside (sync/polling invalidation), i.e., what does the State Machine Inspector (Product Backlog #2) need to surface?

Evidence: document machine spec; Project Plan — New Publish mental model; Publish Guard; Draft Publishing Chain; Multi-draft; Document Web Editing; external Case Study: Document Editor

Next step: Formalize the machine (states × events × guards) from the spec; verify each documented rule (e.g., "discard changes impossible without draft") is a structural invariant; publish the state diagram as the anchor of the "Document Machine" essay (Content Roadmap #22).

_Updated: 2026-08-03 (homepage trigger) — added Investigation #11; appended evidence to #1/#9. All prior content preserved._

What: The Table view plan keeps filtering client-side and defers the server model: metadata predicate representation, supported typed operators, AND/OR grouping, indexing and execution, pagination/cursors, and whether predicates belong in the query model or a reusable saved-view model. Seed's documents carry open metadata maps — the design question is how to query them efficiently on content-addressed, sync-friendly storage.

Open questions:

What predicate grammar fits open metadata maps (attribute → operator → value, typed per the Table view's inferred types: string/number/boolean/date/multi-value)?

Should predicates live in the query model or in a reusable saved-view model — and does that choice predecide Option 2 vs Option 3 of the Table view plan?

How do you index arbitrary metadata keys without a formal schema (EAV-style index? per-key secondary indexes? JSON1?) on SQLite-backed daemons?

How does server-side pagination/cursor design interact with the existing query limit semantics?

Can type inference be pushed server-side, or does the client keep responsibility for mixed/inconsistent values (the plan's deterministic text fallback)?

Does querying over AllDescendants with predicates change the sync/validation story (what counts as a "result" for readers without the full space)?

Evidence: Query Block Table View Implementation Plan — Backend-query boundary, Option 1; the Query Blocks and Databases project doc; Opportunity Backlog #21/#22

Next step: Draft a predicate grammar from the Table view's filter-builder shape (Attribute → Operator → Value, AND chips); evaluate indexing strategies against the daemon's SQLite store; prototype one typed predicate end-to-end.

What: Decentralized identity cannot reset passwords — recovery material is the only path back to the vault. The designs chose 6 recovery words; Iskak argues the recovery-code UX is "more confusing than it's helping" and proposes reusing the existing secret credential type or generated passphrases. The open question is what recovery design actually works for non-technical users without a trusted third party.

Open questions:

What is the actual entropy of 6 words vs the secret credential vs a generated passphrase — and is the recovery material the _only_ vault-unsealing factor (per "vault is cryptographically sealed with the password + recovery word")?

If recovery words are stored encrypted and associated with the vault, what happens when the vault is lost (device wipe)? Is that storage recoverable, and by whom?

What are the empirical failure rates of users saving/keeping recovery material (wallet industry data: seed phrase loss is the #1 cause of lost funds)?

Can recovery be split (threshold schemes) or delegated (recovery contacts) without a central authority?

Does the 6-option word-selection flow ("User selects the recovery word from 6 options") add security theater or genuine verification?

Evidence: password-creation story — recovery-words acceptance criteria (RI5-6GbX, NVTMrZTO, 0muFUWaP); Iskak's thread (2026-08-07) on the same story; High risk for Users with local keys to lose them

Next step: Produce the entropy/failure-mode analysis as input to the design decision (Opportunity Backlog #23); compare against wallet-industry recovery UX; recommend a default with fallbacks before the flow ships.

_Updated: 2026-08-07 (homepage projects trigger) — added Investigations #12/#13; no existing investigations reordered. All prior content preserved._

---

What: The Forum view experiment asks "What if documents can define a type and have 'special views'?" and notes the forum view renders root conversations "similar to how we render children document in the query block" (#Uxl26MAs). The All Documents demo and the Query Block Table view are sibling views. Open question: what is the type/view model — document attribute, view registry, or pure query-block concern?

Open questions:

Is document type an author-selected attribute (per the experiment, #_BwM7vQm) or a derived/registered presentation?

How do typed views relate to query blocks — is a "Forum" view a query over root conversations rendered as threads, or a document-level presentation?

Does type become a first-class predicate in the metadata query model (Investigation #12), and does the Table view's inferred typing (string/number/boolean/date/multi) apply to a document-type attribute?

Migration/back-compat: do existing documents get a default type (e.g., "Document"), and can authors change type without breaking views?

Type × comments: the forum view over comment threads suggests type affects comment rendering too — is that a document-type concern or a query-view concern?

Evidence: Forum view experiment; All Documents - directory; Query Block Table View Implementation Plan; the Seed Hypermedia project doc (embeds)

Next step: Enumerate the decision space (attribute vs registry vs view-on-query) and map the four existing views (card/list/table/tree/forum) onto it; feed the result into the Query Blocks ADR (Content Roadmap #4) and the typed-documents essay (Opportunity Backlog #26).

_Updated: 2026-08-07 (Work & Contributions trigger) — added Investigation #14; appended evidence to #11/#12/#8. All prior content preserved._

What: The electron-trpc tech talk prescribes measuring before and after the migration — startup time, time-to-first-render, bundle size — and its no-gos warn "performance work without measurement is just guessing" (#6VqWIsKJ). The in-site interactions experiment already benchmarks interaction latency (PR #297). This is a concrete measurement protocol for the desktop app.

Open questions:

What are the current baseline numbers (startup, TTR, bundle) before the 42-procedure migration?

Which metrics move when getters/setters move to direct IPC vs when routers lazy-load?

Does the feat/app-startup loading window change perceived startup (TTI vs window-visible)?

Can the benchmark harness from PR #297 be reused for desktop startup, not just site interactions?

Evidence: electron-trpc tech talk; Experiment: Improve performance in-site interactions (PR #297)

Next step: Establish the baseline now (before the migration completes); the before/after numbers become the core of the performance article (Opportunity Backlog #24).

_Updated: 2026-08-07 (Seed Hypermedia project doc trigger) — added Investigations #14/#15; appended type-dimension evidence to #12. No existing investigations reordered; all prior content preserved._

What: The author's public commitment to Spanish-language Devin content (official ambassador) implies a distribution bet: an underserved market ("todos los contenidos de dev tools están en inglés") reached through short videos. Before investing the franchise (Opportunity Backlog #29, Content Roadmap #32), research the market so the bet is informed.

Open questions:

Who currently covers devtools/AI-agent content in Spanish, at what depth, and on which channels (YouTube vs TikTok vs X/Bluesky vs newsletters)?

What formats win for Spanish-speaking dev audiences (short video vs long-form vs written), and what are the engagement baselines?

Does the author's existing English content convert (which posts/videos get Spanish-speaking engagement)?

What is the competitive position of an official ambassador voice in Spanish (Cognition itself has limited Spanish content)?

Which signature ideas travel best in Spanish (agents/async partnership vs trust vs local-first)?

Evidence: Devin Ambassadors post; Devin Booking System; Spanish-language posts already in the repository (Cómo cuidar tu kimono as a format precedent)

Next step: Produce a short market scan (channels, competitors, format baselines) as the go/no-go input for the Spanish franchise; fold into the lane hub when created.

What: Jean PR #583 adds Devin ACP support to Jean — an agent-control protocol integrated into a self-hosted, local-first tool with token auth, websocket broadcaster, and /readyz health checks. This is the repository's first concrete instance of the boundary between an external agent and a local-first tool, and it sits exactly at the intersection of the agent lane (Signature #3), the observability lane (Signature #1), and the local-first lane (Signature #5).

Open questions:

What does a standard agent-control protocol need from a local-first tool: auth/scoped capabilities, tool registration, state reporting, streaming events?

How does Devin ACP relate to MCP (the existing community MCP template)? Same boundary, different framing?

Does ACP expose the state trace the observability thesis needs (Investigation #1/#10), or is observability still left to the host app?

Can the Jean deployment state machine (Investigation #8) be extended with an "agent-connected" state without breaking the reachability matrix?

What are the security implications of an agent control channel on a tailnet-exposed service (token scoping, command whitelisting, audit)?

Evidence: Jean PR #583; Devin Ambassadors post; Jean Web Access behind Tailscale; Agents and State Machines

Next step: Track the Jean ACP PR; when merged, document the protocol boundary (auth, tool registration, state reporting) as a case study and compare against the MCP template; feed the findings into the Verification Protocol (#10).

_Updated: 2026-08-11 (Devin Ambassadors trigger) — added Investigations #16/#17; appended workload evidence to #1 and production-practice evidence to #10. No existing investigations reordered; all prior content preserved._