Task: Fix account registration invalid request parameters

Identity

Task ID: 20260902-registration-invalid-params-59f94692
Mode: Feature
Branch: codex/20260902-registration-invalid-params-59f94692-registration-invalid-params-59f94692
Worktree: /Users/inmanx/Documents/lwltAPI-registration-invalid-params-59f94692
Base commit: 3ed3af1feb
Owner: codex
Status: Ready for Integration

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.
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.

Preserve the accepted fixed-scope admin / team_lead / user account and authorization model.
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.
Reconcile this isolated feature with concurrent main-branch dashboard work only after the main worktree ownership gate is released.

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 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.

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 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.
node --run test:legacy: 260/260 passed, including the new four tests.
node --run build: passed.
check_project_docs.py: passed.
check_doc_drift.py --task-id 20260902-registration-invalid-params-59f94692: passed.
Verification used the bundled Node runtime and a temporary ignored node_modules symlink to the existing dependency tree because Node was not on the isolated shell PATH.

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.

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.