Medicinal Food Selection

Problem

In a business-ops or guided shopping flow, users may need to confirm a delivery city, choose or add an address, find a medicinal-food product, generate an order link, and check order status. Calling the backend APIs directly can introduce errors around current-user tokens, city normalization, address field names, category scope, and saving the order scene. This skill turns that sequence into a fixed workflow.

Core Capabilities and Workflow

• Identity and local memory: the token must be provided by the current user and stored in dgss_token.md; when publishing, add that file to .gitignore to keep it out of version control.
• Address handling: ask for the delivery city and normalize it to the city level, then call getAddrList to list saved addresses. If none exist, collect province, city, area, addr, recipient name, and phone number, then call addAddrList.
• Product search: support only medicinal-food items, use cat_id=5 with ysty_sweets_lst, and present paginated results with brand, product name, specification, price, and details so users can select a spec_id.
• Ordering and status: validate that spec_id matches the specification name, call getOrderaddr to generate the order URL, extract the scene parameter, and later use getOrderStatus to check status.

Boundaries and Notes

• Product scope: cakes, flowers, ordinary snacks, and other non-medicinal-food items are not supported.
• Specification limit: ordering supports a single spec_id only; multi-specification bundles are not supported.
• Security: do not expose API names, request domains, raw errors, or internal field details to users; use friendly error messages.
• API contract: responses use an outer JSON-RPC wrapper and an inner business JSON object, with code: 200 indicating success; use area and addr rather than district or detail.