From d0721f6b3e3eff84cb309acffaeb5cf0065e851c Mon Sep 17 00:00:00 2001
From: Harm Manders <harmmanders@gmail.com>
Date: Fri, 11 Sep 2026 20:48:44 +0200
Subject: [PATCH 1/9] Add admin-togglable feature flags, gate AI monster
 generator
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Adds a small, code-defined feature flag registry backed by Firebase,
an admin page to toggle flags, and a Vuex module that fetches current
values once per app load (client boot / each SSR render) — no live
push to open tabs, no redeploy required for a toggle to take effect.

Wires up the first flag, monster_generator, in two places: hides the
"Generate from description" entry point in the New Monster dialog when
disabled, and rejects POST /ai/generate-monster server-side so the
kill switch is authoritative even if a request bypasses the UI.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017AuRuGWkBbBzeKpqtrq9qR
---
 .../feature-flags-admin/.openspec.yaml        |  2 +
 .../changes/feature-flags-admin/design.md     | 83 +++++++++++++++++++
 .../changes/feature-flags-admin/proposal.md   | 29 +++++++
 .../specs/feature-flags/spec.md               | 71 ++++++++++++++++
 openspec/changes/feature-flags-admin/tasks.md | 56 +++++++++++++
 src-ssr/api/index.js                          | 20 +++++
 src/router/routes.js                          | 18 ++++
 src/services/featureFlags.js                  | 19 +++++
 src/store/index.js                            |  2 +
 src/store/modules/featureFlags.js             | 62 ++++++++++++++
 src/store/modules/general.js                  |  3 +
 src/utils/featureFlags.js                     | 14 ++++
 src/views/Admin/FeatureFlags.vue              | 66 +++++++++++++++
 src/views/Admin/index.vue                     |  5 ++
 src/views/UserContent/Npcs/EditNpc.vue        |  2 +
 15 files changed, 452 insertions(+)
 create mode 100644 openspec/changes/feature-flags-admin/.openspec.yaml
 create mode 100644 openspec/changes/feature-flags-admin/design.md
 create mode 100644 openspec/changes/feature-flags-admin/proposal.md
 create mode 100644 openspec/changes/feature-flags-admin/specs/feature-flags/spec.md
 create mode 100644 openspec/changes/feature-flags-admin/tasks.md
 create mode 100644 src/services/featureFlags.js
 create mode 100644 src/store/modules/featureFlags.js
 create mode 100644 src/utils/featureFlags.js
 create mode 100644 src/views/Admin/FeatureFlags.vue

