Migration map.

design_access_get

Read installed-feature access settings, hierarchy and membership candidates for one channel. Omit installedPAppId first, then select an editable target and read it again to obtain its permissions, capabilities and revision. This call sends no writes and creates no task.

Unknown fields are rejected. Use the existing design-screen OWNER or DELEGATEE context; the server remains authoritative for channel authorization. This workflow does not implement the newer per-operation permission-bit guard used by some other channel tools. The source-defined hosted channel resource admits only its exact channel; an account resource excludes these tools and access-control recovery. Deployed authorization is a separate verification question.

List targets and one page of candidates:

{"channelCode":"selected-channel-code","membershipPage":1,"membershipLimit":50}

Read an editable installed-feature target:

{"channelCode":"selected-channel-code","installedPAppId":123,"membershipPage":2,"membershipLimit":25,"membershipSearch":"Supporters"}

Replace the example channel and ID with the selected channel and a returned editable target. Membership search/pagination does not filter the hierarchy or targets. Follow nextMembershipPage until null when a complete candidate inventory is needed; the default page is not the whole inventory. Candidate rows expose mid, title and type; saving selected IDs independently requires current-channel GENERAL membership detail verification.

A successful DESIGN_ACCESS result includes environment, channel, flattened hierarchy, targets, memberships, pagination and nextMembershipPage. Hierarchy nodes retain hiid, parent, type, target identity, feature code, active/public state, available guard statuses, optional normalized permissions and entrance conditions. System-managed monitoring grants are represented by a digest when present, without returning their grant IDs.

targets includes P_APP_PATH rows even when they are not editable. Editing requires exactly one matching installed-feature row, a non-null target ID, a nonempty feature code other than X00001 and nonempty available guard statuses. Page IDs, inner-screen targets and system pages are not substitutes. A selected editable target adds installedPAppId, pAppCode, permissions, capabilities and a 64-character lowercase hexadecimal revision. The permission rules explain supported guest modes and paid-access preservation.

Copy the selected target's revision into apply. It covers target hierarchy/installed/feature identity, canonical ACL permissions and the optional monitoring digest. It does not cover every channel entrance or visibility condition. List-only get has no target revision. Unsupported or ambiguous ACL data fails with an unverified-contract result; no missing guest fields or false membership grants are guessed into allowed access.

verification.confirmed:true with method:"access_read" confirms the read contract. effectiveVisitorAccess:false means effective visitor access was not verified, not that every visitor is denied. Stored settings, channel entrance restrictions and actual visitor behavior remain distinct. See the screen contract for transport and historical evidence boundaries.

Failed reads

The hierarchy and membership reads start together, as on the source storyboard; the ACL summary follows. A failure returns an error with readStage (the first failing stage), reads (each stage's own result, not_reached where it did not run) and writesPerformed:false. An UPSTREAM_HTTP_* code carries upstream: method, path, query parameter names, status and the server's error code/message with credential-shaped text removed. Readable parts are kept for diagnosis. When the hierarchy fails, the summary of the requested installedPAppId is still read and returned as permissionSummary with targetVerified:false and editable:false. A failed result never includes revision, so no save follows it; the source screen shows nothing after a failed read.

Installed-feature policy

Installed pApps are enabled by installation. There is no separate activation or deactivation step. Use this ACL workflow for supported visitor-access changes; uninstall is not an access-control substitute. A failed read leaves permissions unverified and unchanged, not denied. SELECTED with no memberships still preserves existing paid-entitlement access and must not be reported as blocking everyone.

Inputs