Fabric Type and Stabilizer dropdowns are wired in the UI but never reach the service — Help page claim "this affects underlay and density recommendations" is unmet #146

New issue

Closed

opened 2026-10-03 04:24:12 +00:00 by Mark · 1 comment

Mark commented

2026-10-03 04:24:12 +00:00

Owner

Finding

The RightPanel's Design Settings section has two dropdowns that the user can change but whose values never reach the service:

Fabric Type (src/components/workspace/RightPanel.tsx:131-141): 5 options (Light Weight Cotton / Medium Weight Cotton / Heavy Weight Cotton / Stretchy / Knit / Towel / Fleece)
Stabilizer (src/components/workspace/RightPanel.tsx:143-151): 4 options (Cut-Away / Tear-Away / Wash-Away / Adhesive)

The values are stored in designSettings.fabricType and designSettings.stabilizer (in the workspace reducer), they persist with the saved design, and they round-trip through the gallery. But toServiceSettings at src/lib/digitize-adapters.ts:38-65 does not include either field in the AutoDigitizeSettings object sent to /v1/digitize.

The service's DigitizeSettings schema accepts fabric and targetStitchCount as forward-compatible wire fields (per the openapi description: "settings accepts fabric and targetStitchCount as documented forward-compatible hints (the pipeline does not consume them yet)"). The client doesn't send either.

The Help page advertises: "Choose your fabric type (light, medium, heavy, stretchy, or towel) — this affects underlay and density recommendations." This is a product promise the current implementation cannot keep, because the choice never reaches the service.

Where

UI: src/components/workspace/RightPanel.tsx:131-151
State: src/components/workspace/types.ts:145-146 (fabricType: FabricType;, stabilizer: StabilizerType;)
Adapter (the gap): src/lib/digitize-adapters.ts:38-65 — does not include fabric or stabilizer in the return object
Service schema: DigitizeSettings accepts fabric: str (forward-compatible)
Help page: src/pages/Help.tsx:69 — "Choose your fabric type..."

Suggested fix shape

Add fabric and targetStitchCount (the latter is mentioned alongside fabric in the openapi description) to the toServiceSettings return object. The values come from the workspace state:

return {
  // ... existing fields ...
  fabric: workspaceSettings.fabricType ?? 'cotton',
  // stabilizer isn't in the service schema as a separate field but the service
  // may want to derive it from fabric; if not, omit it for now
};

If the service doesn't yet consume fabric, the wire field is a no-op today but it's set up for the moment the service starts honoring it (same pattern as underlay, per the comment in digitize-adapters.ts:55-58).

Longer-term: the service's digitize algorithm should actually use fabric to choose underlay and density defaults. The current Help page claim is "this affects underlay and density recommendations" — until the service does this, the help page text is a lie.

Severity

Medium. The user's choices are stored but ignored by the engine. The Help page makes promises the implementation can't keep.

Discovered by

Gap analysis (2026-10-02) of auto-digitize settings after the round 5 + #127/#130/#128 work landed.

Same shape as #127 (DigitizeStats surfaced) and #130 (jump filter) — both ship wire fields to the service that the engine doesn't yet consume, in the same forward-compatible pattern.
Help page claim at src/pages/Help.tsx:69 is stale.

## Finding The RightPanel's Design Settings section has two dropdowns that the user can change but whose values **never reach the service**: - **Fabric Type** (`src/components/workspace/RightPanel.tsx:131-141`): 5 options (Light Weight Cotton / Medium Weight Cotton / Heavy Weight Cotton / Stretchy / Knit / Towel / Fleece) - **Stabilizer** (`src/components/workspace/RightPanel.tsx:143-151`): 4 options (Cut-Away / Tear-Away / Wash-Away / Adhesive) The values are stored in `designSettings.fabricType` and `designSettings.stabilizer` (in the workspace reducer), they persist with the saved design, and they round-trip through the gallery. But `toServiceSettings` at `src/lib/digitize-adapters.ts:38-65` does **not include either field** in the `AutoDigitizeSettings` object sent to `/v1/digitize`. The service's `DigitizeSettings` schema accepts `fabric` and `targetStitchCount` as forward-compatible wire fields (per the openapi description: "settings accepts `fabric` and `targetStitchCount` as documented forward-compatible hints (the pipeline does not consume them yet)"). The client doesn't send either. The Help page advertises: "Choose your fabric type (light, medium, heavy, stretchy, or towel) — this affects underlay and density recommendations." This is a product promise the current implementation cannot keep, because the choice never reaches the service. ## Where - UI: `src/components/workspace/RightPanel.tsx:131-151` - State: `src/components/workspace/types.ts:145-146` (`fabricType: FabricType;`, `stabilizer: StabilizerType;`) - Adapter (the gap): `src/lib/digitize-adapters.ts:38-65` — does not include `fabric` or `stabilizer` in the return object - Service schema: `DigitizeSettings` accepts `fabric: str` (forward-compatible) - Help page: `src/pages/Help.tsx:69` — "Choose your fabric type..." ## Suggested fix shape Add `fabric` and `targetStitchCount` (the latter is mentioned alongside `fabric` in the openapi description) to the `toServiceSettings` return object. The values come from the workspace state: ```ts return { // ... existing fields ... fabric: workspaceSettings.fabricType ?? 'cotton', // stabilizer isn't in the service schema as a separate field but the service // may want to derive it from fabric; if not, omit it for now }; ``` If the service doesn't yet consume `fabric`, the wire field is a no-op today but it's set up for the moment the service starts honoring it (same pattern as `underlay`, per the comment in `digitize-adapters.ts:55-58`). Longer-term: the service's digitize algorithm should actually use `fabric` to choose underlay and density defaults. The current Help page claim is "this affects underlay and density recommendations" — until the service does this, the help page text is a lie. ## Severity Medium. The user's choices are stored but ignored by the engine. The Help page makes promises the implementation can't keep. ## Discovered by Gap analysis (2026-10-02) of auto-digitize settings after the round 5 + #127/#130/#128 work landed. ## Related - Same shape as #127 (DigitizeStats surfaced) and #130 (jump filter) — both ship wire fields to the service that the engine doesn't yet consume, in the same forward-compatible pattern. - Help page claim at `src/pages/Help.tsx:69` is stale.

