docs: update scanner roadmap after merge
This commit is contained in:
AzuTear
@@ -223,9 +223,8 @@ Latest live timing evidence on 2026-07-08:
|
||||
`elapsedMs: 63616` because 50 single-record writes produced
|
||||
`writeFlushMs: 8163`.
|
||||
- Current source replaces that experiment with batch persist and quiet
|
||||
auto-scan UI captures. This is code-validated, but the batch version still
|
||||
needs a fresh elevated live run; the follow-up restart was blocked because the
|
||||
admin runtime did not become reachable after shutdown/UAC.
|
||||
auto-scan UI captures. Later direct-GDI live runs validated the batch/quiet
|
||||
path at limits 20, 45, and 100 with 0 misses in the current environment.
|
||||
- Direct GDI hot-path validation:
|
||||
after skipping `desktopCapturer.getSources()` in auto-scan artifact captures,
|
||||
the 20-artifact iteration baseline improved to `20/20` parsed, `19` stored,
|
||||
@@ -248,6 +247,14 @@ Latest live timing evidence on 2026-07-08:
|
||||
- OCR/parser eval after this speed pass: `npm run eval` passed with `23/23`
|
||||
exact-match cases, `100%` field accuracy, and `100%` critical fields. This is
|
||||
a regression gate, not a substitute for manually checking live artifact values.
|
||||
- Ownership and lock proof on 2026-07-09:
|
||||
`/scanner/start?entry=visible-inventory&limit=20&engine=current` completed
|
||||
`20/20` verified and parsed, `19` stored, `1` duplicate, `0` review, and
|
||||
`0` misses in `8047 ms`. Smart Capture parsed equipped footers for `Citlali`
|
||||
and `Linnea`, reported an unlocked artifact as `locked: false`, then reported
|
||||
a visibly locked artifact as `locked: true` with `lockSignal.ratio:
|
||||
0.14797913950456323` over threshold `0.06`. A follow-up bounded scan
|
||||
persisted that locked artifact with `equipped: "Citlali"` and `locked: true`.
|
||||
- 3 artifacts/second preparation:
|
||||
auto-scan artifact captures now also omit the detail-preview payload and
|
||||
expose `averageCaptureRoundTripMs` plus
|
||||
|
||||
+12
-8
@@ -1,9 +1,12 @@
|
||||
# Merge Readiness
|
||||
# Scanner Merge Evidence
|
||||
|
||||
Current branch: `codex/ik-scanner-progress`
|
||||
Merged branch: `codex/ik-scanner-progress`
|
||||
Target branch: `main`
|
||||
Merge commit: `c025daa`
|
||||
Merged on: 2026-07-09
|
||||
|
||||
This checklist records the evidence needed before merging this scanner branch
|
||||
into `main`. It separates merge-relevant proof from optional follow-up work.
|
||||
This document records the evidence used to merge the scanner branch into
|
||||
`main`. It separates the merge-relevant proof from optional follow-up work.
|
||||
|
||||
## Merge-Relevant Evidence
|
||||
|
||||
@@ -51,8 +54,9 @@ lock-state fix.
|
||||
winner; the assessment self-test is a synthetic validator fixture, not a live
|
||||
winner claim.
|
||||
|
||||
## Merge Recommendation
|
||||
## Merge Result
|
||||
|
||||
Ready for final human diff review and then merge into `main`. The previously
|
||||
open `locked: true` proof now passes for both Smart Capture and auto-scan
|
||||
persistence.
|
||||
Merged into `main` and pushed to `origin/main` on 2026-07-09. The previously
|
||||
open `locked: true` proof passed for both Smart Capture and auto-scan
|
||||
persistence before merge. The feature branch was deleted locally and remotely
|
||||
after the merge.
|
||||
|
||||
+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
|
||||
|
||||
|
||||
@@ -258,6 +258,10 @@ Current live limitation:
|
||||
in the current live environment. 3 artifacts/second is not proven; remaining
|
||||
speed work needs a larger OCR or capture-pipeline change, not more click
|
||||
tuning.
|
||||
- The visible-inventory ownership/lock extension is also live-proven in this
|
||||
environment: equipped footer reads for `Citlali` and `Linnea`, unlocked
|
||||
`locked: false`, positive locked `locked: true`, and locked/equipped
|
||||
persistence all passed on 2026-07-09.
|
||||
|
||||
## Inventory Kamera Comparison
|
||||
|
||||
@@ -359,7 +363,8 @@ Expected bottleneck sequence:
|
||||
than click timing.
|
||||
3. Grow the eval corpus with confirmed real review samples before tightening
|
||||
parser thresholds further.
|
||||
4. Validate a positive locked-artifact sample.
|
||||
4. Repeat equipped/locked live samples in later sessions if confidence or UI
|
||||
behavior changes, but the first positive locked proof has passed.
|
||||
5. Keep recommendations secondary until scanner quality remains stable across
|
||||
repeated live sessions.
|
||||
|
||||
|
||||
@@ -5,12 +5,12 @@ Progress on the approved scanner/OCR rework. See ADR-007/008/009/010 in
|
||||
live automation runbook, see
|
||||
[AUTOMATION_LIVE_SCAN.md](AUTOMATION_LIVE_SCAN.md).
|
||||
|
||||
## Current IK-Speed Target Status
|
||||
## Current Scanner Status
|
||||
|
||||
See [scanner-ik-progress-report.md](scanner-ik-progress-report.md) for the full
|
||||
report.
|
||||
|
||||
Current status:
|
||||
Current status after the 2026-07-09 merge to `main`:
|
||||
|
||||
- The scanner architecture now follows the relevant Inventory Kamera model:
|
||||
32 artifact targets per page, lookup-derived fields, fast artifact OCR profile,
|
||||
@@ -27,6 +27,14 @@ Current status:
|
||||
it parsed `97/100`, had `5` review and `3` misses. The next optional speed
|
||||
target remains `3 artifacts/second`, which means `333 ms/artifact` or faster
|
||||
on clean 20-artifact iterations.
|
||||
- The merge-ready default is the visible-inventory path. The app blocks normal
|
||||
guided Auto-Scan unless Artifact inventory and a visible detail card are
|
||||
detected. `auto-entry`, `direct-inventory`, and `paimon-menu` remain explicit
|
||||
Dev-Control experiments.
|
||||
- Ownership and lock-state proof is no longer theoretical: live captures parsed
|
||||
equipped characters (`Citlali`, `Linnea`), unlocked artifacts reported
|
||||
`locked: false`, a visibly locked artifact reported `locked: true`, and a
|
||||
bounded auto-scan persisted the locked/equipped state.
|
||||
|
||||
## Done (implemented, unit-tested, build green)
|
||||
|
||||
@@ -219,11 +227,11 @@ resolution or without UI work best tested live:
|
||||
in a later live session before making major OCR-engine defaults or speed
|
||||
claims beyond this environment.
|
||||
|
||||
Visible-page limits up to 20, scroll/page-transition limit 45, and the final
|
||||
100-artifact current-vs-IK-traineddata comparison have passed for the current
|
||||
environment. Remaining soak work is repeatability, OCR corpus growth, equipped
|
||||
footer confirmation repeats, locked artifact repeats, and optional 3 artifacts/second
|
||||
speed work.
|
||||
Visible-page limits up to 20, scroll/page-transition limit 45, the final
|
||||
100-artifact current-vs-IK-traineddata comparison, equipped footer live smokes,
|
||||
and one positive locked-artifact persistence proof have passed for the current
|
||||
environment. Remaining soak work is repeatability, OCR corpus growth, additional
|
||||
equipped/locked repeats, and optional 3 artifacts/second speed work.
|
||||
|
||||
## Grow the eval corpus
|
||||
|
||||
|
||||
Reference in New Issue
Block a user