coulomb-social/workplans/CSOC-WP-0015-communication-runtime-acceptance.md
tegwick 0cc45be42c
Some checks failed
Use-case regression gate / usecase-regressions (push) Failing after 2m31s
Track sender executor completion and credential owner dependency
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a18e2d-f513-7742-b8e7-12af0b744ff3
2026-10-31 17:19:15 +01:00

24 KiB

id type title domain repo status owner topic_slug created updated origin origin_ref state_hub_workstream_id
CSOC-WP-0015 workplan Communication runtime, inbox operations and flow acceptance communication coulomb-social active codex coulomb-social 2026-10-08 2026-10-31 residual CSOC-WP-0010 38208f72-c285-56fa-be44-de9b59a4e031

Residual acceptance from CSOC-WP-0010, split at the user's request. Existing implementation/release/acceptance evidence remains in the originating workplan; these tasks own the remaining concrete outputs. Source checks never grant runtime or productive acceptance.

Current execution map — 2026-10-31

T01 caller policy, T03 independent ledger recovery and the narrowed T04 implementation/native rehearsal/application release are complete. T02 owns the platform sender and return-mail operation. Platform-root with Bernd as human operator is now explicitly accepted; see decision 9392ef52 below. Sender admission, inbox access and return-message correlation remain unverified. Suppression handling and retention also remain open. Backup-specific Gmail receipt does not close those gates. T05 exposes productive flow verdicts and T06 the remaining native reset-authority owner return.

The four-workplan assessment records the scope split and effort estimate. Task counts are not effort percentages. Historical notes retain the evidence trail; this map and the task blocks govern current status. No original acceptance requirement has been dropped.

T01 — Admit and activate explicit transactional caller policies

id: CSOC-WP-0015-T01
status: done
priority: high
state_hub_task_id: "e87ea643-7bee-5427-b4f5-b32f20dc2f29"

Receiver source is implemented and image deployment recorded in EMAIL-WP-0008. EMAIL-WP-0008-T03 owns actual caller/binding/template/operation/quotas, separate token custody/delivery and original-caller transition. Product acceptance verifies the admitted integration; avoid duplicating receiver implementation or granting arbitrary app notifications.

2026-10-27: EMAIL-WP-0008 completed scoped caller custody and coordinated activation on October 9. Current receiver policy/projection and user-engine tenant/client bindings are present, both deployments Ready. Owner no-send denial/replay receipts and the expanded 103-test isolated gate verify the admitted integration. Productive flow verdicts remain T04. See docs/release/acceptance-audit-2026-10-27.md.

T02 — Establish platform sender and monitored reply/bounce ownership

id: CSOC-WP-0015-T02
status: progress
depends_on: [RPF-WP-0068-T04, EMAIL-WP-0010-T04]
priority: high
state_hub_task_id: "0604cb15-72c7-5d15-bb42-0335d4ec80df"

Review replacing the receiver forgejo sender with platform identity through its credential owner, then name reply/inbox/support owner and prove authorized inbound access, DNS MX/SPF/DKIM/DMARC, correlated bounce/suppression and retention. No unsolicited scans or auto responses. Existing native personal reset is accepted and stays separately evidenced.

2026-10-31 concrete follow-through: T02 advanced from todo to progress. User selected platform-root with Bernd Worsch as human operator for platform-mail replies/bounces, including registration/invitation; decision9392ef52-3bfe-42fd-b6d5-ec0730656775 is resolved. Native generation74/source hashes confirm the receiver still uses forgejo@coulomb.social and has no admitted suppression caller. Four authoritative nameservers agree on MX/SPF/DMARC and three documented DKIM CNAMEs. This is DNS publication evidence, not delivered-message authentication.

Prepared three scoped SMTP projection resources and exact sender/environment patches; all five native server dry-runs pass with unchanged image/PVC/caller policy and unrelated spec. New consumer custody now has the prepared owner controller below; live admission and supervised sender rollout remain pending, so execution_ready is false. Offline actual-owner-source proof shows accepted Message-ID/bounce correlation and scanner deduplication, but no scanner-to-transactional suppression bridge; the existing operator API works only under synthetic admission and affects a recipient across callers/tenants. No production send, mailbox scan, credential read or runtime change occurred. Concrete packet and remaining sequence: docs/release/platform-mail-sender-review-2026-10-31.md. Owner identity need not be asked again. Next: fixed owner SMTP admission and supervised sender rollout; bounded operator return handling plus retention and productive access proof.

