Document the admin password policy for `mw app install` (or return a clearer error)

[Hermsi1337]

Summary

mw app install <cms> … --admin-pass <pw> (observed with typo3) rejects admin passwords that don't satisfy a complexity policy, but that policy is not documented anywhere in the CLI and the failure is easy to misread as a transient error.

Observed with @mittwald/cli/1.18.0.

What happens

During a migration, mw app install typo3 … --admin-pass <pw> failed repeatedly on the password. It only succeeded once the password contained a mix of upper- and lower-case letters, a digit, and a special character (i.e. it looks like a character-class + minimum-length policy is enforced server-side). A human-memorable password that passes a length check but not the character-class requirement fails in a way that looks random.

Why it's confusing

mw app install typo3 --help documents the flag only as:

--admin-pass=<value>  password of your administrator user.

There is no mention of any complexity requirement, minimum length, or allowed/required character classes — so in a non-interactive/scripted install you find the policy by trial and error.

Suggestions (any one would help, roughly in priority order)

1. Document the actual policy in the --admin-pass flag help and the app-install docs (minimum length, required character classes).

2. Return a clear validation error that names the unmet requirement instead of a generic failure.

3. Add a flag to auto-generate a compliant password and print it, e.g. --generate-admin-pass. When set (and --admin-pass is omitted), the CLI generates a password that satisfies the policy, uses it for the install, and prints the generated value to stdout so it can be captured:

   $ mw app install typo3 -p <projectId> --admin-user admin --admin-email <email> --generate-admin-pass -q
   Generated admin password: <the-generated-value>

   This is the most script-friendly option: callers never have to know or replicate the policy, and it removes the guess-and-retry loop entirely. It also composes well with -q for non-interactive use. (The same could apply to any other command that takes a policy-constrained password.)

Notes

• The exact rule under "What happens" is observed, not authoritative — the point of the issue is that it isn't documented, so callers can't know it up front.
• Reported while harvesting learnings for the mittwald/agent-skills mittwald-migrate skill.

[martin-helmich]

"Fixing" this in #1972, with documentation only. Adding a --generate-admin-pass flag would be a never-ending story, because the password requirements differ per software, and are (afaik) not exposed via the API.