Location:
/build/leo/cli/cli_add/ and /build/leo/guides/deploy/
Problem:
The CLI reference mixes two different "do not use" conditions without distinguishing them:
--base-fees on leo deploy is labelled [UNUSED] in the option help text, meaning the flag is parsed but does nothing.--clear on leo add carries the warning "This feature is currently bugged and is non-functional." meaning the flag is wired up but actively broken.--edition on leo add carries "Do not use this feature unless you know what you are doing!", meaning the flag works but is dangerous.
Three different failure modes, surfaced as three differently-worded inline warnings, with no issue links, target fix versions, or guidance on what to do instead.
Consequence:
Developers can't tell whether --clear will work next week or next year, whether --base-fees will be wired up at all, or whether --edition is dangerous-but-correct or dangerous-and-broken. Agents reading the reference may emit these flags into generated scripts.
The fix:
Separate the two categories. For [UNUSED] flags (parsed but no-op), either remove them from the public CLI surface or label them as "reserved — not yet implemented" with a tracking issue. For "bugged and non-functional" flags, hide them from --help until fixed, or link to a tracking issue and ETA. For genuinely advanced flags, document the exact failure mode that warrants the warning.
Location:
/build/leo/cli/cli_add/and/build/leo/guides/deploy/Problem:
The CLI reference mixes two different "do not use" conditions without distinguishing them:
--base-feesonleo deployis labelled[UNUSED]in the option help text, meaning the flag is parsed but does nothing.--clearonleo addcarries the warning "This feature is currently bugged and is non-functional." meaning the flag is wired up but actively broken.--editiononleo addcarries "Do not use this feature unless you know what you are doing!", meaning the flag works but is dangerous.Three different failure modes, surfaced as three differently-worded inline warnings, with no issue links, target fix versions, or guidance on what to do instead.
Consequence:
Developers can't tell whether
--clearwill work next week or next year, whether--base-feeswill be wired up at all, or whether--editionis dangerous-but-correct or dangerous-and-broken. Agents reading the reference may emit these flags into generated scripts.The fix:
Separate the two categories. For
[UNUSED]flags (parsed but no-op), either remove them from the public CLI surface or label them as "reserved — not yet implemented" with a tracking issue. For "bugged and non-functional" flags, hide them from--helpuntil fixed, or link to a tracking issue and ETA. For genuinely advanced flags, document the exact failure mode that warrants the warning.