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
Why: U3 slice 2 ships admission budgets (runtime.* keys, lease semantics, yield/reacquire) and the host-side action matrix; the runbook is the single source for operators and records the versioned public-contract plan KTD13 requires.
Evidence: backend branch feature/collab-storage-u3-budget-authz (admission.go, action matrix in server.go) with admission/matrix tests green.
Impact: docs only.
Refs: proposals/2026-10-11-collaboration-storage-and-distribution.md KTD13/R8, section 5 U3.
Why: branch protection requires the head to contain the current base before merge.
Evidence: fetched origin/main=336a90f0ade0ffe049879ca5159a61f0a3948708.
Impact: integrate upstream changes without rewriting task history.
Refs: Documents PR #63
Why: The U1 controlled trial (three arms on synthetic materials,
MiniMax M3 + M2.7-highspeed, CNY 3 spent of the 200 cap) finished on
2026-10-11; its evidence changes the plan and must live in the master
record: goal-driven structure divergence holds (6/6), generation must
go through tool arguments (text-channel JSON discipline is the floor),
highspeed is rejected as the generator, and the first release keeps the
in-house renderer.
Evidence: Full data and failure taxonomy in Dev task
feature/generative-ui-u1 (.task/genui-u1/report.md, SELF; CI gate on
the Dev PR). Tool-channel and response_format probes recorded there.
Impact: Proposal r1 -> r2 (new results section, catalog/model/channel
revisions); INDEX entry updated. No code or contract changes.
Refs: Dev task feature/generative-ui-u1; Documents PR #60 (r1)
Why: the user reviewed and approved the plan (2026-10-11, five stages bundled) and chose a two-tier admin model for KTD4 instead of strict ledger separation.
Evidence: SELF user session rulings recorded in the Dev task card; document-check receipt follows in the task card evidence section.
Impact: proposal r1 and INDEX now record approval and the two-tier admin ruling; no code or deployment change.
Refs: Dev feature/rdm-two-trees-audit-plan
Why: assess existing two-tree and trace-network capabilities and define project-scoped inspection.
Evidence: SELF source receipt and document checks; business and runtime verification were not run.
Impact: pending-review proposal and index only; no product implementation or deployment.
Refs: Dev feature/rdm-two-trees-audit-plan
Why: the approved collaboration plan U1 requires a fixed deployment manifest, tier config contract, migration mapping, capacity contract, isolation test scheme and KTD14 copy-protection contract as the single source of truth for team-tier operations.
Evidence: contract keys match backend config.go tier/pool fields (U2, backend branch feature/collab-storage-pg-tier); local verification used svc.sh collabtest on 127.0.0.1:8897 and Redis on 6399.
Impact: docs only (new guide + usage.md cross-links); no code change.
Refs: proposals/2026-10-11-collaboration-storage-and-distribution.md sections 5 (U1/U2), KTD1/KTD8/KTD12/KTD14.
Why: The user ruled on 2026-10-11 the three open product choices (first
pilot = full analysis page inside the conversation; enable/disable via a
trusted compiled plugin; U1 trial on MiniMax M3 + M2.7-highspeed with
sanitized materials and a CNY 200 cap), so the proposal now publishes as
the direction's master record instead of a local draft.
Evidence: Doc self-check receipts live in the Dev task card
feature/generative-ui-research; the rulings are recorded in the doc's
"用户裁定记录" section and mirrored in INDEX.md.
Impact: Documents-only change (new proposal + index entry). No runtime,
contract, or code changes; U1 trial start and deployment stay separately
reviewed.
Refs: Dev task feature/generative-ui-research
Why: freeze the direction for 10-100 user multi-project collaboration storage (PostgreSQL team tier, migration, staged multi-instance) before U1+U2 implementation starts.
Evidence: static review record and SELF audit receipt included; user approval recorded in Dev task card 2026-10-11 (instruction to start the transformation per the plan).
Impact: docs only - new proposal, index entry, review record, audit receipt; no code or runtime change.
Refs: Dev .task/feature-collaboration-storage-plan.md; plan section 5 names U1+U2 as the first increment.
Why: The E1 quick-fix increment landed (delegate full text, MiniMax
reasoning split, sandbox deps layer, parallel tool execution with kernel
ordering) and the proposal is the master record, so its stage table and
the index row must reflect the actual progress with links.
Evidence: Agent-Native #42/#43/#44, Backend #127, Dev task
feature/agent-e1-parallel-fixes (live verification receipts: F2 zero
think-leak, F3 sandbox IMPORTS-OK, F5 concurrent overlap; eval
toolFailures 19->11, unverifiedFacts 7->12 recorded honestly).
Impact: Documents-only progress backfill; E2-E5/S0 remain unauthorized.
Why: The user asked for a researched design covering subagent use,
tiered model routing (Claude via dmxapi for complex work, MiniMax for
the rest), a millisecond/sub-second task sandbox (record-only), and a
verdict on why the agent still feels weaker than codex/claude-code/kimi.
Why: Four research threads (external frontier survey, subagent/routing
evidence, harness-vs-model attribution, local code audit and probes)
converge on role/stage routing instead of whole-task routing, and on
three corrections to the sandbox assumptions (overlay is not a snapshot;
snapshots defer conflicts to merge time; destroy must follow sealing).
Evidence: Local measurements are SELF receipts in the Dev task card
(bwrap namespace ~7ms, overlay same, docker ~142ms; MiniMax reasoning
split; dmxapi /v1/messages cache_read; EXT-16 sandbox missing the
python-docx layer). External claims carry per-item source URLs in the
proposal's section 8.
Impact: Documents-only addition: new proposal 2026-10-10 (E1-E5/S0
increments, D/R workstreams, sandbox tiers L0-L2) plus INDEX rows for it
and the previously unlisted G1 package. No product code changes; all
implementation increments stay unauthorized until approved.
Refs: proposals/2026-10-09-agent-quality-improvement-plan.md (P4/P5,
model A/B), 2026-10-09-ext-g1-b1-b3-exec-backend.md (EXT-16),
Dev task feature/agent-exec-routing-sandbox-plan.
weichen
weichen