PROD-WF-002 — Make the single-project compatibility mode explicit before multi-project rollout

Field	Value
Status	Improvement backlog; source-verified
Architecture state	Deployed backward-compatible single-project mode; multi-project/OpenFGA mode inactive
Severity	Medium
Affected surface	Workflow creation, project presentation, list/detail actions, and future access-management rollout
Components	sparqd/oqullus, sparqd/bff-api, sparqd/workflow-backend, OpenFGA
Associated issue	sparqd/oqullus#546

Where the problem appears

Open Workflow creation and inspect the request payload, available project controls, backend default, and returned capability fields.

Concrete observed case

The current frontend intentionally uses the backward-compatible single-project path. It provides no project selector and omits project_id; workflow-backend therefore applies its core default. OpenFGA and multi-project presentation are not rolled out, and the UI does not consume the backend's future per-workflow capability fields.

This is not evidence that current single-project creation is broken. It is an improvement and rollout-readiness finding: the UI does not explain the implicit project, and the dormant project/permission contract must not be presented as an active product capability.

Expected condition

In the current mode, Workflow clearly states that all workflows are created in the single configured project and the response exposes that resolved project. No inactive project or permission controls are shown as supported.

For a future multi-project rollout, activate and validate OpenFGA first, then add authorized project discovery and capability-driven actions. Frontend visibility remains advisory; workflow-backend must enforce each capability.

Cause and evidence

• Backend source contains project discovery, capability fields, and project-scoped OpenFGA checks, but that architecture is inactive.
• The current form payload omits project_id.
• The backend preserves backward compatibility by resolving the omitted value to core.
• No Workflow UI source consumes the permissions dictionary.

Why it matters

The current UI hides an important placement decision, while documentation can mistakenly imply that source-only project and permission contracts are already supported. If multi-project selection is later exposed before authorization and runtime routing are activated together, users could see unusable projects or actions whose legacy Airflow paths bypass workflow-scoped policy.

Existing controls and workarounds

Continue using the configured single project. Treat core as a compatibility default, not a user-selected project, and do not infer per-workflow permission enforcement from returned fields or visible controls.

Alternatives considered

1. Recommended now: keep single-project mode, label the resolved project, and hide dormant multi-project capability presentation.
2. Future rollout: project selector plus capability-driven actions, released only after OpenFGA and the managed runtime facade are active and tested.
3. Remove project concepts permanently — simpler, but discards the implemented expansion path.
4. Use frontend role names — rejected because presentation cannot replace server enforcement.

Component involvement

• sparqd/oqullus labels the current implicit project and later adds project selection and capability presentation behind rollout readiness.
• sparqd/bff-api preserves the single-project compatibility contract and later exposes project discovery without bypassing workflow-backend.
• sparqd/workflow-backend resolves the current default; its project/OpenFGA checks become enforcement only after OpenFGA is activated.

Reproduction and verification

Follow WF-S005.

Resolution conditions

Close the current improvement when the UI and documentation identify the resolved single project without exposing dormant controls. Multi-project rollout additionally requires activated OpenFGA, managed runtime routing, capability-driven presentation, and denial-before-side-effect evidence.

Validation and blockers

Current behavior is source-verified. Product confirmation of the single-project label and deployment evidence for the resolved project remain open. The future role matrix is blocked until OpenFGA rollout begins.