Ecosystem surfaces record: protocol-rendered UI, module system, agent experience, interop

Fourth entry in the record set (#336 map, #337 identity, #341 execution surfaces), and it revises one thing in #341: workstream H's sequencing. Like the others, this is a tracking record; slices get their own issues, and nothing lands except under the house gate.

The organizing idea

Richer human surfaces are earned territory, and the way to earn them cheaply is protocol-first. Interface fragments served over MCP are rendered by hosts we do not build; the bundled web console becomes a later host of the same fragments; native clients, if ever, are thin hosts again. One UI investment, many surfaces. The second thread is that "a programming environment for workflows" needs language-ecosystem machinery rather than more engine: composition-by-inclusion, mechanical interface-versioning, and stdlib governance. Every workstream here is a surface over machinery the other records already specify; nothing below adds engine semantics.

Principles these workstreams add

1. A fragment is a tool with a face. Every rendered surface is backed by the same RPC the CLI uses; the UI adds affordance, never authority. Anything possible in a fragment is possible, identically authorized, without it. No fragment-only capabilities, the same rule #341 states for the console.
2. Composition-by-inclusion is compile time; composition-by-execution is run time. call: runs another workflow as an isolated child with its own identity, policy, and budget. A module import splices declarations into the compiling file before the spec freezes. Never blur them: imports cannot cross an isolation or identity boundary, and call: never silently inlines.
3. The workflow interface is inputs + outputs + signals plus declared triggers. Everything else is implementation. Versioning, breaking detection, generated docs, and any interop projection all derive from this one surface: one definition, many projections, the proto-first doctrine applied to workflows themselves.
4. Diagnostics carry fixes. A diagnostic without a machine-applicable suggested edit is unfinished. The LSP already has code actions and flow fix proved the rewrite discipline; generalize: fix-shaped edits attached to diagnostics, surfaced identically over LSP for editors and over MCP for agents, so a consumer that writes an invalid Flowfile converges without a human translating errors.
5. Adapters at the edge, protobuf at the core. Any interop surface is a projection generated from the same schema substrate, versioned and breaking-checked like everything else. An adapter that grows its own model has failed review before code review.

Workstreams

A. MCP App fragments, and the #341 H resequencing. Serve interface fragments as resources from flow mcp (and the remote MCP surface from #337 H), each backed by an existing RPC, with UI-initiated actions traveling the protocol's own audited tool-call path. The flagship is the approval card: a pending wait_for_signal: gate rendered with what is being approved, who requested it, and the plan digest when #341 D applies; the approve action arrives at the server as an attested signal from the client's identity, fully subject to signals: rules and distinct-from-starter. That one card is the identity investment made visible. Then a plan-review card, a run-watch card over the existing watch stream, and a submit form projected from a workflow's declared typed inputs. Revision to #341 H: the console stops being the first human surface; fragments ship first, and the console arrives later as another host embedding the same fragments plus navigation and search, its riskiest UX already production-real. Open questions: fragment build/test pipeline (fragments are versioned, content-addressed, signed artifacts under #341 A and G), graceful degradation when a host does not negotiate the extension (principle 1 already forces the plain structured result to stand alone), state posture (bias re-query; hosts cache templates, not data), and the review posture for HTML shipped into other people's clients (treat like release binaries: signed, reviewed, pinned). First step is a research spike: read the extension spec in full and prototype the approval card against two different hosts before designing the pipeline.

B. Module system, flow breaking, and stdlib governance. The deepest workstream. Three coupled pieces. (1) Imports: reusable libraries of steps, input-schema fragments, CEL helpers, and policy fragments, spliced at compile time under principle 2, resolved only by digest (#341 G is the distribution layer; this is the semantics layer). Constraints that keep imports analyzable: no cycles, no import-time computation, everything an import contributes visible in flow compile output; the frozen spec stays the single artifact either driver executes, with provenance metadata the only trace. flow fmt and flow fix must understand imports from day one or formatting fractures the ecosystem early. (2) flow breaking: compilation already produces protobuf, so a workflow's interface (principle 3) is a message schema, and breaking-change detection against a previous version (registry digest or git ref) is the same discipline our own CI already applies to the public schema: removed or retyped inputs, tightened constraints, removed outputs, narrowed signals, changed triggers, each classified and run as a CI gate. Callers pin by digest so nothing breaks silently today; flow breaking is what makes intentional evolution legible. Policy files probably get report-only treatment, since a deployment tightening its rules is supposed to constrain callers. (3) Stdlib governance: name the tiers explicitly. Core tasks (in-binary, compatibility-guaranteed), blessed modules (first-party, versioned, signed), community registry (signed, digest-pinned, reputation earned), with promotion criteria written down. The failure mode to design against is discovery without trust gradation.

C. Agent experience: close the loop. The tree is already positioned (AGENTS.md, flow tasks --output json, flow validate --output json, positional diagnostics, LSP code actions, flow mcp, flow fix). Three extensions. (1) Structured suggested edits everywhere (principle 4), with the measure of done being an agent handed a broken Flowfile and the MCP surface converging to valid without reading prose. (2) Docs as MCP resources: DSL reference, task catalog, and worked examples served over flow mcp, generated from the same sources as the human docs and held to the tree by tests, the same discipline that already pins docs/reference/. (3) A Flowfile-authoring eval suite: scripted authoring tasks graded by flow validate plus flow test against reference test files, measuring whether models write correct Flowfiles cold and with the MCP surface. Doubles as regression protection: a syntax change that tanks authoring success is a breaking change in the agent-experience sense.

D. Interop adapter: a published workflow as a delegable task. A thin projection exposing explicitly published workflows to agent-to-agent task protocols: task lifecycle maps to run lifecycle, input-required to wait_for_signal:, auth-required to wait_for_grant: (#337 F), artifacts to run outputs (#341 A), the discovery card generated from the workflow interface (principle 3) and signed with flow keys material, security schemes served by the existing OIDC surface, push notifications by the signed outbound deliveries #337 E already specifies, streaming by the existing watch stream. Inbound delegation is a caller identity under the same federation config #343 just characterized; no new trust machinery. Publication is explicit opt-in per deployment, never all workflows. Where a protocol expects conversational turns a compiled workflow does not model, decline honestly rather than fake it. Sequenced opportunistically: the justification is cheapness (schema-to-schema on the existing Buf substrate, reusing three #337 workstreams), not a bet on adoption.

E. Embeddability deepening and a WASM validator spike. The fragments from A should be consumable as libraries by embedders building their own UIs; the MCP packaging is one host for them, not their home. And a timeboxed research spike: compile flow validate and compile-preview to WASM for browser editors and a docs playground, byte-identical to production, extending "both drivers must agree" to every surface. Binary size and the CEL/protobuf dependency graph are the open questions; spike, measure, then decide.

Sequencing

1. A's research spike and the approval card, which also carries the #341 H resequencing and exercises #337 H.
2. C.1 structured edits: cheap, compounding, mostly plumbing on existing diagnostics.
3. B's study (import semantics and a breaking-rules v1 proposal for review against DSL doctrine), landing implementation after #341 G stabilizes digests.
4. C.2 and C.3 alongside.
5. D opportunistically, after #337 E, H, and I exist to reuse.
6. E.2 anytime, timeboxed.

Anti-goals

Not a consumer app: fragments and the eventual console serve operators, authors, and approvers. No fragment-only power, and no second semantics via sugar: any UI-driven authoring compiles to the same spec. Adapters are deletable without a trace in core. No import-time computation: analyzability of the frozen spec outranks expressiveness of composition. No machine-readable projection ships unless it is generated and held to the tree by tests.

Begin with the extension spec and the sequencing in workstream A; prototype the approval card served by flow mcp against two hosts before proposing a fragment pipeline. For the agent-experience slice, read AGENTS.md, flow validate --output json, the LSP code actions, flow fix, and docs/reference/. Done is defined by the selected spike or slice's explicit experiment, review proposal, or convergence tests.