Owner follow-through is now a live dependency: railiance-platform RPF-WP-0068 (c042789b-4d7f-5c55-8d49-39dd16500f41), CCR-2026-0056. Its T01 fixed reader/helper and T02 supervised foundation/controller preparation are complete; T03 waits for platform/consumer review and founder admission, and T04 owns the native return. The complete controller passed41 SMTP tests and three native server dry-runs. The target Secret is absent by metadata-only query. It verifies native SA binding, guarded read admission, workload login/denials/revocation and projection Ready, with a private durable phase journal and no sender change. Live execution has not occurred; this is not yet verified custody or delivered-message acceptance. See docs/release/platform-mail-custody-preparation-2026-10-31.md for the owner review packet and exact closure conditions. This dependency is tracked as work, not left only in this task's progress narrative.

2026-10-31 sender-boundary follow-through: EMAIL-WP-0010 now owns the separate supervised sender configuration transition. Its T01 provides a tested read-only ledger observer and native return at15:16:41Z: all six tables,2accepted invitations, 121accepted verification sends,1suppression and no uncertain outcomes. The source matches the packaged receiver. The observer correctly gives delivery receipts precedence over retained in_flight invitation rows and uses one transaction so concurrent WAL writes cannot split the result. No rows, passwords or mail were printed or changed. This clears current-state investigation only; it is not a writer fence or rollout approval. Owner T02 still requires the complete executor and interrupted-execution/rollback proof; T03/T04 retain execution and native return after RPF-WP-0068. Evidence: sender boundary review. All existing recipient, reply ownership and separate credential-admission decisions persist.

The owner sender task EMAIL-WP-0010-T02 is now progress: its protocol core has durable intent records, exact configuration changes and explicit recovery that captures the current ledger instead of restoring an older one. All 27 new cases pass, including 10 real process exits with modeled cluster effects and actual SQLite/retry behavior. The owner suite reports 219 passed / 21 existing optional harness skips. This does not establish native execution: adapter/custody/fencing, helper lifecycle, runtime verification and the sealed attended packet remain open in that same task. Evidence: protocol review.

Native adapter preparation now adds exact UID/spec changes, metadata-only Secret queries, foundation receipt/projection checks, the shared capture lock, PVC writer fencing, durable helper identities/cleanup and runtime denial checks. Five native server dry-runs passed without changing production. The actual snapshot/replay path passed in the pinned receiver image with synthetic data and no network; the disposable container was removed. Thirty new cases pass; owner suite is now 249 passed / 21 existing optional harness skips. Evidence: native adapter review. EMAIL-WP-0010-T02 remains progress pending the complete source-bound capsule, attended entry point, assembled forward/recovery proof and exact review packet. The separate owner credential admission, native sender execution/return and productive inbox/bounce/user verdicts remain open. No grant, deployment change, production capture or email send was performed by these checks.

The owner executor now has its attended entry point and eight-file source-bound capsule path. Twenty-one additional assembly cases pass with the actual coordinator, protocol and native adapter against modeled Kubernetes, real SQLite subprocesses and actual scoped WSGI runtime probes; owner suite is 270 passed / 21 existing optional harness skips. EMAIL-WP-0010-T02 has moved to wait on RPF-WP-0068-T04: sealing a live proposal requires the completed credential-owner handoff and its successful foundation receipt. A real preparation invocation refused that missing handoff before contacting the node or writing a capsule. After the return, fresh native sealing and the exact review packet finish T02; execution/acceptance remain T03/T04. Evidence: attended entry review. This consumer task stays progress because sender/inbound/bounce and productive acceptance obligations are still open.

T03 — Complete independent ledger recovery and copy custody

id: CSOC-WP-0015-T03
status: done
priority: high
state_hub_task_id: "286e60bf-76a1-5a18-bd2c-edd9d1400c41"

EMAIL-WP-0007-T03/T04 and RPF-WP-0053-T05/T06 own primary archive admission/atomic credential pair, first encrypted capture/retrieval/rehearsal and monitoring. Require image/schema-bound six-table recovery, restored accepted/unknown/consumed/cancelled/suppressed/quota continuity and post-capture reconciliation; govern temporary pre-release copies.

