The shipped side panel diverges from the panel prototype in four ways

[lamemustafa]

The shipped side panel (#189, on #169's surface) diverges from the panel prototype produced by the
UX-redesign lane. Recorded here because that session has ended and the divergence should not live
only in a chat log.

This is a report on the implementation, not a complaint about the design. #189 was scoped as
"take the permission and make the action open the panel", and it was built from #169's existing
surface rather than from the prototype. That was the wrong read of what was wanted.

Matches the prototype

Header (mark, "Pack", "ComplyEaze", "GST portal · signed in"), the default-view shape, the local-only
footer, and opening on the current financial year.

Diverges, roughly by how much it matters

1. The custom view is the old scope form, not the matrix.
The prototype has a drag-selectable grid — return types as rows, twelve months as columns, grouped by
financial year, unavailable cells disabled, a row label taking the whole year, and "Earlier years"
revealing the rest. What ships behind "Choose a period" is the popup's ScopeForm: return chips,
range, financial-year dropdown, format chips, one button. That is the surface the prototype was
written to replace, reached through a different door.

2. No per-target progress.
The prototype shows a live row per target with a status glyph and an evidence column, under a
status line reading "N of M saved". What ships shows an aggregate: "12 periods saved as one ZIP".

The evidence column is the part worth defending. It is the visible form of the rule that completion
requires correlated download evidence, and an aggregate cannot express a partially-settled run — see
#190, filed from the same live run, where the aggregate and the evidence state contradict each other
on screen.

3. No three-answer review card.
The prototype's paused-target card asks one question with three answers and records "I checked
Downloads" as a manual observation that explicitly does not complete the target. Whether the
shipped RecoveryActions preserves that distinction is unverified. If it does not, that is a
correctness gap in UI clothing.

4. Recipes are per-return-type.
Shipped: three presets, one each for GSTR-3B, GSTR-1, GSTR-2B. The prototype has two — "This year's
GSTR-3B" and "Everything this year" — the second being cross-return, which nothing shipped offers.
The prototype's own notes argue for fewer choices on the first screen, so the count difference looks
deliberate on its side.

Separately: the foreground sentence is a paragraph again

The shipped custom view reads "Keep GST Portal visible in the foreground while Pack creates one ZIP
for all eligible periods."

That was explicitly agreed to be a value derived from whether a run actually requires foreground,
rather than static copy someone must remember to delete. It predates #189, but it is now on the
surface a user meets, and #187 may make it false.

What would settle this

Which of the four are load-bearing, and which were prototype exploration since moved past. Better to
close the real ones deliberately than to reproduce a prototype line by line. If the matrix and the
per-target evidence list are both load-bearing, they want their own lane on top of #189 rather than a
retrofit into it.

[lamemustafa]

Divergence 3 verified against master at cd3a4db. The distinction is preserved. It is not a correctness gap in UI clothing.

Checked at three levels, because the UI saying the right thing would not be enough on its own:

1. The UI says it outright. recovery-actions.tsx:129, shown once a manual observation is recorded:

Manual observation recorded. It does not complete this target.

The component also disables further manual resolution afterwards — canManuallyResolveTarget excludes a target already carrying filed-returns-target-manually-observed — so the observation cannot be repeated into looking like progress.

2. The ledger cannot count it as complete. POSITIVE_TARGET_STATUSES is { downloaded, not-filed }. manually-observed is deliberately absent, so targets.every(POSITIVE) can never be satisfied by observations, and ledgerStatus maps a trailing manually-observed to partial. hasRecoverableActionRequiredTarget still counts it as needing action.

3. A test pins it. filed-returns-full-fiscal-year-recovery.test.ts asserts, for a manually-observed target: status: "partial", completedPeriods: [], the persisted target status, and — the sharp one — expect(JSON.stringify(response)).not.toContain("browser-confirmed"). So the response cannot claim browser confirmation for something a person merely looked at.

One thing that looked wrong and is not. hasTerminalPositiveTarget groups manually-observed with downloaded and not-filed. Its only caller decides whether an existing blocked ledger may be replaced, and there the grouping is right: a manually-observed target is real work a user performed, and silently discarding that ledger would throw it away. It gates replacement, not completion.

What this means for the issue

Divergence 3 reduces to presentation: the prototype asks one question with three answers, the shipped panel offers separate buttons. Worth doing if the panel is being reworked anyway, but nothing behind it is unsafe.

That leaves divergence 2 as the only load-bearing one — an aggregate cannot express a partially-settled run, and #190 recorded that contradiction appearing on screen. The evidence column is the visible form of a rule the runtime already enforces; everything else here is design preference.

If it helps to sequence: divergence 2, then #206 in the same pass since it is the same surface and the same class of problem — a control offering something the runtime will refuse.