coulomb/coulomb-social
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: record reset receipt and personal login 500 deployment correction
Some checks failed
Use-case regression gate / usecase-regressions (push) Has been cancelled
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a10e2d-a5ef-7e92-b03d-b1694e915680
This commit is contained in:
tegwick 2026-10-06 20:52:27 +02:00
parent 0f3338f858
commit 1292539069
8 changed files with 133 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

8
SCOPE.md
View file

@ -66,8 +66,9 @@ the tested app (source ac7bac1852c9, chart 0.2.0, digest pinned) with a retained
2Gi CONTENT_ROOT PVC and one writer/Recreate. OIDC client registration was restored
and KeyCape restarted; authorization now hands off to Authelia. Public health,
clipboard asset delivery, zero pending migrations and content restart durability
passed. Interactive tegwick sign-in remains blocked: Authelia rejects the attempted
credentials although a read-only directory check confirms the account exists.
passed. The user confirmed fresh reset-mail receipt, then reported app500 after
authentication. Revision11 corrects a stale user-service URL with the same image;
successful interactive workspace access remains pending.
Real-use-case acceptance remains pending;
[deployment receipt](docs/release/personal-account-deployed-2026-10-06.md) records
exact evidence and gaps. All six original numbered workplans are finished;
@ -106,6 +107,7 @@ acceptance remains CSOC-IN-0005. User transfer acceptance stays separate.
Platform email facilities are tracked in CSOC-WP-0010. Shared email-connect
and platform mailbox custody exist outside this repo; Authelia reset SMTP
is now active from platform@coulomb.social; actual inbox/account acceptance
is now active from platform@coulomb.social; actual inbox receipt is confirmed.
Full personal-account acceptance
remains pending. See
[platform mail assessment](docs/release/platform-email-2026-10-06.md).

2
WORK-RECORDS.md
View file

@ -70,7 +70,7 @@
| task | CSOC-WP-0009-T03 | done | — | workplans/CSOC-WP-0009-usecase-regression-infrastructure.md |
| task | CSOC-WP-0009-T04 | done | — | workplans/CSOC-WP-0009-usecase-regression-infrastructure.md |
| task | CSOC-WP-0010-T01 | done | — | workplans/CSOC-WP-0010-platform-email-facilities.md |
| task | CSOC-WP-0010-T02 | progress | — | workplans/CSOC-WP-0010-platform-email-facilities.md |
| task | CSOC-WP-0010-T02 | done | — | workplans/CSOC-WP-0010-platform-email-facilities.md |
| task | CSOC-WP-0010-T03 | wait | — | workplans/CSOC-WP-0010-platform-email-facilities.md |
| task | CSOC-WP-0010-T04 | todo | — | workplans/CSOC-WP-0010-platform-email-facilities.md |
| task | CSOC-WP-0010-T05 | todo | — | workplans/CSOC-WP-0010-platform-email-facilities.md |

8
docs/release/personal-account-deployed-2026-10-06.md
View file

@ -57,3 +57,11 @@ another service. No password was requested/read/exported or reset. Authelia's
current notifier is filesystem rather than SMTP: do not promise emailed recovery
or expose reset tokens from notification files. Any credential reset must use
the owning attended recovery/setup lane under a separate exact approved change.
## Latest result and correction
Fresh reset email receipt confirmed by the user; credentials progress through
authentication, then app returns500. Revision11 corrects the stale user-service
URL with the same immutable image. See personal-login-500-2026-10-06.md.
Successful workspace access remains pending; earlier notifier/credential
statements above describe the pre-SMTP stage rather than current runtime.

49
docs/release/personal-login-500-2026-10-06.md Normal file
View file

