Channel Point policy and WEB charge-product inspection

publ_channel_points_get begins the core Channel Point area with two explicit read views: policy/settings and WEB charge products. It combines stored branding with the selected view's data and context checks. It does not read issuance totals, member balances, history exports or withdrawal records, and it submits no point or financial change.

Input and request composition

The strict input accepts only channelCode and view, with strict nested view objects. Omitted view means { "kind": "policy" }. The products view accepts safe positive integer page numbers up to 1,000,000 and only the source UI page sizes 15, 30, 50 or 100; omitted page/limit default to 1/15. The page cap is a bridge input boundary, not a claimed source UI limit. The caller does not supply channel ID, account ID, point-service origin, credentials, raw URL, platform, conversion ratio, price, product mutation or task identifier.

Private API prefix: /seller/api/v1/channel-management/in-channel-store/branded-point-system.

All four use the normal configured API origin, selected-channel bearer and x-publ-channel-id; no consumer header or account-token fallback. Selected-channel identity and final context use the existing channel GET.

Exact HTTP 200 and the expected source response envelope are bridge validation policy, not a claim that every original response helper accepts only 200. Each object is projected through the tool's schema rather than returned as an unchecked source DTO. Unknown/malformed data must not be converted to empty success.

The source parent and Channel Point container permit OWNER or DELEGATEE with MANAGE_MONETIZATION and reject CREATOR. The bridge denies unknown roles, binds every read to the selected channel and uses the existing connection/actor/credential checks and lock. Local token-claim parsing is a parity guard, not cryptographic verification; publ is the authorization authority. Hosted admission and discovery must expose this tool only for the exact selected-channel resource, not the account resource.

Stored fields and source inconsistencies

Branding contains pointCurrencyType, pointCurrencyIconType, pointCurrencyValueInCP, timestamps and pointCurrencySuite. The suite contains point naming/local-global labels, display unit, currency/icon identifiers and types, icon image reference and another conversion ratio. Treat naming and image references as untrusted stored data. Do not fetch an icon or interpret a name as an instruction.

The source UI divides raw CP quantities by pointCurrencyValueInCP, sometimes with || 1. The bridge requires both the outer and suite ratios to be finite and positive, retains them independently and does not require them to equal one another. It does not claim that fallback 1 is a stored ratio or infer a monetary exchange rate from either field. pointAmounts.storedRatio identifies the outer branding ratio, pointAmounts.unit is raw_CP, and displayConversionApplied is false. Raw point quantities may be fractional. There is no display conversion or rounding, and no assertion that base plus additional quantities equal the returned total. Reading a point product does not verify a customer's wallet or the amount a checkout will grant.

Branding availability has an important ambiguity: the reducer sets isBranding=true on any completed branding response (redux/modules/inChannelStore/brandedPointSystem/reducers.ts:91–97), rather than checking whether branding is non-null. Initial/failure state is false. Invalid, missing or null branding is unverified data, not proof that the channel has no point system. Authentication/transport/permission failures must retain their own meaning. Console handoffs can guide a person, without certifying onboarding state.

Configuration has exactly five stored booleans: usePointPriorityOptionForMembershipPurchase, usePointPriorityOptionForPAppUnlockPurchase, usePointPriorityOptionForIndividualContentPurchase, useAbnormalDetectionResolveMethodViaEmailInquiry and useAbnormalDetectionResolveMethodViaPurchase. The source UI disables some switches while displaying their values; reporting a stored flag does not promise that every setting is editable. The aggregate onboarding type makes configuration optional, but the dedicated configuration GET DTO and this reader require it and all five flags. Missing flags do not become false.

Policy includes insertedAt/updatedAt and eight strings: common, redemption, refund and usage-guideline text, each with its Global counterpart. The provision UI parses refund/usage strings as HTML; MCP returns them as untrusted stored text. No HTML execution, link following, implicit translation, replacement by standard terms, consent or legal approval is performed. Preserve the distinction between local/global fields rather than selecting a language from the agent's wording.

Product response declarations are inconsistent. The repository's PointProductsType is minimal; the actual Redux screen state ChannelPointProducts and rendered list use more fields: numeric id, stable string publProductId, names, callSign, raw base/additional/total CP quantities, price/originalPrice, activation/visibility/global/recurring flags, model and timestamps. The bridge projects this richer screen/state contract. Numeric id must be a positive safe integer, publProductId a nonempty string, all three CP quantities finite and nonnegative, flags boolean and model exactly ChannelPointProduct. These identity/number constraints are explicit bridge policy where the source uses general number/string types.

