Mark/Kimi_Agent_Brother_10_Digitizing_App

Fork 0

Workspace's digitize overlay shows hard-coded 'Analyzing image...' text — the dispatched `processingMessage` is set in state but never read; same string is hard-coded in the UI #202

New issue

Closed

opened 2026-10-03 23:53:02 +00:00 by Mark · 1 comment

Mark commented

2026-10-03 23:53:02 +00:00

Owner

Finding

src/components/workspace/useWorkspace.ts dispatches:

dispatch({ type: 'SET_PROCESSING', step: 1, message: 'Analyzing image…' });

The message lands in state.processingMessage (per the WorkspaceState type at types.ts:218). The dispatched message is 'Analyzing image…' (with a horizontal ellipsis character …).

grep -rn 'state\.processingMessage\|processingMessage' src/components/ returns 0 matches. The dispatched message is never rendered.

Meanwhile, the UI's digitize overlay (src/components/workspace/CanvasArea.tsx:478-485) hard-codes:

<p>Analyzing image...</p>

Three regular dots ..., not the ellipsis character …. The strings match in spirit but the abstraction is broken:

A user adds a new step with a custom message
The dispatched message is silently absorbed
The UI still shows "Analyzing image..."

A future change to the step labels has to be made in two places (the dispatch site AND the UI), with no type check to catch the drift.

Where

Dispatch: src/components/workspace/useWorkspace.ts (the SET_PROCESSING dispatch)
State field: src/components/workspace/types.ts:218 (processingMessage: string)
Hard-coded UI: src/components/workspace/CanvasArea.tsx:478-485
No reader: grep -rn 'processingMessage' src/components/ returns 0 hits

Suggested fix shape

Two changes:

Read the message from state in the digitize overlay:

<p>{state.processingMessage || 'Processing…'}</p>

Pass processingMessage as a prop to CanvasArea (or read it from a useWorkspace() consumer inside the canvas).

The processingStep is already passed (per the prop wiring). processingMessage is the missing piece.

Optionally: drive the per-step labels from a single source of truth. src/components/workspace/CanvasArea.tsx:486-510 renders PROCESSING_STEPS.map((step, i) => ...) — that constant is hard-coded too. A single PROCESSING_STEPS_AND_MESSAGES array with { step, message } pairs would let the dispatched state drive both the checklist and the headline text.

Severity

Low. The user sees "Analyzing image..." in the UI; the dispatched message is silent. The abstraction is broken; the visible output is fine.

Discovered by

Gap analysis (2026-10-02) of workspace state/UI symmetry.

#60 (closed) — Run Auto-Digitize button. The dispatch flow was simplified; this gap is downstream.
The processingStep array is also hard-coded in the UI; same family of bug.