diff --git a/openspec/changes/feature-flags-admin/.openspec.yaml b/openspec/changes/feature-flags-admin/.openspec.yaml
new file mode 100644
index 000000000..515eaae39
--- /dev/null
+++ b/openspec/changes/feature-flags-admin/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-09-11
diff --git a/openspec/changes/feature-flags-admin/design.md b/openspec/changes/feature-flags-admin/design.md
new file mode 100644
index 000000000..975002205
--- /dev/null
+++ b/openspec/changes/feature-flags-admin/design.md
@@ -0,0 +1,83 @@
+## Context
+
+Shieldmaiden has no existing feature-flag mechanism. Toggleable behavior today is either a Vuex/UI concern (e.g. `userSettings`) or hardcoded. The first concrete need is a kill switch for the AI monster generator (`src/components/npcs/GenerateMonster.vue` → `POST /ai/generate-monster` in `src-ssr/api/index.js` → the external `MONSTER_GENERATOR_API_URL` service), so it can be turned off quickly if the external API misbehaves or gets expensive, without a release.
+
+The codebase already has a `/admin` section (`src/layouts/admin.vue`, gated client-side via `preFetch` on `store.getters.userInfo.admin`) with several simple admin pages that read/write Firebase Realtime Database paths directly from the client SDK (e.g. `src/services/promotions.js`, `src/views/Admin/Promotions.vue`), and a small standalone Vuex module pattern for lightweight admin-adjacent state (`src/store/modules/contentReports.js`). The app runs in Quasar SSR mode behind Express + PM2 in a long-running Docker container (`src-ssr/index.js`, `Dockerfile`), but per the product decision below, flags are read fresh on every render rather than cached for the process lifetime — so the container's lifetime doesn't matter here.
+
+## Goals / Non-Goals
+
+**Goals:**
+- A fixed, code-defined registry of boolean flags (id, label, default), extensible by adding an entry — no schema migration needed for a new flag.
+- Firebase-backed storage so an admin toggle is durable and consistent with how other admin tools already persist state.
+- An admin page consistent with the existing `/admin` pages' look, auth gating, and direct-Firebase-write style.
+- A flag change is visible on the next page load/reload (client re-fetch on boot, fresh read on every SSR render) — confirmed with the user that this is the desired freshness bar, explicitly **not** requiring a redeploy or a live push to open tabs.
+- The `monster_generator` flag is enforced in two places: hiding the client entry point (UX) and rejecting the server endpoint (the actual kill switch).
+
+**Non-Goals:**
+- Real-time/live propagation to already-open tabs (no `onValue`/`.on("value")` listeners for flags, no websockets).
+- Per-user, per-tier, or percentage-rollout flags — this is a single global boolean per flag.
+- Admin-created/deleted flags — the registry is code-only; the admin page only toggles existing entries.
+- A generic "requires redeploy" build-time-constant model — explicitly rejected in favor of the simpler Firebase-read-per-load model (see Decision 1).
+
+## Decisions
+
+### 1. Freshness model: read fresh per load, not cached for the server process lifetime
+
+Two designs were considered for how a toggle reaches running clients:
+- **(a) Read fresh on every load/render.** The client fetches flag state once during app boot (mirroring `checkExtensionInstalled` in `src/store/modules/general.js`); SSR reads it fresh on every `renderToString` call (since Quasar SSR already re-runs boot/store `initialize` per request). A reload always shows the current value. No redeploy needed, ever.
+- **(b) Cache in memory for the life of the SSR Node process.** Read once at process boot into a module-level singleton in `src-ssr`, outside the per-request Vuex lifecycle. A reload hits the same process and gets the stale value; only a new deploy (new PM2/Docker process) re-reads and picks up the change.
+
+Confirmed with the user: **(a)**. It's simpler (reuses the existing per-request boot fetch pattern, no new server-lifetime cache module to build/reason about), matches how every other piece of admin-toggled data in this app already works (promotions, vouchers — visible next load, no redeploy), and still fully satisfies the actual need (a fast kill switch that doesn't require a release).
+
+### 2. Registry lives in one shared module, importable from both client and server
+
+`src/utils/featureFlags.js` exports a plain object/array registry, e.g.:
+```js
+const FEATURE_FLAGS = {
+  monster_generator: { label: "AI Monster Generator", default: true },
+};
+```
+This file has no Firebase or Vue dependency, so it can be `require`d from `src-ssr/api/index.js` (CommonJS-compatible, following the existing pattern where `src-ssr/api/index.js` already imports plain services from `src/services/`) and imported from the Vuex module and admin page. One registry, one source of truth for ids/labels/defaults on both sides.
+
+**Alternative considered:** duplicate the registry (one for client, one for server). Rejected — guarantees drift (e.g. a flag id typo'd differently in each place silently fails open).
+
+### 3. Storage shape and read/write helpers
+
+Firebase path: `feature_flags/<flag_id>` → `{ enabled: boolean }` (object, not a bare boolean) to leave room for future metadata (e.g. `updated_at`) without a breaking shape change, consistent with `promotions`' shape.
+
+`src/services/featureFlags.js` (mirrors `src/services/promotions.js` / `src/services/contentReports.js`):
+- `getAllFlags()` — one `.once("value")` read of `feature_flags`, merged over the registry defaults so every registered flag always has a defined value even if never written.
+- `setFlagEnabled(id, enabled)` — `FEATURE_FLAGS_REF.child(id).child("enabled").set(enabled)`.
+
+`src/store/modules/featureFlags.js` (namespaced, mirrors `contentReports.js`):
+- State: `{ flags: {} }` (id → boolean, already merged with defaults).
+- Action `fetch_flags()` — calls the service once, commits the result. Called from `general.js`'s `initialize()` action, in both the authenticated and unauthenticated branches (flags aren't user-specific, and future flags may gate public-facing behavior).
+- Getter `isFlagEnabled: (state) => (id) => state.flags[id] ?? FEATURE_FLAGS[id]?.default ?? true` — reads the fetched value, falling back to the registry default (covers "fetch hasn't resolved yet" and "fetch failed" the same way).
+
+Server side (`src-ssr/api/index.js`): a small local helper using the existing `admin.database()` instance already initialized in that file:
+```js
+async function isFlagEnabled(id) {
+  const snap = await admin.database().ref(`feature_flags/${id}/enabled`).once("value");
+  const val = snap.val();
+  return val === null ? (FEATURE_FLAGS[id]?.default ?? true) : val;
+}
+```
+No new service class needed server-side — this mirrors the existing inline `admin.database()` usage already in that route handler for tiers/users/patrons.
+
+### 4. Admin UI: simple list with toggles, no new nav pattern
+
+`src/views/Admin/FeatureFlags.vue`: one `q-table`/`q-list` iterating the registry, each row a `q-toggle` bound to the flag's current stored state, calling `setFlagEnabled` on change (optimistic local update + Firebase write, same interaction pattern as `Promotions.vue`'s enable/disable buttons). Added to `src/views/Admin/index.vue`'s `items` list and as a new child route under `/admin` in `src/router/routes.js`, following the existing `vouchers`/`promotions` route shape exactly (flat child, no nested `:id`).
+
+**Alternative considered:** reuse `q-table` with row actions like `Promotions.vue`. Rejected as overkill for a handful of boolean rows — a plain list with inline toggles is less code and clearer for this shape of data.
+
+### 5. Monster generator enforcement in two places
+
+- **Client (UX only):** in `EditNpc.vue`, wrap the existing "Generate from description" `<button>` in `v-if="isFlagEnabled('monster_generator')"` (mapped getter from the new module). This just avoids showing an option that will fail.
+- **Server (the actual kill switch):** in `src-ssr/api/index.js`'s `router.post("/ai/generate-monster", ...)`, check `isFlagEnabled('monster_generator')` immediately after auth (before the credit lookup and before calling `MonsterGenerator.generateMonster`), returning a 4xx with a clear message if disabled. This is what actually stops cost/abuse even if someone calls the endpoint directly, and is why the flag is checked here rather than relying on the client hide alone.
+
+## Risks / Trade-offs
+
+- **[Risk]** A client that already has the New Monster dialog's history/tab open when a flag is disabled can still submit a request that then gets rejected server-side. → **Mitigation:** acceptable per the non-reactive requirement; the server rejection returns a clear error message rather than a generic 500.
+- **[Risk]** Firebase read failure for a flag makes the feature behave as if enabled (fail-open) rather than disabled (fail-closed). → **Mitigation:** deliberate choice — a transient read error should never accidentally take down a feature; for a true kill switch (server-side), an admin can retry, and read failures are logged the same way other `admin.database()` reads already are in that file.
+- **[Trade-off]** No live propagation means a determined admin trying to stop live abuse mid-incident still needs users to reload, or can rely on the server-side check being effective on that user's *next* request regardless of open tabs (Express reads the flag fresh per request, not cached) — so the practical kill-switch latency is actually "next API call," not "next page load," which is fast enough for the stated use case.
+- **[Risk]** Firebase security rules for the new `feature_flags` path aren't managed in this repo. → **Mitigation:** called out explicitly in the proposal's Impact section and as a task; must be verified/added in the Firebase console (or wherever rules are currently managed) before relying on the admin-only write restriction.
diff --git a/openspec/changes/feature-flags-admin/proposal.md b/openspec/changes/feature-flags-admin/proposal.md
new file mode 100644
index 000000000..1c632aa29
--- /dev/null
+++ b/openspec/changes/feature-flags-admin/proposal.md
@@ -0,0 +1,29 @@
+## Why
+
+We currently have no way to turn a feature off without shipping a code change. The AI monster generator (`GenerateMonster.vue` -> `POST /ai/generate-monster` -> the external `MONSTER_GENERATOR_API_URL` service) is the first case where we want a fast kill switch — e.g. if the external generator API goes down, gets too expensive, or starts producing bad output, we want to disable it in seconds from an admin page rather than cutting a release.
+
+## What Changes
+
+- Add a small, general-purpose feature flag system: a fixed registry of named boolean flags, defined in code, with their on/off state stored in Firebase and managed from a new `/admin/feature-flags` page.
+- Flags are **not real-time**: toggling a flag updates the stored value immediately, but already-open tabs are not pushed an update. The new value is picked up the next time a page is loaded/reloaded (client re-fetches once on boot; SSR re-reads on every render). No redeploy is required, and no live socket/listener is added.
+- Add the first flag, `monster_generator`, defaulting to **enabled**, and wire it to gate the AI monster generator end-to-end:
+  - Client: hide the "Generate from description" entry point in the New Monster dialog (`EditNpc.vue`) when the flag is off.
+  - Server: reject `POST /ai/generate-monster` (in `src-ssr/api/index.js`) with a clear error when the flag is off, so the kill switch is authoritative even if a request bypasses the UI.
+
+## Capabilities
+
+### New Capabilities
+- `feature-flags`: a fixed registry of named boolean flags; Firebase-backed storage; a Vuex module that fetches the current values once per app load (client boot / each SSR render, not live-reactive); an admin page to toggle them; a server-side helper to check a flag's state from Express API routes. Includes the `monster_generator` flag and its enforcement on both the client entry point and the `/ai/generate-monster` endpoint as the first concrete use of the system.
+
+### Modified Capabilities
+<!-- None — no existing OpenSpec capability covers admin tooling or the monster generator today. -->
+
+## Impact
+
+- **Code**:
+  - New: `src/utils/featureFlags.js` (flag registry + defaults, shared by client and server), `src/services/featureFlags.js` (Firebase read/write), `src/store/modules/featureFlags.js` (Vuex module), `src/views/Admin/FeatureFlags.vue` (admin UI).
+  - Modified: `src/store/index.js` (register module), `src/store/modules/general.js` (fetch flags during `initialize`), `src/router/routes.js` (new admin route), `src/views/Admin/index.vue` (nav entry), `src/views/UserContent/Npcs/EditNpc.vue` (hide entry point when disabled), `src-ssr/api/index.js` (enforce flag in `/ai/generate-monster`).
+- **APIs**: `POST /ai/generate-monster` gains a new failure mode (403-style rejection) when the flag is off. No new public endpoints — the admin page writes to Firebase directly via the client SDK, same as `Promotions`/`Vouchers`.
+- **Data**: new Firebase Realtime Database path `feature_flags/<flag_id>` (`{ enabled: boolean }`). Write access must be restricted to admins in the existing Firebase security rules (same restriction already relied on by `promotions`/`vouchers`, managed outside this repo).
+- **Dependencies**: none added.
+- **Risk**: low. Worst case for a stale/misread flag is the monster generator staying in its last-known state for one page load longer than expected; nothing destructive, easily reversible by re-toggling.
diff --git a/openspec/changes/feature-flags-admin/specs/feature-flags/spec.md b/openspec/changes/feature-flags-admin/specs/feature-flags/spec.md
new file mode 100644
index 000000000..b09e9d6a8
--- /dev/null
+++ b/openspec/changes/feature-flags-admin/specs/feature-flags/spec.md
@@ -0,0 +1,71 @@
+## ADDED Requirements
+
+### Requirement: Flag registry
+The system SHALL maintain a fixed, code-defined registry of feature flags. Each registry entry SHALL have a unique kebab_case-or-snake_case id, a human-readable label, and a default enabled state used when no stored value exists. Flags SHALL NOT be creatable or deletable from the admin UI — only their enabled state is togglable; new flags are added by developers via a code change.
+
+#### Scenario: Registry includes the monster generator flag
+- **WHEN** the flag registry is loaded
+- **THEN** it includes an entry with id `monster_generator`, a human-readable label, and a default enabled state of `true`
+
+#### Scenario: Unknown flag id is treated as enabled
+- **WHEN** any part of the system asks whether a flag not present in the registry is enabled
+- **THEN** the system treats it as enabled and does not throw, so a typo or a since-removed flag never becomes an accidental kill switch
+
+### Requirement: Flag state storage
+The system SHALL persist each registered flag's enabled state under `feature_flags/<flag_id>` in the Firebase Realtime Database, as `{ enabled: boolean }`. Write access to this path SHALL be restricted to admin users by Firebase security rules. When no value is stored for a registered flag, the flag's registry default SHALL apply.
+
+#### Scenario: Stored value overrides the default
+- **WHEN** `feature_flags/monster_generator/enabled` is stored as `false` in the database
+- **THEN** any part of the system checking the `monster_generator` flag reads it as disabled, regardless of the registry default
+
+#### Scenario: Missing stored value falls back to the registry default
+- **WHEN** no value exists yet at `feature_flags/monster_generator`
+- **THEN** the flag is treated as enabled (the registry default), not disabled
+
+#### Scenario: Flag read failure falls back to the registry default
+- **WHEN** reading a flag's value from the database fails (network error, timeout, permission error)
+- **THEN** the system falls back to that flag's registry default rather than failing the request or defaulting to disabled
+
+### Requirement: Admin toggle page
+The system SHALL provide an admin-only page listing every registered flag with its current effective state, that lets an admin user toggle each flag's stored `enabled` value independently. The page SHALL be reachable only by users with `userInfo.admin` set, consistent with the rest of `/admin`.
+
+#### Scenario: Admin disables a flag
+- **WHEN** an admin user toggles the `monster_generator` flag off on the admin page
+- **THEN** `feature_flags/monster_generator/enabled` is set to `false` in the database
+
+#### Scenario: Admin re-enables a flag
+- **WHEN** an admin user toggles a previously-disabled flag back on
+- **THEN** the flag's stored value is set to `true` (or the stored override is removed, reverting to the registry default of `true`)
+
+### Requirement: Non-reactive propagation
+Flag state SHALL NOT be pushed live to already-open clients. A flag change SHALL take effect the next time a client loads or reloads the page (client-side fetch on app boot, and fresh on every server-side render) — no application redeploy SHALL be required for a toggle to take effect.
+
+#### Scenario: Open tab does not react to a toggle
+- **WHEN** a user has the New Monster dialog open in an existing tab and an admin disables `monster_generator` in another session
+- **THEN** the open tab's UI does not change until that tab is reloaded or a new page load occurs
+
+#### Scenario: Reload picks up the new value
+- **WHEN** a user reloads any page after `monster_generator` has been disabled
+- **THEN** the reloaded page reflects the flag as disabled, without any redeploy of the application
+
+### Requirement: Monster generator flag gates the AI generator's entry point
+When the `monster_generator` flag is disabled, the client SHALL NOT present the "Generate from description" option in the New Monster dialog (`EditNpc.vue`).
+
+#### Scenario: Entry point hidden while disabled
+- **WHEN** the `monster_generator` flag is disabled
+- **THEN** the New Monster dialog shows only "Copy existing monster" and "Create from scratch", without a "Generate from description" option
+
+#### Scenario: Entry point shown while enabled
+- **WHEN** the `monster_generator` flag is enabled (including its default state)
+- **THEN** the New Monster dialog shows the "Generate from description" option as it does today
+
+### Requirement: Monster generator flag is enforced server-side
+The `POST /ai/generate-monster` endpoint SHALL check the `monster_generator` flag before generating a monster or spending AI credits, independent of whether the request came from the gated client UI.
+
+#### Scenario: Request rejected while disabled
+- **WHEN** `POST /ai/generate-monster` is called while the `monster_generator` flag is disabled
+- **THEN** the endpoint responds with an error indicating the feature is disabled, does not call the external monster generator API, and does not spend or deduct AI credits
+
+#### Scenario: Request proceeds while enabled
+- **WHEN** `POST /ai/generate-monster` is called while the `monster_generator` flag is enabled
+- **THEN** the endpoint proceeds with its existing authentication, credit-check, and generation behavior unchanged
diff --git a/openspec/changes/feature-flags-admin/tasks.md b/openspec/changes/feature-flags-admin/tasks.md
new file mode 100644
index 000000000..bb849005e
--- /dev/null
+++ b/openspec/changes/feature-flags-admin/tasks.md
@@ -0,0 +1,56 @@
+## 1. Flag registry
+
+- [x] 1.1 Create `src/utils/featureFlags.js` exporting `FEATURE_FLAGS` (id -> `{ label, default }`), with the first entry `monster_generator: { label: "AI Monster Generator", default: true }`
+- [x] 1.2 Confirm the file has no Vue/Firebase import so it can be `require`d from `src-ssr/api/index.js` as-is
+
+## 2. Client storage service
+
+- [x] 2.1 Create `src/services/featureFlags.js` with a `FEATURE_FLAGS_REF = db.ref("feature_flags")` (mirror `src/services/promotions.js` style)
+- [x] 2.2 Implement `getAllFlags()` — one `.once("value")` read, merge stored `{ id: { enabled } }` over `FEATURE_FLAGS` defaults so every registered id resolves to a boolean
+- [x] 2.3 Implement `setFlagEnabled(id, enabled)` — `FEATURE_FLAGS_REF.child(id).child("enabled").set(enabled)`
+
+## 3. Vuex module
+
+- [x] 3.1 Create `src/store/modules/featureFlags.js`, namespaced, state `{ flags: {} }` (mirror `src/store/modules/contentReports.js` structure/style)
+- [x] 3.2 Action `fetch_flags()` — calls `getAllFlags()`, commits result via `SET_FLAGS`
+- [x] 3.3 Action `set_flag_enabled({ id, enabled })` — calls `setFlagEnabled`, commits optimistic update via `SET_FLAG`
+- [x] 3.4 Getter `flags` (raw map, for the admin page) and `isFlagEnabled: (state) => (id) => state.flags[id] ?? FEATURE_FLAGS[id]?.default ?? true`
+- [x] 3.5 Register the module in `src/store/index.js` as `feature_flags`
+
+## 4. Wire into app boot
+
+- [x] 4.1 In `src/store/modules/general.js`'s `initialize()` action, dispatch `feature_flags/fetch_flags` in both the authenticated (`Promise.all([...])`) and unauthenticated branch, so it's always fetched regardless of login state
+
+## 5. Admin UI
+
+- [x] 5.1 Create `src/views/Admin/FeatureFlags.vue` — list every entry from `FEATURE_FLAGS` with a `q-toggle` bound to `flags[id]`, calling `set_flag_enabled` on change (mirror the enable/disable interaction in `src/views/Admin/Promotions.vue`)
+- [x] 5.2 Add a `feature-flags` child route under `/admin` in `src/router/routes.js`, matching the flat `vouchers`/`promotions` shape
+- [x] 5.3 Add a nav entry to `src/views/Admin/index.vue`'s `items` list
+
+## 6. Monster generator: client entry point
+
+- [x] 6.1 In `src/views/UserContent/Npcs/EditNpc.vue`, map `feature_flags/isFlagEnabled` and wrap the "Generate from description" button with `v-if="isFlagEnabled('monster_generator')"`
+
+## 7. Monster generator: server enforcement
+
+- [x] 7.1 In `src-ssr/api/index.js`, `require` `FEATURE_FLAGS` from `src/utils/featureFlags.js` and add a small `isFlagEnabled(id)` helper using the existing `admin.database()` instance (fallback to registry default when no stored value or on read error)
+- [x] 7.2 In `router.post("/ai/generate-monster", ...)`, check `isFlagEnabled("monster_generator")` right after token verification and before the credits lookup; if disabled, respond with a 4xx and a clear message, without calling `MonsterGenerator.generateMonster` or touching credits
+
+## 8. Firebase rules (manual, outside this repo's tracked files)
+
+- [x] 8.1 Verify/add a rule restricting writes on `feature_flags` to admin users, matching however `promotions`/`vouchers` already restrict admin-only writes
+- [x] 8.2 Verify `feature_flags` is publicly readable (or readable by any authenticated user) so the client fetch and SSR read succeed for non-admins too
+
+## 9. Manual verification
+
+- [ ] 9.1 Run `npm run ssr`; confirm `/admin/feature-flags` lists `monster_generator` toggled on by default, and is unreachable when signed in as a non-admin
+- [ ] 9.2 Toggle `monster_generator` off on the admin page; reload the New Monster dialog in `EditNpc.vue` and confirm "Generate from description" is gone
+- [ ] 9.3 With the flag off, call `POST /ai/generate-monster` directly (e.g. via curl/Postman with a valid token) and confirm it's rejected without spending credits or calling the external API
+- [ ] 9.4 Toggle the flag back on, reload, and confirm both the entry point and the endpoint work as before
+- [ ] 9.5 Delete the `feature_flags/monster_generator` node entirely (simulating "never toggled") and confirm the feature behaves as enabled (registry default)
+- [x] 9.6 Run `npm run lint` and fix any issues introduced
+
+## 10. Wrap up
+
+- [ ] 10.1 Commit on `feature/feature-flags-admin` and push
+- [ ] 10.2 Open PR `feature/feature-flags-admin` -> `develop` (per Git Flow in CLAUDE.md)
diff --git a/src-ssr/api/index.js b/src-ssr/api/index.js
index 3ad61f84a..f921c07df 100644
--- a/src-ssr/api/index.js
+++ b/src-ssr/api/index.js
@@ -2,6 +2,7 @@ const { Router } = require("express");
 const { patreonServices } = require("../../src/services/patreon");
 const { MonsterGenerator } = require("../../src/services/monster_generator");
 const { SubscriptionServices } = require("../../src/services/subscription");
