[dimitropoulos]

Adds forge inspect methods <spec>, which prints the methods a document makes as a JSON array. Each entry has the method's group path and name in kebab-case, plus its HTTP method, path, hidden, deprecated and availability.

forge normalize openapi.json | forge inspect methods -

[
  {
    "group": ["dns", "records"],
    "name": "list",
    "method": "GET",
    "path": "/zones/{zone_id}/dns_records",
    "hidden": false,
    "deprecated": false,
    "availability": "generally-available"
  }
]

Why

Tools that need to know which methods (and therefore which CLI commands) a document defines, such as CI that flags new or renamed commands on a spec change, otherwise have to reimplement forge's naming rules: x-forge-group-name splitting, x-forge-method-name, x-forge-skip, aliases, and the operationId fallback from #51. With this command, forge's own resolution is the source of truth and callers just diff the output.

Notes

• forge inspect is the parent command for printing what forge reads in a document. methods is the first subcommand; groups, models, security schemes and so on can follow under it.
• Ordering follows Forge::groups() (depth first from the root), with methods sorted by name within each group, so the output is stable.
• A document forge cannot read, such as one with two methods of the same name in a group, is an error, the same as for generating an SDK.
• It reads only native x-forge-* keys. Run forge normalize first for Fern or Stainless keys.
• I ran it over 140 real production bundles after forge normalize. All of them parse, and each takes a few milliseconds.

[Copilot]

🟡 Changes recommended

The duplicate-name fixture in tests/cli.rs uses single-line operation objects instead of the existing one-member-per-line format.

1 open issue

• Expand operation objects to match existing fixture formatting · New

What changed in this PR

Adds forge methods <spec> to expose Forge-resolved method names and metadata as JSON, helping tools compare API commands without duplicating Forge’s naming rules.

Changes:

• Registers the new CLI command and adds JSON serialization of method metadata.
• Adds tests for naming, metadata, skipped operations, and duplicate-name errors.
• Documents usage, normalization pipelines, output ordering, and error behavior.

File	Description
tests/​cli.rs	Adds method-listing and invalid-document integration tests.
src/​bin/​forge/​methods.rs	Implements document reading and JSON method output.
src/​bin/​forge/​main.rs	Registers and dispatches the command; tests argument parsing.
packages/​forge/​README.md	Documents method listing and its output format.

_{Review effort: Balanced}

[pkg-pr-new]

npm i https://pkg.pr.new/cloudflare/forge/@cloudflare/forge@111

commit: fe49ddb

[Swimburger]

Great feature.

1. What do you think about rolling this into a subcommand. Today we only care about methods, but what we may want to retrieve in the future is:

• groups
• schemas/types
• webhooks
• channels (AsyncAPI)
• securitySchemes
• etc.

So something like forge inspect, forge query, forge ir, or something else makes sense.
Which can be built upon using like forge inspect methods, forge inspect groups.
Alternatively, forge ir could just dump our IR to JSON, and it's up to the consumer to use jq to extract the relevant details. More prone to breaking changes, but that's why versioning is important, so I think it's fine.

2. Should we name it methods, or endpoints? At what time of the process does an endpoint become a method, when we add the group and method name metadata? I haven't looked at the model'ing and naming of everything in forge, but worth thinking about if we're going to start using these names in public facing interfaces (CLI commands, output, etc.)