Rephase UX redesign roadmap

docs/player_gm_ux_redesign_plan.md

@@ -293,21 +293,20 @@ This creates a stable reading rhythm across rows with uneven prose length.
 
 ### 4. Critical Cell Editing
 
-The edit popup should become a result editor with automatic re-parse support.
+The edit popup should become a compact result editor with automatic re-parse support.
 
 ### Editing goal
 
-A curator should be able to type the minimum required raw text and let the system fill the normalized card structure automatically.
+A curator should be able to correct a result quickly in a dense popup without giving up space to a separate preview panel.
 
 ### Default editor content
 
 Show:
 
-- a live preview of the resulting critical card
 - raw cell text
-- description text when manual override is needed
+- one-line result text editing when manual override is needed
-- affix chips/effects
+- compact inline affix/effect rows with the same badges/icons used in read mode
-- branch cards
+- compact inline condition rows with their own effect chips
 
 Hide from default editing:
 
@@ -319,12 +318,12 @@ Hide from default editing:
 
 ### Editor structure
 
-1. Result preview
+1. Raw text input
-2. Raw text input
+2. Compact inline parsed sections the user can adjust
-3. Parsed sections the user can adjust
+3. Save actions
-4. Save actions
+4. Optional advanced diagnostics disclosure
 
-The preview should always answer, "What card will the GM/player actually see?"
+There should be no dedicated preview panel in the popup. The edit rows themselves should carry the same affix badges, branch labels, and visible wording that the final result uses.
 
 ### Re-import / re-parse behavior
 
@@ -334,13 +333,14 @@ When the user edits `RawCellText`:
 - optionally support debounced auto-parse after input stabilizes
 - regenerate description, effects, branches, and conditions from shared parser logic
 - preserve user edits only where the user explicitly overrode generated values
+- surface parser notes in advanced disclosure instead of spending default popup space on them
 
 ### Manual override model
 
 A critical result should support two states:
 
 - imported from the pdf
-- raw input manually overridden and derived fields generated from raw input or also manually overriden
+- raw input manually overridden and derived fields generated from raw input or also manually overridden
 
 This avoids the current problem where re-imports using the tool discards user curations.
 
@@ -350,19 +350,22 @@ Adding affixes should not require editing raw structured records.
 
 ### Proposed interaction
 
-- show affixes as chips
+- show each effect as a compact inline row with its affix badge and dropdown
-- include a chip with a plus icon
+- keep add/remove actions small and local to the row
-- clicking the plus chip opens a compact inline editor
+- let the user choose the effect type from the same row they are editing
-- user chooses the affix type from a dropdown
+- show only the minimum value input needed for that effect type
-- user enters the numeric value or expression when needed
+- update the visible badge and label directly in the row without a separate preview area
-- saving immediately creates the new chip
 
 ### Requirements
 
 - chip labels must use user-facing terminology
 - the affix legend and effect codes must map cleanly
 - the editor should support symbol-driven and numeric affixes
-- deleting an affix should be one click from the chip
+- deleting an affix should be one click from the row
+- do not waste space on a redundant title when the dropdown already identifies the effect
+- do not show a `Target` field for `direct_hits`
+- do not show a `Permanent` checkbox in the default editor
+- keep source metadata and internal links out of the default row layout
 
 ### 6. Condition And Branch Editing UX
 
@@ -370,11 +373,11 @@ Branch editing should follow the same interaction model as affixes.
 
 ### Proposed interaction
 
-- branches render as condition cards
+- branches render as compact inline condition rows
-- include a plus chip or plus button for "Add condition"
+- include a small add button for `Add condition`
-- user selects condition type from a dropdown
+- user selects or types the condition text directly in the row
-- user enters the condition value or free text when required
+- user enters optional outcome prose inline
-- the branch card is created immediately
+- branch effects are edited with the same compact affix rows used on the base result
 
 ### Branch card contents
 
@@ -485,101 +488,98 @@ Create a new assembly for critical import/domain transformation logic, for examp
 ### Web editor workflow after shared parsing
 
 1. User opens a critical cell.
-2. The app shows the rendered card preview and raw text input.
+2. The app shows raw text and compact inline edit rows for the visible result.
 3. User edits raw text.
 4. The app calls shared parsing logic for that cell.
 5. The parser returns normalized description, affixes, conditions, branches, and validation messages.
-6. The UI updates the card preview automatically.
+6. The UI updates the inline editing rows automatically.
 7. The user makes small manual fixes only where generation is insufficient.
 8. Save persists both raw text and the normalized result.
 
 This is the key UX shift: the system does the import work again at cell scope instead of forcing the curator to manually edit every derived field.
 
-## Proposed Rollout Phases
+## Implemented Foundation
 
-### Phase 1: Strip visible technical noise
+The following groundwork is already implemented in the web app as of March 15, 2026:
 
