fix: simplify account password flow

.project-docs/30-worklog/tasks/20260902-registration-invalid-params-59f94692.md

@@ -14,31 +14,35 @@
 
 - Diagnose the current account-creation failure reported as “请求参数不符合要求”。
 - Correlate the operator form contract, API payload, server-side validation, privacy-safe runtime diagnostics, and account authorization tests.
-- Add a narrowly scoped client-side validation and error-feedback fix plus regression coverage.
+- Apply the user's superseding product decision: passwords have no length restriction beyond being non-empty, and the first-login forced-password-change flow is removed.
+- Update the account UI, API validation, authentication mapping, compatibility writes, documentation, and regression coverage as one coherent change.
 - Do not create or change a real account, read secrets or request payloads, deploy, restart the service, or modify ERP behavior.
 
 ## Intent And Constraints
 
 - Preserve the accepted fixed-scope `admin` / `team_lead` / `user` account and authorization model.
-- Keep the server-side 12–512-character password boundary unchanged; prevent invalid form input from reaching the API and retain a safe backend-validation fallback.
+- Accept any non-empty password for login, account creation, administrator reset, and self-service password change; do not impose a minimum or maximum length in the application contract.
+- Remove the first-login forced-password-change behavior while retaining voluntary self-service password changes, administrator resets, and session revocation after password changes.
+- Keep the historical `must_change_password` database column as compatibility-only storage; runtime authorization and UI behavior must not depend on it, and password writes clear it to `false`.
 - Use runtime diagnostics only for validation field names; do not persist account names, passwords, request bodies, or other user data.
-- Treat the concurrent compact-dashboard task as a file-level overlap warning only; keep this change limited to the account form and its tests for later reconciliation.
+- Reconcile this isolated feature with concurrent main-branch dashboard work only after the main worktree ownership gate is released.
 
 ## Outcome
 
 - Privacy-safe diagnostics from the running standard service showed the two recent HTTP validation failures both had only `validation_paths=["password"]`; no request content was inspected.
-- Confirmed the mismatch: the API requires a 12–512-character password, while the account form used `novalidate` and submitted without an equivalent client-side check, causing a short password to surface only as the generic Zod response.
-- Added deterministic account-create validation before any API request. Invalid username, password, or role values now show a Chinese field-specific message, mark and focus the relevant field, and do not send a request.
-- Preserved safe backend fallback handling by retaining `error_code` and validation paths from API errors and mapping a server-side password rejection to the same actionable message.
-- Added the password requirement beside the form field and added focused regression coverage for short-password rejection, valid request normalization, backend fallback messaging, and visible form guidance.
+- Confirmed the original mismatch: the API required 12–512 characters while the form submitted under `novalidate`, so a short password reached Zod validation and surfaced as the generic message.
+- The initial length-guidance fix was superseded by the user's explicit direction. Account creation, reset, login, and self-service change now reject only an empty password and accept short non-empty values.
+- Removed the “首次登录必须修改密码” option, forced-password-change screen state, forced route/mutation gate, response flag, and account-list badge. The normal voluntary “修改密码” control remains available.
+- Existing `must_change_password` values no longer affect sessions or authorization; new account creation and password writes leave or force the compatibility column to `false`.
+- Added regression assertions covering one-character account passwords, empty-password rejection, absence of length rules, and absence of the first-login forced-change contract.
 - No live account, database, service process, deployment, ERP state, or external system was changed.
 
 ## Verification
 
-- Focused account-form regression: 4/4 passed.
-- Focused account-authorization regression: 8/8 passed.
+- Focused account-form regression: 4/4 passed after the superseding product change.
+- Focused account-authorization regression: 8/8 passed after the superseding product change.
 - `node --check LianSyn-platform/app.js`: passed.
-- `git diff --check`: passed before the final documentation update.
+- `git diff --check`: passed after the final code and documentation update.
 - `node --run check:repo`: 10/10 passed.
 - `node --run check`: passed.
 - `node --run test:control-plane`: 153/153 passed.
@@ -50,11 +54,16 @@
 
 ## Follow-ups
 
-- Integrate this isolated feature change with the concurrent dashboard layout work, then restart or redeploy the standard service only under separate explicit authorization before expecting the live `/accounts` page to change.
+- Merge this isolated feature into `main` after the concurrent main-worktree task releases ownership; the user explicitly authorized the merge.
+- Restart or redeploy the standard service only under separate explicit authorization before expecting backend behavior to change in the running process.
 
 ## Promotion Candidates
 
-- None recorded.
+- Target documents: `10-project-memory/architecture/system-overview.md`, `10-project-memory/decisions/AUTH-001-fixed-scope-account-isolation.md`, and `20-business-memory/business-rules.md`.
+- Proposed durable fact: application passwords are required to be non-empty but have no application-level length restriction; first-login forced password changes are disabled. Voluntary password change, administrator reset, and session revocation remain supported.
+- Evidence: this task's focused regressions, full repository verification, and the linked privacy-safe diagnosis record.
+- Future-task impact: account UI/API/schema changes must not reintroduce a length rule or `must_change_password`-based gate without a new product decision and migration plan.
+- Human confirmation: explicitly provided by the user on 2026-09-02.
 
 ## Supporting Records
 

.project-docs/50-evidence/topics/20260902-registration-invalid-params-59f94692__account-registration-password-validation.md

@@ -8,10 +8,17 @@
 ## Finding
 
 - The two recent `http.request.invalid` events both reported only the validation path `password`.
-- The server contract requires an initial password length of 12–512 characters.
+- At the inspected base commit, the server contract required an initial password length of 12–512 characters.
 - The HTML field declared the same `minlength` and `maxlength`, but the account form used `novalidate` and the JavaScript request path did not perform its own validation before calling `/api/accounts`.
 - Therefore a short initial password reached server-side Zod validation and the UI displayed the generic response “请求参数不符合要求。” instead of the actual password requirement.
 
+## User Decision And Resolution
+
+- The user explicitly superseded the original password-length contract: all password entry points now require only a non-empty value and impose no application-level minimum or maximum length.
+- The user also directed removal of the first-login forced-password-change flow. The UI option, session flag, route gate, account badge, and forced panel state were removed; voluntary password changes remain available.
+- The historical `must_change_password` database column is retained only for schema compatibility and is ignored by runtime authorization. Password writes clear it to `false`.
+- This change was implemented and verified in an isolated feature worktree. No running service was restarted and no live account or database row was mutated.
+
 ## Privacy And Safety
 
 - Only diagnostic event type and validation field paths were extracted.
@@ -20,8 +27,8 @@
 
 ## Confidence
 
-- High. Runtime field-path evidence, the active form behavior, and the server schema all identify the same password-length mismatch.
+- High. Runtime field-path evidence and the inspected base contract identify the original mismatch; the replacement behavior is directly confirmed by the user's product decision and regression coverage.
 
 ## Stale Trigger
 
-- Reassess if the password contract, account form submission flow, or generic API validation response changes.
+- Reassess if a future product decision introduces password policy requirements, a forced-password-change lifecycle, or a replacement for the compatibility column.