admin/dyolink
0
0
Fork 0
Code Issues 24 Pull Requests 1 Actions Packages Projects 1 Releases Wiki Activity

docs: prove the migration and seed against dev Postgres

Browse Source 
Five migrations were pending, not one: this dev database had not been
migrated since the prosthesis overhaul landed on master. Used migrate deploy
rather than migrate dev so no drift prompt could offer a reset, and counted
the DELETE first — 0 rows matched against 2 total.

Seeded translations verified: 7 categories and 5 subcategories in fa, en and
nl, with crown resolving to روکش‌ها. Both login accounts survived.

Also records that .gitea/workflows run no test, lint or typecheck step at
all, which is why two spec-file type errors reached the branch unnoticed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Amin Mousavi
2026-09-07 14:13:38 +08:00
parent c1d3a241a5
commit dd8e6b17e5
1 changed files with 42 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
docs/specs/voice-treatment-entry/progress.md
View File

@@ -488,3 +488,45 @@ This is decision 39 behaving exactly as approved: teeth and prosthesis apply tog
means a clinician who wants only the teeth from a prosthesis dictation, intending to pick
materials by hand, has no way to get them. Not a spec violation — an unstated consequence.
Deliberately not changed unilaterally.
---
## 2026-09-07 — Migration and seed proven against dev Postgres
The last unverified gate. The inspector had run `prisma validate`, which only parses the schema;
the build compiled solely because the generated client in `node_modules` already carried the new
enum values.
Found five migrations pending, not one — this dev database had not been migrated since the
prosthesis overhaul landed on `master` on 1 September (`a3c14a1`, `72f885d`). Prisma applies in
order, so proving one required applying all five.
Used **`prisma migrate deploy`, not `migrate dev`**: `deploy` applies pending migrations and never
offers to reset, so there is no path where a drift prompt drops dev data. §12 should say `deploy`
for this reason.
Counted the `DELETE` in `…_prosthesis_tree_multi_type` before applying rather than trusting its
own "no-op for current data" comment: **0 rows matched**, against 2 rows total in
`lab_case_tooth_prosthesis`. Both login accounts survived (`users` = 2).
Verified after seeding:
| Check | Result |
|---|---|
| `enum_range(CatalogEntityKind)` | now 5 values, including `PROSTHESIS_CATEGORY` and `PROSTHESIS_SUBCATEGORY` |
| Seeded `PROSTHESIS_CATEGORY` rows | 7 per locale × fa/en/nl |
| Seeded `PROSTHESIS_SUBCATEGORY` rows | 5 per locale × fa/en/nl |
| `crown` in `fa` | `روکش‌ها` — the label that makes "روکش" resolvable to a category |
| Code path | `prosthesis-catalog.service.ts:108,119` resolves both kinds via `CatalogLabelService` |
**Repo-wide gap worth acting on separately:** `.gitea/workflows/*` run no test, lint or typecheck
step — only build and deploy. Combined with `nest build` excluding `**/*spec.ts` and ts-jest
running transpile-only under `isolatedModules`, nothing in this repo would ever catch a type error
in a spec file. That is how two of them reached this branch unnoticed.
## Remaining before this is shippable
- The **manual pass in §12** — none of it has been run. Safari and iPad especially, since that is
the report that started the revision, and the stack / jaw / chip flows in `fa`.
- The Ship phase cannot pass in this repo: no MR template exists, and opening a merge request is
gated regardless.