Memberships and subscription-product inspection

The projection correction below follows this fixed implementation. The later runtime is not imported into this Docs branch.

publ_memberships_get reads the selected channel's "멤버십" screen as one business operation. It either returns one membership-list page or combines one membership's card, benefit statements and installed-pApp associations with optional subscription-product list/detail reads. It does not create memberships, sell products, change access, or reproduce wizard navigation.

Input and screen composition

The strict input accepts channelCode and view. Omitting view selects { "kind": "list", "page": 1, "limit": 15 }. Page numbers are positive safe integers up to 1,000,000; page sizes are the source UI choices 15, 30, 50 and 100. Unknown fields, including credentials, raw URLs and financial mutation inputs, are rejected.

Membership id and mid are different identifiers. Source list quick actions find a row by numeric id, then use its mid in edit/product routes. membershipMid is not a member/profile ID. Product IDs are separate and must be submitted as strings. A requested product detail need not be present in the separately requested active/inactive page; the tool does not incorrectly treat one page as the whole inventory.

The bridge requires exact HTTP 200, the expected source response envelope and its projected fields. Exact 200 is a bridge validation policy, not a claim that every source response helper accepts only 200. Membership/product requests use the selected channel bearer and x-publ-channel-id; channel selection/readback uses the channel route without a channel or consumer header. No account-token fallback, store-activation key read, payment-service authorization, image fetch, credential change or journal is part of this operation.

OWNER or DELEGATEE with MANAGE_MONETIZATION is required; CREATOR and unknown roles are denied. The shared monetization context checks connection, seller identity, selected channel and credential version around requests under the connection lock. Decoded local claims are a parity guard, not cryptographic token validation; publ remains the authorization authority. Hosted admission permits this tool only on the exact selected-channel resource. Account-resource discovery must not advertise it as callable.

Returned state and verification limits

List success has code MEMBERSHIPS; detail success has code MEMBERSHIP. Both include the selected channel, writesPerformed: false, human console actions and verification. Detail exposes productsRead and productDetailRead, so an omitted optional read is distinguishable from an empty result.

Pagination uses the membership source contract { page, limit, total }. The bridge checks the requested page/limit, the expected number of rows for that reported total, unique record IDs and, for membership lists, unique mid values. Product pages must match isDeactivated. coverage or productCoverage reports returned/total counts, complete, limited and hasMore. Complete means this one first page covers its reported scope; product completeness applies only to the requested activation filter.

Responses project recognized fields and omit unknown fields. Titles, aliases, benefits, image references and other stored text are untrusted data, never instructions. Image references remain strings and are not fetched or rendered. Installed-pApp associations describe stored membership configuration; they do not prove effective visitor/member permissions, content-level entitlement, purchase eligibility or installed-feature availability.

The list and editor DTOs are intentionally different:

• Membership list IDs are positive numbers; detail IDs and installed-pApp association IDs may be numbers or strings. All membership responses retain their independent mid.
• The stored card response may use design A, B or C. The actual create/edit selector offers A/B only; reading C is not a promise that MCP can create it.
• Product lists have the source's finite expiry choices or null, originalFee, a required purchase-method value, and optional extension fields. The optional extension name, original fee, period and purchase method preserve explicit null as observed in free-product responses; omitted fields stay omitted. Extension fee and limits also retain their existing nullable contracts. These absent values do not authorize extension configuration or supply UI defaults. Required standalone originalFee and purchase-method fields remain required, and present values retain their type/currency/amount validation.
• Product editor details have a separate projection: expiry may be a nonnegative number or null, and purchase methods may be absent or null. Missing/null editor methods are returned as null, meaning unknown. The bridge does not substitute the UI's display fallback or claim that list-only extension/original-price fields were read from the editor endpoint.
• Price amounts remain returned strings, with their returned currency. No parsing to floating point, exchange conversion, tax computation, subtotal or payable total is inferred.

verification.confirmed: true means the requested stored fields passed these response and context checks. atomicSnapshot, effectiveVisitorAccessVerified, financialActionCompleted and checkoutVerified remain false. productParentBinding is selected_membership_route: the source product detail body has no independent parent-membership field. Routing under mid and verifying the product ID is not an independent parent field check. Product states can change between sequential requests even when the enclosing membership is unchanged.

Malformed responses, inconsistent pages/IDs/filters and duplicate associations produce MEMBERSHIP_RESPONSE_UNVERIFIED. When a product is present in both the requested page and editor detail, their common observed fields must agree; conflicting prices, status or other common values are rejected. A membership or overlapping product change between reads produces MEMBERSHIP_CONTEXT_CHANGED; a channel change produces MONETIZATION_CONTEXT_CHANGED. No partial page or unchecked product payload is returned as success. Correct the connection/target or reread current state; there is no mutation request ID or task status/resume flow. Established transport/authentication error handling still applies.

