@ory/argus 0.9.0 → 0.10.0

package/README.md

@@ -16,7 +16,7 @@ const session = await client.verifySession(sessionToken);
 const result = await client.checkPermission({
   namespace: "AgentTools",
   object: "Bash",
-  relation: "invoke",
+  relation: "use",
   subjectId: `session:${sessionId}`,
 });
 
@@ -57,7 +57,7 @@ async function onBeforeTool(toolName: string, sessionId: string) {
   const result = await client.checkPermission({
     namespace: "AgentTools",
     object: toolName,
-    relation: "invoke",
+    relation: "use",
     subjectId: `session:${sessionId}`,
   });
   if (result.allowed === false) {
@@ -84,7 +84,7 @@ The wrapped Ory client. One instance per harness session.
 | Sessions and tokens | `verifySession`, `introspectToken`, `classifyError` |
 | Permission checks | `checkPermission`, `batchCheckPermissions`, `checkMcpPermission` |
 | Principals (who is acting) | `setUserPrincipal`, `setAgentPrincipal` |
-| Delegation tuples | `createRelationship`, `deleteRelationship` |
+| Delegation relations | `createRelationship`, `deleteRelationship` |
 | Tracing | `tracer` (see Tracer below) |
 
 ### Identity gates

package/assets/skills/auth-setup/SKILL.md

@@ -32,6 +32,48 @@ If you find yourself writing `flow.ui.nodes.map(...)` to render auth UI,
 stop and switch to Ory Elements. Custom node rendering is a fallback,
 not a parallel option.
 
+## Correctness contract — satisfy these or the app will 404 / 500 / CSRF
+
+Almost every "Ory doesn't work" report comes from one of four wiring
+mistakes in the generated app — **not** from Ory itself and **not** from
+the agent plugin governing this session. Treat each as a hard requirement,
+and verify all four (Step 10) before telling the user the app is ready.
+
+1. **Ory must be first-party (same site as your app), or every flow fails
+   CSRF.** Ory's browser flows depend on a CSRF cookie. If the browser calls
+   Ory on a *different* site than your app, the browser drops that cookie and
+   you get `CSRF token mismatch`, 403s, or redirect loops. So the browser SDK
+   URL must be **your own origin** — never `https://<slug>.projects.oryapis.com`
+   directly:
+   - **Local dev against Ory Network** — run `ory tunnel` and point the SDK at
+     the tunnel (`http://localhost:4000`). See Step 9.
+   - **Local dev against the local stack** — the gateway is already on
+     `http://localhost:4000` (first-party to `localhost`). Use `http://localhost`,
+     not `127.0.0.1`.
+   - **Production** — serve Ory from your own domain via an Ory Network custom
+     domain (CNAME) or the `@ory/nextjs` proxy, and set the SDK URL to that.
+2. **The app's routes must match what Ory redirects to, or you get 404s.** Ory
+   redirects the browser to the self-service UI URLs configured on the project
+   (login, registration, recovery, verification, settings, **error**). If a page
+   lives at `/auth/login` but the project points at `/login`, the redirect 404s.
+   Pick one set of paths and make these four agree: the page files you create,
+   the `@ory/nextjs` UI-path config, the project's `selfservice.flows.*.ui_url`
+   (+ `error.ui_url`), and the middleware path lists. Always create an error
+   page — Ory redirects there on any flow error. See Step 8.
+3. **Server-side session/flow calls must forward the request cookies, or they
+   500/401.** A `FrontendApi` built with `credentials: "include"` only sends
+   cookies in the **browser**. In Next.js server components, route handlers, and
+   middleware you must forward the incoming request's cookies — the `@ory/nextjs`
+   server helpers do this for you. Reusing the browser client on the server is
+   the single most common 500. See Step 7.
+4. **The SDK URL env var must be set at runtime, or the SDK 500s on
+   construction.** Validate `NEXT_PUBLIC_ORY_SDK_URL` (browser) / `ORY_SDK_URL`
+   (server) at startup and fail with a clear message instead of constructing the
+   client with `undefined`. See Step 4.
+
+If a flow still fails after all four hold, isolate it with the **App bug vs.
+plugin bug** triage in Step 10 before assuming a bug in Ory or in the plugin.
+
 ## Step 1: Check prerequisites
 
 Before installing the Ory CLI, decide where the auth backend will run:
@@ -107,29 +149,54 @@ React island or a small client bundle so you still get the Elements UI
 on the auth routes. Rendering flow nodes directly on the server is the
 fallback of last resort.
 
+**Match the installed major versions.** `@ory/nextjs` and
+`@ory/elements-react` change import names and component props across major
+versions. After installing, run `npm ls @ory/nextjs @ory/elements-react`
+and follow the docs and TypeScript types for *that* major — do not assume
+symbol names from memory. A missing import or a prop type error at build
+time is a version mismatch in the generated app, not a plugin bug.
+
 ## Step 4: Configure the Ory SDK
 
-Create a shared Ory client configuration. The SDK URL should come
-from an environment variable:
+For **Next.js**, prefer wiring Ory through `@ory/nextjs` (its config proxies
+Ory under your own origin and supplies cookie-forwarding server helpers — this
+satisfies contract #1 and #3 for free). Build a hand-rolled `FrontendApi`
+client only for **browser** code in a React SPA, or for explicit client-side
+calls.
+
+When you do build a client, read the URL from an env var and **validate it** —
+constructing the SDK with an `undefined` `basePath` is a 500 waiting to happen
+(contract #4):
 
 ```typescript
 import { Configuration, FrontendApi } from "@ory/client-fetch";
 
+const sdkUrl = process.env.NEXT_PUBLIC_ORY_SDK_URL ?? process.env.ORY_SDK_URL;
+if (!sdkUrl) {
+  throw new Error(
+    "Ory SDK URL is not set. Set NEXT_PUBLIC_ORY_SDK_URL (browser) " +
+      "or ORY_SDK_URL (server) — see Step 4.",
+  );
+}
+
+// Browser-only: `credentials: "include"` sends cookies from browser code.
+// Do NOT reuse this client in server components / route handlers / middleware
+// (contract #3) — use the @ory/nextjs server helpers there.
 const ory = new FrontendApi(
-  new Configuration({
-    basePath: process.env.NEXT_PUBLIC_ORY_SDK_URL || process.env.ORY_SDK_URL,
-    credentials: "include",
-  })
+  new Configuration({ basePath: sdkUrl, credentials: "include" }),
 );
 
 export default ory;
 ```
 
-Add to the project's `.env` or `.env.local`:
+Add to the project's `.env` or `.env.local`. The **browser** value
+(`NEXT_PUBLIC_ORY_SDK_URL`) must be your own origin (contract #1), so in local
+development point it at the tunnel or the local gateway, not at `*.oryapis.com`:
 
 ```bash
-NEXT_PUBLIC_ORY_SDK_URL=https://<project-slug>.projects.oryapis.com
-# or
+# Local dev (Ory Tunnel for Network, or the local stack gateway):
+NEXT_PUBLIC_ORY_SDK_URL=http://localhost:4000
+# Server-side only (safe to be the direct project URL):
 ORY_SDK_URL=https://<project-slug>.projects.oryapis.com
 ```
 
@@ -166,7 +233,9 @@ Create the following page structure:
 - `app/auth/registration/page.tsx` — `<Registration flow={flow} />`
 - `app/auth/recovery/page.tsx` — `<Recovery flow={flow} />`
 - `app/auth/verification/page.tsx` — `<Verification flow={flow} />`
-- `app/auth/settings/page.tsx` — `<Settings flow={flow} />`
+- `app/auth/settings/page.tsx` — `<Settings flow={flow} />`, wrapped in
+  `<SessionProvider>` from `@ory/elements-react/client` (Settings is the only
+  flow that needs it — see {{REF_LOGIN_FLOW}})
 
 Each page initializes its flow with `getLoginFlow`, `getRegistrationFlow`,
 etc. from `@ory/nextjs/app`, then hands the flow to the matching
@@ -191,17 +260,27 @@ with the user that an Ory Elements island is not viable.
 
 ## Step 7: Add session middleware
 
-Protect authenticated routes by checking the session:
+Protect authenticated routes by checking the session. **Where this code runs
+matters** (contract #3):
 
-```typescript
-const session = await ory.toSession();
-if (!session) {
-  // Redirect to login
-}
-```
+- **Browser code** can use the `credentials: "include"` client from Step 4
+  directly — the browser attaches the session cookie:
+
+  ```typescript
+  const session = await ory.toSession(); // browser only
+  if (!session) {
+    // Redirect to login
+  }
+  ```
+
+- **Server code** (server components, route handlers, middleware) must forward
+  the incoming request's cookies. Do **not** reuse the browser client — it has
+  no cookies on the server and will throw (→ 500) or always return 401. Use the
+  `@ory/nextjs` server helpers, which read and forward the request cookies for
+  you.
 
 For Next.js, prefer the official `@ory/nextjs` middleware helper since
-it pairs with the Elements pages:
+it pairs with the Elements pages and handles server-side cookie forwarding:
 
 ```typescript
 import { createOryMiddleware } from "@ory/nextjs/middleware";
@@ -216,37 +295,118 @@ export const config = {
 };
 ```
 
-## Step 8: Configure allowed redirect URLs
-
-Update the Ory project to allow redirects back to your app:
-
-```bash
-ory patch project <project-id> \
-  --replace '/services/identity/config/selfservice/allowed_return_urls=["http://localhost:3000", "https://your-domain.com"]'
-```
-
-## Step 9: Set up the Ory Tunnel for local development
-
-For local development, use the Ory tunnel to proxy requests and handle cookies:
-
-```bash
-ory tunnel http://localhost:3000 --project <project-slug>
-```
-
-This runs a proxy on `http://localhost:4000` that handles cookie domains
-correctly for local development. Update your SDK URL to point to the
-tunnel during development.
-
-## Step 10: Verify the setup
-
-1. Start the development server
-2. Navigate to the login page — confirm Ory Elements renders the form,
-   including any social login buttons configured on the project
-3. Create a test account via the registration page
-4. Verify login works
-5. Test account recovery flow
-6. Test the verification flow
-7. Check that protected routes redirect unauthenticated users
+## Step 8: Align the project's routes and return URLs with your app
+
+This step prevents the 404s in contract #2. Ory redirects the browser to the
+self-service UI URLs it has configured; those must point at pages your app
+actually serves.
+
+**Pick one route convention and use it everywhere.** This guide uses
+`/auth/login`, `/auth/registration`, `/auth/recovery`, `/auth/verification`,
+`/auth/settings`, and `/auth/error`. The page files, the middleware path lists,
+and the project config below must all use the same paths.
+
+1. **Create an error page.** Ory redirects to the error UI on *any* flow error;
+   if it doesn't exist you get a 404 (or a blank page) instead of a readable
+   message. Create `app/auth/error/page.tsx` rendering the Elements error
+   component (`<Error>` / the flow-error view for your installed version).
+
+2. **Tell Ory where the pages are.**
+   - **Next.js with `@ory/nextjs`:** declare the UI paths in its config (the
+     UI-path overrides in `ory.config.ts`) so its helpers, middleware, and proxy
+     route to your pages. The SDK serves the UI under your own origin, so you
+     usually do not also edit the project's `ui_url`s.
+   - **React SPA / no `@ory/nextjs` proxy:** set the project's self-service UI
+     URLs to your app's routes:
+
+     ```bash
+     ory patch project <project-id> \
+       --replace '/services/identity/config/selfservice/flows/login/ui_url="https://your-domain.com/auth/login"' \
+       --replace '/services/identity/config/selfservice/flows/registration/ui_url="https://your-domain.com/auth/registration"' \
+       --replace '/services/identity/config/selfservice/flows/recovery/ui_url="https://your-domain.com/auth/recovery"' \
+       --replace '/services/identity/config/selfservice/flows/verification/ui_url="https://your-domain.com/auth/verification"' \
+       --replace '/services/identity/config/selfservice/flows/settings/ui_url="https://your-domain.com/auth/settings"' \
+       --replace '/services/identity/config/selfservice/flows/error/ui_url="https://your-domain.com/auth/error"'
+     ```
+
+3. **Allow redirects back to your app** (every origin you run on — dev and prod):
+
+   ```bash
+   ory patch project <project-id> \
+     --replace '/services/identity/config/selfservice/allowed_return_urls=["http://localhost:3000", "https://your-domain.com"]'
+   ```
+
+## Step 9: Serve Ory first-party (required — contract #1)
+
+The browser must reach Ory on the same site as your app, or cookie-based flows
+fail CSRF. How you achieve that depends on the environment:
+
+- **Local dev against Ory Network — run the Ory Tunnel.** This is required, not
+  optional:
+
+  ```bash
+  ory tunnel http://localhost:3000 --project <project-slug>
+  ```
+
+  It runs a proxy on `http://localhost:4000` that serves Ory first-party to
+  `localhost`. Point `NEXT_PUBLIC_ORY_SDK_URL` at the tunnel
+  (`http://localhost:4000`) — **not** at `https://<slug>.projects.oryapis.com`.
+
+- **Local dev against the local stack** — the gateway is already first-party on
+  `http://localhost:4000`; no tunnel needed (switch to {{REF_LOCAL_DEV}}).
+
+- **Production** — serve Ory from your own domain via an Ory Network custom
+  domain (CNAME) or the `@ory/nextjs` proxy, and set the browser SDK URL to that
+  same-origin path.
+
+If you skip this step, login will appear to work but `whoami`/`toSession` will
+return 401 and form submits will fail with a CSRF error — the classic symptom of
+a cross-site SDK URL.
+
+## Step 10: Verify the setup — and confirm it's correct, not just present
+
+Do not declare success on "the pages render." Run these checks; each maps to a
+contract item so a failure points straight at the cause.
+
+1. **SDK URL is first-party (contract #1).** Confirm the browser SDK URL is your
+   own origin (the tunnel/gateway in dev), not `*.oryapis.com`. In the browser
+   devtools Network tab, the flow requests should go to your origin and the
+   response should `Set-Cookie` a CSRF cookie.
+2. **The flow API itself works (isolates Ory from your app).** Against the URL
+   the browser uses:
+
+   ```bash
+   curl -i "$NEXT_PUBLIC_ORY_SDK_URL/self-service/login/browser"
+   ```
+
+   Expect `200` with a `Set-Cookie: csrf_token...` header. If this fails, the
+   problem is Ory config / the tunnel — not your app code.
+3. **Every redirect target exists (contract #2).** Visit `/auth/login`,
+   `/auth/registration`, `/auth/recovery`, `/auth/verification`,
+   `/auth/settings`, and `/auth/error` directly. Each must return `200`, not
+   `404`. A 404 here means a route/`ui_url` mismatch (Step 8).
+4. **End-to-end:** register a test account, log in, confirm a protected route
+   loads while signed in and redirects to login when signed out, then test
+   recovery and verification.
+
+### App bug vs. plugin bug
+
+These are two different systems. Keep them straight so issues are filed in the
+right place:
+
+- **The generated app** (login pages, CSRF, sessions, the `/auth/*` routes) is
+  ordinary code running in the user's project. A `404`/`500`/CSRF on an `/auth/*`
+  route, or in the browser Network tab, is an **app/config** issue — work the
+  four contract items and the checks above.
+- **The agent plugin** governs *this coding session* — it authenticates the
+  agent, checks Ory Permissions before each tool call, and writes trace spans. It
+  never serves your app's HTTP routes. Diagnose it with
+  `{{NPX}} status` and the debug log (`ORY_AGENT_DEBUG=true`), **not** by looking
+  at your app's auth pages.
+
+Quick triage: if `curl` to the flow API (check 2) succeeds but the app page
+fails, it's the app. If `curl` fails, it's Ory/tunnel config. Neither is the
+plugin unless `{{NPX}} status` reports a problem.
 
 ## Customization
 

package/assets/skills/login-flow/SKILL.md

@@ -24,6 +24,27 @@ rendering belongs in the fallback section at the end of this skill.
   no per-app rewrite needed.
 - Works in Next.js (App Router and Pages Router) and any React SPA.
 
+## Avoid the 404 / 500 / CSRF traps
+
+These pages only work if the surrounding wiring is correct — most "the login
+page is broken" reports are wiring, not the pages or the plugin. If you have not
+run {{REF_AUTH_SETUP}}, do that first; it establishes the four invariants these
+pages depend on:
+
+- **First-party SDK URL** — the browser must reach Ory on your own origin (the
+  Ory Tunnel or local gateway, `http://localhost:4000` in dev), never
+  `https://<slug>.projects.oryapis.com` directly, or every form submit fails
+  with a CSRF error.
+- **Routes match the project config** — the `/auth/*` paths below must match the
+  project's self-service `ui_url`s and the middleware lists, and you must create
+  an `/auth/error` page, or Ory's redirects 404.
+- **Server calls forward cookies** — server-side session/flow reads must forward
+  the request cookies (the `@ory/nextjs` server helpers do this); reusing the
+  browser client on the server 500s.
+
+See the **Correctness contract** and the **App bug vs. plugin bug** triage in
+{{REF_AUTH_SETUP}} for the full detail.
+
 ## Before you start
 
 Check the project setup:
@@ -243,6 +264,7 @@ Create `app/auth/settings/page.tsx`:
 
 ```typescript
 import { Settings } from "@ory/elements-react/theme"
+import { SessionProvider } from "@ory/elements-react/client"
 import { getSettingsFlow, OryPageLayout } from "@ory/nextjs/app"
 
 export default async function SettingsPage(props: {
@@ -257,31 +279,62 @@ export default async function SettingsPage(props: {
 
   return (
     <OryPageLayout>
-      <Settings flow={flow} />
+      <SessionProvider>
+        <Settings flow={flow} />
+      </SessionProvider>
     </OryPageLayout>
   )
 }
 ```
 
+Unlike the other flows, **`<Settings>` must be wrapped in `<SessionProvider>`**
+from `@ory/elements-react/client`. Settings renders session-dependent controls
+(connected social accounts, unlinking, logout of other sessions) that read from
+the session context; the pre-auth pages (login, registration, recovery,
+verification) have no session yet and do not need the provider.
+
 ### Settings — React SPA
 
 Initialize with `createBrowserSettingsFlow` and render
-`<Settings flow={flow} />` from `@ory/elements-react/theme`. The
+`<Settings flow={flow} />` from `@ory/elements-react/theme`, wrapped in
+`<SessionProvider>` from `@ory/elements-react/client` (the same requirement
+as the App Router page above — Settings reads session-dependent state). The
 component handles password changes, profile traits, MFA enrollment,
 and connected social providers.
 
+## Build the error page (do not skip — missing it causes 404s)
+
+Ory redirects the browser to the error UI on **any** flow error (expired flow,
+validation failure, misconfiguration). If that route doesn't exist the user
+hits a 404 or a blank page instead of a readable message, and the failure looks
+like a plugin bug when it's just a missing page.
+
+Create `app/auth/error/page.tsx` and render the Elements error view for your
+installed version (`getFlowError` from `@ory/nextjs/app` + the Elements error
+component). Make sure its path matches the project's `error.ui_url`
+(see {{REF_AUTH_SETUP}}, Step 8). For a React SPA, fetch the error with
+`getFlowError({ id })` from the `error` query param and display
+`error.error.message`.
+
 ## Add session management
 
-Create a utility to check the current session:
+Create a **browser** utility to check the current session. (For server
+components, route handlers, and middleware, use the `@ory/nextjs` server
+helpers instead — they forward the request cookies. Reusing this browser client
+on the server has no cookies and will 500/401.)
 
 ```typescript
 import { FrontendApi, Configuration, Session } from "@ory/client-fetch";
 
+const sdkUrl = process.env.NEXT_PUBLIC_ORY_SDK_URL;
+if (!sdkUrl) {
+  throw new Error("NEXT_PUBLIC_ORY_SDK_URL is not set — see ory-auth-setup Step 4.");
+}
+
+// Browser-only client. `credentials: "include"` only sends cookies in the browser,
+// and sdkUrl must be your own origin (the tunnel/gateway in dev), not *.oryapis.com.
 const ory = new FrontendApi(
-  new Configuration({
-    basePath: process.env.NEXT_PUBLIC_ORY_SDK_URL,
-    credentials: "include",
-  })
+  new Configuration({ basePath: sdkUrl, credentials: "include" }),
 );
 
 export async function getSession(): Promise<Session | null> {
@@ -343,16 +396,137 @@ For larger design changes, the Ory Elements primitives package exposes
 the underlying card, button, and input components — use those before
 falling back to custom node rendering.
 
+## Enable MFA and passkeys
+
+These are **project-side** capabilities: once enabled on the Ory project, the
+`<Login>`, `<Registration>`, and `<Settings>` components render the second-factor
+and passkey UI automatically — **no page code changes**. Configure them with the
+Ory CLI against your project (`ory list projects` for the id), the same idiom as
+{{REF_SOCIAL_LOGIN}}. Against the local stack, apply the equivalent keys to the
+local Kratos config instead ({{REF_LOCAL_DEV}}).
+
+### Passkeys
+
+```bash
+ory patch identity-config <project-id> \
+  --add '/selfservice/methods/passkey/enabled=true' \
+  --add '/selfservice/methods/passkey/config/rp/display_name="My App"' \
+  --add '/selfservice/methods/passkey/config/rp/id="your-domain.com"' \
+  --add '/selfservice/methods/passkey/config/rp/origins=["https://your-domain.com"]'
+```
+
+- `rp.id` is the **domain only** — no scheme, no port (`example.com`, not
+  `https://example.com:3000`).
+- `rp.origins` must list the **exact scheme+host+port** the browser uses.
+- For local dev, WebAuthn treats `localhost` as a secure origin: set
+  `rp.id="localhost"` and `rp.origins=["http://localhost:3000"]` (match your app
+  URL). Passkeys registered against `localhost` won't work on the deployed domain
+  and vice-versa.
+
+### MFA methods
+
+Enable the second factors you want. Backup codes (`lookup_secret`) should always
+be enabled alongside any other method so a user who loses their device can
+recover.
+
+```bash
+# TOTP (authenticator app)
+ory patch identity-config <project-id> \
+  --add '/selfservice/methods/totp/enabled=true' \
+  --add '/selfservice/methods/totp/config/issuer="My App"'
+
+# Backup codes
+ory patch identity-config <project-id> \
+  --add '/selfservice/methods/lookup_secret/enabled=true'
+
+# Email code as a second factor
+ory patch identity-config <project-id> \
+  --add '/selfservice/methods/code/mfa_enabled=true'
+```
+
+### Require the second factor (do not skip)
+
+Enabling a method only lets users *enroll* — it does not *require* the second
+factor. Without this step MFA is opt-in and unenforced. Set the required
+assurance level to the highest the identity has available:
+
+```bash
+ory patch identity-config <project-id> \
+  --add '/selfservice/flows/settings/required_aal="highest_available"' \
+  --add '/session/whoami/required_aal="highest_available"'
+```
+
+With `highest_available`, `toSession()` / `getServerSession()` return an
+incomplete session (AAL1) until the user clears the second factor, and Elements
+prompts for it on the next `<Login>`. Your route protection should treat an
+AAL1 session on an MFA-enrolled user as unauthenticated.
+
 ## Test the flow
 
-1. Start the dev server and Ory tunnel (if developing locally)
-2. Visit `/auth/registration` to create an account — confirm Elements
-   renders all configured methods (password, social, passkey, etc.)
-3. Visit `/auth/login` to sign in
-4. Verify session is established (check protected routes)
-5. Test `/auth/recovery` with a registered email
-6. Test `/auth/settings` for profile changes
-7. Test logout
+Don't stop at "the page renders." Run these in order — each one isolates a
+different failure class:
+
+1. Start the dev server **and the Ory tunnel** (local dev against Network), or
+   the local stack. Confirm the browser SDK URL is your own origin, not
+   `*.oryapis.com`.
+2. **Flow API reachable (isolates Ory from your app):**
+
+   ```bash
+   curl -i "$NEXT_PUBLIC_ORY_SDK_URL/self-service/login/browser"
+   ```
+
+   Expect `200` and a `Set-Cookie: csrf_token...` header. If this fails it's the
+   tunnel / Ory config, not your pages.
+3. **No 404s:** visit `/auth/login`, `/auth/registration`, `/auth/recovery`,
+   `/auth/verification`, `/auth/settings`, and `/auth/error` — each returns
+   `200`. A 404 means a route/`ui_url` mismatch.
+4. Register at `/auth/registration` — confirm Elements renders all configured
+   methods (password, social, passkey, etc.).
+5. Sign in at `/auth/login`; confirm a protected route loads, and redirects to
+   login when signed out.
+6. Test `/auth/recovery` with a registered email, `/auth/settings` for profile
+   changes, and logout.
+
+If a submit fails with a CSRF error, the SDK URL is cross-site (trap #1). If a
+redirect 404s, a route doesn't match the project config (trap #2). Neither is a
+plugin bug — see the **App bug vs. plugin bug** triage in {{REF_AUTH_SETUP}}.
+
+### Writing E2E tests (Playwright)
+
+Automating these flows has three gotchas that cause flaky or wrong-for-the-wrong-
+reason failures. Get them right up front:
+
+1. **Match URLs by pattern, never literally.** Ory appends `?flow=<uuid>` on
+   every flow redirect, so an exact-string wait never matches.
+
+   ```typescript
+   await page.waitForURL(/\/auth\/login\?flow=/)   // regex
+   await page.waitForURL("**/dashboard**")          // glob — also matches query params
+   // wrong: await page.waitForURL("http://localhost:3000/auth/login")
+   ```
+
+2. **Use strong, dissimilar credentials.** Kratos rejects passwords that are too
+   similar to the identifier or that appear in a breach database — a weak fixture
+   password fails validation, not the flow you meant to test.
+
+   ```typescript
+   const email = `test-${Date.now()}-${Math.random().toString(36).slice(2)}@example.com`
+   const password = "Str0ngP@ssword!123"   // fixed, strong, not in any breach list
+   ```
+
+3. **Assert on Ory Elements' own testids, not form-level selectors.** Validation
+   messages render inside the auth card, keyed by Kratos UI message id (the
+   `4xxxxxx` range is validation errors), not on the flow wrapper.
+
+   ```typescript
+   page.locator('[data-testid^="ui/message/4"]')  // any validation error
+   page.locator('[data-testid="login-auth-card"]').getByText(/credentials|invalid/i)
+   // wrong: page.locator('[data-testid="login-flow"]').getByText(...) — errors aren't here
+   ```
+
+These selectors track the installed `@ory/elements-react` version; if a testid
+assertion breaks after an Elements upgrade, inspect the rendered DOM before
+assuming a flow bug.
 
 ## Fallback: rendering UI nodes by hand
 
@@ -376,8 +550,9 @@ Ory flow API changes manually.
 - Add social login providers: use {{REF_SOCIAL_LOGIN}}.
   Elements renders the buttons automatically once providers are
   configured server-side.
-- Add multi-factor authentication via Ory project settings — the
-  `<Login>` and `<Settings>` components handle the second-factor UI.
+- Add multi-factor authentication and passkeys — see **Enable MFA and
+  passkeys** above. Once the project is configured, the `<Login>` and
+  `<Settings>` components render the second-factor and passkey UI automatically.
 - Customize the identity schema for additional profile fields. Elements
   reads the schema from the flow and renders new fields automatically.
 - Set up webhooks for registration events.

package/assets/skills/social-login/SKILL.md

@@ -33,6 +33,15 @@ recommend switching to Ory Elements before adding more providers.
    recommend migrating to Ory Elements so social buttons render for
    free.
 
+**Social login depends on the same wiring as the rest of Ory.** Before
+debugging providers, confirm the base app is correct per the Correctness
+contract in {{REF_AUTH_SETUP}}: a first-party SDK URL (the tunnel or local
+gateway in dev, never `*.oryapis.com` in the browser), routes that match the
+project config, and your app origin listed in `allowed_return_urls`. The
+provider redirects the browser back *through Ory* to your app, so a missing
+return URL or a cross-site SDK URL produces a post-login error or 404 that looks
+like a provider bug but isn't.
+
 ## Step 1: Choose providers
 
 Ask the user which social login providers they want. Common options: