request

Submit cloud resource, application environment, or ticket/work order requests through the service catalog.

Flow

The request workflow owns request-projected smartcmp_list_logical_templates and smartcmp_list_images tools. They reuse the same read-only scripts as the datasource global-query tools, but remain visible when AtlasClaw projects only the cmp.request capability.

Multi-resource routing boundary

This skill is for one CMP request flow at a time. That single flow may still represent one service catalog / one resource type / one shared parameter set with quantity N.

Keep the request in this skill when the user wants multiple instances of the same resource type with the same configuration, for example:

• "several identical Linux VMs for one project"
• "multiple instances of the same database service with shared parameters"
• "quantity N of one resource type with one shared parameter set"

Route to request-decomposition-agent only when the request needs to be split into distinct sub-requests, especially when the user gives:

• multiple resource types in one ask
• per-instance differences such as "first ..., second ..., third ..."
• different specs per instance
• mixed roles/components that should become separate CMP requests

Quantity by itself is not a decomposition signal. The request workflow and submit tool should interpret same-type quantity from the user's original language without requiring AtlasClaw core to pre-structure resource_count.

When this boundary is hit, do not continue with the single-catalog parameter collection flow in this skill.

Single-instance vs shared-quantity contract

This skill supports two request shapes, and they are not interchangeable:

• Single-instance request: one resource type, one instance, one resourceSpecs item, and no top-level count field unless the selected catalog explicitly requires one.
• Same-type multi-instance request: one resource type, one shared parameter set, one explicit quantity value from the selected catalog schema or fallback quantity, with resourceSpecs following the selected catalog schema.

For same-type multi-instance requests:

• Read the selected catalog instructions before choosing the quantity key. If an active field in instructions.topLevelFields or instructions.params clearly declares instance quantity, use that exact key and location. Do not choose from a fixed alias list.
• If the selected catalog does not declare a quantity/count field, use fallback top-level quantity.
• When the selected catalog has one instructions.resourceSpecs item, keep one shared resourceSpecs item for the shared parameter set.
• When the selected catalog declares multiple instructions.resourceSpecs items, build each declared item exactly once; do not treat the number of specs as the requested instance count.
• Do not duplicate identical resourceSpecs entries just to represent quantity N.
• Do not invent per-instance names, hostnames, IPs, disk sizes, or other per-instance overrides when the user asked for shared parameters.
• If the user supplies per-instance differences, separate names for each instance, or mixed component roles, stop using this skill and route to request-decomposition-agent.

Do not infer decomposition solely from resourceSpecs length. A single catalog can legitimately declare multiple resource specs. Decomposition is driven by user semantics, such as separate CMP requests or per-instance differences, not by a submit-script spec-count heuristic.

Submitted request status flow

Use smartcmp_get_request_status only for submitted request status or approval-result checks. Pass an explicit Request ID when present. For "刚才提交的 申请", reuse the most recent smartcmp_submit_request Request ID in this conversation; if none exists, ask for the Request ID. Treat Request IDs as opaque user-facing values: do not require a prefix, character set, or fixed length pattern. Use the exact value returned by SmartCMP.

The status script returns structured fields only. Treat the tool output as lookup data, not final user-facing text. Explain the result in the current user's message language using state, statusCategory, approvalPassed, currentStep, currentApprover, provisionState, error, and updatedAt.

Status semantics:

• APPROVAL_PENDING: not approved yet; approval is still pending.
• APPROVAL_REJECTED / APPROVAL_RETREATED: not approved; rejected or returned.
• STARTED / TASK_RUNNING / WAIT_EXECUTE / FINISHED: approval has passed or the request has entered later execution.
• INITIALING / INITIALING_FAILED / FAILED / CANCELED: report the current state as initialization, failure, or cancellation; do not claim approval or rejection.

Complete flow

