docs: record Go RDS TLS diagnosis

.project-docs/30-worklog/tasks/20260816-diagnose-go-rds-tls-9c4a7e21.md

@@ -0,0 +1,97 @@
+# Task: Diagnose Go RDS TLS startup failure
+
+## Identity
+
+- Task ID: 20260816-diagnose-go-rds-tls-9c4a7e21
+- Mode: Feature
+- Branch: main
+- Worktree: D:\Datas\OthersProjects\NianAIGC
+- Base commit: bb50d06d1da67556571eb5e0fdb7312339842e71
+- Owner: codex
+- Status: Ready for Integration
+
+## Scope
+
+- Diagnose the Go API startup failure whose root error is PostgreSQL `server
+  refused TLS connection` during first-super-administrator account listing.
+- Verify the repository TLS defaults and ACK Secret contract without reading
+  or exposing production credentials.
+- Keep the task diagnostic-only; do not change application behavior or mutate
+  the live ACK/RDS environment without cluster access and explicit operational
+  execution.
+
+## Intent And Constraints
+
+- Build a deterministic local PostgreSQL wire-protocol feedback loop that
+  exercises the real Go administration list path.
+- Separate confirmed protocol behavior from the unverified live RDS control
+  plane setting.
+- Prefer verified TLS for production; document `sslmode=disable` only as a
+  deliberate plaintext fallback when the operator accepts that tradeoff.
+- Redact credentials and delete all temporary diagnostic code before finish.
+
+## Outcome
+
+- Confirmed the Go PostgreSQL configuration defaults to `verify-full` when
+  `DATABASE_URL` omits `sslmode`; the checked-in Secret example also specifies
+  `verify-full` and an RDS CA path.
+- Reproduced the exact production error chain against a local PostgreSQL
+  protocol endpoint that returns `N` to `SSLRequest`: `list accounts` -> `list
+  administration accounts` -> `tls error (server refused TLS connection)`.
+- Re-ran the identical administration query path against the same endpoint
+  with `sslmode=disable`; it passed. This isolates the failure to a mismatch
+  between client TLS mode and endpoint TLS capability, before credentials,
+  grants, schema, or bootstrap creation are evaluated.
+- The most likely live cause is that the RDS instance/selected connection
+  address does not have SSL enabled while the deployed `DATABASE_URL` requests
+  verified TLS. Wrong endpoint/port or a TLS-refusing intermediary remain
+  lower-probability alternatives until checked from the Go Pod/RDS console.
+- No product source, deployment manifest, or canonical project-memory file was
+  changed. The temporary diagnostic test was deleted.
+
+## Verification
+
+- RED: `go test ./internal/application -run
+  TestDiagnosticListAccountsAgainstTLSRefusingEndpoint -count=1 -v` reproduced
+  the exact `server refused TLS connection` error on the production query path.
+- GREEN: with diagnostic mode set to `disable`, the same command and fake
+  endpoint passed.
+- A credential-free SSLRequest probe to the real RDS host timed out from this
+  workstation; this is consistent with a private/VPC endpoint but does not
+  establish the RDS SSL setting.
+- `kubectl config current-context` reported no configured context, so no live
+  Secret, Pod DNS result, or RDS endpoint was inspected or mutated.
+- Alibaba Cloud's current RDS PostgreSQL documentation confirms that SSL must
+  be enabled for SSL-mode connections, `disable` is the non-SSL client mode,
+  and enabling/changing the protected address restarts the instance with a
+  minute-level interruption risk.
+
+## Follow-ups
+
+- In the RDS console, verify whether SSL is enabled and whether the protected
+  connection address exactly matches the host used by the Go Pod.
+- Recommended production repair: enable RDS SSL for that address, mount the
+  downloaded CA as `zhinian-rds-ca`, retain `sslmode=verify-full`, update the
+  Go database Secret, and restart/smoke the Go Deployment.
+- Temporary recovery alternative: explicitly use `sslmode=disable` in the Go
+  `DATABASE_URL`, accepting plaintext database transport inside the network,
+  then restart and verify the Deployment.
+- After TLS negotiation succeeds, separately validate credentials, grants,
+  migrations 0001/0002, and super-administrator bootstrap.
+
+## Promotion Candidates
+
+- Target: production RDS validation evidence and deployment troubleshooting
+  guidance.
+  Proposal: record the live RDS SSL state/protected address and add a
+  credential-free SSLRequest check before deploying a `verify-full` database
+  URL.
+  Evidence: the Go startup failure and deterministic RED/GREEN protocol loop
+  recorded above.
+  Future impact: prevents fail-closed Go startup from being mistaken for an
+  account/bootstrap defect when the endpoint refuses TLS.
+  Semantic conflicts: none; this strengthens existing RDS-001/RDS hardening
+  commitments.
+  Human confirmation required: no for evidence/runbook promotion; enabling or
+  disabling production RDS SSL remains an operator decision because it can
+  restart the instance or weaken transport security.