feat(factory): add --yes confirmation guard for destructive commands

[margaretjgu]

Closes #511.

[github-actions]

docs/cli/schema.json is out of date. Comment /fix-schema on this PR and the bot will regenerate and commit it automatically.

[github-actions]

✅MegaLinter analysis: Success

Descriptor	Linter	Files	Fixed	Errors	Warnings	Elapsed time
✅ ACTION	actionlint	1		0	0	0.48s
✅ BASH	shellcheck	4		0	0	0.14s
✅ COPYPASTE	jscpd	yes		no	no	0.46s
✅ REPOSITORY	gitleaks	yes		no	no	57.85s
✅ REPOSITORY	git_diff	yes		no	no	0.11s
✅ REPOSITORY	secretlint	yes		no	no	1.51s
✅ REPOSITORY	trivy	yes		no	no	21.79s
✅ TYPESCRIPT	eslint	8		0	0	4.48s
✅ YAML	yamllint	1		0	0	0.86s

Notices

📣 MegaLinter 9.5.0 is out! Discover the new features and security recommendations in the release announcement. (Skip this info by defining SECURITY_SUGGESTIONS: false)

See detailed reports in MegaLinter artifacts
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

MegaLinter is graciously provided by OX Security
Show us your support by starring ⭐ the repository

[margaretjgu]

dry-run bypass is intentional — dry-run exits before sending anything so confirmation would be a no-op. The other points are noted; not addressing before merge.

[JoshMock]

We've added a more accurate "is destructive" flag to the schemas lib, which should probably be used to simplify any destructive checks in the CLI rather than just inferring from HTTP method. elastic/schemas-js#25

other than that, the overall change LGTM.

[github-actions]

The diff is purely additive schema documentation — it appends a --yes boolean flag to every destructive command's flag list. A few issues worth raising:

Missing dry-run interaction

The --yes flag is added even to entries that already have a dry-run/validate flag, but there's no indication in the schema that --yes is incompatible with or overridden by --dry-run. If the actual implementation doesn't cross-check these, a user could pass both --dry-run --yes and get confusing behaviour. The schema itself can't enforce this, but it should be documented or handled in code.

--yes added to inference.delete without dry-run

At line ~19753 the yes flag is inserted after a path flag (JSON file input), not after a dry-run flag like all other entries. This looks like a copy-paste inconsistency and may indicate the guard logic for that command follows a different code path that could be missed.

No evidence of the actual guard implementation

The diff only touches schema.json. There is no corresponding implementation visible (e.g. a confirmDestructive() helper, flag wiring in the factory, prompt logic, or tests). Shipping a documented flag that isn't actually wired up is a real bug — users will pass --yes, nothing will happen differently, and they'll still get prompted (or worse, not be prompted and assume --yes did something).

Consistency of flag summary capitalisation

All pre-existing flag summaries start with lowercase ("validate all inputs…"), but the new entries use "Confirm destructive action without prompting" (capital C). Minor, but it will look inconsistent in generated help text.

Over-broad application

"Clear cluster voting config exclusions" and "Remove an index block" are included. These are not obviously irreversible in the same way delete operations are — worth confirming they genuinely need the guard rather than getting it because the generator applied it to every non-GET method.

The core concern is point 3: if the implementation diff is missing, this schema change is dead weight at best and misleading at worst.

[github-actions]

docs/cli/schema.json is out of date. Comment /fix-schema on this PR and the bot will regenerate and commit it automatically.

[github-actions]

🔍 Preview links for changed docs

⏳ Building and deploying preview... View progress

This comment will be updated with preview links when the build is complete.

[JoshMock]

#542 was opened today to track this more broadly, per a request from @kobelb in today's CLI workstream meeting. Take a look and make sure your changes are aligned with that before merging. You don't need to fully implement everything noted there, just fix any conflicts with your work and the described implementation. 🙏

Once it's merged, please also update the issue to describe what functionality has been added and what still remains.

[margaretjgu]

done in #537:

• --yes flag and confirmation guard
• interactive prompt on tty when a command is marked destructive
• fails closed with confirmation_required when non interactive and no --yes
• --dry-run skips the prompt since nothing is sent
• cloud delete and other destructive endpoints get explicit intent
• extension remove marked destructive
• cloud reads destructive from @elastic/schemas instead of guessing from the http method

not done:

• yes=true env var
• require_confirmation: false in the config file
• commands.block_destructive
• es and kb still infer destructive from the http method, their definitions come from the generator and don't carry the schema's destructive flag yet

[JoshMock]

LGTM. One question, just making sure we validate that the destructive flag added to JSON schemas via elastic/schemas-js#25 is working, not just using HTTP method as intent.

[JoshMock]

Can we add another test here that uses destructive: true rather than just trusting the @cli-schema/spec library to get intent right based on HTTP method?