Why: the project access and lifecycle work (U1-U6) is now on Backend and RDM main, but Dev still pins an RDM artifact from 2026-10-13 — 918-plus commits behind, and predating the point where role authority moved to Backend. Until this pin advances, none of U2/U3a/U4/U5 ships in the composed product. This PR closes that gap and brings the shared executor along so admission can recognise baseline content.
Evidence:
RDM pin c6304224 → bc8db88 (RDM main, PR #460). Verified that the target contains the delivered work: managementCeilingDenial and managementLifecycleDenial in internal/rdmapp/projects_api.go, txProjectManaged in internal/rdmapp/render_profile.go, MemberAddResolveFailure in internal/rdmapp/project_failure.go.
prev_sha becomes the previously pinned c6304224, keeping the real lifecycle suite's round-trip identity check meaningful; legacy_sha is untouched because it carries the "no identity" semantics that suite depends on. The pin file's comment now states plainly that schema compatibility between sha and prev_sha is not guaranteed by the pin and is what the real lifecycle suite verifies.
deps/development-manager1e5ee55 → 2c2e372 (Development-Manager PR #32), which lets admit accept staged content byte-identical to the authoritative baseline. Without it a task branch cannot merge a mainline that carries real source changes — see the RDM case, where 65 upstream paths were refused until this landed.
modules/backend is not touched here: its pin f084d10 already contains the Backend merge 7158bea from this delivery, verified by ancestry.
Full combination verification green on 98d794e (make test, no failures). The real combination gates that actually exercise the new RDM pin — test-pg and svc-realcombo — run only in CI; local evidence cannot substitute for them.
What the pin advance exposed:
Landing the RDM half required fixing six authorization defects that Dev's gates could never have caught, because those gates only ever exercised the pinned components, never the delivery branches. Three were silent security regressions: the archived-project read-only guard had been lost, the administrator platform cap no longer bounded the creator, and render-profile still let a non-creators exercise project.settings through a role-owner label or an explicit override. Independent review found them one at a time across five rounds; the structural cause was that the R3 refactor moved management paths off evalPerm onto requireProjectManagement and dropped its gates one by one.
A note on the record: an earlier commit in this branch described the delivery branches as "red at tip" as though it were an established finding, with figures that matched no natural measurement. That has been corrected in the task card, which now separates a checkable claim from a SELF observation and voids the imprecise numbers.
Why: the project access and lifecycle work (U1-U6) is now on Backend and RDM main, but Dev still pins an RDM artifact from 2026-10-13 — 918-plus commits behind, and predating the point where role authority moved to Backend. Until this pin advances, none of U2/U3a/U4/U5 ships in the composed product. This PR closes that gap and brings the shared executor along so admission can recognise baseline content.
Evidence:
- RDM pin `c6304224` → `bc8db88` (RDM main, PR #460). Verified that the target contains the delivered work: `managementCeilingDenial` and `managementLifecycleDenial` in `internal/rdmapp/projects_api.go`, `txProjectManaged` in `internal/rdmapp/render_profile.go`, `MemberAddResolveFailure` in `internal/rdmapp/project_failure.go`.
- `prev_sha` becomes the previously pinned `c6304224`, keeping the real lifecycle suite's round-trip identity check meaningful; `legacy_sha` is untouched because it carries the "no identity" semantics that suite depends on. The pin file's comment now states plainly that schema compatibility between `sha` and `prev_sha` is **not** guaranteed by the pin and is what the real lifecycle suite verifies.
- `deps/development-manager` `1e5ee55` → `2c2e372` (Development-Manager PR #32), which lets `admit` accept staged content byte-identical to the authoritative baseline. Without it a task branch cannot merge a mainline that carries real source changes — see the RDM case, where 65 upstream paths were refused until this landed.
- `modules/backend` is not touched here: its pin `f084d10` already contains the Backend merge `7158bea` from this delivery, verified by ancestry.
- Full combination verification green on `98d794e` (`make test`, no failures). The real combination gates that actually exercise the new RDM pin — `test-pg` and `svc-realcombo` — run only in CI; local evidence cannot substitute for them.
What the pin advance exposed:
Landing the RDM half required fixing six authorization defects that Dev's gates could never have caught, because those gates only ever exercised the *pinned* components, never the delivery branches. Three were silent security regressions: the archived-project read-only guard had been lost, the administrator platform cap no longer bounded the creator, and render-profile still let a non-creators exercise `project.settings` through a role-owner label or an explicit override. Independent review found them one at a time across five rounds; the structural cause was that the R3 refactor moved management paths off `evalPerm` onto `requireProjectManagement` and dropped its gates one by one.
A note on the record: an earlier commit in this branch described the delivery branches as "red at tip" as though it were an established finding, with figures that matched no natural measurement. That has been corrected in the task card, which now separates a checkable claim from a SELF observation and voids the imprecise numbers.
Refs: Backend PR #234, RDM PR #460, Development-Manager PR #32, Dev PR #634.
Why: establish the authorized task workspace and its initial baseline.
Evidence: preserved precheck receipt in .task/fix-pal-component-delivery-pins.md; R0=a496ea0f0249b2b412354677ef97612ccd692d25.
Impact: task metadata only; the feature workspace starts at a496ea0f02.
Refs: .task/fix-pal-component-delivery-pins.md
Why: the task card still carried the placeholder goal while the Backend half
of the delivery had already landed, and the verified pre-merge pin state is
the justification for the whole task.
Evidence: Backend main 7158bea contains 284d3ac; Dev pins measured at
dfb31da / 113103f / RDM c6304224.
Impact: task card only.
Refs: Backend PR #234
Why: decision D1 (user ruling A1 on whether the role-cap layer is covered by
R3's carve-out) was written into an RDM test comment as "Decision A1" without
ever being recorded anywhere in the repo, so a later review round found it
cited but unverifiable. D2-D4 are not new choices either: they follow directly
from the plan's U2 archive clause, R6, and the standing platform-cap domain
rule, and now have a written home.
Evidence: RDM review rounds 1-4 in this branch's worktree.
Impact: task card only.
Refs: RDM feature/project-access-lifecycle-u4-work-states-merge
Why: both components have landed, the delivery branch red-at-tip finding and
the six authorization defects it exposed are the substantive result, and the
admit baseline-recognition change is what unblocked the merge at all. None of
that was recorded.
Evidence: Backend 7158bea (Dev pin f084d10 already contains it); RDM bc8db88
via PR #460, five review rounds ending PASS, CI green; Development-Manager
2c2e372 via PR #32.
Impact: task card only.
Refs: Backend PR #234, RDM PR #460, Development-Manager PR #32, Dev PR #634
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=ccb6dfaa9cdf7e69eb15d7df024dee55f37b8df1.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
Why: an independent review caught that the card asserted the two delivery
branches were red at their tips as a verified conclusion, and that the figures
I quoted matched no natural measurement. Both are session-local observations,
not evidence this repo can reproduce.
Evidence: the card now separates a checkable claim (Dev's gates never exercise
the delivery branches) from a SELF observation with the exact commits and
method, marks it as not admissible as GATE evidence, and voids the imprecise
numbers from commit 537bf66.
Impact: task card only.
Refs: RDM PR #460, Development-Manager PR #32
Why: include the current integration baseline before verification.
Evidence: fetched origin/main=a736d5a420370cff052bd946f6d6397d4c354547.
Impact: integrate upstream changes without rewriting task history.
Refs: task-sync
Why: advancing the RDM pin red-lights test-pg on a real composition problem
that make test cannot see, and the card must say so plainly instead of showing
a green combination run.
Evidence: run 4707 job 7812 — the combination build reports missing go.sum
entries for agent-document-renderer packages. RDM bc8db88 replaces that module
with a local path and therefore carries no go.sum entries for it, while the
Dev-side build redirects the backend replace to modules/backend (f084d10),
which imports those packages directly.
Impact: task card only.
Refs: PR #682
Why: the fail-loud assertion worked as intended and named the real cause -
RDM's pins set grew from four to six, so the CI step that checks out and builds
all three pins no longer sees a consistent layout. My prev_sha choice was
wrong and I did not check layout consistency when writing the unit.
Evidence: run 4711 job 7821 - 'rdm pin c6304224 的 pins/agent-system-frontend
未落地：缺少 go.mod'; pin layouts verified across all five commits; local
build-product.sh on the delivered head succeeds.
Impact: task card only.
Refs: PR #682
Why: the pin materialization fix did its job - all three pins now build and the
missing-go.sum error is gone - so the failure relocated to the real combination
lifecycle gate, where svc.sh cannot git fetch from CI's shallow RDM clone.
That is a different component's concern and outside this pin advance.
Evidence: run 4714 job 7830 - svc-realcombo and test green; three lifecycle
cases fail on svc.sh's git fetch against the shallow RDM source clone.
Impact: task card only.
Refs: PR #682
Why: the RDM materialization fix landed separately as PR #684, so this branch
now takes main's version of the workflow and carries only the pin change. The
conflict resolution keeps the fix (submodule update per pin, language-agnostic
fail-loud assertion) and drops the pin-specific comment that described a
first-parent distance belonging to the other pull request.
Impact: workflow resolves to main's already-merged content; this commit's own
contribution is the rdm.pin prev_sha correction.
Refs: PR #682, PR #684
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Why: the project access and lifecycle work (U1-U6) is now on Backend and RDM main, but Dev still pins an RDM artifact from 2026-10-13 — 918-plus commits behind, and predating the point where role authority moved to Backend. Until this pin advances, none of U2/U3a/U4/U5 ships in the composed product. This PR closes that gap and brings the shared executor along so admission can recognise baseline content.
Evidence:
c6304224→bc8db88(RDM main, PR #460). Verified that the target contains the delivered work:managementCeilingDenialandmanagementLifecycleDenialininternal/rdmapp/projects_api.go,txProjectManagedininternal/rdmapp/render_profile.go,MemberAddResolveFailureininternal/rdmapp/project_failure.go.prev_shabecomes the previously pinnedc6304224, keeping the real lifecycle suite's round-trip identity check meaningful;legacy_shais untouched because it carries the "no identity" semantics that suite depends on. The pin file's comment now states plainly that schema compatibility betweenshaandprev_shais not guaranteed by the pin and is what the real lifecycle suite verifies.deps/development-manager1e5ee55→2c2e372(Development-Manager PR #32), which letsadmitaccept staged content byte-identical to the authoritative baseline. Without it a task branch cannot merge a mainline that carries real source changes — see the RDM case, where 65 upstream paths were refused until this landed.modules/backendis not touched here: its pinf084d10already contains the Backend merge7158beafrom this delivery, verified by ancestry.98d794e(make test, no failures). The real combination gates that actually exercise the new RDM pin —test-pgandsvc-realcombo— run only in CI; local evidence cannot substitute for them.What the pin advance exposed:
Landing the RDM half required fixing six authorization defects that Dev's gates could never have caught, because those gates only ever exercised the pinned components, never the delivery branches. Three were silent security regressions: the archived-project read-only guard had been lost, the administrator platform cap no longer bounded the creator, and render-profile still let a non-creators exercise
project.settingsthrough a role-owner label or an explicit override. Independent review found them one at a time across five rounds; the structural cause was that the R3 refactor moved management paths offevalPermontorequireProjectManagementand dropped its gates one by one.A note on the record: an earlier commit in this branch described the delivery branches as "red at tip" as though it were an established finding, with figures that matched no natural measurement. That has been corrected in the task card, which now separates a checkable claim from a SELF observation and voids the imprecise numbers.
Refs: Backend PR #234, RDM PR #460, Development-Manager PR #32, Dev PR #634.