xTr1m/RolemasterDB
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Expand Phase 4 curation plan

Browse Source
This commit is contained in:
Frank Tovar
2026-04-12 00:19:52 +02:00
parent 66cf050be0
commit b1bad734b9
1 changed files with 93 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

105
docs/tables_frontend_overhaul_implementation_plan.md
View File

@@ -29,7 +29,7 @@ It is intentionally implementation-focused:
## Working Status ## Working Status
- Branch: `frontend/tables-overhaul` - Branch: `frontend/tables-overhaul`
- Last updated: `2026-03-21` - Last updated: `2026-04-12`
- Current focus: `Phase 4` - Current focus: `Phase 4`
- Document mode: living plan and progress log - 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 | 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-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-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 ### Lessons Learned
@@ -562,47 +563,127 @@ Turn `/tables` into the canonical reference surface for reading and inspecting c
## Phase 4: `Curation` Workflow Surface ## 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 ### Goal
Create a dedicated queue-first curation workflow so repair work is fast and does not pollute the reference experience. Create a dedicated queue-first curation workflow so repair work is fast and does not pollute the reference experience.
### Tasks ### Tasks
- `P4.1` Create the new `/curation` page and route. - `P4.1` Replace the placeholder `/curation` route body with a real stateful page host:
- `P4.2` Reuse shared table/context selection patterns from Phase 2 and Phase 3. - 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: - `P4.3` Define queue scopes:
- all tables - all tables
- selected table - selected table
- pinned set - 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 - current queue item summary
- queue scope controls
- next-item affordance in a fixed, predictable location
- source image - source image
- parsed preview - parsed preview
- quick parse area - quick parse area
- compact queue metadata such as table, group, column, roll band, and curated state
- save-and-advance actions - save-and-advance actions
- `P4.5` Move the current “next uncurated” logic into the dedicated workflow surface. - `P4.6` Extract and reuse the current curation mechanics from `Tables.razor` with minimal churn:
- `P4.6` Keep full editor access available, but make quick parse and mark curated the fast path. - loading the current result card for curation
- `P4.7` Ensure save-and-advance keeps the user in the same workflow lane without reopening context. - quick parse and reparse
- `P4.8` Use warning styling only for disruptive repair actions, not for normal save flow. - mark curated
- `P4.9` Hide developer-only diagnostics from the normal curation workflow. - 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 ### Deliverables
- `/curation` page - stateful `/curation` page host
- queue-first layout - shared queue-scope and next-item selection helpers
- queue-first split layout components
- integrated save-and-advance flow - 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 ### Acceptance Criteria
- a curator can move from one uncurated cell to the next with one primary action after save - 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 - 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 - 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 - `Tables` no longer carries the primary queue-work burden
### Definition Of Done ### Definition Of Done
- curation is a dedicated workflow page with a stable repeated interaction loop - 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 ## Phase 5: `Tools` Consolidation