@cosmicdrift/kumiko-bundled-features 0.242.0 → 0.243.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cosmicdrift/kumiko-bundled-features",
-  "version": "0.242.0",
+  "version": "0.243.1",
   "description": "Built-in features — tenant, user, auth, delivery. The stuff you'd rewrite anyway, already typed.",
   "license": "BUSL-1.1",
   "author": "Marc Frost <marc@cosmicdriftgamestudio.com>",
@@ -130,12 +130,12 @@
     "./workflow-runner": "./src/workflow-runner/index.ts"
   },
   "dependencies": {
-    "@cosmicdrift/kumiko-dispatcher-live": "0.242.0",
-    "@cosmicdrift/kumiko-framework": "0.242.0",
-    "@cosmicdrift/kumiko-headless": "0.242.0",
-    "@cosmicdrift/kumiko-renderer": "0.242.0",
-    "@cosmicdrift/kumiko-renderer-web": "0.242.0",
-    "@cosmicdrift/kumiko-types": "0.242.0",
+    "@cosmicdrift/kumiko-dispatcher-live": "0.243.1",
+    "@cosmicdrift/kumiko-framework": "0.243.1",
+    "@cosmicdrift/kumiko-headless": "0.243.1",
+    "@cosmicdrift/kumiko-renderer": "0.243.1",
+    "@cosmicdrift/kumiko-renderer-web": "0.243.1",
+    "@cosmicdrift/kumiko-types": "0.243.1",
     "@mollie/api-client": "^4.5.0",
     "@node-rs/argon2": "^2.0.2",
     "@types/mailparser": "^3.4.6",
@@ -164,7 +164,7 @@
   "devDependencies": {
     "@testing-library/user-event": "^14.6.1",
     "@types/qrcode": "^1.5.5",
-    "@cosmicdrift/kumiko-locale-de": "0.242.0",
-    "@cosmicdrift/kumiko-locale-es": "0.242.0"
+    "@cosmicdrift/kumiko-locale-de": "0.243.1",
+    "@cosmicdrift/kumiko-locale-es": "0.243.1"
   }
 }

package/src/auth-email-password/changes.json

@@ -5,6 +5,13 @@
     "title": "Self-signup provisions TenantAdmin on the new tenant",
     "detail": "INITIAL_SIGNUP_ROLES is TenantAdmin (was Admin) so the first user on a new tenant can invite peers and manage memberships without elevation dead-ends."
   },
+  {
+    "version": "0.167.1",
+    "type": "improvement",
+    "title": "accountLockout is reachable through runProdApp/runDevApp (fw#1627).",
+    "detail": "accountLockout was an option on createAuthEmailPasswordFeature, but both wrappers mount auth-email-password themselves and their auth options only knew accountUnlock — an app on either entrypoint had no way to turn brute-force protection on. RunProdAppAuthOptions and RunDevAppAuthOptions now carry accountLockout and composeFeatures passes it through.",
+    "migration": "Opt-in, nothing breaks without it. Two things to know before relying on it: without ctx.redis the lockout is silently skipped in login.write.ts — no error, no warning, no protection — so treat Redis as a deploy invariant, and prove the lockout with a behavioural test instead of assuming the mount is enough."
+  },
   {
     "version": "0.165.1",
     "type": "breaking",
@@ -12,13 +19,6 @@
     "detail": "The four positional args (LoginComponent, loginProps, MfaVerifyComponent, MfaSetupComponent) did not scale past two optional MFA params. Shipped in the stranded 2.0.0 major and carried into the 0.165.1 line.",
     "migration": "Rewrite call sites as makeAuthGate({ loginScreen, loginScreenProps, mfaVerifyScreen, mfaSetupScreen }). Type-check catches every occurrence."
   },
