@tideorg/mcp 1.4.2 → 1.9.1

package/reference-apps/iga-admin-governance/anti-patterns.md

@@ -14,43 +14,45 @@ Scenario-specific mistakes for IGA admin governance panels. General Tide anti-pa
 
 ---
 
-## AP-G02: Using JSON for add-review or add-rejection
+> Endpoints use the current `/iga/change-requests/...` surface (GAP-065). Full spec: `canon/iga-change-requests-api.md`.
 
-**Mistake**: Sending `application/json` to `/tideAdminResources/add-review` or `/tideAdminResources/add-rejection`.
+## AP-G02: Treating authorize as commit
 
-**Why it fails**: These endpoints require `multipart/form-data`. JSON submissions return 415 or are silently ignored.
+**Mistake**: Calling only `POST /iga/change-requests/{id}/authorize` and assuming the change is applied.
 
-**Fix**: Use `FormData` for add-review and add-rejection. All other mutation endpoints (sign/batch, commit/batch, cancel/batch) use JSON.
+**Why it fails**: `authorize` records an approval. The change does not take effect until `POST /iga/change-requests/{id}/commit` is called, and commit returns **412** until `readyToCommit` (threshold met, dependencies committed).
+
+**Fix**: After `authorize` succeeds, poll for `readyToCommit === true`, then `commit`. During bootstrap, `bulk-authorize` then commit ready CRs in dependency passes.
 
 ---
 
-## AP-G03: Treating sign as commit
+## AP-G03: Re-signing the same CR with the same admin
 
-**Mistake**: Calling only `sign/batch` and assuming the change is applied.
+**Mistake**: Retrying `authorize` on a CR the same admin already signed.
 
-**Why it fails**: Signing records an approval. The change does not take effect until `commit/batch` is called after the quorum threshold is met.
+**Why it fails**: Four-eyes enforcement returns **409 Conflict** — one admin cannot count twice toward the threshold.
 
-**Fix**: After sign succeeds and approval count >= threshold, call `commit/batch`.
+**Fix**: Have a *different* admin authorize. If you get 409, refresh the CR (`GET /iga/change-requests/{id}`) — it may already be signed or no longer PENDING.
 
 ---
 
-## AP-G04: Caching change-set counts across mutations
+## AP-G04: Stale pending list across mutations
 
-**Mistake**: Fetching counts once and not refreshing after sign, commit, or cancel.
+**Mistake**: Fetching the pending list once and not refreshing after authorize/commit/deny.
 
-**Why it fails**: Counts change after every mutation. Stale counts cause the UI to show incorrect badge numbers and confuse admins.
+**Why it fails**: `status` and `readyToCommit` change after every action. Stale data drives wrong badge counts and lets the UI offer commit on a CR that is not ready (→ 412).
 
-**Fix**: Refresh counts after every mutation (sign, commit, cancel, add-review, add-rejection).
+**Fix**: Re-fetch `GET /iga/change-requests?status=PENDING` after every mutation and recompute counts/badges from it.
 
 ---
 
-## AP-G05: Ignoring enclave challenge in MultiAdmin mode
+## AP-G05: Skipping the enclave step in Tide MultiAdmin mode
 
-**Mistake**: Not handling the enclave approval popup when multiple admins exist. The sign response indicates `requiresApprovalPopup: true` but the app treats it as a normal success.
+**Mistake**: Calling a bare `authorize` in Tide MultiAdmin mode and treating the response as done.
 
-**Why it fails**: In MultiAdmin mode, `sign/batch` returns an enclave challenge (base64 `changeSetDraftRequests`). The admin must sign this in the enclave popup and submit via `add-review`. Without this, the approval is not recorded.
+**Why it fails**: In Tide MultiAdmin mode the approval is cryptographic — a bare `authorize` does not record it. The admin must complete the two-phase enclave exchange: `GET /iga/change-requests/{id}/approval-model` → sign the `requestModel` in the enclave → `POST /iga/change-requests/{id}/approval-model` with `{ requestModel }`.
 
-**Fix**: Check the sign response for `requiresApprovalPopup`. If true, present the enclave challenge to the admin and submit the result via `add-review` (FormData).
+**Fix**: In MultiAdmin mode, drive the `approval-model` exchange and confirm `recorded: true` / an increased `authCount`. FirstAdmin/Tideless mode signs server-side on `authorize` — no enclave step.
 
 ---
 

package/reference-apps/iga-admin-governance/bootstrap-sequence.md

@@ -50,12 +50,17 @@
      -d "isIGAEnabled=true"
    ```
 
-6. Approve/commit initial client change request:
+6. Approve/commit initial change requests (current `/iga/change-requests/...` surface; see `canon/iga-change-requests-api.md`):
    ```bash
