[MINOR] chore: merge develop to main

.claude/skills/gitnexus/gitnexus-cli/SKILL.md

@@ -23,7 +23,7 @@ Run from the project root. This parses all source files, builds the knowledge gr
 | `--embeddings` | Enable embedding generation for semantic search (off by default) |
 | `--drop-embeddings` | Drop existing embeddings on rebuild. By default, an `analyze` without `--embeddings` preserves them. |
 
-**When to run:** First time in a project, after major code changes, or when `gitnexus://repo/{name}/context` reports the index is stale. In Claude Code, a PostToolUse hook runs `analyze` automatically after `git commit` and `git merge`, preserving embeddings if previously generated.
+**When to run:** First time in a project, after major code changes, or when `gitnexus://repo/{name}/context` reports the index is stale. In Claude Code, a PostToolUse hook detects staleness after `git commit` and `git merge` and notifies the agent to run `analyze` — the hook does not run analyze itself, to avoid blocking the agent for up to 120s and risking KuzuDB corruption on timeout.
 
 ### status — Check index freshness
 

AGENTS.md

@@ -80,7 +80,7 @@ Ask. Refusing to act is always safer than taking an action that bypasses these r
 <!-- gitnexus:start -->
 # GitNexus — Code Intelligence
 
-This project is indexed by GitNexus as **supervaizer** (4837 symbols, 7278 relationships, 93 execution flows). Use the GitNexus MCP tools to understand code, assess impact, and navigate safely.
+This project is indexed by GitNexus as **supervaizer** (6117 symbols, 11434 relationships, 278 execution flows). Use the GitNexus MCP tools to understand code, assess impact, and navigate safely.
 
 > If any GitNexus tool warns the index is stale, run `npx gitnexus analyze` in terminal first.
 

docs/2026_05_PROTOCOLS.md

@@ -1,7 +1,7 @@
 # Protocol Support
 
 > **Created:** 2025-08-06
-> **Updated:** 2026-05-17
+> **Updated:** 2026-05-18
 
 SUPERVAIZER uses several protocol layers. They are related, but they do different jobs:
 
@@ -49,6 +49,14 @@ When an agent declares `supervaizer_v2_registration`, its A2A Agent Card include
 
 This extension does **not** replace the existing Studio server-registration trust model. Studio registration still owns server identity, public key exchange, and encrypted payload handling. The A2A Agent Card advertises the v2 operational contract after the controller is known.
 
+### Workspace Authorization
+
+Workspace and tenant slugs are not enough to authorize shared-agent access. A Supervaizer v2 controller should treat them as display and routing hints only.
+
+The planned shared-agent model uses a Studio-owned Workspace Agent Grant and a short-lived Studio-signed workspace authorization token. Studio sends the token with Studio-to-agent requests, and the Supervaizer SDK verifies it before dispatching handlers. This lets stateless agents safely serve multiple workspaces without storing grant state locally.
+
+See [2026_05_WORKSPACE_AGENT_GRANTS.md](2026_05_WORKSPACE_AGENT_GRANTS.md).
+
 ### Supervaizer v2 JSON-RPC Methods
 
 Supervaizer v2 currently exposes two A2A JSON-RPC methods:
@@ -60,6 +68,12 @@ Supervaizer v2 currently exposes two A2A JSON-RPC methods:
 
 Both methods are scoped by `agent_slug`. In multi-agent controllers, handlers must be registered for the correct agent slug.
 
+Workspace-scoped calls require a Studio-signed workspace authorization token.
+The only bootstrap exceptions are `workspace_binding.*` actions and the
+`workspace_binding.create` surface. These calls are used before a Workspace
+Agent Grant exists, so they require normal Studio-to-agent transport
+authentication but not a workspace authorization token.
+
 ### Transport Status
 
 The current MVP advertises:

docs/2026_05_SUPERVAIZER_v2.md

@@ -2,7 +2,7 @@
 
 
 > **Created:** 2026-05-16
-> **Updated:** 2026-05-17
+> **Updated:** 2026-05-18
 
 Supervaizer v2 is the new operation contract between an agent controller and Supervaize Studio.
 
@@ -102,6 +102,24 @@ The v2 registration is exposed in the A2A Agent Card under `supervaizer.v2`.
 
 This does not replace the existing Studio server registration process. Server identity, public key exchange, and encrypted payload handling still belong to the normal Studio registration path. The v2 extension tells Studio how to operate the already-registered controller.
 
+## Workspace Authorization
+
+Workspace slugs and tenant slugs are not authorization primitives. They are display and routing hints only.
+
+When Studio operates an agent shared into another workspace, Studio must prove that the recipient workspace admin accepted the agent. The planned v2 model is a Studio-owned Workspace Agent Grant plus a short-lived Studio-signed workspace authorization token on each Studio-to-agent request.
+
+Agents may be stateless. They do not need to persist grants locally. The agent verifies the token on every request and uses the verified grant context for resource access, dataset queries, `job.start`, `job.sync`, artifacts, and HITL actions.
+
+If an agent requires an agent-side record before accepting a workspace, it can
+declare `workspace_binding` in its v2 registration. Supervaizer treats
+`workspace_binding.*` actions and the `workspace_binding.create` surface as
+bootstrap capabilities: they still require Studio-to-agent transport
+authentication, but they run before a workspace authorization token exists. All
+other workspace-scoped actions and surfaces fail closed without a valid
+workspace authorization token.
+
+See [2026_05_WORKSPACE_AGENT_GRANTS.md](2026_05_WORKSPACE_AGENT_GRANTS.md) for the implementation plan.
+
 ## Runtime Handlers
 
 Agents register action and surface handlers on the `Server`.