Why: include the current integration baseline before verification.
Evidence: fetched origin/main=69c5c84d8a2f1a7966ebfb809cbb26d54e8e8abb.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
Why: Final fixed Documents composition and current modules passed their checks and now require the user acceptance decision.
Evidence: Complete SELF make test and document checks passed at4af5956; receipt5e81c91e and the independent RDM replay subjects are retained.
Impact: Record-only checkpoint after user stage 6 approval; do not claim stage 7 approval or shipping.
Refs: I1 bounded acceptance; policy/delivery.md
Why: Keep the user-approved implementation and pending acceptance separate in the fixed integration records.
Evidence: Current Dev make test passed at10789653 and RDM combined checks passed at70e27b08; final text-only combination is verified next.
Impact: Documents and card records only; no permission source, pins in RDM, existing services or production data changes.
Refs: I1 stage 7 acceptance candidate
Why: task-sync flagged the earlier rows as recorded with uncommitted script
changes; the gate requires key checks re-run at a committed head.
Evidence: SELF row via make evidence - 25/25 PASS on a fresh rdm@84ca64f
disposable instance.
Impact: task card only.
Refs: task feature/rdm-increment-settings-duties.
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=ee9b437b22b49f96e1bc65f79417b22e8e82a37c.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
Why: with the four-repo v0.4.0 release live, the account.list query/name
passthrough (RDM #356) enables the deferred full assertion of scenario 2; the
harness also needed v0.4.0 adaptations discovered on the combo instance.
Evidence: tool-written rows on the card - full ten-scenario run on a disposable
rdm@84ca64f combo instance (25/25 PASS incl. 2b name-substring, 2c
case-insensitive owner filter, 2d limit truncation), and dev service status
(rdm@84ca64f running against the live dev database, auth gate 401).
Harness fixes: rdm.project.member.setRole renamed to set-role (RDM #350);
command envelope parsed via payload; re-login after the password gate (base
#195 revokes sessions on password change); RDM world provisioning via
rdm.project.create + bind with the domain admin self-removing so owner2 is the
sole owner (creator is seeded as owner); scenario 8b asserts allow:true in the
current response shape; scenario 10b now meaningful (base #195 admits member
conversations through RDM project membership).
Impact: integration script and task card only; no product code.
Refs: task feature/rdm-increment-settings-duties; RDM #356; base v0.4.0 tags.
Why: Preserve the human stage 6 approval separately from the synchronized formal test candidate.
Evidence: Original reviewed objects and the user approval are recorded; startup recovery and synchronization outputs are captured as complete SELF receipts.
Impact: Advance approval records only, retain all upstream membership records and enter planned I1 API/command verification. No production operations or later increments started.
Refs: User approval; policy/delivery.md stage 6 to 7
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=ee9b437b22b49f96e1bc65f79417b22e8e82a37c.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
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: Backend #195 and Frontend #82 (parallel task feature/project-member-access)
merged after the original targets (Backend 15566f9 / Frontend c294835), and Dev
main 20e086e pins exactly those new heads (5d5fc989/eb2d6d32). Tagging the stale
SHAs would make RDM pins->v0.4.0 a downgrade versus Dev main, so the release must
land on current main HEADs; the checkout origin/main command already does this.
Evidence: SELF rows on the card - four-repo ls-remote (main HEADs recorded, all
v0.4.0 tag refs empty), git ls-tree origin/main pins, and 15566f9../42cda9c0..
commit ranges showing the parallel merges.
Impact: Dev task card release-plan section only; no code or pins change.
Refs: task feature/rdm-increment-settings-duties; related Backend #195,
Frontend #82, Dev #527.
Why: The final umbrella head needs its own gate after main components merge.
Evidence: Final task-sync receipt saved; candidate and merged component trees match.
Impact: Task-only checkpoint, keeping the same implementation and runtime boundary.
Refs: Dev PR526; project-member-access
Why: The final base combination must reference actual reviewed main commits.
Evidence: Component PRs are merged, and each merged tree matches the independently tested candidate; whole review receipts remain unmodified.
Impact: Advance gitlinks and preserve acceptance evidence; new exact-head CI follows with no runtime changes.
Refs: Backend195 Frontend82 Documents97; feature/project-member-access
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=d2c23f3a55a77711ded4328aa6215d9469c2b420.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
Why: Final merge gates require the latest main and exact component ancestry.
Evidence: Tool-written task-sync passed; Frontend tree equality preserves functional replay evidence while current HEAD CI will run again.
Impact: Task record only; no product source change.
Refs: feature/project-member-access
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=946cc13c9a10a2023a766b211e1148e625b62943.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
Why: The composed candidate and its validation limits must be available for independent review and current-head CI.
Evidence: Original receipts, fixed manifests, independent identities and real before/after task outcomes are preserved without source relabeling.
Impact: Archive acceptance and gate references in the canonical task; no product code, deployment or live data changes.
Refs: feature/project-member-access; Backend195 Frontend82 Documents97
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=d5428c5f05fc5f625e6232ab3156b17f13e14d6a.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
Why: Existing upload history must stay private after project adoption, and final object evidence must remain traceable.
Evidence: Original tool receipts and independent reports saved byte-for-byte; new fixed combination and CI remain pending.
Impact: Select Backend d26f3cf and proposal r1.1 with unchanged public downstream contracts; preserve workspaces and live data.
Refs: feature/project-member-access; Frontend PR82; Documents PR97
Why: Preserve final fixed-composition verification and separate the local implementation from formal acceptance and shipping.
Evidence: Final Dev make test and document checks passed on 5b8cb91a with full SELF receipt 7ac5b1db; RDM make test and independent preliminary review are linked through their owning task.
Impact: Task record only. No implementation component changes, push, PR, merge or deployment.
Refs: Approved IAM I1 U1-U2; Documents c023551 review record
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=d5428c5f05fc5f625e6232ab3156b17f13e14d6a.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
Why: Keep the reviewable contract and observed verification together in the fixed parent composition.
Evidence: Dev make test passed on 0ab70b0c and RDM make test passed on ef075bd1, recorded as complete SELF receipts. Final parent pin verification follows this metadata checkpoint.
Impact: Advance the text-only review record and save evidence; no implementation components changed.
Refs: IAM I1 U1-U2 local review
Why: Shared project identity resolution is one private module used by app and server.
Evidence: Boundary scan passes 85 edges and its injected illegal-edge negative check; previous full run stopped at this documented boundary.
Impact: Add only app/server to projectscope and projectscope to store, without allowing transport/composition dependencies in the resolver.
Refs: system-project-membership proposal r1; feature/project-member-access
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=143e6367367760deceac91ac3de5ccb3ed6adebc.
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: include the current integration baseline before verification.
Evidence: fetched origin/main=143e6367367760deceac91ac3de5ccb3ed6adebc.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
weichen