user-engine/docs/evidence/2026-09-13-p05-service-operations.md
tegwick 38b041385e
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Account journey acceptance / journeys (push) Successful in 6s
Record verified P05 rollout and service recovery acceptance
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a092fe-13b1-7f12-ac74-7d258af4d79c
2026-09-13 22:31:16 +02:00

89 lines
5.3 KiB
Markdown

# P05 service operations acceptance — 2026-09-13
USER-WP-0032 implements P05 under USER-WP-0030-T03. P06 remains separate.
## Operator journey
Platform administration → Service recovery displays bounded checks for directory,
primary sign-in, authenticator provider, mounted factor-read credential, mail store
and SMTP authentication. Each has impact and recovery guidance. Checks submit no
email. Provider acceptance, inbox receipt and functional sign-in are distinct.
Find one delivery by ID or support reference. Review delivery attempt presents a
CSRF/session-bound confirmation of that exact record. Changing state invalidates
confirmation. Failed claims are released, completed records cannot be submitted
again, and event operations serialize across DB connections. Queueing alone does
not send; no background production backlog processor was enabled.
Selected invitation records show mail evidence from the existing authenticated
mail lane. Durable per-event mail reservations survive process restart and lost
post-send writes. Definitely failed attempts can be retried. Uncertain SMTP
outcomes block resending and require provider reconciliation or assisted account
setup. Provider errors are classified; raw exception text is not stored/shown.
## Automated acceptance
- Full portal suite against disposable PostgreSQL: **227 passed, zero skips**,
including two independent connections submitting one event exactly once.
- Browser suite: **23 checks passed**, including selected review, failure,
retry, completed-send guard and visible receipt limits.
- email-connect: **89 tests passed**, including real loopback GreenMail SMTP/IMAP,
uncertain post-send write/restart and SMTP QUIT failure regression.
- `scripts/p05_mail_acceptance.py`: portal → HTTP adapter → email-connect →
real SMTP/IMAP, deliberately failed audit response, confirmed retry; exactly
one test message received and both delivery lanes finally accepted.
- KeyCape full Go suite passed. Installed-provider Job
`mfa/provider-p05-contract-01` passed genuine JWT expiry, fresh-session recovery,
expired predecessor rejection, permission withdrawal/recovery and existing
enrollment/replacement/recovery contract in isolated SQLite/audit databases.
- Native `scripts/keycape_factor_acceptance.py` passed Job
`keycape-factor-proof-91ea82cd`: wrong service account, issuer-password and
sibling-secret denials; mounted custody match; per-user lookup acceptance;
provider-administration denial; mounted rotation acceptance; proof-session
revocation. Renewal Job `keycape-factor-rotate-91ea82cd` succeeded.
Reproduce portal DB tests with USER_ENGINE_POSTGRES_TEST_DSN and
USER_ENGINE_POSTGRES_TEST_RESET=1 pointing only at a disposable PostgreSQL DB.
Run `make test-browser-journeys`. For SMTP acceptance, start the email-connect
GreenMail harness, then run `PYTHONDONTWRITEBYTECODE=1 python3
scripts/p05_mail_acceptance.py` with sibling email-connect source available.
GreenMail image used: `greenmail/standalone:2.1.12@sha256:9f32971b4f25d32b4de6fa2e297423768441c65e4541f6aecd7631c890a229a7`.
## Evidence ceiling and rollback
All sent messages used loopback test mailboxes. Live validation is non-sending;
no production invitation or backlog was processed. Registration OTP/client policy
and real invited-person email receipt remain their own user/P06 journeys.
Mail schema changes are additive. Preserve send_attempts and deliveries. Before
rolling email-connect back to a pre-P05 image, stop delivery and reconcile any
in_flight reservations: older code does not enforce this duplicate-send guard.
Portal/KeyCape rollback preserves existing credentials/configuration. Replacing
KeyCape's single issuer instance may require restarting an in-progress sign-in.
## Release and live readback
All source/image CI passed: user-engine runs 170/171/172, KeyCape 62/63,
email-connect 24/25/26. Exact CI-built images:
- user-engine source `ac0eb14`: `forgejo.coulomb.social/coulomb/user-engine@sha256:8c55d285123c70c453752e19fa1b0ed179cb7fe060e854040fa1c559748a1ebf`
- key-cape source `aa709fb`: `forgejo.coulomb.social/coulomb/key-cape@sha256:d3c358ec793b59d519ea6b1dbe4172449745a57504474399984de6cd8703024d`
- email-connect source `8984a84`: `forgejo.coulomb.social/coulomb/email-connect@sha256:e095d7e51c68a29ff6b82d735c734d5d27e0041b937dc958ecee5bcb5ddf5e8b`
All three deployments rolled out successfully. Portal public /healthz and /readyz
and KeyCape /readyz return 200. Anonymous /platform/operations returns 403.
The running portal queried both dependencies with its existing service credentials:
LLDAP, Authelia, privacyIDEA and factor_reader all report ok; mail database and
SMTP authentication both report ok, message_sent=false and
inbox_receipt_verified=false. No credential values were printed or copied.
Email invitation URL is corrected from the historical nip.io address to
https://users.coulomb.social. A pre-existing live imagePullPolicy=Never blocked
the first mail replacement; it was corrected to canonical IfNotPresent, and the
verified digest then rolled out. Source manifests preserve both corrections.
RPF-WP-0040 is finished. Repo Manager synchronized commit
817c122d07aba02636b6deb8fe23d955d3c15e73 with equal expected/derived commit on
the primary railiance01 projection. Existing NK-WP-0033 retains the historical
resolver incident; KEY-WP-0035 and USER-WP-0030-T03 retain P06 policy/onboarding.