@stigmer/server 3.27.1 → 3.28.0

package/src/authorization/__tests__/fixtures/fga/reserved-label-writer.fga.yaml

@@ -1,41 +0,0 @@
-# Pinned copy of stigmer-cloud backend/services/stigmer-server/fga/tests/reserved-label-writer.fga.yaml
-# at commit b87dd1170 (the OpenFGA store test the cloud runs against its live model).
-# The body below is byte-identical to the source; the cloud re-runs the LIVE
-# file against this evaluator at the re-pin, so a stale copy is caught there.
-# Store tests for the reserved-label write permission (cloud#320).
-#
-# can_write_reserved_labels gates who may introduce or change labels in
-# the reserved stigmer.ai/* namespace at client-facing write boundaries
-# (GuardReservedLabelsStep). It derives from the platform operator role
-# — the seeding machine account holds it, ordinary tenants (even org
-# owners) never do, regardless of what they own.
-#
-# Run with:
-#   fga model test --tests reserved-label-writer.fga.yaml
-name: reserved-label-writer
-model_file: ../model/fga.mod
-
-tuples:
-  # The bootstrap machine account is the platform operator
-  # (BootstrapIdentitySeeder re-asserts this tuple on every boot).
-  - user: identity_account:machine
-    relation: operator
-    object: platform:stigmer
-
-  # A tenant org owner — owns everything in their org, nothing on the
-  # platform.
-  - user: identity_account:mallory
-    relation: owner
-    object: organization:acme
-
-tests:
-  - name: operator may write reserved labels, tenants may not
-    check:
-      - user: identity_account:machine
-        object: platform:stigmer
-        assertions:
-          can_write_reserved_labels: true
-      - user: identity_account:mallory
-        object: platform:stigmer
-        assertions:
-          can_write_reserved_labels: false

package/src/authorization/__tests__/fixtures/fga/schedule-owner.fga.yaml

@@ -1,113 +0,0 @@
-# Pinned copy of stigmer-cloud backend/services/stigmer-server/fga/tests/schedule-owner.fga.yaml
-# at commit b87dd1170 (the OpenFGA store test the cloud runs against its live model).
-# The body below is byte-identical to the source; the cloud re-runs the LIVE
-# file against this evaluator at the re-pin, so a stale copy is caught there.
-# Schedules are owner-scoped operational config (whatsapp-proactive-
-# messaging DD-008/DD-009, cloned from the agent_channel model): the
-# creator owns the schedule; view/edit/delete require ownership or an
-# explicit grant. Plain org members get NO implicit access — a schedule's
-# levers are billing-affecting (every fire spends the owning org's
-# credits, unattended). Creation is target-gated (can_edit on the
-# referenced agent, checked in-handler), so no organization-level
-# can_create_schedule relation exists to test.
-#
-# Org ADMINS inherit owner (T08, consistent with agents and channels — an
-# admin who can edit the agent can manage its schedules). The narrowness
-# these tests pin: owner + admins have control, granted viewers read,
-# plain members have nothing.
-#
-# Run: fga model test --tests schedule-owner.fga.yaml
-
-name: schedule-owner
-model_file: ../model/fga.mod
-
-tuples:
-  # Org membership for both accounts — proving membership grants nothing.
-  - user: identity_account:alice
-    relation: member
-    object: organization:acme
-  - user: identity_account:mallory
-    relation: member
-    object: organization:acme
-
-  # Org admin — proving T08 inheritance reaches schedules.
-  - user: identity_account:ana
-    relation: admin
-    object: organization:acme
-
-  # The schedule, created by alice (the config-driven create tuples).
-  - user: organization:acme
-    relation: organization
-    object: schedule:daily-fee-reminders
-  - user: identity_account:alice
-    relation: owner
-    object: schedule:daily-fee-reminders
-
-  # An explicit viewer grant to carol (not even an org member).
-  - user: identity_account:carol
-    relation: viewer
-    object: schedule:daily-fee-reminders
-
-tests:
-  - name: owner has full control including grant management
-    check:
-      - user: identity_account:alice
-        object: schedule:daily-fee-reminders
-        assertions:
-          can_view: true
-          can_edit: true
-          can_delete: true
-          can_grant_access: true
-          can_view_access: true
-
-  - name: explicitly granted viewer can read but not mutate
-    check:
-      - user: identity_account:carol
-        object: schedule:daily-fee-reminders
-        assertions:
-          can_view: true
-          can_edit: false
-          can_delete: false
-          can_grant_access: false
-          can_view_access: true
-
-  - name: fellow org member has no implicit access
-    check:
-      - user: identity_account:mallory
-        object: schedule:daily-fee-reminders
-        assertions:
-          can_view: false
-          can_edit: false
-          can_delete: false
-          can_grant_access: false
-          can_view_access: false
-
-  - name: org admin inherits schedule management (T08)
-    check:
-      - user: identity_account:ana
-        object: schedule:daily-fee-reminders
-        assertions:
-          can_view: true
-          can_edit: true
-          can_delete: true
-          can_grant_access: true
-
-  - name: listing schedules reflects ownership and grants, not membership
-    list_objects:
-      - user: identity_account:alice
-        type: schedule
-        assertions:
-          can_view:
-            - schedule:daily-fee-reminders
-          can_edit:
-            - schedule:daily-fee-reminders
-      - user: identity_account:carol
-        type: schedule
-        assertions:
-          can_view:
-            - schedule:daily-fee-reminders
-          can_edit: []
-      - user: identity_account:mallory
-        type: schedule
-        assertions:
-          can_view: []

