Research Roadmap

_Last updated: 2026-08-11 (trigger: Devin Ambassadors announcement — Spanish-language content market research + agent-control protocol boundary; reconciled a concurrent re-fire write that had replaced the document body)_
_Next review: On significant repository change_

---

Active Investigations

1. Agent State Machine Model Validation

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.

---

2. Trust Graph Topology in Open Source

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?

---

3. Multi-Agent Coordination Patterns on Content-Addressed Stores

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.

---

4. Self-Healing Knowledge System Design Patterns [NEW]

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.

---

Proposed Investigations

5. State Machine Adoption Barriers

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.

---

6. AI Contribution Quality Metrics

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.

7. Community Models ↔ Trust Graph Mapping [NEW]

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.

8. Deployment Configuration as State Machine [NEW 2026-07-31]

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.

9. Diagnostic Template Generation from Config State Machines [NEW 2026-07-31 — final revision]

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?

Evidence Update — 2026-07-31 (Vibe code pipeline trigger — the 4-step Linear→Agent pipeline)

Investigation #1 (Agent State Machine Model Validation) — new substrate. The pipeline vision (4-step spec) plus the author's own link to the state machines post gives the formal model a second real-world workload to validate against: task lifecycle (assigned → in_progress → ready_for_review → merged). The community MCP template is an existing implementation whose behavior can be traced.

Investigation #6 (AI Contribution Quality Metrics) — new angle. The pipeline's terminal step ("create PRs when the issue is fixed") begs the quality question: what evidence distinguishes a fixed issue from a plausible-but-wrong fix when the PR was produced autonomously? The source post's new Graduated Trust cross-link makes this the explicit link between pipeline execution and trust. See new Proposed Investigation #10 below.

10. Verification Protocol for the Linear→Agent Pipeline [NEW 2026-07-31]

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

Evidence Update — 2026-07-31 (Short Posts hub restructure trigger — author-labeled clusters)

#1 (Agent State Machine Model Validation) — new substrate. The author's reorganization of Short Posts placed How to Background Agents under the State Machines lane — the author classifies the practical background-agent workflow as state-machine territory, giving the formal model another observable workload (agent spawn → task lifecycle → PR). The lane also cross-links the Knowledge Map.

#8 (Deployment Config as State Machine) — permanent exhibit. The full Jean troubleshooting doc is now embedded in the All Posts lane of the hub — including Recommended setup, Why the direct Tailscale IP may stop working, Quick checks, and Is this a Jean issue?. The manual quick-check matrix stays visible in the hub for comparison against any mechanically generated template.

#9 (Diagnostic Template Generation) — pattern visible in situ. The embed means the troubleshooting structure is now consumed inside an index hub, not only as a standalone post — an additional requirement for generated templates: which parts must remain embeddable (checks, expected outputs) and which are narrative craft?

_Updated: 2026-07-31 (Short Posts hub restructure trigger) — appended lane/embed evidence to #1/#8/#9. No new investigations. Re-applied on top of a concurrent execution (res-vibe-footer2) that had overwritten this document; concurrent content preserved in full._

Evidence Update — 2026-08-03 (homepage trigger: document machine as formal-model substrate)

#1 (Agent State Machine Model Validation) — second formal model available. The document machine spec defines an explicit transition system (loaded → editing → publishing; version-history viewing; discard-draft; rebase with re-entry guards) implemented in XState v5 (465 lines per the Project Plan). This gives the state-machine validation program a second, in-production workload, and Product Backlog Opportunity #2 (State Machine Inspector) is the natural trace-collection tool. The external Case Study: Document Editor on the UI with State Machines hub independently documents version-history/branching behaviors that can be checked against the model.

#9 (Diagnostic Template Generation) — new domain. The document machine's quick-check analog: which states/guards can be checked from outside ("is a draft present?", "is a rebase in flight?") for a troubleshooting template.

11. Document Machine State Model Formalization [NEW 2026-08-03]

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

Evidence Update — 2026-08-07 (Query Block Table View trigger: deferred backend design + identity recovery)

New investigation #12 — Backend Metadata Query Model. The Query Block Table View Implementation Plan explicitly defers the entire server-side query design to a "later backend design" (Backend-query boundary), and Horacio's review-request comment says the alternative modeling options "rely a bit on how the backend query will be constructed." This is the gating research for Seed Databases (Opportunity Backlog #21/#22).

New investigation #13 — Account Recovery for Self-Custody Identity. The password-creation story commits to 6 recovery words stored encrypted + vault sealing, while Iskak's live thread (2026-08-07) challenges recovery-code UX. Recovery is the trust seam of Signature #4 — see Opportunity Backlog #23 and Content Roadmap #26.

12. Backend Metadata Query Model [NEW 2026-08-07]

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.

13. Account Recovery for Self-Custody Identity [NEW 2026-08-07]

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

---

Evidence Update — 2026-08-07 (Seed Hypermedia project doc trigger: typed documents + performance measurement protocol)

