docs: update scanner roadmap after merge

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
+  auto-scan UI captures. Later direct-GDI live runs validated the batch/quiet
-  needs a fresh elevated live run; the follow-up restart was blocked because the
+  path at limits 20, 45, and 100 with 0 misses in the current environment.
-  admin runtime did not become reachable after shutdown/UAC.
 - 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

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
+This document records the evidence used to merge the scanner branch into
-into `main`. It separates merge-relevant proof from optional follow-up work.
+`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
+Merged into `main` and pushed to `origin/main` on 2026-07-09. The previously
-open `locked: true` proof now passes for both Smart Capture and auto-scan
+open `locked: true` proof passed for both Smart Capture and auto-scan
-persistence.
+persistence before merge. The feature branch was deleted locally and remotely
+after the merge.

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-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 | Prototype |
+| 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 | In progress |
+| 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 | In progress |
+| 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 | Prototype |
+| 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 | Prototype |
+| 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 | Prototype |
+| 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 | In progress |
+| 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.
+1. Keep the visible-inventory scanner path as the production baseline and avoid
-2. Tighten the game data generator and parser contract, then backfill regression tests from real bad samples.
+   promoting `auto-entry`, `direct-inventory`, or `paimon-menu` until they pass
-3. Continue moving auto-scan behavior out of `App.tsx` and into isolated scanner modules.
+   their own low-limit live validations.
-4. Repeat the qualified current-vs-IK-traineddata comparison in a later live
+2. Grow the confirmed OCR corpus from review samples exported by
-   session before making stronger speed/default-engine claims.
+   `npm run eval:review-candidates` and prepared through
-5. Validate equipped-character footer reads and a positive `locked=true` sample
+   `npm run eval:prepare-confirmed`.
-   from known artifacts; export candidates with `npm run eval:review-candidates`.
+3. Repeat live scanner runs in later sessions to prove repeatability across
-6. Grow the confirmed OCR corpus from review samples before tightening parser
+   pages, locked/unlocked artifacts, equipped footers, and duplicate handling.
-   thresholds further.
+4. Continue the optional `3 artifacts/second` work only if the next change can
-7. Resume recommendation work only when scan accuracy is consistently trustworthy.
+   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
 

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.
 

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
+Visible-page limits up to 20, scroll/page-transition limit 45, the final
-100-artifact current-vs-IK-traineddata comparison have passed for the current
+100-artifact current-vs-IK-traineddata comparison, equipped footer live smokes,
-environment. Remaining soak work is repeatability, OCR corpus growth, equipped
+and one positive locked-artifact persistence proof have passed for the current
-footer confirmation repeats, locked artifact repeats, and optional 3 artifacts/second
+environment. Remaining soak work is repeatability, OCR corpus growth, additional
-speed work.
+equipped/locked repeats, and optional 3 artifacts/second speed work.
 
 ## Grow the eval corpus