docs: integrate approved Next Go architecture

This commit is contained in:
2026-08-12 21:35:17 +08:00
parent 4485899654
commit 064e155b2f
11 changed files with 287 additions and 5 deletions

View File

@@ -0,0 +1,56 @@
# ADR-003: Next.js Frontend And Go Backend Target
## Status
Accepted target; implementation pending
## Date
2026-08-12
## Context
The integrated application currently runs as a Next.js full-stack Web workload plus a Node process that periodically calls an internal Worker tick endpoint. Next.js owns browser rendering, HTTP routes, authentication, PostgreSQL access, task execution, billing, providers, storage, and Webhooks. This makes the deployment operationally compact, but keeps the UI framework and the complete business backend in the same runtime.
The user explicitly approved a long-term split in which Next.js is the frontend and a Go modular monolith owns the backend. The user later clarified that this integration records design and progress only; it does not authorize or claim a completed code migration.
## Decision
The approved target is a same-origin ACK topology with two long-lived workloads:
- Next.js serves pages, static assets, and SSR. It calls Go over HTTP and does not own RDS, provider, OSS, billing, or migration credentials.
- Go owns the existing `/api/**`, `/uploads/**`, and `/generated-results/**` contracts; identity, administration, assets, jobs, billing, usage, providers, storage, Webhooks, readiness, and an initially embedded WorkerLoop.
- RDS PostgreSQL remains the source of relational truth and cross-instance concurrency.
- The one-shot, versioned PostgreSQL migration Job remains separate.
- Split the embedded WorkerLoop into a third workload only after independent scaling or failure-isolation needs are demonstrated.
The implementation must preserve the existing HTTP and Cookie Interface, multi-tenant authorization, idempotency, task state, wallet, storage, and Webhook behavior. It must continue calling `claim_generation_jobs` and `billing_post_wallet_entry`; Go process-local locks cannot replace these database functions.
Until the implementation is complete and verified, the existing ACK-001 Web/HTTP-polling-Worker architecture remains the deployed and source-code truth.
## Rationale
- Establishes clear runtime and Secret ownership between UI and backend.
- Allows backend lifecycle, testing, and future scaling to evolve independently of Next.js.
- Removes the internal HTTP tick seam once the Go WorkerLoop is production-ready.
- Keeps the initial workload count at two rather than introducing a separate API and Worker before evidence justifies it.
- Preserves the already-reviewed PostgreSQL concurrency and migration contracts.
## Consequences
- The migration is a substantial behavior-compatible rewrite across TypeScript and Go, not a deployment-only change.
- Next.js can remain SSR but is database-free; static export is a separate future choice.
- Go API replica count initially also changes WorkerLoop concurrency and provider/RDS load.
- Executable compatibility tests and reversible, single-writer cutover are mandatory.
- Current code, manifests, and configuration remain unchanged by this ADR.
## Supersedes
- ACK-001 after the Go implementation and cutover are complete. ACK-001 remains the transition-state operational decision until then.
## Related
- `.project-docs/10-decisions/proposals/20260812-go-backend-migration-6f4a92__next-go-architecture.md`
- `.project-docs/30-worklog/tasks/20260812-next-go-architecture-4d81e2.md`
- `.project-docs/30-worklog/tasks/20260812-go-backend-migration-6f4a92.md`
- RDS-001 and RDS-002 in `.project-docs/10-decisions/decision-index.md`

View File

@@ -7,6 +7,7 @@
| RDS-001 | Production persistence uses explicit direct PostgreSQL through one server-only adapter; local JSON is explicit development/test mode. | Accepted | 2026-08-12 | Server stores and scripts | `ZHINIAN_DATA_BACKEND=postgres` fails closed and never silently falls back. |
| RDS-002 | Database changes use versioned, checksummed, advisory-locked migrations executed by a one-shot deployment Job. | Accepted | 2026-08-12 | Database schema and ACK rollout | Migrations do not run in each Web pod init container. |
| ACK-001 | Worker remains an HTTP poller and does not receive RDS credentials; Web owns database access. | Accepted | 2026-08-12 | ACK workloads | Worker calls the internal Web Service with a shared internal token. |
| ADR-003 | Target architecture is a same-origin Next.js frontend plus Go modular-monolith backend with an initially embedded WorkerLoop. | Accepted target; implementation pending | 2026-08-12 | Application and ACK architecture | Current ACK-001 topology remains authoritative until code migration and cutover pass the required compatibility tests. See `adr-003-next-go-target.md`. |
## Superseded Decisions

View File

@@ -9,6 +9,19 @@
| Schema rollout | ACK migration Job | RDS PostgreSQL | Versioned checksummed migrations under an advisory lock. |
| Readiness | ACK probe | Web `/api/ready` -> RDS | Verifies connection, 11 runtime tables, required privileges, and 2 functions. |
## Approved Target Flows
These flows become active only after ADR-003 is implemented:
| Flow | Source | Destination | Required behavior |
|---|---|---|---|
| Browser UI | Browser | Same-origin Ingress -> Next.js or Go by path | Preserve current URLs; avoid cross-origin Cookie/CORS changes. |
| SSR identity/data | Next.js | Internal Go HTTP Interface | Forward Cookie and origin; Go remains the sole authorization authority. |
| Backend persistence | Go Modules | PostgreSQL Adapter -> RDS | Parameterized queries and transactions; fail closed in production. |
| Task execution | Embedded Go WorkerLoop | RDS claim -> provider -> OSS -> RDS -> Webhook | Bounded concurrency, recoverable leases, one owner for external side effects. |
| Asset lifecycle | Go Assets | OSS plus RDS metadata | Shared storage required before horizontal scaling. |
| Schema rollout | Migration Job | RDS | Existing version/checksum/advisory-lock contract remains unchanged. |
## State Ownership
- Production relational state belongs to RDS PostgreSQL when `ZHINIAN_DATA_BACKEND=postgres`.
@@ -21,6 +34,8 @@
- Alibaba Cloud ACK resources under `deploy/ack/`.
- Internal Worker HTTP endpoint is cluster-internal and blocked from public Ingress routing.
In the approved target, the internal Worker HTTP endpoint is removed only after the Node Worker is drained and the Go WorkerLoop is verified. It remains part of the current implementation until that cutover.
## Last Updated
2026-08-12