-  {
-    "version": "0.167.1",
-    "type": "improvement",
-    "title": "accountLockout is reachable through runProdApp/runDevApp (fw#1627).",
-    "detail": "accountLockout was an option on createAuthEmailPasswordFeature, but both wrappers mount auth-email-password themselves and their auth options only knew accountUnlock \u2014 an app on either entrypoint had no way to turn brute-force protection on. RunProdAppAuthOptions and RunDevAppAuthOptions now carry accountLockout and composeFeatures passes it through.",
-    "migration": "Opt-in, nothing breaks without it. Two things to know before relying on it: without ctx.redis the lockout is silently skipped in login.write.ts \u2014 no error, no warning, no protection \u2014 so treat Redis as a deploy invariant, and prove the lockout with a behavioural test instead of assuming the mount is enough."
-  },
   {
     "version": "0.162.0",
     "type": "improvement",
@@ -28,19 +28,19 @@
   {
     "version": "0.154.1",
     "type": "fix",
-    "title": "Export `LoginScreen`/`LoginScreenProps`/`AuthLegalLink` from `@cosmicdrift/kumiko-bundled\u2026",
-    "detail": "Export `LoginScreen`/`LoginScreenProps`/`AuthLegalLink` from `@cosmicdrift/kumiko-bundled-features/auth-email-password/web`. Every other auth screen (ForgotPasswordScreen, SignupScreen, ResetPasswordScreen, \u2026) was already exported from the barrel with its props type; `LoginScreen` was missed. `makeAuthGate`'s second parameter is typed `LoginScreenProps`, so consumers passing a typed `loginScreenProps` override (e.g. `@cosmicdriftgamestudio/kumiko-designer`) couldn't import the type at all. - @cosmicdrift/kumiko-framework@0.154.1 - @cosmicdrift/kumiko-dispatcher-live@0.154.1 - @cosmicdrift/kumiko-headless@0.154.1 - @cosmicdrift/kumiko-renderer@0.154.1 - @cosmicdrift/kumiko-renderer-web@0.154.1"
+    "title": "Export `LoginScreen`/`LoginScreenProps`/`AuthLegalLink` from `@cosmicdrift/kumiko-bundled…",
+    "detail": "Export `LoginScreen`/`LoginScreenProps`/`AuthLegalLink` from `@cosmicdrift/kumiko-bundled-features/auth-email-password/web`. Every other auth screen (ForgotPasswordScreen, SignupScreen, ResetPasswordScreen, …) was already exported from the barrel with its props type; `LoginScreen` was missed. `makeAuthGate`'s second parameter is typed `LoginScreenProps`, so consumers passing a typed `loginScreenProps` override (e.g. `@cosmicdriftgamestudio/kumiko-designer`) couldn't import the type at all. - @cosmicdrift/kumiko-framework@0.154.1 - @cosmicdrift/kumiko-dispatcher-live@0.154.1 - @cosmicdrift/kumiko-headless@0.154.1 - @cosmicdrift/kumiko-renderer@0.154.1 - @cosmicdrift/kumiko-renderer-web@0.154.1"
   },
   {
     "version": "0.151.0",
     "type": "improvement",
-    "title": "`auth-email-password/web` no longer exports `LoginScreen`/`LoginScreenProps` directly \u2014 u\u2026",
-    "detail": "`auth-email-password/web` no longer exports `LoginScreen`/`LoginScreenProps` directly \u2014 use the new `createLoginRoute({ loginScreenProps, mfaVerifyScreen, unaffected (they already build on the same logic internally now). Why: a raw `<LoginScreen />` render has no MFA-challenge handling unless the caller remembers to hand-wire `onMfaChallenge` + swap in a verify screen itself \u2014 exactly how kumiko-framework#266's login-time MFA step went missing in a real app's standalone apex/marketing login route (it renders outside `emailPasswordClient`'s own gate, which already handled this correctly). `createLoginRoute` is the one place this logic lives now, for both the gated and standalone cases \u2014 there's no lower-level piece left to misuse. The `apex-surface-auth` recipe is updated to match."
+    "title": "`auth-email-password/web` no longer exports `LoginScreen`/`LoginScreenProps` directly — u…",
+    "detail": "`auth-email-password/web` no longer exports `LoginScreen`/`LoginScreenProps` directly — use the new `createLoginRoute({ loginScreenProps, mfaVerifyScreen, unaffected (they already build on the same logic internally now). Why: a raw `<LoginScreen />` render has no MFA-challenge handling unless the caller remembers to hand-wire `onMfaChallenge` + swap in a verify screen itself — exactly how kumiko-framework#266's login-time MFA step went missing in a real app's standalone apex/marketing login route (it renders outside `emailPasswordClient`'s own gate, which already handled this correctly). `createLoginRoute` is the one place this logic lives now, for both the gated and standalone cases — there's no lower-level piece left to misuse. The `apex-surface-auth` recipe is updated to match."
   },
   {
     "version": "0.131.0",
     "type": "improvement",
-    "title": "App-Mounting 2.0 S\u00e4ule A: Mid-Level-Widget-Kit in renderer-web (StatCard, MiniStat, Secti\u2026",
-    "detail": "App-Mounting 2.0 S\u00e4ule A: Mid-Level-Widget-Kit in renderer-web (StatCard, MiniStat, SectionCard, StatusBadge, ProgressBar, CollapsibleSection, DetailList, ModeSwitch, StatusBarChart, TimeseriesChart, EmptyState/LoadingState/ErrorState, QueryTable) + Status-Farb-Tokens (--color-status-\\*). Neue Hooks useMutation + useDisclosure. Neues Core-Primitive Link (default/button/muted), Button-Variant \"link\", Text-Variant \"muted\"; auth-email-password nutzt sie (authButtonClass/authMutedLinkClass entfernt)."
+    "title": "App-Mounting 2.0 Säule A: Mid-Level-Widget-Kit in renderer-web (StatCard, MiniStat, Secti…",
+    "detail": "App-Mounting 2.0 Säule A: Mid-Level-Widget-Kit in renderer-web (StatCard, MiniStat, SectionCard, StatusBadge, ProgressBar, CollapsibleSection, DetailList, ModeSwitch, StatusBarChart, TimeseriesChart, EmptyState/LoadingState/ErrorState, QueryTable) + Status-Farb-Tokens (--color-status-\\*). Neue Hooks useMutation + useDisclosure. Neues Core-Primitive Link (default/button/muted), Button-Variant \"link\", Text-Variant \"muted\"; auth-email-password nutzt sie (authButtonClass/authMutedLinkClass entfernt)."
   }
 ]

