The system-management account view creates ordinary accounts without assigning a password, accepts optional profile details, and shows pending trusted-owner initialization. Administrators can search allowed fields, inspect state, disable or re-enable accounts, and manage proof-bound recovery proposals without receiving credentials. The personal account flow shows the server-selected password-change mode and recovery status.
After review, successful writes reset signed-cursor pagination. A lost recovery-proposal response triggers a non-secret status refresh; an explicit retry uses the original idempotency key. Terminal proposals are described by their actual status, and late responses from a previously selected account cannot overwrite the current account. This PR uses the existing UI tokens and controls; the UI repository source is unchanged.
Evidence and delivery state
Product source: Frontend 055476d1354834f63a28fb895d4f281b724dc1cb, paired UI 7c35a78abc8ef7db6fb2d508b2971d59a90de964, Backend owner-published v0.5.0 tree. Commits through current PR HEAD 93ee72313143cad677c46b2b5a7691f052f76157 add only the Gitea CI workflow after that product source.
SELF: 272 Frontend tests and production build passed. A fresh isolated browser run covered first-admin activation, password login, second-page passwordless creation, exact search, disable/enable, lost response after proposal revocation, same-key terminal retry, and account switching without stale proposal state.
Independent /root/u3_stage7_replay reran the product source in real Chromium with an isolated SQLite Backend. Full log /tmp/iam-u3-frontend-terminal-loss-replay-055476d-_wer3ijn.log, SHA256 d628bc8ec9827f81881d22a1b038afcf334b5d15e1983da116f9f0ef671e63ec; Dev U3 task card imports the original log. Source review of 34f6a1b found no remaining focused blocker; 055476d corrected one notice wording detail.
GATE: run 3215/job 4911 on current HEAD 93ee72313143cad677c46b2b5a7691f052f76157 completed successfully on home-runner: fixed Frontend/UI checkout, Node and dependency installation, 272 tests, and production build. A repository-scoped read-only UI deploy key is held as the Frontend UI_DEPLOY_KEY Actions secret; the key is removed from the runner after checkout. Earlier failed runs 3212–3214 remain visible as CI-setup diagnostics. The PR stays draft until Stage 7 human review and Stage 8 final review.
Dependencies and limits
RDM provider-consumer verification is tracked in draft PR #380. Browser evidence is Vite preview plus isolated SQLite Backend; embedded RDM, PostgreSQL, mobile layout, production migration, deployment and real accounts remain outside this check.
Refs: IAM U3 r1 account contract and approved amendments; Dev U3 task card feature/iam-u3-account-directory-recovery.
## Behavior
The system-management account view creates ordinary accounts without assigning a password, accepts optional profile details, and shows pending trusted-owner initialization. Administrators can search allowed fields, inspect state, disable or re-enable accounts, and manage proof-bound recovery proposals without receiving credentials. The personal account flow shows the server-selected password-change mode and recovery status.
After review, successful writes reset signed-cursor pagination. A lost recovery-proposal response triggers a non-secret status refresh; an explicit retry uses the original idempotency key. Terminal proposals are described by their actual status, and late responses from a previously selected account cannot overwrite the current account. This PR uses the existing UI tokens and controls; the UI repository source is unchanged.
## Evidence and delivery state
- Product source: Frontend `055476d1354834f63a28fb895d4f281b724dc1cb`, paired UI `7c35a78abc8ef7db6fb2d508b2971d59a90de964`, Backend owner-published `v0.5.0` tree. Commits through current PR HEAD `93ee72313143cad677c46b2b5a7691f052f76157` add only the Gitea CI workflow after that product source.
- SELF: 272 Frontend tests and production build passed. A fresh isolated browser run covered first-admin activation, password login, second-page passwordless creation, exact search, disable/enable, lost response after proposal revocation, same-key terminal retry, and account switching without stale proposal state.
- Independent `/root/u3_stage7_replay` reran the product source in real Chromium with an isolated SQLite Backend. Full log `/tmp/iam-u3-frontend-terminal-loss-replay-055476d-_wer3ijn.log`, SHA256 `d628bc8ec9827f81881d22a1b038afcf334b5d15e1983da116f9f0ef671e63ec`; Dev U3 task card imports the original log. Source review of `34f6a1b` found no remaining focused blocker; `055476d` corrected one notice wording detail.
- GATE: [run 3215/job 4911](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Frontend/actions/runs/3215/jobs/4911) on current HEAD `93ee72313143cad677c46b2b5a7691f052f76157` completed successfully on `home-runner`: fixed Frontend/UI checkout, Node and dependency installation, 272 tests, and production build. A repository-scoped read-only UI deploy key is held as the Frontend `UI_DEPLOY_KEY` Actions secret; the key is removed from the runner after checkout. Earlier failed runs 3212–3214 remain visible as CI-setup diagnostics. The PR stays draft until Stage 7 human review and Stage 8 final review.
## Dependencies and limits
RDM provider-consumer verification is tracked in draft PR #380. Browser evidence is Vite preview plus isolated SQLite Backend; embedded RDM, PostgreSQL, mobile layout, production migration, deployment and real accounts remain outside this check.
Refs: IAM U3 r1 account contract and approved amendments; Dev U3 task card `feature/iam-u3-account-directory-recovery`.
Why: A lost confirmation or grant-rotation response must not imply that the one-time plaintext can be read again.
Evidence: SELF receipt /tmp/iam-u3-frontend-idempotent-test.json and a normal pinned-UI build after the change.
Impact: The owner view shows current proposal status and offers an explicit new-grant action only when the server returns no plaintext.
Refs: IAM U3 r1 stages 4-5; Dev feature/iam-u3-account-directory-recovery
Why: RDM duty.get publishes capitalized domain role keys, so a selected document appeared to have no assigned people in the new stable-ID picker.
Evidence: SELF receipts /tmp/iam-u3-rdm-ui-wire-compat.json and /tmp/iam-u3-frontend-wire-compat-test.json; normal pinned-UI build passed.
Impact: The workbench accepts both existing capitalized and lower-camel role fields without changing the RDM public response contract.
Refs: IAM U3 r1 stages 4-5; Dev feature/iam-u3-account-directory-recovery
Why: A successful mutation from a later search page reused an invalid signed cursor and falsely reported a write conflict; a lost recovery-proposal response left a committed proposal hidden and retried with a fresh key.
Evidence: Isolated browser red runs reproduced the stale-page duplicate warning and unknown proposal status; after the fix the combined page-two and lost-response flow passed, as did 272 Frontend tests and a production build.
Impact: Successful writes restart pagination and keep their success status, while uncertain proposal outcomes re-read metadata and reuse the same idempotency key for explicit retry.
Refs: IAM U3 Stage 7; Frontend PR #86
Why: A lost proposal response followed by revocation could leave admins with an ambiguous result, and a late response could overwrite a newly selected account.
Evidence: Frontend 272 tests and production build passed; isolated browser replay covered lost response, terminal retry, and account switch.
Impact: Recovery notices reflect current proposal state, and stale account requests cannot update the selected detail.
Refs: IAM U3 account directory and recovery
Why: A confirmed proposal should not instruct the owner to confirm it again.
Evidence: Frontend tests and production build passed at the changed source.
Impact: Confirmation notice describes the existing state and keeps credential authority with the owner.
Refs: IAM U3 account recovery
Why: The Frontend repository lacked an exact-HEAD CI gate for U3 delivery.
Evidence: Workflow syntax parsed locally; Frontend and pinned UI tests and build passed locally; platform run pending.
Impact: PR and main checks now fetch fixed Frontend/UI commits and run install, tests, and production build.
Refs: IAM U3 delivery gate
Why: The runner may inject an internal Gitea URL rather than the public browser URL.
Evidence: PR CI run 3212 exited at checkout preflight before any fetch; updated YAML parses locally.
Impact: Checkout validates the injected URL shape and logs nonsecret event context.
Refs: IAM U3 Frontend PR #86
Why: Gitea job token can fetch Frontend but receives repository-not-found for private UI.
Evidence: PR CI run 3213 checkout log shows Frontend fetch succeeded and UI fetch failed; Frontend secret listing lacks SUBMODULE_TOKEN.
Impact: CI now requests the dedicated UI read credential and fails clearly until it is provisioned.
Refs: IAM U3 Frontend PR #86
Why: The Gitea job token cannot read the private UI repository and this server lacks HTTPS deploy-token API support.
Evidence: Repository-scoped UI deploy key read was verified; Frontend Actions secret UI_DEPLOY_KEY is listed; prior CI run 3214 confirmed the missing credential gate.
Impact: Exact-pin CI uses a read-only SSH key and pinned host identity, deleting the transient key after checkout.
Refs: IAM U3 Frontend PR #86
Why: The CI runner executed a mirror-downloaded toolchain without authenticating its contents.
Evidence: The pinned SHA256 matches the signed Node.js v22.23.3 release manifest and the current mirror archive.
Impact: CI fails before extraction if the Node archive differs from the reviewed release artifact.
Refs: IAM U3 Frontend PR #86
Why: An early filesystem failure could exit before the UI deploy key cleanup trap existed.
Evidence: Parsed workflow confirms the EXIT trap precedes the first secret write.
Impact: Normal checkout failures remove both transient credential files from the runner.
Refs: IAM U3 Frontend PR #86
Why: PR #86 predates IAM U4 and the account-chain UI on main; the U3 behaviour was ported onto main by agent-exec transports d47c493, 72c941c and afd9e75, so this merge only records the U3 branch history.
Evidence: tree equals afd9e75; host tsc -b, vitest 565 passed, build and knip on 72c941c (SELF); independent review blocking item fixed in afd9e75.
Impact: no tree change versus afd9e75.
Refs: Frontend PR #86, base main 1650b4f
Why: the branch predates Frontend governance adoption and had no task card, so pr-check refused PR #86.
Evidence: card records the agent-exec units, host verification log, CI and independent review of e4041b3.
Impact: task card only.
Refs: Frontend PR #86
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: close the card in the same PR before merging.
Evidence: pr-check PR_CHECK_OK on 080c630.
Impact: task card only.
Refs: Frontend PR #86
Co-authored-by: Cursor <cursoragent@cursor.com>
weichen
marked the pull request as ready for review 2026-10-19 01:08:08 +00:00
weichen
merged commit 6db528df10 into main2026-10-19 01:08:09 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Behavior
The system-management account view creates ordinary accounts without assigning a password, accepts optional profile details, and shows pending trusted-owner initialization. Administrators can search allowed fields, inspect state, disable or re-enable accounts, and manage proof-bound recovery proposals without receiving credentials. The personal account flow shows the server-selected password-change mode and recovery status.
After review, successful writes reset signed-cursor pagination. A lost recovery-proposal response triggers a non-secret status refresh; an explicit retry uses the original idempotency key. Terminal proposals are described by their actual status, and late responses from a previously selected account cannot overwrite the current account. This PR uses the existing UI tokens and controls; the UI repository source is unchanged.
Evidence and delivery state
055476d1354834f63a28fb895d4f281b724dc1cb, paired UI7c35a78abc8ef7db6fb2d508b2971d59a90de964, Backend owner-publishedv0.5.0tree. Commits through current PR HEAD93ee72313143cad677c46b2b5a7691f052f76157add only the Gitea CI workflow after that product source./root/u3_stage7_replayreran the product source in real Chromium with an isolated SQLite Backend. Full log/tmp/iam-u3-frontend-terminal-loss-replay-055476d-_wer3ijn.log, SHA256d628bc8ec9827f81881d22a1b038afcf334b5d15e1983da116f9f0ef671e63ec; Dev U3 task card imports the original log. Source review of34f6a1bfound no remaining focused blocker;055476dcorrected one notice wording detail.93ee72313143cad677c46b2b5a7691f052f76157completed successfully onhome-runner: fixed Frontend/UI checkout, Node and dependency installation, 272 tests, and production build. A repository-scoped read-only UI deploy key is held as the FrontendUI_DEPLOY_KEYActions secret; the key is removed from the runner after checkout. Earlier failed runs 3212–3214 remain visible as CI-setup diagnostics. The PR stays draft until Stage 7 human review and Stage 8 final review.Dependencies and limits
RDM provider-consumer verification is tracked in draft PR #380. Browser evidence is Vite preview plus isolated SQLite Backend; embedded RDM, PostgreSQL, mobile layout, production migration, deployment and real accounts remain outside this check.
Refs: IAM U3 r1 account contract and approved amendments; Dev U3 task card
feature/iam-u3-account-directory-recovery.