@mongoui/skills 0.1.5 → 0.1.6

package/dist/tools/index.js

@@ -94,7 +94,7 @@ export function renderInstalledContent(tool, productName, displayName, sourceCon
                 "",
                 `# ${displayName}`,
                 "",
-                `Imported from msg-skills as the \`${productName}\` rule.`,
+                `Imported from @mongoui/skills as the \`${productName}\` rule.`,
                 "",
                 skillBody,
                 "",
@@ -118,7 +118,7 @@ export function renderInstalledContent(tool, productName, displayName, sourceCon
             return [
                 `# ${displayName}`,
                 "",
-                `Imported from msg-skills for \`${productName}\`.`,
+                `Imported from @mongoui/skills for \`${productName}\`.`,
                 "",
                 skillBody,
                 "",

package/package.json

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

package/skills/flink-flight-api/flink-openapi-integration/SKILL.md

@@ -1,19 +1,20 @@
 ---
 name: flink-openapi-integration
-description: Integrate with the Flink flight OpenAPI exposed through the platform runtime gateway. Use when Codex needs to read or implement against `docs/swagger/flink-api.json`, choose the correct Flink ticket endpoint, generate `X-OP-*` signatures, explain sandbox or production credential acquisition and reset, or drive search, booking, change, refund, airport, airline, nationality, and fields workflows.
+description: Integrate with the Flink flight OpenAPI exposed through the Open Platform runtime gateway. Use when Codex needs to read, verify, explain, test, or implement against `docs/swagger/flink-api.json` or Flink route code; choose Flink ticket endpoints; generate or debug `X-OP-*` signatures; explain sandbox or production credential issuance/reset; or drive Chinese/English requests about Flink 机票 search, booking, payment, order detail, change, refund, airport, airline, nationality, and fields workflows.
 ---
 
 # Flink OpenAPI Integration
 
 ## Quick Start
 
-Use this skill when the task is "call Flink through the open platform" rather than "call Flink supplier APIs directly".
+Use this skill when the task is "call Flink through the open platform".
 
-Start with the smallest reference that answers the request:
+Start with the smallest current source that answers the request:
 
+- Prefer the repository source of truth when it exists: `docs/swagger/flink-api.json`, route handlers, DTOs, and tests.
 - Read `references/auth-and-credentials.md` for signing, headers, key acquisition, reset, or auth troubleshooting.
 - Read `references/api-workflows.md` for business sequencing such as search to booking, change, or refund.
-- Read `references/endpoint-index.md` for exact method, path, required fields, and follow-up identifiers.
+- Read `references/endpoint-index.md` for a compact endpoint map, then verify fragile fields against the current swagger or code.
 - Use `scripts/flink_signed_request.py` to generate headers, inspect the canonical string, or send a signed request.
 
 ## Working Rules
@@ -21,15 +22,17 @@ Start with the smallest reference that answers the request:
 Follow this workflow:
 
 1. Confirm the environment: `sandbox` and `production` credentials are separate.
-2. Confirm the public path under `/openapi/v1/flink/*` and the required `lang` path parameter when present.
-3. Build the minimum valid request body from `references/endpoint-index.md`.
-4. Sign the exact request path, sorted query string, and raw body bytes with the platform secret.
-5. Evaluate both HTTP status and response envelope `code`.
+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/flink/*` and the required `lang` path parameter when present.
+4. Build the minimum valid request body from swagger/code first, using `references/endpoint-index.md` as navigation.
+5. Sign the exact request 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.
 
 Do not violate these rules:
 
 - Always send `X-OP-App-Key`, `X-OP-Timestamp`, `X-OP-Nonce`, and `X-OP-Sign`.
-- Never send supplier-side `appid`, `timestamp`, or `sign`; the platform injects them downstream.
+- Never send Flink-side `appid`, `timestamp`, or `sign`; the platform injects Flink downstream auth fields.
+- 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`.
@@ -53,6 +56,8 @@ Use these patterns by default:
 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.
 - State which environment the credential belongs to.
 - State which identifier from the previous step is needed next.
 - Call out auth failures with the likely root cause and the exact header or field to inspect.
+- For code changes, keep Flink downstream auth and platform gateway auth clearly separated.

package/skills/flink-flight-api/flink-openapi-integration/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Flink OpenAPI 接入"
-  short_description: "帮助完成 Flink 机票开放接口鉴权、凭证获取和业务调用"
-  default_prompt: "Use $flink-openapi-integration to integrate with the Flink flight open API, including auth, credentials, and endpoint selection."
+  short_description: "Flink 机票开放接口鉴权、签名和业务调用"
+  default_prompt: "Use $flink-openapi-integration to implement or debug Flink flight OpenAPI auth, signatures, endpoint selection, and order workflows."

package/skills/flink-flight-api/flink-openapi-integration/references/api-workflows.md

@@ -100,5 +100,5 @@ Use the same `lang` across related calls unless there is a clear reason to switc
 ## Business Handling Rules
 
 - Do not treat HTTP `200` as enough; inspect `code`.
-- Do not rebuild supplier headers; the runtime gateway handles supplier authentication.
-- Preserve the original upstream identifiers from earlier responses instead of recomputing them.
+- Do not rebuild Flink headers; the runtime gateway handles downstream authentication.
+- Preserve the original Flink identifiers from earlier responses instead of recomputing them.

package/skills/flink-flight-api/flink-openapi-integration/references/auth-and-credentials.md

@@ -59,7 +59,7 @@ Sandbox:
 
 1. The developer applies for app access.
 2. The operator activates the app access with `env_type=sandbox`.
-3. The platform records sandbox supplier mapping and issues a sandbox `open_app_id/open_app_secret`.
+3. The platform records sandbox Flink mapping and issues a sandbox `open_app_id/open_app_secret`.
 4. The app access becomes `sandbox_active`.
 
 Production:
@@ -73,7 +73,7 @@ Important constraints:
 
 - Sandbox and production credentials are separate and not interchangeable.
 - Developers can see platform credentials only.
-- Developers cannot see supplier-side secrets.
+- Developers cannot see Flink downstream secrets.
 
 ## How To View Or Reset Keys
 
@@ -131,6 +131,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 supplier request identifier when available.
+- `downstream_request_id` is the Flink request identifier when available.
 - `code=SUCCESS` means the business call succeeded.
-- `code=SUPPLIER_BIZ_ERROR` means the supplier returned a business error and can still arrive with HTTP `200`.
+- `code=SUPPLIER_BIZ_ERROR` means Flink returned a business error and can still arrive with HTTP `200`.

package/skills/flink-flight-api/flink-openapi-integration/references/endpoint-index.md

@@ -1,6 +1,6 @@
 # Flink Endpoint Index
 
-All routes are public gateway routes. Sign the public path, not the downstream supplier path.
+All routes are public gateway routes. Sign the public path, not the downstream Flink path.
 
 ## Flight Search
 

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

@@ -1,19 +1,20 @@
 ---
 name: glink-openapi-integration
-description: Integrate with the Glink hotel OpenAPI exposed through the platform runtime gateway. Use when Codex needs to read or implement against `docs/swagger/glink-api.json`, choose the correct Glink hotel endpoint, generate `X-OP-*` signatures, explain sandbox or production credential acquisition and reset, or drive static data, hotel search, hotel info, product, order, 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 酒店 static data, hotel search, hotel info, product detail, booking, payment, order, cancel, order status push/callback, checkout, invoice, and balance workflows.
 ---
 
 # Glink OpenAPI Integration
 
 ## Quick Start
 
-Use this skill when the task is "call Glink through the open platform" rather than "call Glink supplier APIs directly".
+Use this skill when the task is "call Glink through the open platform".
 
-Start with the smallest reference that answers the request:
+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.
 - 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 exact method, path, required fields, and supplier-field caveats.
+- 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.
 - Use `scripts/glink_signed_request.py` to generate headers, inspect the canonical string, or send a signed request.
 
 ## Working Rules
@@ -21,28 +22,44 @@ Start with the smallest reference that answers the request:
 Follow this workflow:
 
 1. Confirm the environment: `sandbox` and `production` credentials are separate.
-2. Confirm the public path under `/openapi/v1/glink/*`.
-3. Build the minimum valid request body from `references/endpoint-index.md`.
-4. Sign the exact public path, sorted query string, and raw body bytes with the platform secret.
-5. Evaluate both HTTP status and response envelope `code`.
+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:
 
 - Always send `X-OP-App-Key`, `X-OP-Timestamp`, `X-OP-Nonce`, and `X-OP-Sign`.
-- Never send supplier-side `partnerCode`, `signature`, `requestType`, or supplier `timestamp`.
-- Never wrap the payload in supplier-style `header` or `businessRequest`; send only business fields.
+- 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.
+- 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 supplier fields as required, follow the route description first and omit those supplier-managed 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 downstream fields from the client payload.
+- 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.
 
 ## Typical Requests
 
 Use these patterns by default:
 
 - Static data: city, country, district, business area, and brand lookup calls
-- Search and booking: destination or keyword lookup -> hotel search or hotel list -> product detail or lowest price -> `checkBooking` -> `createOrder` -> `payOrder` -> `queryOrderDetail`
-- Order aftercare: `cancelOrder`, `queryOrderCheckDetailInfo`, `checkoutApply`, `queryCheckoutDetail`
+- 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`
 
 ## Output Expectations
@@ -50,7 +67,9 @@ Use these patterns by default:
 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.
 - State which environment the credential belongs to.
 - State whether the payload should contain only business fields.
-- Call out supplier-field residue in the swagger when relevant.
+- 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.

package/skills/glink-hotel-api/glink-openapi-integration/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Glink OpenAPI 接入"
-  short_description: "帮助完成 Glink 酒店开放接口鉴权、凭证获取和业务调用"
-  default_prompt: "Use $glink-openapi-integration to integrate with the Glink hotel open API, including auth, credentials, and endpoint selection."
+  short_description: "Glink 酒店开放接口鉴权、签名和业务调用"
+  default_prompt: "Use $glink-openapi-integration to implement or debug Glink hotel OpenAPI auth, signatures, endpoint selection, and order workflows."

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

@@ -15,6 +15,19 @@ Use these calls to build hotel search prerequisites:
 
 These APIs usually feed city selection, district filters, brand filters, and keyword suggestions.
 
+For the required Open Platform Glink onboarding flow, build local hotel and room mapping in this order:
+
+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.
+
 ## Hotel Search And Product Selection
 
 Use this sequence for discovery and pricing:
@@ -32,6 +45,12 @@ Use this sequence for discovery and pricing:
 
 Use `queryHotelAllList`, `queryHotelIdList`, and `queryHotelIncrement` when synchronizing hotel catalogs rather than serving live booking UX.
 
+For the Open Platform Glink flow, prefer the local mapped catalog over broad live search during booking:
+
+- 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`.
+
 ## Booking Flow
 
 Use this sequence for a normal hotel booking flow:
@@ -39,18 +58,20 @@ Use this sequence for a normal hotel booking flow:
 1. `glink.queryProductDetail`
    - Identify the exact sellable room and rate.
 2. `glink.checkBooking`
-   - Perform pre-booking validation.
+   - 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.
+   - 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`
-   - Pay when the order flow requires explicit payment.
-5. `glink.queryOrderDetail`
-   - Track final status and supplier-side details.
+   - 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
+   - Treat the push/callback as the primary confirmation result channel. The receiver must be idempotent.
+6. `glink.queryOrderDetail`
+   - 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`: supplier-side order number when available
+- `fcOrderCode`: Glink-side order number when available
 
 Prefer carrying both once they appear, because several aftercare APIs accept one or both.
 
@@ -59,7 +80,9 @@ Prefer carrying both once they appear, because several aftercare APIs accept one
 Use these calls after booking:
 
 - `glink.cancelOrder`
-  - Cancel an order when policy permits.
+  - 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`
   - Read extended order or check-in related detail.
 - `glink.checkoutApply`
@@ -73,12 +96,15 @@ Use these calls for financial follow-up:
 
 - `glink.createInvoice`
   - Submit invoice information using business fields only.
-  - Ignore supplier-managed `partnerCode` and `sign` even if they appear in the swagger schema.
+  - Ignore Glink-managed `partnerCode` and `sign` even if they appear in the swagger schema.
 - `glink.queryCreditBalance`
   - Read remaining credit balance.
 
 ## Business Handling Rules
 
 - Do not treat HTTP `200` as enough; inspect `code`.
-- Do not rebuild supplier headers or wrapper payloads; the runtime gateway handles supplier authentication and wrapping.
-- Preserve upstream order identifiers from earlier responses instead of recomputing them.
+- 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.
+- 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.

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

@@ -51,7 +51,7 @@ Notes:
 
 ## Platform Wrapping Rules
 
-Glink supplier authentication is handled by the runtime gateway.
+Glink downstream authentication is handled by the runtime gateway.
 
 Client responsibilities:
 
@@ -61,16 +61,16 @@ Client responsibilities:
 Do not send:
 
 - `partnerCode`
-- `signature` or `sign` used by the supplier
+- `signature` or `sign` used by Glink downstream auth
 - `requestType`
-- supplier-side `timestamp`
+- Glink-side `timestamp`
 - wrapper objects like `header` or `businessRequest`
 
 Important exception handling:
 
 - `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 supplier-managed.
+- Prefer the route description and treat those fields as platform-managed downstream fields.
 
 ## Credential Acquisition
 
@@ -80,7 +80,7 @@ Sandbox:
 
 1. The developer applies for app access.
 2. The operator activates the app access with `env_type=sandbox`.
-3. The platform records sandbox supplier mapping and issues a sandbox `open_app_id/open_app_secret`.
+3. The platform records sandbox Glink mapping and issues a sandbox `open_app_id/open_app_secret`.
 4. The app access becomes `sandbox_active`.
 
 Production:
@@ -94,7 +94,7 @@ Important constraints:
 
 - Sandbox and production credentials are separate and not interchangeable.
 - Developers can see platform credentials only.
-- Developers cannot see supplier-side secrets.
+- Developers cannot see Glink downstream secrets.
 
 ## How To View Or Reset Keys
 
@@ -152,6 +152,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 supplier request identifier when available.
+- `downstream_request_id` is the Glink request identifier when available.
 - `code=SUCCESS` means the business call succeeded.
-- `code=SUPPLIER_BIZ_ERROR` means the supplier returned a business error and can still arrive with HTTP `200`.
+- `code=SUPPLIER_BIZ_ERROR` means Glink returned a business error and can still arrive with HTTP `200`.

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

@@ -1,6 +1,6 @@
 # Glink Endpoint Index
 
-All routes are public gateway routes. Sign the public path, not the downstream supplier path.
+All routes are public gateway routes. Sign the public path, not the downstream Glink path.
 
 ## Static Data
 
@@ -52,6 +52,7 @@ All routes are public gateway routes. Sign the public path, not the downstream s
 - `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`
@@ -96,6 +97,9 @@ All routes are public gateway routes. Sign the public path, not the downstream s
   - `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
@@ -113,7 +117,7 @@ All routes are public gateway routes. Sign the public path, not the downstream s
 - `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 supplier auth fields. Do not send supplier-managed fields from the client.
+  - 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