@pikku/skills 0.12.25 → 0.12.27

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pikku/skills",
-  "version": "0.12.25",
+  "version": "0.12.27",
   "description": "The Pikku agent skills — the instruction set coding agents read to build, wire and deploy Pikku projects",
   "author": "yasser.fadl@gmail.com",
   "license": "MIT",

package/skills/pikku-a11y/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: pikku-a11y
+description: >-
+  Accessibility rules (WCAG 2.2) for the app UI: labeled inputs, real buttons/links, keyboard and focus, contrast and not-color-alone, modals, reduced motion.
+  TRIGGER when: building forms or any interactive UI, icon-only buttons, modals/drawers, tables/lists with actions, keyboard/focus work, or the user mentions accessibility / screen readers / WCAG.
+  DO NOT TRIGGER when: working on backend functions, database, or deployment with no UI.
+installGroups: [client]
+---
+
+# Accessibility Rules
+
+Mantine components are accessible ONLY when used properly — the rules below are the
+"properly". They apply to every page; heading order, landmarks, and image alt text are
+covered in the `pikku-seo` skill and apply app-wide, not just on public pages.
+
+## Every input has a label
+
+- Use the `label` prop on every Mantine input — a placeholder is NOT a label (it
+  disappears on input and is never announced as one). Placeholder = example value only.
+- Use the `error` and `description` props for validation/help text — Mantine associates
+  them with the input for screen readers; a loose `<Text c="red">` next to the field
+  does not.
+- Icon-only controls (`ActionIcon`, icon `Button`) MUST have `aria-label={m.key()}`
+  naming the action ("Delete item", not "Trash icon").
+
+## Interactive = a real button or link
+
+- Never `onClick` on a `div`/`Box`/`Card` — it is invisible to keyboard and screen
+  readers. Use `Button`, `ActionIcon`, `UnstyledButton`, or `<Link>`; navigation is a
+  link (href), actions are buttons.
+- Everything reachable by Tab, activatable by Enter/Space. Never remove focus outlines
+  (the theme owns the focus ring), never set `tabIndex` greater than 0, never trap focus
+  yourself.
+- Whole-row/whole-card click: put the button/link INSIDE with the row as its label —
+  don't make the container clickable and unfocusable.
+
+## Don't say it with color alone
+
+- Status must carry text or an icon, not only a color: a Badge says "Overdue", a form
+  error has a message — a red tint by itself is invisible to colorblind users.
+- Contrast comes from the theme; don't undermine it by stacking `c="dimmed"` on small
+  text over tinted backgrounds. Body copy stays at least AA-readable.
+- Touch targets: WCAG 2.2 minimum 24px — don't shrink `ActionIcon`/`Checkbox` below
+  size `sm`, and keep adjacent row actions spaced.
+
+## Overlays and motion
+
+- Modals/drawers: use Mantine `Modal`/`Drawer` and ALWAYS pass `title` — that is what
+  gets announced; focus trap and Escape come built in. (This project uses drawers, not
+  dialogs.)
+- Landing-page animation (the only custom-CSS surface) respects
+  `prefers-reduced-motion: reduce` — gate transforms/parallax behind the media query.
+
+## Self-check before declaring UI done
+
+Tab through the page once: every control reachable and visibly focused, every input
+labeled, every icon button named, every status readable without color. A browser
+scenario proves the flow works, not that it is reachable without a mouse — this
+manual pass is the only check that does.

package/skills/pikku-admin-to-fabric/SKILL.md