package/src/authorization/__tests__/fixtures/fga/schedule-session-visibility.fga.yaml

@@ -1,214 +0,0 @@
-# Pinned copy of stigmer-cloud backend/services/stigmer-server/fga/tests/schedule-session-visibility.fga.yaml
-# at commit b87dd1170 (the OpenFGA store test the cloud runs against its live model).
-# The body below is byte-identical to the source; the cloud re-runs the LIVE
-# file against this evaluator at the re-pin, so a stale copy is caught there.
-# Store tests for schedule-session read-only observability (the session
-# `schedule` structural link — project DD-012 D-E, the channel-session
-# idiom's second application).
-#
-# A session created by the schedule runtime carries a single
-#   session#schedule@schedule:<id>
-# tuple and inherits the schedule's viewer set (creator owner + org admins
-# via `admin from organization` on schedule + explicit grantees) into
-# can_view ONLY — `viewer from schedule` is composed into session.can_view,
-# deliberately NOT into session.viewer, so schedule observers never gain
-# can_create_execution_in / can_edit / can_delete / can_grant_access
-# (injecting a console message into an unattended run is not
-# observability). Executions follow through agent_execution's
-# `can_view: viewer or can_view from session`.
-#
-# The personal-session invariant is untouched: console sessions never carry
-# a schedule tuple, so `viewer from schedule` resolves to nothing for them
-# (pinned below and by session-personal-resource.fga.yaml).
-#
-# Run with:
-#   fga model test --tests schedule-session-visibility.fga.yaml
-#
-# Scenario: org "acme" has admin alice, member bob (who created the
-# fee-reminder schedule and owns it), member carol (no relation to the
-# schedule), and member dave (an explicit schedule viewer grant — the
-# console "share this schedule" affordance). "rival" is another org whose
-# admin eve must see nothing. The schedule session is owned by acme's
-# system-schedule account; bob also has a normal personal console session
-# to prove the invariant.
-name: schedule-session-visibility
-model_file: ../model/fga.mod
-
-tuples:
-  # --- Org roles ---
-  - user: identity_account:alice
-    relation: admin
-    object: organization:acme
-  - user: identity_account:bob
-    relation: member
-    object: organization:acme
-  - user: identity_account:carol
-    relation: member
-    object: organization:acme
-  - user: identity_account:dave
-    relation: member
-    object: organization:acme
-  - user: identity_account:eve
-    relation: admin
-    object: organization:rival
-
-  # --- The Schedule (tuples written on create: org link + creator owner) ---
-  - user: organization:acme
-    relation: organization
-    object: schedule:fee-reminder
-  - user: identity_account:bob
-    relation: owner
-    object: schedule:fee-reminder
-  # dave's explicit viewer grant on the schedule (never on the session):
-  - user: identity_account:dave
-    relation: viewer
-    object: schedule:fee-reminder
-
-  # --- The schedule session (owned by the org's system-schedule account) ---
-  - user: organization:acme
-    relation: organization
-    object: session:scheduled-run
-  - user: identity_account:sys-schedule-acme
-    relation: owner
-    object: session:scheduled-run
-  # The structural link written by ScheduleSessionLinkStep:
-  - user: schedule:fee-reminder
-    relation: schedule
-    object: session:scheduled-run
-
-  # --- An execution inside the schedule session ---
-  - user: session:scheduled-run
-    relation: session
-    object: agent_execution:scheduled-run-1
-
-  # --- bob's ordinary personal console session (NO schedule tuple) ---
-  - user: organization:acme
-    relation: organization
-    object: session:bobs-chat
-  - user: identity_account:bob
-    relation: owner
-    object: session:bobs-chat
-  - user: session:bobs-chat
-    relation: session
-    object: agent_execution:bobs-run-1
-
-tests:
-  - name: schedule creator can view the run but only view it
-    check:
-      - user: identity_account:bob
-        object: session:scheduled-run
-        assertions:
-          can_view: true
-          can_create_execution_in: false
-          can_edit: false
-          can_delete: false
-          can_grant_access: false
-          can_view_access: false
-
-  - name: org admin inherits view through the schedule, read-only
-    check:
-      - user: identity_account:alice
-        object: session:scheduled-run
-        assertions:
-          can_view: true
-          can_create_execution_in: false
-          can_edit: false
-          can_delete: false
-          can_grant_access: false
-
-  - name: plain org member without schedule access sees nothing
-    check:
-      - user: identity_account:carol
-        object: session:scheduled-run
-        assertions:
-          can_view: false
-          can_create_execution_in: false
-
-  - name: another org's admin sees nothing
-    check:
-      - user: identity_account:eve
-        object: session:scheduled-run
-        assertions:
-          can_view: false
-
-  - name: the system-schedule account keeps full session ownership
-    check:
-      - user: identity_account:sys-schedule-acme
-        object: session:scheduled-run
-        assertions:
-          can_view: true
-          can_create_execution_in: true
-          can_edit: true
-          can_delete: true
-
-  - name: executions inherit read-only schedule observability
-    check:
-      - user: identity_account:bob
-        object: agent_execution:scheduled-run-1
-        assertions:
-          can_view: true
-          can_edit: false
-      - user: identity_account:alice
-        object: agent_execution:scheduled-run-1
-        assertions:
-          can_view: true
-          can_edit: false
-      - user: identity_account:carol
-        object: agent_execution:scheduled-run-1
-        assertions:
-          can_view: false
-
-  - name: an explicit schedule viewer grant reaches the run read-only
-    check:
-      # dave holds schedule viewer only — he can open the runs, still
-      # read-only, and gains nothing on the schedule's management levers.
-      - user: identity_account:dave
-        object: session:scheduled-run
-        assertions:
-          can_view: true
-          can_create_execution_in: false
-          can_edit: false
-      - user: identity_account:dave
-        object: agent_execution:scheduled-run-1
-        assertions:
-          can_view: true
-          can_edit: false
-
-  - name: personal-session invariant is untouched by the schedule model
-    check:
-      # Admin still has no path into a console session (no schedule tuple).
-      - user: identity_account:alice
-        object: session:bobs-chat
-        assertions:
-          can_view: false
-          can_edit: false
-          can_delete: false
-      - user: identity_account:alice
-        object: agent_execution:bobs-run-1
-        assertions:
-          can_view: false
-      # And the owner's own access is unchanged.
-      - user: identity_account:bob
-        object: session:bobs-chat
-        assertions:
-          can_view: true
-          can_edit: true
-          can_create_execution_in: true
-
-  - name: list viewable sessions resolves the schedule chain
-    list_objects:
-      - user: identity_account:alice
-        type: session
-        assertions:
-          can_view:
-            - session:scheduled-run
-      - user: identity_account:bob
-        type: session
-        assertions:
-          can_view:
-            - session:scheduled-run
-            - session:bobs-chat
-      - user: identity_account:carol
-        type: session
-        assertions:
-          can_view: []

