OpenWOP openwop.dev

Companion to 0133-workflow-chain-composition.md. Working document (not normative). Per RFCS/README.md §"Companion gap & risk registers", every open row must be closed / transferred / carried forward as a named Unresolved question before an Accepted flip. Sweep complete at Accepted (2026-07-22) — dispositions below.

IDSectionQuestion / Missing InputOwnerResolution pathStatus
G1§1.1 ProposalsubChainRef shape: a bare string (sibling chainId) vs an object (external {packName, chainId, version}). RFC accepts BOTH via a oneOf. Confirm the sibling-string form cannot be ambiguous with an external chainId — it can't; a sibling is resolved against the same pack's chains[] first, an object ref is explicit.Schema ArchitectSubChainRef oneOf in the manifest schema; chain-subchain-sibling.test.ts pins the sibling form.Closed — schema landed.
G2§1.2 ProposalForbidding a concrete config.workflowId inside a fragment: enforce at manifest-validation (schema not) vs expansion-time only. RFC enforces at the schema layer.Schema Architectconfig.not: { required: ["workflowId"] } + the chain-subchain-fanout §A negative leg.Closed — schema not-guard + test landed.
G3§1.3 ProposalDeterministic child-id derivation: key on chainId alone (a shared child registers once) vs fold in parameter values (WCP2 parameter-distinct identity). RFC keys on (parentExpansionId, childChainId) — a child is a co-registered workflow, not a parameter-frozen inline splice, so parameters ride the child's own run inputs, not its identity.Spec ArchitectmintChildWorkflowId + chain-subchain-sibling.test.ts determinism + dedup legs.Closed — reference library + test landed.
G4§1.3 / Unresolved #1External sub-chain version pinning for reproducibility.Security / CompatibilityNormative SHOULD (pin resolved version into the parent's ownership record); SubChainRef.ref.version description.Closed (resolved: pin) — Unresolved-Q1.
G5§1.3 / Unresolved #2Co-registered child ownership lifecycle (delete vs reference-count). Host-side lifecycle, not wire shape.Reference hostRECOMMENDED reference-count by deterministic id; carried forward as WCP5 + docs/KNOWN-LIMITS.md.Carried forward — Unresolved-Q2.
G6§1.3 / Unresolved #3maxSubChainDepth default value.Security ArchitectRECOMMENDED default 8; capabilities.workflowChainPacks.subChains.maxDepth (default: 8) + DEFAULT_MAX_SUB_CHAIN_DEPTH.Closed (resolved: 8) — Unresolved-Q3.
G7§2.2 ProposalClosed-world variable validation scope: reads in inputs only, or also config? RFC validates any { type:"variable", variableName } binding anywhere in a node's inputs or config.Spec ArchitectvalidateVariableReads walks both; chain-produced-var-roundtrip.test.ts.Closed — reference library + test landed.
G8§ConformanceThe 5 scenarios + 2 SECURITY invariants are specified but must land with the promotion (RFC 0079 precedent: a protocol-tier MUST-NOT lands with its public test in the same PR).Conformance Architect3 server-free scenarios + sub-chain-expansion-bounded (protocol) land + pass now; 2 gated scenarios + sub-chain-child-tenant-scoped (reference-impl) land soft-skipping.Closed — landed in the promotion PR.
G9§1.3 / SECURITYReference-host verification that runtime child dispatch co-registers per-tenant + refuses when unsupported requires a host wiring the from-chain seam. No public conformance host does yet.Conformance Architect (+ reference host)Deferred to reference-host implementation (openwop-app is the natural fit); chain-subchain-fanout / -unsupported-refused soft-skip until then.Carried forwardAccepted §"Status note"; host-pending.
G10CompatibilityAmending RFC 0013's "chain reference NOT preserved at runtime" (spec step 9) + "no new dispatch semantics" — is this additive or a relaxation of an existing MUST? Additive: it adds an OPT-IN mode; the inline mode's guarantees are unchanged and a subChains-free chain expands byte-identically.Compatibility ArchitectSpec §Expansion step 9 + §What hosts dispatch qualified for the opt-in mode; RFC 0013 gains an Amended by row.Closed — additive; amended-by + spec qualification landed.