docs: update scanner roadmap after merge
This commit is contained in:
AzuTear
+51
-27
@@ -5,14 +5,14 @@ This document is the source of truth for project intent, scope, runtime facts, a
|
||||
For implementation structure, see [ARCHITECTURE.md](ARCHITECTURE.md). For engineering standards, see [CONVENTIONS.md](CONVENTIONS.md).
|
||||
For the latest Inventory-Kamera comparison work, see
|
||||
[scanner-ik-progress-report.md](scanner-ik-progress-report.md).
|
||||
For the current branch merge checklist, see [MERGE_READINESS.md](MERGE_READINESS.md).
|
||||
For the 2026-07-09 scanner merge evidence, see [MERGE_READINESS.md](MERGE_READINESS.md).
|
||||
|
||||
## Project Identity
|
||||
|
||||
| Field | Value |
|
||||
| --- | --- |
|
||||
| Project name | Genshin Artifact Assistant |
|
||||
| Status | Scanner rebuild in progress |
|
||||
| Status | Scanner baseline merged to `main`; repeatability, corpus growth, and recommendation work are next |
|
||||
| Platform | Windows desktop |
|
||||
| Target users | Genshin Impact players who want artifact decisions without complex optimizer setup |
|
||||
| Runtime | Electron app with React UI and TypeScript |
|
||||
@@ -43,14 +43,14 @@ The app is not intended to replace deep min-max tools. It prioritizes time savin
|
||||
|
||||
| ID | Requirement | Priority | Status |
|
||||
| --- | --- | --- | --- |
|
||||
| FR-001 | List capture sources and automatically prefer the detected Genshin window when available. | Must | Prototype |
|
||||
| FR-002 | Read one currently opened artifact reliably from the local screen and show its parsed result. | Must | Prototype |
|
||||
| FR-003 | Generate and maintain a local canonical Genshin data package for sets, pieces, slots, stats, characters, aliases, and UI profiles. | Must | In progress |
|
||||
| FR-004 | Parse artifact fields only through deterministic matching, validation, and derivation against the canonical package. | Must | In progress |
|
||||
| FR-005 | Run a stable automatic inventory scan: detect grid, click tile, verify detail change, parse, store, continue, scroll, resume. | Must | Prototype |
|
||||
| FR-006 | Save low-confidence, failed, conflicting, or stale scans automatically as review samples with reason codes. | Must | Prototype |
|
||||
| FR-007 | Apply local learned fixes from review corrections before every new parse. | Must | Prototype |
|
||||
| FR-008 | Keep the scan UI operator-friendly: main preview first, debug in modals or drawers, completion summary after scan. | Must | In progress |
|
||||
| FR-001 | List capture sources and automatically prefer the detected Genshin window when available. | Must | Implemented |
|
||||
| FR-002 | Read one currently opened artifact reliably from the local screen and show its parsed result. | Must | Implemented |
|
||||
| FR-003 | Generate and maintain a local canonical Genshin data package for sets, pieces, slots, stats, characters, aliases, and UI profiles. | Must | Implemented baseline |
|
||||
| FR-004 | Parse artifact fields only through deterministic matching, validation, and derivation against the canonical package. | Must | Implemented baseline |
|
||||
| FR-005 | Run a stable automatic inventory scan: detect grid, click tile, verify detail change, parse, store, continue, scroll, resume. | Must | Implemented for visible-inventory baseline |
|
||||
| FR-006 | Save low-confidence, failed, conflicting, or stale scans automatically as review samples with reason codes. | Must | Implemented baseline |
|
||||
| FR-007 | Apply local learned fixes from review corrections before every new parse. | Must | Implemented baseline |
|
||||
| FR-008 | Keep the scan UI operator-friendly: main preview first, debug in modals or drawers, completion summary after scan. | Must | Implemented baseline |
|
||||
| FR-009 | Provide account-level artifact triage after scanner trust is acceptable. | Should | Pending |
|
||||
| FR-010 | Provide 1-3 simple build suggestions per character from owned artifacts after scanner trust is acceptable. | Should | Pending |
|
||||
| FR-011 | Farming overlay for reward scans. | Later | Prototype shell |
|
||||
@@ -136,7 +136,13 @@ The app is not intended to replace deep min-max tools. It prioritizes time savin
|
||||
|
||||
### Current product conclusion
|
||||
|
||||
The app should stop behaving like an OCR demo with extra features around it. The next phase is a scanner product rebuild: canonical data first, scan engine second, learning loop third, recommendations later.
|
||||
The app has crossed from OCR-demo/prototype into a validated scanner baseline on
|
||||
`main`. The current merge-ready path is the visible-inventory scan flow: the
|
||||
operator opens Artifact inventory with a visible detail card, the app verifies
|
||||
the state, scans read-only, persists parsed artifacts, and keeps uncertain data
|
||||
reviewable. The next product phase is not another broad scanner rewrite; it is
|
||||
repeatability, corpus growth, UI polish, and then recommendations on top of the
|
||||
trusted artifact store.
|
||||
|
||||
## Product Direction
|
||||
|
||||
@@ -156,7 +162,9 @@ Outcome:
|
||||
- Scan completion popup summarizes scanned, stored, duplicates, review samples, blocked reason, and elapsed time.
|
||||
|
||||
Status:
|
||||
- In progress
|
||||
- Mostly done for the scanner baseline. The Diagnose/dev surface is separated
|
||||
and scrollable, scan summaries are compact, and the normal Auto-Scan path is
|
||||
guarded. Further UI polish remains useful but no longer blocks scanner merge.
|
||||
|
||||
### Phase 1 - Canonical game data package
|
||||
|
||||
@@ -174,7 +182,9 @@ Outcome:
|
||||
- Parser stops "free guessing" outside the canonical package.
|
||||
|
||||
Status:
|
||||
- In progress
|
||||
- Implemented as a generated lookup package in `src/data/genshinGameData.json`
|
||||
with validation and parser integration. Continue regenerating and expanding
|
||||
aliases deliberately when Genshin data or OCR samples require it.
|
||||
|
||||
### Phase 2 - Deterministic parser hardening
|
||||
|
||||
@@ -192,7 +202,10 @@ Outcome:
|
||||
`Not detected` instead of being stored as invented character names.
|
||||
|
||||
Status:
|
||||
- In progress
|
||||
- Implemented for the merge baseline. Parser tests cover canonical set/slot/stat
|
||||
matching, equipped-character footer noise, known aliases, and unsafe one-letter
|
||||
fragments. Continue growing the confirmed review corpus before tightening
|
||||
thresholds further.
|
||||
|
||||
### Phase 3 - Scanner core rebuild
|
||||
|
||||
@@ -214,7 +227,11 @@ Outcome:
|
||||
marker is visible; preflight and polling captures still skip expensive OCR.
|
||||
|
||||
Status:
|
||||
- In progress
|
||||
- Implemented and merged for the visible-inventory path. Live validation on
|
||||
2026-07-09 covered `20/20` verified/parsed with `0` review and `0` misses,
|
||||
equipped-character persistence, unlocked lock state, positive locked state,
|
||||
and locked persistence. Explicit entry-mode experiments remain separate from
|
||||
the normal merge-ready path.
|
||||
|
||||
### Phase 4 - Input automation replacement
|
||||
|
||||
@@ -230,7 +247,10 @@ Outcome:
|
||||
- Auto-scan never starts on a session that cannot prove one successful detail-card change.
|
||||
|
||||
Status:
|
||||
- First live path validated; broader soak testing still needed
|
||||
- Read-only C# helper path and elevated dev startup are validated for the
|
||||
visible-inventory scanner baseline. Direct inventory, Paimon-menu, and
|
||||
auto-entry modes remain Dev-Control experiments and should be tested with low
|
||||
limits before being promoted.
|
||||
|
||||
### Phase 5 - Learning loop that actually compounds
|
||||
|
||||
@@ -257,20 +277,24 @@ Outcome:
|
||||
- Recommendations explain uncertainty and surface conflicts instead of pretending perfect certainty.
|
||||
|
||||
Status:
|
||||
- Deferred until scanner trust is acceptable
|
||||
- Next major product area after repeatability and corpus work. Do not promote
|
||||
recommendation UX until stored artifact quality is backed by more confirmed
|
||||
review samples and repeat live scan runs.
|
||||
|
||||
## Immediate Next Implementation Order
|
||||
|
||||
1. Finish scan-page cleanup so the main operator view is no longer noisy.
|
||||
2. Tighten the game data generator and parser contract, then backfill regression tests from real bad samples.
|
||||
3. Continue moving auto-scan behavior out of `App.tsx` and into isolated scanner modules.
|
||||
4. Repeat the qualified current-vs-IK-traineddata comparison in a later live
|
||||
session before making stronger speed/default-engine claims.
|
||||
5. Validate equipped-character footer reads and a positive `locked=true` sample
|
||||
from known artifacts; export candidates with `npm run eval:review-candidates`.
|
||||
6. Grow the confirmed OCR corpus from review samples before tightening parser
|
||||
thresholds further.
|
||||
7. Resume recommendation work only when scan accuracy is consistently trustworthy.
|
||||
1. Keep the visible-inventory scanner path as the production baseline and avoid
|
||||
promoting `auto-entry`, `direct-inventory`, or `paimon-menu` until they pass
|
||||
their own low-limit live validations.
|
||||
2. Grow the confirmed OCR corpus from review samples exported by
|
||||
`npm run eval:review-candidates` and prepared through
|
||||
`npm run eval:prepare-confirmed`.
|
||||
3. Repeat live scanner runs in later sessions to prove repeatability across
|
||||
pages, locked/unlocked artifacts, equipped footers, and duplicate handling.
|
||||
4. Continue the optional `3 artifacts/second` work only if the next change can
|
||||
reduce OCR/capture transport time without weakening quality gates.
|
||||
5. Start recommendation/product UX work only after repeat scan quality and
|
||||
confirmed corpus coverage are strong enough to trust stored artifacts.
|
||||
|
||||
## Open Questions
|
||||
|
||||
|
||||
Reference in New Issue
Block a user