Why: U4 must sync main before stage 7 acceptance; main carries 21 newer commits (renderer, regulations and two-trees documents). Evidence: git merge-tree reported no conflicts; no content resolved by hand. Impact: U4 documents now sit on main 5bb4877. Refs: Dev card feature-iam-u4-role-authority
Why: Register the U9 public contract proposal.
Evidence: CI success on 3a3904fe (governance).
Impact: Documentation only.
Refs: .task/feature-regulations-kb-ext20-proposal.md
Why: the adoption PR is reviewed and its candidate HEAD passed CI; the card closure is folded into the PR so no separate close PR is needed.
Evidence: CI GATE on 9d4582a47f4f4c887afd2fafb3ad507f20716f8d; independent Review REPLAY (cursor-agent-stable --mode ask 全新只读会话（fresh_session=true，session id not-observable）闭合重审 VERDICT: APPROVE（对象 9d4582a，与 HEAD 仅 .task/ 不同）).
Impact: task card only (moved to .task/archive/).
Refs: https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/110
Why: independent Review blocked the adoption; the repair unit ran through the shared executor and was integrated with agent-exec apply.
Evidence: .task/evidence/governance-adoption/ (SELF): governance check and agent-exec validate on the repaired head.
Impact: task card and evidence logs only.
Refs: .task/feature-governance-adoption.md
Why: Phase 6 requires one positive executor run and the negative cases (missing config, bad receipt, out-of-scope path, unknown side effect) before adoption becomes active.
Evidence: .task/evidence/governance-adoption/ (SELF): governance check, agent-exec validate and adoption cases; this commit passed the generated pre-commit hook (admit).
Impact: task card and evidence logs only.
Refs: .task/feature-governance-adoption.md
Why: development-governance-v2 Phase 6 adopts the shared governance kit in every formal repository; the executor needs a valid AGENT-EXECUTION.md before any implementation unit can run.
Evidence: generated by dm-server governance init at Development-Manager bd3a7de57a3a9e1a4495b94c5fa5c08d71e7be8c; dm-server agent-exec validate passes.
Impact: configuration and task card only; no code or CI change yet.
Refs: Agent-System-Dev docs/superpowers/plans/2026-10-16-development-governance-v2-master.md
Why: 8788 could not render docx because the sandbox hides host site-packages and there is no request path for extra packages. The proposal fixes the design before the implementation lands.
Evidence: SELF — proposal written from the cnv_7936c0a799ff transcript and the existing exec-deps-dir code path.
Impact: Documents only. Index lists the proposal as pending review, not approved.
Refs: docs/proposals/2026-10-15-layered-python-env.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: the duty page needs one record for the four domain rulings, and the earlier settings plan must show which duty-page sections it no longer owns.
Evidence: SELF review of the proposal text against the approved implementation plan.
Impact: r1 section 4 and the duty-page parts of P5 and P7 point at r2. Settings, members, and the permission matrix stay in r1.
Refs: docs/proposals/2026-10-15-rdm-duty-matrix-rework.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: keep the compose proposal in the document set while it remains under review.
Evidence: this repository has no workflow; head 2a8deac89d contains origin/main. Backend CI is already green and merged.
Impact: proposal status stays pending review. Inclusion is not approval.
Refs: #107
Why: The approved role and permission implementation needs a focused, reviewable path through browser acceptance, component delivery, and guarded closure.
Evidence: Structural audit confirms DR1-DR21, U1-U9, and KTD1-KTD6; git diff --check passes; six-lens document review findings are incorporated.
Impact: Adds the stage 7-10 plan, records the focused specification approval, and indexes the plan without authorizing production migration or deployment.
Refs: feature/iam-u4-role-authority
Why: base the IAM delivery plan on the current Documents main.
Evidence: fetched origin/main=87b88018b9236434b97ff6781655d625901d4090.
Impact: integrates documentation-only upstream changes before adding the U4 delivery plan.
Refs: feature/iam-u4-role-authority
Why: deploy needs a reviewed design for compiling selected plugins into the base binary before that behavior is treated as approved.
Evidence: the proposal records the throwaway compose build; implementation status stays unreviewed.
Impact: adds a pending proposal and an index link. Inclusion does not approve the design.
Refs: Dev .task/feature-svc-plugin-compose.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: the plan's progress annex still described the pre-adjudication
state (44 needs-review, U2-U6 pending); the authoritative record must
reflect the 2026-10-14 landing: batch adjudication, publication flip
(44/44 published), U5 product-loop wiring with pilot pass, U6
per-identity matrix (41 PASS + 2 EXPECTED_BLOCKED + 1 EXPECTED_LIMITED),
and the owner-side exit items (deployment pilot, independent REPLAY,
U4 originals) now blocked on the owner per the handoff checklist.
Evidence: docs-only change in the Documents repo; all referenced RDM
PRs (#377/#381/#383/#385/#387/#389/#391) carry green CI and merged
state; pilot and matrix outputs are recorded in the RDM task cards and
docs/records/dhf/.
Impact: plan annex only; no code or asset change.
Refs: RDM docs/records/dhf/package-review-decision-2026-10-14.md;
RDM docs/records/dhf/u6-acceptance.md; u6-replay-handoff.md
Why: The approved scope spans Backend authority, RDM project enforcement, and Frontend configuration and needs exact contracts and verification boundaries.
Evidence: The plan was checked against every specification section, fixed interface names, failure cases, and placeholder rules.
Impact: Implementation is limited to one effective role, system and project authorization, and the requested configuration views.
Refs: Focused role and permission system spec
Why: The implementation scope must match the requested single-role position model and three permission layers without carrying unrelated IAM work.
Evidence: The spec was checked for placeholders, internal contradictions, and whitespace errors.
Impact: Backend becomes the role authority while RDM retains project permissions and document duties.
Refs: IAM role and permission system
Why: Preserve the owner’s Stage 5 decision and implementation method on the reviewed plan object.
Evidence: Owner approved plan 28c4ceb in the task conversation; git diff --check and relative links passed (SELF).
Impact: Documentation status only; Dev implementation remains subject to Stage 6 and 7 review.
Refs: Agent-System-Documents #105; Agent-System-Dev #518
Why: The approved Stage 4 design needs a reviewable Stage 5 implementation and test sequence.
Evidence: git diff --check, relative-link validation, M2-1 through M2-6 coverage, and placeholder scan passed (SELF).
Impact: Documentation only; no Dev queue activation or task takeover.
Refs: Agent-System-Documents #104; Agent-System-Dev #518
Why: The first trial reduced final CI churn, while later Dev merges exposed gaps in shared window records that must be addressed before broadening manual coordination.
Evidence: SELF Gitea API snapshot for PR #539–#548, current #518 comments, protection and open PR states; fixed first-trial report and current project rules reviewed.
Impact: Add a stage-4 design and evidence snapshot only; no queue activation, platform protection change, production task takeover, or workflow edit.
Refs: Dev issue #518; Documents 2026-10-14 merge queue trial report
Why: the progress note still listed Documents #102, RDM #365 and Dev
#540 as WIP and said the stage-8 review was under rectification, but all
three PRs merged on 2026-10-14 and the Dev task card is archived; the
note must state the terminal state instead of stale WIP/GATE caveats.
Evidence: merge SHAs 9062445 (Documents), 57d2214 (RDM), 11aa76a (Dev)
per the archived card .task/archive/feature-dhf-template-pipeline-plan.md
(Dev #542); this change is documentation-only and does not touch the
frozen r0.1 body or its recorded SHA256.
Impact: readers of the plan see the merged terminal state and the
remaining U1/U2-U6 exits; no requirement or scope change.
Refs: Dev task feature/dhf-plan-progress-note
Why: Delegated RDM renames currently lose the real operator before the Backend project write, leaving an account-disable race in the Backend database.
Evidence: Read-only source review identified both HTTP lifecycle and command rename paths; the proposed contract and validation plan are pending human stage 4-5 review.
Impact: Adds a narrow request-bound projection capability proposal and two-account final transaction plan. No product code, production state, or approval status changes.
Refs: Approved U3 r1 and A1-A4 amendment; Dev feature/iam-u3-account-directory-recovery task card.
Why: The approved plan remained an earlier review snapshot and contradicted the index and task card after U1 implementation began.
Evidence: The pre-decision r0.1 file hash is f99e1424; the additive dated note preserves that text and records owner stage 6/7 decisions, four package reviews and remaining gates.
Impact: Documentation status only; no asset or product behavior change.
Refs: docs/proposals/2026-10-14-dhf-template-generation-plan.md
Why: independent review found in-flight write, API-key admission, lock-order, and cross-instance cursor gaps in the U3 candidate.
Evidence: SELF source review of Backend 4053c4d against approved U3 r1; proposal records triggers, scope, and replay plan.
Impact: request stage-four and stage-five re-review before further affected implementation; no production action.
Refs: IAM U3 r1; Dev policy/delivery.md
Why: prepare the U3 review amendment against the current documentation baseline.
Evidence: origin/main=2d35cd49c203820d24d7c38acead06d37793c1f1.
Impact: integrate upstream documentation without changing the approved U3 r1 text.
Refs: IAM U3 r1
weichen
weichen