-   # Get pending client changes
-   CLIENTS=$(curl -s "http://localhost:8080/admin/realms/$REALM/tide-admin/change-set/clients/requests" \
-     -H "Authorization: Bearer $TOKEN")
-   # Extract changeSets array, then sign and commit
+   # Authorize all pending, then commit ready ones (FirstAdmin bootstrap signs server-side)
+   curl -s -X POST "http://localhost:8080/admin/realms/$REALM/iga/change-requests/bulk-authorize" \
+     -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
+     -d '{"actionTypeIn":["CREATE","DELETE"],"limit":100}'
+   for id in $(curl -s "http://localhost:8080/admin/realms/$REALM/iga/change-requests?status=PENDING" \
+       -H "Authorization: Bearer $TOKEN" | jq -r '.[] | select(.readyToCommit==true) | .id'); do
+     curl -s -X POST "http://localhost:8080/admin/realms/$REALM/iga/change-requests/$id/commit" \
+       -H "Authorization: Bearer $TOKEN"
+   done
    ```
 
 ---

package/reference-apps/iga-admin-governance/role-policy-matrix.md

@@ -49,19 +49,18 @@ The governance panel may optionally include policy management. These are NOT req
 
 ---
 
-## Change-Set Endpoints (core governance)
+## Change-Request Endpoints (core governance)
+
+Current `/iga/change-requests/...` surface (replaces legacy `/tide-admin/change-set/...`, GAP-065). **Full spec: `canon/iga-change-requests-api.md`.**
 
 | Operation | Endpoint | Method | Content-Type | Notes |
 |-----------|---------|--------|-------------|-------|
-| List counts | `/tide-admin/change-set/counts` | GET | — | Returns per-type counts |
-| List all requests | `/tide-admin/change-set/all/requests` | GET | — | Returns all pending changes grouped by type |
-| List by type | `/tide-admin/change-set/{type}/requests` | GET | — | `{type}` = users, roles, clients, groups |
-| Sign (approve) | `/tide-admin/change-set/sign/batch` | POST | `application/json` | Body: `{ changeSets: [...] }` |
-| Commit | `/tide-admin/change-set/commit/batch` | POST | `application/json` | Body: `{ changeSets: [...] }` |
-| Cancel | `/tide-admin/change-set/cancel/batch` | POST | `application/json` | Body: `{ changeSets: [...] }` |
-| Add review (enclave) | `/tideAdminResources/add-review` | POST | **`multipart/form-data`** | Used after enclave challenge in MultiAdmin mode |
-| Add rejection | `/tideAdminResources/add-rejection` | POST | **`multipart/form-data`** | Content-type asymmetry: NOT JSON |
-| Activity | `/tide-admin/change-set/{id}/activity` | GET | — | Returns approvals, rejections, comments |
-| Add comment | `/tide-admin/change-set/{id}/comments` | POST | `application/json` | |
-| Licensing requests | `/tideAdminResources/change-set/licensing/requests` | GET | — | Different path prefix from other types |
-| Ragnarok requests | `/ragnarok/change-set/offboarding/requests` | GET | — | Different path prefix |
+| List | `/iga/change-requests?status=PENDING` | GET | — | Objects keyed by `id`; `status` = PENDING/APPROVED/DENIED/CANCELLED. Derive counts from the list. |
+| Get one | `/iga/change-requests/{id}` | GET | — | Full CR (`entityType`, `readyToCommit`, `threshold`, `dependsOn`) |
+| Authorize (approve) | `/iga/change-requests/{id}/authorize` | POST | `application/json` | Body `{}` optional. 409 = four-eyes re-sign |
+| Bulk authorize | `/iga/change-requests/bulk-authorize` | POST | `application/json` | `{ "actionTypeIn": ["CREATE","DELETE"], "limit": 100 }`; 429 if a bulk run is active |
+| Commit | `/iga/change-requests/{id}/commit` | POST | — | 412 if under threshold / unmet dependency |
+| Deny (reject) | `/iga/change-requests/{id}/deny` | POST | — | → 204 |
+| Enclave sign (Tide MultiAdmin) | `/iga/change-requests/{id}/approval-model` | GET/POST | `application/json` | Two-phase: GET challenge → POST `{ requestModel }` |
+| Comments | `/iga/change-requests/{id}/comments` | GET/POST | `application/json` | `{ "comment": "..." }` (≤2000) |
+| Manual ADOPT | `/iga/adopt` | POST | `application/json` | `{ "entityType": "USER", "entityId": "..." }` |

package/reference-apps/iga-admin-governance/scenario.md

@@ -72,17 +72,18 @@ These happen before any admin uses the governance panel:
 
 Once bootstrap is complete, the governance panel operates as follows:
 
+Endpoints use the current `/iga/change-requests/...` surface (replaces legacy `/tide-admin/change-set/...`, GAP-065; full spec `canon/iga-change-requests-api.md`).
+
 1. Admin logs in via TideCloak SSO (DPoP-bound)
-2. Panel fetches change-set counts (`GET /tide-admin/change-set/counts`)
-3. Panel lists pending requests by type (users, roles, groups, clients, settings, policies)
+2. Panel lists pending requests (`GET /iga/change-requests?status=PENDING`) and derives counts
+3. Panel groups pending CRs by `entityType` (users, roles, groups, clients, settings, policies)
 4. Admin reviews a change request's details, activity, and comments
-5. Admin approves: `POST /tide-admin/change-set/sign/batch` (JSON body)
-   - If MultiAdmin: enclave challenge popup appears; admin signs and submits via `POST /tideAdminResources/add-review` (**multipart/form-data**, not JSON)
-   - If FirstAdmin: signed immediately with VRK
-6. When approval count >= quorum threshold: `POST /tide-admin/change-set/commit/batch`
-7. Admin can cancel pending requests: `POST /tide-admin/change-set/cancel/batch`
-8. Admin can reject: `POST /tideAdminResources/add-rejection` (**multipart/form-data**)
-9. Admin can add/edit/delete comments on change requests
+5. Admin approves: `POST /iga/change-requests/{id}/authorize` (body `{}`; 409 = four-eyes)
+   - If Tide MultiAdmin: complete the two-phase `GET`/`POST /iga/change-requests/{id}/approval-model` enclave exchange
+   - If FirstAdmin/Tideless: signed server-side immediately
+6. When `readyToCommit`: `POST /iga/change-requests/{id}/commit` (412 if under threshold)
+7. Admin can reject: `POST /iga/change-requests/{id}/deny`
+8. Admin can add/edit/delete comments on change requests
 
 ---
 
@@ -104,10 +105,11 @@ Once bootstrap is complete, the governance panel operates as follows:
 
 | Symptom | Likely cause | Fix |
 |---------|-------------|-----|
-| Sign returns 401 | Token expired or DPoP not attached | Re-login; ensure `secureFetch` with DPoP |
-| Sign returns enclave challenge (MultiAdmin) | Multiple admins exist | Handle popup flow via `add-review` endpoint |
-| Commit returns error | Not all required approvals met | Check approval count vs quorum threshold |
-| Change request stays PENDING after sign | Missing commit step | Call `commit/batch` after sign succeeds |
+| Authorize returns 401 | Token expired or DPoP not attached | Re-login; ensure `secureFetch` with DPoP |
+| Authorize returns 409 | Same admin re-signing (four-eyes) or CR not PENDING | Use a different admin; refresh the list |
+| MultiAdmin: authorize does not record | Enclave step skipped | Complete `{id}/approval-model` two-phase exchange |
+| Commit returns 412 | Under threshold / unmet dependency | Collect more approvals; commit `dependsOn` CR first |
+| Change request stays PENDING after authorize | Missing commit step | Call `{id}/commit` once `readyToCommit` |
 | add-review returns 415 | Wrong content-type | Use `multipart/form-data`, not JSON |
 | Counts don't update after commit | Stale data | Refresh counts after every mutation |
 | Policy change requests don't appear | Realm policy not in pending state | Create pending realm policy first via `/tide-admin/realm-policy/pending` |

package/reference-apps/organisation-password-manager/bootstrap-sequence.md

@@ -48,12 +48,11 @@ All steps must complete before users can safely use the app. Order matters.
 
 ## Phase 4: Change-set approval
 
-10. **Approve pending change-sets**
-    - IGA creates draft change-sets for client and user mutations made during setup.
-    - List: `GET /admin/realms/{realm}/tide-admin/change-set/{type}/requests` for types `clients`, `users`.
-    - For each pending change-set:
-      - Sign: `POST /admin/realms/{realm}/tide-admin/change-set/sign` (requires admin doken).
-      - Commit: `POST /admin/realms/{realm}/tide-admin/change-set/commit`.
+10. **Approve pending change requests** (current `/iga/change-requests/...` surface — see `canon/iga-change-requests-api.md`)
+    - IGA creates draft change requests for client and user mutations made during setup (each mutating write returns 202).
+    - List: `GET /admin/realms/{realm}/iga/change-requests?status=PENDING` (objects keyed by `id`).
+    - Approve: `POST /admin/realms/{realm}/iga/change-requests/bulk-authorize` (`{"actionTypeIn":["CREATE","DELETE"],"limit":100}`; FirstAdmin signs server-side).
+    - Commit: `POST /admin/realms/{realm}/iga/change-requests/{id}/commit` for each `readyToCommit` CR.
     - Without this step, client and user changes are in draft state and not active.
 
 ## Phase 5: IDP settings and adapter export

package/reference-apps/policy-governed-signing/bootstrap-sequence.md

@@ -28,12 +28,12 @@ All steps must complete before users can safely use signing features. Order matt
    - `POST /admin/realms/{realm}/tide-admin/toggle-iga` with form-urlencoded `isIGAEnabled=true`.
    - Must happen after licensing. Enables change-set governance for role/user mutations.
 
-## Phase 3: Approve initial change-sets
+## Phase 3: Approve initial change requests
 
-6. **Approve client change-sets**
-   - IGA creates draft change-sets for client mutations during realm import.
-   - List: `GET /admin/realms/{realm}/tide-admin/change-set/clients/requests`.
-   - For each: sign (`POST .../change-set/sign`) then commit (`POST .../change-set/commit`).
+6. **Approve initial change requests** (current `/iga/change-requests/...` surface — see `canon/iga-change-requests-api.md`)
+   - IGA creates draft change requests for client/role mutations during realm import (each mutating write returns 202).
+   - List: `GET /admin/realms/{realm}/iga/change-requests?status=PENDING` (objects keyed by `id`).
+   - Approve: `POST /admin/realms/{realm}/iga/change-requests/bulk-authorize` (`{"actionTypeIn":["CREATE","DELETE"],"limit":100}`), then `POST /admin/realms/{realm}/iga/change-requests/{id}/commit` for each `readyToCommit` CR. FirstAdmin bootstrap signs server-side.
 
 ## Phase 4: Admin user setup
 
@@ -52,11 +52,11 @@ All steps must complete before users can safely use signing features. Order matt
     - Poll `GET /admin/realms/{realm}/users/{userId}` until `attributes.tideUserKey` and `attributes.vuid` are present.
     - Do not proceed until both attributes exist.
 
-## Phase 5: Approve user change-sets
+## Phase 5: Approve user change requests
 
-11. **Approve user change-sets**
-    - List: `GET /admin/realms/{realm}/tide-admin/change-set/users/requests`.
-    - For each: sign then commit.
+11. **Approve user change requests**
+    - List: `GET /admin/realms/{realm}/iga/change-requests?status=PENDING`.
+    - Authorize then commit (see Phase 3 / `canon/iga-change-requests-api.md`).
 
 ## Phase 6: IDP settings and adapter export
 

package/skills/tide-diagnostics/SKILL.md

@@ -54,7 +54,7 @@ Troubleshoot broken Tide integrations. Own login failures, missing roles/claims,
 |---------|-------------|----------|
 | Login hangs or blank screen | CSP missing `frame-src '*'`, redirect handler missing, DPoP auth page missing | `diagnose-broken-login` |
 | Login redirect loop | `@tidecloak/react` ESM alias missing (AP-42), provider not wired | `diagnose-broken-login` |
-| DPoP login fails | `tide_dpop_auth.html` missing or dynamic route not configured (I-12, L-07) | `diagnose-broken-login` |
+| DPoP login fails | `tide_dpop_auth.html` missing, or its `app/tide_dpop/[...path]/route.ts` catch-all route handler / hash-pinned CSP / `Allow-CSP-From: *` header not configured (I-12, L-07) | `diagnose-broken-login` |
 | 401 on all API calls | JWT verification not implemented, or DPoP proof missing | `diagnose-missing-roles-or-claims` |
 | 403 on API calls | Role not assigned, IGA change-set not committed, or 120s refresh delay | `diagnose-missing-roles-or-claims` |
 | Roles missing from JWT | IGA change-set not committed, token not refreshed (up to 120s) | `diagnose-missing-roles-or-claims` |

package/skills/tide-integration/SKILL.md

@@ -17,11 +17,11 @@ Wire the Tide SDK into the application. Own SDK installation, provider setup, co
 | `tidecloak.json` placement and import | `tide-setup` if file doesn't exist and TideCloak not bootstrapped |
 | `silent-check-sso.html` in `public/` | — |
 | Post-auth redirect handler (`auth/redirect/page.tsx`) | — |
-| `tide_dpop_auth.html` + `next.config.ts` rewrites + DPoP headers (I-12) | — |
+| `tide_dpop_auth.html` served via a `app/tide_dpop/[...path]/route.ts` catch-all route handler + DPoP headers (I-12) | — |
 | CSP (`frame-src '*'`) in `next.config` headers | — |
 | Webpack workarounds (`strictExportPresence`, `@tidecloak/react` ESM alias) | — |
 | Retrofit into existing apps | — |
-| Server-side delegation setup (`@tidecloak/server`, `createTideFetch`) | — |
+| ASP.NET Core (.NET 10) backend via `Tide.Asgard.AspNetCore` SDK | Follow [playbooks/protect-aspnet-core-asgard.md](../../playbooks/protect-aspnet-core-asgard.md). Out of scope for the Next.js/React/Vanilla priority — do not invent OIDC wiring; route to that playbook. |
 | Route/API protection | `tide-route-and-api-protection` |
 | Roles, RBAC, encryption | `tide-rbac-and-e2ee` |
 | TideCloak bootstrap, realm, licensing | `tide-setup` |
@@ -35,6 +35,7 @@ Wire the Tide SDK into the application. Own SDK installation, provider setup, co
 - `tide-setup` detected hardening gaps (Path D)
 - User asks to "add Tide to my app" or "add login"
 - Orchestrator routed here after bootstrap is confirmed
+- User asks about adding Tide auth to an **ASP.NET Core / C# / .NET** API. Route directly to [playbooks/protect-aspnet-core-asgard.md](../../playbooks/protect-aspnet-core-asgard.md) — do not attempt to retrofit Node-side guidance.
 
 ### Scenario-disambiguation gate (I-17)
 
@@ -71,8 +72,8 @@ Follow playbook `add-auth-nextjs-fresh`:
 3. Place `tidecloak.json` at correct path (`data/` for Next.js, `public/` for React/Vite)
 4. Create `public/silent-check-sso.html`
 5. Create post-auth redirect handler at `auth/redirect/page.tsx`
-6. Copy `tide_dpop_auth.html` to `public/` and add `rewrites()` + DPoP-specific `headers()` in `next.config.ts` (I-12). Do NOT use a route handler.
-7. Configure CSP: `frame-src '*'` in `next.config` headers (global); `script-src 'unsafe-inline'` on `/tide_dpop/:path*` only
+6. Copy `tide_dpop_auth.html` to `public/` and serve it via a catch-all route handler at `app/tide_dpop/[...path]/route.ts` (matches the shipped `@tidecloak/create-nextjs` scaffold; I-12). The handler reads the single bundled `public/tide_dpop_auth.html` and returns it for any `/tide_dpop/...` path. Do NOT use `next.config.ts` rewrites for this.
+7. On that route handler's response, set a **sha256 hash-pinned** CSP (pin the file's inline `script`/`style` via `sha256-...` hashes — NOT `script-src 'unsafe-inline'`) plus an `Allow-CSP-From: *` header (lets the ORK embed the page cross-origin). Global CSP stays `frame-src '*'` in `next.config` headers.
 8. Add webpack workarounds to `next.config.ts`: `strictExportPresence = false` + `@tidecloak/react` ESM alias
 
 ### Existing app (has other auth)
@@ -82,16 +83,6 @@ Follow playbook `add-auth-nextjs-existing`:
 2. Replace existing auth provider with `TideCloakProvider`
 3. Remove old auth (NextAuth, Clerk, etc.) after Tide is working
 
-### Server-side delegation
-
-Follow playbook `setup-server-delegation`:
-1. Install `@tidecloak/server`
-2. Create `TideDelegation` singleton with TideCloak config
-3. Wire `/api/delegation` POST endpoint with `handleDelegation()`
-4. Add `requireDelegation()` middleware to admin routes
-5. Wrap browser fetch with `createTideFetch` from `@tidecloak/js`
-6. Optionally scope delegation roles via `requireDelegation({ roles: { ... } })`
-
 ### Hardening gaps (from tide-setup Path D)
 
 Fix each missing item per the table in `tide-setup`.
@@ -105,11 +96,10 @@ Fix each missing item per the table in `tide-setup`.
 - [ ] `tidecloak.json` exists with `jwk`, `vendorId`, `homeOrkUrl`
 - [ ] `public/silent-check-sso.html` exists
 - [ ] Post-auth redirect handler exists at configured `redirectUri`
-- [ ] `public/tide_dpop_auth.html` exists + `next.config.ts` has `rewrites()` for `/tide_dpop/:path*` and DPoP-specific `headers()`
+- [ ] `public/tide_dpop_auth.html` exists + `app/tide_dpop/[...path]/route.ts` catch-all route handler serves it with a sha256 hash-pinned CSP and `Allow-CSP-From: *`
 - [ ] CSP includes `frame-src '*'`
 - [ ] Webpack config has `strictExportPresence = false` + `@tidecloak/react` ESM alias
 - [ ] Login flow completes: redirect to Tide IdP -> auth -> callback -> app
-- [ ] If server-side admin calls needed: `@tidecloak/server` installed, delegation endpoints wired
 
 ---
 
@@ -132,5 +122,6 @@ Next: Security Engineer | STOP if integration incomplete
 - Do not create ad hoc auth wiring. Follow the playbook.
 - Do not use `NEXT_PUBLIC_TIDECLOAK_*` env vars. Use `tidecloak.json` directly. (AP-38)
 - Do not pass `useDPoP` as a JSX prop. It goes inside the config object. (AP-42, session-002)
-- Do not modify `tide_dpop_auth.html`. It is integrity-checked. (I-12, L-07)
-- Do not apply `script-src 'unsafe-inline'` globally. Only on the DPoP auth route. (L-07)
+- Do not modify `tide_dpop_auth.html`. It is integrity-checked and its inline script/style are sha256-pinned in the route handler's CSP. (I-12, L-07)
+- Do not serve the DPoP auth page with `script-src 'unsafe-inline'`. Pin its inline script/style with `sha256-...` hashes in the route handler's CSP instead. (L-07)
+- Do not use `next.config.ts` `rewrites()` to serve the DPoP auth page. Use the `app/tide_dpop/[...path]/route.ts` catch-all route handler (the shipped `@tidecloak/create-nextjs` approach). (I-12)

package/skills/tide-mcp-qa/SKILL.md

@@ -0,0 +1,139 @@
+# Role: MCP QA Engineer (Pre-Release Gate)
+
+---
+
+## Purpose
+
+Decide whether the Tide MCP pack is safe to release. This role runs the deterministic test gate, then does the semantic review the gate cannot, and issues a single verdict: **SHIP**, **SHIP_WITH_WARNINGS**, or **BLOCK**. It is the pre-release quality gate for the pack (canon, playbooks, skills, prompts, reference-apps, and the MCP server that exposes them).
+
+This role is **read-only and advisory about the release**. It runs tests and reads content; it does not fix defects it finds. When it finds a blocker, it names the file and the fix owner and blocks the release.
+
+## Two layers, one verdict
+
+1. **Deterministic gate (objective, must be green).** `cd mcp-server && npm test` — protocol smoke tests (all tools/prompts present, each returns correct-looking content, graceful errors) plus content-consistency checks (no stray legacy endpoints, no merge markers, referenced playbooks exist, SG-01..SG-18 present, GAP counts sum, honesty guards present). **Any red here is an automatic BLOCK.**
+2. **Semantic review (judgment, gate can't see it).** Spot-read tool outputs and doctrine for correctness, coherence, and honesty; drive a sample of eval cases; confirm new/changed capabilities actually lead an agent to the right behavior.
+
+A release is **SHIP** only when the gate is green *and* semantic review finds no correctness/honesty blocker.
+
+---
+
+## Boundary
+
+| This role owns | Does NOT own |
+|----------------|--------------|
+| Running `npm test` and interpreting it | Fixing failing tests or defects |
+| Semantic/coherence review of tool outputs & doctrine | Writing new pack content |
+| Driving sample eval cases | Building features |
+| Honesty/overclaim audit | Changing doctrine to make a test pass |
+| The release verdict (SHIP / WARN / BLOCK) | Publishing/releasing (that's the human's call after the verdict) |
+
+**Hard rule:** never weaken a check or edit doctrine to turn a gate green. If a test is wrong, report it as a test defect; do not silence it.
+
+---
+
+## When to Trigger
+
+- Before publishing/releasing the MCP pack or the npm package.
+- After a substantial doctrine change (a reconciliation like the IGA API migration, a new capability, a merge of feature branches).
+- On demand: "QA the MCP", "is the pack ready to release", "run the release gate".
+
+## When NOT to Trigger
+
+- Building or editing pack content (that's the authoring roles).
+- Diagnosing a live TideCloak app (that's `tide-diagnostics`).
+- Security-analysing a customer system (that's `tide-security-analyst`).
+
+---
+
+## Execution
+
+### Step 1 — Run the deterministic gate
+```bash
+cd mcp-server && npm test
+```
+Record the summary line and every failing check verbatim. If the harness itself crashes, that is a BLOCK (the gate is not trustworthy). If any check is red, the verdict is **BLOCK** — capture the failures and skip to the report; do not rationalize a red gate into a ship.
+
+### Step 2 — Semantic review (only meaningful once the gate is green)
+Call the tools through the MCP server (or read the assets directly) and judge what the grep-level gate cannot:
+
+- **Correctness of guidance.** Read `tide_security_analysis`, `tide_hosting`, and the IGA reference (`tide_canon iga-change-requests-api`). Do the endpoints, payloads, and status codes read as internally consistent? Would an agent following them do the right thing?
+- **Coherence after change.** For the area that changed since last release, read the primary canon + one consumer (a playbook or reference-app) and confirm they agree. (E.g. after the IGA migration: `canon/iga-change-requests-api.md` vs a bootstrap script vs `setup-iga-admin-panel` — same surface, same payloads.)
+- **Routing.** `tide_choose_playbook` / `tide_choose_scenario` on a few real phrasings land on the right path (hosted→skycloak, "security analysis"→analyst, "org password manager"→scenario, ambiguous→disambiguation, not silent default).
+- **Honesty audit (load-bearing).** Confirm the pack does NOT overclaim:
+  - Security analysis keeps the out-of-scope section and never claims Tide fixes injection/XSS/deps (AP-SEC-1).
+  - Hosting is not sold as fully turnkey before GAP-066 (AP-HOST-2); the Tideless-IGA caveat is present.
+  - IGA "no single bypass / tamper-evident" claims are scoped to Tide mode, not Tideless.
+  - Anything marked REQUIRES_RUNTIME_VALIDATION (e.g. the IGA bootstrap loop) is flagged as such, not asserted as verified.
+
+### Step 3 — Drive sample eval cases
+Pick a representative spread from `evals/cases.yaml` (a fresh-setup case, a protection case, a security-analysis case, a hosting case, an IGA governance case). For each, reason: given the pack's current content, would an agent hit the `expected_behavior` and avoid the `failure_conditions`? Note any case the pack would now fail. (This is judgment, not execution — say so.)
+
+### Step 4 — Verdict + report
+Emit the Release Readiness Report. One verdict:
+- **SHIP** — gate green, no semantic blocker, no unmanaged overclaim.
+- **SHIP_WITH_WARNINGS** — gate green; only non-blocking issues (cosmetic, low-risk doc gaps, known REQUIRES_RUNTIME_VALIDATION items that are correctly labelled). List them.
+- **BLOCK** — any red gate check, any harness crash, any correctness or honesty defect, or a sample eval the pack would now fail. Name each blocker + the file + the fix owner (which authoring role).
+
+---
+
+## Release Readiness Report (required format)
+
+```
+# Tide MCP — Release Readiness Report
+Verdict: SHIP | SHIP_WITH_WARNINGS | BLOCK
+Scope: <what changed since last release / full pack>
+
+## Deterministic gate
+Command: cd mcp-server && npm test
+Result: <N/M passed>  (PASS/FAIL)
+Failures: <each red check verbatim, or "none">
+
+## Semantic review
+- Correctness: <observations, or "no issues">
+- Coherence (changed area): <what you cross-checked → verdict>
+- Routing: <phrasings tried → where they landed>
+- Honesty audit: <overclaim checks → pass/fail with evidence>
+
+## Sample eval cases
+<case id → would-pass / would-fail (why)>
+
+## Blockers (if any)
+1. <defect> — <file:line> — fix owner: <authoring role/skill>
+
+## Warnings (non-blocking)
+- <item, why it's acceptable to ship>
+
+## Recommendation
+<one line: release, or fix blockers then re-run the gate>
+```
+
+---
+
+## Verification (of the QA pass itself)
+
+- [ ] `npm test` was actually run this pass; its summary is quoted.
+- [ ] A red gate or harness crash was reported as BLOCK (never rationalized).
+- [ ] The honesty audit ran and its results are in the report.
+- [ ] Every blocker names a file and a fix owner.
+- [ ] No check was weakened and no doctrine was edited to pass the gate.
+
+## Anti-Patterns
+
+- **AP-QA-1** — Shipping on a red or crashed gate. The deterministic gate is a hard floor.
+- **AP-QA-2** — Editing a test or doctrine to turn a check green instead of reporting the defect. QA reports; it does not launder failures.
+- **AP-QA-3** — Skipping the honesty audit. Overclaiming (turnkey hosting, crypto-tamper-evidence on Tideless, "fixes XSS") is a release blocker, not a warning.
+- **AP-QA-4** — Reporting a green gate as SHIP without semantic review. Grep-green is necessary, not sufficient.
+- **AP-QA-5** — Treating a correctly-labelled REQUIRES_RUNTIME_VALIDATION item as a blocker. It ships as a warning; an *unlabelled* one is the blocker.
+
+## Handoff Trace
+
+```
+[TRACE]
+Scenario: pre-release QA of the Tide MCP pack
+Role: MCP QA Engineer
+Reason: <release / post-change gate>
+Preconditions: mcp-server builds; npm test runnable
+Verdict: <SHIP | SHIP_WITH_WARNINGS | BLOCK>
+Next: <release, or route blockers to named authoring roles>
+[/TRACE]
+```

package/skills/tide-rbac-and-e2ee/SKILL.md

@@ -43,7 +43,7 @@ Self-encryption (this skill) is **permanently user-bound**. It cannot be upgrade
 - App is not Tide-enabled. Route to `tide-setup` skill.
 - API routes do not verify JWT yet. Route to `tide-route-and-api-protection` skill first. RBAC on unverified tokens is meaningless.
 - User needs shared/group encryption (policy-governed VVK encryption with Forseti contracts). That is covered by playbook `setup-forseti-e2ee`, not this skill. This skill covers self-encryption only.
-- User asks about Keycloak-to-TideCloak migration. Not yet documented (GAP-023).
+- User asks about a **direct Keycloak-to-TideCloak** migration. That specific path is not yet documented (GAP-023). (Migrating an app off generic-OIDC / NextAuth / Clerk is a separate task covered by `playbooks/migrate-from-existing-auth.md`; the open gap is the KC→TideCloak realm/data migration itself.)
 
 **Early sharing detection**: If the user request mentions any of: "sharing", "share encrypted", "chosen recipients", "other users can decrypt", "cross-user decryption", "encrypt for others", "selective sharing" — route directly to `setup-forseti-e2ee`. Do NOT start with self-encryption and attempt to add sharing later. Self-encryption cannot be upgraded to shared encryption by renaming roles or changing parameters. The SDK call path must be different from the start. VERIFIED (session-001, F-07).
 
@@ -139,8 +139,8 @@ Self-encryption is user-bound. Only the encrypting user can decrypt their own da
 - [ ] Bypassing UI (direct curl) still enforces role server-side
 
 ### Self-Encryption (if applicable)
-- [ ] `doEncrypt('tag', data)` succeeds for user with `_tide_{tag}.selfencrypt` role
-- [ ] `doDecrypt('tag', ciphertext)` returns original data for same user
+- [ ] `doEncrypt([{ data, tags: ['tag'] }])` succeeds for user with `_tide_{tag}.selfencrypt` role
+- [ ] `doDecrypt([{ data: ciphertext, tags: ['tag'] }])` returns original data for same user
 - [ ] `doEncrypt` fails for user without the selfencrypt role
 - [ ] `doDecrypt` by a different user fails (expected behavior — self-encryption is user-bound; A-27 INFERRED, not runtime-confirmed)
 - [ ] Ciphertext stored in DB is not plaintext
@@ -181,8 +181,8 @@ Self-encryption is user-bound. Only the encrypting user can decrypt their own da
 
 This is a policy-flow failure, not a role issue. See T-14.
 
-1. Check admin policy was fetched from `GET /realms/{realm}/tide-policy-resources/admin-policy`
-2. Check admin policy bytes were base64-decoded before use
+1. Check admin policy was fetched (admin bearer) from `GET /admin/realms/{realm}/iga/role-policies`, reading the signed bytes from the `policy` field (the public `tide-policy-resources/admin-policy` endpoint does not exist on main)
+2. Check admin policy bytes were base64-decoded from the `policy` field before use
 3. Check `addPolicy(adminPolicyBytes)` was called after approval, not during request construction
 4. Check URL construction has no double slashes (strip trailing slash from `auth-server-url`)
 

package/skills/tide-reviewer/SKILL.md

@@ -65,7 +65,7 @@ The Reviewer is optional per-step but **mandatory before handing the app to the
 - [ ] Does `next.config.ts` have `strictExportPresence = false`? (not `reexportExportsPresence`)
 - [ ] Does `next.config.ts` have the `@tidecloak/react` ESM alias? (AP-42)
 - [ ] Does `public/tide_dpop_auth.html` exist? (I-12, L-07)
-- [ ] Does `next.config.ts` have `rewrites()` for `/tide_dpop/:path*` and DPoP-specific `headers()` with `script-src 'unsafe-inline'`? (I-12)
+- [ ] Is the DPoP auth page served by a `app/tide_dpop/[...path]/route.ts` catch-all route handler (NOT `next.config.ts` rewrites) with a sha256 hash-pinned CSP (NOT `script-src 'unsafe-inline'`) and an `Allow-CSP-From: *` header? (I-12)
 - [ ] Does `public/silent-check-sso.html` exist? (I-07)
 - [ ] Does the redirect handler exist at the configured `redirectUri`? (I-16)
 - [ ] Is CSP set to `frame-src '*'`? (I-06)