@team-semicolon/semicolony-cli 4.18.106 → 4.18.107

package/migrations/203_ops_meetings_board_grant.sql

@@ -0,0 +1,45 @@
+-- 203_ops_meetings_board_grant.sql
+--
+-- Let the SEMO Ops control room read the team meeting record.
+--
+-- `/ops` reads `semo_ops` through the least-privilege `sc_fleet_board` role on a
+-- separate pool, and that role holds SELECT on fourteen tables — `meetings` not
+-- among them. Without this grant the meetings view fails with
+-- `permission denied for table meetings`, which is how the action-item and
+-- ontology cards failed in 196: a release gap, not a code bug.
+--
+-- SELECT only. The control room observes; every write goes through
+-- `record_meeting`, and the writer roles must not overlap with the board.
+--
+-- Unlike `knowledge_base`, `semo_ops.meetings` has RLS disabled, so there is no
+-- policy to extend and no silent-zero-rows failure mode here. The grant is the
+-- whole permission story, which also means **restriction is not enforced by the
+-- database for this table**: a `restricted` meeting is visible to any granted
+-- role, and the reading query must filter `visibility` itself. That is stated in
+-- semo-ops `docs/dashboard/code-and-authority-inventory-2026-08-13.md` and
+-- KB `semo-ops/process/meetings-visibility-enforcement`.
+--
+-- `action_items` is already granted (196), so meeting → action-item lookups need
+-- no further permission.
+--
+-- Safety: additive, SELECT only. The runner owns the transaction boundary, so no
+-- BEGIN/COMMIT here, and it retargets the `semicolony.` qualifier to the active
+-- schema.
+
+GRANT SELECT ON TABLE semicolony.meetings TO sc_fleet_board;
+
+DO $$
+DECLARE v_cols int;
+BEGIN
+  -- A table-level grant must cover every column; a partial grant would drop
+  -- fields from the view with no error at grant time.
+  SELECT count(*) INTO v_cols
+    FROM information_schema.role_column_grants
+   WHERE grantee = 'sc_fleet_board'
+     AND table_schema = current_schema()
+     AND table_name = 'meetings'
+     AND privilege_type = 'SELECT';
+  IF v_cols = 0 THEN
+    RAISE EXCEPTION 'sc_fleet_board did not receive SELECT on meetings';
+  END IF;
+END $$;

package/migrations/206_action_scope_narrow_dashboard.sql

@@ -0,0 +1,29 @@
+-- The semo-ops-dashboard credential gained action:read and action:write from
+-- 205's blanket scope amendment, but the dashboard never calls the Gateway's
+-- action routes -- it reads and writes semo_ops.action_items through direct
+-- queries in lib/core/action-items.ts. Measured 2026-08-14: zero occurrences
+-- of /action/list|create|update|get anywhere in packages/semicolony-dashboard.
+-- Take the unused scopes back.
+UPDATE semicolony.gateway_credentials
+   SET scopes = array_remove(array_remove(scopes, 'action:read'), 'action:write')
+ WHERE status = 'active'
+   AND metadata->>'device_id' = 'semo-ops-dashboard';
+
+DO $$
+DECLARE
+  remaining text[];
+BEGIN
+  SELECT scopes INTO remaining
+    FROM semicolony.gateway_credentials
+   WHERE status = 'active' AND metadata->>'device_id' = 'semo-ops-dashboard';
+
+  IF remaining IS NULL THEN
+    RAISE EXCEPTION 'semo-ops-dashboard credential not found or not active';
+  END IF;
+  IF 'workspace:assets-read' <> ALL(remaining) THEN
+    RAISE EXCEPTION 'workspace:assets-read was lost: %', remaining;
+  END IF;
+  IF 'action:read' = ANY(remaining) OR 'action:write' = ANY(remaining) THEN
+    RAISE EXCEPTION 'action scopes still present: %', remaining;
+  END IF;
+END $$;

package/migrations/207_action_grants_fleet_board.sql

