Selling Configuration Findings and Product Questions
The findings separate established implementation differences from unresolved product authority and proof gaps.
Findings
| id | severity | statement | affects | evidence | kind |
|---|---|---|---|---|---|
FND-COM-CAT-001 | high | Several implemented choices remain recommendations rather than Product decisions: normalized audience names, category dependencies, sample preview, invoice descriptions, card ranges, code characters, unlisted public sales, function registration, ineffective codes, performance definitions and remaining counts. Related console recommendations are also pending. Their originless rules inherit proposed intent until Product confirms them. | BR-CAP-COM-CAT-001-04, BR-CAP-COM-CAT-005-05, BR-CAP-COM-CAT-006-03, BR-CAP-COM-CAT-008-07, BR-CAP-COM-CAT-010-03, BR-CAP-COM-CAT-012-07, BR-CAP-COM-CAT-015-04, BR-CAP-COM-CAT-016-12, BR-CAP-COM-CAT-016-14, BR-CAP-COM-CAT-017-07, CAP-COM-CAT-018 | services-commerce:docs/milestones/COMM-M1-set-up-what-you-sell.md#Decisions (D-REC-1 to D-REC-18) | undocumented |
FND-COM-CAT-002 | high | Product’s later schedule-ownership ruling assigns periods to their owning event and removes standalone administration. The retained engine and API still have no owner and refuse ownership input. With the console editor and picker removed, existing scheduled products remain usable but staff cannot prepare new schedules there. | CAP-COM-CAT-011, BR-CAP-COM-CAT-011-01, BR-CAP-COM-CAT-011-09, BR-CAP-COM-CAT-012-05, OQ-COM-CAT-001 | services-commerce:docs/debt/pricing-schedules-owned-by-event.md; services-commerce:docs/milestones/COMM-M1-set-up-what-you-sell.md#Acceptance (2026-10-22) | inconsistency |
FND-COM-CAT-003 | medium | The approved plan assigns tax configuration to Accounting, whose console screens remain the editing surface. Commerce nevertheless calculates from its own interim zones by default. The proposed ownership realignment needs a decision before these two configurations can provide one reliable staff workflow. | CAP-COM-CAT-004, BR-CAP-COM-CAT-004-08, OQ-COM-CAT-002 | services-commerce:docs/milestones/plans/COMM-M1-plan.md#Excluded; services-commerce:modules/pricing/services/tax/commerce-tax-port.ts; react-console:lib/accounting-config/tax.ts | inconsistency |
FND-COM-CAT-004 | low | The shared policy resolution read handles explicit, application-default and workspace-default selection. Checkout supplies the broader store and selling-context steps. A read can therefore disagree with sale-time selection, whose full proof belongs to the orders module. | BR-CAP-COM-CAT-002-01, BR-CAP-COM-CAT-002-02, BR-CAP-COM-CAT-002-03 | services-commerce:modules/configuration/services/persistence/ordering-profiles.ts:resolveOrderingProfile; services-commerce:modules/checkout/services/checkout/ordering-profile-resolution.ts | inconsistency |
FND-COM-CAT-005 | medium | Cancellation release is retained per promotion and defaults from its first code. Mixed personal and shared codes inherit that one setting, so insertion order affects later code behaviour. Product needs to reconcile this implementation with the stated personal/shared defaults and per-promotion override. | BR-CAP-COM-CAT-015-11, OQ-COM-CAT-004 | services-commerce:modules/promotions/services/persistence/promotion-codes.ts:releaseDefaultApplies; services-commerce:docs/milestones/COMM-M1-set-up-what-you-sell.md#D13 | inconsistency |
FND-COM-CAT-006 | medium | The approved plan permits non-ASCII code characters, while later unconfirmed recommendations restrict the normalized alphabet to ASCII letters, digits, hyphen and underscore. Sharp-s therefore fails current validation, and existing incompatible codes remain without migration. | BR-CAP-COM-CAT-015-04, BR-CAP-COM-CAT-015-05 | services-commerce:docs/milestones/plans/COMM-M1-plan.md#4. Assumptions (A22); services-commerce:docs/milestones/COMM-M1-set-up-what-you-sell.md#D-REC-6, D-REC-12 | inconsistency |
FND-COM-CAT-007 | medium | The engine-plan preview deferral is stale: pinned implementation reads parts and criteria, including explicitly included automatic drafts. It still supplies no rated shipping charge, leaving parity with shipping checkout outcomes unproved. | CAP-COM-CAT-018, BR-CAP-COM-CAT-018-02 | services-commerce:modules/promotions/services/previews/promotion-previews.ts:includingPromotions; services-commerce:modules/promotions/services/checkout/checkout-candidates.ts:resolveCheckoutCandidates | inconsistency |
FND-COM-CAT-008 | low | Legacy promotion scope remains accepted without effect, and code-promotion eligibility has moved to codes. The obsolete columns and carrying code remain scheduled for later removal. | BR-CAP-COM-CAT-014-05 | services-commerce:docs/debt/promotion-scope-column.md | debt |
FND-COM-CAT-009 | low | Eleven configured permission keys have no route binding. These include unused bulk grants and selected purchasing-settings, product-extension and recommendation-rule create or delete grants. Role-editor visibility does not establish an executable operation for them. | CAP-COM-CAT-004, CAP-COM-CAT-010, CAP-COM-CAT-011, CAP-COM-CAT-012, CAP-COM-CAT-019 | services-commerce:aws/commerce.service.ts; the route declarations of the six modules | debt |
FND-COM-CAT-010 | low | The configuration entry point requires listing-read authority before opening merchandise. Subsequent item inspection also requests merchandise, product and listing reads, excluding a merchandise-only reader at entry. | CAP-COM-CAT-007, BR-CAP-COM-CAT-007-12 | react-console:components/configuration/area-route.tsx:merchandise; react-console:lib/commerce/merchandise/tests/permissions.test.ts | inconsistency |
FND-COM-CAT-011 | medium | The cited earlier acceptance inventory is absent from the pinned console commit, so its identifiers are not superseded here. Bound console evidence consists of unit and mock-browser tests; no pinned live browser proof establishes these module journeys. | MOD-COM-CAT, JNY-COM-CAT-001, JNY-COM-CAT-002, JNY-COM-CAT-003, JNY-COM-CAT-004, JNY-COM-CAT-005, JNY-COM-CAT-006 | services-commerce:docs/milestones/plans/COMM-M1-plan.md#9. Acceptance scenarios; services-commerce:docs/milestones/README.md | debt |
FND-COM-CAT-012 | medium | Member prices can be configured and previewed, but real membership qualification is deferred. Development fixtures supply eligibility answers and the audience screen withholds membership setup until the eligibility connection is enabled. | BR-CAP-COM-CAT-010-07, BR-CAP-COM-CAT-013-02 | services-commerce:docs/milestones/COMM-M1-set-up-what-you-sell.md#D1; services-commerce:docs/milestones/walkthroughs/COMM-M1-handoff.md#Gaps and deferrals | debt |
FND-COM-CAT-013 | medium | Recommendations have implementation and tests without an approved milestone plan or console screen. Membership-savings configuration is retained for later evaluation, and application-flow actions remain unavailable. | CAP-COM-CAT-019, CAP-COM-CAT-020, BR-CAP-COM-CAT-019-04 | services-commerce:docs/milestones/README.md#COMM-M7; services-commerce:modules/recommendations/tests/unit/rule-rules.spec.js#accepts a membership_savings rule’s parameters whole, for R1 to read | undocumented |
FND-COM-CAT-014 | low | Digital downloads are outside the accepted setup milestone and remain without confirming product records. Their grant ownership belongs to the orders module, so implemented download rules remain proposed. | CAP-COM-CAT-009 | services-commerce:docs/milestones/plans/COMM-M1-plan.md#Excluded | undocumented |
FND-COM-CAT-015 | low | Anonymous storefront, quote and offer routes exist while portal delivery is held. The approved public guards therefore describe API behaviour without establishing an available portal screen. | CAP-COM-CAT-008, JNY-COM-CAT-003 | services-commerce:docs/milestones/README.md#Storefront and member portal (held) | undocumented |
FND-COM-CAT-016 | low | Store extension references are saved without registered-handler validation. Staff can retain a typo and discover the missing handler only during later calculation. | BR-CAP-COM-CAT-003-10 | services-commerce:modules/configuration/services/persistence/stores.ts:storeColumns | defect |
FND-COM-CAT-017 | low | The console code normalizer removes hyphens that the service retains. A displayed normalized code can consequently differ from the identity the service looks up. | CAP-COM-CAT-015 | react-console:lib/commerce/promotions/rules.ts:codeNormalize; services-commerce:modules/promotions/services/persistence/promotion-codes.ts:normalizePromotionCode | inconsistency |
FND-COM-CAT-018 | medium | The revised promotions milestone remains in progress. Its parts, restriction and issuance implementation does not yet carry engineering verification or walkthrough acceptance, despite decision-backed intent for selected rules. | CAP-COM-CAT-014, CAP-COM-CAT-015, CAP-COM-CAT-016 | services-commerce:docs/milestones/COMM-M1b-promotions-and-codes.md | undocumented |
FND-COM-CAT-019 | low | The setup milestone record reports Product acceptance while the milestone index still reports earlier progress states. The record is the stronger status source, and the index needs reconciliation. | MOD-COM-CAT | services-commerce:docs/milestones/COMM-M1-set-up-what-you-sell.md; services-commerce:docs/milestones/README.md#Records | inconsistency |
FND-COM-CAT-020 | low | The handoff documents retained invoice-template and card-fee settings that are not delivered to Accounting. The invoice request has no template field, leaving those configuration choices partly ineffective. | CAP-COM-CAT-001 | services-commerce:docs/milestones/walkthroughs/COMM-M1-handoff.md#Gaps and deferrals | debt |
FND-COM-CAT-021 | medium | The recorded interim decision refuses order-pricing fees until invoicing supports their fee line. Preview and placement therefore return a refusal rather than silently omitting the fee. | BR-CAP-COM-CAT-013-10 | services-commerce:docs/milestones/COMM-M1-set-up-what-you-sell.md#D5-F1 | debt |
FND-COM-CAT-022 | low | Some must-prove claims rely on product records or cross-module code without direct bound proof here, including public purchasing of unlisted items and promotion names on invoice lines. The broader policy-selection proof also remains with checkout. | BR-CAP-COM-CAT-006-03, BR-CAP-COM-CAT-016-14 | the rule sources | debt |
FND-COM-CAT-023 | medium | The isolated engine accepts variant prices and modifiers, but the running product loader supplies empty variant and modifier collections. Ordinary quotes therefore do not prove the merchandise adjustment behaviour demonstrated by engine fixtures. | BR-CAP-COM-CAT-007-11, CAP-COM-CAT-013 | services-commerce:modules/pricing/services/persistence/catalog-products.ts:variants; services-commerce:modules/merchandise/services/persistence/merchandise-extensions.ts:readMerchandiseCatalog | defect |
| FND-COM-CAT-024 | medium | Offer expiry limits a first acceptance without freezing its displayed amount. A previous acceptance is returned before expiry checking. Changed-price and expired-repeat proof is needed before Product describes this as a price promise. | CAP-COM-CAT-020, BR-CAP-COM-CAT-020-03 | services-commerce:modules/recommendations/services/acceptance/accept-offer.ts:acceptOffer | inconsistency | | FND-COM-CAT-025 | low | The examination job’s named planning brief is absent from the supplied specification commit. Code and recorded decisions can be reviewed, but comparison with that original authoring brief remains unavailable. | MOD-COM-CAT | rhythm-v2-docs:briefs/planning/commerce-catalog.brief.md (absent at be389609fd82b86dcd0e38f2c42f53c93496f117) | undocumented | | FND-COM-CAT-026 | medium | Compound rules frequently have narrower bound examples than their complete wording. Added lock and cleanup rules, snapshot retention and offer-action branches need explicit proof before approval; source existence and ownership mapping alone are insufficient. | MOD-COM-CAT, BR-CAP-COM-CAT-001-14, BR-CAP-COM-CAT-001-16, BR-CAP-COM-CAT-003-13, BR-CAP-COM-CAT-005-10, BR-CAP-COM-CAT-006-13, BR-CAP-COM-CAT-007-14, BR-CAP-COM-CAT-010-12, BR-CAP-COM-CAT-011-11, BR-CAP-COM-CAT-006-14, BR-CAP-COM-CAT-020-11 | services-commerce:modules/configuration/services/persistence/ordering-profiles.ts:snapshotOf; services-commerce:modules/catalog/services/assets/catalog-assets.ts; services-commerce:modules/recommendations/services/acceptance/accept-offer.ts | debt | | FND-COM-CAT-027 | medium | Promotion-action acceptance applies the code before recording the interaction without joining both calls in an enclosing transaction. Failure of the later write can leave an applied code without an accepted-offer record. | CAP-COM-CAT-020 | services-commerce:modules/recommendations/services/acceptance/accept-offer.ts:acceptOffer | defect | | FND-COM-CAT-028 | low | The Platform standards each design mechanism follows (persistence, assets, queued work, indexing, row-level security, record history) sit in a repository this design job could not read. The design names the standard each mechanism follows from Commerce's own records, which cite them; conformance to the standards' text is unverified. | ADR-COM-CAT-004, ADR-COM-CAT-012, ADR-COM-CAT-013, ADR-COM-CAT-014, ADR-COM-CAT-015 | services-commerce:AGENTS.md#Naming and the Binding Rules (the standards are read from services-platform, never copied) | undocumented | | FND-COM-CAT-029 | medium | The console saves a merchandise item as three separate requests (the Accounting product, then the merchandise details, then the listing) and does not use the service's single-transaction path that writes the product and its extension together. A refusal after the first step leaves a product without details or a listing; nothing reverses the earlier writes, and the screen only reopens the half-made item. | WF-COM-CAT-005, WF-COM-CAT-006, SCR-COM-CAT-011, BR-CAP-COM-CAT-007-02, OQ-COM-CAT-006 | react-console:lib/commerce/merchandise/live.ts:createLiveMerchandiseAdapter; services-commerce:modules/merchandise/services/persistence/merchandise-products.ts | defect | | FND-COM-CAT-030 | low | A code generation request without an idempotency key is given a fresh batch identity, so a repeated click creates a second batch of codes rather than finding the first. | WF-COM-CAT-013, STATE-COM-CAT-009, BR-CAP-COM-CAT-015-12 | services-commerce:modules/promotions/services/issuance/issuance-request.ts:issuanceIdFor | defect | | FND-COM-CAT-031 | low | A limited download consumes one use per request key, and a request without a key uses its own request identity, so a client that retries without repeating its key spends another of the buyer's uses. | WF-COM-CAT-008, BR-CAP-COM-CAT-009-02 | services-commerce:modules/catalog/aws/api/storefront.routes.ts:downloadEntitledFile | inconsistency | | FND-COM-CAT-032 | high | The deployed quote, preview and placement paths are built with the fixture membership facts and the fixture extension handlers. Real membership standing therefore never reaches the eligibility evaluation, and a registered pricing function is answered by an in-process fixture rather than the customer's handler. The eligibility transport itself is real once Platform publishes it, which it now does. | WF-COM-CAT-009, WF-COM-CAT-010, ADR-COM-CAT-021, BR-CAP-COM-CAT-013-02, BR-CAP-COM-CAT-013-09, OQ-COM-CAT-007 | services-commerce:modules/pricing/services/checkout-pricing/price-checkout-with-engine.ts; services-commerce:modules/pricing/aws/api/price-quotes.routes.ts; services-commerce:aws/commerce.service-calls.ts:PLATFORM_SERVICE_FUNCTIONS_PUBLISHED | debt | | FND-COM-CAT-033 | medium | The realization of Accounting's special-price handovers is implemented and tested but nothing invokes it: no route, schedule, queue or job calls it, and its eligibility binding port is a fixture. Migrated special prices therefore stay as audiences nobody qualifies for until a caller exists. | WF-COM-CAT-011, STATE-COM-CAT-006, BR-CAP-COM-CAT-010-09 | services-commerce:modules/pricing/services/handovers/audience-handover-realization.ts:realizePricingAudienceHandovers | debt | | FND-COM-CAT-034 | low | A redemption declares a reversed status that no code path sets; counts and refusals treat it as already given back. Either a reversal flow is missing or the value is unused vocabulary. | STATE-COM-CAT-010, DOM-COM-CAT-005 | services-commerce:modules/promotions/db/promotion-redemptions.table.ts:REDEMPTION_STATUSES | debt | | FND-COM-CAT-035 | medium | A caller may set a record's protection level on create or replace. Once a record is fully locked, every later replacement is refused, so the full lock can never be removed through any route, and no screen shows or sets protection. Who may protect and unprotect configuration has not been decided. | ADR-COM-CAT-015, BR-CAP-COM-CAT-001-16, BR-CAP-COM-CAT-003-13, BR-CAP-COM-CAT-005-10, BR-CAP-COM-CAT-006-13, BR-CAP-COM-CAT-007-14, BR-CAP-COM-CAT-010-12, BR-CAP-COM-CAT-011-11, OQ-COM-CAT-008 | services-commerce:db/system-values.ts:clientSystemColumnsFromWire; services-commerce:modules/configuration/services/persistence/ordering-profiles.ts | undocumented | | FND-COM-CAT-036 | medium | Until Platform's extension tables exist, the extension references stored on stores and products are themselves the bindings. A reference no registered handler answers is refused under the closed failure policy, so one mistyped store reference makes every checkout preview and placement in that store fail as unavailable, not only the extension. | WF-COM-CAT-009, WF-COM-CAT-010, BR-CAP-COM-CAT-003-10, FND-COM-CAT-016 | services-commerce:modules/pricing/services/extensions/commerce-extensions.ts; services-commerce:modules/pricing/services/extensions/failure-policy.ts | defect | | FND-COM-CAT-037 | low | Only Commerce's own merchandise selling area is registered. The seam for other applications' areas is written but wired nowhere, so a promotion part can discount merchandise alone today. | WF-COM-CAT-020, BR-CAP-COM-CAT-014-03 | services-commerce:modules/promotions/services/areas/remote-provider.ts | undocumented | | FND-COM-CAT-038 | low | The unlisted Coupons area remains reachable by address and shows a fixed set of sample coupons from the console itself; no Commerce operation backs it, so its list and form neither read nor change anything real. | SCR-COM-CAT-023 | react-console:components/configuration/resources/accounting.tsx:couponResources; react-console:lib/configuration/areas.ts | inconsistency | | FND-COM-CAT-039 | low | The standalone price schedule list, view and editor components remain in the console but no route renders them since the ownership ruling; they are unreachable code that can drift from the retained API. | ADR-COM-CAT-017, BR-CAP-COM-CAT-011-09 | react-console:components/commerce/pricing-schedules/price-schedules-page.tsx; react-console:components/configuration/area-route.tsx | debt | | FND-COM-CAT-040 | medium | When Accounting cannot be reached, a checkout policy is saved with its default merchant account unchecked and the warning goes only to the service log; the person saving is not told the account was never verified. | WF-COM-CAT-001, BR-CAP-COM-CAT-001-03 | services-commerce:modules/configuration/services/persistence/ordering-profiles.ts; services-commerce:modules/configuration/tests/unit/persistence/ordering-profile-merchant-account.spec.js#is let through, logged, when Accounting is unreachable | inconsistency | | FND-COM-CAT-041 | low | Offer presentations are written on every live evaluation and kept without the monthly partitioning and thirteen-month retention the recommendations architecture calls for, which wait for a later release. | DOM-COM-CAT-006, WF-COM-CAT-017 | services-commerce:modules/recommendations/db/offer-presentations.table.ts | debt | | FND-COM-CAT-042 | low | The redemption release code still says nothing calls the cancellation release, but the cancellation workflow and the enforcement handler now do; the design follows the calls, not the comment. | WF-COM-CAT-015 | services-commerce:modules/promotions/services/redemptions/redemption-release.ts; services-commerce:modules/orders/services/cancellations/cancellation-workflow.ts | inconsistency | | FND-COM-CAT-043 | medium | Promotions keep their own append-only history, but checkout policies, stores, categories, listings, merchandise, audiences, schedules and recommendation rules keep only who last changed them and when. No Commerce record emits change events or uses Platform record history yet. | ADR-COM-CAT-014, DOM-COM-CAT-001, DOM-COM-CAT-002, DOM-COM-CAT-003, DOM-COM-CAT-004, DOM-COM-CAT-006 | services-commerce:AGENTS.md#Naming and the Binding Rules (change events and record history: none exists in Commerce yet); services-commerce:modules/promotions/services/persistence/promotions.ts | undocumented | | FND-COM-CAT-044 | low | The module asks no model: none of its services, workflows or screens calls the Platform LLM module or a provider, so it has no inference directory. The module charter does not yet say so in one sentence, as the conventions require; the charter is a planning artifact and needs that sentence added at its next revision. | MOD-COM-CAT | services-commerce:modules/{catalog,merchandise,pricing,promotions,configuration,recommendations} (no model call found); rhythm-v2-docs:specs/CONVENTIONS.md#9.8 Inference Operation (IOP) | undocumented |
| FND-COM-CAT-045 | high | Acceptance history is unique per offer, but the checkout action runs before the conflict-handling insert and the first acceptance lookup runs outside that action transaction. Different concurrent request keys may therefore perform the action more than once; sequential repeat tests do not prove concurrent safety. The design now limits its guarantee to repeated completed requests and unique history. | WF-COM-CAT-018, STATE-COM-CAT-012, DOM-COM-CAT-006, SVC-COM-CAT-recommendations, BR-CAP-COM-CAT-020-04 | services-commerce:modules/recommendations/services/acceptance/accept-offer.ts:acceptOffer; services-commerce:modules/recommendations/services/persistence/offer-interactions.ts:recordOfferInteraction; services-commerce:modules/checkout/db/checkout-items.table.ts | inconsistency | | FND-COM-CAT-046 | medium | The draft treated ownerless schedules as confirmed design even though the later recorded ruling assigns schedules to their selling owner. The decision now records the retained implementation as an unresolved gap and cites that ruling; deciding ownership again would contradict the planning layer. | ADR-COM-CAT-017, FND-COM-CAT-002, OQ-COM-CAT-001 | services-commerce:docs/debt/pricing-schedules-owned-by-event.md#Decision | inconsistency | | FND-COM-CAT-047 | low | Several screen contracts named generic patterns, confirmation prompts or actions absent from the built screens. The examination replaces these with actual components, removes the policy-view duplicate action, records its Make Default action, corrects immediate status and code actions, and identifies the full-width pricing, audience-view and code-list surfaces. | SCR-COM-CAT-002, SCR-COM-CAT-005, SCR-COM-CAT-006, SCR-COM-CAT-013, SCR-COM-CAT-015, SCR-COM-CAT-021, SCR-COM-CAT-022 | react-console:components/commerce/ordering-profiles/checkout-policy-view-screen.tsx; react-console:components/commerce/promotions/code-page.tsx; react-console:components/commerce/pricing/product-pricing-page.tsx | inconsistency | | FND-COM-CAT-048 | medium | The product Pricing screen admits Accounting product readers and gates price editing on Accounting product update authority. Its Commerce reads and purchasing-settings save still depend on their separate backend permissions; screen entry alone does not establish that all panels or saves are authorized. | SCR-COM-CAT-015, CAP-COM-CAT-012, CAP-COM-CAT-013 | react-console:components/commerce/pricing/product-pricing-page.tsx; react-console:lib/commerce/pricing/access.ts:priceEditing; services-commerce:modules/pricing/aws/api/product-purchasing-settings.routes.ts | inconsistency |
| FND-COM-CAT-049 | medium | Console audience ordering and promotion-with-code saves span independent requests. Rank failures can leave temporary or partially assigned ranks; first-code failure after creation attempts rename and archive, and failure during an edit retains the saved campaign changes. The draft omitted both workflows and incorrectly described the withdrawal branch as duplication. | WF-COM-CAT-021, WF-COM-CAT-022, WF-COM-CAT-020, SCR-COM-CAT-012, SCR-COM-CAT-017, SCR-COM-CAT-019 | react-console:lib/commerce/audiences/live.ts:createLivePricingAudiencesAdapter; react-console:lib/commerce/promotions/live.ts:createLivePromotionsAdapter | inconsistency | | FND-COM-CAT-050 | medium | The console offers Archive for every campaign status except archived, while the service permits archive only from draft or ended. The built lifecycle component exposes neither End nor Duplicate, so an active or paused campaign can be offered an archive request that the API refuses. Design now describes the actual controls instead of inventing an end-and-duplicate action. | SCR-COM-CAT-016, SCR-COM-CAT-018, SCR-COM-CAT-019, STATE-COM-CAT-007 | react-console:components/commerce/promotions/lifecycle-actions.tsx:PromotionLifecycleActions; services-commerce:modules/promotions/services/persistence/promotions.ts:PROMOTION_TRANSITIONS | inconsistency |
| FND-COM-CAT-051 | medium | A repeated code-generation request without a request key creates another batch; the interface does not require a stable key to prevent that second effect. | CAP-COM-CAT-015, WF-COM-CAT-013, SVC-COM-CAT-promotions | See control_backfill_evidence | control-gap | | FND-COM-CAT-052 | high | Offer acceptance checks for an earlier interaction before changing the cart; concurrent requests can both reach the change before the retained interaction resolves their identity. | CAP-COM-CAT-020, WF-COM-CAT-018, SVC-COM-CAT-recommendations | See control_backfill_evidence | control-gap | | FND-COM-CAT-053 | medium | Applying a promotion from an offer and recording acceptance do not share an enclosing transaction; a later recording failure leaves a changed cart without its accepted-offer result. | CAP-COM-CAT-020, WF-COM-CAT-018, SVC-COM-CAT-recommendations | See control_backfill_evidence | control-gap | | FND-COM-CAT-054 | medium | Public storefront, quote and offer evaluation retain an explicit rate-limiting exception; the declared public routes do not provide the requested operation-specific abuse limits. | CAP-COM-CAT-008, CAP-COM-CAT-013, CAP-COM-CAT-020, WF-COM-CAT-007, WF-COM-CAT-009, WF-COM-CAT-017, SVC-COM-CAT-catalog, SVC-COM-CAT-pricing, SVC-COM-CAT-recommendations | See control_backfill_evidence | control-gap |
Open Questions
| id | question | why_it_matters | options | recommendation | affects |
|---|---|---|---|---|---|
OQ-COM-CAT-001 | Which interim preparation surface should price schedules use before their owning application exists? | Removing standalone administration leaves dated configuration available only through retained APIs. | A: retain API-only preparation. B: restore temporary staff administration. C: implement owner-bound schedules now. | The product should retain API-only preparation under the ownership ruling and record the migration plan for ownerless schedules. | CAP-COM-CAT-011, FND-COM-CAT-002 |
OQ-COM-CAT-002 | Which area owns the authoritative tax configuration used by Commerce? | Staff edit one configuration while the default calculation reads another. | A: approve Commerce tax ownership and its editing surface. B: delegate to Accounting and retire duplicate zones. C: retain configurable dual providers. | The product should approve one ownership model and editing path; until realignment is approved, Accounting delegation is the coherent alternative. | CAP-COM-CAT-004, FND-COM-CAT-003 |
OQ-COM-CAT-003 | May public buyers purchase a directly linked unlisted item? | Visibility and sale-access expectations need an explicit common interpretation. | A: permit direct-link public sales. B: treat unlisted as unavailable publicly. C: require authentication. | The product should confirm direct-link purchase if unlisted remains a shareable offering; otherwise it should change the public guard explicitly. | CAP-COM-CAT-006, CAP-COM-CAT-013 |
OQ-COM-CAT-004 | Where should personal and shared cancellation-release defaults be retained? | The first code currently establishes one setting for every later claim on that promotion. | A: retain defaults per code. B: retain first-code promotion defaults. C: require an explicit promotion setting. | The product should select per-code defaults or explicitly endorse the mixed-code consequences of the promotion-level setting. | CAP-COM-CAT-015, CAP-COM-CAT-017, FND-COM-CAT-005 |
OQ-COM-CAT-005 | When should recommendations become approved product scope? | Available routes lack an approved milestone and staff administration surface. | A: plan and approve the feature. B: hold delivery pending its milestone. C: remove the implementation. | The product should prepare the milestone and review implemented rules before designing recommendation surfaces. | CAP-COM-CAT-019, CAP-COM-CAT-020, FND-COM-CAT-013 |
OQ-COM-CAT-006 | Should the console save a merchandise item in one request that writes the product, its details and its listing together? | Today a failure part-way leaves a half-made item that staff must finish by hand, although the service already writes the product and its extension atomically. | A: one service request for product, details and listing. B: keep three requests and let the screen resume the incomplete item. C: two requests, product with details atomically, then the listing. | The product should choose C now (the service path exists) and plan A when the listing joins the same request; B leaves the gap permanent. | WF-COM-CAT-005, FND-COM-CAT-029 |
OQ-COM-CAT-007 | May a deployed workspace price with fixture membership facts and fixture extension handlers? | Member prices and pricing functions look configured but cannot behave as configured while the fixtures answer. | A: refuse member-audience qualification and pricing functions until the real sources are wired. B: keep the fixtures and warn on every affected line. C: keep the fixtures silently until the sources are published. | The product should choose A for placement and B for quotes, so no sale binds a price the real rule never confirmed. | ADR-COM-CAT-021, FND-COM-CAT-032 |
OQ-COM-CAT-008 | Who may protect a configuration record from change or deletion, and who may lift that protection? | A full lock set through the API can never be lifted, and staff cannot see why a record refuses edits. | A: system and migration only, never staff. B: an administrator permission to set and lift it, shown on each screen. C: remove client-set protection entirely. | The product should choose A, and show the protection on screens, until a protection feature is planned. | ADR-COM-CAT-015, FND-COM-CAT-035 |