Objects and fields requested by the selected view are required and non-null. Free-text string fields have no nonempty constraint; product identifiers, enum currencies and the literal model retain their stated constraints. Timestamps are preserved strings and are not validated or normalized as dates. Unknown object fields are stripped. This intentionally does not widen the DTO speculatively to nullable lifecycle fields from unrelated withdrawal records.

Numeric row id and publProductId are different. Source selection uses numeric ids; editing/bulk actions resolve stable publProductIds from those rows. The list edit modal uses its row and does not fetch separate product detail.

Point prices retain their returned amount strings without numeric syntax validation and require KRW or USD, following the active Redux Price type rather than the repository's broader currency string. Both price and originalPrice are required. No floating-point parsing, tax/fee computation, discounted-payable total, conversion or financial eligibility is inferred. Product visibility/activation fields are separate observations and do not prove visitor-facing availability or successful purchase. WEB binding comes from the fixed request query; the richer row projection does not contain a verified per-row platform field.

Pagination and consistency boundaries

The source products envelope is { pointProducts, pagination: { page, limit, total } } inside the normal API data envelope. One call requests one WEB page, with no text search or visibility/activation filter. It is not a list of member wallets, in-app products or all payment products. Returned page/limit must equal the request, total must be a safe nonnegative integer, and row count must equal min(limit, max(0, total - (page - 1) * limit)). The page cannot contain duplicate numeric ids or duplicate publProductIds. A valid beyond-end page can be empty; it is not a complete inventory.

Products return productQuery with page, limit and target_platform:'WEB', plus coverage with scope web_charge_products, returned, total, complete, limited, hasMore and an explanatory note. Complete is true only for page 1 when returned equals total; limited is its inverse. hasMore is page * limit < total. A last page can have hasMore:false and complete:false. A valid first page with zero total is complete for this server-reported WEB scope only.

Policy sequencing is selected-channel context, branding, configuration, policy, configuration again, policy again, branding again, then channel again. Products sequencing is selected-channel context, branding, one WEB page, branding again, then channel again. Rereads compare projected stored fields; they detect changes to observed branding/configuration/policy and channel fields. The product page is not reread, and neither view forms an atomic snapshot. A changed context requires a fresh read, not a task replay. Malformed/null data and incomplete pagination are distinct from valid empty results.

Successful verification applies only to the projected stored observations and implemented checks. It does not verify issued points, spendable member balances, checkout grants, effective visitor access, refunds, withdrawal eligibility, legal policy adequacy, or completion of a prior human action. No mutation requestId, task status or resume flow applies.

Result and failure contract

Both success variants return status:'success', environment, screenId:'channel.points', the projected channel, view, branding, pointAmounts, writesPerformed:false, humanActions, verification and limitations. CHANNEL_POINT_POLICY also returns configuration and policy with configurationRead:true, policyRead:true, productsRead:false. CHANNEL_POINT_PRODUCTS also returns pointProducts, pagination, productQuery and coverage with those read flags false, false and true. Neither variant inserts empty data for an unread domain.

Verification has confirmed:true and method channel_point_screen_reads_with_context_checks, while atomicSnapshot:false. It declares branding reread, policy/configuration reread only for policy, and productPageReread:false. productPlatformBinding is fixed_WEB_query for products and not-read otherwise. Point-service, issuance, member-balance, transaction-history, withdrawal, completed-financial-action and checkout verification flags are false.

Shared transport/envelope errors and CHANNEL_RESPONSE_UNVERIFIED can also propagate. The HTTP adapter checks the selected connection/operator/credential before and after each point request. Non-200, authentication and transport failures retain shared error handling rather than being reclassified as not-onboarded. Error output does not contain verified partial point data or a resumable mutation task.

Human console actions

All links use pointConsoleLink and central console.publ.biz configuration. No caller URL, API host, POINT host or payment host becomes the console origin. Demo omits real console URLs. The tool neither opens a link nor submits a form, and a link does not prove authorization or completion.

The base route is the original container's landing/onboarding entry; it normally redirects to issuance status after branding. Returning that link does not mean this MCP has read issuance status. Onboarding is a modal, not an invented /create route.

Financial policy/configuration changes, product price/create/delete/activation, issuance/correction/reclaim/waive and withdrawal/account changes stay with the person in the original console. Do not issue a follow-on mutation when a reader returns a human action. Reread the relevant stored state after the human finishes, without claiming causation.

