Files

T

Jeffery f44200f543 feat: 完成 B 群組 — 資料層與核心領域模型

- 導入 Prisma 7.9.1 + SQLite（better-sqlite3 driver adapter），prisma.config.ts 管理連線設定
- 完整資料模型：User／Work／Character／CharacterAlias／EpisodicMemory／SemanticMemory／
  ProceduralRule／EmotionState／Relationship／SentimentLedgerEntry
- packages/db：Prisma Client 存取層（ESM，因 Prisma 7 產出的 generated client 僅支援 ESM）
- apps/api 隨之改為 ESM 以相容 packages/db
- packages/shared：新增角色／記憶／情緒／關係共用型別，api 與 web 皆從此匯入
- prisma/seed.ts：建立測試使用者與元氣型測試角色，含完整關係帳本與記憶種子資料
- apps/api：新增 GET /characters
- scripts/smoke/B.mjs：驗證資料表齊全、API 讀出種子角色、關係與記憶可寫入讀出
- 保留 Prisma 官方隨 CLI 附的 agent skill 文件（.agents/skills 等），供後續群組查閱

npm run restart && npm run smoke -- B 皆通過（B-V），A 群組冒煙測試無回歸。

2026-08-13 09:43:15 +08:00

3.1 KiB

Raw Blame History

migrations-mapping

How the v6 MongoDB "no migrations" story maps onto Prisma Next's first-class migration flow.

Priority

HIGH

Why It Matters

This is the largest workflow change in the migration — in v6, MongoDB explicitly has no Prisma Migrate, while in Prisma Next MongoDB participates in the full migration lifecycle. Teams porting a db push habit into Next without understanding the plan/verify/sign flow will fight the tooling or bypass its safety rails.

v6: `db push` only

MongoDB on v6 has no Prisma Migrate and no plans to add it — "MongoDB projects do not rely on internal schemas" (no support for Prisma Migrate). The workflow is prisma db push to sync indexes and unique constraints, with no migration history on disk.

Prisma Next: first-class, contract-driven migrations (Mongo included)

Migration authoring in Next is first-class for Postgres and Mongo (prisma-next skills/prisma-next-migrations/SKILL.md) — MongoDB is not a push-only special case:

Flow: contract emit → diff → plan (writes a content-hashed migration package) → migrate (apply in graph order) → verify (live schema vs destination contract) → sign (advance the marker after a verify pass).
Mongo migration ops come from dedicated factories: createCollection, dropCollection, validatedCollection, setValidation, createIndex, dropIndex, collMod, and dataTransform for data backfills.
Marker storage: Next records migration state in a document in the _prisma_migrations collection (per space) — the same collection name family v6 users know from SQL, repurposed for Mongo state.
DDL is not transactional on Mongo: the runner applies operations, verifies the live schema against the destination contract, and only advances the marker on a verify pass — making interrupted runs resumable rather than atomic (see Prisma Next's prisma-next-migrations skill).
Push-style alternative still exists: db update diffs the live database against the contract and applies directly without writing a migration directory — the closest analogue to the v6 db push habit, at the cost of no history.
Validators: Next emits closed $jsonSchema validators by default since 0.12 (prisma-next CHANGELOG.md) — collections gain schema enforcement v6 never applied.

Bad

Porting the v6 habit: run the Next equivalent of `db push` for every change in production,
accumulating no migration history, and hand-editing collections when verification fails.

Good

Adopt the Next lifecycle: emit the contract, plan a migration package, apply it with
migrate, let verify gate the marker, and sign. Reserve `db update` for local prototyping,
mirroring how `db push` was used on v6.

References

v6: no Prisma Migrate for MongoDB
Prisma Next migrations skill (skills/prisma-next-migrations) — authoritative for the Next side; verified @ a2791c5dd59d579b4b3052942ae7f8fe5e2ee852

3.1 KiB Raw Blame History