-Status:
+- visible technical chrome has been removed from the primary lookup and table flows
+- lookup result cards now lead with gameplay outcome instead of parse metadata
+- the critical table browser is framed for play use rather than import administration
+- critical cells support re-parse from shared parser logic
+- advanced diagnostics have been separated from the primary editing flow
 
-- implemented in the web app on March 15, 2026
+These changes are real and complete, but they are no longer the active roadmap because the detailed acceptance checklist still has unfinished items.
+
+## Remaining Implementation Phases
+
+### Phase 1: Complete live lookup flow ergonomics
 
 Scope:
 
-- simplify home page copy
+- add dice buttons to the attack and direct critical lookup inputs
-- simplify lookup result card
+- support fast reroll without manual typing
-- remove technical metadata from default visible surfaces
+- tighten any remaining lookup prompts so a first-time GM can move through the flow without reading extra copy
 
 Acceptance criteria:
 
-- no SQLite/import/debug references in primary play flows
+- both lookup flows support random roll entry without typing
-- lookup result card shows gameplay outcome first
+- the main lookup page fully satisfies the live-play checklist item for random lookup support
 
-### Phase 2: Clean up critical table browsing
+### Phase 2: Compact inline cell editor
-
-Status:
-
-- implemented in the web app on March 15, 2026
 
 Scope:
 
-- reframe tables page around reading and selecting outcomes
+- remove the dedicated preview panel from the critical cell popup
-- bottom-align branch stacks inside critical cells
+- convert effect editing to dense inline rows with badges/icons and minimal controls
-- keep the affix legend but present it as play help, not import metadata
+- convert branch editing to the same compact inline model
+- remove redundant effect titles and any non-essential controls from the default edit surface
 
 Acceptance criteria:
 
-- dense table rows remain visually aligned
+- the popup spends its space on actual editing rather than preview duplication
-- the page reads as a usable table browser during play
+- common effect and branch corrections require less scrolling than the current popup
+- `direct_hits` has no unused `Target` field in the default editor
+- the default editor has no `Permanent` checkbox
 
-### Phase 3: Redesign the cell editor
+### Phase 3: Generated versus overridden state model
-
-Status:
-
-- implemented in the web app on March 15, 2026
 
 Scope:
 
-- add live result preview
+- explicitly track which values are parser-generated and which values were manually overridden
-- remove parse/debug/import fields from default editing
+- ensure re-parse refreshes generated values without silently discarding intentional edits
-- add chip-based affix and condition editing
+- define how save and future import refresh flows respect manual overrides
 
 Acceptance criteria:
 
-- editing focuses on the resulting card
+- shared parsing can regenerate derived data without clobbering preserved overrides
-- common corrections require materially less scrolling and fewer fields
+- the manual override model described in this document is implemented rather than only implied
 
-### Phase 4: Shared parsing assembly
+### Phase 4: Compare and review workflow
-
-Status:
-
-- implemented in the web app on March 15, 2026
 
 Scope:
 
-- extract shared parser/normalizer logic from the import tool
+- add a clear comparison surface for generated result versus current edited result
-- consume it from the web app
+- let curators review what changed after re-parse before accepting or keeping overrides
-- support single-cell re-parse from raw text
+- keep this comparison workflow in advanced curation, not in the primary live-play path
 
 Acceptance criteria:
 
-- import tool and web app produce the same normalized result for equivalent raw cell input
+- curators can inspect generated-versus-current differences without reading raw JSON first
-- raw text changes can regenerate card fields automatically
+- compare tooling exists for the override workflow described above
 
-### Phase 5: Advanced curation and diagnostics split
+### Phase 5: Final tooling boundary cleanup
-
-Status:
-
-- implemented in the web app on March 15, 2026
 
 Scope:
 
-- move debug/import details into a separate advanced surface
+- verify that normal curation mode contains only user-facing correction tools
-- optionally add diff/compare tools for generated vs overridden values
+- move any remaining engineering-only diagnostics into a separate developer or admin surface if they still leak into curation mode
+- leave advanced curation available without forcing ordinary users through engineering concepts
 
 Acceptance criteria:
 
-- primary editing surface stays clean
+- the primary play flow stays clean
-- engineering diagnostics remain available without polluting live-play UX
+- compact curation remains available
+- engineering diagnostics remain accessible without defining the normal correction UX
 
 ## Detailed Acceptance Checklist
 
@@ -622,4 +622,4 @@ Mitigation:
 
 ## Recommended Next Step
 
-Implement Phase 1 and Phase 2 first. They offer immediate UX improvement with low architectural risk and create the visual foundation for the editor redesign and shared parsing work that follow.
+Implement the new Phase 1 and Phase 2 first. Dice-button support and the compact inline popup editor close the most visible gaps in the detailed acceptance checklist and should be completed before the override and compare workflow phases.