Amin Mousavi
f1a4594a0a
Second correctness pass one271858found three ways an arch-only appliance could be written as a per-tooth job, plus a gap in the previous repair. 1. The deferred region check was never completed. A mixed-region category resolved with no region recorded, and nothing re-validated the leaf the clinician then picked — "پروتز متحرک برای دندون ۱۲" wrote a complete denture onto tooth 12, which the manual chart cannot produce and which task generation would expand as denture steps. Targets now resolve BEFORE types, so the target kind narrows a category's candidates and an impossible leaf is never offered. The deferral disappears with it. 2. `some` over the stack's regions let one legal code admit every other. `types: ['pfm_crown','night_guard_soft']` on tooth 12 passed, because `crown` suited the tooth, and wrote a night guard onto that tooth. Now every named code must suit the target. 3. `regions.size === 1` also deferred `implant`, whose leaves span root and crown — both tooth regions, so not a tooth/arch category at all. An implant aimed at a jaw resolved as a UA target. Narrowing by target kind rejects it instead. 4. Thee271858type-row lock ticked the row and the payload but not the count, so the sheet read "Apply 1 field" while two landed. One `effectiveSelection` now drives the count and the payload. Also narrows a `filter(Boolean)` in the disjointness test that left two implicit-any errors under the full tsconfig (nest build excludes specs, so the repo gate never saw them). Pre-existing at15ddb9a. Adds four resolver tests: candidate narrowing per target kind, a category with no usable leaf, a stack where only one code suits, and a legal stack. All three defects passed the previous 209 tests. Gates: backend 212 tests, nest build, ESLint clean on the voice module; frontend 37 Vitest tests, tsc --noEmit, ESLint clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Dyolink
Monorepo: NestJS backend (backend/), Next.js frontend (frontend/), Docker stack under infrastructure/..
Local development: see backend/README.md and frontend/README.md.
Cursor AI: project conventions for agents are in AGENTS.md, .cursor/rules/, and .cursor/skills/.
Production deploy (https://nudentic.ir)
Full guide: infrastructure/DEPLOY.md
Git tag v1.0.1 → Gitea workflow .gitea/workflows/prod-tag-deploy.yml builds images (URLs baked for nudentic.ir), pushes to Gitea registry, SSH-deploys the Linux stack.
First-time SSL / Hub fallback: same DEPLOY.md.
Staging deploy (https://wixur.ir)
Full guide: infrastructure/STAGING-DEPLOY.md
Merge or push to master → Gitea Actions builds images → deploys to https://wixur.ir (Gitea: http://wixur.ir:3000).
Workflow: .gitea/workflows/registry-build-deploy.yml
Related paths
| Path | Role |
|---|---|
backend/Dockerfile |
API image |
frontend/Dockerfile |
Web image |
infrastructure/STAGING-DEPLOY.md |
Staging setup, CI variables, testing |
infrastructure/docker-compose.registry.yml |
Pull-only staging stack (registry images + nginx + postgres) |
infrastructure/deploy.registry.env.example |
Template for deploy.registry.env |