Status: audit note before continuing 07/08/09.

Purpose: stop inventing replacement nodes. This maps the nodes already visible in the frontend and backend to real executable capability, current wiring, and collection usefulness.

Implementation slice:

• Backend now exposes GET /api/v1/workflows/capabilities.
• Frontend proxies it through GET /api/workflow/capabilities.
• Canvas catalog, command palette, node cards, and Node Management can show REAL, BLOCKED, PREVIEW, or DESIGN status from the capability projection.
• Frontend Canvas Run now proxies to backend /api/v1/workflows/runs, replays /events/stream, and patches existing Canvas nodes from backend run events.
• Canvas now has a real intelligence.input.collection-need catalog node. The node owns the visible user input textarea and calls /api/v1/workflows/demand-draft to produce reviewable real-node patches.
• intelligence.schedule.cron now compiles/runs as a workflow schedule tick binding for Canvas Run; automatic scheduler-to-run creation remains a separate scheduler integration.
• This does not execute blocked nodes. It makes runtime truth visible and runs the narrow OpenCLI node/package proof path; full result/resource workbench wiring is still pending.
• intelligence.output.webhook now exposes the workflow.notifier.webhook.send notifier contract, but Canvas live delivery remains blocked until EvidenceBatch projection, notification permission, and webhook URL resources are connected.
• Webhook input primitives now compile to workflow.trigger.webhook_input. POST /api/v1/workflows/{workflow_id}/webhooks/{trigger_node_id} validates the node contract, creates an idempotent workflow run, and emits typed workflow/run/node/source event identifiers. This remains separate from the data-source /api/v1/webhooks/{source_id} route.
• EvidenceBatch list/detail/projection APIs expose stable, replay-deduplicated run outputs to the Build workspace without streaming raw records.
• Workflow authoring and runtime inspection live under the Build product boundary at /build/workflow; /canvas and /studio are compatibility redirects rather than primary navigation entries.
• The durable backend reuse map is docs/opencli-admin-backend-system-map.md; check it before adding workflow/runtime surfaces.

The system has three real but misaligned surfaces:

1. Frontend Canvas catalog: 23 addable catalog nodes in frontend/lib/workflow/node-catalog.ts.
2. Frontend primitive library: 107 primitive/import nodes in frontend/lib/workflow/node-primitives.ts.
3. Backend collection capability: 7 real DataSource.channel_type runners under backend/channels.

Today, Canvas workflow runtime execution is wired for Collection Need patch drafting, schedule trigger ticks, and source/fetch with an OpenCLI adapter (provider=opencli or config.channel=opencli). Webhook Notify has backend notifier contract metadata, but it is intentionally blocked as live delivery until projection/permission/URL closure. Other catalog nodes may compile or display, but they do not yet have an authoritative workflow runtime binding.

So the next step is not more hand-made nodes. The next step is to project existing backend source/channel/runtime/notifier capabilities into the Canvas catalog, and to mark any unmapped visible node as blocked or design/import-only.

The 107 primitives are not useless, but they are not runtime bindings. They are vocabulary/import atoms. Backend node_registry.py accepts the known primitive ids so imported or AI-patched nodes cannot smuggle arbitrary executor definitions, but accepting an id is not the same as executing it.

Important existing primitives for input/output/webhook:

The operator says a Collection Need, for example "抓小红书热帖". That is not a node strategy and should not force the operator to fill account, keyword, OpenCLI command, profile, cookie, or worker policy by hand.

The correct translation is:

1. Runtime-Aware Plan Drafting matches the need against existing capability metadata.
2. Source/channel candidates come from real DataSource channels, OpenCLI source metadata, saved DataSources, and presets generated from backend metadata.
3. Credentials, cookies, profiles, browser capacity, and worker pools are Execution Resources. They are resolved through saved source credentials, cookie/session stores, browser pool, and worker/resource policy.
4. If a resource cannot be resolved, the node is visible but blocked with a missing-resource reason. It must not look runnable.
5. User-provided text like "抓小红书热帖" becomes plan intent and optional query args, not raw secret/session/runtime params.

Current adapter/resource truth:

This means the "input point" is not a generic textbox inside a source node. There are several typed inputs:

Outputs should not push raw records through events or webhook responses. The existing design note in docs/workflow-hda-demand-runtime-io-webhook-linkage.md is still right:

• Events carry node status, counts, error details, evidence batch refs, artifact refs, and projection links.
• Result views read projection APIs.
• Outbound webhook/notifier nodes send compact payloads plus links/refs.
• Respond-to-webhook only works for inbound webhook runs and should return a short-wait projection summary or 202 with a run id/projection link.

Current state:

Backend tests and the frontend Canvas can now exercise the OpenCLI node/package trace/run event proof path. The narrow answer is: yes for backend run creation, event replay, and real node-status patching on the current OpenCLI source/fetch path.

The broader collection surface is still not directly usable because:

1. The source catalog is not generated from backend channel capability metadata.
2. Most catalog and primitive nodes are visible but lack runtime bindings.
3. Collection Need is now a Canvas node for patch drafting, but WorkflowRunStartRequest still submits the accepted project graph only.
4. Resource resolution for cookies/profile/credentials/worker pool is not connected to Canvas source materialization.
5. Evidence/result projection APIs are not ready, so outputs are still references and event counts rather than inspectable collection results.
6. The single outbound webhook node has a backend notifier contract, but live delivery, notifier fanout, inbound webhook trigger mode, and respond-to-webhook policy are not bound to the workflow run axis.

So the next work remains wiring existing capabilities instead of adding new node concepts.

The next issues are ready only within the narrowed contracts in their issue files:

• 07-evidencebatch-projection-api: ready for a read-only projection API slice with explicit routes, response shapes, pagination, and partial/failure semantics.
• 08-browser-worker-profile-concurrency: ready for runtime resource requirement/resolution metadata and blocked reasons. It is not a full Docker/multi-machine scheduler task, and it must not add user-facing cookie/profile/worker fields.
• 09-canvas-runtime-binding-result-workbench: ready for Canvas workbench wiring against the run/projection APIs, with intelligence.input.collection-need as the visible demand node and no fixture/demo fallback on invalid run payloads.

Agents should treat cookie material, concrete profile ids, worker slots, worker pools, and raw OpenCLI commands as runtime resources or generated adapter metadata. They are never manual user inputs for this workflow path.

1. Add a backend capability projection endpoint for real source/channel/notifier/trigger capabilities, backed by existing registries.
2. Generate/annotate Canvas source nodes from that projection, including runnable/blocked/design-only status.
3. Add resource resolution for source nodes: saved DataSource, source credentials, cookie/session/profile, browser pool, worker policy.
4. Finish EvidenceBatch/projection API so outputs are references and workbench-ready.
5. Wire notifier fanout, non-webhook notifier sinks, inbound webhook triggers, and respond-to-webhook behavior to the same run axis.

This keeps "抓小红书热帖" as a Collection Need. The system should assemble the plan from real OpenCLI/DataSource/resource/notifier capabilities and show blocked gaps only when an existing required capability/resource is absent.