## Finding `src/components/workspace/useWorkspace.ts` dispatches: ```ts dispatch({ type: 'SET_PROCESSING', step: 1, message: 'Analyzing image…' }); ``` The message lands in `state.processingMessage` (per the `WorkspaceState` type at `types.ts:218`). The dispatched message is `'Analyzing image…'` (with a horizontal ellipsis character `…`). `grep -rn 'state\.processingMessage\|processingMessage' src/components/` returns 0 matches. The dispatched message is never rendered. Meanwhile, the UI's digitize overlay (`src/components/workspace/CanvasArea.tsx:478-485`) hard-codes: ```tsx <p>Analyzing image...</p> ``` Three regular dots `...`, not the ellipsis character `…`. The strings match in spirit but the abstraction is broken: - A user adds a new step with a custom message - The dispatched message is silently absorbed - The UI still shows "Analyzing image..." A future change to the step labels has to be made in two places (the dispatch site AND the UI), with no type check to catch the drift. ## Where - Dispatch: `src/components/workspace/useWorkspace.ts` (the SET_PROCESSING dispatch) - State field: `src/components/workspace/types.ts:218` (`processingMessage: string`) - Hard-coded UI: `src/components/workspace/CanvasArea.tsx:478-485` - No reader: `grep -rn 'processingMessage' src/components/` returns 0 hits ## Suggested fix shape Two changes: 1. **Read the message from state** in the digitize overlay: ```tsx <p>{state.processingMessage || 'Processing…'}</p> ``` 2. **Pass `processingMessage` as a prop** to `CanvasArea` (or read it from a `useWorkspace()` consumer inside the canvas). The `processingStep` is already passed (per the prop wiring). `processingMessage` is the missing piece. Optionally: drive the per-step labels from a single source of truth. `src/components/workspace/CanvasArea.tsx:486-510` renders `PROCESSING_STEPS.map((step, i) => ...)` — that constant is hard-coded too. A single `PROCESSING_STEPS_AND_MESSAGES` array with `{ step, message }` pairs would let the dispatched state drive both the checklist and the headline text. ## Severity Low. The user sees "Analyzing image..." in the UI; the dispatched message is silent. The abstraction is broken; the visible output is fine. ## Discovered by Gap analysis (2026-10-02) of workspace state/UI symmetry. ## Related - #60 (closed) — Run Auto-Digitize button. The dispatch flow was simplified; this gap is downstream. - The `processingStep` array is also hard-coded in the UI; same family of bug.

Mark added the

bug

triage-approved

labels

2026-10-03 23:53:02 +00:00

Mark referenced this issue from a commit

2026-10-04 01:49:09 +00:00

fix(#202): digitize overlay headline reads state.processingMessage

Mark commented

2026-10-04 01:50:29 +00:00

Author

Owner

Fixed in commit b05b113 (main).

Change: src/components/workspace/CanvasArea.tsx now destructures processingMessage from state and renders {processingMessage || "Processing…"} in place of the hard-coded Analyzing image.... The dispatched SET_PROCESSING message is now actually displayed; the fallback Processing… (with horizontal ellipsis) shows when no message is set.

Verification:

tsc --noEmit -p tsconfig.app.json clean
eslint clean on changed files
vitest 916/916 pass (was 914; +2 new tests for the headline contract — one pins the dispatch->render path, one pins the empty-message fallback)

Scope note: The headline fix is the minimum change for this issue. The same family of bug exists for PROCESSING_STEPS (the per-step labels in the checklist are still hard-coded in the UI). That is a separate issue — the per-step labels need a coordinated reducer change to push a message per step, not just at step 1 / step 4. Worth filing as a follow-up if you want single-source-of-truth.

Fixed in commit b05b113 (main). **Change:** `src/components/workspace/CanvasArea.tsx` now destructures `processingMessage` from `state` and renders `{processingMessage || "Processing…"}` in place of the hard-coded `Analyzing image...`. The dispatched `SET_PROCESSING` message is now actually displayed; the fallback `Processing…` (with horizontal ellipsis) shows when no message is set. **Verification:** - `tsc --noEmit -p tsconfig.app.json` clean - `eslint` clean on changed files - `vitest` 916/916 pass (was 914; +2 new tests for the headline contract — one pins the dispatch->render path, one pins the empty-message fallback) **Scope note:** The headline fix is the minimum change for this issue. The same family of bug exists for `PROCESSING_STEPS` (the per-step labels in the checklist are still hard-coded in the UI). That is a separate issue — the per-step labels need a coordinated reducer change to push a `message` per step, not just at step 1 / step 4. Worth filing as a follow-up if you want single-source-of-truth.

Mark closed this issue

2026-10-04 01:50:44 +00:00

Mark referenced this issue

2026-10-04 03:39:22 +00:00

Workspace has no progress indicator for auto-digitize — user uploading a large image sees the canvas blank with no feedback while the service runs (could be 5-30s), no step number, no progress bar, no message #264

Mark referenced this issue from a commit

2026-10-04 12:10:45 +00:00

fix(#264): Workspace auto-digitize — progress pill instead of full-screen overlay

Mark referenced this issue

2026-10-04 12:10:56 +00:00