Expand Phase 4 curation plan
This commit is contained in:
@@ -29,7 +29,7 @@ It is intentionally implementation-focused:
|
||||
## Working Status
|
||||
|
||||
- Branch: `frontend/tables-overhaul`
|
||||
- Last updated: `2026-03-21`
|
||||
- Last updated: `2026-04-12`
|
||||
- Current focus: `Phase 4`
|
||||
- Document mode: living plan and progress log
|
||||
|
||||
@@ -75,6 +75,7 @@ It is intentionally implementation-focused:
|
||||
| 2026-03-21 | P3.12 | Completed | Added keyboard-selectable cells, visible focus treatment, and selection normalization so changing filters or modes cannot leave the inspector pointing at hidden cells. |
|
||||
| 2026-03-21 | Post-P3 fix 1 | Completed | Added a defensive visible-column fallback in the table canvas and tightened view-state normalization so a stale severity filter cannot collapse the grid to roll bands only. |
|
||||
| 2026-04-11 | Post-P3 fix 2 | Completed | Simplified `/tables` by removing static prose and context controls, dropped the redundant selected-result inspector in favor of a floating action menu, and moved the canvas onto its own scroll region so sticky headers layer correctly beneath the context bar. |
|
||||
| 2026-04-12 | Phase 4 planning | Planned | Expanded the `Curation` phase from a route placeholder into a concrete migration plan that moves queue-first curation out of `Tables` and into a dedicated workflow surface. |
|
||||
|
||||
### Lessons Learned
|
||||
|
||||
@@ -562,47 +563,127 @@ Turn `/tables` into the canonical reference surface for reading and inspecting c
|
||||
|
||||
## Phase 4: `Curation` Workflow Surface
|
||||
|
||||
### Status
|
||||
|
||||
`Planned`
|
||||
|
||||
### Task Progress
|
||||
|
||||
| Task | Status | Notes |
|
||||
| --- | --- | --- |
|
||||
| `P4.1` | Planned | Replace the current placeholder route with a real stateful `Curation` host page while keeping shell navigation and route identity stable. |
|
||||
| `P4.2` | Planned | Reuse the shared table-context and selection patterns from Phase 2 and Phase 3 so queue state, deep links, and restore behavior stay consistent with `Tables`. |
|
||||
| `P4.3` | Planned | Introduce one normalized queue-scope model for `All tables`, `Selected table`, and `Pinned set` instead of hard-coding the current table-only flow. |
|
||||
| `P4.4` | Planned | Introduce a shared queue descriptor and next-item selection pipeline so queue ordering and scope resolution are not trapped inside `Tables.razor`. |
|
||||
| `P4.5` | Planned | Build a queue-first split workspace with summary, source image, parsed preview, quick parse input, and predictable primary actions. |
|
||||
| `P4.6` | Planned | Rehost the current load, reparse, mark-curated, and save-and-advance mechanics from `Tables` with minimal churn instead of rewriting them from scratch. |
|
||||
| `P4.7` | Planned | Preserve full editor access as an escape hatch while making `Mark curated` and `Quick parse` the common fast path. |
|
||||
| `P4.8` | Planned | Keep save-and-advance inside the same workflow lane by retaining scope, queue ordering, and current work context after save. |
|
||||
| `P4.9` | Planned | Keep the action hierarchy disciplined so warning treatment is reserved for disruptive repair actions rather than normal save flow. |
|
||||
| `P4.10` | Planned | Remove raw diagnostics and provenance details from the default curation lane and link out to `Tools` when deep inspection is needed. |
|
||||
|
||||
### Current Baseline
|
||||
|
||||
- The route already exists at `Components/Pages/Curation.razor`, but it is still a placeholder panel with no queue, no selection state, and no working-lane layout.
|
||||
- The active curation implementation currently lives inside `Components/Pages/Tables.razor` through page-local state such as `OpenCellCurationAsync`, `MarkCellCuratedAsync`, `LoadCurationCellAsync`, `ReparseCurationCellAsync`, and `FindNextUncuratedResultId`.
|
||||
- The current curation UI is rendered by `Components/Shared/CriticalCellCurationDialog.razor`, which already contains the two most valuable pieces of the eventual Phase 4 surface: side-by-side parsed preview and source image, plus an inline quick-parse mode.
|
||||
- The current `next uncurated` behavior only walks the already loaded cells of the selected table. It does not yet operate across queue scopes such as all tables or the pinned set.
|
||||
- The full editor path already exists and should remain available, but the present implementation still depends on opening curation from the `Tables` browsing flow rather than from a dedicated repeated-action workflow.
|
||||
|
||||
### Goal
|
||||
|
||||
Create a dedicated queue-first curation workflow so repair work is fast and does not pollute the reference experience.
|
||||
|
||||
### Tasks
|
||||
|
||||
- `P4.1` Create the new `/curation` page and route.
|
||||
- `P4.2` Reuse shared table/context selection patterns from Phase 2 and Phase 3.
|
||||
- `P4.1` Replace the placeholder `/curation` route body with a real stateful page host:
|
||||
- keep the existing route and shell navigation entry point
|
||||
- own queue scope, current queue item, quick-parse mode, loading states, and save-and-advance transitions in the page host
|
||||
- keep rendering concerns in focused `Components/Curation` children rather than rebuilding another monolithic page
|
||||
- `P4.2` Reuse shared table/context selection patterns from Phase 2 and Phase 3:
|
||||
- build on `TableContextState`, shared URL serialization, and the existing table identifiers already used by `Tables` and diagnostics
|
||||
- preserve table, group, column, roll band, result id, and curation mode context where useful
|
||||
- keep curation selection deterministic and bookmarkable rather than page-local only
|
||||
- `P4.3` Define queue scopes:
|
||||
- all tables
|
||||
- selected table
|
||||
- pinned set
|
||||
- `P4.4` Build a stable queue-first layout with:
|
||||
- `P4.4` Build one normalized queue descriptor and selection pipeline behind those scopes:
|
||||
- selected scope value
|
||||
- optional selected table slug when the scope is table-specific
|
||||
- current queue item identity
|
||||
- queue ordering rules
|
||||
- next-item resolution that is independent from the `Tables` page
|
||||
- `P4.5` Build a stable queue-first layout with:
|
||||
- current queue item summary
|
||||
- queue scope controls
|
||||
- next-item affordance in a fixed, predictable location
|
||||
- source image
|
||||
- parsed preview
|
||||
- quick parse area
|
||||
- compact queue metadata such as table, group, column, roll band, and curated state
|
||||
- save-and-advance actions
|
||||
- `P4.5` Move the current “next uncurated” logic into the dedicated workflow surface.
|
||||
- `P4.6` Keep full editor access available, but make quick parse and mark curated the fast path.
|
||||
- `P4.7` Ensure save-and-advance keeps the user in the same workflow lane without reopening context.
|
||||
- `P4.8` Use warning styling only for disruptive repair actions, not for normal save flow.
|
||||
- `P4.9` Hide developer-only diagnostics from the normal curation workflow.
|
||||
- `P4.6` Extract and reuse the current curation mechanics from `Tables.razor` with minimal churn:
|
||||
- loading the current result card for curation
|
||||
- quick parse and reparse
|
||||
- mark curated
|
||||
- save and advance
|
||||
- open full editor for edge cases
|
||||
- `P4.7` Keep full editor access available, but make quick parse and mark curated the fast path:
|
||||
- quick parse should stay inline in the curation workspace
|
||||
- full edit should remain one action away without becoming the default
|
||||
- avoid modal-on-modal or browse-surface detours for normal work
|
||||
- `P4.8` Ensure save-and-advance keeps the user in the same workflow lane without reopening context:
|
||||
- preserve queue scope and ordering after save
|
||||
- advance immediately when another queue item exists
|
||||
- surface a clear terminal state when the current queue is exhausted
|
||||
- `P4.9` Use warning styling only for disruptive repair actions, not for normal save flow:
|
||||
- `Mark curated` and `Save and continue` remain strong-accent primary actions
|
||||
- warning styling is reserved for unusual or risky repair paths, not ordinary progression
|
||||
- `P4.10` Hide developer-only diagnostics from the normal curation workflow:
|
||||
- keep raw JSON, parser provenance, and engineering detail out of the default curation lane
|
||||
- provide links into `Tools` when deep inspection is needed instead of embedding diagnostics directly in `Curation`
|
||||
|
||||
### Deliverables
|
||||
|
||||
- `/curation` page
|
||||
- queue-first layout
|
||||
- stateful `/curation` page host
|
||||
- shared queue-scope and next-item selection helpers
|
||||
- queue-first split layout components
|
||||
- integrated save-and-advance flow
|
||||
- quick parse in-context workflow
|
||||
- inline quick-parse workflow
|
||||
- preserved full-editor handoff from the curation lane
|
||||
- context-preserving links between `Curation`, `Tables`, and `Tools`
|
||||
|
||||
### Acceptance Criteria
|
||||
|
||||
- a curator can move from one uncurated cell to the next with one primary action after save
|
||||
- a curator can start from `All tables`, `Selected table`, or `Pinned set` without losing the repeated-action workflow
|
||||
- source and parsed result are visible side by side on wide screens
|
||||
- quick parse can be completed without opening the full editor for common cases
|
||||
- full editor remains available as a secondary path for complex corrections
|
||||
- normal curation work does not require stacked dialogs or re-entering queue context after every save
|
||||
- the queue can be exhausted gracefully without dropping the user into an ambiguous empty state
|
||||
- diagnostics detail is not embedded by default in the curation workspace
|
||||
- `Tables` no longer carries the primary queue-work burden
|
||||
|
||||
### Definition Of Done
|
||||
|
||||
- curation is a dedicated workflow page with a stable repeated interaction loop
|
||||
- `Tables` remains browse-first after the queue workflow moves out
|
||||
- queue scope, item context, and save-and-advance behavior are implemented once and not duplicated between `Tables` and `Curation`
|
||||
|
||||
### Phase 4 Implementation Notes
|
||||
|
||||
- The lowest-risk migration path is to keep `CriticalCellCurationDialog` as the behavioral baseline, extract any queue and save helpers that are currently trapped in `Tables.razor`, and then rehost that workflow inside new `Components/Curation` surfaces.
|
||||
- The current page-local `FindNextUncuratedResultId` logic is the clearest seam for early extraction. Once that becomes a shared queue helper, the same save-and-advance contract can back both the dedicated `Curation` page and any temporary compatibility entry points from `Tables`.
|
||||
- `Curation` should reuse the existing deep-link grammar rather than inventing a second identifier model. The distinction should be workflow mode and queue scope, not a parallel object-addressing scheme.
|
||||
- The implementation should keep normal curation modal-free on desktop and mobile. Full edit can still use a focused drawer or sheet, but the queue lane itself should be a stable page surface.
|
||||
- Verification for the implementation phase should include:
|
||||
- build success
|
||||
- save-and-advance through at least one real uncurated item
|
||||
- quick parse round-trip in the queue lane
|
||||
- queue exhaustion behavior
|
||||
- context-preserving navigation back to `Tables` and into `Tools` when needed
|
||||
|
||||
## Phase 5: `Tools` Consolidation
|
||||
|
||||
|
||||
Reference in New Issue
Block a user