lda-wf/ISSUES.md

Issues

Draft authoring parity

• Dedicated draft CLI subcommands cover every draft step kind.
• Draft interrupts preserve request and resume schemas.
• Draft subgraphs preserve workflow references and boundary contracts.

Draft data-shaping parity

• wf draft bind accepts nested node-local targets such as local.report.title, consistently with canonical LocalPath, the runtime binding resolver, and WorkflowBuilder.
• Capability-step authoring projects workflow input/state schemas for nested local targets while preserving their canonical binding paths.
• An atomic API/RPC/CLI helper assembles one structured node input from multiple graph paths. Canonical replacement accepts several bindings in one revision-checked edit without an intermediate state object or raw JSON Patch.
• Focused draft authoring can add or replace literal node-input bindings comparable to WorkflowBuilder.use(input=[{"target": ..., "value": ...}]) through canonical API, RPC, MCP, and CLI surfaces.
• Compatibility step input/output map merges reject canonical lists they cannot reproduce exactly, and workflow-output map merges reject requested sources with ambiguous fan-out. Canonical replacement remains the supported path for ordered fan-out and mixed path/literal bindings.
• Focused workflow-output authoring supports literal output bindings through canonical Python, JSON-RPC, MCP, and CLI replacement surfaces.
• Workflow-output replacement projects nested input.* and state.* source schemas, including local references, into missing nested public output targets without requiring raw schema patches.
• CLI help and agent instructions describe step-input targets as bare local fields and do not document the nested composition behavior already supported by the canonical runtime model.
• Canonical bindings construct array values from independently sourced elements through recursive literal/path expressions. Mixed inputs such as wf.std.concat with one state-backed item and one literal are covered by the Python runtime, remote CLI, and browser-to-RPC vertical proofs; indexed local targets such as items.0 remain intentionally unsupported.

Console workflow-client gaps

• Workflow final-output bindings currently accept context.* paths in the shared path model and validation, but finalization projects output without an execution-frame context. Define stable final-output context semantics or reject those bindings during validation. Until then, high-level clients must not suggest runtime context as a final-output source and must show persisted occurrences as unsupported repair values.
• first_item and last_item currently reuse the broad SequenceInput contract even though they reject empty arrays at runtime. Their capability schemas therefore truthfully allow { "items": [] }, and the generated form correctly permits submission. Give only those two operations a non-empty input model and project its minItems constraint into form validation; empty-aware sequence operations must continue accepting empty arrays.
• Artifact creation, deployment creation/rebinding, and complete run start/interrupt/resume/output/trace journeys are not yet usable end-to-end from the console. Existing routes are inspection-oriented and must not be presented as completed acceptance-test coverage.

Draft workspace lifecycle parity

• Capability-free draft workspace creation is exposed through the transport-facing API, JSON-RPC, and CLI for control-first, interrupt-first, end-first, and subgraph-first authoring.
• A focused revision-checked operation changes the draft entry point without patching /start directly.
• A focused contract operation replaces the complete declared workflow outcomes list.
• A focused contract operation replaces workflow input/state/output schemas, preserving reducer metadata carried by the supplied state schema.
• Capability-step creation accepts desc, retry, timeout_seconds, and ordered canonical path/literal inputs through Python, JSON-RPC, MCP, and CLI. The focused update operation preserves use, routes, and outputs while changing selected metadata or atomically replacing the complete canonical input list. Changing the capability itself remains an explicit remove/add operation. TypeScript JSON-RPC parity remains tracked below.

Draft revision semantics

• Semantic draft edits consistently check the expected revision before reading current draft content or capability metadata. After request-envelope validation, stale callers receive the canonical revision_conflict result; mutation-time revision checking remains the final race-safe guard.

TypeScript JSON-RPC coverage

• TypeScript JSON-RPC parity remains incomplete: @lda/workflow-rpc models only the 16 operations needed by the current console explorer. It omits typed access to capabilities, source inspect/diagnose, artifact save/delete/create, deployment save/delete, every draft operation, and source-registry/admin operations already exposed by the Python JSON-RPC server.
  • All 70 Python methods now have named OpenRPC success schemas, including connections, events, and secret-safe auth admin results. No success result collapses to a generic object.
  • contracts/workflow-api.manifest.json is the checked transport-neutral inventory, and python -m wf_contract_manifest check is the drift gate.
  • @lda/workflow-rpc now generates WorkflowOperationName, raw parameter and result types, and a 70-operation lookup map from that manifest. pnpm contract:check detects TypeScript artifact drift.
  • The manifest does not authorize callers: browser authorization, operation metadata, and membership in the 16-operation Effect RpcGroup remain authored boundaries even though their payload/result decoders are generated.
  • A fail-closed representative JSON Schema-to-Effect translator now proves constrained primitives, objects, arrays, anyOf, local references, and structurally guarded recursion against synthetic schemas plus representative checked manifest components. It rejects unsupported oneOf, conditional, composition, and unknown-keyword semantics instead of weakening them.
  • A test-only parity harness translates the payload and success schemas for all 16 authored RPCs: all 32 sides are inside the supported translator subset. Frozen pre-migration schemas pin eight former result mismatches. Run inspect/start/resume used a reduced interrupt instead of the complete manifest interrupt in both acceptance directions; run trace used a compact trace-page envelope and omitted canonical frame identifiers.
  • Runtime decoder migration is complete for the 16 current Effect RPCs. Run inspect/start/resume now require the canonical full interrupt contract, and run trace requires the full run envelope plus canonical frame_id and next_node_id values. Frozen pre-migration schemas keep the eight old bidirectional mismatches visible as compatibility evidence. All generated decoders apply a 64-container request/response value-depth guard. Broader callable client coverage remains incomplete, and the browser allowlist remains authored.
  • The Effect client operation union, runtime list, and guard are now inferred from the authored metadata registry and checked against generated WorkflowOperationName. Hono keeps a separate typed allowlist so adding client support cannot automatically expose an operation to the browser.
• The stock @open-rpc/generator TypeScript client is not suitable here. It exhausted a 4 GB Node heap on the full contract and emitted invalid dotted class members plus any results for a minimal workflow.health contract. Keep OpenRPC as an interchange format, but generate a small transport-neutral contract manifest rather than adopting its client stack.