@@ -0,0 +1,212 @@
+---
+name: pikku-admin-to-fabric
+description: 'Port a legacy back-office admin (ActiveAdmin, Django admin, Rails Admin, Laravel Nova, Filament) to Fabric admin screens, driven by a `.knowledge/` Product Blueprint. Covers the admin-DSL→Fabric mapping (resources→screens, index/column→tables, filter→query params, scope→query variants, member_action/collection_action→pikkuFuncs, permit_params→input schemas), the "the admin is half your app" audit, and admin-specific permissions. TRIGGER when: porting/rebuilding a legacy app that has a generated/DSL-driven admin, or the user says "port the admin screens" / "implement the admin". DO NOT TRIGGER when: no legacy admin exists (use pikku-fabric to build screens fresh), or the app is being extended rather than ported (use pikku-build).'
+installGroups: [fabric]
+argument-hint: '<path to .knowledge/> [resource to port next]'
+---
+
+# Legacy admin → Fabric admin screens
+
+## Agent Operating Procedure
+
+1. **Count first.** How many commands cite the admin? That number decides whether this is a chore or a third of the project.
+2. **The blueprint already has the commands.** Do not re-derive them from the DSL. Map to them.
+3. **Port the actions before the screens.** A screen with no action behind it is a table; the actions are the product.
+4. **One resource per slice**, same as `pikku-blueprint-to-fabric`. Verify green before the next.
+5. **An admin permission is not a checkbox.** Legacy admins routinely authenticate and do not authorize. Do not port that.
+6. **Record what you did NOT port**, per resource, in the parity report.
+
+## The mistake this skill exists to prevent
+
+> "It's just the admin — CRUD screens over the same tables. We'll scaffold it at the end."
+
+This is wrong in a specific, measurable way, and you can check it in one command
+before you believe anything else in this file:
+
+```bash
+node -e "
+const c = require('./.knowledge/commands.json').commands
+const admin = c.filter(x => (x.evidence||[]).some(e => (e.file||'').match(/admin/)))
+console.log(admin.length + ' of ' + c.length + ' commands live in the admin')
+"
+```
+
+On a real Rails app (Applause, 39 ActiveAdmin resources, 5,545 lines of DSL) the
+answer was **82 of 187 — 44%**, plus 71 of 223 API surfaces. The admin was not a
+side panel over the customer-facing app. It was nearly **half the application's
+write surface**, and a large share of those commands existed *nowhere else*:
+issue a refund, retrigger a payment, queue a sync, impersonate a user, mark a
+blade returned, reassign a company. There is no customer screen for any of them.
+
+So: the admin is not the last 10% of the port. Budget it as what the count says.
+
+**Corollary — the admin is where the unguarded capabilities live.** A
+`member_action :impersonate` or `:create_stripe_refund` is a command that moves
+money or identity, defended in legacy by nothing more than "you reached an
+`/admin` URL". Every one of these needs a real `pikkuPermission` in the rebuild,
+and writing them is the point of the port, not overhead on top of it.
+
+## Stage 0 — Preflight
+
+- The `.knowledge/` blueprint must exist and validate (`0 error(s)`). If not, run
+  **pikku-software-archaeology** first. This skill maps to the blueprint; it does
+  not parse Ruby.
+- Read `parity-*.md` for the domains you are about to touch. Renames decided in an
+  earlier slice (a `tenant` that became a `Market`, a `membership_level` that
+  became a `certification_level`) are binding here. An admin screen that reintroduces
+  the old word undoes the decision.
+- Run the count above and say the number out loud in your plan.
+
+## Stage 1 — Inventory the DSL
+
+Every generated admin is the same six ideas under different syntax. Inventory
+them, do not read them line by line:
+
+```bash
+# ActiveAdmin
+grep -rhoE "^\s{0,4}(index|show|form|filter|scope|action_item|member_action|collection_action|batch_action|permit_params|csv|sidebar|panel|actions)\b" app/admin/*.rb | sort | uniq -c | sort -rn
+grep -rhoE "(member_action|collection_action) :[a-z_]+" app/admin/*.rb | sort -u
+```
+
+| Legacy | Also called | Becomes in Fabric |
+|---|---|---|
+| `ActiveAdmin.register X` / `class XAdmin` | resource, ModelAdmin, Nova Resource | one TanStack route + one screen |
+| `index do … column :x` | `list_display`, `columns()` | a Mantine `Table`/`DataTable`, columns from the query's return type |
+| `filter :x` | `list_filter`, `searchable` | typed input fields on the list query |
+| `scope :active` | `get_queryset` variants, `Nova::Filters` | a named variant of the list query — NOT a new function per scope |
+| `form do f.input …` | `fields()`, `fieldsets` | a Mantine form; inputs from the command's zod input schema |
+| `permit_params` | `fields`, `$fillable` | you already have this: it is the command's input schema. Cross-check, don't re-derive. |
+| `member_action :foo` | custom action, `Nova::Actions` | **a `pikkuFunc`** — almost always already in `commands.json` |
+| `collection_action :foo` | bulk action | a `pikkuFunc` taking a set |
+| `batch_action` | admin action | a `pikkuFunc` taking ids[] |
+| `csv do … end` | export | a readonly func returning rows; render client-side |
+| `panel`/`sidebar` | inlines, `relations` | a section on the show screen, fed by a related query |
+| `action_item` | — | a button. It is not a capability; find the action it calls. |
+
+**`action_item` vs `member_action` is the distinction that matters.** An
+`action_item` is a *button*; a `member_action` is a *capability*. Legacy files
+pair them, and a fast reader counts the buttons. Count the capabilities.
+
+## Stage 2 — Map actions to blueprint commands (do this before any UI)
+
+For each `member_action`/`collection_action`, find its command in
+`commands.json`. Three outcomes, and the third is the valuable one:
+
+1. **Found** — the archaeology already lifted it (`ArchiveProduct`,
+   `CancelInvoice`). Wire the screen to it. Nothing to build.
+2. **Found under a different name** — the blueprint names concepts in domain
+   language, the DSL names them after routes. `member_action :rerun` may be
+   `RetryWebhookDelivery`. Match on behaviour, not spelling. **Use the blueprint's
+   name.**
+3. **Not found** — stop. Either the archaeology missed a command (fix
+   `.knowledge/`, do not paper over it here) or the action is dead code. Both are
+   findings. Do not quietly invent a command to fill the gap: a command with no
+   blueprint entry has no evidence, no policy and no actor, and you will not
+   notice which.
+
+Two legacy shapes to expect and *not* reproduce:
+
+- **`*_form` + `*` action pairs** (`create_stripe_refund_form` +
+  `create_stripe_refund`, `issue_payment_form` + `issue_payment`). The `_form` half
+  is a GET that renders a modal — it is a *screen*, not a capability. It collapses
+  into the screen; only the second half is a `pikkuFunc`. Porting both doubles your
+  command count with phantoms.
+- **A `member_action` that only redirects** to another action. That is routing.
+- **An action disabled in the production environment is not a live capability.**
+  Grep the environment guards before porting:
+  ```bash
+  grep -rn "env.production?\|env\.development?\|ENV\[" app/admin/*.rb
+  ```
+  On Applause, both halves of `create_stripe_refund` open with
+  `return redirect_to … if Rails.env.production?` — the admin refund screen has
+  never run in production, and refunds are actually issued in the Stripe dashboard.
+  Porting it faithfully would ship a prominent button for a capability the business
+  does not use through this app, and quietly move refunds into a surface nobody has
+  ever tested. Whether it should now exist is a **product decision**, not a port.
+  Check the guard is on the *mutating* half too: if the form is blocked and the POST
+  is not, you have found a hole rather than a dead feature.
+
+## Stage 3 — Permissions (the part legacy skipped)
+
+Generated admins authenticate and then trust. The whole admin sits behind one
+"is an admin" check, and every action inside it is equally reachable — refunds,
+impersonation and editing an FAQ all guarded identically.
+
+- Read `policies.json` for the real rule per command. If the blueprint says the
+  policy is `enforcedBy: nothing`, that is a **gap you are now closing**, not a
+  behaviour to port.
+- With Better Auth's `admin()` plugin, `user.role` is the platform role and
+  `session.impersonated_by` is set during impersonation. Both are yours already.
+- **Money and identity actions deserve their own permission**, not the blanket one.
+  If the blueprint offers no rule, that is a `decisionsNeeded` entry — ask, do not
+  invent.
+- **Impersonation:** Better Auth's `impersonateUser`/`stopImpersonating` replace the
+  hand-rolled version. If the legacy audit table recorded only the *start* of an
+  impersonation (no `ended_at`, no session id), do not port it — the Fabric audit
+  table already answers "what did they do while impersonating", which was the whole
+  question it failed to answer.
+
+## Stage 4 — Screens
+
+- The list query is `pikkuSessionlessFunc` + `readonly: true`; filters and scopes
+  are **input fields on one function**, not one function per scope. Legacy needs a
+  method per scope because the DSL has no parameters. You do not.
+- Columns come from the query's return type. If a column exists in the DSL but not
+  in the type, the DSL was computing it in Ruby per row — that is an N+1 wearing a
+  column, and it belongs in the query.
+- Reuse the app's Mantine theme. An admin styled differently from the product is
+  how design systems fork.
+- **Server-computed charts** (chartkick/groupdate and friends) do not port. The
+  aggregation becomes a real query; the plot becomes a chart component. This is the
+  one genuinely expensive screen in most admins — cost it separately.
+- **Drag-and-drop reordering** (`acts_as_list`, sortable tables) is custom logic,
+  not a table. Port the position semantics deliberately.
+
+## Stage 5 — Verify and report
+
+```bash
+pikku all && pikku fabric validate --json
+```
+
+Per resource, the parity report records:
+
+- **Ported** — screens + which blueprint commands back them.
+- **Deliberately not ported** — with the reason. Expect: `*_form` halves, dead
+  actions, single-member enums, screens over dropped tables.
+- **Now authorized** — every action that was guarded by "reached an /admin URL"
+  and now has a real permission. This is the port's dividend; name it.
+- **Still open** — actions whose rule the blueprint could not settle.
+
+## Red Flags
+
+| Thought | Reality |
+|---|---|
+| "The admin is just CRUD, scaffold it last" | Run the count. It was 44% of commands on a real app, and those commands exist nowhere else. |
+| "I'll read the DSL and write the commands" | The blueprint already has them, with evidence, actors and policies. Map; don't re-derive. |
+| "One function per scope" | A scope is a filter argument. The DSL needed a method because it has no parameters. |
+| "`action_item` count = capability count" | Buttons aren't capabilities. Count `member_action`/`collection_action`. |
+| "Port `create_stripe_refund_form` too" | It is a GET that renders a modal. It is a screen. Only the non-`_form` half is a command. |
+| "Admins are admins; one permission is fine" | That is the legacy bug. Refunds and FAQ edits are not the same risk. |
+| "The admin action isn't in commands.json, I'll add it" | Stop. Either the archaeology missed it (fix the blueprint) or it is dead. Both are findings. |
+| "I'll restyle the admin, it's internal" | An admin off the product's theme is how a design system forks. |
+
+## Quick Reference
+
+```bash
+# 1. how much of the app is actually the admin?
+node -e "const c=require('./.knowledge/commands.json').commands;console.log(c.filter(x=>(x.evidence||[]).some(e=>(e.file||'').match(/admin/))).length+'/'+c.length)"
+
+# 2. inventory the capabilities (not the buttons)
+grep -rhoE "(member_action|collection_action) :[a-z_]+" app/admin/*.rb | sort -u
+
+# 3. per resource: map actions -> commands.json, then build the screen
+# 4. verify
+pikku all && pikku fabric validate --json
+```
+
+## Related skills
+
+- **pikku-software-archaeology** — produces the `.knowledge/` blueprint this needs.
+- **pikku-blueprint-to-fabric** — the parent port; run this per-domain alongside it.
+- **pikku-auth** — roles, ban and impersonation, and the scopes that gate them.
+- **pikku-fabric** — screens, theme, Mantine conventions.

