Path parameters ignore `x-forge-params` `default` / `required` / `positional`

[G4brym]

derivePathParams in packages/cli/generator/arg-derivation.ts hard-codes path parameters as required: true and reads only hidden and description from x-forge-params. default, required and positional are dropped, even though the x-forge-params-valid-format lint rule accepts them and query/body parameters already honour them.

Example: AI Search sets x-forge-params: { namespace: { default: "default" } } on /accounts/{account_id}/ai-search/namespaces/{namespace}/..., but:

• every cf ai-search command still requires the namespace flag;
• create takes it as a positional: cf ai-search create <namespace> <id>.

Expected: a path parameter with a default becomes an optional flag, defaulting to that value, and is never chosen as the positional. For example cf ai-search create <id>.

[wra-sol]

Confirming this from the cf artifacts command group, and adding a second, distinct symptom.

1. Same class as the AI Search example: path param chosen as a positional

cf artifacts namespaces repos create takes the namespace as a positional, while every sibling command in the same group treats it as a flag:

$ cf artifacts namespaces repos create --help
  Positionals
    namespace  Artifacts namespace name.   [string] [required]
  Options
        --name   The name field   [string]

$ cf artifacts namespaces repos get --help
  Positionals
    name  Repository name.        [string] [required]
  Options
        --namespace  Artifacts namespace name.  [string] [required]

$ cf artifacts namespaces repos logs get --help
  Positionals
    name  Repository name.        [string] [required]
  Options
        --namespace  Artifacts namespace name.  [string] [required]

$ cf artifacts namespaces repos files get --help
  Positionals
    name  Repository name.        [string] [required]
  Options
        --namespace  Artifacts namespace name.  [string] [required]

$ cf artifacts namespaces repos list --help
  (no Positionals section at all)
  Options
        --namespace  Artifacts namespace name.  [string] [required]

So create takes {namespace} positionally and --name as a flag, while get, logs get, files get take {name} positionally and --namespace as a flag, and list takes only the flag. A caller who gets the shape right for create has it exactly backwards for get:

$ cf artifacts namespaces repos create ingress-probe --name ingress-probe
  -> "Not enough non-option arguments: got 0, need at least 1"

$ cf artifacts namespaces repos get spike --name ingress-probe
  -> "Unknown arguments: name"

This matches the AI Search case precisely: the spec declares a default for namespace, and the derived command takes it as a positional rather than an optional defaulting flag.

2. A more severe variant: the path param is not surfaced at all

cf accounts subscriptions get has two required path params that the command exposes as no option and no positional, so the command cannot be invoked with its path params by any means:

$ cf schema accounts subscriptions get
{
  "operationId": "generated:get:/{account_or_zone}/{account_or_zone_id}/subscriptions",
  "httpMethod": "GET",
  "path": "/{account_or_zone}/{account_or_zone_id}/subscriptions",
  "pathParams": [
    { "name": "account_or_zone",     "type": "string", "required": true },
    { "name": "account_or_zone_id",  "type": "string", "required": true }
  ],
  "queryParams": [],
  "hasRequestBody": false,
  "requestBodyFields": []
}

$ cf accounts subscriptions get --help
  Options
        --dry-run  Validate and show what would happen without executing

$ cf accounts subscriptions get --account-or-zone accounts --account-or-zone-id <id>
┌ Error
│ Unknown arguments: account-or-zone, accountOrZone, account-or-zone-id, accountOrZoneId
└

$ cf accounts subscriptions get accounts <id>
┌ Error
│ Unknown commands: accounts, <id>
└

This is worth separating from the positional/default case, because the failure mode differs: in AI Search the flag exists but is wrongly required and misfiled as a positional, whereas here no argument is registered at all, so neither a flag nor a positional can satisfy the path. The only way through is CLOUDFLARE_ACCOUNT_ID, which happens to work for this command because the value can be inferred, but it means the path template /{account_or_zone}/{account_or_zone_id} is effectively unreachable from the CLI.

Flagging both in case the fix differs: dropping default/required/positional fixes the first; the second looks like path params being skipped entirely for this operation, possibly because both are unprefixed ({account_or_zone} rather than {account_id}) and the derivation keys off an account_id-style prefix.