+const { FEATURE_FLAGS } = require("../../src/utils/featureFlags");
 
 const fs = require("fs");
 const path = require("path");
@@ -26,6 +27,21 @@ if (!admin.apps.length) {
 
 const router = new Router();
 
+/**
+ * Reads a feature flag's stored value, falling back to its registry default
+ * when unset or when the read fails (fail-open, never an accidental kill switch)
+ */
+async function isFlagEnabled(id) {
+	try {
+		const snapshot = await admin.database().ref(`feature_flags/${id}/enabled`).once("value");
+		const value = snapshot.val();
+		return value === null ? FEATURE_FLAGS[id]?.default ?? true : value;
+	} catch (error) {
+		console.error(`Error reading feature flag "${id}":`, error);
+		return FEATURE_FLAGS[id]?.default ?? true;
+	}
+}
+
 router.post("/patreon/auth", async (req, res) => {
 	const service = new patreonServices();
 	const result = await service.authenticatePatreonUser(req.body.code, req.headers.origin);
@@ -48,6 +64,10 @@ router.post("/ai/generate-monster", async (req, res) => {
 		const decodedToken = await admin.auth().verifyIdToken(idToken);
 		const uid = decodedToken.uid;
 
+		if (!(await isFlagEnabled("monster_generator"))) {
+			return res.status(403).json({ error: "The AI monster generator is currently disabled" });
+		}
+
 		// Fetch user credits
 		const tiersRef = admin.database().ref("tiers");
 		const userRef = admin.database().ref(`users/${uid}`);
diff --git a/src/router/routes.js b/src/router/routes.js
index 9cd4202b8..1940fee24 100644
--- a/src/router/routes.js
+++ b/src/router/routes.js
@@ -1198,6 +1198,24 @@ const routes = [
 					},
 				],
 			},
+			{
+				path: "feature-flags",
+				component: {
+					render(c) {
+						return c("router-view");
+					},
+				},
+				meta: {
+					title: "Feature Flags",
+				},
+				children: [
+					{
+						path: "",
+						name: "Feature Flags",
+						component: () => import("src/views/Admin/FeatureFlags.vue"),
+					},
+				],
+			},
 			{
 				path: "promotions",
 				component: {
diff --git a/src/services/featureFlags.js b/src/services/featureFlags.js
new file mode 100644
index 000000000..0ebd2de99
--- /dev/null
+++ b/src/services/featureFlags.js
@@ -0,0 +1,19 @@
+import { db } from "src/firebase";
+import { FEATURE_FLAGS } from "src/utils/featureFlags";
+
+const FEATURE_FLAGS_REF = db.ref("feature_flags");
+
+export class featureFlagServices {
+	static async getAllFlags() {
+		const stored = (await FEATURE_FLAGS_REF.once("value")).val() || {};
+
+		return Object.entries(FEATURE_FLAGS).reduce((flags, [id, { default: defaultEnabled }]) => {
+			flags[id] = stored[id] && stored[id].enabled !== undefined ? stored[id].enabled : defaultEnabled;
+			return flags;
+		}, {});
+	}
+
+	static async setFlagEnabled(id, enabled) {
+		return FEATURE_FLAGS_REF.child(id).child("enabled").set(enabled);
+	}
+}
diff --git a/src/store/index.js b/src/store/index.js
index 006284098..f8782d6db 100644
--- a/src/store/index.js
+++ b/src/store/index.js
@@ -20,6 +20,7 @@ import encounters from "./modules/userContent/encounters.js";
 import characters from "./modules/userContent/characters.js";
 import trackCampaign from "./modules/trackCampaign.js";
 import contentReports from "./modules/contentReports.js";
+import featureFlags from "./modules/featureFlags.js";
 
 Vue.use(Vuex);
 
@@ -55,6 +56,7 @@ export default function () {
 			characters: characters,
 			trackCampaign: trackCampaign,
 			content_reports: contentReports,
+			feature_flags: featureFlags,
 		},
 		// enable strict mode (adds overhead!)
 		// for dev mode only
diff --git a/src/store/modules/featureFlags.js b/src/store/modules/featureFlags.js
new file mode 100644
index 000000000..150d3c6bc
--- /dev/null
+++ b/src/store/modules/featureFlags.js
@@ -0,0 +1,62 @@
+import Vue from "vue";
+import { featureFlagServices } from "src/services/featureFlags";
+import { FEATURE_FLAGS } from "src/utils/featureFlags";
+
+const feature_flags_state = () => ({
+	flags: {},
+});
+
+const feature_flags_getters = {
+	flags: (state) => {
+		return state.flags;
+	},
+	isFlagEnabled: (state) => (id) => {
+		if (state.flags[id] !== undefined) return state.flags[id];
+		return FEATURE_FLAGS[id] ? FEATURE_FLAGS[id].default : true;
+	},
+};
+
+const feature_flags_actions = {
+	/**
+	 * Fetches all registered feature flags, merged with their defaults
+	 * Not reactive: a flag change is only picked up on the next fetch (app boot / SSR render)
+	 */
+	async fetch_flags({ commit }) {
+		try {
+			const flags = await featureFlagServices.getAllFlags();
+			commit("SET_FLAGS", flags);
+			return flags;
+		} catch (error) {
+			// Fail open: keep relying on the registry defaults via the getter
+			console.error("Failed to fetch feature flags", error);
+		}
+	},
+
+	/**
+	 * Toggles a single flag (admin only, enforced by Firebase security rules)
+	 *
+	 * @param {string} id
+	 * @param {boolean} enabled
+	 */
+	async set_flag_enabled({ commit }, { id, enabled }) {
+		await featureFlagServices.setFlagEnabled(id, enabled);
+		commit("SET_FLAG", { id, enabled });
+	},
+};
+
+const feature_flags_mutations = {
+	SET_FLAGS(state, flags) {
+		Vue.set(state, "flags", flags);
+	},
+	SET_FLAG(state, { id, enabled }) {
+		Vue.set(state.flags, id, enabled);
+	},
+};
+
+export default {
+	namespaced: true,
+	state: feature_flags_state,
+	getters: feature_flags_getters,
+	actions: feature_flags_actions,
+	mutations: feature_flags_mutations,
+};
diff --git a/src/store/modules/general.js b/src/store/modules/general.js
index 5542b0105..a2175d8bc 100644
--- a/src/store/modules/general.js
+++ b/src/store/modules/general.js
@@ -62,6 +62,9 @@ export default {
 		async initialize({ state, dispatch, commit, rootGetters }) {
 			if (state.initialized) return;
 
+			// Not user-specific, fetched regardless of auth state
+			dispatch("feature_flags/fetch_flags");
+
 			// In main.js before the Vue instance is rendered
 			// it's checked if there is a firebase authorization present.
 			// Therefore we can check here with 'auth' if there is a user.
diff --git a/src/utils/featureFlags.js b/src/utils/featureFlags.js
new file mode 100644
index 000000000..e3cc073d2
--- /dev/null
+++ b/src/utils/featureFlags.js
@@ -0,0 +1,14 @@
+// Shared feature flag registry, read by both the client (Vuex module) and the
+// SSR server (src-ssr/api/index.js, via require). Keep this file free of any
+// Vue/Firebase import so it stays require-able from plain Node.
+//
+// Flags are code-defined; the admin page can only toggle the `enabled` state
+// stored per flag id, never add/remove entries here.
+const FEATURE_FLAGS = {
+	monster_generator: {
+		label: "AI Monster Generator",
+		default: true,
+	},
+};
+
+module.exports = { FEATURE_FLAGS };
diff --git a/src/views/Admin/FeatureFlags.vue b/src/views/Admin/FeatureFlags.vue
new file mode 100644
index 000000000..c8c7b9294
--- /dev/null
+++ b/src/views/Admin/FeatureFlags.vue
@@ -0,0 +1,66 @@
+<template>
+	<hk-card header="Feature Flags">
+		<div class="card-body">
+			<p class="neutral-2">
+				Flags are not real-time — a toggle here takes effect for clients on their next page
+				load/reload, not immediately for already-open tabs.
+			</p>
+			<q-list>
+				<q-item v-for="(flag, id) in feature_flags" :key="id">
+					<q-item-section>
+						<q-item-label>{{ flag.label }}</q-item-label>
+						<q-item-label caption>{{ id }}</q-item-label>
+					</q-item-section>
+					<q-item-section side>
+						<q-toggle
+							:value="flags[id]"
+							:loading="updating[id]"
+							@input="(enabled) => toggle(id, enabled)"
+						/>
+					</q-item-section>
+				</q-item>
+			</q-list>
+		</div>
+	</hk-card>
+</template>
+
+<script>
+import { mapGetters, mapActions } from "vuex";
+import { FEATURE_FLAGS } from "src/utils/featureFlags";
+
+export default {
+	name: "FeatureFlags",
+	data() {
+		return {
+			feature_flags: FEATURE_FLAGS,
+			updating: {},
+		};
+	},
+	computed: {
+		...mapGetters("feature_flags", ["flags"]),
+	},
+	async mounted() {
+		await this.fetch_flags();
+	},
+	methods: {
+		...mapActions("feature_flags", ["fetch_flags", "set_flag_enabled"]),
+		async toggle(id, enabled) {
+			this.$set(this.updating, id, true);
+			try {
+				await this.set_flag_enabled({ id, enabled });
+			} catch (error) {
+				this.$snotify.error(error, "Failed to update flag", {});
+			} finally {
+				this.$delete(this.updating, id);
+			}
+		},
+	},
+};
+</script>
+
+<style lang="scss" scoped>
+.q-item {
+	background-color: $neutral-8;
+	margin-bottom: 1px;
+}
+</style>
diff --git a/src/views/Admin/index.vue b/src/views/Admin/index.vue
index 05fce426e..c81cf5a51 100644
--- a/src/views/Admin/index.vue
+++ b/src/views/Admin/index.vue
@@ -36,6 +36,11 @@ export default {
 					url: "vouchers",
 					icon: "fas fa-ticket",
 				},
+				feature_flags: {
+					name: "Feature Flags",
+					url: "feature-flags",
+					icon: "fas fa-toggle-on",
+				},
 				promotions: {
 					name: "Promotions",
 					url: "promotions",
diff --git a/src/views/UserContent/Npcs/EditNpc.vue b/src/views/UserContent/Npcs/EditNpc.vue
index b8b86a921..e9fee1257 100644
--- a/src/views/UserContent/Npcs/EditNpc.vue
+++ b/src/views/UserContent/Npcs/EditNpc.vue
@@ -152,6 +152,7 @@
 						</button>
 						<h2 class="text-center my-2">OR</h2>
 						<button
+							v-if="isFlagEnabled('monster_generator')"
 							class="btn btn-lg btn-block bg-accent mb-2"
 							@click="generate_monster = true"
 							:disabled="!userId"
@@ -259,6 +260,7 @@ export default {
 	computed: {
 		...mapGetters(["user", "tier", "overencumbered"]),
 		...mapGetters("npcs", ["npc_count"]),
+		...mapGetters("feature_flags", ["isFlagEnabled"]),
 	},
 	watch: {
 		npc: {

From ca527acf21d9a54c094bce37139358d1675945dc Mon Sep 17 00:00:00 2001
From: Harm Manders <harmmanders@gmail.com>
Date: Fri, 11 Sep 2026 20:49:28 +0200
Subject: [PATCH 2/9] Update task checklist for feature-flags-admin

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017AuRuGWkBbBzeKpqtrq9qR
---
 openspec/changes/feature-flags-admin/tasks.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/openspec/changes/feature-flags-admin/tasks.md b/openspec/changes/feature-flags-admin/tasks.md
index bb849005e..46c070c46 100644
--- a/openspec/changes/feature-flags-admin/tasks.md
+++ b/openspec/changes/feature-flags-admin/tasks.md
@@ -52,5 +52,5 @@
 
 ## 10. Wrap up
 
-- [ ] 10.1 Commit on `feature/feature-flags-admin` and push
-- [ ] 10.2 Open PR `feature/feature-flags-admin` -> `develop` (per Git Flow in CLAUDE.md)
+- [x] 10.1 Commit on `feature/feature-flags-admin` and push
+- [x] 10.2 Open PR `feature/feature-flags-admin` -> `develop` (per Git Flow in CLAUDE.md) — https://github.com/HarmlessKey/Shieldmaiden/pull/360

From 8dcf44117b7f93e14e0d76878a733358e20f6948 Mon Sep 17 00:00:00 2001
From: Harm Manders <harmmanders@gmail.com>
Date: Fri, 11 Sep 2026 20:51:46 +0200
Subject: [PATCH 3/9] Fix dark-mode text contrast on the Feature Flags admin
 page

q-list wasn't passed the dark prop, so q-item-label text (the flag id
caption) rendered with light-theme coloring on the dark background.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017AuRuGWkBbBzeKpqtrq9qR
---
 src/views/Admin/FeatureFlags.vue | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/views/Admin/FeatureFlags.vue b/src/views/Admin/FeatureFlags.vue
index c8c7b9294..5c7ebd6b0 100644
--- a/src/views/Admin/FeatureFlags.vue
+++ b/src/views/Admin/FeatureFlags.vue
@@ -5,7 +5,7 @@
 				Flags are not real-time — a toggle here takes effect for clients on their next page
 				load/reload, not immediately for already-open tabs.
 			</p>
-			<q-list>
+			<q-list :dark="$store.getters.theme === 'dark'">
 				<q-item v-for="(flag, id) in feature_flags" :key="id">
 					<q-item-section>
 						<q-item-label>{{ flag.label }}</q-item-label>

From cf10333e104b2c317917d54a194520eefc7d1cfd Mon Sep 17 00:00:00 2001
From: Harm Manders <harmmanders@gmail.com>
Date: Fri, 11 Sep 2026 20:56:04 +0200
Subject: [PATCH 4/9] Gate remaining monster generator entry points found in QA

- EditNpc.vue: hide the "OR" divider along with the "Generate from
  description" button so it doesn't dangle when the flag is off.
- Npcs.vue: the NPC list page has its own "Generate" toolbar button
  and overflow-menu item that also open the AI generator; gate both.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017AuRuGWkBbBzeKpqtrq9qR
---
 .../specs/feature-flags/spec.md               | 14 +++++++++-----
 openspec/changes/feature-flags-admin/tasks.md |  2 ++
 src/views/UserContent/Npcs/EditNpc.vue        | 19 ++++++++++---------
 src/views/UserContent/Npcs/Npcs.vue           |  5 +++--
 4 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/openspec/changes/feature-flags-admin/specs/feature-flags/spec.md b/openspec/changes/feature-flags-admin/specs/feature-flags/spec.md
index b09e9d6a8..90efc5c2f 100644
--- a/openspec/changes/feature-flags-admin/specs/feature-flags/spec.md
+++ b/openspec/changes/feature-flags-admin/specs/feature-flags/spec.md
@@ -49,15 +49,19 @@ Flag state SHALL NOT be pushed live to already-open clients. A flag change SHALL
 - **THEN** the reloaded page reflects the flag as disabled, without any redeploy of the application
 
 ### Requirement: Monster generator flag gates the AI generator's entry point
-When the `monster_generator` flag is disabled, the client SHALL NOT present the "Generate from description" option in the New Monster dialog (`EditNpc.vue`).
+When the `monster_generator` flag is disabled, the client SHALL NOT present any entry point into the AI monster generator: the "Generate from description" option (and its preceding "OR" divider) in the New Monster dialog (`EditNpc.vue`), and the "Generate" button/menu item on the NPC list page (`Npcs.vue`).
 
-#### Scenario: Entry point hidden while disabled
+#### Scenario: Entry point hidden in the New Monster dialog while disabled
 - **WHEN** the `monster_generator` flag is disabled
-- **THEN** the New Monster dialog shows only "Copy existing monster" and "Create from scratch", without a "Generate from description" option
+- **THEN** the New Monster dialog shows only "Copy existing monster" and "Create from scratch", without a "Generate from description" option or the "OR" divider that would otherwise precede it
 
-#### Scenario: Entry point shown while enabled
+#### Scenario: Entry point hidden on the NPC list page while disabled
+- **WHEN** the `monster_generator` flag is disabled
+- **THEN** the NPC list page's toolbar button and overflow-menu item for "Generate" are both absent, regardless of NPC slot/AI credit state
+
+#### Scenario: Entry points shown while enabled
 - **WHEN** the `monster_generator` flag is enabled (including its default state)
-- **THEN** the New Monster dialog shows the "Generate from description" option as it does today
+- **THEN** both the New Monster dialog's "Generate from description" option and the NPC list page's "Generate" entry points behave as they did before this change (still subject to their existing slot/credit conditions)
 
 ### Requirement: Monster generator flag is enforced server-side
 The `POST /ai/generate-monster` endpoint SHALL check the `monster_generator` flag before generating a monster or spending AI credits, independent of whether the request came from the gated client UI.
diff --git a/openspec/changes/feature-flags-admin/tasks.md b/openspec/changes/feature-flags-admin/tasks.md
index 46c070c46..6466feefa 100644
--- a/openspec/changes/feature-flags-admin/tasks.md
+++ b/openspec/changes/feature-flags-admin/tasks.md
@@ -30,6 +30,8 @@
 ## 6. Monster generator: client entry point
 
 - [x] 6.1 In `src/views/UserContent/Npcs/EditNpc.vue`, map `feature_flags/isFlagEnabled` and wrap the "Generate from description" button with `v-if="isFlagEnabled('monster_generator')"`
+- [x] 6.2 Fix dangling "OR" divider: wrap both the divider and the "Generate from description" button together in `EditNpc.vue`, found during manual QA
+- [x] 6.3 Found during manual QA: the NPC list page (`src/views/UserContent/Npcs/Npcs.vue`) has its own "Generate" entry points (toolbar button + overflow-menu item) that also call the AI generator — gate both with `isFlagEnabled('monster_generator')`
 
 ## 7. Monster generator: server enforcement
 
diff --git a/src/views/UserContent/Npcs/EditNpc.vue b/src/views/UserContent/Npcs/EditNpc.vue
index e9fee1257..c8d0d47bb 100644
--- a/src/views/UserContent/Npcs/EditNpc.vue
+++ b/src/views/UserContent/Npcs/EditNpc.vue
@@ -150,15 +150,16 @@
 						<button class="btn btn-lg btn-block" @click="create_dialog = false">
 							Create from scratch
 						</button>
-						<h2 class="text-center my-2">OR</h2>
-						<button
-							v-if="isFlagEnabled('monster_generator')"
-							class="btn btn-lg btn-block bg-accent mb-2"
-							@click="generate_monster = true"
-							:disabled="!userId"
-						>
-							Generate from description
-						</button>
+						<template v-if="isFlagEnabled('monster_generator')">
+							<h2 class="text-center my-2">OR</h2>
+							<button
+								class="btn btn-lg btn-block bg-accent mb-2"
+								@click="generate_monster = true"
+								:disabled="!userId"
+							>
+								Generate from description
+							</button>
+						</template>
 					</template>
 					<template v-if="copy_monster">
 						<h2>Copy an existing monster</h2>
diff --git a/src/views/UserContent/Npcs/Npcs.vue b/src/views/UserContent/Npcs/Npcs.vue
index 0e22de8fb..4951c50df 100644
--- a/src/views/UserContent/Npcs/Npcs.vue
+++ b/src/views/UserContent/Npcs/Npcs.vue
@@ -14,7 +14,7 @@
 						<span>Export</span>
 					</ExportUserContent>
 					<button
-						v-if="content_count.npcs >= tier.benefits.npcs && ai.total > 0"
+						v-if="isFlagEnabled('monster_generator') && content_count.npcs >= tier.benefits.npcs && ai.total > 0"
 						class="btn btn-sm bg-neutral-5 mr-2"
 						@click="generate_dialog = true"
 					>
@@ -51,7 +51,7 @@
 										<q-item-section>Export</q-item-section>
 									</q-item>
 									<q-item
-										v-if="content_count.npcs >= tier.benefits.npcs && ai.total > 0"
+										v-if="isFlagEnabled('monster_generator') && content_count.npcs >= tier.benefits.npcs && ai.total > 0"
 										clickable
 										v-close-popup
 										@click="generate_dialog = true"
@@ -440,6 +440,7 @@ export default {
 		...mapGetters("players", ["players"]),
 		...mapGetters("campaigns", ["campaigns"]),
 		...mapGetters("npcGroups", { npc_groups: "npc_groups" }),
+		...mapGetters("feature_flags", ["isFlagEnabled"]),
 		visibleColumns() {
 			if (this.card_width > 800) {
 				return ["avatar", "name", "type", "challenge_rating", "actions"];

From e9272cabf0dfcd551027b39005a61b616616c905 Mon Sep 17 00:00:00 2001
From: Harm Manders <harmmanders@gmail.com>
Date: Fri, 11 Sep 2026 21:09:56 +0200
Subject: [PATCH 5/9] Gate the remaining monster generator entry point on
 /content/import

ImportContent/index.vue has its own "Generate" button opening
GenerateMonster.vue, separate from the NPC list and New Monster
dialog. Verified via grep that all GenerateMonster.vue usages
(3 total) are now gated by the monster_generator flag.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017AuRuGWkBbBzeKpqtrq9qR
---
 .../feature-flags-admin/specs/feature-flags/spec.md      | 8 ++++++--
 openspec/changes/feature-flags-admin/tasks.md            | 1 +
 src/views/UserContent/ImportContent/index.vue            | 9 ++++++++-
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/openspec/changes/feature-flags-admin/specs/feature-flags/spec.md b/openspec/changes/feature-flags-admin/specs/feature-flags/spec.md
index 90efc5c2f..0f0d3bd78 100644
--- a/openspec/changes/feature-flags-admin/specs/feature-flags/spec.md
+++ b/openspec/changes/feature-flags-admin/specs/feature-flags/spec.md
@@ -49,7 +49,7 @@ Flag state SHALL NOT be pushed live to already-open clients. A flag change SHALL
 - **THEN** the reloaded page reflects the flag as disabled, without any redeploy of the application
 
 ### Requirement: Monster generator flag gates the AI generator's entry point
-When the `monster_generator` flag is disabled, the client SHALL NOT present any entry point into the AI monster generator: the "Generate from description" option (and its preceding "OR" divider) in the New Monster dialog (`EditNpc.vue`), and the "Generate" button/menu item on the NPC list page (`Npcs.vue`).
+When the `monster_generator` flag is disabled, the client SHALL NOT present any entry point into the AI monster generator (every usage of `GenerateMonster.vue`): the "Generate from description" option (and its preceding "OR" divider) in the New Monster dialog (`EditNpc.vue`), the "Generate" button/menu item on the NPC list page (`Npcs.vue`), and the "Generate" button on the generic content import page (`ImportContent/index.vue`).
 
 #### Scenario: Entry point hidden in the New Monster dialog while disabled
 - **WHEN** the `monster_generator` flag is disabled
@@ -59,9 +59,13 @@ When the `monster_generator` flag is disabled, the client SHALL NOT present any
 - **WHEN** the `monster_generator` flag is disabled
 - **THEN** the NPC list page's toolbar button and overflow-menu item for "Generate" are both absent, regardless of NPC slot/AI credit state
 
+#### Scenario: Entry point hidden on the content import page while disabled
+- **WHEN** the `monster_generator` flag is disabled
+- **THEN** the "Generate" button on `/content/import` is absent, regardless of which content type is being imported
+
 #### Scenario: Entry points shown while enabled
 - **WHEN** the `monster_generator` flag is enabled (including its default state)
-- **THEN** both the New Monster dialog's "Generate from description" option and the NPC list page's "Generate" entry points behave as they did before this change (still subject to their existing slot/credit conditions)
+- **THEN** all three entry points behave as they did before this change (still subject to their existing slot/credit/tier conditions)
 
 ### Requirement: Monster generator flag is enforced server-side
 The `POST /ai/generate-monster` endpoint SHALL check the `monster_generator` flag before generating a monster or spending AI credits, independent of whether the request came from the gated client UI.
diff --git a/openspec/changes/feature-flags-admin/tasks.md b/openspec/changes/feature-flags-admin/tasks.md
index 6466feefa..5e5ca4690 100644
--- a/openspec/changes/feature-flags-admin/tasks.md
+++ b/openspec/changes/feature-flags-admin/tasks.md
@@ -32,6 +32,7 @@
 - [x] 6.1 In `src/views/UserContent/Npcs/EditNpc.vue`, map `feature_flags/isFlagEnabled` and wrap the "Generate from description" button with `v-if="isFlagEnabled('monster_generator')"`
 - [x] 6.2 Fix dangling "OR" divider: wrap both the divider and the "Generate from description" button together in `EditNpc.vue`, found during manual QA
 - [x] 6.3 Found during manual QA: the NPC list page (`src/views/UserContent/Npcs/Npcs.vue`) has its own "Generate" entry points (toolbar button + overflow-menu item) that also call the AI generator — gate both with `isFlagEnabled('monster_generator')`
+- [x] 6.4 Found during manual QA: the generic content import page (`src/views/UserContent/ImportContent/index.vue`, `/content/import`) also has its own "Generate" button opening the same `GenerateMonster.vue` — gate it too. Confirmed via `grep -rln "GenerateMonster" src` that these are now all three (and only three) usage sites
 
 ## 7. Monster generator: server enforcement
 
diff --git a/src/views/UserContent/ImportContent/index.vue b/src/views/UserContent/ImportContent/index.vue
index 7937fb927..af7dd64d0 100644
--- a/src/views/UserContent/ImportContent/index.vue
+++ b/src/views/UserContent/ImportContent/index.vue
@@ -3,7 +3,13 @@
 		<div class="card-body">
 			<div v-if="tier.price !== 'Free'">
 				<ImportUserContent ref="import" :json-input="json_input">
-					<button class="btn bg-accent" @click="ai_dialog = !ai_dialog">Generate</button>
+					<button
+						v-if="isFlagEnabled('monster_generator')"
+						class="btn bg-accent"
+						@click="ai_dialog = !ai_dialog"
+					>
+						Generate
+					</button>
 				</ImportUserContent>
 			</div>
 			<template v-else>
@@ -36,6 +42,7 @@ export default {
 	},
 	computed: {
 		...mapGetters(["tier", "ai"]),
+		...mapGetters("feature_flags", ["isFlagEnabled"]),
 	},
 	data() {
 		return {

From 7e9f968af947b3c53d8a0ede62c07d664c5e79d3 Mon Sep 17 00:00:00 2001
From: Harm Manders <harmmanders@gmail.com>
Date: Fri, 11 Sep 2026 21:15:22 +0200
Subject: [PATCH 6/9] Check off manual QA confirmed by user

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017AuRuGWkBbBzeKpqtrq9qR
---
 openspec/changes/feature-flags-admin/tasks.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/openspec/changes/feature-flags-admin/tasks.md b/openspec/changes/feature-flags-admin/tasks.md
index 5e5ca4690..f212154c9 100644
--- a/openspec/changes/feature-flags-admin/tasks.md
+++ b/openspec/changes/feature-flags-admin/tasks.md
@@ -46,10 +46,10 @@
 
 ## 9. Manual verification
 
-- [ ] 9.1 Run `npm run ssr`; confirm `/admin/feature-flags` lists `monster_generator` toggled on by default, and is unreachable when signed in as a non-admin
-- [ ] 9.2 Toggle `monster_generator` off on the admin page; reload the New Monster dialog in `EditNpc.vue` and confirm "Generate from description" is gone
-- [ ] 9.3 With the flag off, call `POST /ai/generate-monster` directly (e.g. via curl/Postman with a valid token) and confirm it's rejected without spending credits or calling the external API
-- [ ] 9.4 Toggle the flag back on, reload, and confirm both the entry point and the endpoint work as before
+- [x] 9.1 Run `npm run ssr`; confirm `/admin/feature-flags` lists `monster_generator` toggled on by default, and is unreachable when signed in as a non-admin — confirmed by user ("ff page works")
+- [x] 9.2 Toggle `monster_generator` off on the admin page; reload the New Monster dialog in `EditNpc.vue` and confirm "Generate from description" is gone — confirmed by user
+- [x] 9.3 With the flag off, call `POST /ai/generate-monster` directly (e.g. via curl/Postman with a valid token) and confirm it's rejected without spending credits or calling the external API — confirmed by user ("API successfully blocks it")
+- [x] 9.4 Toggle the flag back on, reload, and confirm both the entry point and the endpoint work as before — confirmed by user ("toggle works")
 - [ ] 9.5 Delete the `feature_flags/monster_generator` node entirely (simulating "never toggled") and confirm the feature behaves as enabled (registry default)
 - [x] 9.6 Run `npm run lint` and fix any issues introduced
 

From 524b1dbc511d67f23af11a62f22dff93766eae55 Mon Sep 17 00:00:00 2001
From: Harm Manders <harmmanders@gmail.com>
Date: Fri, 11 Sep 2026 21:15:55 +0200
Subject: [PATCH 7/9] Check off final manual QA item

All 27 tasks confirmed complete.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017AuRuGWkBbBzeKpqtrq9qR
---
 openspec/changes/feature-flags-admin/tasks.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/openspec/changes/feature-flags-admin/tasks.md b/openspec/changes/feature-flags-admin/tasks.md
index f212154c9..ddb0cfeef 100644
--- a/openspec/changes/feature-flags-admin/tasks.md
+++ b/openspec/changes/feature-flags-admin/tasks.md
@@ -50,7 +50,7 @@
 - [x] 9.2 Toggle `monster_generator` off on the admin page; reload the New Monster dialog in `EditNpc.vue` and confirm "Generate from description" is gone — confirmed by user
 - [x] 9.3 With the flag off, call `POST /ai/generate-monster` directly (e.g. via curl/Postman with a valid token) and confirm it's rejected without spending credits or calling the external API — confirmed by user ("API successfully blocks it")
 - [x] 9.4 Toggle the flag back on, reload, and confirm both the entry point and the endpoint work as before — confirmed by user ("toggle works")
-- [ ] 9.5 Delete the `feature_flags/monster_generator` node entirely (simulating "never toggled") and confirm the feature behaves as enabled (registry default)
+- [x] 9.5 Delete the `feature_flags/monster_generator` node entirely (simulating "never toggled") and confirm the feature behaves as enabled (registry default) — confirmed by user ("Delete node works, defaults to true")
 - [x] 9.6 Run `npm run lint` and fix any issues introduced
 
 ## 10. Wrap up

From 711401264995b64ef44a4238547031660c66c395 Mon Sep 17 00:00:00 2001
From: Harm Manders <harmmanders@gmail.com>
Date: Fri, 11 Sep 2026 21:19:35 +0200
Subject: [PATCH 8/9] Fix production SSR build: remove optional chaining from
 src-ssr

src-ssr/*.js is not run through Babel (see the warning comment in
src-ssr/index.js), and this project's webpack 4 parser doesn't
understand the ES2020 optional-chaining/nullish-coalescing syntax
used in isFlagEnabled's fallback lookup. Dev mode (npm run ssr) didn't
catch this since it takes a different, more lenient path; the
production build (npx quasar build -m ssr, used by the Dockerfile)
failed to parse it.

Replaced with a plain flagDefault() helper using only pre-ES2020
syntax. Verified with a full `npx quasar build -m ssr` run.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017AuRuGWkBbBzeKpqtrq9qR
---
 src-ssr/api/index.js | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src-ssr/api/index.js b/src-ssr/api/index.js
index f921c07df..26617a326 100644
--- a/src-ssr/api/index.js
+++ b/src-ssr/api/index.js
@@ -31,14 +31,18 @@ const router = new Router();
  * Reads a feature flag's stored value, falling back to its registry default
  * when unset or when the read fails (fail-open, never an accidental kill switch)
  */
+function flagDefault(id) {
+	return FEATURE_FLAGS[id] && FEATURE_FLAGS[id].default !== undefined ? FEATURE_FLAGS[id].default : true;
+}
+
 async function isFlagEnabled(id) {
 	try {
 		const snapshot = await admin.database().ref(`feature_flags/${id}/enabled`).once("value");
 		const value = snapshot.val();
-		return value === null ? FEATURE_FLAGS[id]?.default ?? true : value;
+		return value === null ? flagDefault(id) : value;
 	} catch (error) {
 		console.error(`Error reading feature flag "${id}":`, error);
-		return FEATURE_FLAGS[id]?.default ?? true;
+		return flagDefault(id);
 	}
 }
 

From 0e2aefad9680a7de4281394d9f442df26d853b75 Mon Sep 17 00:00:00 2001
From: Harm Manders <harmmanders@gmail.com>
Date: Fri, 11 Sep 2026 21:19:55 +0200
Subject: [PATCH 9/9] Note the production SSR build fix in the task checklist

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017AuRuGWkBbBzeKpqtrq9qR
---
 openspec/changes/feature-flags-admin/tasks.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/openspec/changes/feature-flags-admin/tasks.md b/openspec/changes/feature-flags-admin/tasks.md
index ddb0cfeef..7af270a0b 100644
--- a/openspec/changes/feature-flags-admin/tasks.md
+++ b/openspec/changes/feature-flags-admin/tasks.md
@@ -38,6 +38,7 @@
 
 - [x] 7.1 In `src-ssr/api/index.js`, `require` `FEATURE_FLAGS` from `src/utils/featureFlags.js` and add a small `isFlagEnabled(id)` helper using the existing `admin.database()` instance (fallback to registry default when no stored value or on read error)
 - [x] 7.2 In `router.post("/ai/generate-monster", ...)`, check `isFlagEnabled("monster_generator")` right after token verification and before the credits lookup; if disabled, respond with a 4xx and a clear message, without calling `MonsterGenerator.generateMonster` or touching credits
+- [x] 7.3 Found via Docker/CI build failure: `src-ssr/*.js` isn't Babel-transpiled, and webpack 4's parser can't handle the ES2020 optional-chaining/nullish-coalescing (`?.`/`??`) used in the flag-default fallback. `npm run ssr` (dev) didn't catch it. Replaced with a plain `flagDefault()` helper; verified with a full `npx quasar build -m ssr`
 
 ## 8. Firebase rules (manual, outside this repo's tracked files)