PROD-WF-004 — Hide notifications until the channel and delivery contract is complete

Field	Value
Status	Open; source-verified, deployed delivery unverified
Architecture state	Exposed incomplete feature
Severity	High
Affected surface	Multi-task workflow create and edit forms
Components	sparqd/oqullus, sparqd/bff-api, sparqd/workflow-backend, sparqd/platform-stacks, Airflow runtime/provider
Associated issue	sparqd/oqullus#547

Where the problem appears

Open the multi-task workflow form and select + Add Notification. The form offers a channel selector, Failure, Success, Retry, and Execute events, and recipient entry for email channels.

Concrete observed case

The visible form loads /workflow/api/v1/workflows/notification-channels and can submit notification assignments with a workflow. However:

• Oqullus has assignment controls but no channel create, edit, delete, test, or delivery-status journey. An empty channel list is therefore a dead end.
• Workflow-backend lists all channel rows and resolves assignments by globally unique channel_id; the channel model has no project or workspace scope. Channel routes do not enforce a workflow/channel capability. The list and delete routes do not even resolve request identity.
• Channel read responses include the stored config object. A Teams webhook_url is therefore returned instead of being write-only and redacted.
• The assessed Alibaba stack sets NOTIFICATION_SYNC_ALICLOUD_KMS_ENABLED=true and disables AWS synchronization, but workflow-backend defines and checks only NOTIFICATION_SYNC_AWS_SECRETS_ENABLED. Teams connection synchronization is consequently not implemented for this deployment path.
• The compiler emits callbacks to airflow.providers.oqullus.notifications.multi.send_multi_channel_notification, but installation and end-to-end delivery of that runtime provider were not established by the reviewed stack source.

The controls therefore imply a reliable, scoped notification capability that the current product boundary cannot guarantee.

Expected condition

Hide notification assignment from create and edit until a user can manage or select an authorized scoped channel, secrets are write-only, the deployment can provision the corresponding Airflow connection, and delivery plus failure feedback are verified in every supported environment.

Cause and evidence

• MultipleTask.tsx renders the notification section and fetches channels.
• workflow-service.ts validates and serializes assignments into workflow_config.notifications.
• Workflow-backend implements channel CRUD, assignment validation, database storage, AWS Secrets Manager synchronization, and DAG callback compilation.
• The channel model and queries contain no project/workspace key or OpenFGA authorization check.
• The response schema returns channel config unchanged.
• Platform-stacks enables the AliCloud notification-sync flag, while the reviewed backend has no corresponding setting or implementation.

Why it matters

Users can configure a control that may fail only at execution time, cannot repair missing channels from the product, and may see channels outside their intended scope. Returning webhook configuration also exposes notification credentials to readers of the list endpoint.

Existing controls and workarounds

Do not rely on the visible notification form in gj76anadpsc. Hide it with a server-owned capability flag. Existing channels and secrets must be managed and tested operationally until the complete product journey is available.

Alternatives considered

1. Recommended now: hide assignment controls and reject new notification assignments unless a deployment capability declares the full path ready.
2. Complete the feature: add scoped channel management, authorization, write-only secrets, provider health, test delivery, audit, and observable per-event failures before re-exposure.
3. Keep the controls visible with a beta label — rejected because labelling does not contain the authorization, secret-disclosure, or runtime gaps.

Component involvement

• sparqd/oqullus hides or capability-gates the controls, adds channel management and delivery feedback when ready, and avoids a dead-end selector.
• sparqd/bff-api exposes only the scoped, authorized channel contract and prevents secret-bearing responses from reaching the browser.
• sparqd/workflow-backend scopes channels, enforces capabilities, redacts secrets, and makes secret/database synchronization recoverable.
• sparqd/platform-stacks and the Airflow runtime install and configure the provider, connection backend, SMTP/Teams dependencies, and environment capability consistently.

Reproduction and verification

Follow WF-S009.

Resolution conditions

Close when incomplete deployments cannot expose the controls and an enabled deployment proves scoped channel lifecycle, redaction, assignment persistence, event delivery, failure feedback, audit, and recovery for each advertised channel and trigger event.

Validation and blockers

Product, frontend, workflow-backend, security, infrastructure, Airflow, and operations reviewers must validate. Deployed email and Teams delivery evidence for gj76anadpsc remains unavailable.