diff --git a/docs/AUTOMATION_LIVE_SCAN.md b/docs/AUTOMATION_LIVE_SCAN.md index a6b9d9d..040b5a9 100644 --- a/docs/AUTOMATION_LIVE_SCAN.md +++ b/docs/AUTOMATION_LIVE_SCAN.md @@ -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 diff --git a/docs/MERGE_READINESS.md b/docs/MERGE_READINESS.md index 01eb6c9..958cc4d 100644 --- a/docs/MERGE_READINESS.md +++ b/docs/MERGE_READINESS.md @@ -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. diff --git a/docs/PROJECT.md b/docs/PROJECT.md index 5b85799..b32e968 100644 --- a/docs/PROJECT.md +++ b/docs/PROJECT.md @@ -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 diff --git a/docs/scanner-ik-progress-report.md b/docs/scanner-ik-progress-report.md index 291e699..9014cba 100644 --- a/docs/scanner-ik-progress-report.md +++ b/docs/scanner-ik-progress-report.md @@ -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. diff --git a/docs/scanner-rework-status.md b/docs/scanner-rework-status.md index 42f70b2..3ce1fd3 100644 --- a/docs/scanner-rework-status.md +++ b/docs/scanner-rework-status.md @@ -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