package/src/authorization/__tests__/fixtures/fga/session-personal-resource.fga.yaml

@@ -1,117 +0,0 @@
-# Pinned copy of stigmer-cloud backend/services/stigmer-server/fga/tests/session-personal-resource.fga.yaml
-# at commit b87dd1170 (the OpenFGA store test the cloud runs against its live model).
-# The body below is byte-identical to the source; the cloud re-runs the LIVE
-# file against this evaluator at the re-pin, so a stale copy is caught there.
-# Store tests for the session personal-resource model, including owner
-# deletability (2026-07-08-owner-session-delete changelog entry).
-#
-# Sessions are always private: no visibility tuples are ever written, so
-# access is owner + explicit viewer grants only. Org admins have no implicit
-# access, and platform operators have no session-delete override — the
-# platform-level can_delete_session relation was removed in favor of
-# `can_delete: owner` on the session itself (deletion no longer threatens
-# the billing trail; usage records are immutable and denormalized).
-#
-# Agent executions inherit ALL access from their parent session
-# (`owner from session`), so the execution assertions here pin the
-# inheritance that session cascade-delete relies on.
-#
-# Run with:
-#   fga model test --tests session-personal-resource.fga.yaml
-#
-# Scenario: org "acme" has admin alice, member bob (session creator), and
-# member carol. dana is a platform operator with no relation to the session.
-name: session-personal-resource
-model_file: ../model/fga.mod
-
-tuples:
-  # --- Org roles ---
-  - user: identity_account:alice
-    relation: admin
-    object: organization:acme
-  - user: identity_account:bob
-    relation: member
-    object: organization:acme
-  - user: identity_account:carol
-    relation: member
-    object: organization:acme
-
-  # --- Platform operator (no relation to the session) ---
-  - user: identity_account:dana
-    relation: operator
-    object: platform:stigmer
-
-  # --- bob's session (tuples written on create) ---
-  - user: organization:acme
-    relation: organization
-    object: session:bobs-chat
-  - user: identity_account:bob
-    relation: owner
-    object: session:bobs-chat
-
-  # --- carol holds an explicit viewer grant on the session ---
-  - user: identity_account:carol
-    relation: viewer
-    object: session:bobs-chat
-
-  # --- an execution inside the session ---
-  - user: session:bobs-chat
-    relation: session
-    object: agent_execution:run-1
-
-tests:
-  - name: owner has full control including delete
-    check:
-      - user: identity_account:bob
-        object: session:bobs-chat
-        assertions:
-          can_view: true
-          can_edit: true
-          can_delete: true
-          can_create_execution_in: true
-          can_grant_access: true
-
-  - name: explicit viewer can view and run, but not edit or delete
-    check:
-      - user: identity_account:carol
-        object: session:bobs-chat
-        assertions:
-          can_view: true
-          can_create_execution_in: true
-          can_edit: false
-          can_delete: false
-          can_grant_access: false
-
-  - name: org admin has no implicit access to a personal session
-    check:
-      - user: identity_account:alice
-        object: session:bobs-chat
-        assertions:
-          can_view: false
-          can_edit: false
-          can_delete: false
-
-  - name: platform operator has no session-delete override
-    check:
-      - user: identity_account:dana
-        object: session:bobs-chat
-        assertions:
-          can_view: false
-          can_delete: false
-
-  - name: execution access is inherited from the parent session
-    check:
-      - user: identity_account:bob
-        object: agent_execution:run-1
-        assertions:
-          can_view: true
-          can_edit: true
-      - user: identity_account:carol
-        object: agent_execution:run-1
-        assertions:
-          can_view: true
-          can_edit: false
-      - user: identity_account:alice
-        object: agent_execution:run-1
-        assertions:
-          can_view: false

