Initialize super-admin plan and task card

Why: Set up the task card and approved implementation plan for environment-configured super-admin.

Evidence: make precheck and task-start validated.

Impact: Establishes task metadata and implementation baseline.

Refs: #0

docs/superpowers/plans/2026-10-19-0113-super-admin-plan.md

@@ -0,0 +1,124 @@
+---
+title: Environment-configured super administrator
+date: 2026-10-19
+type: plan
+artifact_contract: ce-unified-plan/v1
+product_contract_source: ce-plan-bootstrap
+execution: code
+---
+
+## Goal Capsule
+
+- **Objective:** The system has one environment-configured super administrator who can appoint system administrators, while administrators can create ordinary accounts but cannot elevate accounts or reset the super administrator's password.
+- **Means:** Add an explicit super-administrator identity and apply its authority in server-side authentication and account-management checks (KTD1).
+- **Authority:** The user request in this session; preserve current project and RDM domain authorization boundaries.
+- **Execution profile:** Implement in bounded Backend and Frontend units, with focused SQLite/PostgreSQL tests and browser coverage for changed account-management flows.
+- **Stop conditions:** Stop when the requirements and direct verification pass. Do not change RDM domain-admin authority, general recovery policy, deployment state, or unrelated role capabilities.
+- **Delivery owner:** Host owns planning, scope review, integration, authoritative verification, review, PR/CI, and safe closure under repository policy; implementation units use the configured agent-per-unit route.
+
+## Product Contract
+
+### Summary
+
+Configure a single highest-privilege system administrator using credentials supplied through `.env`. This account may create administrator accounts or promote an existing account. Other administrator accounts may create ordinary accounts only and cannot reset the super administrator's password. The super administrator may change their password in the product; the configured environment password remains a separate fallback login credential.
+
+### Problem Frame
+
+The system currently has `is_admin` accounts and delegated system actions, but no distinct super-administrator identity. That makes it impossible to reserve administrator appointment and super-administrator protection to one bootstrap authority while retaining ordinary administrator account creation.
+
+### Requirements
+
+- R1. In authentication-enabled account-management deployments, exactly one system super-administrator identity is configured by `SUPER_ADMIN_OWNER` and `SUPER_ADMIN_PASSWORD` in the process environment sourced from the protected `.env` configuration. Missing, partial, invalid, or unavailable configuration must fail closed with a clear startup error; the unauthenticated embedded single-user mode must not expose account-administration operations. Secret values must never be logged or returned by APIs.
+- R2. The configured identity is established as a distinct super-administrator in persistent account state. It is never inferred from legacy `is_admin`, a role, a project membership, or RDM domain-admin state.
+- R3. The super administrator can create ordinary accounts and can create administrator accounts or promote an existing account to administrator.
+- R4. An ordinary administrator can create ordinary accounts, but every server-side path that creates or grants administrator authority rejects that actor, regardless of UI visibility or supplied request fields.
+- R5. An ordinary administrator cannot reset, recover, rename, delete, disable, or demote the super-administrator account through account-management or CLI paths. Ordinary administrators cannot change their own or another account's administrative authority through account creation, role assignment, system-grant APIs, or CLI commands. The super administrator can change their own password through R6 but cannot remove or transfer the unique super-administrator identity through product account-management paths.
+- R6. The super administrator can change their password through the existing authenticated password-change flow. The changed password and configured environment fallback password both authenticate that same identity; changing the database password does not remove the fallback.
+- R7. Failed super-administrator password checks follow the existing login throttling and session-version rules. Successful login and password changes continue to use HttpOnly sessions and existing credential/audit safeguards.
+- R8. The UI identifies the super administrator and exposes administrator creation/promotion controls only to that identity. Server authorization remains authoritative.
+
+### Scope Boundaries
+
+- Preserve existing RDM domain-admin separation and project/resource authorization.
+- Do not add multiple super administrators, self-registration, a new recovery channel, an alternate CLI administrator-bootstrap path, or production deployment/migration operations.
+- Do not reduce unrelated permissions of delegated users beyond the account-elevation and super-administrator-protection rules in R4-R5.
+
+## Planning Contract
+
+### Key Technical Decisions
+
+- KTD1. **Model super-administrator as a separate system identity flag.** Keep `is_admin` for compatibility and ordinary system-admin behavior, while a dedicated persisted marker identifies the single highest-privilege account. `is_admin` remains true for the super administrator, but never implies super-administrator status.
+- KTD2. **Use the database password and environment fallback as two valid credentials for the configured owner.** Verify both only for the super-administrator identity, retain the environment secret only in process memory, and never overwrite it when the UI changes the database password.
+- KTD3. **Enforce privilege boundaries on the server and within account-write transactions.** Apply one consistent super-admin-aware authorization rule to account creation, role assignment, system-grant changes, state changes, resets, and recovery entry points that can affect administrator or super-administrator authority.
+- KTD4. **Bootstrap idempotently and fail closed on identity conflict.** Startup may establish the configured account and its initial password when absent or uninitialized; if the owner already belongs to another account or a second super-admin marker exists, startup must stop instead of silently promoting, replacing credentials, or creating a second authority.
+
+### High-Level Technical Design
+
+Backend startup reads the two required settings from `.env` through the supported runtime environment-file path, validates them, and passes an immutable secret-bearing configuration object into account initialization and the authentication service. The database stores the designated account identity and the ordinary password hash; the configured fallback is not persisted. Login checks the normal password hash first, then the fallback only when the requested owner matches the configured super administrator. Account authorization resolves the persisted marker from trusted server state and applies actor/target constraints before each write. Frontend account screens consume a server-provided `isSuperAdmin` field and conditionally show the elevation controls.
+
+The Backend currently reads configuration from process environment but no dotenv parser was found. U1 must verify the actual service launcher and make its protected `.env` values available to the Backend through that supported runtime path. If no such path exists, add one narrowly scoped `.env` loading mechanism at the existing configuration boundary; do not silently fall back to missing credentials or duplicate parsing across modules.
+
+### Assumptions
+
+- `SUPER_ADMIN_OWNER` is a stable account identifier; renaming it or transferring super-admin authority is outside this change.
+- `.env` remains protected from source control and has restrictive filesystem permissions in deployments.
+- If the fallback secret is exposed, an operator must rotate `SUPER_ADMIN_PASSWORD` in `.env` and restart the service; the UI password change does not revoke this fallback.
+- Existing account password hashing, password policy, lockout, session revocation, and audit mechanisms remain the authoritative primitives.
+
+## Implementation Units
+
+### U1. Configure and bootstrap the single super administrator
+
+- **Goal:** Load validated super-administrator settings and establish exactly one persistent super-administrator identity without silently taking over a conflicting account.
+- **Requirements:** R1, R2
+- **Files:** `modules/backend/cmd/agent-system/main.go`, `modules/backend/internal/app/`, `modules/backend/internal/store/account_model.go`, `modules/backend/internal/store/migrate.go`, `modules/backend/internal/server/server.go`, `scripts/svc.sh`
+- **Approach:** Trace and wire the protected `.env` startup path; pass credentials via a dedicated config boundary; add a schema migration and idempotent bootstrap operation; reject account-admin operations when authentication is disabled; keep secrets out of persistent storage, diagnostics, and JSON projections.
+- **Test Scenarios:** Both values absent, only one present, invalid password, first bootstrap, repeated bootstrap, conflicting existing owner, duplicate marker, and legacy databases with administrators but no super administrator.
+- **Verification:** Focused Backend config, store migration/bootstrap, and startup tests on SQLite and PostgreSQL.
+
+### U2. Add fallback login and password-change behavior
+
+- **Goal:** Let the configured super administrator authenticate with either the database password or the `.env` fallback, including after changing the database password in the UI.
+- **Requirements:** R6, R7
+- **Files:** `modules/backend/internal/server/accounts.go`, `modules/backend/internal/store/auth.go`, `modules/backend/internal/server/auth.go`, `modules/backend/internal/server/login_recovery_test.go`
+- **Approach:** Extend the login verifier at the authentication boundary; fallback comparison is limited to the configured super-admin owner; retain current rate limiting, verified-session version checks, and normal password-change behavior.
+- **Test Scenarios:** Initial environment password works; UI password change makes both new and fallback passwords valid; old database password stops working; fallback fails for every other owner; disabled/missing account and throttled attempts remain rejected.
+- **Verification:** Focused login/password tests covering password-change session handling and audit effects, plus existing account serialization tests where verifier changes affect session races.
+
+### U3. Enforce super-admin-only appointment and target protection
+
+- **Goal:** Restrict admin creation/promotion to the super administrator and make the super-administrator account untouchable by ordinary admin maintenance paths.
+- **Requirements:** R3, R4, R5
+- **Files:** `modules/backend/cmd/agent-system/main.go`, `modules/backend/internal/app/`, `modules/backend/internal/server/accounts.go`, `modules/backend/internal/server/roles.go`, `modules/backend/internal/store/account_model.go`, `modules/backend/internal/store/role_policy.go`, `modules/backend/internal/authz/`
+- **Approach:** Audit every account/admin elevation and target mutation route, including `user create --admin`, `user create --role admin`, and `user bootstrap-admin`; only configured startup bootstrap may establish the super administrator, and no CLI path may appoint another administrator. Enforce actor and target checks in the authorization/write boundary, including transactional rechecks for race safety. Preserve the ordinary-admin path for creating pending user accounts.
+- **Test Scenarios:** Super admin creates/promotes admin; ordinary admin creates user; ordinary admin cannot create/promote admin by request payload, role assignment, grants, or CLI commands; neither ordinary admin nor legacy admin can reset/recover/rename/delete/disable/demote the super admin; super admin can change their own password but cannot transfer or remove the unique super-admin identity; auth-disabled mode exposes no account-administration operations; unauthorized and concurrent changes are rejected without partial writes.
+- **Verification:** Focused account, role-policy, and recovery authorization tests on SQLite and PostgreSQL.
+
+### U4. Surface identity and available account actions in the UI
+
+- **Goal:** Make super-administrator status and allowed administrator-management actions clear in account-management screens.
+- **Requirements:** R3, R4, R8
+- **Files:** `modules/backend/internal/server/accounts.go`, `modules/frontend/src/components/AdminZone.tsx`, `modules/frontend/src/components/AccountUsersPanel.tsx`, `modules/frontend/src/components/adminSections.tsx`, `modules/frontend/e2e/admin-user-create.playwright.ts`, `modules/frontend/e2e/iam-role-authority.playwright.ts`
+- **Approach:** Add a non-secret `isSuperAdmin` identity projection and show admin-create/promotion actions only for that user. Keep ordinary account creation available to authorized admins and avoid exposing environment credentials or fallback status details.
+- **Test Scenarios:** In the primary `AccountUsersPanel`, super admin sees admin-promotion controls and can complete promotion; ordinary admin sees ordinary-account creation without elevation controls; direct API calls remain rejected when controls are hidden; layout remains usable at supported viewport sizes.
+- **Verification:** Focused Frontend typecheck and Playwright coverage for the account-management flow.
+
+## Verification Contract
+
+| Scope | Verification | Proves |
+|---|---|---|
+| Backend account/auth changes | Focused `go test` packages under `modules/backend/internal/server`, `internal/store`, `internal/app`, and `cmd/agent-system` | Bootstrap, dual-credential login, account elevation boundaries, and compatibility |
+| Database portability | Relevant PostgreSQL integration tests in the affected Backend packages | Migration/bootstrap and transactional authorization behavior on PostgreSQL |
+| UI behavior | Focused Frontend typecheck and admin-user Playwright tests | Correct controls and browser-visible account flow |
+| Final candidate | `make test` when required by the selected delivery tier and exact repository gate | Fixed Dev/component composition and repository-required checks |
+
+No production deployment or live `.env` credential test is included in this plan. Runtime acceptance requires a separately authorized environment and must use test credentials without recording secret values.
+
+## Definition of Done
+
+- Exactly one environment-configured super administrator can be established, and startup rejects ambiguous or conflicting identity state.
+- The super administrator can appoint administrators; other administrators can create ordinary accounts but cannot grant administrative authority.
+- Ordinary administrators cannot mutate the super-administrator account through supported account-management or recovery paths.
+- The super administrator can change the database password in the UI and can continue to log in with the configured fallback.
+- Server tests, affected database coverage, focused browser verification, code review, and repository delivery gates pass for the exact candidate; secrets are absent from logs, responses, and committed files.
+- Abandoned implementation attempts are removed, and no production deployment, credential rotation, or history-changing action is performed without its required authorization.