@ -0,0 +1,49 @@
# Personal login HTTP500 correction — 2026-10-06
The user confirmed receipt of a fresh platform password-reset email, then
reported Server Error500 after authentication. End-to-end personal app login
is not yet accepted. CSOC-WP-0008-T11 and CSOC-WP-0010-T03 remain wait.
## Diagnosis
The app's identity-linking client requests /api/v1/me on USER_ENGINE_BASE_URL.
The deployed historical address https://users.92-205-62-239.nip.io returns302
to https://users.coulomb.social/api/v1/me. httpx does not follow redirects by
default; raise_for_status rejects302. establish_session calls that client
before recording last_login_at or establishing the Django session; its failure
is uncaught by the callback. This explains the reported symptom; raw traceback
was not available from the production app's recent stdout log.
Credential-safe in-pod probes send an empty claims envelope (no subject/issuer)
using the configured service credential internally: old address302; canonical
address400 missing claims. This establishes the canonical address accepts the
service credential without creating an identity, sending email, exporting
credentials or impersonating the user. It does not prove full signed-in use.
## Correction deployed
Owning railiance-apps main commit3f8276e changes USER_ENGINE_BASE_URL in chart
defaults and production overrides to https://users.coulomb.social. Helm lint
passed. Node-side server dry-run and parsed manifest comparison passed, proving
only that environment value changes. Image, Secret references, issuer/client/
tenant, PVC, access rules and every other manifest field remain unchanged.
This completes the personal app deployment already approved by the founder
(“Go on and deploy the interruption is not a problem.”), decision
8bbce691-a787-4140-9cd4-df06e8635a27. Authority: ADMINISTER @
realm:kubernetes/railiance01, activation=APPROVED. Node IP verified92.205.62.239.
Node-side Helm --reuse-values --atomic --wait --timeout5m succeeded: release
coulomb-social revision11 deployed, chart0.2.0, same image digest
sha256:bf975939e22b9b0a5d9ac05584ae6265ba201169df6dc48e506ec684b30a9c58.
One of one replicas available. Public /healthz and landing200, login302.
Post-deploy in-pod empty-claims probe confirms canonical base URL,400 response
and no redirect using the existing service credential (probe exit0).
Rollback target: Helm revision10, which restores the historical URL.
## Acceptance
The user was asked to start a fresh sign-in at
https://app.coulomb.social/auth/login/ and report workspace access or error.
Only that successful interactive flow closes personal-login acceptance.
Inbox receipt is accepted separately. No private protocol was imported and
Bubble remains on the apex.

13
docs/release/platform-email-active-2026-10-06.md
View file

@ -42,13 +42,14 @@ coulomb-social client and S256 PKCE; authorization302 hands off to Authelia.
An initial KeyCape discovery check during the restart was transiently unsuccessful;
readiness/discovery and complete handoff checks passed on retry afterward.
## Actual user acceptance remains open
## Inbox receipt confirmed; app acceptance remains open
User asked to request a NEW Passwort zuruecksetzen for tegwick, confirm delivery
to their existing directory email, set a password privately and complete app
sign-in. Delivery readiness and startup SMTP check do not prove inbox receipt
or user recovery. CSOC-WP-0010-T03 and CSOC-WP-0008-T11 remain waiting for that
confirmation; NK-WP-0047-T03 owns the authentication review.
The user confirmed: “The reset email arrived.” This proves actual inbox receipt
for the fresh reset request independently of SMTP startup/provider acceptance.
The subsequent login reaches a Server Error500 page; app acceptance remains
open in CSOC-WP-0010-T03 and CSOC-WP-0008-T11. NK-WP-0047-T03 retains the
authentication review. See personal-login-500-2026-10-06.md for diagnosis and
correction. No complete app sign-in is inferred from email delivery.
The agent sent no test email, read no reset URL/mail body/password, changed no
user password and imported no ReichelAg data. Subsequent notifications and

47
history/20261006T185202Z-personal-login-500-correction.md Normal file
View file

