docs: integrate approved Next Go architecture

This commit is contained in:
brother7 committed 2026-08-12 21:35:17 +08:00
1 parent 4485899654
commit 064e155b2f
11 files changed
+287 -5

No files matched your search

+8 -4
View File
@@ -6,29 +6,33 @@ This file is the integrated default-branch snapshot. Feature tasks record progre
- `c44274f` (rebased integration of `84d84ba`, task `20260812-rds-postgres-adapter-7f2c1a`)
- `79d29bb` (cross-platform ACK manifest validation fix)
- `4485899` (Next.js frontend plus Go backend target design and explicit not-implemented progress record)
## Current Focus
The application now has a production deployment path for Alibaba Cloud ACK backed by direct Alibaba Cloud RDS PostgreSQL access. Local JSON remains an explicit development/test backend.
The implemented application has a production deployment path for Alibaba Cloud ACK backed by direct Alibaba Cloud RDS PostgreSQL access. Local JSON remains an explicit development/test backend. ADR-003 now records the approved future Next.js frontend plus Go modular-monolith backend, but no Go implementation has been merged.
## Recently Completed
- 2026-08-12: Replaced the Supabase/PostgREST runtime path with a server-only `pg` adapter across data, account, and billing stores.
- 2026-08-12: Added versioned PostgreSQL migrations, strict backend selection, verified-CA TLS, database readiness, and ACK Web/Worker/migration manifests.
- 2026-08-12: Accepted and documented the Next.js frontend plus Go backend target, migration contracts, and acceptance criteria. Implementation was explicitly deferred; interrupted code drafts were discarded.
## In Progress
- Production environment values and the real RDS/ACK rollout are not yet validated in this repository environment.
- The Go backend migration has not started. Current code remains Next.js full-stack plus the HTTP-polling Node Worker under ACK-001.
## Next Recommended Steps
1. Back up the target database; create separate migration and application roles; verify the RDS internal endpoint, VPC connectivity, whitelist, TLS mode, and CA certificate.
2. Build and push the reviewed image, run the one-shot migration Job, confirm `/api/ready`, then roll out Web and Worker.
3. Keep Web at one replica until generated assets are externalized to OSS or another shared object store.
1. Before any Go implementation, turn the ADR-003 compatibility requirements into executable HTTP, Cookie, tenant, job, billing, storage, and Webhook contracts.
2. For the current implementation, back up RDS; verify roles, internal networking, TLS and CA; then run the reviewed migration/Web/Worker rollout if production deployment proceeds before the Go migration.
3. Keep the current Web at one replica until generated assets are externalized to OSS or another shared object store.
## Open Questions / Blockers
- Target RDS PostgreSQL version, connection budget, endpoint, TLS enforcement, CA bundle, database roles, and ACK network policy remain deployment inputs.
- Go implementation still needs a deliberate decision on whether to parse existing `zhinian_session` cookies without logout, plus measured API/backlog data before any later Worker split.
## Risky Areas
+1
View File
@@ -5,6 +5,7 @@
| Date | Task | Outcome | Docs Updated |
|---|---|---|---|
| 2026-08-12 | `20260812-rds-postgres-adapter-7f2c1a` | Direct PostgreSQL/RDS persistence and ACK deployment support integrated; local JSON retained for development/tests. | Current state, architecture, data flow, module map, decisions, commitments |
| 2026-08-12 | `20260812-go-backend-migration-6f4a92` | Accepted the Next.js frontend plus Go backend target and recorded migration/acceptance contracts; no application code implemented. | ADR-003, current state, architecture, data flow, module map |
## Notes
@@ -0,0 +1,50 @@
# Task: Integrate Next and Go architecture design into main
## Identity
- Task ID: 20260812-integrate-go-design-c12e7b
- Mode: Integration
- Branch: codex/20260812-integrate-go-design-c12e7b-integrate-go-design
- Worktree: D:\Datas\OthersProjects\NianAIGC-go-docs-integration-c12e7b
- Base commit: a235266bed8f1a7e19518cdd3aa5ed3e0a309b82
- Owner: codex
- Status: Superseded by final validation task
## Scope
- Integrate the approved Next.js frontend plus Go backend design and the explicit implementation progress into canonical project memory.
- Preserve the distinction between the implemented ACK-001 topology and the accepted-but-unimplemented ADR-003 target.
- Merge documentation only; exclude all interrupted Go, Docker, Compose, ACK, package, SQL, and application drafts.
## Intent And Constraints
- The user explicitly requested design and progress documentation only, merged to `main`.
- Promote the human-confirmed architecture without claiming that the Go backend exists.
- Retain RDS-001 and RDS-002; mark ACK-001 as current transition state until implementation and cutover.
- Preserve the occupied `main` worktree's unrelated untracked runtime configuration task record.
## Outcome
- Added ADR-003 as an accepted target with implementation pending.
- Added current-versus-target sections to system overview, module map, and data flow.
- Updated current state, task history, decision index, and commitments with explicit not-implemented progress.
- Integrated the feature task record and detailed architecture proposal.
- No runtime, application, database, build, package, or deployment file changed.
- The first drift check correctly reported that source task-owned records were introduced after this task's recorded base. The prepared canonical state will be committed as a fixed read-only base, this integration lock released, and a fresh Integration Gate task will perform final validation without treating source records as integration-owned edits.
## Verification
- Source documentation commit `ed60e74` was cherry-picked as `4485899` onto the integration base.
- Source feature drift check passed before completion.
- Canonical changes preserve current ACK-001 facts while recording ADR-003 as future target.
- Initial integration drift check: blocked on source-record base ordering, not on document content.
- A fresh Integration Gate based on the fixed source/canonical candidate commit is required before merging `main`.
## Follow-ups
- Implement ADR-003 in a separate future task only after compatibility tests are executable.
- Live RDS/ACK/OSS/provider validation remains outside this documentation-only integration.
## Promotion Candidates
- None recorded.
@@ -0,0 +1,69 @@
# Task: Assess Next.js frontend and Go backend architecture
## Identity
- Task ID: 20260812-next-go-architecture-4d81e2
- Mode: Feature
- Branch: codex/20260812-next-go-architecture-4d81e2-next-go-architecture
- Worktree: D:\Datas\OthersProjects\NianAIGC-next-go-architecture-4d81e2
- Base commit: a235266bed8f1a7e19518cdd3aa5ed3e0a309b82
- Owner: codex
- Status: Ready for Integration
## Scope
- Assess whether the current Next.js full-stack application can become a Next.js frontend with a Go backend.
- Inspect the current API, server modules, authentication, PostgreSQL, asynchronous worker, storage, provider, billing, and SSR coupling surfaces.
- Compare a combined Go API/worker modular monolith, a Next BFF strangler migration, and separate Go API/worker workloads.
- Recommend a target architecture and migration boundary without changing application or deployment code.
## Intent And Constraints
- Challenge the premise that this is a direct deployment-only split; distinguish feasibility from migration cost.
- Preserve the existing HTTP, cookie, multi-tenant, job-claim, wallet-idempotency, and migration contracts during any future rewrite.
- Prefer a same-origin deployment boundary to avoid introducing CORS and cross-site cookie complexity.
- Keep confirmed repository facts separate from recommendations and assumptions that require production evidence or human direction.
- Treat the accepted ACK-001 worker/Web ownership boundary as authoritative until a replacement architecture decision is approved.
## Outcome
- On 2026-08-12, the user explicitly confirmed the recommended target architecture: same-origin Next.js frontend plus a Go modular-monolith backend, initially retaining two long-lived Pods and embedding the task loop in Go.
- Confirmed that the architecture can become a Next.js frontend plus Go backend, but it requires an equivalent backend rewrite rather than a command or manifest change.
- Counted 45 `app/api` route files with 64 HTTP handlers and identified approximately 10.7k lines of directly affected TypeScript server/auth/provider implementation; a behavior-compatible migration is estimated at roughly 10k-14k equivalent implementation lines plus tests and infrastructure.
- Recommended a same-origin ACK target: Ingress routes pages to Next.js and API/file paths to a Go modular monolith. Go owns authentication, RDS, OSS, providers, billing, Webhooks, and initially an internal worker loop; Next.js retains rendering and HTTP calls but no database or provider secrets.
- Recommended retaining the PostgreSQL `claim_generation_jobs` and `billing_post_wallet_entry` functions as concurrency authorities rather than replacing them with Go in-memory locks.
- Recommended a strangler migration that freezes the current HTTP/Cookie contract, migrates vertical slices with shadow reads and single-owner writes, and cuts the worker over only after the old worker is stopped and in-flight locks are handled.
- Determined that the recommended initial steady state remains two long-lived Pods (`Next x1 + Go x1`). Separating the Go API and Go worker creates a third workload and should follow demonstrated scaling or failure-isolation needs rather than be the default first step.
- Confirmed that retaining SSR means Next.js remains a server process even when it no longer accesses the database; a truly static frontend requires client-side authentication and page-guard changes.
- No application, database, or deployment files were changed.
## Verification
- Read the current project memory, accepted RDS/ACK decisions, architecture documents, deployment manifests, API routes, server modules, auth code, worker script, and PostgreSQL migration contract from base commit `a235266`.
- Independently reviewed the migration surface, modular-monolith design, BFF strangler design, separate API/worker design, and compatibility risks using bounded parallel agents.
- Cross-checked the critical session, tenant-isolation, job-claim, wallet-idempotency, provider-recovery, storage, readiness, and migration contracts against current code and SQL.
- Final read-only architecture review returned PASS after requiring explicit limits on per-path strangler routing, SSR session introspection, the full cookie contract, side-effect-free shadowing, worker drain/cutover, and coupled API/worker scaling.
- No live traffic profile, Go prototype, RDS integration run, provider call, or ACK rollout was performed.
## Follow-ups
- Human direction is now confirmed for replacing ACK-001 with the initial two-Pod modular-monolith target; canonical promotion still requires the serialized Integration Gate.
- Decide whether Go must parse existing `zhinian_session` cookies or whether one forced re-login at cutover is acceptable.
- Confirm external `/api/v1` compatibility obligations, expected traffic/backlog, team ownership of the Go codebase, and whether SSR must be retained.
- If approved, first create executable HTTP/Cookie golden tests and a migration proposal; do not begin with a big-bang route rewrite.
## Promotion Candidates
- Target: `.project-docs/10-decisions/decision-index.md` and a new accepted architecture decision.
Proposal: replace ACK-001 with a same-origin Next.js frontend and Go backend boundary, initially using a Go modular monolith with an internal worker loop and retaining PostgreSQL as the job and billing concurrency authority.
Evidence: current Next.js owns all business logic and RDS access while the Node worker only invokes an internal HTTP tick; the assessed migration surface and alternatives are recorded in this task outcome.
Future impact: changes application ownership, secrets, deployments, API compatibility policy, worker lifecycle, scaling, and rollback strategy.
Semantic conflicts: conflicts with accepted ACK-001, which assigns database access to the Next Web workload and requires the Worker to call Web over HTTP without database credentials.
Human confirmation required: received from the user on 2026-08-12; serialized Integration Gate promotion remains pending.
- Target: `.project-docs/20-architecture/system-overview.md`, `module-boundaries.md`, and `data-flow.md`.
Proposal: after the replacement decision is accepted and implemented, document Next.js as a rendering/client module and Go as the owner of identity, jobs, assets, billing, administration, RDS, OSS, providers, Webhooks, and asynchronous execution.
Evidence: the recommended deep-module boundaries and same-origin routing seam in this task outcome.
Future impact: future feature work and deployment configuration will use the Go HTTP interface instead of importing Next.js server modules.
Semantic conflicts: must not be promoted while the existing Next.js implementation and ACK-001 remain authoritative.
Human confirmation required: yes.
@@ -0,0 +1,52 @@
# Task: Audit current runtime configuration
## Identity
- Task ID: 20260812-runtime-config-audit-9b3e6d
- Mode: Feature
- Branch: main
- Worktree: D:\Datas\OthersProjects\NianAIGC
- Base commit: a235266bed8f1a7e19518cdd3aa5ed3e0a309b82
- Owner: codex
- Status: Complete
## Scope
- Audit every runtime environment variable consumed by the current `main` code, scripts, Docker image, and ACK manifests.
- Reconcile the code contract with `.env.example`, deployment documentation, and the current ACK Web, Worker, Migration, Service, and Ingress resources.
- Produce an ACK-oriented configuration list for RDS PostgreSQL without changing application or deployment files.
## Intent And Constraints
- Treat the current source code as authoritative when examples or documentation disagree.
- Separate confirmed behavior, deployment recommendations, and facts that still require validation in the live ACK/RDS environment.
- Separate non-sensitive ConfigMap values from Secret values and assign them only to the workload that consumes them.
- Do not present dormant external OAuth configuration as an available production login path.
## Outcome
- Confirmed the existing ACK manifests cover the PostgreSQL, RDS CA, session, and internal Worker startup baseline, but not a complete real-generation production configuration.
- Produced workload-specific configuration groups for Web, Worker, and the PostgreSQL migration Job, including conditional provider, OSS, Open API, webhook, billing, and organization settings.
- Confirmed that production needs an explicit public HTTPS origin, an explicitly selected image/video engine, the selected provider credentials, and complete OSS configuration to avoid mock behavior or ephemeral Pod-local asset storage.
- Identified current source-of-truth gaps: `.env.example` omits `VIDEO_GENERATE_ENGINE`, all Bailian settings, organization settings, directory overrides, Worker ID, and several compatibility settings.
- Confirmed external OAuth/JWT variables are read by helpers but the current login route uses platform-owned PostgreSQL phone/password accounts; configured OAuth client IDs are also overridden by the hard-coded `platform` value.
- Confirmed the obsolete Supabase variables are no longer consumed by runtime code.
## Verification
- Audited `process.env` reads across application and Node scripts, excluding tests and build output.
- Inspected `.env.example`, `Dockerfile`, `docker-compose.yml`, PostgreSQL adapter and migration scripts, auth, storage, providers, Worker/task handling, billing, organization client, health/readiness routes, and all eight ACK manifests.
- `npm run deploy:check`: passed for all 8 ACK manifests.
- Independent configuration/security review: current ACK manifest completeness `FAIL`; configuration-list framing `PASS` when it distinguishes startup baseline from real-production requirements, includes provider and OSS configuration, and marks OAuth as not connected.
- No live RDS connection, migration execution, provider/OSS request, Docker build, ACK server-side dry run, or rollout was performed.
## Follow-ups
- Update `.env.example` and ACK ConfigMap/Secret templates in a separate implementation task if the user wants the audited list applied to the repository.
- Validate RDS TLS, roles, privileges, connection budget, ACR pulling, Ingress controller compatibility, provider credentials, OSS access, and the migration Job in the target ACK environment before production cutover.
- Fix or remove the dormant OAuth configuration path before advertising external SSO support.
- Decide whether application logs should move to stdout/log collection or a persistent volume; OSS only persists assets, not the current file log.
## Promotion Candidates
- None recorded. This audit refines deployment guidance but does not change the integrated architecture or accepted production boundaries.