Stitch Preference "Detail" button still in UI (RightPanel.tsx:194) — service renamed it to "Quality" in the literal type but the button array was never updated; clicking Detail produces a 422 #138

Closed
opened 2026-10-03 04:03:07 +00:00 by Mark · 1 comment
Owner

Finding

The RightPanel's Stitch Preference buttons offer 3 values: balanced, detail, speed. The service accepts 3 values: balanced, quality, speed. The client sends detail when the user picks "detail"; the service returns 422 with a literal_error.

Verified at runtime: POST /v1/digitize with stitchPreference: "detail" returns:

HTTP 422
{"detail":[{"type":"literal_error","loc":["body","settings"],"msg":"Input should be 'balanced', 'quality' or 'speed'","input_value":"detail"}]}

This is a regression of closed issue #116, which fixed the same problem. The fix landed in the reducer/adapter (the service-side type is the source of truth now), but the UI still renders the 3-button "balanced / detail / speed" grid from src/components/workspace/RightPanel.tsx:194-210.

A user picks "Detail" expecting more careful stitching, hits Auto-Digitize, and gets a 422 error toast (or silent failure if the error isn't surfaced to the right place).

Where

  • UI source of truth: src/components/workspace/RightPanel.tsx:194 — (['balanced', 'detail', 'speed'] as StitchPreference[]).map(...)
  • Service enum: POST /v1/digitize schema literal ["balanced", "quality", "speed"]
  • Type definition: src/lib/easystitch-client.ts:19 — stitchPreference: "balanced" | "quality" | "speed"
  • Closed prior: #116

Suggested fix shape

Single-line fix: change 'detail' to 'quality' in the RightPanel's button array. Also update the visual label if it says "Detail" — render as "Quality" instead so the user-facing string matches the underlying value. The button's capitalize CSS class will handle the rest.

-  {(['balanced', 'detail', 'speed'] as StitchPreference[]).map((pref) => (
+  {(['balanced', 'quality', 'speed'] as StitchPreference[]).map((pref) => (

Plus a test in RightPanel.test.tsx that asserts the rendered button labels include "Quality" not "Detail".

Severity

High. The user-visible button is broken — clicking it produces a server error.

Discovered by

Gap analysis (2026-10-02) of unreached service parameters + live API test.

  • #116 (closed) — original fix. The UI was not updated to match the new value.
  • #117 (closed) — underlay toggle, same family of RightPanel↔service drift.
## Finding The RightPanel's Stitch Preference buttons offer 3 values: `balanced`, `detail`, `speed`. The service accepts 3 values: `balanced`, `quality`, `speed`. The client sends `detail` when the user picks "detail"; the service returns 422 with a literal_error. Verified at runtime: `POST /v1/digitize` with `stitchPreference: "detail"` returns: ``` HTTP 422 {"detail":[{"type":"literal_error","loc":["body","settings"],"msg":"Input should be 'balanced', 'quality' or 'speed'","input_value":"detail"}]} ``` This is a regression of closed issue #116, which fixed the same problem. The fix landed in the reducer/adapter (the service-side type is the source of truth now), but the UI still renders the 3-button "balanced / detail / speed" grid from `src/components/workspace/RightPanel.tsx:194-210`. A user picks "Detail" expecting more careful stitching, hits Auto-Digitize, and gets a 422 error toast (or silent failure if the error isn't surfaced to the right place). ## Where - UI source of truth: `src/components/workspace/RightPanel.tsx:194` — `(['balanced', 'detail', 'speed'] as StitchPreference[]).map(...)` - Service enum: `POST /v1/digitize` schema literal `["balanced", "quality", "speed"]` - Type definition: `src/lib/easystitch-client.ts:19` — `stitchPreference: "balanced" | "quality" | "speed"` - Closed prior: #116 ## Suggested fix shape Single-line fix: change `'detail'` to `'quality'` in the RightPanel's button array. Also update the visual label if it says "Detail" — render as "Quality" instead so the user-facing string matches the underlying value. The button's `capitalize` CSS class will handle the rest. ```diff - {(['balanced', 'detail', 'speed'] as StitchPreference[]).map((pref) => ( + {(['balanced', 'quality', 'speed'] as StitchPreference[]).map((pref) => ( ``` Plus a test in `RightPanel.test.tsx` that asserts the rendered button labels include "Quality" not "Detail". ## Severity High. The user-visible button is broken — clicking it produces a server error. ## Discovered by Gap analysis (2026-10-02) of unreached service parameters + live API test. ## Related - #116 (closed) — original fix. The UI was not updated to match the new value. - #117 (closed) — underlay toggle, same family of RightPanel↔service drift.
Author
Owner

Closed by commit bb5bdd7 on main (Mark/Kimi_Agent_Brother_10_Digitizing_App).

Root cause was the opposite of what the body described: the #115 adapter layer was correctly translating detail to quality at the service boundary, so the runtime 422 the body reported would only fire on a stale build or a path that bypassed the adapter. But the workspace still shipped a UI literal that did not match the service literal, with a one-line if in mapStitchPreference masking the divergence.

Fix collapses the two literals into one — the workspace now uses quality directly, the UI button renders Quality, and the adapter is removed as dead code.

  • src/components/workspace/types.ts: StitchPreference literal detail to quality
  • src/components/workspace/RightPanel.tsx:194: button array detail to quality (capitalize class renders it as Quality)
  • src/lib/digitize-adapters.ts: removed mapStitchPreference() and its comment
  • src/lib/digitize-adapters.test.ts: replaced the translation test with a #138 regression-guard asserting the UI literal flows to the service unmodified

Gates: vitest digitize-adapters + RightPanel 43/43 pass; pnpm lint clean; tsc -b error count unchanged from baseline (8 pre-existing, unrelated).

Closed by commit bb5bdd7 on main (Mark/Kimi_Agent_Brother_10_Digitizing_App). Root cause was the opposite of what the body described: the #115 adapter layer was correctly translating detail to quality at the service boundary, so the runtime 422 the body reported would only fire on a stale build or a path that bypassed the adapter. But the workspace still shipped a UI literal that did not match the service literal, with a one-line `if` in mapStitchPreference masking the divergence. Fix collapses the two literals into one — the workspace now uses `quality` directly, the UI button renders `Quality`, and the adapter is removed as dead code. - src/components/workspace/types.ts: StitchPreference literal `detail` to `quality` - src/components/workspace/RightPanel.tsx:194: button array `detail` to `quality` (capitalize class renders it as `Quality`) - src/lib/digitize-adapters.ts: removed mapStitchPreference() and its comment - src/lib/digitize-adapters.test.ts: replaced the translation test with a #138 regression-guard asserting the UI literal flows to the service unmodified Gates: vitest digitize-adapters + RightPanel 43/43 pass; pnpm lint clean; tsc -b error count unchanged from baseline (8 pre-existing, unrelated).
Mark closed this issue 2026-10-03 05:05:59 +00:00
Sign in to join this conversation.
No description provided.