@@ -0,0 +1,48 @@
+-- The dashboard's action-item surface moved off appdb.semicolony onto
+-- semo_ops (see KB semicolon decision
+-- semo-ops-dashboard-control-room-data-routing-2026-08-06, and the 42P01
+-- outage measured 2026-08-16). Its pool connects as sc_fleet_board, which
+-- held SELECT only. Writes still reach action_items exclusively through
+-- SECURITY DEFINER functions -- this grants EXECUTE on the three the
+-- dashboard calls (lib/core/action-items.ts: createActionItem,
+-- assignActionItem, operatorUpdateActionItem -- cancelActionItem delegates
+-- to operatorUpdateActionItem rather than calling its own function) and
+-- adds no direct DML. The other five surfaces that moved to the fleet pool
+-- in the same cutover (the /api/action-items roster query, /api/goals,
+-- /api/person/[domain], lib/plugins/service/kpi.ts, lib/tasks-db.ts) are
+-- read-only SELECTs against action_items/team_members/bot_commitments and
+-- call no function, so they need no grant here. No read path selects from
+-- action_item_events, so this migration does not grant SELECT on it either.
+GRANT EXECUTE ON FUNCTION semicolony.create_action_item(
+  p_description text, p_project_domain text, p_deadline date,
+  p_assignee_kind text, p_assignee_member text, p_assignee_agent text,
+  p_assignee_device text, p_priority text, p_source_kind text,
+  p_source_ref text, p_related_url text, p_external_contact text,
+  p_metadata jsonb, p_origin_surface text, p_origin_actor_kind text,
+  p_origin_member text, p_origin_agent text, p_origin_device text,
+  p_origin_harness text, p_origin_session_key text
+) TO sc_fleet_board;
+
+GRANT EXECUTE ON FUNCTION semicolony.assign_action_item(
+  p_action_item_id uuid, p_assignee_kind text, p_assignee_member text,
+  p_assignee_agent text, p_assignee_device text, p_actor_kind text,
+  p_actor_member text, p_actor_agent text
+) TO sc_fleet_board;
+
+GRANT EXECUTE ON FUNCTION semicolony.operator_update_action_item(
+  p_action_item_id uuid, p_status text, p_deadline date, p_note text,
+  p_metadata jsonb, p_actor_kind text, p_actor_member text,
+  p_actor_agent text
+) TO sc_fleet_board;
+
+DO $$
+BEGIN
+  IF EXISTS (
+    SELECT 1 FROM information_schema.table_privileges
+     WHERE grantee = 'sc_fleet_board' AND table_schema = 'semicolony'
+       AND table_name = 'action_items'
+       AND privilege_type IN ('INSERT','UPDATE','DELETE')
+  ) THEN
+    RAISE EXCEPTION 'sc_fleet_board must never hold direct DML on action_items';
+  END IF;
+END $$;

package/migrations/208_action_grants_fleet_board_guard_repair.sql

@@ -0,0 +1,45 @@
+-- 207_action_grants_fleet_board.sql shipped a safety-net guard that can never
+-- fire in the environment it targets:
+--
+--   WHERE grantee = 'sc_fleet_board' AND table_schema = 'semicolony' ...
+--
+-- `table_schema = 'semicolony'` is a string LITERAL compared against a column,
+-- not a schema-qualified identifier. `retargetSchemaSql`
+-- (packages/cli/src/commands/db.ts:35-44) rewrites `semicolony.` only when it
+-- qualifies an identifier (`semicolony.<name>`, matched by
+-- `(?<![\w./])semicolony\.`) -- a bare string literal with no trailing dot,
+-- like `'semicolony'` in a WHERE clause, is left untouched by design (see
+-- that function's own docstring, which names this exact pattern as excluded).
+-- This migration always runs with SEMICOLONY_DB_SCHEMA=semo_ops against
+-- team_knowledge_fabric, which has no `semicolony` schema at all -- so the
+-- guard's WHERE clause matched zero rows regardless of grant state, and the
+-- RAISE EXCEPTION was dead code. The invariant itself was never violated
+-- (verified separately, see task-3-report.md); only the safety net was inert.
+--
+-- Fix: drop the schema filter rather than try to make it retarget-aware.
+-- `current_schema()` was considered and rejected -- it happens to resolve to
+-- `semo_ops` for the role this migration currently runs as (that role's
+-- search_path defaults to `semo_ops, public, pg_catalog` in this database),
+-- but that is a property of the connecting role's search_path, not of
+-- SEMICOLONY_DB_SCHEMA, and would silently go back to matching nothing under
+-- a role without that search_path -- the same failure mode this migration
+-- exists to close. `action_items` is schema-unique in this database (checked
+-- against information_schema.tables across all schemas: exactly one row,
+-- semo_ops.action_items) so filtering on table_name alone is unambiguous
+-- today, and if a second action_items ever appears anywhere and picks up
+-- direct DML for sc_fleet_board, this guard should fire for that too -- a
+-- schema-agnostic check is the more conservative invariant, not a weaker one.
+--
+-- Record the trap for future authors: a bare string literal inside a WHERE
+-- clause is not an identifier and `retargetSchemaSql` will never rewrite it,
+-- by design, no matter how much it looks like a schema reference.
+DO $$
+BEGIN
+  IF EXISTS (
+    SELECT 1 FROM information_schema.table_privileges
+     WHERE grantee = 'sc_fleet_board' AND table_name = 'action_items'
+       AND privilege_type IN ('INSERT','UPDATE','DELETE')
+  ) THEN
+    RAISE EXCEPTION 'sc_fleet_board must never hold direct DML on action_items';
+  END IF;
+END $$;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@team-semicolon/semicolony-cli",
-  "version": "4.18.106",
+  "version": "4.18.107",
   "description": "SemiColony CLI - AI operations and agent orchestration installer",
   "main": "dist/bundle.js",
   "bin": {