2026-10-27: EMAIL-WP-0007 completed independent provider escrow, separately bound recovery reader, nonexpiring image/tools/receipt kit, six-table offline recovery, mirrored rolling archives and monitored schedules on October 10. Fresh checks show both timers active and today's backup/freshness successful, with verified mirror. The app gate now binds real encryption/recovery and scoped quota continuity tests; 103 owner cases pass with zero skips. Historical private copies remain retained pending explicit owner disposition, with no inferred expiry/deletion. Production restore still requires fencing and post-capture reconciliation. See the audit.

T04 — Implement, rehearse and release owner-spanning browser journeys

id: CSOC-WP-0015-T04
status: done
priority: high
decision_id: "75b94bb6-4709-495f-91fe-43e53e2867ed"
state_hub_task_id: "7c718d86-8f0d-5cb2-a765-b0c07116005c"
needs_human: false

Current scope after the October 31 tracking audit: The owner-source and native isolated browser gates plus the exact revision 19 application release are complete. Productive UC-010/011 verdicts, current Case B and any remaining reset review continue in T05; the native reset-authority owner return continues in T06. Existing personal reset acceptance remains preserved. This split does not promote unaccepted journeys to established.

Earlier dated notes below are retained as history, not the current task state.

Use isolated issuer/directory/local mail sink/app for UC-009/010/011. Bind exact mandatory browser nodes without production URLs/accounts or SMTP provider sends; test expired/replayed handles and tenant/client/caller denials. Future UC-012 needs a user-selected product template/caller. Preserve UC-008 manual mail distribution and UC-009 existing personal reset acceptance.

2026-10-11: the checkout has a loopback issuer, directory and mailbox double. The browser node is bound on UC-009/010/011 and still established: false. It covers reset-to-local-mailbox, sign-in, callback replay, expired and reused handles, tenant and client refusal, registration verify/cancel, and caller/suppression invitation counts. No SMTP, production account, or live issuer is contacted. Real user-engine/email-connect admission, DNS and productive per-flow verdicts remain open. UC-012 stays deferred. Gate for this slice: make check 200 passed.

2026-10-30: added an explicit real-owner-source browser gate for UC-010/011. Private snapshots run the actual user-engine portal, registration/outbox HTTP adapters and email-connect scoped receiver/SQLite ledger, with synthetic session, authorization, directory, activity sink and mail provider. Actual forms cover verify/cancel/expiry/replay, fresh-handle cross-caller denial, tenant/client/token denials, cross-tenant admin refusal, invitation/resend, duplicate delivery and suppression. Python only permits fixture ports; browser routes/API redirects are bounded to fixture origins. No production configuration, account, SMTP provider, mailbox scan or original note body is used. Exact node is linked in the candidate registry and the invocation is in docs/usecases/platform-communication.md. Proof: docs/release/owner-communication-browser-2026-10-30.json. This completes the owner-source UC-010/011 browser integration slice, not native issuer/directory/ app-login coverage or productive per-flow verdicts. T04 remains progress; T02 sender/inbound/bounce ownership and UC-012 nomination remain separate gates.

2026-10-30 UC-009 callback follow-through: signed-token reproduction found that optional UserInfo could replace verified identity/tenant/assurance claims and a token-response userinfo object could bypass the ID-token requirement. Corrected the app assembler to require the verified token, exact UserInfo subject equality and profile-only enrichment.13 real RSA/JWKS callback cases cover refusal, authority preservation, step-up denial and optional-UserInfo fallback;20 focused identity cases pass. Candidate registry links added without promoting UC-009. Review: docs/release/oidc-userinfo-binding-review-2026-10-30.md. This source is not in the sealed17d0eb6storage image; a subsequent reviewed release is required. Full native reset/directory/inbox/app browser coverage and productive verdicts remain open. No production login, issuer change, mail or deployment performed. Full make check:396 passed, zero skips; all newly linked UC-009 fast node IDs are present in its JUnit report. Bounded proof and source hashes are retained in docs/release/oidc-userinfo-binding-review-2026-10-30.json.