View File

@@ -16,6 +16,22 @@
- Routes and services depend on store interfaces; stores depend on the shared database adapter; the adapter does not depend on domain stores.
- Worker depends on the internal Web HTTP API, not the database module.
## Approved Target Module Map
The target below is a design contract, not current source layout:
| Target Module | Interface | Implementation notes |
|---|---|---|
| Next.js frontend | Pages, SSR, and same-origin browser calls | Forwards Cookie/request context to Go; no direct persistence or domain ownership. |
| Go Identity | Login/logout/session/password/authorization | Preserves the current signed chunked Cookie and per-request account/organization/sessionVersion validation. |
| Go Administration | Organizations, accounts, settings visibility, logs, administrative usage | Enforces current super-admin and organization-admin rules. |
| Go Assets | Register/upload/list/get/delete/download | Uses object-storage Adapter; preserves owner-scoped 404 and storage metadata. |
| Go Jobs | Submit/query/cancel/retry/claim/execute/terminal transitions/Webhooks | Uses the PostgreSQL claim function and hides provider/retry/refund state. |
| Go Billing | Quote/wallet/ledger/price/charge/refund/settlement | Uses the PostgreSQL wallet function and integer-fen arithmetic. |
| Go Usage | Platform/public attribution and usage records | Retains organization/account context and job uniqueness. |
Real internal seams are PostgreSQL transport, object storage, generation providers, and deterministic test dependencies. Avoid one shallow repository Interface per table.
## Risky Or Sensitive Areas
- `database/migrations/` and the two concurrency-sensitive PostgreSQL functions.

View File

@@ -4,6 +4,22 @@
The Next.js application runs as a Web workload with a separate HTTP-polling Worker. Production server state is stored directly in PostgreSQL through a shared server-only adapter; development and tests can explicitly use local JSON. ACK deploys database migration, Web, Worker, Service, and Ingress resources separately.
This remains the implemented and deployable architecture. No Go backend code or Go deployment resources have been integrated.
## Approved Target Architecture
The accepted target in ADR-003 is a same-origin Next.js frontend plus Go modular-monolith backend:
| Target component | Responsibility | Constraint |
|---|---|---|
| Next.js frontend | Pages, static assets, SSR, browser UI | Calls Go over HTTP; no RDS/provider/OSS/business Secret. |
| Go backend | Existing HTTP/file contracts, identity, administration, assets, jobs, billing, usage, providers, storage, Webhooks, readiness | Owns relational access and initially embeds WorkerLoop. |
| RDS PostgreSQL | Relational state and cross-instance concurrency | Retains versioned migrations and both concurrency-sensitive database functions. |
| Migration Job | Schema and application-role grants | Remains one-shot and separate from long-lived workloads. |
| Alibaba Cloud OSS | Shared generated/uploaded assets | Must be production-ready before horizontal workload scaling. |
Ingress will eventually route page/static paths to Next.js and `/api`, `/uploads`, and `/generated-results` to Go. The initial target remains two long-lived Pods (`Next x1 + Go x1`). This target is not yet implemented.
## Main Components
| Component | Responsibility | Notes |
@@ -24,7 +40,8 @@ The Next.js application runs as a Web workload with a separate HTTP-polling Work
## Related Decisions
- `RDS-001`, `RDS-002`, `ACK-001` in the decision index.
- Current implementation: `RDS-001`, `RDS-002`, and `ACK-001`.
- Accepted target: `ADR-003`; it supersedes ACK-001 only after verified implementation and cutover.
## Last Updated

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

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

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.

View File

@@ -7,6 +7,7 @@ Track future-facing memory: promised follow-ups, unfinished loops, timed checks,
| 2026-08-12 | Validate migration, TLS, permissions, and readiness against the real Alibaba Cloud RDS instance. | Before production cutover | Deployment owner | Open | Back up RDS, provision roles/CA/network access, then run the one-shot migration Job. |
| 2026-08-12 | Keep Web at one replica until generated assets use OSS or another shared store. | Before raising Web replicas | Deployment owner | Open | Configure and validate external object storage. |
| 2026-08-12 | Harden the runtime image to non-root after writable paths are designed. | Security hardening follow-up | Application owner | Open | Define ownership for runtime and settings paths, then update Docker/ACK security context. |
| 2026-08-12 | Implement ADR-003 only after executable compatibility contracts exist. | Before starting the Go migration | Application owner | Open | Add golden tests for HTTP/Cookie/authorization/jobs/billing/storage/Webhooks, then implement vertical slices with single-writer cutover. |
## Use