Files
dyolink/frontend
Amin Mousavi f1a4594a0a fix(voice): validate a code's region against its target properly
Second correctness pass on e271858 found 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. The e271858 type-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 at 15ddb9a.

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>
2026-09-07 12:42:06 +08:00
..

Dyolink — Frontend (Next.js)

Prerequisites

  • Node.js 20+ and npm

First-time setup

  1. Clone the monorepo and go to the frontend app:

    git clone <repository-url> dyolink
    cd dyolink/frontend
    
  2. Install dependencies

    npm install
    
  3. Environment

    Create .env.local in this folder (not committed to git) with the public URLs your browser will use:

    NEXT_PUBLIC_APP_URL=http://localhost:3001
    NEXT_PUBLIC_API_URL=http://localhost:3000/api
    NEXT_PUBLIC_APP_NAME=Dyolink
    
    • Adjust NEXT_PUBLIC_API_URL if the Nest API runs on another host/port.
    • These values are baked in at build time for production images; for local dev, restart npm run dev after changing them.

Run (development)

npm run dev

Open http://localhost:3001 (dev server uses port 3001 so it does not clash with the API on 3000).

Ensure the backend is running and NEXT_PUBLIC_API_URL matches its base URL (including /api if your API is mounted there).

After pulling latest main

git pull
npm install

Useful commands

Command Purpose
npm run dev Development server (port 3001)
npm run build Production build
npm run start Serve production build (port 3000 — used inside Docker)
npm run lint ESLint

Docker

Image build and build-args (NEXT_PUBLIC_*) are documented in the repository root README.md.