2026-10-30 native recovery prerequisite: added an isolated pinned Authelia4.39.28/ LLDAP0.6.2 rehearsal with no ports, host mounts or external routes. The strict read-only bind from NetKingdom's source permits first factor and reset-link verification but refuses password update (HTTP200/KO); the synthetic password- manager bind succeeds and actual old/new directory authentication switches. Both refuse consumed-link replay, unverified reset, interactive service sign-in and directory group creation. All containers removed; generated fixture values remain private. Review/evidence: docs/release/native-password-reset-review-2026-10-30.md and native-password-reset-2026-10-30.{json,sources.txt}. Retain the supported narrow reset-authority review on the existing NK-WP-0054-T05 owner boundary; no live grant, installed-role conclusion or provider task duplication. Full browser/ expiry/mail-sink/KeyCape/app coverage and productive release remain open here. Final source-bound native proof includes verified cleanup and three CLI refusal cases. Full make check rerun:396 passed, zero skips, mandatory browsers included.

2026-10-31 native browser follow-through: the exact explicit node scripts/native_recovery/test_journey.py::test_native_reset_directory_smtp_issuer_and_app passes with zero skips. Real Authelia UI/LLDAP/SMTP-to-local-sink exercise read-only refusal, successful password replacement, expired and replayed native links. Real KeyCape PKCE/JWT plus the current app source and actual user-engine HTTP claims service establish the app session; old-password and callback replay, unknown-client, wrong-redirect and explicit directory/client tenant-conflict controls refuse. One owner user/Member and unusable local password are verified. Kernel network-none/loopback, scoped browser requests and all-container cleanup are verified. Owner storage/PDP are fixtures; no productive grant, MFA or TLS trust-store acceptance. Review/proof: docs/release/native-recovery-browser-review-2026-10-31.md and native-recovery-browser-2026-10-31.{json,sources.txt}. Candidate registry binds the node without promotion. Existing NK-WP-0054-T05 reset-authority return, productive UC-010/011 verdicts and deployment/runtime acceptance remain open. Full make check:396 passed, zero skips. Four separate synthetic JUnit-envelope checks refuse wrong/skipped/failed/extra nodes without publishing a proof; the real native gate itself passes its exact one node with zero skips.

2026-10-31 packaged OIDC fix: candidate source 23ffe2c is published at immutable digest 522bcd7f and independently verified against the registry and all 80 packaged source files. All 25 OIDC/export focused tests pass inside that image, with actual packaged application imports, no source overlay, network none and synthetic identity peers. Python and all 25 runtime distribution versions match the live image. Source full gate 441 passes; recovered-store candidate/previous-image view checks also pass. Review: docs/release/identity-export-candidate-review-2026-10-31.md. The fix remains undeployed pending its separate exact current-target release packet and supervised execution. Native owner/productive verdicts, sender and inbox ownership remain open; this image publication grants no such acceptance.

2026-10-31 supervised release preparation: separate owner image-only controller and 16-member capsule9f1daf6c pass 19 release safety tests, lint/compile and native read-only preflight against revision18 and the post-correction dataset. It requires the existing migration/global constraint, preserves migration history and full business/content hashes, captures/readbacks a fresh paired primary before Helm, and verifies postflight plus any image/helper rollback. Default live values and installed helper remain unchanged. The completed storage launcher is not reused. Owner execution is RAPPS-WP-0015-T05; open decision75b94bb6. Concrete founder steps and evidence: docs/release/identity-export-release-review-2026-10-31.md. Execution, independent current-point recovery/export and productive flow verdicts remain open.

2026-10-31 founder image-release return: proposal9f1daf6c completed at07:15:24Z, Helm revision19/image522bcd7f. Independent complete-spec/Ready/identity checks, all80packaged source hashes, unchanged92business rows/86files/migration history, 40owner renders/40outsider denials, public endpoints and refreshed helperdcc8dd2a all pass. Live owner values/product pins are reconciled. Fresh07:13 primary point is mirrored, independently retrieved and restored (13tables/114rows/86files); packaged client export verifies85files without source mutation. Full make check 441passes, zero skips. Release decision75b94bb6 is resolved only for that exact execution; RAPPS-WP-0015-T05 is complete. Productive flow and service/offboarding acceptance remain open. Return: docs/release/identity-export-release-return-2026-10-31.md.

T05 — Obtain productive registration and invitation flow verdicts

id: CSOC-WP-0015-T05
status: todo
priority: high
state_hub_task_id: "120ec9a8-6340-576f-8a3c-b8139c0dc25a"