1. Call smartcmp_list_services once. Auto-select a catalog only when the user's wording clearly matches one returned catalog; otherwise ask a numbered catalog-selection question.
2. Call smartcmp_get_request_catalog once with the selected catalog UUID to load only that catalog's generated request instructions.
3. Call smartcmp_list_available_bgs with the selected catalog UUID. If one business group is returned, use it. If multiple are returned, ask a concise numbered question using display names only and wait for the user's selection. Do not show business group IDs to the user.
4. Before asking for request fields, check the selected catalog metadata. If a ticket/work-order catalog (serviceCategory: "GENERIC_SERVICE") has instructions.genericRequest, build from that metadata. If a cloud/resource catalog has no instructions.resourceSpecs but its selected catalog metadata has type: "cloudchef.nodes.Compute", use the Compute fallback below. If it has no Markdown and is not Compute, stop and explain that the catalog is missing generated Markdown instructions.
5. Build the request from the selected catalog's generated Markdown metadata: instructions.resourceSpecs, instructions.genericRequest, and instructions.topLevelFields.
6. For every active selectable field, resolve its candidates even when it has a default. A default is only a suggestion in its declared or returned position: use a sole candidate, but require an explicit user choice among multiple candidates unless the user's existing intent uniquely identifies one. Use non-selectable defaults silently, and ask for other active required or ask: true fields without a value. The sole platform-resolved exception is flavorId after computeProfileId is selected when the exact selected resource-pool item has cloudEntryTypeId equal to yacmp:cloudentry:type:vsphere; omit that field instead of asking for it.
7. Reuse resolved workflow lookup evidence. For every resource spec with an active resourceBundleTags, active resourceBundleId, or runtime_fields.resolver, resolve its resource pool and dynamic request fields, then collect each unresolved active required, ask: true, or selectable value. Ticket/work-order genericRequest catalogs have no resource specs and skip this step. Use the exact returned option ID for option-backed fields. Once all declared fields have values, show a schema-exact JSON preview with credential secrets masked, ask for confirmation, and stop. Do not run a final resource-pool revalidation solely to authorize the preview.
8. After the user confirms, call smartcmp_submit_request with the corresponding unmasked request body. For tag-only and internal resource-pool modes, also pass resource_bundle_selections keyed by node with the exact pool ID already resolved for the preview. The displayed preview is presentation-only; restore each original secret value and never submit a preview mask.

Steps 1 through 3 are mandatory for every new request. Never ask the user to type a business group before calling smartcmp_list_available_bgs.

When the service has a clear automatic match, steps 1 through 3 may continue in the same turn. Stop after any step that requires a user selection; smartcmp_get_request_catalog is an internal schema lookup, not a user-facing question.

Catalog identity contract

• Displayed service list numbers are conversation choices only. Resolve them against the latest smartcmp_list_services result.
• Preserve each returned index when displaying a filtered subset; never renumber catalog choices in the assistant response.
• A catalog-selection question MUST show the exact returned index at the start of every option line, for example 3. LinuxOS. Never ask the user to reply with a number unless those numbers are visible in the response.
• catalogId must be the selected catalog metadata UUID, never the displayed list number and never sourceKey.
• After catalog selection, call smartcmp_get_request_catalog and smartcmp_list_available_bgs with the same UUID in one tool-call batch. The business-group lookup does not depend on the catalog-detail response.
• There is no catalog questionnaire/default-property/preview tool in this skill. Do not invent one.

Tool sequencing

