GeezerVison

What

Workspace fork sync manufactured required re-pick rows the source never asked for, disabling Sync and suppressing the "Fully mapped" badge. Two independently-reported symptoms turned out to be two distinct root causes landing on the same line in collectForkDependentReconfigs.

Symptom A — an Agent block whose tools include Jira Get Issue, with Select Issue deliberately blank so the agent resolves it at runtime. The modal demanded a value.

Symptom B — a Jira block on write whose Select Project was blank in the source. A required row appeared under the credential card. Toggling the field to manual-input mode and redeploying made the demand vanish.

Why

Cause A — a block-level required applied to a nested tool param

emitAnchoredDependents() runs over two structurally different things: a block's own subblocks, and the params of each tool inside a tool-input. The nested pass read the raw block config and stamped required: isSubBlockRequired(...).

Jira's issueKey subblock declares required: { field: 'operation', value: ['read', …] }, so a Get Issue tool evaluated operation === 'read' → required: true.

But Sim already models this as ParameterVisibility: the tool param is issueKey: { required: true, visibility: 'user-or-llm' }. Every other consumer honors that — the tool-row editor strips required for anything not user-only, and createLLMToolSchema keeps an empty param in the model's schema so the model can fill it. The fork collector was the only surface that didn't.

The editor's own verdict on the same field: Domain * and Jira Account * carry asterisks; Select Project and Select Issue do not.

Cause B — demanding configuration the source never had

projectId hangs off the credential anchor, so a blank one was emitted as a required row. The asymmetry that proves it's a collector bug rather than a data bug: only members carrying a selectorKey are emitted, so the basic selector gated while its advanced twin manualProjectId — identical required and dependsOn, no selectorKey — did not. The same empty configuration blocked or didn't purely on a display preference. That's also why the manual-mode workaround worked: the toggle writes canonicalModes.projectId = 'advanced', and the dormant-member guard skips the row.

Not the remapper. A Jira project isn't a remappable kind — project-selector maps to selector-resource, absent from REGISTRY_KIND_TO_FORK_KIND, so it never reaches unmappedRequired.

Neither fix subsumes the other

• The emptiness fix alone leaves a populated user-or-llm param gating after a parent swap, because effectiveDependentValue blanks the stored value whenever the parent changed in-session.
• The visibility rule alone never touches top-level subblocks.

How

One predicate at the single out.push site, expressing two independent invariants:

1. A sync carries the source's configuration across; it never invents configuration the source never had. Applies to every dependent.
2. Inside a tool-input, only a user-only param is the user's to supply. Applies to the nested pass, where visibility is known.

The tool-row rule is extracted to apps/sim/lib/workflows/tool-input/param-visibility.ts and used by both the editor and the sync gate, so they can't drift. Visibility comes from getToolInputParamConfigs — the same resolver the rest of fork remapping already uses. Unknown schemas (custom-tool / MCP / unresolvable tool id) fail closed to the pre-existing gate.

Rows are still emitted either way — only the gating flag changes — so no stored dependent value is orphaned and no row disappears.

The predicate is written as the positive === 'user-only', never a user-or-llm || llm-only denylist: the two non-user visibilities reach the same verdict for different reasons, and a denylist would silently mis-classify any visibility added later.

Blast radius

~110 required selector dependents across ~45 blocks stop gating when blank in source. Populated ones still gate everywhere — verified on the knowledge-base anchor, which is a different code path from the credential anchor.

Untouched: mapping entries themselves (mapping-service.ts hardcodes required: true, and a blank credential never becomes an entry), nested user-only params with a value, requiredComplete, syncDisabled, and the cleared-ref blocker list.

Verification

Fork diff before → after, against a workflow built and deployed through the real editor:

Row count unchanged (7 → 7). Push and pull directions produce identical flags.

End-to-end through the UI, on a forked workspace:

• Credential mapped → badge reads "Fully mapped", Sync enabled.
• A populated required row emptied → Sync disabled, reason "Reconfigure all required fields first".
• Re-picked a document → persisted as documentSelector = doc_child → after sync the target block holds doc=doc_child.
• Two real syncs ran: credential remapped cred_jira_a → cred_jira_child, KB kb_parent → kb_child, blanks preserved.
• Repeat sync idempotent (no duplicate workflows); rollback {"restored":1} with the undo consumed; unlink left parent: null.

Tests

apps/sim/lib/workflows/tool-input/param-visibility.test.ts (new), dependent-field-noun.test.ts (new), plus 12 cases added to dependent-reconfigs.test.ts. Every behavioral case was verified to fail without the fix, not just pass with it.

Full apps/sim suite: 1,968 files / 26,289 tests passing. turbo run type-check clean across all 24 workspaces. check:api-validation passes.

Review findings fixed in-branch

The pre-landing review caught a real defect in the first commit, fixed in 3ca8d29:

• Silent un-gating on non-string values. The predicate asked isNonEmptyValue about rawSourceValue, which flattens every non-string to '' for the wire contract. A multi-select dependent stores an array, so a populated one reported blank and stopped gating. Reachable today via zoho-desk departmentIds. Now asks the raw value.
• Canonical id is an alias — no longer clobbers a param owning that key as its own paramId.
• A test asserting .every() over an empty array (vacuously true) now pins both shapes.
• The indexer mock is reset per test, so the new cases aren't order-dependent.
• Placeholder copy: Select ${title.toLowerCase()} rendered "Select select issue" for titles that already read as instructions. Extracted and tested; a bare "Select" title now falls back instead of rendering "Select " / "No found".

Security specialist: no findings.

Deliberately out of scope

• human_in_the_loop. Its notification subblock is also a tool-input, but its tools execute directly with no model, so a user-or-llm blank there genuinely is missing. This change stops fork sync gating on it. The gap already exists in the editor — the HITL tool row shows no asterisk and saves blank — so fork sync was only masking it, and only for forked workspaces. The fix is editor-side (give those params explicit visibility: 'user-only', which re-gates them through this same rule). Separate PR.
• Jira condition gating (sibling in-flight PR). It shrinks the blast radius but does not fix Cause B — write / read-bulk / get_project legitimately show the selector. Independent; can land in either order.

Note for affected users

The toggle-to-manual workaround persists advanced into those workflows, which changes which member serializes. Harmless while both fields are empty, but if anyone later picks a project in the basic selector it will be silently dropped. Not auto-migrated — those blocks want toggling back by hand.