Add quick parse notation for critical editor
This commit is contained in:
@@ -574,6 +574,7 @@ The following groundwork is already implemented in the web app as of March 15, 2
|
||||
- critical cells support re-parse from shared parser logic
|
||||
- advanced diagnostics have been separated from the primary editing flow
|
||||
- advanced curation now includes a generated-versus-current comparison view for re-parse review
|
||||
- critical cells now open with quick parse input derived from the imported result instead of requiring OCR-era symbol typing
|
||||
|
||||
These changes are real and complete, but they are no longer the active roadmap because the detailed acceptance checklist still has unfinished items.
|
||||
|
||||
@@ -680,6 +681,18 @@ Acceptance criteria:
|
||||
|
||||
### Phase 6: Friendly quick parse input
|
||||
|
||||
Status:
|
||||
|
||||
- implemented in the web app on March 15, 2026
|
||||
|
||||
Implemented model:
|
||||
|
||||
- the editor now treats quick parse input as the primary generation surface
|
||||
- existing imported results are translated into quick parse notation on the fly when the editor opens
|
||||
- the popup shows a supported shorthand legend directly under the quick input field
|
||||
- generation supports all currently available effect types, including power-point modifiers such as `+2d10-3pp`
|
||||
- OCR glyph tokens remain accepted as compatibility aliases, but they are no longer the primary editing language
|
||||
|
||||
Scope:
|
||||
|
||||
- add a dedicated `Quick parse input` field distinct from OCR provenance
|
||||
@@ -752,4 +765,4 @@ Mitigation:
|
||||
|
||||
## Recommended Next Step
|
||||
|
||||
Implement Phase 6 next. The current structural gap is the editor input model itself: curators still need a friendly quick parse grammar that treats the first line as prose, all following lines as affix or conditional-affix lines, and comma-separated aliases as the normal typing language instead of OCR-era symbols.
|
||||
Implement Phase 7 next. The remaining parser gap is trustworthiness under imperfect input: unknown tokens still need stronger surfaced review, and no-silent-loss behavior should be enforced comprehensively across compare output and regression coverage.
|
||||
|
||||
Reference in New Issue
Block a user