CLI command naming is inconsistent

[joehoyle]

As the CLI has grown, naming patterns have diverged. This tracks the inconsistencies so we can agree on conventions going forward.

Two patterns for multi-action resource commands

Some resources use a single command with as a positional arg:

app variables <list|get|set|delete> [app]
app domains <list|add|remove|retry> [app]
app ip-list <get|set> [app]
app ua-blocklist <get|set> [app]
app tasks [list|cancel|logs]
Others use separate named commands per operation:

app deploy (create) vs app deploys (list)
app build (create) vs app builds (list)
app backup (create) vs app backups (list)
These are equivalent patterns for the same kind of CRUD operation.

Action vocabulary isn't standardised

add vs create, remove vs delete, set vs update are used interchangeably across commands with no rule for which to pick.

instance uses a non-standard flat positional chain

instance [group] [action] [id] [value]
All other commands use yargs subcommands. The instance routing is manual if/else, which breaks per-subcommand --help and causes the target argument to shift position:

instance info — id is in the action slot
instance access list — id is in the id slot

php-logs is redundant

stack php-logs duplicates app logs --type php. The dedicated command adds noise.

build-cache only accepts one value

build-cache requires a positional action but only accepts clear. It should just be build-cache clear.

local-setup is undocumented

lib/commands/stack/local-setup.js exists but is not listed in the README. Either document it or remove it.
Mark php-logs as deprecated

For Altis Team Use

Acceptance Criteria

• Agree on a standard CRUD pattern (suggest: plural noun + action subcommand - deploys list, deploys create)
• Agree on action vocabulary (list, get, create, update, delete, with add/remove only for membership)
• Refactor instance to use proper yargs subcommands
• Document agreed conventions in README or CONTRIBUTING
• Mark php-logs as deprecated

Ready for Work Checklist

Is this ticket ready to be worked on? See
the Play Book Definition of Ready

• Is the title clear?
• Is the description clear and detailed enough?
• Are acceptance criteria listed?
• Have any dependencies been identified? (Optional)
• Have any documentation/playbook changes been identified? (Optional)
• Is an estimate or time box assigned?
• Is a priority label assigned?
• Is this ticket added to a milestone?
• Is this ticket added to an epic? (Optional)

Completion Checklist

Is this ticket done? See
the Play Book Definition of Done

• Has the acceptance criteria been met?
• Is the documentation updated (including README)?
• Do any code/documentation changes meet project standards?
• Are automatic tests in place to verify the fix or new functionality?
  • Or are manual tests documented (at least on this ticket)?
• Are any Playbook/Handbook pages updated?
• Has a new module release (patch/minor) been created/scheduled?
• Have the appropriate backport labels been added to the PR?
• Is there a roll-out (and roll-back) plan if required?

[joehoyle]

Personally I'm more a fan of the explicit CRUD names, which is more similar to wp cli, e.g. backups create vs backup. Nouns can also be verbs which can make it difficult to predict if backup is going to be a singular noun vs verb. That has already tripped me up once or twice.

[joehoyle]

@jerico / @rmccue thoughts here?