The google-sheets module documents every command invocation — including its own "Verify" step — as railcall airlock exec <command>. There is no railcall airlock command, so following the setup guide's verify step errors out and a new user reasonably concludes their configuration is broken.
Reproduction (station-v0.93, sami666/google-sheets v0.3.0)
Follow the module's docs/SETUP.md to the "A4 · Verify" step and run what it says:
railcall airlock exec google.sheets_get_metadata --inputs '{"spreadsheet_id":"<your-sheet-id>"}'
Result:
unknown command: airlock
Observed
railcall airlock is not a command. In railcall_cli.py the dispatch table has no airlock entry (grep -c '"airlock":' railcall_cli.py -> 0), and there is no exec / run / invoke command either. _dispatch looks the verb up and falls straight through to the unknown-command path:
fn = COMMANDS.get(arg1)
if not fn:
print(footer(ok=False, label=f"unknown command: {arg1}"))
return cmd_dashboard() or 1
(railcall_cli.py, _dispatch)
The module references railcall airlock exec in four shipped places:
- docs/SETUP.md L51 — the A4 · Verify step (the step whose whole job is to confirm the setup worked)
- docs/SETUP.md L114 — the OAuth bootstrap invocation
- docs/SETUP.md L216 — a third airlock exec usage
- handlers/handler.py L617 — printed back to the user in the bootstrap_oauth success output:
"next_step": "Try: railcall airlock exec google.sheets_get_metadata --inputs '...'",
So even a user who gets past setup and runs the bootstrap is handed the broken command a second time, by the tool itself.
The correct path exists — the same publisher already uses it
This isn't a missing feature; it's a stale command name. The same publisher's other module, sami666/singleops-browser, drives its commands through the real Studio API in scripts/run_backlog_to_*.py:
approve = _post("/api/commands/approve", { ... })
exe = _post("/api/commands/execute", { ... })
Commands are run from the Studio Sends tab (preview -> approve -> execute) or by POSTing to /api/commands/* — not via any railcall airlock verb.
Why it matters
The one step in the guide designed to give a new user confidence — "A4 · Verify" — fails with unknown command: airlock. The most likely reading is "my credentials are wrong" or "the module didn't install," sending people to debug a setup that is actually fine. And the module's own success message repeats the same dead command, so there's no self-correcting signal.
Suggested fix
Replace the railcall airlock exec <command> invocations in docs/SETUP.md (L51, L114, L216) and the next_step string in handlers/handler.py (L617) with the real invocation path — either "run it from Studio -> Sends (preview -> approve -> execute)", or a /api/commands/execute POST like the publisher's own singleops-browser scripts already use. If a first-class railcall <run-a-command> CLI verb is intended to exist, that's a separate CLI gap; today the docs should point at the path that works.
Environment: station-v0.93; module sami666/google-sheets v0.3.0. Verified by reading docs/SETUP.md and handlers/handler.py in the installed module against the CLI's dispatch table in railcall_cli.py; the "unknown command" result is traced from _dispatch, not run live.