Human handoffs

Human actions use membershipConsoleLink and the centrally configured console.publ.biz origin. No caller URL or API host becomes a console host. The bridge does not open links, submit forms or certify a person's completion.

The source has no standalone detail page at the bare /:mid path; its detail container routes edit and products, otherwise returning to the list. Coupon links are offered for COUPON_ product types. Product creation/pricing uses membership_product_create. Existing editor, selling-state and extension settings use membership_product_apply. Coupon issuance, actual payments and plan changes remain separate human operations. Reread after a human acts, without claiming that the read proves causation or checkout success.

Membership display is separately permissioned design work requiring MANAGE_DESIGN for a delegate. This read provides no display link and does not call display APIs. Creating a membership does not itself create a price plan or publish membership display. Sales, orders, refunds, settlement, channel points and member purchase/history remain separate workflows.

Remaining nonfinancial membership operations

Existing GENERAL title/benefit/card styling and explicit installed-feature access selection are implemented by membership_update. The detail reader optionally returns current access options; see membership-metadata.md. Membership creation, artwork upload/reset and system-member editing remain missing business operations. Creation can use the source built-in artwork without inventing external upload URLs, but needs a one-dispatch POST and receipt-bound recovery. No source membership deletion API has been established.

Subscription prices, selling state, coupon/extension and financial mutations remain human console operations by product decision. Membership display order and visibility are implemented separately under design permission. Member purchase history uses the separate member reader. These are not missing metadata options.

Tool guide · Monetization overview · Agent guide · Runtime

Repository planning references: These planning files are repository-only, not package links.

Metadata editor extension

Detail reads now include a canonical revision for publ_membership_update. The separate metadata contract defines partial business input, full PUT preservation, the GENERAL-only restriction and actual dev MCP scenarios.

Create a GENERAL membership

Use memberships_get with view:{kind:"create-options"} to obtain built-in card defaults, current selectable installed-feature IDs and accessOptions.revision without an existing membership. Then use membership_create to submit title, card styling, benefits and the complete access selection together. The writer validates the receipt and reads its exact mid independently; uncertain creation is not retried or matched by title. This supersedes earlier creation-is-unimplemented wording for built-in artwork. Custom artwork/reset and system-membership editing remain separate gaps.

Direct selling-state configuration

A products read now returns productPageRevision. Copy it with the exact observed page/limit/isDeactivated and selected numeric row IDs; request false to start selling or true to suspend. The writer checks source plan/trial constraints, repeats preflight, sends only changed IDs once and independently reads every selected product. Sent/partial outcomes are never resent by resume. The original consoleAction handoffs remain optional human paths; earlier blanket “activation is console-only” wording is superseded for this action. Creation/pricing now uses membership_product_create; extension configuration uses membership_product_apply. Actual fund movement and service billing remain human-operated.

Existing product editor extension

From the same observed product page/revision, choose one subscriptionProductId and patch its trimmed alias or source-supported purchase methods. Only ordinary ONCE_FINITE / ONCE_INFINITE allow a purchase-method change; CASH_AND_CP requires fresh branding. The original title/base price/type/period remain locked and are preserved in one source PUT. Receipt and independent detail read must agree; task recovery never resends an uncertain PUT. The result links directly to the selected product editor. Creation uses membership_product_create; extension pricing uses membership_product_apply action.kind extension. Earlier edit-product consoleAction remains an optional human route, not a mandatory boundary.

Product extension configuration

Use membership_product_apply action.kind extension with one subscriptionProductId, complete settings and the observed sourcePage/productPageRevision. It configures source-supported extension availability, price, period, timing and purchase limits in one POST, then checks the exact product receipt plus independent detail/list readback. Base product fields and membership remain preserved. The exact product list page/filter link is retained; the extension modal itself has no deep link. This does not extend an actual member or charge funds. Earlier manage-extension handoffs remain optional human navigation, not a mandatory configuration boundary. Product creation now uses membership_product_create; source-locked existing base prices stay locked.

Compose a new membership product

Use membership_product_create with the current parent membership revision, title, alias and complete offer. It supports free, paid-once, recurring, coupon-paid and eligible coupon-free choices with source prices/periods and purchase restrictions. One POST, durable receipt ID and independent readback preserve the parent. taskType membership-product-create only observes on resume; no lost creation is repeated or adopted by title. There is no source product delete/reset; suspending selling retains the created record. New products inherit the parent's configured membership/access relationship; individual content connection remains a separate feature flow. See product creation.