Add managed variables and workflow-scoped secrets #11

New issue

Open

opened 2026-09-16 09:54:34 +02:00 by morten-olsen · 0 comments

morten-olsen commented

2026-09-16 09:54:34 +02:00

Owner

Context

Flows need reusable user-managed values without embedding configuration or credentials in workflow documents. Nodes should resolve ordinary values from a vars namespace and credentials from a distinct secrets namespace. Secrets are more sensitive: defining a secret must not make it available to every workflow or node automatically.

Scope

Add a durable variable and secret manager backed by the existing persistence/engine seams.
Let users create, rename, update, and delete named variables. Variables are ordinary managed values and are available to workflow nodes as vars.<name>.
Let users create, replace, rename, and delete named secrets. Store secret material using Android platform-backed protected storage; never persist it in workflow documents.
Expose only secret metadata (for example name and assignment state) to listing, editing, diagnostics, export, and authoring surfaces. Secret material is write-only after creation/replacement and must be redacted from logs, histories, errors, and test reports.
Require an explicit assignment for every secret use: attach a secret to a workflow and optionally narrow that grant to specific node IDs. A secret is present as secrets.<name> only for nodes covered by that assignment.
Validate names, duplicate handling, expression references, workflow/node assignments, and deletion. Reject a workflow that references a secret it is not assigned, and reject deletion while a variable or secret is still referenced unless the user first resolves those references.
Resolve variables and secrets through one execution-context boundary shared by all node types; do not add node-specific credential handling.
Ensure workflow validation and safe test execution report missing, unassigned, or unavailable values as structured diagnostics without revealing secret material.

Non-goals

Do not implement remote secret sync, cloud vault integrations, shared-device/multi-user secret sharing, or secret import/export.
Do not expose secret values through the future authoring IPC, HTTP, MCP, or in-app agent surfaces.
Do not change node-specific action configuration formats beyond replacing resolved values at the established runtime input boundary.

Acceptance

A user can manage named variables and secrets in the app; variables persist as ordinary managed values, and secrets persist without appearing in workflow documents or subsequent read views.
A node can resolve an assigned variable through vars.<name> and a secret through secrets.<name> during execution.
A secret referenced by a workflow but not assigned to that workflow, or assigned only to a different node, produces a deterministic validation/execution failure and is unavailable to the node.
A workflow-level secret assignment makes the secret available to the workflow's nodes; a node-scoped assignment makes it available only to the selected node IDs.
Attempts to export, inspect, log, or return a secret through validation, execution history, errors, or test results return metadata/redaction only, never secret material.
Rename, deletion, and assignment changes preserve reference integrity: invalid references are surfaced before mutation, and no partial state is committed.
Focused tests cover namespace resolution, workflow- and node-scoped access, missing/unassigned failures, protected persistence, and redaction.

## Context Flows need reusable user-managed values without embedding configuration or credentials in workflow documents. Nodes should resolve ordinary values from a `vars` namespace and credentials from a distinct `secrets` namespace. Secrets are more sensitive: defining a secret must not make it available to every workflow or node automatically. ## Scope - Add a durable variable and secret manager backed by the existing persistence/engine seams. - Let users create, rename, update, and delete named variables. Variables are ordinary managed values and are available to workflow nodes as `vars.<name>`. - Let users create, replace, rename, and delete named secrets. Store secret material using Android platform-backed protected storage; never persist it in workflow documents. - Expose only secret metadata (for example name and assignment state) to listing, editing, diagnostics, export, and authoring surfaces. Secret material is write-only after creation/replacement and must be redacted from logs, histories, errors, and test reports. - Require an explicit assignment for every secret use: attach a secret to a workflow and optionally narrow that grant to specific node IDs. A secret is present as `secrets.<name>` only for nodes covered by that assignment. - Validate names, duplicate handling, expression references, workflow/node assignments, and deletion. Reject a workflow that references a secret it is not assigned, and reject deletion while a variable or secret is still referenced unless the user first resolves those references. - Resolve variables and secrets through one execution-context boundary shared by all node types; do not add node-specific credential handling. - Ensure workflow validation and safe test execution report missing, unassigned, or unavailable values as structured diagnostics without revealing secret material. ## Non-goals - Do not implement remote secret sync, cloud vault integrations, shared-device/multi-user secret sharing, or secret import/export. - Do not expose secret values through the future authoring IPC, HTTP, MCP, or in-app agent surfaces. - Do not change node-specific action configuration formats beyond replacing resolved values at the established runtime input boundary. ## Acceptance - A user can manage named variables and secrets in the app; variables persist as ordinary managed values, and secrets persist without appearing in workflow documents or subsequent read views. - A node can resolve an assigned variable through `vars.<name>` and a secret through `secrets.<name>` during execution. - A secret referenced by a workflow but not assigned to that workflow, or assigned only to a different node, produces a deterministic validation/execution failure and is unavailable to the node. - A workflow-level secret assignment makes the secret available to the workflow's nodes; a node-scoped assignment makes it available only to the selected node IDs. - Attempts to export, inspect, log, or return a secret through validation, execution history, errors, or test results return metadata/redaction only, never secret material. - Rename, deletion, and assignment changes preserve reference integrity: invalid references are surfaced before mutation, and no partial state is committed. - Focused tests cover namespace resolution, workflow- and node-scoped access, missing/unassigned failures, protected persistence, and redaction.

morten-olsen added the

feature

label

2026-09-17 08:19:57 +02:00