package/src/authorization/__tests__/fixtures/fga/workflow-execution-sharing.fga.yaml

@@ -1,190 +0,0 @@
-# Pinned copy of stigmer-cloud backend/services/stigmer-server/fga/tests/workflow-execution-sharing.fga.yaml
-# as changed by stigmer-cloud#765 (the OpenFGA store test the cloud runs against its live model).
-# The body below is byte-identical to the source; the cloud re-runs the LIVE
-# file against this evaluator at the re-pin, so a stale copy is caught there.
-# Store tests for workflow_execution sharing and run observability.
-#
-# Two independent axes govern who can read a run's inputs/outputs:
-#
-#   1. Per-execution sharing — the triggerer (owner) grants viewer on a single
-#      workflow_execution. Enabled by the new can_grant_access / can_view_access
-#      relations (mirrors session.fga).
-#   2. Instance-level run observability — opt-in via the workflow_instance's
-#      `execution_viewer` relation, inherited by every execution through
-#      `viewer = ... or execution_viewer from workflow_instance`.
-#
-# The critical invariant: making an instance org-RUNNABLE (instance#viewer for
-# org members) must NOT leak run history. Only execution_viewer does that.
-#
-# Run with:
-#   fga model test --tests workflow-execution-sharing.fga.yaml
-#
-# Scenario: org "acme" with members alice (triggerer), bob, carol; outsider
-# org with member mallory. inst1 is org-runnable but keeps runs private; inst2
-# opts into org-wide run observability.
-name: workflow-execution-sharing
-model_file: ../model/fga.mod
-
-tuples:
-  # --- Org memberships ---
-  - user: identity_account:alice
-    relation: member
-    object: organization:acme
-  - user: identity_account:bob
-    relation: member
-    object: organization:acme
-  - user: identity_account:carol
-    relation: member
-    object: organization:acme
-  - user: identity_account:vera
-    relation: viewer
-    object: organization:acme
-  - user: identity_account:mallory
-    relation: member
-    object: organization:outsider
-
-  # --- inst1: ORG-RUNNABLE instance, runs stay PRIVATE (no execution_viewer) ---
-  - user: organization:acme
-    relation: organization
-    object: workflow_instance:inst1
-  - user: identity_account:alice
-    relation: owner
-    object: workflow_instance:inst1
-  # Everyone in the org can SEE the instance (cloud#257 viewer shape;
-  # RUNNING it is additionally gated in Java on can_create_execution_in)...
-  - user: organization:acme#viewer
-    relation: viewer
-    object: workflow_instance:inst1
-  # ...but NO execution_viewer tuple, so run history is not shared.
-
-  # run1: alice's run on inst1, no explicit grants.
-  - user: organization:acme
-    relation: organization
-    object: workflow_execution:run1
-  - user: workflow_instance:inst1
-    relation: workflow_instance
-    object: workflow_execution:run1
-  - user: identity_account:alice
-    relation: owner
-    object: workflow_execution:run1
-
-  # run1b: alice's run on inst1, explicitly shared with bob (per-execution).
-  - user: organization:acme
-    relation: organization
-    object: workflow_execution:run1b
-  - user: workflow_instance:inst1
-    relation: workflow_instance
-    object: workflow_execution:run1b
-  - user: identity_account:alice
-    relation: owner
-    object: workflow_execution:run1b
-  - user: identity_account:bob
-    relation: viewer
-    object: workflow_execution:run1b
-
-  # --- inst2: opts into ORG-WIDE run observability (execution_viewer) ---
-  - user: organization:acme
-    relation: organization
-    object: workflow_instance:inst2
-  - user: identity_account:alice
-    relation: owner
-    object: workflow_instance:inst2
-  - user: organization:acme#viewer
-    relation: execution_viewer
-    object: workflow_instance:inst2
-
-  # run2: alice's run on inst2.
-  - user: organization:acme
-    relation: organization
-    object: workflow_execution:run2
-  - user: workflow_instance:inst2
-    relation: workflow_instance
-    object: workflow_execution:run2
-  - user: identity_account:alice
-    relation: owner
-    object: workflow_execution:run2
-
-tests:
-  - name: triggerer always sees and can manage sharing of their own run
-    check:
-      - user: identity_account:alice
-        object: workflow_execution:run1
-        assertions:
-          can_view: true
-          can_grant_access: true
-          can_view_access: true
-
-  - name: org-runnable instance does NOT leak run history to teammates
-    check:
-      # bob and carol can see/run inst1, but cannot read alice's run1.
-      - user: identity_account:bob
-        object: workflow_execution:run1
-        assertions:
-          can_view: false
-          can_view_access: false
-      - user: identity_account:carol
-        object: workflow_execution:run1
-        assertions:
-          can_view: false
-
-  - name: per-execution share grants exactly the named teammate
-    check:
-      - user: identity_account:bob
-        object: workflow_execution:run1b
-        assertions:
-          can_view: true
-          can_view_access: true
-      # A viewer cannot re-share (only the owner can grant).
-      - user: identity_account:bob
-        object: workflow_execution:run1b
-        assertions:
-          can_grant_access: false
-      # Another org member not on the grant sees nothing.
-      - user: identity_account:carol
-        object: workflow_execution:run1b
-        assertions:
-          can_view: false
-
-  - name: instance execution_viewer opt-in shares all runs org-wide
-    check:
-      - user: identity_account:bob
-        object: workflow_execution:run2
-        assertions:
-          can_view: true
-      - user: identity_account:carol
-        object: workflow_execution:run2
-        assertions:
-          can_view: true
-      # cloud#257: run observability is a pure read grant, so the org's
-      # read-only viewers are exactly its audience.
-      - user: identity_account:vera
-        object: workflow_execution:run2
-        assertions:
-          can_view: true
-      # Outsiders never gain access through org-scoped observability.
-      - user: identity_account:mallory
-        object: workflow_execution:run2
-        assertions:
-          can_view: false
-
-  - name: run privacy holds against org viewers exactly as against members
-    check:
-      # No execution_viewer opt-in on inst1 → vera reads the instance but
-      # never alice's run history.
-      - user: identity_account:vera
-        object: workflow_instance:inst1
-        assertions:
-          can_view: true
-      - user: identity_account:vera
-        object: workflow_execution:run1
-        assertions:
-          can_view: false
-
-  - name: list a teammate's viewable runs reflects both sharing axes
-    list_objects:
-      - user: identity_account:bob
-        type: workflow_execution
-        assertions:
-          can_view:
-            - workflow_execution:run1b
-            - workflow_execution:run2