8000 feat(automations): saved variables, kept between runs and set by the set_variable action by adeelahmad · Pull Request #460 · adeelahmad/lense · GitHub
[go: up one dir, main page]

Skip to content

feat(automations): saved variables, kept between runs and set by the set_variable action - #460

Merged
adeelahmad merged 1 commit into
mainfrom
claude/project-thread-oi3om9
Oct 16, 2026
Merged

adeelahmad merged 1 commit into
mainfrom
claude/project-thread-oi3om9

Conversation

@adeelahmad
Copy link
Copy Markdown
Owner

Requested by Adeel · project thread

Workflow studio M9, part 2 of 3 (variables and templates): saved variables. Part 1 (#454, templates) is merged; the variable picker's catalog and preview come next.

Description

Before: vars in the run context was always empty. An automation had no way to keep a value between runs, such as a counter or when it last alerted.

After:

  • Saved variables (automation_var): an automation's own, or its namespace's, which every automation working there reads. A run reads them as vars.<name>, and the automation's own win on a name.
  • The set_variable action (group Run, effect self, so routine) can set, increment (default 1), append (keeping the last 100) or clear. Values are JSON up to 16 KB, and a scope holds at most 100 variables. Two runs writing at once both count, because a write that loses the race (CAS on rev) reads the value again. Namespace scope needs the automation's person to be an editor there.
  • Outside text: a variable set from a template that reads what the run got from outside Lens is marked untrusted. Later runs' prompts wrap it as outside text, and an action reading it counts as reading outside text. Other variables stay as written. This replaces part 1's default of marking every variable.
  • API:
    • GET/PUT /api/v1/automations/{id}/vars: for admins and whoever may change the automation; 404 otherwise.
    • GET/PUT /api/v1/namespaces/{name}/automation-vars: readers read, editors change.
    • PUT takes {"vars": {name: value}}, where null clears one, and audits the change.
  • MCP: automation_vars (read-only) and set_automation_vars (write scope). They are split like the other read and set tools, so clients can treat reading as safe.

Motivation and Context

Workflow studio, module M9 (brief workflow-studio/briefs/M9.md, item 4). It makes counters, "last alert at" values and lists shared between runs possible: {"action": "set_variable", "params": {"name": "door_opened", "op": "increment"}}, then {{ steps.count.value }}.

Defaults taken (reversible):

  • Automation variables use M6's rule for who manages an automation, read from the automation row directly until M6's API lands.
  • The MCP tool is split into read and write tools, matching the repo's other x / set_x pairs.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change; ! in the title)

Checklist:

  • The title is a Conventional Commit.
  • My code follows the code style of this project (make hooks checks it on commit).
  • I added or updated tests (tests/api/test_automation_vars.py, the MCP tool list in tests/api/test_mcp.py).
  • My change requires documentation updates, and I have updated docs/ accordingly: docs/automations.md (Saved variables, a counter example), docs/api.md, docs/mcp.md and docs/database.md. I also fixed table cells whose \| pipes showed a backslash.
  • Users need more than the title to understand it, so I wrote it under ## Unreleased in CHANGELOG.md. (n/a)

Done questions (AGENTS.md)

  • Goal: part 2 of 3 of M9. It merges when CI is green.
  • Agents: the automation_vars and set_automation_vars MCP tools, the REST API, and the set_variable action that agents can put in automations.
  • Zero setup: no new prerequisite; the table is defined at start (IF NOT EXISTS).
  • Fewest clicks: one PUT sets several values, and null clears one. The builder's Variables tab comes with M11.
  • Configurable: n/a. The caps (16 KB, 100 items, 100 variables) are fixed limits like other actions'.
  • Light: a small SurrealDB table, with no new dependency.
  • Private and secure: variables stay in the local database. Access follows namespace roles. Outside text stays marked across runs, which is a new line in P-INJECTION-EGRESS in the threat model.
  • Cost: n/a, no model calls.
  • User decides: routine actions only change the automation's own state. No variable exists until an automation or a person sets one.
  • Upgrades: it adds a new table only, so existing data is unchanged.
  • Honest: the docs status table marks saved variables built and the picker/preview planned.
  • Tests and docs updated, and the client regenerated with make openapi.
  • Open standards: JSON values, with no new dependencies.
  • Refine later items are written in docs/automations.md: secrets, typed declarations, an activity when a person changes one, finer marking, and removing an automation's variables when it is deleted (M6).

🤖 Generated with Claude Code

https://claude.ai/code/session_01JZDyxMfCBYNRw12CHqE9ss


Generated by Claude Code

…set_variable action

An automation's own variables and its namespace's, read as vars in the run context; the set_variable action (set,
increment, append to the last 100, clear) with writes that race read the value again; the API and the
automation_vars and set_automation_vars MCP tools. A variable set from a template reading outside text stays marked
in later runs' prompts.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JZDyxMfCBYNRw12CHqE9ss
@adeelahmad adeelahmad self-assigned this Oct 16, 2026
@adeelahmad
adeelahmad merged commit a3be527 into main Oct 16, 2026
11 checks passed
@adeelahmad
adeelahmad deleted the claude/project-thread-oi3om9 branch October 16, 2026 02:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

0