tasks/02_manager_ops.yml:30 passes XWIKI_SUPERADMIN_PASSWORD as an argument of shell/debug_superadmin.sh, so the secret is in the process list of the stack host and in the deploy log while that task runs. Options: feed it through stdin, hand the script a file path, or let the script read it from the container environment.
templates/compose.yml.j2:28 puts XWIKI_LDAP_BIND_PASS into JAVA_OPTS as a -D system property, so it is visible in the process list of the container. Options: write it into xwiki.cfg or xwiki.properties from the entrypoint, or mount it as a file the configuration reads.
tasks/03_administrator.yml posted the group member object on every deploy with a body XWiki ignored (<properties> wrapper, text outside <value>), so an existing installation carries one empty XWiki.XWikiGroups object on XWiki.XWikiAdminGroup per earlier deploy (measured: two). The post now carries the member and runs once. Options: delete the empty member objects through REST, or leave them (they grant nothing).
templates/xml/user/xwikiusers_object.xml.j2 has the same shape, so first name, last name, email and active of the administrator are not stored (measured: first_name empty). Options: write the properties as <property name="..."><value>...</value></property> directly below <object>, and update an existing object with a PUT on the object.
templates/playwright.env.j2 blocks the administrator persona with the reason that the account has no password. Without SSO and LDAP the role now sets one. Options: unblock the persona for that case and teach the admin flow the native sign-in form, or keep the block and reword its reason.
