chore: seal Design Vision v1 and monorepo scaffold
Archive the differentiated YuXinGu product docs, AI engineering system, design contract, and Go/Vue scaffold. Next execution prioritizes Cece-parity over early innovation (see .ai/product/STRATEGY.md). Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
@@ -0,0 +1,20 @@
|
||||
# ADR-0001 Use Golang for API
|
||||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
|
||||
## Decision
|
||||
|
||||
Backend is Go only (`apps/api`).
|
||||
|
||||
## Reason
|
||||
|
||||
1. Fits small team / AI-assisted CRUD + rule engines
|
||||
2. Simple deploy (single binary)
|
||||
3. Strong concurrency for future AI/proxy workloads
|
||||
|
||||
## Never
|
||||
|
||||
Never replace the API language with Node/Java/Python without a new ADR and explicit approval.
|
||||
Legacy `server.py` is temporary and must not grow new product APIs.
|
||||
@@ -0,0 +1,19 @@
|
||||
# ADR-0002 Use gin HTTP framework
|
||||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
|
||||
## Decision
|
||||
|
||||
Use `github.com/gin-gonic/gin` for HTTP routing and middleware.
|
||||
|
||||
## Reason
|
||||
|
||||
1. Widely known; good AI completion quality
|
||||
2. Enough features for REST MVP
|
||||
3. Low ceremony
|
||||
|
||||
## Never
|
||||
|
||||
Never switch to echo/fiber/chi “for fun” mid-feature. Framework change needs a new ADR.
|
||||
@@ -0,0 +1,20 @@
|
||||
# ADR-0003 REST API (not GraphQL)
|
||||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
|
||||
## Decision
|
||||
|
||||
Public HTTP API is REST under `/api/v1` with envelope `{code,message,data}`.
|
||||
|
||||
## Reason
|
||||
|
||||
1. Simpler mental model for H5 + mini-program
|
||||
2. Better Cursor/Claude reliability than GraphQL schemas mid-flight
|
||||
3. Easier debugging with curl
|
||||
|
||||
## Never
|
||||
|
||||
Never replace with GraphQL without approval + new ADR.
|
||||
Internal gRPC later is allowed only behind a new ADR; public clients stay REST.
|
||||
@@ -0,0 +1,19 @@
|
||||
# ADR-0004 JWT (or opaque Bearer) for auth
|
||||
|
||||
## Status
|
||||
|
||||
Accepted (direction)
|
||||
|
||||
## Decision
|
||||
|
||||
Clients send `Authorization: Bearer <token>`. Prefer JWT for stateless MVP; server may later move to opaque tokens + session store via new ADR.
|
||||
|
||||
## Reason
|
||||
|
||||
1. Works for H5 and future mini-program
|
||||
2. Simple middleware story
|
||||
|
||||
## Never
|
||||
|
||||
Never invent parallel auth headers (`X-User-Id` as sole auth).
|
||||
Never trust client-only “isVip” flags.
|
||||
@@ -0,0 +1,22 @@
|
||||
# ADR-0005 Redis — deferred
|
||||
|
||||
## Status
|
||||
|
||||
Deferred (not accepted for MVP)
|
||||
|
||||
## Decision
|
||||
|
||||
MVP does **not** require Redis. Use PostgreSQL + process memory only when safe.
|
||||
|
||||
## Reason
|
||||
|
||||
1. Reduce moving parts for first ship
|
||||
2. Membership/session can start in Postgres
|
||||
|
||||
## When to revisit
|
||||
|
||||
Rate limiting, hot session cache, or distributed locks → write ADR-0005b Accepted before adding Redis.
|
||||
|
||||
## Never
|
||||
|
||||
Never add Redis “just in case” without an Accepted ADR update.
|
||||
@@ -0,0 +1,21 @@
|
||||
# ADR-0006 Monorepo + Vue3 user-h5
|
||||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
|
||||
## Decision
|
||||
|
||||
- npm workspaces Monorepo: `apps/*` + `packages/*`
|
||||
- Primary client: Vue 3 + TypeScript + Vite (`apps/user-h5`)
|
||||
- Shared network: `packages/sdk`
|
||||
|
||||
## Reason
|
||||
|
||||
1. Multi-platform path to mini-program via SDK adapters
|
||||
2. AI-friendly explicit boundaries
|
||||
3. Retire root Legacy HTML gradually
|
||||
|
||||
## Never
|
||||
|
||||
Never start a second unrelated frontend framework for user-h5 without ADR.
|
||||
Reference in New Issue
Block a user