From 52f660c731d4099b51038c4da8c834498ee4a4e3 Mon Sep 17 00:00:00 2001
From: Pablo Vilas <pablovilas89@gmail.com>
Date: Wed, 2 Sep 2026 18:38:30 -0300
Subject: [PATCH] fix(k8s): register the update-scope action so scope edits run
 the update workflow

The k8s provider ships scope/workflows/update.yaml (create minus domain
generation, traced as "Update scope" / job k8s-scope-update) and the entrypoint
routes an action of type `update` to it, but specs/actions never declared one.
The orchestrator treats update as optional: with no action of type `update` on
the service it marks the scope active at once, so an edit never reached the
cluster and the dashboard had nothing to show for it.
---
 CHANGELOG.md                            |  3 +++
 README.md                               |  2 +-
 k8s/specs/actions/update-scope.json.tpl | 29 +++++++++++++++++++++++++
 k8s/specs/service-spec.json.tpl         |  1 +
 4 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 k8s/specs/actions/update-scope.json.tpl

diff --git a/CHANGELOG.md b/CHANGELOG.md
index b707a9e0..a607328e 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -5,6 +5,9 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [Unreleased]
+- Fix: editing a k8s scope now runs the provider's update workflow (networking, ingress and IAM re-applied from the new settings, with step-by-step progress in the dashboard). Before, the `update-scope` action was never registered, so an edit was marked active immediately without touching the cluster. Providers configured before this version need the new action registered once: `np service specification action specification create --serviceSpecificationId <id> --body "$(gomplate --file k8s/specs/actions/update-scope.json.tpl)"` with `SERVICE_SPECIFICATION_ID` set, or re-run `./configure`
+
 ## [1.16.1] - 2026-09-02
 - Fix: the Instances tab of the performance view now shows every pod of a k8s scope. The instance list had a hard cap of 10 that nothing could override, so a scope with 20 pods showed only the first 10 and the table had no next page. A `limit` in the request is honored, the `LIMIT` env var on the agent stays as the operator override, and with neither every pod is returned
 
diff --git a/README.md b/README.md
index d90cdbb1..3600af9f 100644
--- a/README.md
+++ b/README.md
@@ -73,7 +73,7 @@ Run the configuration script to register the scope schema, actions, and the agen
 
 The script will:
 -   Register the JSON schema for the selected scope (from `$SERVICE_PATH`).
--   Create action specifications (e.g., `create-scope`, `delete-scope`).
+-   Create action specifications (e.g., `create-scope`, `update-scope`, `delete-scope`).
 -   Register the scope type.
 -   Set up a notification channel for your agent.
 
diff --git a/k8s/specs/actions/update-scope.json.tpl b/k8s/specs/actions/update-scope.json.tpl
new file mode 100644
index 00000000..50d3aab2
--- /dev/null
+++ b/k8s/specs/actions/update-scope.json.tpl
@@ -0,0 +1,29 @@
+{
+  "name": "update-scope",
+  "slug": "update-scope",
+  "type": "update",
+  "retryable": false,
+  "service_specification_id": "{{ env.Getenv "SERVICE_SPECIFICATION_ID" }}",
+  "parameters": {
+    "schema": {
+      "type": "object",
+      "required": [
+        "scope_id"
+      ],
+      "properties": {
+        "scope_id": {
+          "type": "string"
+        }
+      }
+    },
+    "values": {}
+  },
+  "results": {
+    "schema": {
+      "type": "object",
+      "required": [],
+      "properties": {}
+    },
+    "values": {}
+  }
+}
diff --git a/k8s/specs/service-spec.json.tpl b/k8s/specs/service-spec.json.tpl
index 60763b89..2594a495 100644
--- a/k8s/specs/service-spec.json.tpl
+++ b/k8s/specs/service-spec.json.tpl
@@ -1,6 +1,7 @@
 {
   "available_actions": [
     "create-scope",
+    "update-scope",
     "delete-scope",
     "start-initial",
     "start-blue-green",