docs: reconcile authenticated SSR production state

.project-docs/30-worklog/current-state.md

@@ -13,10 +13,11 @@ This file is the integrated default-branch snapshot. Feature tasks record progre
 - `f10cdd9` (record of completed task `20260812-architecture-task-breakdown-a83f61c2`)
 - `ff055c9` (config-driven super-admin bootstrap in the Go backend, task `20260814-go-bootstrap-admin-6e2b7d9c`)
 - `4a8f2d5` (Go workload deployment artifacts and split Ingress routing, task `20260814-go-deploy-artifacts-2a5f8e1d`)
+- `498c2fa` (authenticated Next.js SSR-to-Go identity bridge and ACK Web internal Go URL, task `20260816-fix-authenticated-ssr-6c3f8a21`)
 
 ## Current Focus
 
-ADR-003's Go modular-monolith backend is implemented and merged into `main` under `backend/` (`cmd/zhinian-api`, 18 `internal/` packages, 24 contract fixtures, migration 0002). There is no production instance of this application yet: the **first production deployment** will run the ADR-003 split topology directly — Next.js serves pages/static/SSR, Go owns `/api`, `/uploads`, and `/generated-results` — so there is no legacy cutover, no Node Worker drain, and no legacy production session compatibility to preserve. Next.js route handlers remain in the repository for local development only. The production schema is initialized by manually executing the versioned SQL files; the ACK migration Job is not part of the deployment path.
+The first production deployment is live at `https://nianxxaigc.nianxx.cn`. Its deployed revision does not yet include `498c2fa`: authenticated `/create` currently triggers a production RSC error, while the public `/api/ready` endpoint has been observed returning HTTP 200 with PostgreSQL configured. The repository now contains the authenticated Next.js SSR-to-Go identity bridge in `lib/server/auth/current-user.ts`; when `ZHINIAN_GO_INTERNAL_BASE_URL` is configured it refreshes identity through internal Go `/api/auth/me`, and without that environment variable local Next.js full-stack development retains the direct-store path. Current work is the production repair rollout: publish the updated Web image and ACK configuration, then complete an authenticated `/create` smoke test. The exact live Service owner for each request path remains unverified until confirmed from cluster configuration or logs.
 
 ## Recently Completed
 
@@ -28,31 +29,32 @@ ADR-003's Go modular-monolith backend is implemented and merged into `main` unde
 - 2026-08-14: Added config-driven first-super-administrator bootstrap to the Go backend (task `20260814-go-bootstrap-admin-6e2b7d9c`).
 - 2026-08-14: Recorded the first-deployment model: no production cutover, manual schema initialization without the migration Job pod (task `20260814-deploy-model-reconcile-9b4c2e7f`).
 - 2026-08-14: Built the Go workload deployment artifacts: `backend/Dockerfile`, `deploy/ack/go-api.yaml`, split-path Ingress routing, non-root/read-only-filesystem workload config, and updated manifest assertions (task `20260814-go-deploy-artifacts-2a5f8e1d`).
+- 2026-08-16: Implemented authenticated production SSR identity refresh through Go `/api/auth/me`, forwarding only enumerated `zhinian_session` chunks, strictly validating the response, preserving the local direct-store path when the internal URL is absent, and keeping the updated ACK Web configuration database-free (task `20260816-fix-authenticated-ssr-6c3f8a21`, commit `498c2fa`; not yet deployed).
 
 ## In Progress
 
-- None.
+- Release `498c2fa` to the existing production environment and verify authenticated `/create` SSR; the live revision still exhibits the RSC failure.
 
 ## Next Recommended Steps
 
-1. Build and push the `zhinian-go-api` image from `backend/Dockerfile`, then validate all manifests with `kubectl apply --dry-run=server` on the target ACK cluster.
-2. Initialize the production schema by manually executing `database/migrations/0001_initial_schema.sql` then `0002_generation_lifecycle_fencing.sql` as the migration role, then apply the application-role grants (tables plus the two concurrency functions).
-3. Configure `ZHINIAN_BOOTSTRAP_ADMIN_*` on the first Go startup; the process creates the first super administrator exactly once.
-4. Validate against non-production RDS (real application role, verified-CA TLS), real OSS, provider credentials, and external Webhooks before the first production rollout.
-5. Confirm the public `/api/v1` compatibility promise for external consumers.
+1. Build and push the updated Web image containing `498c2fa`, and validate the updated ACK configuration with a server-side dry run on the production cluster.
+2. Apply the updated Web image and ACK configuration without assuming the current live Service ownership beyond what cluster configuration and logs confirm.
+3. Smoke-test an authenticated request to `/create`, confirming the production RSC error is resolved and SSR refreshes the user through internal Go `/api/auth/me`.
+4. Recheck public `/api/ready` after the rollout; it currently returns HTTP 200 with PostgreSQL configured.
+5. Continue real RDS/OSS/provider/Webhook validation and confirm the public `/api/v1` compatibility promise for external consumers.
 
 ## Open Questions / Blockers
 
-- Target RDS PostgreSQL version, connection budget, endpoint, TLS enforcement, CA bundle, database roles, and ACK network policy remain deployment inputs.
+- Canonical memory does not yet record the live RDS PostgreSQL version, connection budget, endpoint, TLS/CA details, database roles, ACK network policy, or confirmed request-path Service ownership.
 - Real OSS bucket/credential configuration is still needed for shared asset storage.
 - Public `/api/v1` support promises for external consumers need explicit confirmation.
 
 ## Risky Areas
 
-- Database grants and least-privilege roles must be tested against the actual RDS instance before the first rollout.
+- Database grants and least-privilege roles still require documented validation against the live RDS instance.
 - The current image runs as root; moving to a non-root user requires an explicit writable-path ownership design.
-- The Go code is contract-tested but has never run against real provider, OSS, RDS, and Webhook traffic; parity gaps can only surface under real dependencies.
+- Real provider, OSS, RDS, and Webhook coverage is not fully documented; do not infer which live workload owns those paths without cluster evidence.
 
 ## Last Updated
 
-2026-08-14
+2026-08-16