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: The final zero-paid candidate incorporates three review findings and fresh browser/PostgreSQL evidence.
Evidence: Backend RED-to-GREEN regressions; task-card SELF receipts for HTTP/browser and isolated PostgreSQL reruns.
Impact: Real-model quality remains NOT_RUN and still blocks merge.
Refs: U3 quality revision r0.2
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: The merged candidate now has complete local combination and task-owned PostgreSQL results.
Evidence: Imported SELF receipts for make test && make build and Backend runmgr/cardsvc/store on isolated PostgreSQL.
Impact: The report keeps final exact-head and model acceptance gates pending for the next candidate SHA.
Refs: U3 quality revision r0.2
Why: The resolved cross-component candidate now has actual HTTP/browser evidence and one diagnosed fixture failure.
Evidence: Task-card SELF sync and browser receipts, including manifest verification and two passing Playwright cases.
Impact: The report keeps model quality NOT_RUN for r0.2 and the older paid failure unchanged.
Refs: U3 quality revision r0.2
Why: Historical observations in the approved plan used current-tense wording after implementation advanced, making the progress pointer harder to interpret.
Evidence: Independent documentation review identified the wording; the diff changes only baseline time and references current task/PR evidence. Document replay follows on the new candidate.
Impact: No change to approved units, interfaces, authorization or acceptance criteria; actual progress remains in the task and fixed-candidate records.
Refs: Documentation review Minor finding; approved plan ba4044d; U1-U6
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: The design and implementation plan were approved while the previous report still described them as pending.
Evidence: git diff --check; Backend, UI and affected Frontend tests recorded as SELF with their component SHAs.
Impact: The report distinguishes the new mechanism candidate from the failed paid v7 sample and keeps model QA NOT_RUN.
Refs: U3 quality revision r0.2
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: The existing browser fixture parses the trailing source index that the approved source-once layout removes.
Evidence: A zero-paid parser probe matched the old format and rejected the planned inline format; the plan now owns a failing fixture test and adaptation.
Impact: Preserve real HTTP browser coverage without changing product contracts or model acceptance.
Refs: Agent-System-Documents#95; Agent-System-Dev#512
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: A provider may report prompt and completion tokens while leaving totalTokens zero; the reserve must not treat that usage as free.
Evidence: Existing budgetedStream falls back to prompt plus completion, while subRun usage accounting currently does not; the plan adds a focused regression.
Impact: Clarify the reviewed implementation scope without changing product code or authorizing a model sample.
Refs: Agent-System-Documents#95; Agent-System-Dev#512
Why: Hiding a tool declaration alone does not prevent a model from calling a tool already in the runtime registry.
Evidence: The agent-native loop continues after tool errors; the plan now requires a local stop latch before any later provider call.
Impact: Clarify the zero-paid test and implementation boundary without changing the approved design or authorizing model usage.
Refs: Agent-System-Documents#95; Agent-System-Dev#512
Why: The approved written design needs testable work items before changing model behavior or spending another sample.
Evidence: The plan maps all three design duties to existing code seams, RED-to-GREEN checks, a fixed combination gate and a separately authorized real-model exit.
Impact: Record stage-five review material without modifying product code, using paid models, or opening merge gates.
Refs: Agent-System-Documents#95; Agent-System-Dev#512
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: Validation of the complete candidate against origin/main detected added blank lines at the end of the authored documents.
Evidence: git diff --check origin/main validates the final candidate format; unchanged semantic content remains covered by the approved specification and implementation plan.
Impact: Document whitespace only; no version obligations, execution mode or authorization change.
Refs: Merge queue implementation plan U4; formal document validation
Why: The approved model samples showed unsupported approval claims, repeated source input and no final answer before the run budget stopped.
Evidence: The design cites the preserved A01 provider usage, persisted findings and independent sample audit without claiming new model validation.
Impact: Define a reviewable source, claim and final-reserve revision while keeping code, paid trials and merge gated.
Refs: Agent-System-Documents#95; Agent-System-Dev#512
Why: preserve the approved plan and point readers to the actual task objects instead of treating historical planning state as current delivery status.
Evidence: user approval of plan r1 and Dev task-card receipts; actual platform activation and real trial remain NOT_RUN.
Impact: plan metadata, test-file organization and navigation only; task state remains authoritative in Dev.
Refs: docs/proposals/2026-10-13-merge-queue-implementation-plan.md; Dev .task/feature-merge-queue-policy-draft.md
Why: The controlled trial made one more paid provider request after rejecting a nonliteral quote.
Evidence: Independent transcript audit found a 14231-token continuation within the same child run; original receipts and failed quality verdict remain intact.
Impact: Make the authorization deviation explicit and reference a zero-paid prevention guard; no additional model run is authorized.
Refs: Agent-System-Documents#95; Agent-System-Backend#193; Agent-System-Dev#512
Why: The approved v7 sample saved two checkpoints but still missed semantic and final-result acceptance.
Evidence: Independent DB replay, provider usage reconciliation, source checks and the original failed evaluation receipt.
Impact: Preserve the exhausted one-shot boundary and keep all draft PRs unmerged.
Refs: Agent-System-Documents#95; Agent-System-Dev#512
Why: The approved extra sample ended with no valid saved findings and exhausted its per-run token threshold.
Evidence: Provider responses, strict-source rejections, Usage and independent analysis are retained; v7 has only local checks.
Impact: Define a separately approvable two-run 30000-token-per-run experiment without altering original acceptance rules or claiming model success.
Refs: Approved U2/U3 plan r0.1; independent extra A01 assessment
Why: turn the confirmed scheduling specification into sequenced work with explicit interfaces, evidence handling and admission validation.
Evidence: SELF plan checks verified fixed source commits, 83 relative links, six units and four Python example blocks; implementation and runtime checks remain NOT_RUN.
Impact: reviewable implementation plan and navigation only; no task scripts, workflow, platform settings or business behavior are implemented.
Refs: docs/proposals/2026-10-13-merge-queue-implementation-plan.md; Dev policy/merge-queue.md r1; Development-Guidelines draft.11
Why: The project and proposal indexes still said no U2/U3 implementation or experiment existed.
Evidence: Current combination, full PG backend, two HTTP browser cases and independent code review are linked with their actual statuses.
Impact: Documentation only; real-model acceptance is explicitly failed and no release is claimed.
Refs: Approved U2/U3 task card and validation report
Why: Keep the latest merged candidate reviewable without turning failed model findings into a release claim.
Evidence: Exact d06792c composition, two current browser cases and independent model review are linked and source-labeled.
Impact: Documentation only; model quality gate and merge remain closed.
Refs: Approved U2/U3 task card
Why: The model produced no admissible findings, so release and further paid work remain gated.
Evidence: Original provider calls, 42203 tokens, independent SQLite replay and strict source rejection are linked from the validation report.
Impact: Correct planning status and recommend a bounded lower-complexity test design for separate approval.
Refs: Approved U2/U3 plan r0.1; extra A01 user approval 2026-10-13
Why: Preserve other approved planning records and index updates.
Evidence: Exact current main fetched; no overlapping source behavior.
Impact: Retain both planning histories.
Refs: Agent-System-Dev U2/U3 delivery
Why: Make the current corrected candidate reviewable while preserving the failed model acceptance boundary.
Evidence: Native SELF receipt for exact source composition 7fd5288 is green; independent reviewer verifies Backend 6a2d85c and all fixed regressions.
Impact: Documentation only; the six failed or limited model samples remain unchanged and no merge or deployment is claimed.
Refs: Approved U2/U3 plan; pending explicit extra A01 test authorization
Why: Planning-only status no longer matches the candidate, while failed model samples must remain explicit.
Evidence: Native SELF receipts and independent REPLAY reports distinguish code checks, six model cases and the failed quality/fidelity boundaries; relative links verified.
Impact: Update only this approved U2/U3 planning record and validation report; CI, merge, deployment and an extra sample remain pending.
Refs: User confirmation 2026-10-13; Dev feature-fast-slow-u2-u3-plan
Why: The 2026-10-13 login recovery flow was approved and merged
(Backend #187, Frontend #76, Dev #504); the master proposal must carry
the three adjudications, implementation record, and evidence pointers
per the repo's lineage conventions.
Evidence: Dev #504 HEAD CI (test/test-pg/svc-realcombo) success; browser
acceptance receipts be7ae9a2/b3a9e691 bound to Dev HEAD 268ef29 (SELF).
Impact: r3 is an implementation record only; R/KTD/U numbering semantics
unchanged; U7 explicitly NOT marked complete (atomic bootstrap and CLI
credential delivery remain). INDEX.md status line updated.
Refs: Dev docs/svc-deploy/2026-10-13-login-recovery-contract.md
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: make persistent activity and grounded findings reviewable before business changes.
Evidence: fixed source audit and scoped plan self-review; business and live checks remain NOT_RUN.
Impact: proposed contracts, implementation sequence, compatibility and bounded verification only.
Refs: fast-slow design r1.1, Dev feature/fast-slow-u2-u3-plan
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 2026-10-12 approval covers the recovery U8 and account U7 additions, and the RDM U5 note still treated the lifecycle pull request as the whole export.
Evidence: Backend 183 and 185 plus Dev 486 were already green; Dev 482, RDM 301, Frontend 73, and Dev 488 remain open and are not marked merged.
Impact: proposal status only. No implementation or deployment claim changes.
Refs: docs/proposals/2026-10-12-service-restart-data-recovery.md, docs/proposals/2026-10-12-svc-unified-deploy-and-login-key.md, docs/proposals/2026-10-11-rdm-two-trees-trace-audit-integration.md
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: the 2026-10-12 batch-update failure still had identity, rollback, and real-combo gaps after Dev #474, Backend #180, and RDM #276. The recovery plan is the single record for that work, and the rdmcand data-ownership check needed a written result before any restore.
Evidence: read-only queries on runtime-backups/{dev,rdm1,rdmcand}/20261012T133921Z and the matching domain backups. No business rows were moved.
Impact: adds r3.1 sections D1/D2/D3 and the ownership finding that dev conversations predate rdmcand's use of dev/data, so no cross-instance restore is indicated. r3's earlier unapproved text stays unapproved.
Refs: Dev feature/svc-d1-identity-flow; Backend feature/d1-identity-open
Co-authored-by: Cursor <cursoragent@cursor.com>
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
weichen
weichen