@mongoui/skills 0.1.7 → 0.1.8

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mongoui/skills",
-  "version": "0.1.7",
+  "version": "0.1.8",
   "description": "CLI for installing product skills into AI tools",
   "license": "MIT",
   "publishConfig": {

package/skills/glink-hotel-api/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: glink-hotel-api
-description: Integrate with the Glink hotel OpenAPI exposed through the Open Platform runtime gateway. Use when an AI coding assistant needs to read, verify, explain, test, or implement against `docs/swagger/glink-api.json` or Glink route code; choose Glink hotel endpoints; generate or debug `X-OP-*` signatures; explain sandbox or production credential issuance/reset; or handle Chinese/English requests about Glink 酒店 static data, hotel search, hotel info, product detail, booking, payment, order, cancel, order status push/callback, checkout, invoice, and balance workflows.
+description: Integrate with the Glink hotel OpenAPI exposed through the Open Platform runtime gateway. Use when Codex needs to read, verify, explain, test, or implement against `docs/swagger/glink-api.json` or Glink route code; choose Glink hotel endpoints; generate or debug `X-OP-*` signatures; explain sandbox or production credential issuance/reset; or drive Chinese/English requests about Glink hotel static data, hotel search, hotel info, product detail, booking, payment, order, cancel, order status push/callback, checkout, invoice, and balance workflows.
 ---
 
-# Glink Hotel API Skill
+# Glink OpenAPI Integration
 
 ## Quick Start
 
@@ -12,6 +12,8 @@ Use this skill when the task is "call Glink through the open platform".
 Start with the smallest current source that answers the request:
 
 - Prefer the repository source of truth when it exists: `docs/swagger/glink-api.json`, route handlers, DTOs, and tests.
+- Treat the current DHub shared document and `docs/swagger/glink-api.json` as the route source of truth; older bundled notes can be stale.
+- Customer-facing explanations should use only our short interface paths such as `/search/destination`, `/booking/createOrder`, and `/order/orderDetail`.
 - Read `references/auth-and-credentials.md` for signing, headers, key acquisition, reset, and auth troubleshooting.
 - Read `references/api-workflows.md` for hotel search, booking, cancel, checkout, invoice, and balance workflows.
 - Read `references/endpoint-index.md` for a compact endpoint map and platform-managed field caveats, then verify fragile fields against the current swagger or code.
@@ -23,53 +25,128 @@ Follow this workflow:
 
 1. Confirm the environment: `sandbox` and `production` credentials are separate.
 2. Confirm whether the user is asking for documentation, code changes, local smoke testing, or live API calls.
-3. Confirm the public path under `/openapi/v1/glink/*`.
-4. Build the minimum valid request body from swagger/code first, using `references/endpoint-index.md` as navigation.
-5. Sign the exact public path, sorted query string, and raw body bytes with the platform secret.
-6. Evaluate both HTTP status and response envelope `code`, not HTTP status alone.
-
-When the user asks for the Open Platform Glink hotel onboarding or booking flow, apply this required sequence:
-
-1. Static bootstrap: `queryCityList` -> `queryHotelIdList` by city -> `queryHotelInfo` for hotel/room static data, then persist mapping locally.
-2. Static maintenance: run `queryHotelIncrement`, then call `queryHotelInfo` for changed hotel IDs and update or disconnect local mappings when needed.
-3. List pricing: run `queryHotelLowestPrice` for mapped hotels, normally as a daily job after the Glink price refresh window, and use it as list-page display/reference data.
-4. Detail pricing: before `queryProductDetail`, check the local saleable hotel ID cache; skip hotels not in the saleable list. Use `bookType=1` products as bookable candidates.
-5. Booking: call `checkBooking` with the actual room count before entering or submitting the order flow; call it again before `createOrder` when the local order is ready.
-6. Payment and confirmation: after `createOrder`, call `payOrder` only after local customer payment succeeds or the platform has decided the Glink order should be confirmed.
-7. Confirmation result: treat Glink order operation push/callback as primary and idempotent; use `queryOrderDetail` only as low-frequency compensation before final confirmation or cancellation.
-8. Cancellation: call `cancelOrder` for unpaid timeout such as 30 minutes or customer cancellation. If the cancellation API returns success, update the local order and do not keep polling for another status push.
-
-Do not violate these rules:
+3. Confirm the interface path, for example `/search/destination` or `/booking/productDetails`.
+4. Choose the integration mode before recommending a flow:
+   - Standard API Integration: for partners who build and maintain a local saleable hotel catalog and room mapping.
+   - Lightweight Integration Flow: for faster launch with destination-driven hotel discovery and less pre-synced catalog data.
+5. Keep customer-facing docs and answers aligned to our short interface paths only, such as `/search/destination`, `/booking/productDetails`, and `/order/orderDetail`.
+6. For actual gateway signing/calls, the runtime public path is the short path prefixed with `/openapi/v1/glink`. Keep that detail in tooling/auth guidance, not in customer workflow names.
+7. Build the minimum valid request body from swagger/code first, using `references/endpoint-index.md` as navigation.
+8. Sign the exact runtime public path, sorted query string, and raw body bytes with the platform secret.
+9. Evaluate both HTTP status and response envelope `code`, not HTTP status alone.
+
+When the user asks for the Open Platform Glink hotel onboarding or booking flow, choose one of these two approved integration modes and use the mandatory interface sets below.
+
+## Standard API Integration
+
+Mandatory interfaces:
+
+| No. | Interface | Method | Path |
+| --- | --- | --- | --- |
+| 1 | Available Hotel ID List | POST | `/search/hotelIdList` |
+| 2 | Query Hotel Basic Information | POST | `/hotel/detail` |
+| 3 | Hotel Real-Time Product Query | POST | `/booking/productDetails` |
+| 4 | Trial Booking / Availability Check | POST | `/booking/availabilityCheck` |
+| 5 | Create Order | POST | `/booking/createOrder` |
+| 6 | Order Payment | POST | `/booking/payOrder` |
+| 7 | Cancel Order | POST | `/order/cancelOrder` |
+| 8 | Order Detail Query | POST | `/order/orderDetail` |
+
+Use this sequence by default:
+
+1. Static bootstrap: `/search/hotelIdList` -> `/hotel/detail` for hotel/room static data, then persist local hotel and room mappings.
+2. Optional foundational data: `/region/countries` and `/region/cities` can be used to build country/city mappings against the FCG hotel system.
+3. Static maintenance: run `/hotel/increment`, then call `/hotel/detail` for changed hotel IDs and update or disconnect local mappings when needed.
+4. List pricing: run `/hotel/lowestPrice` for mapped hotels as list-page display/reference data. The next 30 days of daily lowest prices are updated every day; recommend updating daily after 5:00 AM.
+5. Detail pricing: call `/booking/productDetails` in real time when the customer enters the hotel detail or booking path. Before querying, check the local saleable hotel ID cache and skip hotels not in the saleable list. Prefer `bookType=1` products as bookable candidates.
+6. Booking pre-check: when the user clicks Book, call `/booking/availabilityCheck` with the actual room count to confirm the product is bookable before entering the order form.
+7. Submit order: call `/booking/availabilityCheck` again immediately before `/booking/createOrder`; if still bookable, call `/booking/createOrder`.
+8. Payment and confirmation: after `/booking/createOrder`, call `/booking/payOrder` only after local customer payment succeeds or when the platform has decided the Glink order should be confirmed.
+9. Confirmation result: treat `/notify/orderStatus` as the primary confirmation channel and make the callback idempotent. Use `/order/orderDetail` only as low-frequency compensation if no confirmation result is received.
+10. Cancellation: call `/order/cancelOrder` for unpaid timeout such as 30 minutes or active customer cancellation. If the cancellation API returns success, update the local order and stop polling.
+
+## Lightweight Integration Flow
+
+Mandatory interfaces:
+
+| No. | Interface | Method | Path |
+| --- | --- | --- | --- |
+| 1 | Destination Query | POST | `/search/destination` |
+| 2 | Get Hotel Filter Conditions | POST | `/search/hotelFilters` |
+| 3 | Query Hotel List by Destination | POST | `/search/hotelList` |
+| 4 | Query Hotel Basic Information | POST | `/hotel/detail` |
+| 5 | Query Hotel Basic Information Increment | POST | `/hotel/increment` |
+| 6 | Query Hotel Images | POST | `/hotel/images` |
+| 7 | Hotel Real-Time Product Query | POST | `/booking/productDetails` |
+| 8 | Trial Booking / Availability Check | POST | `/booking/availabilityCheck` |
+| 9 | Create Order | POST | `/booking/createOrder` |
+| 10 | Order Payment | POST | `/booking/payOrder` |
+| 11 | Cancel Order | POST | `/order/cancelOrder` |
+| 12 | Order Detail Query | POST | `/order/orderDetail` |
+| 13 | Order Status Push | POST | `/notify/orderStatus` |
+
+Use this sequence by default:
+
+1. Destination bootstrap: call `/search/destination` to obtain the destination ID.
+2. Discovery: optionally call `/search/hotelFilters` for filter conditions, then call `/search/hotelList` with the destination ID to obtain matching hotels.
+3. Display hydration: call `/hotel/detail` for hotel static information and `/hotel/images` for images used by the client.
+4. Static maintenance: use `/hotel/increment` to discover changed hotel static information when local caching is used.
+5. List pricing: optionally call `/hotel/lowestPrice` as list-page price reference when the product experience needs a stable starting price.
+6. Detail pricing: call `/booking/productDetails` in real time when the customer enters the hotel detail or booking path. Prefer `bookType=1` products.
+7. Booking pre-check: when the user clicks Book, call `/booking/availabilityCheck` with the actual room count before entering the order form.
+8. Submit order: call `/booking/availabilityCheck` again immediately before `/booking/createOrder`; if still bookable, call `/booking/createOrder`.
+9. Payment and confirmation: after `/booking/createOrder`, call `/booking/payOrder` only after local customer payment succeeds or when the platform has decided the Glink order should be confirmed.
+10. Confirmation result: treat `/notify/orderStatus` as the primary confirmation channel and make the callback idempotent. Use `/order/orderDetail` only as low-frequency compensation if no confirmation result is received.
+11. Cancellation: call `/order/cancelOrder` for unpaid timeout such as 30 minutes or active customer cancellation. If the cancellation API returns success, update the local order and stop polling.
+
+## Mandatory Order Placement Flow
+
+Use these calls for order placement in both integration modes:
+
+1. `/hotel/lowestPrice`: Query the lowest price of mapped hotels as a reference for whether to display the hotel in the local hotel list.
+2. `/booking/productDetails`: Called in real time when a customer enters the hotel details or booking path.
+3. `/booking/availabilityCheck`: Validate whether a bookable product can be reserved, passing in the actual number of rooms to book.
+4. `/booking/createOrder`: Called after trial booking passes and the local order is successfully created. It is recommended to perform another trial booking validation before calling.
+5. `/booking/payOrder`: Called after the local customer pays successfully, or when the order needs confirmation, to notify FCG to process the order.
+6. `/order/cancelOrder`: Called when the order is unpaid for 30 minutes or the customer actively cancels. If the interface returns success, update the local order and stop polling.
+7. `/notify/orderStatus`: After payment notification, FCG processes the order and pushes the status. This callback must support idempotency.
+8. `/order/orderDetail`: If no confirmation result is received after payment, periodic queries can be used as compensation. Frequent polling is unnecessary; stop querying once the order is confirmed or canceled.
+
+## Do Not Violate
 
 - Always send `X-OP-App-Key`, `X-OP-Timestamp`, `X-OP-Nonce`, and `X-OP-Sign`.
-- Never send Glink-side `partnerCode`, `signature`, `requestType`, or Glink-side `timestamp`.
-- Never wrap the payload in Glink-style `header` or `businessRequest`; send only business fields.
+- Send only the business fields defined by our Open Platform swagger.
+- For adapter code, keep internal route configuration and customer-facing interface paths clearly separated.
 - Never invent credentials or secrets. Use explicit user-provided values or environment variables.
 - Treat `code=SUCCESS` as success. Treat `code=SUPPLIER_BIZ_ERROR` as a business failure even if HTTP status is `200`.
 - Keep timestamp skew within `+-5` minutes.
 - Reuse of the same nonce under the same app key can trigger `NONCE_REPLAY`.
-- If a swagger schema still shows Glink-managed fields as required, follow the route description first and omit those platform-managed downstream fields from the client payload.
+- If a swagger schema still shows Glink-managed fields as required, follow the route description first and omit those platform-managed internal fields from the client payload.
+- If external reference material and the current swagger/code use different names, use our current short interface path as the source of truth.
 - Do not frequently poll order status. Stop polling once the order is confirmed or canceled; rely on idempotent push/callback handling as the source of truth for confirmation progress.
 - Do not query real-time products for hotels outside the cached saleable hotel list; it wastes integration quota and usually returns no useful sellable data.
+- For Standard API Integration, recommend local saleable hotel cache maintenance. For Lightweight Integration Flow, recommend the smaller destination-driven flow unless the user explicitly needs full static catalog sync.
 
 ## Typical Requests
 
 Use these patterns by default:
 
-- Static data: city, country, district, business area, and brand lookup calls
-- Catalog sync: `queryCityList` -> `queryHotelIdList` -> `queryHotelInfo`; maintain with `queryHotelIncrement` -> `queryHotelInfo`
-- Search and booking: mapped saleable hotel IDs -> `queryHotelLowestPrice` for list display -> `queryProductDetail` for hotel detail -> `checkBooking` -> optional second `checkBooking` -> `createOrder` -> `payOrder` -> order push/callback primary, `queryOrderDetail` as compensation
-- Order aftercare: `cancelOrder`, Glink order push/callback, `queryOrderDetail`, `queryOrderCheckDetailInfo`, `checkoutApply`, `queryCheckoutDetail`
-- Finance: `createInvoice`, `queryCreditBalance`
+- Static data and filters: `/region/countries`, `/region/cities`, `/region/popularCities`, `/region/businesses`, `/region/districts`, `/region/pois`, and `/hotel/groupBrand`.
+- Standard catalog sync: `/search/hotelIdList` -> `/hotel/detail`; maintain with `/hotel/increment` -> `/hotel/detail`.
+- Lightweight discovery: `/search/destination` -> `/search/hotelFilters` -> `/search/hotelList` -> `/hotel/detail`/`/hotel/images` -> `/booking/productDetails`.
+- Search and booking: `/hotel/lowestPrice` for list display/reference -> `/booking/productDetails` for hotel detail -> `/booking/availabilityCheck` -> optional second `/booking/availabilityCheck` -> `/booking/createOrder` -> `/booking/payOrder` -> order push/callback primary, `/order/orderDetail` as compensation.
+- Order aftercare: `/order/cancelOrder`, order push/callback, `/order/orderDetail`, `/order/checkInDetail`, `/order/checkoutRequest`, `/order/checkoutDetail`.
+- Finance: `/order/invoiceRequest`, `/order/invoiceInfo`, `/search/creditBalance`.
 
 ## Output Expectations
 
 When answering or coding with this skill:
 
 - Prefer concrete request examples over abstract summaries.
-- Name the source used when the current swagger/code and bundled references disagree.
+- Name the source used when the current swagger/code and bundled references disagree, but keep customer-facing answers on our short interface paths.
+- State whether the recommendation follows Standard API Integration or Lightweight Integration Flow when giving onboarding advice.
 - State which environment the credential belongs to.
 - State whether the payload should contain only business fields.
 - Call out Glink-managed field residue in the swagger when relevant.
 - Call out auth failures with the likely root cause and the exact header or field to inspect.
-- For code changes, keep Glink downstream auth and platform gateway auth clearly separated.
+- For code changes, keep internal Glink integration auth and platform gateway auth clearly separated.

package/skills/glink-hotel-api/references/api-workflows.md

@@ -1,77 +1,124 @@
 # Glink API Workflows
 
-## Static Data
+Source of truth:
 
-Use these calls to build hotel search prerequisites:
+- Current Open Platform route and payload source: `docs/swagger/glink-api.json`.
+- Customer-facing explanations should use only our short interface paths, such as `/search/destination`, `/booking/createOrder`, and `/order/orderDetail`.
 
-- `glink.queryCountryList`
-- `glink.queryCityList`
-- `glink.queryHotCityList`
-- `glink.queryDistrictList`
-- `glink.queryDistrictAndBusiness`
-- `glink.queryBusinessList`
-- `glink.queryHotelPlateList`
-- `glink.queryCityAndHotelByKeyword`
+## Standard API Integration
 
-These APIs usually feed city selection, district filters, brand filters, and keyword suggestions.
+Use this mode when the integrator will maintain a local saleable hotel catalog, hotel-room mapping, and daily price refresh jobs.
 
-For the required Open Platform Glink onboarding flow, build local hotel and room mapping in this order:
+Mandatory interfaces:
 
-1. `glink.queryCityList`
-   - Get Glink city codes used by the platform hotel flow.
-2. `glink.queryHotelIdList`
-   - Use the city code to fetch the account's saleable hotel ID list and cache it locally.
-3. `glink.queryHotelInfo`
-   - Fetch hotel and room static data for the cached hotel IDs. Persist only the fields needed for local hotel and room mapping.
-4. `glink.queryHotelIncrement`
-   - Periodically fetch changed hotel IDs, including added, updated, or deleted hotels.
-5. `glink.queryHotelInfo`
-   - Rehydrate changed hotel IDs and decide whether local mappings should be updated or disconnected.
+| No. | Interface | Method | Path |
+| --- | --- | --- | --- |
+| 1 | Available Hotel ID List | POST | `/search/hotelIdList` |
+| 2 | Query Hotel Basic Information | POST | `/hotel/detail` |
+| 3 | Hotel Real-Time Product Query | POST | `/booking/productDetails` |
+| 4 | Trial Booking / Availability Check | POST | `/booking/availabilityCheck` |
+| 5 | Create Order | POST | `/booking/createOrder` |
+| 6 | Order Payment | POST | `/booking/payOrder` |
+| 7 | Cancel Order | POST | `/order/cancelOrder` |
+| 8 | Order Detail Query | POST | `/order/orderDetail` |
 
-## Hotel Search And Product Selection
+## Static Data
 
-Use this sequence for discovery and pricing:
+Use these calls to build hotel search prerequisites:
 
-1. `glink.getDestination` or `glink.queryCityAndHotelByKeyword`
-   - Resolve the destination or keyword to a city or hotel scope.
-2. `glink.getHotelSearch` or `glink.findHotelList`
-   - Search hotels using city, dates, room count, and optional filters.
-3. `glink.queryHotelLowestPrice`
-   - Pull summary pricing for selected hotel IDs.
-4. `glink.queryProductDetail`
-   - Read real-time sellable products for a selected hotel and stay range.
-5. `glink.queryHotelInfo`, `glink.queryHotelImage`, or `glink.queryHotelMainInfoByHotelIds`
-   - Hydrate hotel details for display or validation.
+- `/region/countries`
+- `/region/cities`
+- `/region/popularCities`
+- `/region/districts`
+- `/region/pois`
+- `/region/businesses`
+- `/hotel/groupBrand`
 
-Use `queryHotelAllList`, `queryHotelIdList`, and `queryHotelIncrement` when synchronizing hotel catalogs rather than serving live booking UX.
+These APIs usually feed country/city selection, district filters, POI filters, business area filters, and brand filters.
 
-For the Open Platform Glink flow, prefer the local mapped catalog over broad live search during booking:
+For Standard API Integration, build local hotel and room mapping in this order:
 
-- Use `glink.queryHotelLowestPrice` for mapped hotels to refresh daily starting prices. It is list-page reference/display data and should normally be refreshed once daily after the Glink price refresh window, for example after 05:00.
-- Before calling `glink.queryProductDetail`, verify that the hotel is still in the cached saleable hotel ID list. Do not query products for hotels outside the saleable list.
-- Use `glink.queryProductDetail` when the customer enters a hotel detail or booking path. Treat products with `bookType=1` as bookable candidates, then confirm with `checkBooking`.
+1. `/search/hotelIdList`
+   - Fetch the account's saleable hotel ID list and cache it locally.
+2. `/hotel/detail`
+   - Fetch hotel and room static data for the cached hotel IDs. Persist only the fields needed for local hotel and room mapping.
+3. `/hotel/increment`
+   - Periodically fetch changed hotel IDs, including added, updated, or deleted hotels.
+4. `/hotel/detail`
+   - Rehydrate changed hotel IDs and decide whether local mappings should be updated or disconnected.
+5. `/hotel/lowestPrice`
+   - Refresh mapped-hotel starting prices daily, normally after 05:00.
+
+## Lightweight Integration Flow
+
+Use this mode when the user wants a faster launch with less up-front static sync and a destination-driven hotel discovery path.
+
+Mandatory interfaces:
+
+| No. | Interface | Method | Path |
+| --- | --- | --- | --- |
+| 1 | Destination Query | POST | `/search/destination` |
+| 2 | Get Hotel Filter Conditions | POST | `/search/hotelFilters` |
+| 3 | Query Hotel List by Destination | POST | `/search/hotelList` |
+| 4 | Query Hotel Basic Information | POST | `/hotel/detail` |
+| 5 | Query Hotel Basic Information Increment | POST | `/hotel/increment` |
+| 6 | Query Hotel Images | POST | `/hotel/images` |
+| 7 | Hotel Real-Time Product Query | POST | `/booking/productDetails` |
+| 8 | Trial Booking / Availability Check | POST | `/booking/availabilityCheck` |
+| 9 | Create Order | POST | `/booking/createOrder` |
+| 10 | Order Payment | POST | `/booking/payOrder` |
+| 11 | Cancel Order | POST | `/order/cancelOrder` |
+| 12 | Order Detail Query | POST | `/order/orderDetail` |
+| 13 | Order Status Push | POST | `/notify/orderStatus` |
+
+Recommended sequence:
+
+1. `/search/destination`
+   - Resolve the destination keyword into an Open Platform destination ID.
+2. `/search/hotelFilters`
+   - Fetch filter conditions when the UI needs hotel filters.
+3. `/search/hotelList`
+   - Search destination-based hotel results using the destination ID, stay dates, and optional filters.
+4. `/hotel/detail` and optionally `/hotel/images`
+   - Read richer hotel details and media for client display after the hotel list returns candidates.
+5. `/hotel/lowestPrice`
+   - Optional but useful for list-page price reference when the experience needs a stable starting-price display.
+6. `/booking/productDetails`
+   - Query real-time sellable products for a selected hotel on the hotel detail or booking path.
+7. `/booking/availabilityCheck`
+   - Run trial booking with the actual room count before final booking.
+8. `/booking/createOrder`
+   - Create the order after trial booking succeeds. If the booking step is delayed, run `/booking/availabilityCheck` again first.
+9. `/booking/payOrder`
+   - Notify payment status after local payment succeeds or when the platform decides the order should be confirmed.
+
+Lightweight mode still benefits from small local caches:
+
+- Cache destination lookup results from `/search/destination` when the same searches are repeated often.
+- Keep the current hotel IDs from `/search/hotelList` or prior detail-page flows long enough to avoid wasteful duplicate quote traffic.
+- Treat order push/callback as primary even in lightweight mode.
 
 ## Booking Flow
 
-Use this sequence for a normal hotel booking flow:
+Use this sequence for both Standard API Integration and Lightweight Integration Flow:
 
-1. `glink.queryProductDetail`
+1. `/booking/productDetails`
    - Identify the exact sellable room and rate.
-2. `glink.checkBooking`
+2. `/booking/availabilityCheck`
    - Perform pre-booking validation with the actual room count. Use this before showing or entering the final order submission path.
-3. `glink.createOrder`
-   - Submit the order with guest, contact, amount, and price item details. When the local order has been created and is ready to submit, call `checkBooking` again first if there is any delay or state change risk.
-4. `glink.payOrder`
-   - Notify Glink after local customer payment succeeds, or after the platform has decided the Glink order should be confirmed.
-5. Glink order operation push/callback
+3. `/booking/createOrder`
+   - Submit the order with guest, contact, amount, and price item details. When the local order has been created and is ready to submit, call `/booking/availabilityCheck` again first if there is any delay or state change risk.
+4. `/booking/payOrder`
+   - Notify payment after local customer payment succeeds, or after the platform has decided the order should be confirmed.
+5. `/notify/orderStatus`
    - Treat the push/callback as the primary confirmation result channel. The receiver must be idempotent.
-6. `glink.queryOrderDetail`
+6. `/order/orderDetail`
    - Use as low-frequency compensation only before final confirmation or cancellation. Do not keep polling confirmed or canceled orders.
 
 Key order identifiers:
 
-- `coOrderCode`: your platform-side order number
-- `fcOrderCode`: Glink-side order number when available
+- `coOrderCode`: customer platform order number.
+- `fcOrderCode`: FCG order number when available.
 
 Prefer carrying both once they appear, because several aftercare APIs accept one or both.
 
@@ -79,32 +126,33 @@ Prefer carrying both once they appear, because several aftercare APIs accept one
 
 Use these calls after booking:
 
-- `glink.cancelOrder`
+- `/order/cancelOrder`
   - Cancel an order when policy permits, when the customer asks to cancel, or when the local unpaid timeout is reached, such as 30 minutes. If cancellation returns success, update the local order and do not continue polling for another push.
-- Glink order operation push/callback
-  - This is required for order confirmation progress after `payOrder`. It may not appear as a public `/openapi/v1/glink/*` request route in swagger because it is an inbound callback capability; inspect platform callback route code before implementing.
-- `glink.queryOrderCheckDetailInfo`
+- `/notify/orderStatus`
+  - Required for order confirmation progress after `/booking/payOrder`; implement idempotency.
+- `/order/checkInDetail`
   - Read extended order or check-in related detail.
-- `glink.checkoutApply`
+- `/order/checkoutRequest`
   - Submit a checkout or refund-like aftercare request for an order.
-- `glink.queryCheckoutDetail`
+- `/order/checkoutDetail`
   - Query the checkout task by `taskOrderCode`.
 
 ## Finance
 
 Use these calls for financial follow-up:
 
-- `glink.createInvoice`
+- `/order/invoiceRequest`
   - Submit invoice information using business fields only.
-  - Ignore Glink-managed `partnerCode` and `sign` even if they appear in the swagger schema.
-- `glink.queryCreditBalance`
+- `/order/invoiceInfo`
+  - Query invoice status and invoice metadata after an invoice request.
+- `/search/creditBalance`
   - Read remaining credit balance.
 
 ## Business Handling Rules
 
 - Do not treat HTTP `200` as enough; inspect `code`.
-- Do not rebuild Glink headers or wrapper payloads; the runtime gateway handles downstream authentication and wrapping.
-- Preserve Glink order identifiers from earlier responses instead of recomputing them.
+- Use only our short interface paths in customer-facing docs and workflows.
+- Preserve FCG order identifiers from earlier responses instead of recomputing them.
 - Keep local saleable hotel ID cache and hotel/room mappings current before pricing and booking.
-- Avoid integration quota waste: skip `queryProductDetail` for hotels not in the saleable hotel cache.
-- Push/callback is primary for order confirmation; `queryOrderDetail` is only a compensation path and should not be frequent.
+- Avoid integration quota waste: skip `/booking/productDetails` for hotels not in the saleable hotel cache.
+- Push/callback is primary for order confirmation; `/order/orderDetail` is only a compensation path and should not be frequent.

package/skills/glink-hotel-api/references/auth-and-credentials.md

@@ -34,7 +34,7 @@ APP_KEY
 Rules:
 
 - Uppercase `METHOD`.
-- Use the exact public request path, for example `/openapi/v1/glink/queryBusinessList`.
+- Use the exact runtime public request path. Customer-facing docs use short paths like `/region/businesses`; for actual signing, prefix with `/openapi/v1/glink`, for example `/openapi/v1/glink/region/businesses`.
 - Sort query parameters by key and then value before joining them as `k=v&k2=v2`.
 - Hash the raw request body bytes with SHA256 and use the lowercase hex digest.
 - Use the request timestamp exactly as sent in `X-OP-Timestamp`.
@@ -49,28 +49,15 @@ Notes:
 - Nonce must be unique for the same app key in a short time window.
 - For empty bodies, hash the empty byte string.
 
-## Platform Wrapping Rules
-
-Glink downstream authentication is handled by the runtime gateway.
+## Request Body Rules
 
 Client responsibilities:
 
-- Send only business fields.
-- Sign the public open-platform request.
-
-Do not send:
-
-- `partnerCode`
-- `signature` or `sign` used by Glink downstream auth
-- `requestType`
-- Glink-side `timestamp`
-- wrapper objects like `header` or `businessRequest`
-
-Important exception handling:
+- Send only the business fields shown by our Open Platform swagger.
+- Sign the runtime public request path, not only the short interface path.
+- Do not add wrapper objects or hidden integration fields that are not part of our public schema.
 
-- `createInvoice` currently still exposes `partnerCode` and `sign` in schema examples and required lists.
-- The route description still says the platform fills those fields automatically.
-- Prefer the route description and treat those fields as platform-managed downstream fields.
+If a legacy schema still exposes an internal managed field, prefer the route description and current swagger examples. Do not ask the customer to send fields that are not part of the Open Platform public contract.
 
 ## Credential Acquisition
 
@@ -94,7 +81,7 @@ Important constraints:
 
 - Sandbox and production credentials are separate and not interchangeable.
 - Developers can see platform credentials only.
-- Developers cannot see Glink downstream secrets.
+- Developers cannot see internal integration secrets.
 
 ## How To View Or Reset Keys
 
@@ -110,10 +97,10 @@ Developer portal APIs:
 
 Response fields that matter:
 
-- `open_app_id`: the App Key to place into `X-OP-App-Key`
-- `open_secret_masked`: masked secret for display only
-- `open_secret_version`: useful for rotation tracking
-- `plain_open_secret`: returned only on first issuance or reset
+- `open_app_id`: the App Key to place into `X-OP-App-Key`.
+- `open_secret_masked`: masked secret for display only.
+- `open_secret_version`: useful for rotation tracking.
+- `plain_open_secret`: returned only on first issuance or reset.
 
 Practical guidance:
 
@@ -142,7 +129,7 @@ The platform wraps business responses in a common envelope:
 {
   "request_id": "req_xxx",
   "trace_id": "trc_xxx",
-  "downstream_request_id": "optional",
+  "downstream_request_id": "dreq_xxx",
   "code": "SUCCESS",
   "message": "ok",
   "data": {}
@@ -152,6 +139,6 @@ The platform wraps business responses in a common envelope:
 Interpretation:
 
 - `request_id` and `trace_id` are platform-side tracing keys.
-- `downstream_request_id` is the Glink request identifier when available.
+- `downstream_request_id` is a platform response field used for cross-system tracing when available.
 - `code=SUCCESS` means the business call succeeded.
-- `code=SUPPLIER_BIZ_ERROR` means Glink returned a business error and can still arrive with HTTP `200`.
+- `code=SUPPLIER_BIZ_ERROR` means the business call failed after reaching the hotel integration and can still arrive with HTTP `200`.

package/skills/glink-hotel-api/references/endpoint-index.md

@@ -1,129 +1,128 @@
 # Glink Endpoint Index
 
-All routes are public gateway routes. Sign the public path, not the downstream Glink path.
-
-## Static Data
-
-- `glink.queryBusinessList`
-  - `POST /openapi/v1/glink/queryBusinessList`
-  - Required body fields: `cityCode`
-- `glink.queryCountryList`
-  - `POST /openapi/v1/glink/queryCountryList`
-  - Required body fields: none
-- `glink.queryHotelPlateList`
-  - `POST /openapi/v1/glink/queryHotelPlateList`
-  - Required body fields: none
-- `glink.queryHotCityList`
-  - `POST /openapi/v1/glink/queryHotCityList`
-  - Required body fields: none
-- `glink.queryDistrictList`
-  - `POST /openapi/v1/glink/queryDistrictList`
-  - Required body fields: `cityCode`
-- `glink.queryDistrictAndBusiness`
-  - `POST /openapi/v1/glink/queryDistrictAndBusiness`
-  - Required body fields: `cityCode`
-- `glink.queryCityList`
-  - `POST /openapi/v1/glink/queryCityList`
-  - Required body fields: `countryCode`
-
-## Hotel Query
-
-- `glink.queryCityAndHotelByKeyword`
-  - `POST /openapi/v1/glink/queryCityAndHotelByKeyword`
-  - Required body fields: `keyWord`
-- `glink.getDestination`
-  - `POST /openapi/v1/glink/getDestination`
-  - Required body fields: `keyWord`
-  - Swagger example uses `keyword`; double-check the field naming against current backend behavior before coding around it.
-- `glink.getHotelSearch`
-  - `POST /openapi/v1/glink/getHotelSearch`
-  - Required body fields: none
-  - Common fields: `cityCode`, `checkInDate`, `checkOutDate`, `roomNum`, `language`
-- `glink.findHotelList`
-  - `POST /openapi/v1/glink/findHotelList`
-  - Required body fields from schema: `roomFacilityCodes`, `hotelFacilityCodes`, `checkInDate`, `checkOutDate`, `distance`
-  - Treat this as a high-friction route and inspect the real example payload before implementing.
-- `glink.queryHotelAllList`
-  - `POST /openapi/v1/glink/queryHotelAllList`
-  - Required body fields: none
+Source of truth: current DHub / `docs/swagger/glink-api.json`.
+
+All routes below are customer-facing short interface paths. For actual gateway calls and signing, prefix them with `/openapi/v1/glink`.
+
+Customer-facing explanations should use only short interface paths such as `/search/destination`.
+
+Integration mode shortcuts:
+
+- Standard API Integration: prefer `/search/hotelIdList` -> `/hotel/detail` -> `/hotel/increment` and maintain local saleable hotel mappings.
+- Lightweight Integration Flow: prefer `/search/destination` -> `/search/hotelFilters` -> `/search/hotelList` -> `/hotel/detail`/`/hotel/images` -> `/booking/productDetails` for faster launch.
+
+## Region Static Data
+
+- `/region/countries`
+  - Method: `POST`
+  - Required body fields: none.
+- `/region/cities`
+  - Method: `POST`
+  - Common body fields: `countryCode`, `language`, `dataType`.
+- `/region/popularCities`
+  - Method: `POST`
+  - Required body fields: none.
+- `/region/businesses`
+  - Method: `POST`
+  - Common body fields: `cityCode`, `language`.
+- `/region/districts`
+  - Method: `POST`
+  - Common body fields: `cityCode`, `language`.
+- `/region/pois`
+  - Method: `POST`
+  - Common body fields: `cityCode`, `keyword`, `language`.
 
 ## Hotel Info
 
-- `glink.queryHotelIdList`
-  - `POST /openapi/v1/glink/queryHotelIdList`
-  - Required body fields: none
-  - The Open Platform Glink onboarding flow commonly uses `cityCode` to fetch the account's saleable hotel IDs for that city; verify the current swagger/code example before generating strict DTOs.
-- `glink.queryHotelInfo`
-  - `POST /openapi/v1/glink/queryHotelInfo`
-  - Required body fields: `hotelIds`
-- `glink.queryHotelIncrement`
-  - `POST /openapi/v1/glink/queryHotelIncrement`
-  - Required body fields: `startTime`, `endTime`
-  - Swagger example uses `lastUpdateTime`; inspect schema versus example before generating code.
-- `glink.queryHotelImage`
-  - `POST /openapi/v1/glink/queryHotelImage`
-  - Required body fields: `hotelIds`
-  - Swagger example uses `hotelId`; inspect schema versus example before generating code.
-- `glink.queryHotelMainInfoByHotelIds`
-  - `POST /openapi/v1/glink/queryHotelMainInfoByHotelIds`
-  - Required body fields: `language`
-
-## Product Info
-
-- `glink.queryHotelLowestPrice`
-  - `POST /openapi/v1/glink/queryHotelLowestPrice`
-  - Required body fields: `hotelIds`
-- `glink.queryProductDetail`
-  - `POST /openapi/v1/glink/queryProductDetail`
-  - Required body fields: `hotelId`, `checkInDate`, `checkOutDate`, `roomNum`
+- `/search/hotelIdList`
+  - Method: `POST`
+  - Common body fields: `cityCode`.
+  - Use for saleable hotel ID bootstrap and cache refresh.
+- `/hotel/detail`
+  - Method: `POST`
+  - Required body fields: `hotelIds`.
+- `/hotel/increment`
+  - Method: `POST`
+  - Common body fields: `startTime`, `endTime`, `maxId`, `pageSize`.
+- `/hotel/lowestPrice`
+  - Method: `POST`
+  - Common body fields: `hotelIds`, `checkInDate`, `checkOutDate`, `checkInType`.
+- `/hotel/images`
+  - Method: `POST`
+  - Common body fields: `hotelIds` or `hotelId`; verify the current swagger example before strict DTO generation.
+- `/hotel/groupBrand`
+  - Method: `POST`
+  - Required body fields: none.
+
+## Search And Booking
+
+- `/search/destination`
+  - Method: `POST`
+  - Common body fields: `keyWord`, `cityCode`, `destinationType`, `source`.
+- `/search/hotelFilters`
+  - Method: `POST`
+  - Common body fields: `destinationId`, `destinationType`, `language`, `lngGoogle`, `latGoogle`, `lngBaidu`, `latBaidu`, `dataType`, `distance`.
+- `/search/hotelList`
+  - Method: `POST`
+  - Common body fields: `destinationId`, `destinationType`, `lngGoogle`, `latGoogle`, `lngBaidu`, `latBaidu`, `checkInDate`, `checkOutDate`, filters.
+- `/booking/productDetails`
+  - Method: `POST`
+  - Required body fields: `hotelId`, `checkInDate`, `checkOutDate`, `roomNum`, `numberOfAdults`.
+- `/booking/availabilityCheck`
+  - Method: `POST`
+  - Required body fields: `hotelId`, `roomId`, `ratePlanId`, `checkInDate`, `checkOutDate`, `roomNum`, `supplyCode`.
+- `/booking/createOrder`
+  - Method: `POST`
+  - Required body fields: `hotelId`, `roomId`, `ratePlanId`, `checkInDate`, `checkOutDate`, `roomNum`, `supplyCode`, `totalAmount`, `coOrderCode`, `priceItems`, `guestInfos`, `linkMan`, `linkPhone`, `arriveTime`, `latestArriveTime`.
+- `/booking/payOrder`
+  - Method: `POST`
+  - Common body fields: `coOrderCode`, `fcOrderCode`.
+- `/search/creditBalance`
+  - Method: `POST`
+  - Required body fields: none; send `{}` or omit body according to the SDK/runtime caller.
 
 ## Order Info
 
-- `glink.checkBooking`
-  - `POST /openapi/v1/glink/checkBooking`
-  - Required body fields: `hotelId`, `checkInDate`, `checkOutDate`, `roomId`, `ratePlanId`, `roomNum`, `supplyCode`
-- `glink.createOrder`
-  - `POST /openapi/v1/glink/createOrder`
-  - Required body fields: `hotelId`, `checkInDate`, `checkOutDate`, `roomId`, `ratePlanId`, `roomNum`, `supplyCode`, `totalAmount`, `coOrderCode`, `priceItems`, `guestInfos`, `linkMan`, `linkPhone`, `arriveTime`, `latestArriveTime`
-- `glink.payOrder`
-  - `POST /openapi/v1/glink/payOrder`
-  - Required body fields: none
-  - Common fields: `coOrderCode`, `fcOrderCode`
-- `glink.cancelOrder`
-  - `POST /openapi/v1/glink/cancelOrder`
-  - Required body fields: none
-  - Common fields: `coOrderCode`, `fcOrderCode`, `cancelReson`
-- `glink.queryOrderDetail`
-  - `POST /openapi/v1/glink/queryOrderDetail`
-  - Required body fields: none
-  - Common fields: `coOrderCode`, `fcOrderCode`
-- Glink order operation push/callback
-  - Required by the Open Platform Glink booking flow after `payOrder`.
-  - This is an inbound callback capability rather than a normal public `/openapi/v1/glink/*` request route in the current endpoint list. Before implementing, inspect route code or product requirements for the platform callback URL, signature/auth expectations, idempotency key, and retry handling.
-- `glink.queryOrderCheckDetailInfo`
-  - `POST /openapi/v1/glink/queryOrderCheckDetailInfo`
-  - Required body fields: none
-  - Common fields: `coOrderCode`, `fcOrderCode`
-- `glink.checkoutApply`
-  - `POST /openapi/v1/glink/checkoutApply`
-  - Required body fields: `fcOrderCode`, `checkoutReason`, `checkoutRoomInfoList`
-- `glink.queryCheckoutDetail`
-  - `POST /openapi/v1/glink/queryCheckoutDetail`
-  - Required body fields: `taskOrderCode`
-  - Swagger example uses order codes instead of `taskOrderCode`; inspect the live contract before coding.
-
-## Finance
-
-- `glink.createInvoice`
-  - `POST /openapi/v1/glink/createInvoice`
-  - Business-required fields to focus on: `orderCode`, `invoiceTypeInteger`, `invoiceHeader`, `amount`, `applyId`, `invoiceTitleType`, `getMethod`
-  - Schema still marks `partnerCode` and `sign` as required, but route docs say the platform injects Glink auth fields. Do not send Glink-managed fields from the client.
-- `glink.queryCreditBalance`
-  - `POST /openapi/v1/glink/queryCreditBalance`
-  - Required body fields: none
+- `/order/orderDetail`
+  - Method: `POST`
+  - Common body fields: `coOrderCode`, `fcOrderCode`.
+- `/order/cancelOrder`
+  - Method: `POST`
+  - Common body fields: `coOrderCode`, `fcOrderCode`, `cancelReson`.
+- `/order/checkInDetail`
+  - Method: `POST`
+  - Common body fields: `coOrderCode`, `fcOrderCode`.
+- `/order/invoiceRequest`
+  - Method: `POST`
+  - Business fields to focus on: `orderCode`, `invoiceTypeInteger`, `invoiceHeader`, `amount`, `applyId`, `invoiceTitleType`, `getMethod`.
+- `/order/invoiceInfo`
+  - Method: `POST`
+  - Common body fields: `coOrderCode` or `fcOrderCode`.
+- `/order/checkoutRequest`
+  - Method: `POST`
+  - Required body fields: `fcOrderCode`, `supplierRefundNumber`, `checkoutReason`, `refundType`, `checkoutRooms`.
+- `/order/checkoutDetail`
+  - Method: `POST`
+  - Common body fields: `taskOrderCode`, `coOrderCode`, `fcOrderCode`; verify current swagger example before strict DTO generation.
+
+## Callback Capabilities
+
+- `/notify/orderStatus`
+  - Method: `POST`
+  - Order status push/callback. The receiver must be idempotent.
+- `/notify/orderOperate`
+  - Method: `POST`
+  - Order operation push/callback. The receiver must be idempotent.
+- `/notify/orderCheckout`
+  - Method: `POST`
+  - Checkout status push/callback. The receiver must be idempotent.
+- `/notify/orderInvoice`
+  - Method: `POST`
+  - Invoice status push/callback. The receiver must be idempotent.
 
 ## Global Notes
 
+- Current Glink swagger route count may include outbound request APIs and callback APIs; verify against `docs/swagger/glink-api.json`.
 - Most Glink routes accept plain business JSON bodies with no wrapper objects.
 - Platform error responses can return `401`, `403`, `404`, `500`, `502`, or `504`.
 - Common auth-related `401` codes are `APP_KEY_INVALID`, `SIGN_ERROR`, `TIMESTAMP_EXPIRED`, and `NONCE_REPLAY`.

package/skills/glink-hotel-api/scripts/glink_signed_request.py

@@ -4,14 +4,14 @@
 Examples:
   python scripts/glink_signed_request.py ^
     --method POST ^
-    --path /openapi/v1/glink/queryBusinessList ^
+    --path /region/businesses ^
     --body-json "{\"language\":\"zh-CN\",\"cityCode\":\"1\"}" ^
     --app-key open_app_xxx ^
     --app-secret sk_xxx
 
   python scripts/glink_signed_request.py ^
     --method POST ^
-    --path /openapi/v1/glink/queryCreditBalance ^
+    --path /search/creditBalance ^
     --body-json "{}" ^
     --app-key open_app_xxx ^
     --app-secret sk_xxx ^
@@ -32,11 +32,21 @@ import urllib.request
 import uuid
 from pathlib import Path
 
+GATEWAY_PREFIX = "/openapi/v1/glink"
+
 
 def sha256_hex(data: bytes) -> str:
     return hashlib.sha256(data).hexdigest()
 
 
+def normalize_path(path: str) -> str:
+    if not path.startswith("/"):
+        path = f"/{path}"
+    if path == GATEWAY_PREFIX or path.startswith(f"{GATEWAY_PREFIX}/"):
+        return path
+    return f"{GATEWAY_PREFIX}{path}"
+
+
 def parse_query_items(items: list[str]) -> list[tuple[str, str]]:
     pairs: list[tuple[str, str]] = []
     for item in items:
@@ -124,7 +134,7 @@ def main() -> int:
     parser = argparse.ArgumentParser(description="Generate or send a signed Glink open-platform request.")
     parser.add_argument("--base-url", default=os.getenv("OPEN_PLATFORM_BASE_URL", "http://127.0.0.1:8671"))
     parser.add_argument("--method", required=True)
-    parser.add_argument("--path", required=True)
+    parser.add_argument("--path", required=True, help="Short interface path, such as /search/destination; full gateway paths are also accepted")
     parser.add_argument("--query", action="append", default=[], help="Repeatable key=value query parameter")
     parser.add_argument("--body-json", help="JSON string request body")
     parser.add_argument("--body-file", help="Path to a raw request body file")
@@ -143,6 +153,7 @@ def main() -> int:
     try:
         query_pairs = parse_query_items(args.query)
         body_bytes = load_body(args)
+        runtime_path = normalize_path(args.path)
     except Exception as exc:
         print(str(exc), file=sys.stderr)
         return 2
@@ -150,7 +161,7 @@ def main() -> int:
     query_string = canonical_query(query_pairs)
     payload = build_sign_payload(
         method=args.method,
-        path=args.path,
+        path=runtime_path,
         query_string=query_string,
         body_bytes=body_bytes,
         timestamp=args.timestamp,
@@ -159,7 +170,7 @@ def main() -> int:
     )
     signature = sign(args.app_secret, payload)
     headers = build_headers(args.app_key, args.timestamp, args.nonce, signature, bool(body_bytes))
-    url = build_url(args.base_url, args.path, query_string)
+    url = build_url(args.base_url, runtime_path, query_string)
 
     print("URL:")
     print(url)