• Resolve resource-spec lookup fields in dependency order: active resourceBundleTags -> active resourceBundleId -> computeProfileId -> explicitly selectable flavorId when declared -> logicTemplateId -> physicalTemplateId or templateId. Do not call tools for two unresolved selectable fields in one model response. When tags are the sole pool selector, use the first filtered result in CMP response order only for internal dynamic-field resolution and do not submit its ID. Ticket/work-order genericRequest catalogs skip this resource-spec lookup sequence.
• After resourceBundleId is selected, smartcmp_list_flavors is the only valid next lookup while an active computeProfileId or explicitly selectable flavorId remains unresolved. Resolve computeProfileId first, then call the same tool with that value to resolve flavorId. Do not perform that second lookup when the exact selected resource-pool item has cloudEntryTypeId equal to yacmp:cloudentry:type:vsphere: after computeProfileId is resolved, omit flavorId from preview and submit JSON so SmartCMP resolves it from the compute profile. Never send an empty flavorId, never copy computeProfileId into it, and never infer this branch from an empty lookup result. A missing or different platform marker remains fail-closed. Do not call any logical-template, physical-template, or image lookup first.
• For each active generated selectable field, call only that field's lookup, regardless of whether it has a default. When the opted-in read-only tool returns one visible candidate, the generic runtime selects it and continues. When it returns multiple choices without an explicit user selection, present only those choices in returned order, ask the user to select one, and stop. Do not ask for later lookup fields or user-entered fields in the same reply.
• Every lookup-selection prompt must also state exactly one immediate workflow step that will follow the user's selection, without asking for that next step in the same reply. If another generated lookup remains, state that the next live lookup will run. If generated lookups are complete and an already-known active non-lookup field is missing, state that this field will be collected next. If no such field is missing, state that placement resolution or exact validation will run next. This immediate-next-step statement is mandatory and must match the current generated instructions and any applicable latest exact requestFields.
• After recording a lookup selection, continue the generated lookup sequence above while any active lookup field remains unresolved. Once that sequence is complete, but before starting resource_bundle_placement discovery or exact validation, collect the already-known active non-lookup fields in their declared order. A field belongs to this sequence when it is required, ask: true, or selectable, has satisfied dependencies, and has neither a real user value nor a usable non-selectable default. A selectable default is not a real user value when multiple candidates exist. A promise to provide a value later is not a value. Ask for exactly the first missing field and stop. After the user supplies it, re-evaluate the same already-known active non-lookup fields. If another field still meets these conditions, ask for that field next and do not state or imply that placement resolution or validation will run yet. Only when the current field is the last such missing field must the prompt state that placement resolution or validation follows after it is supplied. Apply this only to fields already proven active by generated instructions or the latest exact requestFields. Use an exact field only when its condition and dependency inputs have not changed since that result; never activate a conditional field by guessing.
• Phrase every multiple-choice reply with the pending field meaning and visible numbered options. A bare visible number or the exact visible option text is a valid generic continuation; do not require the user to repeat field names.
• Stop after a lookup whenever the user must choose among multiple unresolved options. Ask at most one concise question and wait for the answer.
• A sole visible candidate may auto-continue only when its read-only tool is explicitly marked auto_select_single_option. Multiple candidates remain a user selection boundary unless existing user intent uniquely matches one. Tools without that metadata never gain automatic-selection behavior.
• During mandatory catalog discovery, when the initial list has one clear automatic match, emit smartcmp_get_request_catalog and smartcmp_list_available_bgs in the same tool-call batch with the selected catalog UUID. The business-group query does not depend on the catalog-detail response. When the user must choose a catalog, stop after the list and issue that batch only after their selection.
• After a lookup result that needs user input, summarize the selectable result in natural language and ask at most one next question. When no user choice is needed, preserve the compact lookup evidence and continue the resolver chain.
• Do not paste raw tool output, _internal metadata, UUID dumps, or JSON meta blocks into the reply.
• If the previous assistant message asked the user to choose a business group and the user replies with a bare number or group name, treat it as a business group selection, never as an unsupported operation.
• In a tool-required turn after a business group selection, call smartcmp_list_available_bgs again with the same selected catalog UUID to refresh the business group list, resolve the user's selection against that result, then continue with generated Markdown, Compute fallback, or the JSON preview.
• During request building, do not call unrelated discovery tools such as smartcmp_list_components or smartcmp_list_applications. Use the request-projected logical-template and image tools declared above.

User Response Language

• Use the current user's language for user-facing replies.
• Keep JSON keys, API fields, catalog names, provider names, and tool names unchanged.
• In Chinese user-facing text, always call SmartCMP resource pools 资源池. Never call them 资源包. Keep API field names such as resourceBundleId and resourceBundleTags unchanged inside JSON or code.

Generated Markdown Instructions

Catalog instructions is expected to be the Markdown generated by the Java catalog instruction builder. For request building, only these sections are in scope:

• # Request Parameter Instructions: YAML parameter contract.
• # Request Instructions: optional request-building guidance.

smartcmp_get_request_catalog exposes the selected catalog's parsed # Request Parameter Instructions YAML as metadata:

• instructions.topLevelFields
• instructions.topLevelRequired
• instructions.params
• instructions.genericRequest
• instructions.resourceSpecs
• instructions.requestInstructions from exactly # Request Instructions, when that section exists

Ignore old JSON instruction payloads. Do not use instructions.parameters or legacy raw params as the request schema. Use instructions.params only when it is parsed from # Request Parameter Instructions.

Instruction section boundary

The catalog Markdown body may contain multiple instruction sections, such as # Request Parameter Instructions, # Request Instructions, # Preapproval Instructions, or other future sections. For this request skill, only # Request Parameter Instructions and # Request Instructions are in scope.

• Read # Request Parameter Instructions first; it is the authoritative schema contract.
• The # Request Instructions section is optional. If it is absent, use # Request Parameter Instructions only.
• For free-form Markdown instructions, read only the content under exactly # Request Instructions.
• Stop reading request instructions at the next same-level heading that starts with # , such as # Preapproval Instructions.
• Never fall through to # Preapproval Instructions or any other section when # Request Instructions is missing.
• Ignore all other sections for request building. They must not change required fields, defaults, when behavior, resource tag handling, payload shape, or submit/preview behavior.
• A catalog body with only # Preapproval Instructions has no request-body instructions. It is still requestable only if # Request Parameter Instructions contains enough request schema metadata.

Markdown field rules