package/skills/pikku-architect/SKILL.md

@@ -11,6 +11,7 @@ description: >-
   NOT TRIGGER when: the milestone notes themselves are still being written (use pikku-knowledge),
   the plan already exists and the job is to build it (use pikku-build), or the ask is a one-off
   edit to a working app.
+installGroups: [core]
 ---
 
 # Plan one milestone

package/skills/pikku-auth/references/better-auth.md

@@ -15,7 +15,6 @@ The only acceptable auth implementation in a Pikku app is the one described in t
 
 ---
 
-
 ## Installation
 
 ```bash
@@ -448,9 +447,14 @@ someone" means **a particular kind of user** rather than one fixed admin.
 Register it explicitly — it is not automatic:
 
 ```typescript
-import { pikkuActor } from '@pikku/better-auth'
-
-plugins: [pikkuActor({ secret: SCENARIO_ACTOR_SECRET })]
+import { ACTOR_SIGN_IN_OPT_IN_ENV, pikkuActor } from '@pikku/better-auth'
+
+plugins: [
+  pikkuActor({
+    secret: SCENARIO_ACTOR_SECRET,
+    allowSignIn: await variables.get(ACTOR_SIGN_IN_OPT_IN_ENV),
+  }),
+]
 ```
 
 `POST ${basePath}/sign-in/actor` `{ email, secret, name? }` → 200 + the normal
@@ -481,9 +485,19 @@ itself instead.
 A stage that genuinely must run scenarios opts in on purpose, with
 `PIKKU_ALLOW_ACTOR_SIGN_IN=passwordless-actor-sign-in`. Any other value is
 ignored and warned about, so the hatch cannot be opened by copying a `true` from
-the line above, and it is the only hatch — there is no build-time option, because
-an option compiled into the bundle cannot be audited from the environment it
-runs in.
+the line above.
+
+**Pass it in on any runtime without a populated `process.env`.** The gate reads
+the environment by default, which is enough for Node but not for a Worker: there
+the opt-in arrives as a binding and reaches user code through the variables
+service, so a gate left to `process.env` stays shut on exactly the stages a
+deployment targets. `allowSignIn` takes the value the caller already read —
+`await variables.get(ACTOR_SIGN_IN_OPT_IN_ENV)` — and is checked against the same
+literal, near-miss warning included. It is deliberately a value and not a flag:
+what opens the gate is still something the deployment set and an operator can
+read back out of it, never something compiled into the bundle. A value passed
+here is the one consulted, so the environment cannot quietly override what the
+stage was configured with.
 
 **Signing in and provisioning are separate powers.** An unknown address becomes
 an `actor: true` row only under `pikku dev`. With the opt-in set, a stage signs
@@ -624,3 +638,107 @@ export const auth = pikkuBetterAuth(async ({ secrets, variables, kysely }) => be
 - Export exactly ONE `pikkuBetterAuth` per project; the CLI generates a single catch-all worker for all auth routes.
 - `betterAuthSession({ auth })` (generated) bridges the better-auth session into the Pikku session on every request — you never add it by hand.
 - MFA, organizations, passkeys, etc. are better-auth plugins: add them to `betterAuth({ plugins: [...] })`. The catch-all route already forwards their endpoints.
+
+---
+
+## Post-signup side effects
+
+Anything that must happen after a user signs up — a welcome email, seeding a first
+row, creating a personal organization — goes in `databaseHooks.user.create.after`
+inside the `betterAuth({...})` config. Never a custom signup RPC that writes the
+user itself: better-auth owns the `user` table, and a second write path desyncs it
+from the session bridge.
+
+## Two-factor (2FA / MFA)
+
+TOTP authenticator apps, email/SMS OTP, backup codes and trusted devices are all
+better-auth's `twoFactor()` plugin. Never hand-roll TOTP or OTP.
+
+1. **Enable + migrate** — add `twoFactor({ issuer: '<AppName>' })` to the `plugins`
+   array in the `pikkuBetterAuth` factory, then generate its schema and apply it as a
+   migration like any other table change. Run the CLI at the version of better-auth the
+   project actually has installed (`npx @better-auth/cli@<that version> generate`) — a
+   bare `npx @better-auth/cli` resolves the latest release, which can emit a schema for
+   a library you are not running. `twoFactorSecret` lands on `user`.
+2. **Client** — add `twoFactorClient({ onTwoFactorRedirect() { /* go to /2fa */ } })`
+   to `createAuthClient({ plugins: [...] })`, and expose thin wrappers
+   (`enable2FA`, `verifyTotp`, `disable2FA`, …) rather than leaking the raw
+   `authClient`, same as every other auth call.
+3. **OTP delivery** — `otpOptions.sendOTP` goes through the injected email service
+   and a rendered template, not a raw `sendEmail`. Set `storeOTP: 'encrypted'`.
+4. **Sign-in flow** — the challenge is raised on the three CREDENTIAL endpoints:
+   `signIn.email`, `signIn.username` and `signIn.phoneNumber`. Check
+   `context.data.twoFactorRedirect` in `onSuccess`; if true, route to a `/2fa` page
+   and verify via `verifyTotp`/`verifyOtp`/`verifyBackupCode` (`trustDevice: true`
+   for a 30-day trusted device). The response also carries `twoFactorMethods`
+   (`'totp'` only once that user has a verified secret, `'otp'` whenever
+   `otpOptions.sendOTP` is configured) — render the choice from it rather than
+   assuming TOTP. The session cookie is only created after verification: the
+   credential handler's session is deleted while the challenge is in flight, so a
+   hook reading `ctx.context.newSession` after sign-in must null-check it.
+5. **UI** — a QR rendered from `data.totpURI` plus the `data.backupCodes` list.
+   Enabling, disabling and regenerating backup codes all require the user's
+   password.
+
+TOTP secrets and backup codes are encrypted at rest with the auth secret, and
+`/two-factor/*` is rate-limited (3/10s) out of the box.
+
+**2FA gates credential sign-in only.** Magic link, email OTP and OAuth are not
+matched by the plugin's hook, so a user with 2FA enabled who signs in through one
+of them is NOT challenged. If every route into the app must be gated, either do not
+offer the passwordless ones to 2FA users or add your own check — enabling the
+plugin does not do it.
+
+## Security hardening
+
+The `pikkuBetterAuth` factory — where `betterAuth({...})` is built — is the one
+place to harden. Everything below is a `betterAuth` option, not a pikku one.
+
+- **Secret** — `BETTER_AUTH_SECRET` comes from the injected secrets service
+  (`await secrets.getSecret('BETTER_AUTH_SECRET')`), never `process.env`, a
+  literal, or a fallback default. 32+ chars, high entropy
+  (`openssl rand -base64 32`). Better Auth rejects placeholder secrets in
+  production.
+- **Trusted origins** — the `baseURL` origin is auto-trusted, so a single-domain
+  app serving its API same-origin needs nothing. Add `trustedOrigins` (or a
+  comma-separated `BETTER_AUTH_TRUSTED_ORIGINS` variable; wildcards like
+  `*.example.com` allowed) ONLY when the browser origin differs from the API
+  origin — embedded, preview, or custom-domain deployments. An untrusted
+  `callbackURL`/`redirectTo`/`origin` is a 403.
+- **CSRF** — keep it on (`advanced.disableCSRFCheck: false`, the default). A
+  proxy in front of the app must preserve the `/api/auth/*` prefix so origin
+  checks still work; do not disable the check to "fix" a redirect.
+- **Rate limiting** — on by default in production (100/10s global, 3/10s on
+  sign-in/up/change-password). `storage: 'memory'` resets on restart, so a
+  deployed app wants `storage: 'database'`. Tighten sensitive routes with
+  `customRules`, e.g. `'/sign-in/email': { window: 60, max: 5 }` — the key is matched
+  against the path with the base path ALREADY STRIPPED, so a rule written as
+  `'/api/auth/sign-in/email'` matches nothing and silently leaves the route on the
+  default.
+- **Cookies & sessions** — `httpOnly`, `sameSite: 'lax'` and `path: '/'` are
+  unconditional, but `secure` and the `__Secure-` name prefix are NOT: they follow a
+  `baseURL` on `https://` (or production, or an explicit
+  `advanced.useSecureCookies: true`). A deployment whose TLS terminates at a proxy
+  and passes an `http://` baseURL through therefore ships session cookies with no
+  `secure` flag — set `useSecureCookies` there rather than assuming. Defaults are
+  `session.expiresIn` 7d and
+  `updateAge` 1d. Add `freshAge` for sensitive actions, and
+  `cookieCache: { strategy: 'jwe' }` if the session carries sensitive data — see
+  the cookieCache section above, which you want enabled regardless. Only enable
+  `crossSubDomainCookies` if auth is genuinely shared across subdomains.
+- **OAuth tokens** — set `account.encryptOAuthTokens: true` (AES-256-GCM) if you
+  store provider tokens to call their APIs later.
+- **Audit** — drive auth events from `databaseHooks` (`session.create.after`,
+  `user.update.after` for email changes, `account.create.after` for links) into
+  whatever audit service the app injects, never a bespoke audit table wired into
+  a function body. Returning `false` from a `before` hook blocks the operation.
+- **Background tasks** — on a serverless target, hand genuinely disposable work
+  (analytics, logging) to `advanced.backgroundTasks.handler` → `ctx.waitUntil(promise)`
+  so it does not delay the response. Not mail: the default handler is
+  `p.catch(() => {})`, so anything that must actually arrive — an invitation, a
+  password reset — is lost without a trace if the platform reaps the request first.
+  Better Auth sends its own through `runInBackgroundOrAwait`, which awaits when no
+  handler is configured; do the same for yours.
+- **Enumeration** — handled already (generic "Invalid credentials", dummy work on
+  unknown users). Keep your own error copy generic too; never leak "user not
+  found".