wangxuming/LWLT-AIBOT
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

merge: simplify account password flow

Browse Source
This commit is contained in:
inman committed 2026-09-02 11:21:08 +08:00
2 parents e530b7a348 df65e9f517
commit 029c8c6a59
10 files changed
+385 -102
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

.project-docs/30-worklog/tasks/20260902-integrate-password-flow-b73c91.md
+57
View File
@@ -0,0 +1,57 @@
# Task: Integrate simplified account password flow
## Identity
- Task ID: 20260902-integrate-password-flow-b73c91
- Mode: Integration
- Branch: main
- Worktree: /Users/inmanx/Documents/lwltAPI
- Base commit: e530b7a3489c8f2be2f15f69de2149658aaa8ca3
- Owner: codex
- Status: Ready for Integration
## Scope
- Integrate feature task `20260902-registration-invalid-params-59f94692` commits `203bfb3` and `df65e9f` into the current `main` branch after the dashboard tasks released the main worktree.
- Reconcile overlapping account UI and authorization tests while preserving the subsequently integrated dashboard layout and ranking-bar behavior.
- Run the complete repository verification gates on the merged result.
- Hand canonical promotion to a follow-on Integration Gate whose base commit already contains the source task record and supporting evidence, as required by the task-aware drift checker.
## Intent And Constraints
- Password entry points require a non-empty value but impose no application-level length restriction.
- Remove first-login forced password changes from the UI, API/session contract, and authorization gates; retain voluntary password change, administrator reset, and session revocation.
- Keep the historical `must_change_password` column compatibility-only and clear it on password writes rather than adding a destructive migration.
- Preserve all current dashboard changes already on `main`, account roles, owner isolation, route authorization, audit, and ERP safety boundaries.
- The user authorized merging to `main`; service restart, deployment, live account/database mutation, and ERP access remain out of scope.
## Outcome
- Merged feature commits `203bfb3246f70beb82f7759752d828cfc8259060` and `df65e9f5174b843de9722dfddcba172888f2b557` into the current `main` history without conflicts.
- Confirmed that the three subsequent dashboard commits and their ranking-bar UI remain present after the merge.
- Account creation, login, administrator reset, and self-service change now accept any non-empty password and impose no application-level length limit.
- Removed the first-login forced-change UI option, response/session flag, account badge, and read/mutation gates. Voluntary password change, administrator reset, session revocation, roles, owner isolation, route grants, and audit behavior remain intact.
- Kept canonical project-memory edits out of this source merge. The first drift run correctly identified that source task-owned records landed after this task's base commit; canonical promotion continues under task `20260902-promote-password-flow-c81d42` from the completed merge commit.
- No service restart, deployment, live account/database mutation, ERP access, or external delivery was performed.
## Verification
- Feature-worktree verification: account-form 4/4, focused authorization 8/8, repository check 10/10, control-plane 153/153, legacy 260/260, TypeScript check/build, JavaScript syntax, and diff check all passed.
- Integrated `main` `node --run check:repo`: 10/10 passed.
- Integrated `main` `node --run check`: passed.
- Integrated `main` `node --run test:control-plane`: 153/153 passed.
- Integrated `main` `node --run test:legacy`: 260/260 passed.
- Integrated `main` `node --run build`: passed.
- Integrated `main` `node --check LianSyn-platform/app.js`: passed.
- `git diff --check`: passed.
- `check_project_docs.py`: passed.
- The initial task-aware drift check correctly blocked canonical integration because the feature task record and evidence entered after this task's base commit. The check was not bypassed; source merge and canonical promotion were split so the follow-on integration task starts from the merged source commit.
## Follow-ups
- Continue canonical promotion under integration task `20260902-promote-password-flow-c81d42`.
- Restart or redeploy the standard service only under separate explicit authorization before relying on the new backend behavior in the running process.
## Promotion Candidates
- Carry the source feature task's accepted password-lifecycle candidates into integration task `20260902-promote-password-flow-c81d42`.
.project-docs/30-worklog/tasks/20260902-registration-invalid-params-59f94692.md
+70
View File
@@ -0,0 +1,70 @@
# 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: 3ed3af1feb503358b98fb57d3e8d97ab59d98129
- Owner: codex
- Status: Ready for Integration
## Scope
- 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.
## Intent And Constraints
- 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.
## 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 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 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`.
## Follow-ups
- 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
- 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
- [Account registration password validation evidence](../../50-evidence/topics/20260902-registration-invalid-params-59f94692__account-registration-password-validation.md)
.project-docs/50-evidence/topics/20260902-registration-invalid-params-59f94692__account-registration-password-validation.md
+34
View File
@@ -0,0 +1,34 @@
# Account Registration Password Validation Evidence
## Source
- Read-only inspection on 2026-09-02 of the standard service's privacy-safe structured diagnostics.
- Active account form, API request builder, `accountCreateSchema`, authentication validation, and account authorization tests at base commit `3ed3af1feb503358b98fb57d3e8d97ab59d98129`.
## Finding
- The two recent `http.request.invalid` events both reported only the validation path `password`.
- 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.
- No password, account name, request body, environment file, database row, or other business/user content was read or stored.
- No live account request or runtime mutation was performed.
## Confidence
- 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 a future product decision introduces password policy requirements, a forced-password-change lifecycle, or a replacement for the compatibility column.