Why: An isolated PostgreSQL test demonstrates that explicit low IDs bypass the current committed-prefix guard and disappear across pages.
Evidence: The test-only RED and reviewed database/migration tradeoffs are bound to the documented candidate and exact SHA256.
Impact: Adds a human-review design for all online audit writes and exclusive offline copy; no runtime change or migration.
Refs: feature/rdm-two-trees-latest-templates W9
Why: A validated sensitive-text persistence defect requires a reviewed X1 source reauthorization contract.
Evidence: User approved the immutable r1 design at its recorded SHA256; the Backend RED remains preserved.
Impact: Allows isolated W6 implementation while retaining separate migration, tag and acceptance gates.
Refs: feature/rdm-two-trees-latest-templates W6
Why: Persisting goal-sensitive model prompts in long-lived context receipts violates the approved content-minimization boundary.
Evidence: A fixed Backend HEAD RED reproduces stored workflow output; source and migration constraints were reviewed against current code.
Impact: Adds a reviewable X1 interface and data correction proposal; implementation stays paused until human approval.
Refs: feature/rdm-two-trees-latest-templates W6
Why: W2 transaction consistency and PostgreSQL audit pagination need their reviewed dependency and data-order boundaries preserved.
Evidence: User approved the two immutable r1 objects at their recorded SHA256 values; local link and whitespace checks passed.
Impact: Main record now authorizes isolated W4a and W9 work while retaining separate live migration gates.
Refs: feature/rdm-two-trees-latest-templates stage 6
Why: PostgreSQL sequence IDs can become visible out of order and undermine fixed audit pagination.
Evidence: Isolated PostgreSQL late-commit reproduction and sequence cache behavior were checked against official documentation.
Impact: Adds a reviewable proposal with lock, sequence, migration, rollback, and throughput boundaries; no runtime code changes.
Refs: feature/rdm-two-trees-latest-templates W9
Why: Preserve the reviewed 44-template scope, design, implementation plan, and exact stage decisions in the shared project record.
Evidence: Approved stage hashes and local links verified; W0 inventory has 44 records and current implementation limits are explicit.
Impact: Adds traceable planning, source receipts, audit-link approval, and a pending W2/W4 sequence adjustment without changing published assets.
Refs: feature/rdm-two-trees-latest-templates
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
Why: the reviewer record must reflect that all r2 gap claims hold at the post-sync backend pin 25fbea85, and that the svc-autorecover ownership decision now has 373 lines of unregistered, partially failing in-flight work to weigh.
Evidence: SELF - drift-check receipt in the Dev task card (exit 0, all cited gaps hold); svc-autorecover suite observed 5 of 10 tests failing on 2026-10-11.
Impact: review record addendum only; proposal r2 (SHA256 9cfda252...) unchanged.
Refs: Dev task card .task/feature-service-restart-recovery-plan.md
Why: absorb the external source-review round - pin the shutdown budget change, close the U1 acceptance gap for program/cwd changes, gate U4 public states on a mapping table, and make the svc-autorecover coordination an explicit human decision.
Evidence: SELF - external review round 2 in the review record; r2 SHA256 9cfda2520b913e6966c68fb3f66fb7bc8382a8f7a2b69cb364122216dcdb72cd; all reviewed claims re-verified against the pinned baselines.
Impact: documents only; four targeted amendments (U1/U3/U4/section 9) plus version bump and INDEX update; requirements and metrics unchanged.
Refs: Dev task card .task/feature-service-restart-recovery-plan.md
Why: U5 landed via RDM PR #213 (merge 1dce69d); all five implementation units now complete.
Evidence: RDM PR #213 merged=True.
Impact: plan status + U5 progress + INDEX.
Refs: RDM PR #213
Why: U4 landed via Dev PR #368 (merge 7aa8fd9).
Evidence: Dev PR #368 merged; CI green.
Impact: status line + U4 progress + INDEX only.
Refs: Dev PR #368
Why: The U6 precondition (benefit evidence from U4/U5) resolves to the
owner actually using the landed U1-U5 capability - the human usability
comparison marked NOT_RUN since U1 finds its execution path here; the
user ruled 2026-10-11 to evaluate first and decide U6 after.
Evidence: Ruling collected via the session question panel on
2026-10-11; U1-U5 all merged (Dev #329/#336/#345/#351/#367).
Impact: Documents-only (master record U6 gate note + index status).
Refs: r2 U6 clause; Dev task feature/generative-ui-u6-gate-record
EOF
)
Why: The user ruled on the three questions (categories and ranges
approved as proposed; C-class limited to plugin KV plus task ledger;
confirm UX reuses the inline card); the proposal becomes the approved
scope and unblocks the U5 implementation task.
Evidence: Ruling collected via the session question panel on
2026-10-11; implementation task feature/generative-ui-u5 starts under
policy/delivery.md.
Impact: Documents-only (proposal r2 + index status).
Refs: r2 master record U5; Dev task feature/generative-ui-u5
EOF
)
Why: The r2 U5 clause requires a human review of the action scope
before implementation; this draft grounds the decision in the current
command inventory and existing safety machinery.
Evidence: Source facts cited inline (builtin command list with risk
levels, DangerHigh inline-confirm flow with pendingStore, audit
envelope) verified against backend main on 2026-10-11.
Impact: Documents-only (new proposal + index entry); no code changes.
Refs: 2026-10-10-generative-ui-plugin.md (r2 U5); Dev task
feature/generative-ui-u5-scope
Why: U3 landed via RDM PR #201 (merge dbc41b6); the master record must reflect actual progress.
Evidence: SELF U3 closeout doc check exit 0 (receipt in Dev closeout task card).
Impact: proposal status line, U3 progress paragraph, INDEX row only.
Refs: RDM PR #201; Dev feature/rdm-u3-closeout
Why: Dev PR #340 pinned this Documents branch tip while it was never merged into Documents main (cross-repo pin discipline); this reconciliation unifies both planning lineages.
Evidence: merge-base 2a5f658; INDEX conflict resolved as union (U1+U2 progress row + two new plan entries).
Impact: docs only.
Refs: Dev #340
Why: U2 landed via RDM PR #197 (merge fe8a75b); delivery policy requires the master record to reflect actual progress at task completion.
Evidence: SELF U2 closeout doc check exit 0 (receipt in the Dev closeout task card); RDM PR #197 merged=True via API.
Impact: proposal status line, U2 progress paragraph, and INDEX row only.
Refs: RDM PR #197; Dev feature/rdm-u2-closeout
Why: retain the newly merged RDM U1 progress alongside the final-target plan.
Evidence: resolved the single index conflict by keeping the updated U1 entry and both new plan links; diff check passed.
Impact: documentation merge only; business validation NOT_RUN.
Refs: docs/proposals/INDEX.md
Why: reconcile the confirmed project, privacy and duty rules with all approved product requirements.
Evidence: current RDM d8d7e743 source review, recorded source receipt, and exact 34 UR/68 SR/10 F matrix checks; business validation NOT_RUN.
Impact: reviewed planning documents only, covering all 69 template types and the existing XLSX asset; no runtime changes.
Refs: docs/proposals/2026-10-11-rdm-final-target-completion.md
Why: U1 landed via RDM PR #195 (merge 05b7d1a); delivery policy requires the master record to reflect actual progress at task completion.
Evidence: SELF closeout doc check exit 0 (receipt in the Dev closeout task card); RDM PR #195 merged=True via API.
Impact: proposal status line, U1 progress paragraph, and INDEX row only; no scope or requirement change.
Refs: RDM PR #195; Dev feature/rdm-u1-closeout
Why: preserve the user decision from the previous planning turn before expanding scope.
Evidence: r1.1 records the explicit user response; prior documentation-check receipt is in the Dev task card.
Impact: planning metadata only; no business changes.
Refs: docs/proposals/2026-10-11-rdm-template-dialog-generation.md
Why: U4 ships the managed migration entry; the runbook is the operator-facing contract for inventory/backup/migrate, migration identity and resume rules, verification semantics, and the authorized-window switch sequence.
Evidence: backend branch feature/collab-storage-u4-migrator - integration tests green against real PostgreSQL (idempotent rerun, resume, foreign-data refusal, wrong-snapshot refusal, unknown-owner block).
Impact: docs only.
Refs: proposals/2026-10-11-collaboration-storage-and-distribution.md U4 and section 6.
Why: connect the existing RDM assets and two-trees model to a reviewable document workflow.
Evidence: source inventory at RDM 0081628a; document structure and local link checks recorded as SELF in the Dev task card; business validation NOT_RUN.
Impact: planning and inventory documents only; no implementation or deployment.
Refs: docs/proposals/2026-10-11-rdm-template-dialog-generation.md
weichen
