Adopt agents-settings kit, ship Product/SKU scan models, harden auth, verify OCR accuracy

Backend (app-pfm-ocr-v2/backend):
- Product/SKU scan feature complete: trained DINOv2 index (118 reference
  photos, 16 SKU classes) and YOLO classifier (83.3% top-1 val accuracy),
  fixed scripts/install-pipeline.sh (was missing ultralytics/torch), fully
  browser-verified end-to-end on /scan-pfm. Mobile m-scan-pfm page cancelled
  (Flutter app handles mobile; web UI is desktop-only for pipeline testing).
- Fixed a real data-loss bug: Save Ground Truth (scan-pfm and the DO-flow's
  manual-label) was silently writing into the pfm-web-app container's
  ephemeral filesystem instead of the host, because /sources wasn't
  bind-mounted in docker-compose.yml. Added the mount, recovered an
  orphaned entry.
- accounts.password is now bcrypt-hashed (bcryptjs, idempotent migration
  in db/init.ts) instead of plaintext; login route compares hashes.
- /api/v1/documents/* (list, PUT, upload) now enforces real 401 auth,
  matching what the Flutter client already sends. The "classic" routes
  deliberately stay open — they're dev-only web UI with no login flow and
  won't exist in production.
- OCR accuracy investigated end-to-end: real baseline is 95.10% overall
  (target met; accuracy_report.md was stale at 75.04%, now flagged). Fixed
  one genuine parser.ts bug (SO/DO field duplication in the global fallback
  regex); remaining gaps are OCR/layout-model limitations, not parser bugs.
- Adopted a standalone copy of the fhanyuh/agents-settings e/n workflow
  scoped to backend/ (AGENTS.md Part A/B split, SKILLS.md, plans/, docs/),
  independent of the root copy which now covers Flutter only.
- next-implementation.md deleted; content folded into
  backend/plans/next-enhancements.md for traceability.

Root:
- Adopted fhanyuh/agents-settings kit (AGENTS.md, SKILLS.md, plans/,
  docs/feature-list.md), scoped to the Flutter app only.
- Pending documents queue now persists to Hive (lib/core/storage) instead
  of memory-only, surviving an app kill mid-upload.

Removed backend_backup/ (stale Express/Prisma prototype, superseded by
pfm-web-app) and the completed plans/next-enhancement-plan.md checklist.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

backend/SKILLS.md

@@ -0,0 +1,103 @@
+# Skills & Roles (backend)
+
+Backend-scoped copy of the root `SKILLS.md` — same five roles, applied to
+`backend/` surfaces (Next.js API gateway, OCR pipeline, Postgres, Docker/deploy)
+during `n`/`next` execution (see `AGENTS.md` Part B, this dir). One agent can play
+all of them in sequence; a multi-agent harness may spawn each as a separate
+subagent for a fresh-context pass. Order matters: Architect → Backend/Frontend →
+QA → Hardware/Compatibility.
+
+## 1. Software Architect
+
+**Responsibilities**
+- Decide where new backend code lives; keep module boundaries clean (API routes vs.
+  `utils/` business logic vs. `db/` layer vs. the Python pipeline in `config/`).
+- Prefer deep modules (few, well-bounded files with simple interfaces) over shallow
+  ones — this is what keeps the codebase navigable for an agent.
+- Own the 256-LOC split rule (`AGENTS.md` Part B §B3): when a file crosses the
+  threshold, decide the split boundary before anyone patches around it.
+- Keep `plans/next-enhancements.md` (this dir) structured by real backend module
+  boundaries, not arbitrary groupings.
+- Owns the existing-project audit (`AGENTS.md` Part B §B0) for backend specifically.
+
+**When invoked**: start of every `e`/`enhance` run; start of every `n`/`next` task,
+before implementation begins.
+
+**Handoff**: hands the Backend/Frontend roles a target file layout and interface
+contract, not just a task description.
+
+## 2. Backend Engineer
+
+**Responsibilities**
+- Implement Next.js API route logic, DB access (`src/db/`), and the Python OCR
+  pipeline (`config/classify_ocr_server.py`, pipeline API) as the task requires.
+- Wire the mock-vs-live routing required by the Demo/Live switch (`AGENTS.md` Part B
+  §B5) and the Cloud/Local endpoint switch (§B6) if/when built — both must resolve
+  through the same contract so swapping either setting never changes calling code.
+- Keep business logic out of route handlers (`src/app/api/**/route.ts`); route
+  handlers stay thin, matching the existing `utils/parser.ts`-style separation.
+- Use `withTransaction` (`src/db/index.ts`) for any multi-statement write that must
+  be atomic — see task 7.1 in the pre-kit history for why this matters here.
+
+**When invoked**: any task touching API routes, the DB layer, or the OCR pipeline.
+
+**Handoff**: gives Frontend a stable contract (types/response shape) to build
+against; gives QA the list of new/changed endpoints and their expected error modes.
+
+## 3. Frontend Engineer
+
+**Responsibilities**
+- Implement UI for the task inside `pfm-web-app/src/app/`, including Demo/Live and
+  Cloud/Local switcher controls where relevant.
+- Follow this repo's existing page pattern: consolidated single-page flows (root
+  `page.tsx`) vs. standalone-purpose route folders (`manual-label/page.tsx`,
+  `scan-pfm/page.tsx`) — see backend `CLAUDE.md` for which pattern a given feature
+  should follow.
+- Consume the Backend Engineer's contract rather than reaching around it.
+- Keep components small and composable, respecting the 256-LOC rule.
+
+**When invoked**: any task with a user-facing surface inside `pfm-web-app/`.
+
+**Handoff**: gives QA the golden-path user flow and the edge cases it's aware of.
+
+## 4. QA / Test Engineer
+
+**Responsibilities**
+- During clarification (`AGENTS.md` Part B §B2a), turn resolved answers into
+  concrete acceptance criteria — what "done" verifiably means.
+- Write/extend automated tests (`parser.test.ts` pattern) for the change.
+- For anything touching `parser.ts` or the OCR pipeline, run the accuracy
+  regression harness (`node pfm-web-app/scripts/accuracy-check.mts`) and check for
+  regressions against the current baseline (~89.4% overall, target 95% — see
+  backend `CLAUDE.md`), not just "it compiles."
+- Run the **verify build integrity** pass: golden path + edge cases + regression
+  check on adjacent features.
+- Reject work back to the relevant role if acceptance criteria aren't met — don't
+  patch around a failing check.
+
+**When invoked**: acceptance-criteria drafting during §B2a; final verification pass
+before a task is marked `[DONE]`.
+
+**Handoff**: reports pass/fail with specifics (what broke, under what input) back to
+whichever role owns that surface.
+
+## 5. Hardware & Performance Compatibility Reviewer
+
+**Responsibilities**
+- Check the change against this stack's real constraints: single vs. dual-GPU dev
+  mode (`docker-compose.yml` runs `npm run dev`, a known throughput ceiling), VRAM
+  budget for vLLM (`gpu-memory-utilization` in `config/vllm_config.yaml`), and
+  behavior under the Local/on-prem deployment mode from `AGENTS.md` Part B §B6.
+- Flag newly introduced heavy Python/Node dependencies, GPU-specific assumptions, or
+  anything that would break the isolated vLLM-server-only environment (no
+  `paddlepaddle-gpu` in this venv — see `AGENTS.md` Part A / `docs/vllm-service.md`).
+- Flag anything that would degrade badly on lower-spec hardware or slower networks
+  (e.g. the mobile app's 2s polling loop against a slow backend response), and
+  suggest a lighter-weight alternative when one exists.
+
+**When invoked**: final verification pass, alongside QA, before a task is marked
+`[DONE]`; also whenever a task adds a new dependency or changes the deployment/
+runtime surface.
+
+**Handoff**: blocks `[DONE]` status until concerns are resolved or explicitly
+accepted as a documented trade-off in `docs/feature-list.md` (this dir).