package/src/auth-foundation/changes.json

@@ -5,16 +5,16 @@
     "title": "validateSessionStoreMultiplicity accepts zero sessionStore providers (fw#1547).",
     "detail": "A machine-API-only deployment (PAT-bearer auth, no browser sessions) can mount auth-foundation without also mounting sessions."
   },
-  {
-    "version": "0.161.0",
-    "type": "improvement",
-    "title": "tenantResolver/tenantExistence extension points, sessionStore without auth.sessions (fw#1372-1375).",
-    "detail": "Auth-foundation migration: tenant resolution and tenant-existence become extension points, sessionStore is wired without going through auth.sessions, AnonymousAccessConfig is slimmed down. See the auth-foundation-providers recipe."
-  },
   {
     "version": "0.165.0",
     "type": "fix",
     "title": "Allow zero tokenVerifier when sessionStore present",
     "detail": "Auth foundation now accepts zero tokenVerifier when a sessionStore is configured — prevents crash in session-store-only setups."
+  },
+  {
+    "version": "0.161.0",
+    "type": "improvement",
+    "title": "tenantResolver/tenantExistence extension points, sessionStore without auth.sessions (fw#1372-1375).",
+    "detail": "Auth-foundation migration: tenant resolution and tenant-existence become extension points, sessionStore is wired without going through auth.sessions, AnonymousAccessConfig is slimmed down. See the auth-foundation-providers recipe."
   }
 ]

package/src/cap-overview/changes.json

@@ -1,14 +1,14 @@
 [
-  {
-    "version": "0.224.0",
-    "type": "improvement",
-    "title": "Add cap-overview feature: tier + cap usage visibility per tenant.",
-    "detail": "New read-only bundled feature. SystemAdmin gets a paged, searchable tenant list with tier/billing columns and per-cap usage bars, plus a per-tenant dashboard reachable from the list. TenantAdmin gets a 'My usage' dashboard showing their own tenant's cap usage as cards. Reads tier-engine, billing-foundation and tenant projections plus caller-supplied CapSpec usage callbacks; every handler enforces explicit tenant scoping (no ambient tenant filter, cross-tenant reads require SystemAdmin + acknowledgeCrossTenant)."
-  },
   {
     "version": "0.233.0",
     "type": "improvement",
     "title": "CapSpec.limit can now return null for an unlimited usage meter.",
     "detail": "A CapSpec's `limit(tier)` may now return `null` to mean unlimited: the cap is still counted (used shows the raw count) but never capped, has no percent, and renders no progress bar or badge. This is a distinct meaning from `limit <= 0`, which unchanged still means 'not part of this tier' and renders as 0/0%."
+  },
+  {
+    "version": "0.224.0",
+    "type": "improvement",
+    "title": "Add cap-overview feature: tier + cap usage visibility per tenant.",
+    "detail": "New read-only bundled feature. SystemAdmin gets a paged, searchable tenant list with tier/billing columns and per-cap usage bars, plus a per-tenant dashboard reachable from the list. TenantAdmin gets a 'My usage' dashboard showing their own tenant's cap usage as cards. Reads tier-engine, billing-foundation and tenant projections plus caller-supplied CapSpec usage callbacks; every handler enforces explicit tenant scoping (no ambient tenant filter, cross-tenant reads require SystemAdmin + acknowledgeCrossTenant)."
   }
 ]

package/src/crypto-shredding/changes.json

