Nine roles enabled an MCP surface without a browser-side spec, so nothing
ever asked what the endpoint answers a caller with no credential at all.
Lift gitea's assertion into two shared registrars and register them per
role, and give each role the MCP_SERVICE_ENABLED flag they gate on.
mcpEndpointUrl now takes the base URL rather than reading APP_BASE_URL
unconditionally: jellyfin and zammad export their own base variable, and
declaring APP_BASE_URL for them would un-skip the shared guest persona,
which collapses itself on that variable being absent.
The env-gate scanner follows require("./x") into the shared harness so a
gate declared there counts as consumed, and strips block comments first
so service-gating.js's own doc examples do not credit EMAIL, SSO and OICD
to every role that imports it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
meta/schema.yml became meta/secrets.yml, but its content still landed at
applications.<app>.credentials — the one meta file whose payload did not sit
under a root named after the file. Every other topic obeys that rule:
meta/volumes.yml goes to volumes, meta/rbac.yml to rbac. Credentials now go to
secrets.credentials.
The path exists exactly once, in utils/manager/credential_key.py, and
OVERRIDE_SECTION is derived from its two segments rather than spelled beside
them, so the dotted form used by --set and the nested form used by the
inventory cannot drift. Six consumers read it: the loader, the generator, the
CLI override parser, the two emit helpers, and the four lookup validators.
--set now accepts exactly one key shape,
applications.<app>.secrets.credentials.<key>. The three short forms are
rejected instead of guessed at: the same short key names different credentials
on different apps. That also retired primary_app_id, which only existed to
disambiguate them.
Three defects surfaced while wiring this up. _apply_one_role_schema still wrote
to the old root, so an app's own credentials would have moved while its
providers' stayed behind. web-app-pgadmin reads through
lookup('applications', ...).credentials.<key>, an access path no regex over
lookup('config', ...) could see, and would have deployed with an empty postgres
password. And _META_NON_GENERIC_TOPICS still listed 'schema' — a bare topic
name, invisible to any path search — so the generic file-root loop assigned the
raw schema under secrets and the follow-up write landed inside the cached
document, truncating keycloak's four credentials to one for every later
reader.
tests/integration/ansible/lookups/config/test_credentials_roundtrip.py pins both
directions of the seam and the cache invariant that last defect broke.
Existing inventories still carry the pre-rename root; migrating them is
deliberately out of scope here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Every entry in LISTMONK_SETTINGS was one boot late. Listmonk reads settings
into koanf once at startup (cmd/main.go:186 initSettings) and builds the media
store from them (:205); the only reload trigger is SIGHUP (:315). The role
writes them with a direct UPDATE from 02_manager_ops.yml:34, after the single
`notify: compose up` in the whole role has already been flushed at :8. A DB
write reaches neither koanf nor the settings API, and `changed_when: false`
meant the task could not notify a handler even if one existed.
It never self-healed either: notify fires only on a changed config.toml, which
on the second run is identical, so no recreate. In the CI shape -- fresh stack,
one deploy, then Playwright -- the settings were guaranteed inactive.
What was therefore never in effect: upload.provider=s3 and the whole
upload.s3.* block (uploads went to the container filesystem, not the bucket),
security.oidc (so /admin/login rendered no SSO control at all), smtp, and
app.root_url -- which is why the deployed instance's public pages linked to
http://localhost:9000.
Proven against listmonk/listmonk:v6.2.0 with a throwaway Postgres: with the
settings written and no reload, /admin/login has no OIDC form; after
`docker kill --signal HUP` the same URL renders
`<form method="post" action="/auth/oidc">`. `container recreate` is the
existing shared handler, already used for exactly this in
web-app-peertube/tasks/oidc/enable.yml.
The OIDC control is still not reachable by the shared persona helper after the
reload: clickOidcLoginLink prefers the strict locator, and Listmonk's native
submit button's accessible name is exactly "Login" while the OIDC button is
"Login with <name>" -- so the strict matcher takes the wrong control. There is
no setting that hides the native form; cmd/auth.go renderLoginPage hardcodes
PasswordEnabled. appearance.public.custom_js is a real v6.2.0 setting, injected
into /admin/login and served same-origin, so a few lines of JS submit the OIDC
form and the second hop disappears. The shared helper stays untouched, which
keeps the 61 other roles that route through it out of this.
Measured with the helper's own source driving a real browser: no reload ->
no form; reload alone -> reached: false; reload plus custom_js -> reached: true.
The administrator persona is unblocked accordingly. biber stays blocked, and
for the third distinct reason this role has been given: Listmonk matches OIDC
users by e-mail and provisions no biber account, cmd/auth.go OIDCFinish 404s
unless security.oidc.auto_create_users is set, and createOIDCUser needs a real
default_user_role_id -- the seeded database holds only Super Admin.
Three nocheck rationales in playwright.env.j2 asserted things that are false:
that mail delivery is "covered by the sys-svc-mail integration tests" (no such
tests exist; the coverage is in web-app-mailu's own spec), and twice that the
CSP helper asserts the injector origin (personas/utils/csp.js:96 bails with
`if (!host) continue`, and no consumer role renders CSS_BASE_URL). Rewritten to
what is actually true.
Not fixed here, recorded in TODO.md: security.enable_captcha,
security.captcha_key and security.captcha_secret do not exist in v6.2.0 -- the
live table carries one security.captcha object -- so all three UPDATEs match
zero rows and hCaptcha has never been active. Repairing that would switch a
captcha on for the public subscription form, which is a behaviour change nobody
asked for.
Unverified: the logout leg. Whether inAppLogout finds Listmonk's Vue user menu,
and whether assertCspInjections passes against the admin SPA, has not been run.
The first deploy settles both.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
test_has_spec.py forces every roles/web-app-* to ship a Playwright spec and
calls a missing one a hard error, because the persona contract must never be
silently absent from the deploy capstone. Nothing forced the other half. The
runner discovers roles by rglob('templates/playwright.env.j2')
(discover_playwright_roles.py:53), so a spec without that file is staged
nowhere and executed never.
21 of 76 web-app roles were in exactly that state. Verified rather than
inferred: running the discovery filter directly returns 61 roles and none of
the 21 is among them, `make compose-playwright` refuses without a rendered
.env from a prior deploy, and `git log --all` on those paths shows the file
never existed on any branch -- the single hit is web-app-gitlab on a fork
branch. Their specs have never run once. 15 of the 21 deploy in CI today,
reporting green while their only functional verification never fires.
The new lint mirrors test_has_spec and carries a per-role opt-out that is
used nowhere: uniform beats exceptions.
Every one of the 21 now has a template written against its own
meta/services.yml rather than a shared skeleton -- espocrm splits
ADMIN_PASSWORD from ADMIN_NATIVE_PASSWORD because OIDC_ALLOW_ADMIN_USER
leaves both login paths open, the four permanently auth-less roles declare
their personas blocked instead of shipping a knowingly-red spec, and
web-app-mastodon gained a real test-seaweedfs.js because no honest
suppression existed for a role that does route Paperclip to S3.
web-app-magento moves pre-alpha -> alpha here: it now has a spec that runs,
which is what the lifecycle gate is about.
Six meta/services.yml files change only where adding a template falsified an
existing suppression -- gitlab and shopware both claimed the role 'ships no
templates/playwright.env.j2', which stopped being true in this commit.
Not resolved here, and the adversarial review says so plainly: the specs are
enabled, not proven. None has executed against a live stack. The review found
three classes of defect that land in follow-up commits rather than being
smuggled in silently -- persona blocks that are missing or should be tied to
sso.enabled, eleven suppressions naming a sys-svc-mail test suite that does
not exist, and eight claiming a CSP assertion that cannot fire because no
consumer role renders CSS_BASE_URL.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
kevinveenbirkenbachandClaude Opus 5