Why: the duties tab only listed existing documents — rdm.docs.instantiate
had no UI entry, so a fresh project showed an empty duties tab with no
setup path (owner trial feedback 2026-10-15).
Evidence: new docs-instantiate-params tests green; full vitest run shows
only the 12 pre-existing conversation-work failures also present at clean
HEAD; design-guard green.
Impact: duties tab gains a template picker + title input wired to
rdm.docs.instantiate (backend command rdm.docs.templates lists published
identities); instantiation refreshes the catalog and selects the new doc.
Refs: Agent-System-RDM docs/records/dhf/u4-header-footer-slots.md
Why: Fine-grained viewers and managers need independent data loading, safe conflict recovery, and complete paged role access.
Evidence: Frontend 281 tests, production build, and knip baseline passed; independent final review found no remaining findings.
Impact: Adds action-specific controls, server-side role filters and paging, matrix cap editing, and sequence-safe draft rebasing.
Refs: feature/iam-u4-role-authority
Why: The Backend-authoritative role and account views replace the legacy local role and user panels.
Evidence: npm test; npm run build; node scripts/check-knip.mjs; UI npm test.
Impact: Keeps one role administration surface and restores the unused-export baseline.
Refs: feature/iam-u4-role-authority
Why: Object details render the same relationship row and must identify the endpoint relative to that object.
Evidence: Type checking identified the missing selected-object context after the endpoint fix.
Impact: Relationship rendering is consistent in the trace view and object details.
Refs: rdm-two-trees-latest-templates
Why: The trace view selected an endpoint by lexical ID order and could present the current section as its own source.
Evidence: Focused presentation tests cover both selected directions of a source-to-section relationship.
Impact: Source and impact columns now identify the object opposite the selected node.
Refs: rdm-two-trees-latest-templates
Why: Recursive template nodes without titles were rendered as repeated generic project objects in the audit tree.
Evidence: Focused presentation tests pass, including a regression for stable readable fallback names.
Impact: Template-derived paragraphs, tables, rows, cells, fields, and attachments remain distinguishable in the document tree.
Refs: rdm-two-trees-latest-templates
Why: Administrators and delegated system managers need focused role, user, and permission controls with search, filters, single-role editing, and a matrix view.
Evidence: Frontend 280 tests, production build, paired UI 163 tests, and design guards passed.
Impact: Replaces the RDM role panel with Backend role authority and adds optional user profiles, unique role assignment, and explicit system-grant editing.
Refs: Focused role and permission system task 7
Why: Single-role and matrix views need one typed Backend contract and one draft model so filtering cannot mutate authorization scope.
Evidence: Focused draft-model tests passed and the Frontend production build completed.
Impact: Adds role, binding, catalog, and system-grant APIs without changing visible UI yet.
Refs: Focused role and permission system task 6
Why: Project document and knowledge structures can contain nested nodes whose children must remain navigable beyond the first section level.
Evidence: A RED test first showed child-bearing sections were not expandable; presentation and design-guard tests, knip baseline 43, and npm run build now pass.
Impact: Recursively render any node marked with children while preserving current document fallback and readable node states.
Refs: TT-N01, TT-N02, TT-D01, TT-U01; two trees one graph vertical slice
Why: Project members need to understand who changed what, why, and with what impact without reading operation codes or raw audit payloads.
Evidence: A RED presentation test first failed on the missing humanization layer; 276 frontend tests passed, design guard 10 checks passed, knip stayed at baseline 43, and npm run build passed.
Impact: Humanize tree, relation, state, and operation vocabulary; render structured reason, impact, source, and outcome fields; raw event detail is no longer shown in the audit timeline.
Refs: TT-U01, TT-U02, TT-U03, TT-U04; two trees one graph stage-five plan
Why: Independent review found component-local color derivation, a private transition, and missing dark/molv coverage in the visual candidate.
Evidence: Frontend design guard passes and 19 Playwright scenarios cover light, dark, molv, and 320-1920px layouts.
Impact: Keeps the approved visual direction while moving color ownership to @ui tokens and removing private motion.
Refs: Agent-System-Dev feature/workbench-visual-redesign
Why: The inherited light-theme divider and hover treatment disappeared inside the new inverse create button.
Evidence: Focused browser layout test and production build pass locally.
Impact: Changes only the create action divider and hover surface.
Refs: Agent-System-Dev feature/workbench-visual-redesign
Why: Spacing-only refinements still looked like the original flat gray workspace and did not satisfy the approved visual redesign.
Evidence: 272 unit tests, 16 browser scenarios across 320-1920px, and the production build pass locally.
Impact: Gives navigation, authored messages, assistant results, and work details clearly different visual surfaces while preserving behavior.
Refs: Agent-System-Dev feature/workbench-visual-redesign
Why: The three-column workspace read as flat and visually scattered, making conversation, current work, and navigation difficult to distinguish.
Evidence: 272 unit tests, 16 focused browser scenarios across 320-1920px, and the production build pass locally.
Impact: Refines the existing workbench presentation without changing its data flow or fast/slow task behavior.
Refs: Agent-System-Dev feature/workbench-visual-redesign
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: 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: 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: 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 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: 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: 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: 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 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: Status words shared with a final reply could suppress a child completion record.
Evidence: 272 frontend unit tests, build, and 15 isolated browser scenarios.
Impact: Tag client-side collaboration replay so partial-delta deduplication preserves agent notes.
Refs: Agent-System-Dev feature/work-companion-visibility UI1
Why: A dropped delta batch can leave a short event prefix next to the complete saved message.
Evidence: 271 frontend unit tests, build, and 14 isolated browser scenarios.
Impact: Suppress overlapping partial replay text and thinking while retaining saved content.
Refs: Agent-System-Dev feature/work-companion-visibility UI1
Why: Event replay could hide saved retry notes and leave completed cards outside the active work filter.
Evidence: 270 frontend unit tests, build, and 14 isolated browser scenarios.
Impact: Merge replay into saved history, retain child progress, and locate cards under the right scope.
Refs: Agent-System-Dev feature/work-companion-visibility UI1 UI2
Why: Fast and slow channel cards duplicate across panes and completed replies hide process output.
Evidence: npm test; npm run build; 12 isolated Playwright scenarios with reload and responsive widths.
Impact: Preserve ordered folded process history, load durable run events, and give work cards one detailed pane.
Refs: Agent-System-Dev feature/work-companion-visibility UI1 UI2 UI3
Why: Users must see truthful first replies when work queues or cannot start.
Evidence: RED and GREEN HTTP browser receipts plus Frontend 269 tests and production build.
Impact: Adds two task-owned Playwright scenarios; production UI is unchanged.
Refs: U3 r0.5 independent review finding
Why: The first reply and task reuse need end-to-end checks across long and small material inputs.
Evidence: Dev evidence receipts for ten Playwright scenarios, Frontend tests, and build.
Impact: Adds browser-only coverage; production UI and API behavior are unchanged.
Refs: U3 r0.5 implementation plan Task 4
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 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: One system reminder can contain multiple failed child notices, so the browser test must wait for the whole batch rather than one message per child.
Evidence: The first post-merge HTTP/Playwright run failed only at this false one-to-one assumption; all six task-owned browser cases passed after counting notice entries in the persisted reminder.
Impact: Test-only correction; no production UI behavior change.
Refs: U3 r0.4 Task 6 review closure
Why: Keep the approved RDM export controls and the U3 material browser coverage in one component candidate.
Evidence: Changes in store.ts touch separate state fields and behavior; full Frontend tests/build and task-owned browser cases will be rerun after this merge.
Impact: Includes upstream RDM export UI without changing U3 source or notice contracts.
Refs: Dev U3 r0.4 Task 6 final review synchronization
Why: A failed task card can appear before its notification turn, and the second finding must be observed while work is still running.
Evidence: The strengthened browser checks first exposed missing fixture notice text and a zero-width second-stage window; after fixture correction all six task-owned HTTP/Playwright scenarios passed. Frontend 265 unit tests and build passed.
Impact: Test coverage only; no production UI change.
Refs: U3 r0.4 independent review Important 5
Why: The r0.4 acceptance must show running findings, zero and partial failure, and a source-bound choice in the real UI.
Evidence: Six task-owned HTTP/Playwright cases passed; npm test (265 tests) and npm run build passed.
Impact: Browser test coverage only; no production UI change.
Refs: U3 r0.4 Task 6
Why: Complete the authorized export entry while preserving current main project and session behavior.
Evidence: SELF full frontend tests and build, 263 unit tests; deferred browser races reproduced then all 6 passed. Raw records stay outside source until Dev task closure.
Impact: Export callbacks are invalidated on project, identity and unmount changes. Command readiness and current main security paths remain intact.
Refs: Dev PR #488; Frontend PR #73; user takeover authorization on 2026-10-14
Why: The U3 browser gate must show a host-generated pending question for underdetermined source counts.
Evidence: The new assertion failed against the old mechanism fixture while existing source-navigation and focus-flow tests remained observable; Backend fixture now emits structured premises.
Impact: Browser test inputs and assertion only; no production UI change.
Refs: Backend 756679d; Dev task feature/fast-slow-u2-u3-plan
Why: The Core mirror must satisfy the Frontend unused-export guard without changing the candidate shape.
Evidence: Dev make contracts regenerated the file; Frontend knip 51 <= 52 and build passed.
Impact: Type-only export visibility change.
Refs: Core b474394; Dev task feature/fast-slow-u2-u3-plan
Why: Frontend generated types must follow the single Core checkpoint contract.
Evidence: Dev make contracts generated the mirror; npm test and npm run build passed.
Impact: Type-only mirror update; persisted task cards and reading behavior stay unchanged.
Refs: Core c722c16; Dev task feature/fast-slow-u2-u3-plan
weichen
weichen