user-engine/docs/evidence/2026-09-13-p05-service-operations.md

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.