@@ -1,4 +1,12 @@
 [
+  {
+    "version": "0.167.0",
+    "type": "breaking",
+    "title": "Test-only reset helpers moved from /crypto to /testing (fw#1631).",
+    "detail": "resetPiiSubjectKmsForTests and resetBlindIndexKeyForTests are no longer exported by the production barrels. The functions did not change — only the export path. Why it matters beyond tidiness: resetPiiSubjectKmsForTests clears the injected KMS, after which encryptForStorage sees no adapter and writes subject-annotated fields in plaintext, with no error and no log. Reachable from a production barrel, that is one stray import away from silent plaintext PII.",
+    "migration": "Change the import in your test files: `import { resetPiiSubjectKmsForTests } from \"@cosmicdrift/kumiko-framework/testing\"` instead of `.../crypto`. Type-check catches every occurrence; nothing else changes. Apps mounting crypto-shredding typically hit this in every test that configures an InMemoryKmsAdapter.",
+    "codemod": "scripts/codemod/crypto-shredding-testing-move.ts"
+  },
   {
     "version": "0.166.0",
     "type": "improvement",
@@ -11,14 +19,6 @@
     "title": "KmsWiringEnv accepts process.env directly (fw#1618).",
     "detail": "All members being optional made TypeScript's weak-type detection reject ProcessEnv for having no properties in common, which forced every consumer into a cast or a six-key mapping — the boilerplate fw#1617 set out to remove."
   },
-  {
-    "version": "0.167.0",
-    "type": "breaking",
-    "title": "Test-only reset helpers moved from /crypto to /testing (fw#1631).",
-    "detail": "resetPiiSubjectKmsForTests and resetBlindIndexKeyForTests are no longer exported by the production barrels. The functions did not change — only the export path. Why it matters beyond tidiness: resetPiiSubjectKmsForTests clears the injected KMS, after which encryptForStorage sees no adapter and writes subject-annotated fields in plaintext, with no error and no log. Reachable from a production barrel, that is one stray import away from silent plaintext PII.",
-    "migration": "Change the import in your test files: `import { resetPiiSubjectKmsForTests } from \"@cosmicdrift/kumiko-framework/testing\"` instead of `.../crypto`. Type-check catches every occurrence; nothing else changes. Apps mounting crypto-shredding typically hit this in every test that configures an InMemoryKmsAdapter.",
-    "codemod": "scripts/codemod/crypto-shredding-testing-move.ts"
-  },
   {
     "version": "0.165.3",
     "type": "improvement",

package/src/personal-access-tokens/changes.json

@@ -1,15 +1,15 @@
 [
-  {
-    "version": "0.117.0",
-    "type": "improvement",
-    "title": "personal-access-tokens: add `toggleable` option so the whole feature can be tier-gated vi…",
-    "detail": "personal-access-tokens: add `toggleable` option so the whole feature can be tier-gated via the tier-engine (mirrors ledger/tags). Pass `{ toggleable: { default: false } }` for fail-closed gating — PAT is then off until a tier lists `\"personal-access-tokens\"` in its features. Omitting the option keeps PAT always-on (no behaviour change for existing consumers)."
-  },
   {
     "version": "0.202.0",
     "type": "breaking",
     "title": "personal-access-tokens: `write:create` now requires `currentPassword` (+ `mfaCode` if MFA enrolled) (e91d4cb).",
     "detail": "`personal-access-tokens:write:create` now requires `currentPassword` (verified against the caller's password hash) before minting a token, and rejects when the caller has MFA enrolled and `mfaCode` is missing or wrong — a session cookie alone is no longer enough to stand up a durable API credential. `expiresInDays` now defaults to 90 days instead of never-expiring when omitted (the existing 3650-day cap is unchanged, so a genuinely long-lived token is still possible if requested explicitly). Changing a user's password, or enabling/disabling MFA, now revokes all of that user's live PAT tokens — mirrors the existing session auto-revoke-on-password-change behavior. `run-prod-app`/`run-dev-app` wire the new MFA↔PAT revoke callback automatically when both `auth-mfa` and `personal-access-tokens` are mounted; no app-level change needed for that part.",
     "migration": "Apps that already mint PATs (their own client code, scripts, or tests) need to add `currentPassword` to the `create` request payload — this is a breaking change to the `create` request shape despite the minor bump (bundled-features doesn't follow strict semver across its handler schemas yet). If the caller has MFA enrolled, also include a valid `mfaCode`."
+  },
+  {
+    "version": "0.117.0",
+    "type": "improvement",
+    "title": "personal-access-tokens: add `toggleable` option so the whole feature can be tier-gated vi…",
+    "detail": "personal-access-tokens: add `toggleable` option so the whole feature can be tier-gated via the tier-engine (mirrors ledger/tags). Pass `{ toggleable: { default: false } }` for fail-closed gating — PAT is then off until a tier lists `\"personal-access-tokens\"` in its features. Omitting the option keeps PAT always-on (no behaviour change for existing consumers)."
   }
 ]

package/src/user-data-rights/changes.json

@@ -6,18 +6,18 @@
     "detail": "`privacy-center` is now a declarative `projectionDetail` screen instead of a custom React component: the Restriction and Deletion sections render through the generic renderer (`EditFieldsSection` + `actions: RowAction[]`), preserving the original confirmation dialogs (`RowActionWriteHandler.confirm`) and visibility rules (`visible: {field, eq/ne}`) 1:1. The Export section (Art. 20) stays a custom `EditExtensionSection` — it needs polling + a signed-URL download — registered via the new `ClientFeatureDefinition.extensionSectionComponents` under `EXPORT_SECTION_EXTENSION_NAME`. `PrivacyCenterScreen` is a dead export (the renderer selects the screen by `screen.type`, not the client component registry). The single `status` field now renders through the `enumOption` format instead of the raw enum string; `gracePeriodEnd` is hidden when no deletion is pending instead of showing an empty date. Known UI regression, accepted for this pass: the confirm-dialog title is now always the action's `label` (the renderer hardcodes this) — the original's distinct `dialogTitle` copy and its dynamic composed banner sentence (e.g. \"Your account will be deleted on {date}\") are gone, replaced by the translated `status` label plus a separately labeled `gracePeriodEnd` date.",
     "migration": "A declarative screen is registered once and can no longer be toggled per-app on the client: `userDataRightsClient(options)`'s `privacyCenter: { showDeletion }` option is removed. Move the flag server-side instead — replace `createUserDataRightsFeature({})` with `createUserDataRightsFeature({ privacyCenterShowDeletion: false })` (default `true`) — it conditionally omits the Deletion section and its `request-deletion`/`cancel-deletion` actions from the screen definition. Then drop the now-unused `privacyCenter` option from the matching `userDataRightsClient({ privacyCenter: { showDeletion: false } })` call. Known affected consumer: `money-horse` (`src/app/client-features.tsx:74`)."
   },
-  {
-    "version": "0.165.1",
-    "type": "fix",
-    "title": "restrict-account runs the same cross-tenant membership check as lift-restriction (fw#1543).",
-    "detail": "Any Admin/TenantAdmin — not just SystemAdmin — could restrict a user's account and force-revoke their sessions regardless of tenant, as long as they held an admin role in some tenant. Also: the GET /user-export/by-token fallback now forwards x-forwarded-for to the internal query call, so the per-IP 30/min limit stops collapsing into one global bucket."
-  },
   {
     "version": "0.165.3",
     "type": "improvement",
     "title": "Forget cleanup purges derived Meili docs for searchable subject-PII (fw#1610).",
     "detail": "run-forget-cleanup (and the forget cron path) call purgeSearchDocumentsForSubject after crypto-shred so searchable userOwned fields do not linger in Meili as plaintext after Art. 17."
   },
+  {
+    "version": "0.165.1",
+    "type": "fix",
+    "title": "restrict-account runs the same cross-tenant membership check as lift-restriction (fw#1543).",
+    "detail": "Any Admin/TenantAdmin — not just SystemAdmin — could restrict a user's account and force-revoke their sessions regardless of tenant, as long as they held an admin role in some tenant. Also: the GET /user-export/by-token fallback now forwards x-forwarded-for to the internal query call, so the per-IP 30/min limit stops collapsing into one global bucket."
+  },
   {
     "version": "0.165.0",
     "type": "breaking",

package/src/user-profile/__tests__/profile-screen.test.tsx

@@ -105,15 +105,62 @@ async function waitForMount(view: ReturnType<typeof render>, testId: string): Pr
   });
 }
 
