Skip to main content
← Back to list
01Issue
FeatureIn ProgressSwamp CLIPublic
Assigneesstack72

Relationships

#3922 Datastore rework Phase 5: content-level authorisation for forwarded definition and evaluated-file writes

Opened by stack72 · 10/25/2026

Background

swamp-club#3915 adds serve's datastore API for team mode: clients forward v3 commits, and serve authorises each op on its intent. For some puts, serve's WebSocket handlers check more than write on the target:

  • Behavior and workflow definition edits:
    • a retag needs tag;
    • a rename needs write on the result;
    • the expressions an edit adds are authorised against what they reference (swamp-club#2755);
    • a workflow edit's added steps are authorised (authorizeWorkflowEdit).
  • Evaluated files: serve reads stored evaluated definitions back when it runs a behavior (loadEvaluatedDefinition in src/serve/deps.ts). A forged evaluated-definition.save could carry resolved values that skip the expression checks above.

A forwarded commit cannot be checked like that yet. So, in #3915, these puts need admin:

  • definition.create, definition.edit and definition.rename-to for behaviors, workflows and vaults. A vault is found by the name its content declares (YamlVaultConfigRepository.findByName), not by the intent's name, so a vault put authorised on one name could install a config under another;
  • evaluated-definition.save and evaluated-workflow.save;
  • auto-definition.save;
  • run-snapshot.save.

The list is CONTENT_CHECKED_PUTS in src/domain/datastore_v3/commit_authorization.ts.

What to build

Content-level parity for forwarded commits, so these puts need what serve's handlers need instead of admin:

  1. Make serve's content checks callable for a caller with no socket: the retag and rename authorisation, authorizeExpressionReferences and authorizeWorkflowEdit are socket-bound today. Run them on a forwarded definition put's before and after content.
  2. Decide how serve treats a forwarded evaluated definition, evaluated workflow or run snapshot. Either re-derive it on serve, or never trust a forwarded one when running. Then allow those puts for callers who may run the behavior or workflow.
  3. Tie a vault put's content to its intent: its declared name must equal the intent's (or the rename's matching side), and its id must equal the key's uuid. Then allow vault puts for callers with write on the vault.
  4. Allow auto-definition.save for callers who may run the behavior once its content is checked like direct execution's.

Done when

  • A non-admin can push a definition edit, and run a behavior through team mode (its data, outputs and evaluated definition commit together), with the same checks serve's handlers apply.
  • A test shows that each content check refuses a forwarded edit the WebSocket edit would refuse.
  • A forged evaluated definition cannot change what serve runs.

Blocked by: swamp-club#3915. This must land before the CLI's serve upstream lets non-admins run methods through team mode.

02Bog Flow
✓OPEN✓TRIAGED◉IN PROGRESS○SHIPPED+ 1 MOREASSIGNED+ 25 MOREREVIEW+ 1 MOREIMPLEMENTATION

In Progress

10/26/2026, 9:34:23 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack7210/26/2026, 8:31:21 PM

Sign in to post a ripple.