#12 (Backend Metadata Query Model) — new predicate dimension. The Forum view experiment proposes author-selectable document types — "type" becomes a first-class queryable attribute for the metadata query model, and typed views (forum/table/list/tree) are presentation functions over typed documents. Add "type" to the predicate grammar sketch (Investigation #14).

14. Document Types & View Polymorphism [NEW 2026-08-07]

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

15. Electron Startup Performance Baseline [NEW 2026-08-07]

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

Evidence Update — 2026-08-07 (second trigger: the same-day curation revert)

#12 (Backend Metadata Query Model) — field evidence for the predicate design. The Projects whole-space Table demo (16:21) was replaced within ~2.5 hours by a curated layout — the uncurated firehose was unpresentable on a public index. This makes the #12 predicate/filter design a launch requirement for live public indexes, not a v2 nicety, and adds a research question: how do curated pin lists compose with server-side predicates (public index = query + curated subset)? The same-day sequence is the strongest empirical argument that the Table view cannot ship as a public default without #12.

_Updated: 2026-08-07 (second trigger) — appended same-day curation-revert evidence to #12. No new investigations; all prior content preserved._

Evidence Update — 2026-08-07 (reconciliation, second — Interface Notions convention substrate re-applied)

#1 (Agent State Machine Model Validation) — new convention substrate (re-applied). Interface Notions is the author's interface-common-understanding doc aimed at constraining agent-generated code — a testable convention layer for the agent model: agent output (UI components, IPC procedures) should conform to the catalog. The electron-trpc teardown's 109 procedures across 26 modules are observable traces of the generated API layer. The concurrent pass covered typed documents (#14) and startup performance (#15) but dropped this item; it is re-applied here. (Opportunity Backlog #28, Content Roadmap #29.)

_Reconciled: 2026-08-07 (concurrent merge, second) — re-applied the convention-substrate evidence to #1 that the concurrent write dropped; concurrent op0807b/wr0807/res0807b content preserved in full._

Evidence Update — 2026-08-11 (Devin Ambassadors trigger: Spanish content market + agent-control protocol boundary)

New investigation #16 — Spanish-Language DevTools Content Market. The Devin Ambassadors post commits to short videos in Spanish and names the gap ("el español es un hueco enorme"). Before scaling the franchise (Opportunity Backlog #29), quantify the market. Feeds the franchise investment decision and the Spanish lane hub (Content Roadmap #32).

New investigation #17 — Devin ACP as a Protocol Boundary. Jean PR #583 integrates Devin ACP into a self-hosted local-first tool — the first concrete agent-control-protocol instance in this repository. Ties Signatures #1/#3/#5.

#1 (Agent State Machine Model Validation) — new workload. The ambassador post's workflow (task → plan → PR → video → human merge) is another observable workload; the video-review loop is an explicit verification state in production.

#10 (Verification Protocol) — practice exists in production. The video-review loop (Devin records the app running; the human watches then merges, per the booking-system article) is a concrete evidence-bundle practice already running — formalize it as the protocol's reference implementation.

16. Spanish-Language DevTools Content Market [NEW 2026-08-11]

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.

17. Devin ACP as a Protocol Boundary [NEW 2026-08-11]

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

Reconciliation — 2026-08-11 (re-fire note preserved; document body restored)

What happened: A concurrent re-fire execution wrote a single reconciliation note that replaced the entire document body (all Investigations #1-#15 and the 08-11 #16/#17). This version restores the full body and preserves the re-fire note's substance below. All prior content is preserved in this revision.

Status (from re-fire): This firing re-delivered the same Devin Ambassadors doc-update already analyzed above (#16 Spanish content market, #17 Devin ACP boundary, evidence on #1/#10). The concurrent treatment is comprehensive — no new investigations are added by the re-fire.

Live-anchor drift (verify fragments). The live revision of Me uno al programa de Devin Ambassadors (bafyreih35mpsm5vpzfk3ozoteghhqizuhf5l7x4hbyhaw3wajvhfrtvwuu) restructured the post; block IDs changed. Canonical live anchors: #jqN1KpTs (Spanish videos / "hueco enorme"), #tLFqxwQx (Barcelona meetup), #BATSkROG (mobile-first Seed), #S1SAujt_ (Jean ACP PR #583), #9v9x-zxG (open question CTA). Use these in the #16 market scan and #17 case study.

#10 (Verification Protocol) — public failure corpus is being solicited. The post's open-question CTA (#9v9x-zxG: "¿Dónde flaquea?") invites public failure documentation — an incoming real-world corpus for the evidence-bundle design.

#16 (Spanish content market) — demand signal reinforced. The Gardener wiring pass confirms the author-curated Related section (#rel-gt-devin-amb etc.), and the AI & Agent Workflows cluster is at 8+ docs (hub threshold) — feed both into the market scan's demand snapshot.

_Reconciled: 2026-08-11 (concurrent merge) — restored the full Research Roadmap body that a concurrent re-fire write had replaced; preserved the re-fire note's live anchors and evidence in full. All prior content preserved. | Next review: on significant repository change_