Why: the task card, proposal index, and frontend gitlink need to name the document-duty rework instead of the superseded duties tab.
Evidence: SELF commits 034faa4 in documents and 1b7ba77 in frontend. RDM f16287f is a sibling repository, not a Dev gitlink.
Impact: the duties settings entry now comes from the three-view frontend. Deployment and live-account acceptance remain unauthorized.
Refs: modules/documents/docs/proposals/2026-10-15-rdm-duty-matrix-rework.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=cc40e10f3b4b6e41cb3a7aa0826e08dd3b8b7270.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
Why: Keep branches developing independently and serialize only final sync, validation, and agent merge without expanding into audits or new platform mechanisms.
Evidence: scope and link checks, git diff --check, and recursive worktree verification passed as SELF evidence in the task card.
Impact: Documentation only; existing task-sync, CI, branch protection, and agent merge behavior remain unchanged.
Refs: Agent-System-Dev #518
Why: deploy needs to choose registered plugins and ship them inside one agent-system, then refuse the release when they are not active.
Evidence: python3 -m unittest tests.test_svc_plugins tests.test_svc_user_help tests.test_svc tests.test_svc_u2 (SELF, 63 passed, 1 skipped). Real compose build and make test-lifecycle are NOT_RUN.
Impact: --with is mutually exclusive with --from rdm and --from release. Existing non-interactive deploys stay without plugins unless plugins= is already recorded. Changing the plugin id set on a live service requires --allow-source-switch.
Refs: .task/feature-svc-plugin-compose.md modules/documents/docs/proposals/2026-10-14-svc-plugin-compose-deploy.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: The Dev project entry and task card still described only three accepted packages after the DI owner review.
Evidence: RDM DI catalog binds four exact hashes and RDM local tests/build passed at 9997990; Dev git diff --check receipt is in this task card.
Impact: Progress record only; Documents pin, publication state, deployment and runtime data are unchanged.
Refs: PROJECT.md; .task/feature-dhf-template-pipeline-plan.md
Why: Keep the integration entry aligned with the separate project-proposal, F01 and F02 package decisions.
Evidence: SELF RDM make test passed on 87fa010; owner four-hash decisions are recorded in the RDM task card.
Impact: Progress metadata only; 44 assets remain unpublished and 14 DOC fidelity reviews remain open.
Refs: DHF r0.1 U1, feature/dhf-template-pipeline-plan
Why: Keep the integration task aligned with the two unpublished process-validation Word packages and their owner review boundary.
Evidence: SELF RDM make task-sync and GOWORK=off make test passed on 10933dc; receipts remain in the RDM task card.
Impact: Progress metadata only; no Documents pin, dictionary, live data, or publication change.
Refs: DHF r0.1 U1, feature/dhf-template-pipeline-plan
Why: Keep the integration project entry aligned with the owner F01/F02 purpose and stage decisions.
Evidence: SELF RDM make test passed on cdb66c5; detailed source and dictionary checks are in the RDM task card.
Impact: Progress metadata only; no dictionary registration, running data migration, or template publication.
Refs: DHF r0.1 U1, feature/dhf-template-pipeline-plan
Why: Keep the integration project entry aligned with the owner-approved pilot package while preserving the unpublished state.
Evidence: SELF RDM make test passed on e21a82b; owner acceptance and four artifact digests are recorded in the RDM task card.
Impact: Progress metadata only; E1, F01/F02 purpose, U1 completion and release remain open.
Refs: DHF r0.1 U1, feature/dhf-template-pipeline-plan
Why: Keep the Dev project entry and task record aligned with the owner semantic decision and the RDM pilot package.
Evidence: SELF RDM make task-sync and GOWORK=off make test passed on df17ed1; the exact receipts are in the RDM task card.
Impact: Progress metadata only; E1 fidelity, publication, U2-U6, and deployment remain open.
Refs: DHF r0.1 U1, feature/dhf-template-pipeline-plan
Why: Keep the Dev project entry and task record aligned with the approved DHF implementation and saved U1 evidence.
Evidence: SELF make test passed on the Dev combination with Documents c256558; the complete output is in the task card.
Impact: Advances only the Documents pin and progress metadata; no template publication, migration, or deployment.
Refs: DHF r0.1 U1, feature/dhf-template-pipeline-plan
Why: Resume the approved DHF work from saved planning artifacts and a clean task tree.
Evidence: Startup failure and combination-check receipts are retained in the task card.
Impact: Planning entry, task authorization and Documents composition only.
Refs: feature/dhf-template-pipeline-plan; DHF plan r0.1
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=1e5c6b9c10ba77ed34663fd670138621a17342bd.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
Why: The approved document dependencies have been reviewed and merged. Their actual immutable merge commits must be fixed before final host validation, while operational activation remains a separate gate.
Evidence: Independent document replay and verified PR merges are recorded in the task card. The staged host combination passed make test with actual merged child pointers; final commit build/CI remains pending and will be recorded outside source.
Impact: Advance only the two reviewed merged child pins, expose the real plan path, and record partial stage-seven approval and pending activation. Preserve current main components and existing admission/owner boundaries.
Refs: Guidelines PR #5 (2f5b198); Documents PR #96 (129cc35); Dev PR #519; implementation plan U4-U6; Issue #518
Why: The resumed task requires a fresh baseline before recording the approved implementation and formal checks.
Evidence: Startup identified SYNC_REQUIRED; Documents pointer conflict was resolved by merging the referenced upstream commit while preserving all three approved I1 documents byte-for-byte.
Impact: Workspace recovery only; retain incoming project-membership records and the fixed I1 approval objects. Formal checks remain pending.
Refs: User approval of I1 implementation; policy/governance.md startup and recovery
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=20e086e48b9cec7f300feba5342db7a0661a4d4e.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
Why: Keep the accepted IAM direction and I1 review entry visible from the authoritative integration checkout.
Evidence: Full SELF document consistency receipts are recorded in the I1 task card. Final synchronized parent combination verification follows this checkpoint.
Impact: Advance Documents only and record I1 local authorization; backend, frontend and UI behavior pins remain unchanged.
Refs: Approved IAM plan r1; I1 U1-U2
Why: Host-only project creation and domain membership must form one verified identity.
Evidence: Tool-imported SELF receipts and independent Backend and Frontend replay attestations; composed acceptance and final CI remain in progress.
Impact: Advance fixed component pins and record the authorized implementation and privacy boundaries without deployment or runtime changes.
Refs: .task/feature-project-member-access.md; system-project-membership proposal r1
Why: agents need consistent entrypoints and recording defaults to avoid retrying synchronization and CI outside the final delivery window.
Evidence: SELF generated-task-card red-green regression and governance suite recorded through make evidence; pending shared record created as Issue #518.
Impact: rules, task template and capability matrix stay explicit about pending activation, default strict startup, manual coordination and unchanged CI triggers.
Refs: U4; policy/merge-queue.md; .task/feature-merge-queue-policy-draft.md
Why: preserve the user's continuation from the delivered r1 specification into a concrete implementation and verification plan.
Evidence: precheck and plan source/link/example checks are preserved as SELF receipts in the task card; code, CI and platform trials remain NOT_RUN.
Impact: approval metadata, plan association and project entry only; the delivery mode remains unchanged and the plan awaits stage 5 review.
Refs: policy/merge-queue.md; .task/feature-merge-queue-policy-draft.md; Documents docs/proposals/2026-10-13-merge-queue-implementation-plan.md
Why: prepare a reviewable delivery window and migration contract that reduces repeated synchronization while preserving final CI and approval requirements.
Evidence: SELF precheck, document checks and read-only platform observations are preserved in .task/feature-merge-queue-policy-draft.md; runtime queue and platform trials remain NOT_RUN.
Impact: proposed policy, project entry and task record only; scripts, workflow, platform protection and guideline gitlink are not changed by this draft.
Refs: policy/merge-queue.md; .task/feature-merge-queue-policy-draft.md
Why: The live deploy journal never called fault injection, and test-lifecycle failed closed on login so CI could not require the real combination cases.
Evidence: SELF python3 -m unittest tests.test_svc_u2.U2ReleaseTests -q exit 0 (35 ok, 1 skipped) on 3602a87; receipt sha256 9b5785577751e8e9e7947cf9700fb8854b1c80142f34273ae25f3097ee4c9aa8.
Impact: test-pg builds the Dev binary and runs make test-lifecycle. Login and full-track deploy without SVC_RDM_ORIGIN stay NOT_RUN. No live data move and no account CLI.
Refs: recovery plan D2/D3; Dev #485
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=2c016931044bebdc4a114c1ca1127d1b40d4ab17.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
# Conflicts:
# modules/documents
Why: isolate the approved interface work and fix its component baseline.
Evidence: imported startup precheck SELF receipt; source requirements and plan recorded in Documents.
Impact: task metadata, project links and authoritative UI/Frontend baselines; existing service state is untouched.
Refs: UI01-UI13 and work-companion-ui implementation plan r1.
Why: probing identity by running the subcommand still launched old RDM
builds, and ensure on a missing database created an empty one. A batch
update also inherited the caller's AGENT_SYSTEM_* variables.
Evidence: python3 -m unittest tests.test_svc_identity tests.test_svc_recover passed (41 tests, 1 skipped). tests.test_svc_lifecycle_isolation caller-env and restart cases passed.
Impact: capability probes use version --json only. Established instances
refuse a missing identity row until adopt --confirm. update and recover
run each service in a clean environment. serve reads a 0600 serve.env
and does not inherit the caller environment. Backend and documents pins
move to the D1 identity and recovery-plan commits.
Refs: recovery plan r3.1 D1; Backend feature/d1-identity-open; RDM feature/d1-version-json
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: preserve evidence, current contracts and the next review scope without changing the running system.
Evidence: SELF startup, sync and document validation receipts in the task card; runtime and fault acceptance NOT_RUN.
Impact: task metadata, planning index and account specifications only; component pins and business code unchanged.
Refs: feature/svc-account-durability-plan; Documents account r2 and recovery r3
Why: capture the 2026-10-12 approval so push/PR and U1/U4 starts are gated.
Evidence: SELF task-card update after user approval.
Impact: task metadata and Documents gitlink; no runtime change.
Refs: .task/feature-svc-unified-deploy-login-key.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: land the approved review conclusions as a formal proposal, U1/U4
specs, and draft task cards without starting business implementation.
Evidence: SELF precheck READY (receipt in task card); docs-only change.
Impact: planning docs and Documents gitlink; runtime behavior unchanged.
Refs: .task/feature-svc-unified-deploy-login-key.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: U2's first slice landed via main (PR #396/#401); the plan card's next-task line must point at the remaining U2 delta instead of the closed task.
Evidence: SELF - documents gitlink advanced; merged main range 555fb2162f..c622372 (96 commits) inspected.
Impact: task metadata and submodule pointer only.
Refs: .task/archive/feature-svc-autorecover.md
Why: stage-review table, phase line and next-task line must carry the 2026-10-12 approval and vehicle decision.
Evidence: SELF - user decision; documents gitlink advanced to the approval-record commit.
Impact: task metadata and submodule pointer only.
Refs: modules/documents/docs/records/2026-10-12-service-restart-data-recovery-review.md
Why: the reviewed candidate moves from untracked drafts to a fixed two-repo combination; task card and project index must reference r2 and record the svc-autorecover ownership decision as a human gate.
Evidence: SELF - documents gitlink cbc64eb (r1 pinned at 54fc24e, revised to r2 with SHA256 9cfda252...); resume precheck receipt imported above; task-sync merged origin/main 555fb2162f cleanly.
Impact: task metadata, submodule pointer and index only; no business code, no push/PR.
Refs: modules/documents/docs/records/2026-10-12-service-restart-data-recovery-review.md (round 2)
Why: finish the prior session's in-flight records so the tree is clean before the resume precheck (P1.1 object pinning).
Evidence: SELF - documents gitlink now points at 54fc24e (proposal r1 + review record + INDEX); task card carries the prior session's evidence rows and authorization scope.
Impact: task metadata and submodule pointer only; no business code.
Refs: modules/documents/docs/proposals/2026-10-12-service-restart-data-recovery.md
Why: resolve the interrupted sync: take the reconciled Documents pin eb36571 (union of U2 progress and template/final-target plans) plus main's card/PROJECT updates.
Evidence: Documents PR #68 merge eb36571; gitlink conflict resolved to the superset tip.
Impact: task-branch integration merge only.
Refs: Documents #68; Dev #340/#354
Why: the master record now records U2 as merged (Documents 559af219); the Dev gitlink and PROJECT.md entry must follow.
Evidence: Documents PR #67 merged=True (API); closeout doc check receipt in card; RDM PR #197 merge fe8a75b.
Impact: modules/documents gitlink, PROJECT.md planning entry, task card; no code change.
Refs: Documents PR #67; RDM PR #197/#198
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=866086c2a080716195c3dd35e6ef362016347c94.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
Why: retain the clarified shared-project and private-document design with complete requirements coverage.
Evidence: SELF source receipt, 112-row requirements matrix, plan review and documentation checks in the task card.
Impact: local planning candidate only; no business implementation, push, merge to main or deployment.
Refs: modules/documents/docs/proposals/2026-10-11-rdm-final-target-completion.md
agent-exec-transport
weichenandCursor