Dear @mrz,
Having been in the RouterOS schema business for a while and far too familiar with /console/inspect, I see a path to my own retirement here 
— so, some meat on the bones for consideration:
Publish the reference as data, not only HTML
The highest-leverage addition. The rendered pages are already richer than raw /console/inspect, but a parsable form (JSON / YAML / even CSV) per path is what lets editors, linters, LSPs and LLMs actually enforce the schema instead of scraping tables. restraml already publishes /console/inspect JSON for 40+ versions and rosetta indexes it and webpages like my API Explorer & Schema Diff & Command Lookup — proof the model is practical, not a request that you adopt my format.
"The ROS command list" is multidimensional — version × platform × package
There isn't one command list. All my schema tools build from x86 CHR because I need a live router per version (my RouterOS LSP and TikBook go further and query a connected router directly) — but the command set genuinely varies by platform. Even ARM64 vs x86 CHR at the same version differ by ~1K items:
ver. arm-only x86-only completion
cmds/attr cmds/attr key drift
7.20.8 180/973 8/21 1087
7.21.4 187/1020 10/26 1132
7.22.3 187/1071 10/25 1139
(ARM64 is larger mostly because it carries more extra packages; only a few dozen are x86-only.) Related: there's currently no signal for which package is available on which architecture (other than the TOC, see next).
Stable, package-agnostic URLs
Right now the package name is baked into the reference URL (…/CLI%20Reference/system/ip/firewall#ipfirewallnat). But the tools that most want to deep-link — LSPs, editors, scripts, agents — usually know the command path/attribute, not which package ships it. So they can't construct today's URL from RouterOS path data alone without an extra package/site-map lookup.
The ask: make a reference link derivable from a RouterOS path, illustratively something like …/cli/ip/firewall/nat#flags (or a resolver such as …?path=/ip/firewall/nat#attributes), resolving within the selected version/platform context and redirecting to the canonical package-qualified page when unambiguous. Stable #flags / #attributes (and per-attribute) anchors on top of that turn the reference into something tools can link to deterministically — path → URL with no out-of-band package lookup.
### Argument-type definitions are incomplete
edit: added to top CLI Reference, CLI Reference | RouterOS Manual
The deterministic allowed-values in the reference already exceed /console/inspect request=syntax, which is great. But the type vocabulary on the Argument Types page doesn't define many forms actually used on real pages (e.g. super { !, {...} }). Publishing the full argument-type grammar — including how compound forms (super, negation, ranges, nested/enum maps) compose, not just a flat token list — would make the reference machine-checkable end to end.
Cross-link narrative ↔ CLI Reference
More work, but high value: CLI Reference pages should link back to the relevant narrative page (/interface/bridge → "Bridging"), and narrative pages should link commands to the reference (or carry a "Related Commands" list). rosetta and my API Explorer already do this heuristically by parsing the Confluence HTML — incomplete, but proof a build-step can generate it. Example mapping (~4k rows, currently Confluence-based): rosetta/commands-to-docs.csv at main · tikoci/rosetta · GitHub .
Originally written by me, edited by Opus 4.8 for clarity/brevity, "rubber duck" review by GPT 5.5 for final accuracy