@tideorg/mcp 1.4.1 → 1.9.0

package/prompts/security-gap-analysis.md

@@ -0,0 +1,55 @@
+# Prompt: Security Gap Analysis of an Existing System
+
+Copy-paste this to an AI coding agent to audit an existing application for identity, key-management, authorization, and data-exposure gaps — and map each gap to the Tide capability that removes it. Works on systems with no Tide involvement at all.
+
+This is an **advisory, read-only** analysis. It does not modify the target.
+
+---
+
+## The Prompt
+
+> Perform a security gap analysis of this system. You are acting as the **Security Analyst** role from the Tide agent pack. Do not modify any code. Produce a report; do not begin remediation until I approve it.
+>
+> **First, confirm scope**: state exactly what you will inspect (repo, running instance, config) and that this is my own system or an authorized engagement. Read-only.
+>
+> **Load the doctrine**: read `canon/security-gap-mapping.md` (the SG-01 … SG-18 gap table) and `skills/tide-security-analyst/SKILL.md`. If you have the Tide MCP server, call `tide_security_analysis` to load them at once.
+>
+> **Two tiers**: run the **static** sweep (code/config/schema) always. Only run the **runtime confirmation** tier — sending live probes to confirm findings — if I confirm I own or am authorized to test the target, and then strictly per `canon/security-runtime-probes.md` (non-destructive, no exploitation, my own test account only). If I have not authorized live testing, stay static-only and keep findings tagged INFERRED.
+>
+> **Inventory the trust architecture first** (before pattern-matching), answering from the code/config:
+> 1. Identity — how are users authenticated, where do credentials live?
+> 2. Authority — how are tokens/sessions signed, who holds the signing key?
+> 3. Authorization — where is the access decision made: client, server, or both?
+> 4. Data — what sensitive data exists, and who can read it in the clear?
+>
+> **Run the full gap sweep**: work through SG-01 … SG-12 exhaustively. For each, run the detection commands from `canon/security-gap-mapping.md` against the target and record hits. Do NOT sample APIs (SG-05) — enumerate every route and diff against the routes that actually verify. Also collect anything matching the "Out of scope" table.
+>
+> **Every finding must have**:
+> - A named **trust concentration** — the single party or artifact that, once compromised, defeats the control. "Uses passwords" is not a finding; "password verification collapses to one database + one server process" is.
+> - **Evidence** — a file:line, config value, schema column, or HTTP observation — tagged VERIFIED (observed), INFERRED (implied by code), or ASSUMED (my statement, unconfirmed).
+> - A **severity** (CRITICAL / HIGH / MEDIUM / INFO) based on blast radius under a single compromise.
+> - The **Tide replacement**, cited from `canon/feature-mapping.md` or `canon/invariants.md`, with its sourcing tag.
+> - The **remediation playbook sequence** (verify each playbook exists via `tide_list playbooks`).
+> - The **limits** — the honesty note: what the Tide replacement does NOT cover.
+>
+> **Be honest**: include a non-empty "Not Addressed by Tide" section for anything you find that Tide doesn't fix (injection, XSS, CSRF, vulnerable dependencies, rate limiting, infra hardening). Never present Tide as fixing these. An honest analysis is more credible than an inflated one.
+>
+> **Report in the format** defined in `skills/tide-security-analyst/SKILL.md` (Report Format section): trust-architecture summary, findings most-severe-first, gap interactions, out-of-scope section, then a recommended remediation sequence with the execution role to engage first (per I-18).
+>
+> **Do not**: modify code, run TideCloak bootstrap, install the SDK, or start fixing anything. Report only. When I approve findings, hand off to the execution roles (Setup → Application → Security → IAM/Policy → Reviewer).
+
+---
+
+## Acceptance Criteria
+
+- [ ] Scope and authorization confirmed before inspection
+- [ ] Trust architecture (identity / authority / authorization / data) documented
+- [ ] All of SG-01 … SG-18 checked, not sampled (or non-applicability stated per SG)
+- [ ] Every finding names a trust concentration and carries evidence with a confidence tag
+- [ ] Runtime tier run only if authorized; probed findings carry a Runtime confirmation line; unprobed findings stay INFERRED
+- [ ] Every Tide-replacement claim cites `canon/feature-mapping.md` or `canon/invariants.md`
+- [ ] Every remediation names a playbook that exists in `playbooks/`
+- [ ] Non-empty "Not Addressed by Tide" section (or explicit "none found in scope")
+- [ ] No finding claims Tide fixes an out-of-scope gap class
+- [ ] Remediation sequence provided with first execution role named
+- [ ] No code was modified; the analysis is read-only

package/reference-apps/encrypted-communication/anti-patterns.md