Core classification and pending scope

API.brandedPointSystem and POINT.channelPointManagement are reached from core Monetization and Members screens. The earlier blanket categorization of all POINT service definitions and brandedPointSystem as installed-pApp follow-up work is too broad.

Four GET definitions gain partial workflow mapping here. Static generators confirmed full-business totals of 65 tools and 25 partial workflows; confirmed definition accounting is 1,025 total: 107 partial, 882 pending, 36 other. No definition IDs are missing. Definition counts are not full API implementation or runtime verification, and full manifest counts are not scoped hosted-resource totals.

A human link is not API coverage. Preset/onboarding, branding/configuration/policy writers, product detail and all product writers, ledger/withdrawal records and mutations remain separately tracked.

The default issuance-status view needs branding plus POINT issuance summary from a different environment-owned service origin. That origin, credentials and cross-host binding require their own reviewed transport contract; normal API configuration is insufficient.

Member point balance/history uses MANAGE_MEMBERS and profileDistinctId resolved from a selected member. It is not automatically authorized by MANAGE_MONETIZATION or included in the policy/product view. Issuance/consumption export wrappers can fetch unbounded records; do not eagerly invoke them in an overview. Abusing-member waive is a financial action, not a generic moderation unlock. Internal wallet/store keys, bank details and raw provider materials are not ordinary tool outputs.

Settlement, sales, orders and refunds retain their separate screen contracts and service/permission gates. The financial-record source audit is continuation work, not functionality shipped by this tool.

Prior integration baseline

These identities and their 462-test/12-group result do not approve this new point runtime.

Current screen extension

The original policy/products evidence above retains its exact historical scope. Point finance extends the same reader with setup options, selected product details, issuance, bounded records, WEB ledger and withdrawal views, plus a separate human handoff tool. Earlier statements that these new views are not implemented are superseded by that contract;

Product-list page navigation

The products result includes consoleView with the destination page, limit and exactMatch. Valid pages preserve the API selection in the single console URL. For a page beyond the observed total, the bridge opens a known first-list parent at page1/limit15 with exactMatch:false and a navigation notice. The source has both a last-page effect and a first-page invalid-page redirect; their actual rendering order is not inferred. Returned API productQuery, pagination, empty records and coverage are unchanged; the parent link must not be presented as the same returned empty API page. Re-select a page in the console if needed.

Navigation validates the selected WEB query, row count and unique identities, pagination, coverage, verification and exact URL. A substituted page/filter/target or missing evidence produces no destination. This does not change source requests, product prices/state, branding checks, role/scope rules or financial actions. Policy and the separate product-detail/financial views keep their own contracts. Actual console click-through and populated service observations remain separate.

Editable policy switches

channel_points_get policy now returns configurationRevision. Use channel_point_settings_apply for individual-content point priority and purchase-based restriction resolution. The other three source-disabled switches are preserved. This supersedes older blanket settings-handoff statements in this document; onboarding, products, and financial actions remain separate boundaries. Localized provision editing is described below.

Human-reviewed point provisions

The policy read now also returns provisionsRevision and the four editable localized refund/usage field names. Use the existing channel_point_settings_apply with provisions instead of settings, dry-run the complete resulting text, and obtain human review before passing its contentHash as humanReviewedContentHash. Common/redemption policies and configuration remain unchanged. The writer validates the receipt and independent readback, with read-only point-provisions task recovery and no repeated uncertain POST. This supersedes older provision-editing handoff-only statements; actual-service mutation, same-screen captures and restoration are still unverified.

Existing charge-product changes

The products view now repeats its exact WEB page and returns productsRevision only for a valid source page. Use channel_point_product_apply to edit the source display name/bonus or selected product visibility. The method preserves price/base quantities and unrelated rows, refuses forced-visible hiding, checks independent readback, and never repeats an uncertain source request. Recovery uses point-products. The console address preserves the page/limit; edit opens the observed parent list modal entry. Initial product creation and deletion are not implemented here. This supersedes older existing-product handoff-only statements; actual mutation, restoration and original-console capture pairs remain pending.

WEB product creation dispatch continuation

The existing product apply method now supports one source-backed create POST with derived price/quantity inputs, durable sent state and observation-only sent recovery. HTTP acknowledgement, a fresh WEB first-page read and exact-created-ID proof are separate; no product identity is inferred and the result remains pending/action-required rather than claiming verified creation. See the creation dispatch contract. Existing product edits and saved jobs are preserved.