# Task: Disable PostgreSQL TLS for Go production

## Identity

- Task ID: 20260816-disable-postgres-tls-d4a89c12
- Mode: Feature
- Branch: main
- Worktree: D:\Datas\OthersProjects\NianAIGC
- Base commit: acf368b6fe290f44157ada79448673ab11808f7c
- Owner: codex
- Status: Ready for Integration

## Scope

- Change the Go PostgreSQL adapter so production never negotiates TLS, even
  when the existing `DATABASE_URL` contains `sslmode=verify-full` and
  `sslrootcert` from the previous deployment template.
- Align the Node migration client, ACK Secret/template checks, Go Deployment,
  environment example, and deployment guide with plaintext PostgreSQL.
- Preserve explicit PostgreSQL selection, credentials, authorization,
  migrations, pooling, and fail-closed startup behavior.

## Intent And Constraints

- The user explicitly chose code-side plaintext transport instead of changing
  Alibaba Cloud RDS SSL configuration and accepted the resulting lack of
  database link encryption.
- A newly built Go image must start with the existing TLS-bearing Secret; no
  live Secret or RDS control-plane mutation is part of this task.
- Work test-first at the configuration/connection seam that reproduced the
  production `server refused TLS connection` failure.
- Keep the change surgical and do not alter API, authentication, billing,
  storage, or database schema behavior.

## Outcome

- Go `ParseConfig` removes case-insensitive `sslmode`/`sslrootcert` values,
  writes `sslmode=disable`, never reads a CA, and records plaintext mode.
- Go `Open` normalizes the URL again and explicitly clears pgx `TLSConfig` and
  fallbacks, so a direct or legacy `Config` cannot negotiate TLS.
- The migration Node client and retained server-only TypeScript adapter apply
  the same normalization and pass `ssl: false` to `pg`.
- ACK no longer defines or mounts `zhinian-rds-ca`; migration and Go Secret
  examples use `sslmode=disable`.
- Environment examples, both READMEs, deployment guidance, and manifest
  assertions now disclose plaintext PostgreSQL transport and require private
  network isolation.
- No live Alibaba Cloud or ACK configuration was changed.

## Verification

- RED: new Go tests failed because the old parser read `sslrootcert`, defaulted
  to `verify-full`, and `Open` required TLS configuration.
- RED: new Node tests failed because the old clients tried to read a missing CA
  and the ACK checker found the retained CA mount.
- GREEN: `go test ./...` passed for every backend package.
- GREEN: `npm test` passed 53 files / 160 tests.
- GREEN: `npx tsc --noEmit --incremental false` passed.
- GREEN: `npm run deploy:check` passed all seven checked-in ACK manifests.
- GREEN: `node --check` passed for both modified Node scripts.
- GREEN: `npm run build` exported all 14 static pages successfully.
- `git diff --check` passed with line-ending warnings only.
- First read-only `sol_reviewer` verdict: FAIL because `backend/README.md`
  retained TLS claims and tests did not observe a real PostgreSQL startup
  packet; both findings were fixed.
- Final read-only `sol_reviewer` verdict: PASS on both Standards and Spec after
  the Go wire test observed plaintext StartupMessage `196608` (not SSLRequest
  `80877103`) and the executable TypeScript configuration test passed.

## Follow-ups

- Build and deploy an immutable Go image, then verify startup bootstrap and
  `/api/ready` against the live RDS instance.
- Reapplying the database Secret is not required for TLS removal because the
  new clients override old TLS parameters, but the checked-in plaintext Secret
  template should be used for future rotations.
- Reassess TLS if the network boundary or compliance requirements change.

## Promotion Candidates

- Target: RDS-001/current architecture/database deployment commitments.
  Proposal: record that production PostgreSQL transport is intentionally
  plaintext and code-enforced, superseding the prior verified-CA TLS default.
  Evidence: production RDS refused TLS, the deterministic diagnosis task
  `20260816-diagnose-go-rds-tls-9c4a7e21`, and the user's explicit 2026-08-16
  instruction not to modify Alibaba Cloud and to remove TLS in code.
  Future impact: future deployment templates and database clients must not
  silently reintroduce TLS without a new operator decision and compatible RDS
  configuration.
  Semantic conflicts: canonical current state and commitments still describe
  verified-CA TLS as the prior target.
  Human confirmation required: already received for plaintext production
  transport; canonical promotion still requires the serialized Integration
  Gate.