Mark added the

bug

triage-approved

labels

2026-10-03 04:24:12 +00:00

Mark referenced this issue from a commit

2026-10-03 06:27:10 +00:00

fix(#146): wire fabric dropdown through to service payload (forward-compat)

Mark commented

2026-10-03 06:30:30 +00:00

Author

Owner

Fixed in 7a6dc74. The RightPanel's Fabric Type dropdown now flows through toServiceSettings and onto the /v1/digitize payload as the forward-compat fabric field. Same wire shape as the underlay toggle (#115): the easystitch-service DigitizeSettings accepts fabric on the wire but _translate_settings ignores it today, so the field is now present and ready for the moment the engine adopts it.

Adapter change: toServiceSettings gained a fabricType parameter; useWorkspace passes state.designSettings.fabricType through.

Workspace FabricType (light/medium/heavy/stretchy/towel) does not overlap with the service's fabric Literal (standard/cotton/polyester/silk/denim/felt/stretch), so the adapter maps each workspace value onto a service-compatible value: light/medium/heavy/towel -> cotton; stretchy -> stretch. A literal pass-through would have 422'd in Pydantic.

Stabilizer remains client-side: the service schema has no stabilizer field, so the value stays in workspace state until/unless the service grows a matching field.

Local gates: tsc clean, 599/599 pass, eslint clean. Pushed as 7a6dc74 on origin/main; CI run #7420 is currently waiting for the self-hosted runner (all recent runs on this repo are stuck waiting/cancelled — that's the queue, not this commit). Will surface separately if CI comes back red.

Help page claim ("this affects underlay and density recommendations") is now wire-accurate: the value reaches the service. Whether the engine actually uses it to alter underlay/density is a follow-up in the service repo (Mark/easystitch-service#31) — not in scope here, since the wire layer is the gap that was fixable from this side.

Fixed in 7a6dc74. The RightPanel's Fabric Type dropdown now flows through `toServiceSettings` and onto the `/v1/digitize` payload as the forward-compat `fabric` field. Same wire shape as the `underlay` toggle (#115): the easystitch-service `DigitizeSettings` accepts `fabric` on the wire but `_translate_settings` ignores it today, so the field is now present and ready for the moment the engine adopts it. Adapter change: `toServiceSettings` gained a `fabricType` parameter; `useWorkspace` passes `state.designSettings.fabricType` through. Workspace FabricType (light/medium/heavy/stretchy/towel) does not overlap with the service's `fabric` Literal (standard/cotton/polyester/silk/denim/felt/stretch), so the adapter maps each workspace value onto a service-compatible value: light/medium/heavy/towel -> cotton; stretchy -> stretch. A literal pass-through would have 422'd in Pydantic. Stabilizer remains client-side: the service schema has no `stabilizer` field, so the value stays in workspace state until/unless the service grows a matching field. Local gates: tsc clean, 599/599 pass, eslint clean. Pushed as 7a6dc74 on origin/main; CI run #7420 is currently `waiting` for the self-hosted runner (all recent runs on this repo are stuck `waiting`/cancelled — that's the queue, not this commit). Will surface separately if CI comes back red. Help page claim ("this affects underlay and density recommendations") is now wire-accurate: the value reaches the service. Whether the engine actually uses it to alter underlay/density is a follow-up in the service repo (Mark/easystitch-service#31) — not in scope here, since the wire layer is the gap that was fixable from this side.

Mark closed this issue

2026-10-03 06:30:33 +00:00