@ -0,0 +1,47 @@
# Personal login HTTP500 correction — 2026-10-06
The user confirmed receipt of a fresh platform password-reset email, then
reported Server Error500 after authentication. End-to-end personal app login
is not yet accepted. CSOC-WP-0008-T11 and CSOC-WP-0010-T03 remain wait.
## Diagnosis
The app's identity-linking client requests /api/v1/me on USER_ENGINE_BASE_URL.
The deployed historical address https://users.92-205-62-239.nip.io returns302
to https://users.coulomb.social/api/v1/me. httpx does not follow redirects by
default; raise_for_status rejects302. establish_session calls that client
before recording last_login_at or establishing the Django session; its failure
is uncaught by the callback. This explains the reported symptom; raw traceback
was not available from the production app's recent stdout log.
Credential-safe in-pod probes send an empty claims envelope (no subject/issuer)
using the configured service credential internally: old address302; canonical
address400 missing claims. This establishes the canonical address accepts the
service credential without creating an identity, sending email, exporting
credentials or impersonating the user. It does not prove full signed-in use.
## Correction deployed
Owning railiance-apps main commit3f8276e changes USER_ENGINE_BASE_URL in chart
defaults and production overrides to https://users.coulomb.social. Helm lint
passed. Node-side server dry-run and parsed manifest comparison passed, proving
only that environment value changes. Image, Secret references, issuer/client/
tenant, PVC, access rules and every other manifest field remain unchanged.
This completes the personal app deployment already approved by the founder
(“Go on and deploy the interruption is not a problem.”), decision
8bbce691-a787-4140-9cd4-df06e8635a27. Authority: ADMINISTER @
realm:kubernetes/railiance01, activation=APPROVED. Node IP verified92.205.62.239.
Node-side Helm --reuse-values --atomic --wait --timeout5m succeeded: release
coulomb-social revision11 deployed, chart0.2.0, same image digest
sha256:bf975939e22b9b0a5d9ac05584ae6265ba201169df6dc48e506ec684b30a9c58.
One of one replicas available. Public /healthz and landing200, login302.
Rollback target: Helm revision10, which restores the historical URL.
## Acceptance
The user was asked to start a fresh sign-in at
https://app.coulomb.social/auth/login/ and report workspace access or error.
Only that successful interactive flow closes personal-login acceptance.
Inbox receipt is accepted separately. No private protocol was imported and
Bubble remains on the apex.

11
workplans/CSOC-WP-0008-production-transfer-acceptance.md
View file

@ -353,3 +353,14 @@ Platform reset mail is now active through native Authelia SMTP from platform@.
CSOC-WP-0010-T02 completed; T11 remains wait until user receives a fresh reset,
changes the password privately and completes actual app login. See
docs/release/platform-email-active-2026-10-06.md.
## Personal sign-in HTTP500 diagnosis — 2026-10-06
User confirmed fresh reset mail arrival, then reported app500 after authentication.
Contained in-pod HTTP probes with empty verified-claims envelopes create no
identity: old user-engine address returns302 redirect, canonical endpoint400
missing claims using the existing credential. Application httpx rejects302;
identity-linking failure occurs before local session creation. Owning
RAPPS-WP-0015 corrects only USER_ENGINE_BASE_URL with the same immutable image
and existing approval8bbce691-a787-4140-9cd4-df06e8635a27. T11 remains wait for
fresh successful personal app sign-in. See docs/release/personal-login-500-2026-10-06.md.

5
workplans/CSOC-WP-0010-platform-email-facilities.md
View file

@ -103,3 +103,8 @@ scoped store/projectionReady, native configuration Job succeeded18:31:49Z,
reviewed notifier/mount rollout generation 28 healthy1/1; public auth/app/issuer
and full authorization handoff pass. T02 done; T03 waits actual reset inbox/recovery
and personal signin. Receipt: docs/release/platform-email-active-2026-10-06.md.
User acceptance update: fresh reset email arrived (user confirmation). Login
then reaches app HTTP500. Inbox delivery is accepted; full personal app sign-in
remains open. See docs/release/personal-login-500-2026-10-06.md. T03 stays wait
for post-correction interactive acceptance, not mail-provider readiness.