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: 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: 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: 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
Why: The approved U6 plan requires a reviewable account of three real serial deliveries, CI costs, recovery paths, and manual adoption limits.
Evidence: Dev #489/#488/#486 fixed-head Actions runs 3038/3050/3067 and main runs 3040/3053/3068; component PRs and Issue #518 preserve raw SELF and independent REPLAY.
Impact: Document observed behavior and untested automatic coordination boundaries without changing product code or declaring rollout authority.
Refs: Dev issue #518; merge queue implementation plan U6
Why: Keep the planning index aligned with the approved scope and actual U1 results.
Evidence: The RDM branch saved the 44-asset catalog and E1 receipts; exact candidate fidelity remains under human review.
Impact: Documentation status only; no template is published and no runtime behavior changes here.
Refs: DHF plan r0.1; RDM feature/dhf-template-assets@6af4497
Why: Keep the owner-reviewed scope and asset evidence available for implementation.
Evidence: Plan review and SELF document/source receipts are recorded in the Dev task card.
Impact: Documentation and asset inventory only; no product behavior changes.
Refs: DHF plan r0.1; owner approval to begin implementation
Why: refine the approved IAM scope into enforceable account, directory and recovery boundaries.
Evidence: SELF document checks and independent document reviews; business tests and CI are NOT_RUN.
Impact: proposed contract and implementation plan only; preserve the approved global plan and all runtime data.
Refs: Dev feature/iam-u3-account-directory-recovery; IAM r1 U3 and IAM-D/IAM-C
Why: old r2 and r3 draft-stage paragraphs contradicted the retained approval records and current user takeover authorization.
Evidence: independent Documents review identified the ambiguity; targeted diff and link checks are captured outside the candidate.
Impact: label historical planning limits without changing genuine NOT_RUN results, deployment boundaries, or the newer login recovery implementation record.
Refs: Documents PR #89; Dev PR #489; independent review /tmp/mq-trial489-docs-independent-review-20261014.json
Why: retain the approved recovery and account additions while preserving the newer login recovery record and all current documentation.
Evidence: diff checks and affected links are captured by the evidence tool; historical CI remains scoped to its original object and is not current admission.
Impact: merge the current document target into the existing status task, preserve r3 records, and apply the user mandate that agents execute merges.
Refs: Documents PR #89; Dev PR #489; merge queue Issue #518; user continuation authorization on 2026-10-14
Why: Preserve delegated project settings while keeping physical Host mutations owner-scoped.
Evidence: User explicitly approved the independently reviewed amendment and repair plan; original amendment digest recorded in the contract.
Impact: Clarify actual-actor authorization and audit, single-target owner projection, durable recovery and masked metadata; no provider implementation or deployment claim.
Refs: IAM I1 host projection amendment r1; Documents PR 98; Dev policy/delivery.md affected stages 4-5.
Why: Avoid presenting an earlier extension surface as the current provider after main advances.
Evidence: Independent documentation review identified a non-blocking version attribution issue.
Impact: Attribute the existing-capability table to Backend 0f192a48; preserve contract semantics and approved plan digest.
Refs: IAM I1 stage 8 document review.
Why: Remove stale local-review and pending-acceptance statements after user confirmation.
Evidence: Independent stage 8 documentation review identified the status mismatch.
Impact: Update delivery status only; preserve permission semantics and the approved plan digest.
Refs: 2026-10-13 IAM I1 acceptance record; Dev policy/delivery.md.
Why: Preserve the explicit stage 7 decision before formal review and integration.
Evidence: User confirmation in this session; document consistency receipt 17a3542f8e69fc899a05a152d258b721a8aaab4cd0a3629f8f5cbb7364d77d84 (SELF).
Impact: Record acceptance of the fixed I1 candidate and its stated limitations; leave the approved plan unchanged.
Refs: Dev policy/delivery.md stages 7-9; IAM I1 permission contract.
Why: Stage 6 is approved and formal command/API results need a version-bound human acceptance decision.
Evidence: Complete SELF receipts and independent replays are linked to fixed Dev/RDM subjects; the original implementation approval is retained.
Impact: Record test coverage, predicate corrections, immutable product digests and explicitly untested later scopes. Do not mark user acceptance or shipping complete.
Refs: IAM I1 U1-U2; phase 7 acceptance
Why: The user approved the previously delivered local implementation and compatibility effects.
Evidence: This chat reply says approval; its objects remain c023551 Documents, b93908e RDM and 72ed8b4 Dev. Execution receipts are separate from this human decision.
Impact: Stage 6 passes and planned stage 7 begins; acceptance, shipping, later increments and production operations are not approved by substitution.
Refs: I1 implementation review on 2026-10-13
Why: Legacy upload events and synced duty flows need the same private-data and current-state guarantees as new member work.
Evidence: Real legacy SSE leakage and independent duty replay findings; correction evidence remains in the canonical task record.
Impact: Describe trusted per-event sharing and durable duty versions without new mandatory downstream interfaces or runtime changes.
Refs: system-project-membership r1.1; Dev feature/project-member-access
Why: Separate observed local implementation and test results from formal acceptance, CI and deployment.
Evidence: Complete SELF outputs and fixed subjects are in the owning Dev and RDM task cards; independent preliminary review passed on dfb9c407.
Impact: Update review progress and explicit follow-up boundaries only; preserve approved plan and permission contract.
Refs: IAM I1 U1-U2
Why: The approved plan needs traceable local progress and explicit capability limitations before human implementation review.
Evidence: The owning task cards retain full local SELF startup, sync, red and green outputs; final combination checks and independent review are pending in this checkpoint.
Impact: Preserve the original approved plan and identify I1 behavior, deferred capabilities and the next separately authorized unit.
Refs: IAM plan r1; I1 U1-U2
Why: Existing public host contracts cannot prove source ownership, scoped revocation or private artifact filtering.
Evidence: The I1 documentation consistency checker preserves the approved plan digest and fixed RDM core rules; behavior verification is recorded in the owning task.
Impact: Record conservative I1 defaults and explicit follow-up provider requirements without adding public implementations.
Refs: IAM plan r1, I1 U1-U2
Why: Joined members must see one globally named project and keep private conversations and source documents.\n\nEvidence: Proposal links the fixed implementation plan, explicit authorization and task evidence without claiming deployment or CI success.\n\nImpact: Define optional lifecycle extension, identity recovery, private reads and published knowledge for U2/U3/U5.\n\nRefs: Dev feature/project-member-access
Why: separate protected system actions from project authority and freeze the approved identity and resource boundaries.
Evidence: SELF document check recorded by Dev evidence; approved plan digest retained and fixed-base core rules preserved.
Impact: contract and navigation only; provider implementations, multi-role migration and deployment remain later increments.
Refs: IAM plan r1 U1; Agent-System-Dev feature/iam-i1-permission-boundaries
Why: provide the approved contract for the I1 implementation without altering its accepted content.
Evidence: SELF source artifact SHA-256 39b8e9a6e078dc509bd80118c1807ce6ed23e4466e5902b51f4bfa255d55c0a1; user approved the plan and authorized U1-U2.
Impact: documentation checkpoint only; no production code or runtime changes.
Refs: Agent-System-Dev feature/iam-i1-permission-boundaries
Why: the retest changed the K4 SELF result, and the plan has to record that without opening write traffic.
Evidence: SELF drill backup-20261013-013354, K1-K7 true. Documents has no CI workflow.
Impact: proposal r2.3. Second-instance writes stay closed.
Refs: #92
Why: the 2026-10-12 drill left artifact recovery failed, and the retest changed that SELF result without changing the write-traffic gate.
Evidence: backup-20261013-013354 on Dev a83588dd and backend 46073d30; K1-K7 true, RPO 65s, RTO 3s, five artifacts matched and cross-user access returned 404. SELF.
Impact: proposal moves to r2.3. Second-instance writes stay closed until REPLAY or CI and the second host exist.
Refs: docs/records/2026-10-12-u7-ops-drill-report.md docs/proposals/2026-10-11-collaboration-storage-and-distribution.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: Keep planning progress aligned with actual implemented corrections without duplicating CI and merge state.
Evidence: Reference UI155, Frontend210 and 19 local browser cases via Dev native receipts; final GATE remains separately tracked.
Impact: Planning metadata only; no deployment or model-routing claim.
Refs: work-companion-ui r0.2/r1, UI01-UI13
Why: Keep the approved design and implementation plan consistent with the current candidate.
Evidence: Reference actual SELF verification and pending independent Review and GATE, without copying command output.
Impact: Planning progress only; inherited live-model capabilities and deployment remain separate.
Refs: UI01-UI13, work-companion-ui U5
Why: preserve concurrent planning records before the Dev combination sync.
Evidence: fetched authoritative Documents main f76cce9e32.
Impact: planning record integration without rewriting history.
Refs: work-companion-ui U5.
Why: B6, C4, and C5 now have same-host results, and the plan still said the ops drills were not done and that replay was the next step.
Evidence: Dev results pgbench-20261012-131948, fault-20261012-142734, and backup-20261012-153441 (SELF). The user declined a capacity replay on 2026-10-12.
Impact: Second-instance writes stay closed. K4 remains a product defect. Replay and C3 are not started.
Refs: feature/u7-ops-drills
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: the recovery plan needs the D1-D3 remediation record before the Dev pin moves.
Evidence: repository has no .gitea workflow; combined status has zero checks. Diff is one recovery-plan section.
Impact: documents only.
Refs: #88
Why: implement a simple workbench for nontechnical users under continuous authorization.
Evidence: current source audit and the reviewed r0.1 prototype; runtime verification remains pending.
Impact: design and plan only; task execution state stays in the Dev task card.
Refs: UI01-UI13 and the existing fast-slow display design r1.1.
Why: keep r2/r3 proposal updates rebase-friendly before PR.
Evidence: origin/main at fetch time.
Impact: Documents feature tip includes latest main.
Refs: feature/svc-account-durability-plan
Why: Capacity ladder/60m/2h dual-instance windows finished; planning
progress must reflect SELF-pass vs remaining GATE/REPLAY/C3 gaps.
Evidence: SELF load results summarized in the new capacity report.
Impact: Preferred next becomes independent REPLAY or C3/C4/C5.
Refs: Dev feature/u7-capacity-wrap-measure; release-multi-instance.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: Dev #451 cannot pin modules/documents while feature tip and main diverge.
Evidence: merge-tree reports submodule conflict 1048e7c vs 9e4ee27.
Impact: Documents #84 tip includes main@1048e7c plus r1.1/U1 plan.
Refs: Dev PR #451; Documents PR #84
Why: distinguish timed observations from current service ownership.
Evidence: SELF task-sync and read-only observations at 18:14 Beijing time.
Impact: planning metadata only; runtime and component deployment unchanged by this task.
Refs: account r2; recovery r3
Why: account help, dev credential writes and crash recovery need a current, reviewable contract.
Evidence: SELF source and sanitized runtime observations; seven document review lenses; business and fault validation NOT_RUN.
Impact: revise two planning documents only; preserve prior approvals and mark additions pending review.
Refs: Dev feature/svc-account-durability-plan; account r2; recovery r3
Why: User authorized stage-5 start; record plan status for executors.
Evidence: Chat authorization "开始"; no runtime tests.
Impact: Documents proposal status only.
Refs: 2026-10-12-fast-slow-channel-display-u1-plan.md
Why: Record approved stage-4 design with R03 splits and U1 exit
whitelist, plus stage-5 U1 implementation plan for review.
Evidence: Document edits only; no runtime verification.
Impact: Documents proposals INDEX; no business code.
Refs: feature/fast-slow-display-design
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: Delivery requires writing planning progress back after U7
landed; the proposal still claimed U1+U2 start / NOT_RUN.
Evidence: SELF doc edit against archived U7 cards and release
checklist A1-A7/B1 facts.
Impact: Readers see code-done vs capacity-window-pending; adds
HTTP multi-instance vs Manager-test lesson.
Refs: Dev feature/u7-capacity-wrap-measure; release-multi-instance.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: Capture nil-card panic and intent data-flatten field fixes found
during local prod acceptance without revising the final closure verdict.
Evidence: Backend#173 #174; prod action checklist
Impact: Field-fix log lists the two hotfixes and their PRs.
Refs: GenUI prod deploy; fix track
Why: Record that the known-boundary production deploy/acceptance ran
on the local prod svc instance with auth and PG.
Evidence: scripts/svc.sh prod list; acceptance API checklist
Impact: Usage guide boundary list no longer says deploy is pending.
Refs: GenUI prod deploy task
Why: user approved the proposal and U1/U4 specs and authorized push/PRs
plus U1/U4 implementation start.
Evidence: SELF conversation approval 2026-10-12; implementation still NOT_RUN.
Impact: planning status only.
Refs: docs/proposals/2026-10-12-svc-unified-deploy-and-login-key.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: capture the reviewed design for binary/source install, env prep,
and passwordless activation via one-time restricted sessions.
Evidence: SELF source review against Dev af9c2de; implementation NOT_RUN.
Impact: Documents planning index only; no runtime change.
Refs: docs/proposals/2026-10-12-svc-unified-deploy-and-login-key.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: Record the independent U5-style review for the first two B-class
surface actions and update the usage guide allowlist note.
Evidence: proposal r1 status approved; usage doc API table updated.
Impact: Documents authority for backend whitelist implementation.
Refs: U5 action-scope r2; plan GenUI boundaries 2026-10-12
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: The direction closes at U7 - the master record needs its
companion usage guide (enable/generate/revise/act/disable for owners)
and the combined evaluation record covering every landed increment
with its evidence chain and known boundaries.
Evidence: Live E2E on dev@b634a27 (real MiniMax-M3): progress page
presented autonomously, conversation surfaces=2, project aggregation
returns cross-conversation pages under the owner scope; receipts in
Dev task feature/generative-ui-u7-acceptance.
Impact: Documents-only (new guide + index closeout).
Refs: r2 master record; U5 scope r2; Dev task
feature/generative-ui-u7-acceptance
Why: between the review round and the approval decision another session completed and merged svc-autorecover (PR #396/#400/#401/#402), so the (a)-decision tracking must reflect the landed slice and the remaining U2 delta.
Evidence: SELF - merged main history c622372 and archived card .task/archive/feature-svc-autorecover.md (10/10 tests, 146/146 governance, CI green on e0b49d1).
Impact: review record, INDEX; proposal r2 body unchanged.
Refs: PR #396#401
Why: the human gate resolved on 2026-10-12 - r2 approved (five stages at once) and option (a) adopted; the review record, proposal index and status navigation must reflect it.
Evidence: SELF - user decision relayed in conversation; stage-review details in the Dev task card; proposal r2 body unchanged (SHA256 9cfda252...).
Impact: review record, INDEX entry; no plan content change.
Refs: Dev task card .task/feature-service-restart-recovery-plan.md
weichen