@@ -10,7 +10,7 @@ Scenario-specific mistakes for encrypted communication apps using the hybrid Tid
 
 **Why it fails**: The private key is the root of trust for all E2E operations. If stored in plaintext, a database breach or XSS attack exposes all encrypted communications.
 
-**Fix**: Always encrypt the private key with `doEncrypt(privateKeyBytes, tag)` before storing. Always decrypt with `doDecrypt()` on login. Never persist the decrypted private key outside of in-memory variables.
+**Fix**: Always encrypt the private key with `doEncrypt([{ data: privateKeyBytes, tags: [tag] }])` before storing. Always decrypt with `doDecrypt()` on login. Never persist the decrypted private key outside of in-memory variables.
 
 ---
 
@@ -118,6 +118,6 @@ Scenario-specific mistakes for encrypted communication apps using the hybrid Tid
 
 **Mistake**: Installing a 0.99.x pre-release version of the Tide SDK.
 
-**Why it fails**: 0.99.x versions are unstable pre-releases. The stable version is 0.13.26 (per pack version policy).
+**Why it fails**: 0.99.x versions are unstable pre-releases. The stable version is 0.13.33 (per pack version policy).
 
-**Fix**: Pin `@tidecloak/react` to `0.13.26`. See `canon/version-policy.md`.
+**Fix**: Pin `@tidecloak/react` to `0.13.33`. See `canon/version-policy.md`.

package/reference-apps/encrypted-communication/bootstrap-sequence.md

@@ -117,12 +117,12 @@
 
 23. Implement first-login flow:
     - Generate keypair client-side
-    - Encrypt private key with `doEncrypt(privateKeyBytes, tag)`
+    - Encrypt private key with `doEncrypt([{ data: privateKeyBytes, tags: [tag] }])`
     - Store encrypted private key + public key via protected API
 
 24. Implement returning-login flow:
     - Fetch encrypted key material via protected API
-    - Decrypt private key with `doDecrypt(encryptedPrivateKey, tag)`
+    - Decrypt private key with `doDecrypt([{ encrypted: encryptedPrivateKey, tags: [tag] }])`
     - Private key available in memory for runtime E2E operations
 
 25. Implement runtime E2E operations using the external crypto library (not Tide).

package/reference-apps/encrypted-communication/scenario.md

@@ -77,14 +77,14 @@ On **first login** for a new user:
 1. User authenticates via TideCloak SSO
 2. App checks database for existing encrypted key material
 3. No keys found → app generates a new asymmetric keypair client-side (e.g., `crypto_box_keypair()`)
-4. App encrypts the private key using `doEncrypt(privateKeyBytes, tag)` (Tide self-encryption)
+4. App encrypts the private key using `doEncrypt([{ data: privateKeyBytes, tags: [tag] }])` (Tide self-encryption)
 5. App stores the encrypted private key and the public key in the database via a protected API endpoint
 6. Private key is now available in memory for runtime E2E operations
 
 On **returning login**:
 1. User authenticates via TideCloak SSO
 2. App fetches encrypted key material from database
-3. App decrypts the private key using `doDecrypt(encryptedPrivateKey, tag)` (Tide self-encryption)
+3. App decrypts the private key using `doDecrypt([{ encrypted: encryptedPrivateKey, tags: [tag] }])` (Tide self-encryption)
 4. Private key is now available in memory for runtime E2E operations
 
 **Runtime E2E operations** (not Tide — handled by external crypto library):

package/reference-apps/git-pr-signing-service/bootstrap-sequence.md

@@ -27,11 +27,11 @@ All steps must complete before the service can sign merge commits. Order matters
    - `POST /admin/realms/{realm}/tide-admin/toggle-iga` with form-urlencoded `isIGAEnabled=true`.
    - Must happen after licensing.
 
-## Phase 3: Approve initial change-sets
+## Phase 3: Approve initial change requests
 
-6. **Approve client change-sets**
-   - 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`)
+   - List: `GET /admin/realms/{realm}/iga/change-requests?status=PENDING` (objects keyed by `id`).
+   - Approve: `POST .../iga/change-requests/bulk-authorize` (`{"actionTypeIn":["CREATE","DELETE"],"limit":100}`), then `POST .../iga/change-requests/{id}/commit` for each `readyToCommit` CR. FirstAdmin bootstrap signs server-side.
 
 ## Phase 4: Admin user setup
 
@@ -50,11 +50,11 @@ All steps must complete before the service can sign merge commits. Order matters
 10. **Wait for account linking**
     - Poll `GET /admin/realms/{realm}/users/{userId}` until `attributes.tideUserKey` and `attributes.vuid` are present for each admin.
 
-## 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/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)