Acceptance scope split from T04: current Case B, UC-010 registration and UC-011 invitation/resend/cancel/expiry behavior need private owner-spanning productive review and explicit verdicts. Preserve existing UC-009 personal-reset acceptance and UC-008 manual distribution; review only remaining reset differences. Keep each gap as live work and do not promote candidate journeys from isolated tests alone. UC-012 remains deferred pending an explicitly selected template/caller, not an implied requirement to add arbitrary notifications. Review sources: docs/usecases/platform-communication.md and docs/identity/smoke.md.

T06 — Verify the native reset-authority owner return

id: CSOC-WP-0015-T06
status: progress
depends_on: [NK-WP-0054-T10]
priority: high
state_hub_task_id: "e17a6d09-1fdd-5fa1-a36d-763802e37f7f"

Remaining owner admission from T04 is canonical NK-WP-0054-T10, the explicit reset follow-through to the completed T05 bind split. Isolated native Authelia/LLDAP reset and full browser integration are proven, including read-only-bind refusal and successful scoped password replacement. Obtain and assess the owner native authority/runtime return; preserve MFA/TLS/directory boundaries and link acceptance here. Do not create a duplicate provisioning lane or infer a live grant from the synthetic proof. Evidence: docs/release/native-recovery-browser-review-2026-10-31.md and native-password-reset-review-2026-10-30.md.

2026-10-31 owner-return assessment: NK-WP-0054-T05 is now done and its founder bind migration plus restore drill have been inspected. They prove sign-in/MFA, not post-split password change. Current native ConfigMap uses svc-authelia; both Ready native images match our isolated proof, and the dated owner receipt assigns strict-readonly. This establishes an unclosed reset-authority requirement, not a claimed production reset attempt. NK-WP-0054-T09 records the completed assessment; T10 now owns supported reset authority, preparation, explicit admission, native return and recovery verification in the same owner workplan. T06 advanced to progress for this assessment and consumes T10; it cannot close on T05's done label. Evidence: docs/release/reset-owner-return-assessment-2026-10-31.json. No credential, mail, password, directory grant or live configuration was changed. Prior personal reset acceptance is preserved with its original date and scope.

2026-10-31 authority preparation: owner T11 records the native role matrix; T10 is progress. Password-manager permits ordinary/application-admin/non-admin service password changes but refuses LLDAP administrators. Seven other directory writes per role refuse with valid admin controls. Ten direct cases and eight Authelia flows pass; all containers removed. Full gate546 and original reset regression pass. Detailed scope and next admission conditions are in native-password-reset-review-2026-10-30.md and reset-authority-validation-2026-10-31.json. A complete runtime proposal still needs current subject classification and, if that subject is an LLDAP administrator, its supported recovery route. T06 remains progress, with no live grant, reset or productive acceptance inferred.

2026-10-31 observation preparation: the retained personal acceptance identifies tegwick. Technical decision8770d4ea binds the current-role check to that exact account and makes administrator recovery conditional on its actual role, preserving the original contract. Owner T12 is done: a fixed read-only observer passes92 unit/transport checks and native LLDAP classification/metadata-preservation checks. T13 waits for the human admin's private terminal authentication and credential-free JSON return. The concrete command and limits are in the native-reset review; reset-observer-preparation-2026-10-31.json binds sources/tests. T06 remains progress; no actual directory-role observation, password change or grant is claimed.

2026-10-31 attended role return: founder supplied the12:57:44Z observation. Independent private-file and source-hash verification passes; owner T13 is done. svc-authelia has only strict-readonly, while the accepted tegwick subject is not an LLDAP administrator (one other group, name not disclosed). This resolves the classification dependency. T10 can prepare the reviewed password-manager transition; its broad non-admin reach remains part of admission. No directory-admin recovery route is needed for this accepted flow on the observed roles, and no new policy, password change or productive reset acceptance is inferred. Evidence: reset-role-observation-2026-10-31.json and reset-role-return-verification-2026-10-31.json.

Completion

Finish when every task above has its stated evidence and acceptance, or hand off any newly discovered residual to a live work record first. Cross-owner dependencies remain their existing canonical records.

2026-10-31 reset transition preparation: owner T14 prepares the source-bound, crash-recoverable role controller; T15 explicitly holds founder admission and execution; T16 holds source alignment, productive reset/app/MFA and identity backup/restore acceptance. The same running Authelia process picks up grant and rollback in the confined native fixture. Membership rollback does not revoke HTTP tokens issued during a grant; the review includes their up-to-24-hour scope. No production role/password changed. T06 remains progress and consumes owner T10, whose acceptance is preserved rather than closed by fixture proof.