+// Reproduces the real host: RenderEdit renders exactly one <form
+// testId="render-edit-form"> around every singleton projectionDetail screen
+// (render-edit.tsx), and both sections mount as children of that form via
+// ExtensionSectionMount. A section that renders its own <form> nests invalid
+// DOM inside it — the security bug this guards against: the submit button
+// falls back to a native GET navigation, putting the password(s) in the URL
+// query instead of dispatching a write.
+function renderInsideHostForm(node: ReactNode) {
+  const writes: Array<{ type: string; payload: unknown }> = [];
+  const view = render(<form data-testid="render-edit-form">{node}</form>, {
+    wrapper: withProviders(writes),
+  });
+  return { view, writes };
+}
+
 describe("ChangeEmailSection", () => {
-  test("renders on a real <form> (Enter-to-submit, password-manager boundary), shows the current email, no raw i18n keys", async () => {
+  test("renders no <form> of its own (would nest inside the host RenderEdit <form>), shows the current email, no raw i18n keys", async () => {
     const { view } = renderChangeEmailSection("marc@example.com");
     await waitForMount(view, "change-email-root");
-    expect(view.getByTestId("profile-email").tagName).toBe("FORM");
+    expect(view.container.querySelector("form")).toBeNull();
     expect(view.getByTestId("profile-email-current").textContent).toContain("marc@example.com");
     expect(view.container.textContent).not.toContain("profile.");
   });
 
+  // Security regression guard: mounted inside the real host <form> (as
+  // RenderEdit does in production), a click on the submit button must still
+  // reach the write dispatcher — not fall back to the host form's native
+  // GET submission, which would put currentPassword/newEmail in the URL.
+  test("mounted inside the host RenderEdit <form>, a click on the submit button dispatches change-email (no nested <form>, no native submit fallback)", async () => {
+    const { view, writes } = renderInsideHostForm(
+      <ChangeEmailSection
+        entityName="user"
+        entityId={null}
+        values={{ email: "old@example.com" }}
+        patch={() => {}}
+      />,
+    );
+    await waitForMount(view, "profile-email");
+    expect(view.container.querySelectorAll("form")).toHaveLength(1);
+
+    const emailInput = view.container.querySelector<HTMLInputElement>("#profile-new-email");
+    const pwInput = view.container.querySelector<HTMLInputElement>("#profile-email-password");
+    if (!emailInput || !pwInput) throw new Error("email form inputs not found");
+    fireEvent.change(emailInput, { target: { value: "new@example.com" } });
+    fireEvent.change(pwInput, { target: { value: "current-pw" } });
+    fireEvent.click(view.getByTestId("profile-email-submit"));
+
+    await waitFor(() => {
+      if (writes.length === 0) throw new Error("no write dispatched yet");
+    });
+    expect(writes[0]).toEqual({
+      type: "user-profile:write:change-email",
+      payload: { currentPassword: "current-pw", newEmail: "new@example.com" },
+    });
+  });
+
   test("submits change-email with currentPassword + newEmail, patches the host's email on success", async () => {
     const { view, writes, patchCalls } = renderChangeEmailSection("old@example.com");
     await waitForMount(view, "profile-email");
@@ -212,13 +259,40 @@ describe("ChangeEmailSection", () => {
 });
 
 describe("ChangePasswordSection", () => {
-  test("renders on a real <form>, no raw i18n keys", async () => {
+  test("renders no <form> of its own (would nest inside the host RenderEdit <form>), no raw i18n keys", async () => {
     const { view } = renderChangePasswordSection();
     await waitForMount(view, "change-password-root");
-    expect(view.getByTestId("profile-password").tagName).toBe("FORM");
+    expect(view.container.querySelector("form")).toBeNull();
     expect(view.container.textContent).not.toContain("profile.");
   });
 
+  // Security regression guard: mounted inside the real host <form> (as
+  // RenderEdit does in production), a click on the submit button must still
+  // reach the write dispatcher — not fall back to the host form's native
+  // GET submission, which would put old+new passwords in the URL.
+  test("mounted inside the host RenderEdit <form>, a click on the submit button dispatches change-password (no nested <form>, no native submit fallback)", async () => {
+    const { view, writes } = renderInsideHostForm(<ChangePasswordSection />);
+    await waitForMount(view, "profile-password");
+    expect(view.container.querySelectorAll("form")).toHaveLength(1);
+
+    const oldPw = view.container.querySelector<HTMLInputElement>("#profile-old-password");
+    const newPw = view.container.querySelector<HTMLInputElement>("#profile-new-password");
+    const confirmPw = view.container.querySelector<HTMLInputElement>("#profile-confirm-password");
+    if (!oldPw || !newPw || !confirmPw) throw new Error("password form inputs not found");
+    fireEvent.change(oldPw, { target: { value: "current-pw" } });
+    fireEvent.change(newPw, { target: { value: "new-pw-1" } });
+    fireEvent.change(confirmPw, { target: { value: "new-pw-1" } });
+    fireEvent.click(view.getByTestId("profile-password-submit"));
+
+    await waitFor(() => {
+      if (writes.length === 0) throw new Error("no write dispatched yet");
+    });
+    expect(writes[0]).toEqual({
+      type: "auth-email-password:write:change-password",
+      payload: { oldPassword: "current-pw", newPassword: "new-pw-1" },
+    });
+  });
+
   test("mismatched confirm password blocks the submit (no write dispatched)", async () => {
     const { view, writes } = renderChangePasswordSection();
     await waitForMount(view, "profile-password");

package/src/user-profile/changes.json

@@ -1,4 +1,10 @@
 [
+  {
+    "version": "0.243.1",
+    "type": "fix",
+    "title": "Security fix: ChangePasswordSection/ChangeEmailSection no longer nest a <form> inside the host RenderEdit form.",
+    "detail": "Since `profile` became a declarative `projectionDetail` screen (fw#2312), RenderEdit wraps the whole singleton screen in its own host `<form>`. `ChangePasswordSection` and `ChangeEmailSection` were each rendering their own `<Form>` inside that host, creating invalid nested `<form>` DOM. The submit button silently fell back to a native GET submission of the outer form instead of dispatching a write, putting the entered password(s) in the URL query string (browser history, `Referer` header, proxy/server access logs — `ChangePasswordSection` leaked both the old and the new password). Both sections now follow the same no-nested-form pattern `write-form-section.tsx` uses: a plain container with a `type=\"button\"` that calls the write dispatcher directly. testIds are unchanged; Enter-to-submit inside these two sections is an accepted, deliberate trade-off (same one `write-form-section.tsx` already makes)."
+  },
   {
     "version": "0.241.0",
     "type": "breaking",

package/src/user-profile/web/profile-screen.tsx

@@ -13,7 +13,6 @@ import {
   usePrimitives,
   useTranslation,
 } from "@cosmicdrift/kumiko-renderer";
-import { BareFormProvider } from "@cosmicdrift/kumiko-renderer-web";
 import { type ReactNode, useState } from "react";
 import { AuthHandlers } from "../../auth-email-password/constants";
 import { requestEmailVerification } from "../../auth-email-password/web";
@@ -46,12 +45,15 @@ function StatusBanner({ status }: { readonly status: SectionStatus }): ReactNode
 
 // Mounted by the renderer's ExtensionSectionMount (already wrapped in
 // <Section title={...} testId="section-extension-...">) — takes no props of
-// its own. BareFormProvider keeps <Form> from rendering a second card/title
-// inside that Section (same pattern as AuthCard, see
-// auth-email-password/web/auth-form-primitives.tsx).
+// its own. Deliberately NOT a <Form>: RenderEdit already renders a host
+// <form> around the whole singleton screen (render-edit.tsx), so a second
+// nested <form> here is invalid DOM and silently degrades the submit button
+// into a native GET navigation instead of a write dispatch (same failure
+// mode write-form-section.tsx documents and avoids the same way — a plain
+// button click, not a second <form>).
 export function ChangePasswordSection(): ReactNode {
   const t = useTranslation();
-  const { Form, Field, Input, Button } = usePrimitives();
+  const { Field, Input, Button } = usePrimitives();
   const dispatcher = useDispatcher();
   const [oldPassword, setOldPassword] = useState("");
   const [newPassword, setNewPassword] = useState("");
@@ -82,55 +84,55 @@ export function ChangePasswordSection(): ReactNode {
 
   const submitting = status.kind === "submitting";
   return (
-    <BareFormProvider>
-      <Form
-        testId="profile-password"
-        onSubmit={onSubmit}
-        actions={
-          <Button type="submit" disabled={submitting} testId="profile-password-submit">
-            {t("profile.password.submit")}
-          </Button>
-        }
-      >
-        <Field id="profile-old-password" label={t("profile.password.old")} required>
-          <Input
-            kind="password"
-            id="profile-old-password"
-            name="profile-old-password"
-            value={oldPassword}
-            onChange={setOldPassword}
-            disabled={submitting}
-            required
-            autoComplete="current-password"
-          />
-        </Field>
-        <Field id="profile-new-password" label={t("profile.password.new")} required>
-          <Input
-            kind="password"
-            id="profile-new-password"
-            name="profile-new-password"
-            value={newPassword}
-            onChange={setNewPassword}
-            disabled={submitting}
-            required
-            autoComplete="new-password"
-          />
-        </Field>
-        <Field id="profile-confirm-password" label={t("profile.password.confirm")} required>
-          <Input
-            kind="password"
-            id="profile-confirm-password"
-            name="profile-confirm-password"
-            value={confirm}
-            onChange={setConfirm}
-            disabled={submitting}
-            required
-            autoComplete="new-password"
-          />
-        </Field>
-        <StatusBanner status={status} />
-      </Form>
-    </BareFormProvider>
+    <div data-testid="profile-password" className="flex flex-col gap-4">
+      <Field id="profile-old-password" label={t("profile.password.old")} required>
+        <Input
+          kind="password"
+          id="profile-old-password"
+          name="profile-old-password"
+          value={oldPassword}
+          onChange={setOldPassword}
+          disabled={submitting}
+          required
+          autoComplete="current-password"
+        />
+      </Field>
+      <Field id="profile-new-password" label={t("profile.password.new")} required>
+        <Input
+          kind="password"
+          id="profile-new-password"
+          name="profile-new-password"
+          value={newPassword}
+          onChange={setNewPassword}
+          disabled={submitting}
+          required
+          autoComplete="new-password"
+        />
+      </Field>
+      <Field id="profile-confirm-password" label={t("profile.password.confirm")} required>
+        <Input
+          kind="password"
+          id="profile-confirm-password"
+          name="profile-confirm-password"
+          value={confirm}
+          onChange={setConfirm}
+          disabled={submitting}
+          required
+          autoComplete="new-password"
+        />
+      </Field>
+      <StatusBanner status={status} />
+      <div className="flex items-center justify-end gap-2">
+        <Button
+          type="button"
+          disabled={submitting}
+          onClick={() => onSubmit()}
+          testId="profile-password-submit"
+        >
+          {t("profile.password.submit")}
+        </Button>
+      </div>
+    </div>
   );
 }
 
@@ -142,7 +144,7 @@ export function ChangePasswordSection(): ReactNode {
 // relying on a full-screen refetch to un-stale the "current email" line.
 export function ChangeEmailSection({ values, patch }: ExtensionSectionProps): ReactNode {
   const t = useTranslation();
-  const { Form, Field, Input, Button, Text } = usePrimitives();
+  const { Field, Input, Button, Text } = usePrimitives();
   const dispatcher = useDispatcher();
   const [newEmail, setNewEmail] = useState("");
   const [currentPassword, setCurrentPassword] = useState("");
@@ -188,45 +190,45 @@ export function ChangeEmailSection({ values, patch }: ExtensionSectionProps): Re
 
   const submitting = status.kind === "submitting";
   return (
-    <BareFormProvider>
-      <Form
-        testId="profile-email"
-        onSubmit={onSubmit}
-        actions={
-          <Button type="submit" disabled={submitting} testId="profile-email-submit">
-            {t("profile.email.submit")}
-          </Button>
-        }
-      >
-        <Text variant="muted" testId="profile-email-current">
-          {t("profile.email.current")}: {currentEmail}
-        </Text>
-        <Field id="profile-new-email" label={t("profile.email.new")} required>
-          <Input
-            kind="email"
-            id="profile-new-email"
-            name="profile-new-email"
-            value={newEmail}
-            onChange={setNewEmail}
-            disabled={submitting}
-            required
-            autoComplete="email"
-          />
-        </Field>
-        <Field id="profile-email-password" label={t("profile.email.currentPassword")} required>
-          <Input
-            kind="password"
-            id="profile-email-password"
-            name="profile-email-password"
-            value={currentPassword}
-            onChange={setCurrentPassword}
-            disabled={submitting}
-            required
-            autoComplete="current-password"
-          />
-        </Field>
-        <StatusBanner status={status} />
-      </Form>
-    </BareFormProvider>
+    <div data-testid="profile-email" className="flex flex-col gap-4">
+      <Text variant="muted" testId="profile-email-current">
+        {t("profile.email.current")}: {currentEmail}
+      </Text>
+      <Field id="profile-new-email" label={t("profile.email.new")} required>
+        <Input
+          kind="email"
+          id="profile-new-email"
+          name="profile-new-email"
+          value={newEmail}
+          onChange={setNewEmail}
+          disabled={submitting}
+          required
+          autoComplete="email"
+        />
+      </Field>
+      <Field id="profile-email-password" label={t("profile.email.currentPassword")} required>
+        <Input
+          kind="password"
+          id="profile-email-password"
+          name="profile-email-password"
+          value={currentPassword}
+          onChange={setCurrentPassword}
+          disabled={submitting}
+          required
+          autoComplete="current-password"
+        />
+      </Field>
+      <StatusBanner status={status} />
+      <div className="flex items-center justify-end gap-2">
+        <Button
+          type="button"
+          disabled={submitting}
+          onClick={() => onSubmit()}
+          testId="profile-email-submit"
+        >
+          {t("profile.email.submit")}
+        </Button>
+      </div>
+    </div>
   );
 }