[Migration map](../reference/tool-name-migration.md).
# 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.
| Input | Contract |
| --- | --- |
| `channelCode` | Required nonempty string identifying the selected channel |
| `installedPAppId` | Optional positive integer copied from an editable `targets` row |
| `membershipPage` | Optional integer, minimum 1, default 1 |
| `membershipLimit` | Optional integer, 1–100, default 50 |
| `membershipSearch` | Optional string forwarded to membership search; this schema specifies no length limit or trimming |
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:
```json
{"channelCode":"selected-channel-code","membershipPage":1,"membershipLimit":50}
```
Read an editable installed-feature target:
```json
{"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](../guides/access-control.md#permission-rules) explain supported guest modes and paid-access preservation.
Copy the selected target's revision into [apply](publ_design_access_apply.md). 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](../design/access-control.md) 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
| Field | Required here | Contract |
| --- | --- | --- |
| `membershipPage` | No | integer; minimum 1; default `1` |
| `membershipLimit` | No | integer; minimum 1; maximum 100; default `50` |
| `membershipSearch` | No | string |
| `app` | No | string; The feature screen: its code (for example A00002) or its exact title from the targets list. |
