ba-auto-daily/ba_auto/config.py

"""Central configuration for ba-auto-daily, ported from the old ba_dailies.sh."""
import os

DISPLAY = ":0"
XAUTHORITY = "/run/user/1000/gdm/Xauthority"
ENV = {**os.environ, "DISPLAY": DISPLAY, "XAUTHORITY": XAUTHORITY}

WINDOW_NAME = "BlueArchive"
ASSET_DIR = os.path.expanduser("~/ba_assets")

# Runtime working files (probe/detection screenshots); never /tmp, per CLAUDE.md.
SCRATCHPAD_DIR = os.path.join(os.path.dirname(os.path.dirname(os.path.abspath(__file__))), "scratchpad")
os.makedirs(SCRATCHPAD_DIR, exist_ok=True)

# Refined from (1726, 60): that coordinate sat on the edge of the icon's
# hitbox and intermittently missed during live testing.
MAILBOX_ICON = (1732, 50)
CLAIM_ALL = (1691, 1128)

MISSION_ICON = (75, 350)
# Background pixel inside the "一括受取" (claim all) button on the Mission
# panel: bright yellow (r~250, r-b~180+) when something is claimable, flat
# grey (r-b<20) when not. Calibrated live at 1920x1200.
MISSION_CLAIM_PROBE = (1600, 1100)

CAFE_ICON = (165, 1100)
CAFE_ROOM_SWITCH = (190, 160)
CAFE_INCOME = (1780, 1105)
# Max sparkle-detection attempts per room (hits and misses both count --
# sparkles are on a per-student cooldown, so most checks legitimately find
# nothing and the loop keeps polling rather than giving up after one miss).
CAFE_MAX_CLICKS_PER_ROOM = 15
CAFE_SPARKLE_TEMPLATE = os.path.join(ASSET_DIR, "cafe_sparkle.png")
# A pat that crosses an affection-rank threshold shows a full-screen "絆ラン
# クアップ!" (Bond Rank Up!) cutscene with no cafe header visible at all --
# confirmed against screenshots/cafe/student/01-02: navigation.is_on_subscreen's
# header probe reads (183,220,240) there (r<200, fails) vs (248,249,250) on
# the normal cafe screen (r>200, passes), so the existing header-brightness
# check already tells the two apart. Bounds how many Enter presses
# _dismiss_rank_up_if_shown will try before giving up.
CAFE_RANK_UP_DISMISS_RETRIES = 5

# Home -> お仕事 (Work hub) -> 任務 (Task) card -> Normal/Hard story region browser.
WORK_ICON = (1793, 1138)
# Moved up from the original (1370, 450): that point sat close enough to the
# 任務 card's bottom edge that a live Phase 10 run missed and landed on the
# "総力戦" (Total War) card in the row below instead -- confirmed live via
# screenshot, not just a hunch. (1250, 380) sits solidly mid-card, on the
# "任務" title text itself, well clear of every edge.
TASK_CARD = (1250, 380)
REGION_RIGHT_ARROW = (1862, 598)
# Pixel-scanline-scanned (not visually estimated -- see plan.md Phase 8's
# lesson) from scratchpad/stage_info.png: the "<" chevron's navy-blue pixel
# centroid was (66, 597), mirroring REGION_RIGHT_ARROW. Used for the
# OCR-driven to_region port (ba_auto/tasks/story_sweep.py) to step backward
# when the current region is past the target.
REGION_LEFT_ARROW = (66, 598)
# Bounds the "read region, click delta, re-check" loop in
# ba_auto/tasks/story_sweep.py's _go_to_region. A correct read normally
# converges in one round; this just guards against a stuck OCR misread.
REGION_NAV_MAX_ATTEMPTS = 8

# Region-number readout on the region browser's left panel (the "Area 30"
# card's big digits, below the smaller "Area" label). Rect pixel-scanned from
# scratchpad/stage_info.png: the "Area" label occupies roughly y 295-325, the
# number itself y 330-372 -- this rect isolates just the digits. Replaces
# _go_to_latest_region's "spam the arrow and hope" (see plan.md Phase 9's
# retrospective) with task_utils.py::to_region's actual OCR-read-and-click-
# the-exact-delta approach.
REGION_NUMBER_OCR_RECT = (175, 325, 250, 380)

# Stage list panel (right side of the region browser). Scrolling to either
# extreme always shows exactly 4 full stage rows, since every region has at
# least 5 stages -- scrolling past either end is a harmless no-op (verified
# live), so a generous bounded click count is safe. Each stage row's "入場"
# (enter) button sits at STAGE_ENTER_X across both scroll extremes; the two
# row-position sets below were measured at each extreme.
STAGE_LIST_SCROLL_POINT = (1400, 700)
# 10 was the original (Phase 9) calibration, but live re-testing during
# Phase 10 found it insufficient to reach the opposite extreme when the list
# was already scrolled near the other end (it undershot, landing between the
# two calibrated row-position sets and producing garbled OCR reads) -- 20
# reliably reached either extreme regardless of starting position. Scrolling
# past either end remains a harmless no-op (verified live both phases).
STAGE_LIST_SCROLL_CLICKS = 20
STAGE_ENTER_X = 1683
STAGE_ROWS_AT_TOP_Y = (424, 570, 718, 866)
STAGE_ROWS_AT_BOTTOM_Y = (483, 630, 778, 926)

# Stage-label OCR rect (e.g. "30-1", "30-A"), offset from a row's known
# center y above. Pixel-scanned across all eight row positions (both
# STAGE_ROWS_AT_TOP_Y and _BOTTOM_Y) in live captures -- x[1030,1150],
# y[row_y-40, row_y-4] consistently isolates just the label text line above
# the row's star-rating icons. The symmetric row_y+/-40 crop tried first
# during calibration included the stars below and reliably broke OCR (empty
# or garbled reads) even with a character whitelist -- see plan.md Phase 10.
# Replaces _pick_random_stage_row's "scroll to an extreme, grab a random one
# of the 4 rows" with a scoped-down port of the reference's
# swipe_search_target_str: since this client's stage list only ever has 2
# relevant scroll positions (top/bottom extremes, both already known-good),
# full swipe-and-retry generality isn't needed -- just OCR each of the 4
# visible rows at each extreme and match by label text.
STAGE_LABEL_OCR_X = (1030, 1150)
STAGE_LABEL_OCR_Y_PAD = (40, 4)

# 任務情報 (stage info) modal's sweep sub-panel. This modal is wide enough
# that navigation.MODAL_DIM_PROBE (960, 200) lands on the modal's own white
# card instead of the dimmed backdrop -- use a corner point that's outside
# the card in either scroll/region state instead.
STAGE_MODAL_PROBE = (1870, 600)
# Regular numbered stages (30-1..30-5) render an extra "集中指揮"/"簡易攻略"
# tab row and a manual "任務開始" panel below the sweep panel that the
# bonus "-A" stage Phase 9 originally calibrated against does not have --
# discovered live during Phase 10 when Phase 9's coordinates (calibrated
# only against 30-A) missed the MAX button on 30-3 by ~43px vertically.
# These values are pixel-scanned against 30-3's tabbed layout and are what
# config.STORY_SWEEP_TARGETS will hit in the common case (sweeping a
# regular numbered stage, not the "-A" bonus stage). If a target's stage is
# "A", these may be off by the same ~43px the old (untabbed) calibration
# used -- not yet re-confirmed against an actual "-A" stage since this fix;
# see plan.md Phase 10.
SWEEP_MAX_BUTTON = (1620, 550)
SWEEP_START_BUTTON = (1400, 710)
# The "-" stepper button next to the sweep count: flat grey (240,240,239)
# while count is still at its default of 1, vivid orange (255,111,0) once
# MAX (or any +) has raised it. Used to verify the MAX click actually landed
# instead of trusting a single click blindly, since this gates real AP spend.
SWEEP_MINUS_BUTTON_PROBE = (1285, 555)
# The modal's own "X" close icon (top-right corner of the white card).
# Escape does NOT close this modal (confirmed live: two Escape presses left
# it open with focus on the live "任務開始"/start-mission button) -- must
# click this explicitly. Pinned via pixel-scanline scan of the glyph's
# crossing point, not visual estimation.
#
# The whole card (not just the sweep sub-panel) is vertically centered on
# its own content height rather than anchored at a fixed absolute position
# -- confirmed live during Phase 10: the tabbed regular-stage layout (see
# SWEEP_MAX_BUTTON above) is taller than the "-A" bonus-stage layout this
# was originally calibrated against, and its X button sits ~46px higher
# on screen (225 vs the old 271) as a result. This value is re-measured
# against the taller, tabbed layout.
STAGE_MODAL_CLOSE_BUTTON = (1691, 225)
# "+" stepper button, for configured exact (non-"max") sweep counts. Pinned
# via color-scan (bright cyan glyph centroid) against 30-3's tabbed layout
# (see SWEEP_MAX_BUTTON above) -- unlike SWEEP_MAX_BUTTON/
# SWEEP_MINUS_BUTTON_PROBE this specific button has NOT been live-clicked
# yet; confirm it before relying on a non-"max" configured count (see
# plan.md Phase 10).
SWEEP_PLUS_BUTTON = (1520, 550)

# Clicking 掃討開始 (start sweep) always raises an "AP<N>使用して、掃討を
# <M>回行いますか?" usage-confirmation dialog before the sweep actually
# runs -- discovered live during Phase 10; the previous design had no
# handling for this dialog at all, which is what a crude early placeholder
# probe was misreading as "inadequate_ap" on every sweep, successful or not.
#
# If AP is too low for even one sweep (confirmed live by deliberately
# emptying the count via MAX/"+" at low AP), a dialog that looks the same
# and sits at the *same* OK-button position appears instead, but titled
# "AP購入" (real-currency AP purchase) with a gold/yellow OK button instead
# of cyan. The two are told apart by that color, not by position.
SWEEP_CONFIRM_BUTTON = (1150, 810)
SWEEP_CONFIRM_CANCEL_BUTTON = (770, 810)
SWEEP_CONFIRM_CYAN = ((90, 190, 230), (200, 240, 256))
SWEEP_CONFIRM_GOLD = ((200, 200, 50), (256, 256, 150))

# Region spanning every button this task clicks through after 掃討開始: the
# AP-usage-confirm OK above, and the "掃討完了" (sweep complete) results
# screen's "SKIP" (first, skips the reward-reveal animation) and final "OK"
# (after full reward totals appear) buttons. SKIP and the final OK share
# SWEEP_CONFIRM_CYAN's color but sit ~120px apart vertically, so this task
# finds whichever one is showing by color within this region instead of
# hardcoding each dialog's exact Y position.
SWEEP_RESULT_BUTTON_REGION = (700, 700, 1300, 1050)

# (region, stage, count) targets to sweep, mirroring the reference's
# unfinished_normal_tasks shape (module/explore_tasks/sweep_task.py). `stage`
# is 1-5, or the string "A" for the bonus stage that only exists when
# region % 3 == 0. `count` is a positive int (uses the "+" stepper) or the
# literal string "max" (uses the in-game MAX button).
#
# Empty by default -- the earlier placeholder here was (1, 1, "max"), which
# a real run then dutifully swept region 1 stage 1 instead of the account's
# actual last region, since story_sweep has no "find the latest region"
# heuristic anymore (see plan.md Phase 9's retrospective for why that
# heuristic was removed). Add entries here for any additional fixed targets
# you want swept every run, on top of the daily rotation target below.
STORY_SWEEP_TARGETS = []

# Daily-rotating target: sweeps a single region, cycling through its stages
# one per day rather than grinding the same stage every run, per explicit
# user direction. `ROTATION_STAGE_COUNT` is how many stages that region has
# (1..N); which one runs today is `today's date -> N` via a plain date
# ordinal modulo, not the calendar day-of-year, so the cycle doesn't skip or
# repeat around a year boundary. Set STORY_SWEEP_ROTATION_REGION to None to
# disable this and only sweep STORY_SWEEP_TARGETS.
STORY_SWEEP_ROTATION_REGION = 30
STORY_SWEEP_ROTATION_STAGE_COUNT = 6
STORY_SWEEP_ROTATION_COUNT = "max"

# Common Shop / Tactical Challenge Shop. Both tabs share the same underlying
# checkbox-grid-then-bulk-buy UI (the live equivalent of the reference's
# module/shop/shop_utils.py get_item_position/ensure_choose/buy pattern);
# see ba_auto/tasks/shop_utils.py for the shared control flow.
SHOP_ICON = (1155, 1085)  # bottom nav "ショップ" icon on the home screen
SHOP_BACK_BUTTON = (85, 55)
SHOP_TAB_COMMON = (160, 208)  # 通常アイテム tab (credit-point items)
# 戦術対抗戦 tab (tactical-coin items). The reference reaches this via
# goto_shop_by_name's OCR swipe-search over the shop-type tab list
# (module/shop/shop_utils.py) because that list can require scrolling on
# some accounts/versions. Confirmed live here: this account's tab list is
# only 7 entries and all fit on screen with no scroll needed, so a fixed
# click is faithful (there is nothing to search for), not a shortcut around
# the OCR the reference would otherwise need.
SHOP_TAB_TACTICAL = (160, 915)

# Item grid checkbox top-left-ish click point per (row, col), pixel-scanned
# live against the shop's real catalog (see plan.md's shop phase). Confirmed
# identical across both shop tabs -- it's the same shared UI component.
SHOP_ITEM_COL_X = [972, 1197, 1423, 1649]
SHOP_ITEM_ROW_Y = [297, 674]
# The checkbox glyph renders this vivid yellow-green only once checked
# (plain white/grey otherwise) -- pixel-sampled from a live checked vs.
# unchecked capture of the same card.
SHOP_CHECKED_RGB = ((60, 130, 80), (220, 245, 115))
# Each item's price-digit crop, as an (x1, y1, x2, y2) offset added to that
# item's own (col_x, row_y). Pixel-scanned and OCR-tested live against all 8
# configured targets' actual prices (12,500 up to 500,000) -- wide enough
# for the largest configured price without bleeding into the neighboring
# column's card.
SHOP_PRICE_OCR_OFFSET = (48, 166, 145, 195)

SHOP_BUY_BUTTON = (1751, 1112)
SHOP_CANCEL_BUTTON = (1525, 1112)
# A corner point that both the purchase-confirm dialog and the post-purchase
# "報酬獲得!" (reward acquired) banner dim away from pure white as they
# cover the screen -- confirmed live across both, and confirmed to stay pure
# white with no dialog open (across tab switches and scrolling). Cheaper and
# more robust than tracking each dialog's own layout individually.
SHOP_OVERLAY_PROBE = (100, 600)
SHOP_OVERLAY_IDLE_MIN_CHANNEL = 200
# Bounds shop_utils.confirm_purchase's "press Enter until idle" loop.
# Confirmed live: exactly 2 presses clears both the confirm dialog and the
# reward banner in one purchase; this leaves headroom for any additional
# one-time popup (e.g. a first-time notice) without spinning forever if the
# game is ever in a state this project doesn't recognize.
SHOP_PURCHASE_MAX_ENTER_PRESSES = 6

# Top status bar credit-point balance -- present on every screen, not
# shop-specific. Rect excludes the currency icon on the left, which OCR
# otherwise misreads as a spurious leading digit (confirmed live).
CREDIT_BALANCE_OCR_RECT = (1040, 15, 1290, 55)
# The Tactical Challenge Shop's own coin-balance readout, shown inline above
# the item grid on that tab specifically (not in the top status bar).
TACTICAL_COIN_OCR_RECT = (1090, 100, 1290, 150)

# (row, col, item name (log/debug only -- identification is by grid
# position, see shop_utils.py's module docstring for why), expected
# credit-point price). Buy-list confirmed with the user; all 8 are visible
# without scrolling.
COMMON_SHOP_TARGETS = [
    (0, 0, "初級レポート", 12500),
    (0, 1, "中級レポート", 125000),
    (0, 2, "上級レポート", 300000),
    (0, 3, "最上級レポート", 500000),
    (1, 0, "初級強化珠", 10000),
    (1, 1, "中級強化珠", 40000),
    (1, 2, "上級強化珠", 96000),
    (1, 3, "最上級強化珠", 128000),
]

# (row, col, item name, expected tactical-coin price). Buy-list confirmed
# with the user; both visible without scrolling.
TACTICAL_SHOP_TARGETS = [
    (0, 0, "初級栄養ドリンク(AP30)", 15),
    (0, 1, "中級栄養ドリンク(AP60)", 30),
]

# Lesson/Schedule (module/lesson.py). This client renders the reference's
# paged single-region view as a scrollable "Location Select" list of 12
# named regions instead -- these names are the reference's own
# lesson_region_name.JP list (core/config/default_config.py), embedded there
# directly rather than fetched externally, so hardcoding it locally isn't an
# external-data problem the way the shop price table was. They're used only
# for logging here, not for OCR identification -- unlike the reference's
# paged arrows, this list's scroll position is deterministic (see
# REGION_ROW_Y below), so there's nothing to OCR-locate.
LESSON_ICON = (314, 1100)  # bottom nav "スケジュール" icon on the home screen
LESSON_BACK_BUTTON = (85, 55)  # shared by both the region-list and per-region map screens

LESSON_REGION_NAMES = [
    "シャーレオフィス", "シャーレ居住区", "ゲヘナ学園・中央区", "アビドス高等学校",
    "ミレニアム・スタディーエリア", "トリニティ・スクエア", "レッドウインター連邦学園",
    "百鬼夜行中心部", "D.U.シラトリ区", "山海経中央特区", "春葉原", "ワイルドハント総合芸術地区",
]
# The region list only ever settles at two scroll positions -- scrolled fully
# to top (regions 0-5 visible) or fully to bottom (regions 6-11) -- confirmed
# live: 15 scroll-down clicks always lands on the same bottom state, it
# doesn't keep scrolling past it. Each row's card is clickable at this
# center-ish Y regardless of which of the two scroll states is showing.
LESSON_REGION_ROW_Y = [265, 420, 585, 745, 900, 1060]
LESSON_REGION_LIST_SCROLL_POINT = (1400, 700)
LESSON_REGION_LIST_SCROLL_CLICKS = 15
LESSON_REGION_ROW_X = 1400

# Per-region isometric map screen -- opens the "全てのスケジュール" grid
# modal (this client's rendering of the reference's per-region 3x3
# get_lesson_each_region_status/get_lesson_relationship_counts grid).
LESSON_ALL_SCHEDULES_BUTTON = (1770, 1118)
LESSON_GRID_MODAL_CLOSE_BUTTON = (1710, 211)

# Grid modal cell layout: up to 3 columns x 3 rows of location cards, each
# showing up to 3 student portraits with a heart-shaped affection-count
# badge at bottom-right. Pixel-scanned live against two different regions'
# modals (Gehenna Central: 8 cells, Schale Office: 7 cells) -- consistent
# across both. A region with more than 9 currently-unlocked locations would
# need scrolling inside this modal, which isn't implemented (not yet seen
# live on this account; see plan.md).
LESSON_GRID_COL_X = [270, 786, 1302]  # portrait-slot-0 center per column
LESSON_GRID_ROW_HEADER_Y = [380, 608, 836]  # click target to open a cell's info panel
LESSON_GRID_ROW_PORTRAIT_Y = [486, 713, 940]
LESSON_GRID_PORTRAIT_STEP_X = 109  # slot 1/2 center = slot 0 center + N * this
# Badge center sits below-right of each portrait-slot's own center point.
LESSON_GRID_BADGE_OFFSET = (38, 24)
LESSON_GRID_BADGE_OCR_HALF_SIZE = (26, 20)  # crop half-width/half-height around badge center
# A green checkmark can appear at top-right of a portrait ALONGSIDE its
# unchanged heart badge number, not instead of it (confirmed live -- an
# earlier assumption that "done" always blanks the number was wrong) --
# this is the only reliable "already done today" signal, so it's checked
# separately rather than inferred from the badge OCR.
LESSON_GRID_CHECKMARK_OFFSET = (41, -31)
LESSON_GRID_CHECKMARK_RGB = ((130, 190, 60), (220, 255, 160))
LESSON_GRID_CHECKMARK_HALF_SIZE = (14, 13)
# A masked, digit-only OCR read of the heart badge can still occasionally
# fuse a stray leading digit from portrait art bleeding into the crop's left
# edge (confirmed live: "13" -> "413", "18" -> "418", reproducible across
# every psm mode -- see detector.read_int_on_heart_badge). Real affection
# values never reach this range in practice, so treat anything this large
# as contamination and discard it rather than trust it.
LESSON_GRID_BADGE_MAX_PLAUSIBLE = 99

# "保有チケット N/M" readout, top-left of the region-list/map screens.
LESSON_TICKET_OCR_RECT = (295, 133, 385, 172)

# Per-cell info panel ("スケジュール情報"), opened by clicking a grid cell.
# Its Start button and the post-schedule report's OK button (below) are the
# same bright-cyan gradient button at nearly the same position -- confirmed
# by direct pixel sample, sharing one color range.
LESSON_ACTION_BUTTON_RGB = ((90, 195, 235), (150, 240, 255))
LESSON_INFO_START_BUTTON = (960, 890)
LESSON_INFO_CLOSE_BUTTON = (1435, 240)

# After clicking Start, a variable sequence of intermediate screens can
# appear before settling back on the grid modal -- a bond-rank-up full-
# screen cutscene (confirmed live, see screenshots/lesson/ -- its art is
# character-dependent, so no fixed color/position reliably identifies it)
# and/or a "スケジュールレポート" results modal. A transient "run the
# schedule twice" campaign multiplier was also observed live, doubling how
# many of these screens appear in a row -- rather than special-case any of
# this, `lesson.py` presses Enter in a bounded loop and re-checks two fixed
# markers each round:
#
# - the grid modal's own title underline (this exact yellow-gold, confirmed
#   live) is visible ONLY when the grid modal is frontmost and idle -- both
#   the report modal and the cutscene cover it, confirmed live against all
#   three states.
LESSON_GRID_IDLE_PROBE_RECT = (790, 244, 1130, 252)
LESSON_GRID_IDLE_RGB = ((235, 220, 70), (255, 250, 130))
# - the report modal's OK button -- same color as LESSON_ACTION_BUTTON_RGB,
#   its own confirmed fixed position -- clicked directly rather than folded
#   into the blind Enter-press fallback, since we can verify it precisely.
LESSON_REPORT_OK_BUTTON = (960, 895)
LESSON_POST_SCHEDULE_MAX_ENTER_PRESSES = 8

# Arena / Tactical Challenge (module/arena.py). Fights a real ranked PvP
# battle each run -- opt-in only, never in DEFAULT_ORDER (see
# ba_auto/reference_notes/mapping.md's Arena row). Per explicit user decision
# (2026-07-09): v1 fights exactly one battle per invocation, matching the
# reference's own per-call pacing -- it relies on a persistent background
# thread rescheduling itself 55 minutes later for the next ticket, which this
# project's one-shot-per-invocation CLI has no equivalent for.

# Policy knobs, carried over unchanged from the reference's own
# core/config/default_config.py defaults. These have no live-UI dependency,
# so they're safe to set now rather than waiting for calibration.
ARENA_COMPONENT_NUMBER = 1  # which of the 3 visible opponent slots to challenge (1-3)
ARENA_LEVEL_DIFF = 0  # accept an opponent up to this many levels above self (negative = only below)
ARENA_MAX_REFRESH_TIMES = 10  # give up rerolling for an acceptable opponent after this many refreshes
ARENA_STOP_FIGHT_WHEN_RANK1 = False  # if True and current rank OCRs as 1, skip fighting and just collect rewards

# Live-calibrated against nik-gpu on 2026-07-09 (see scratchpad/arena_calib_*
# for the captured screenshots this was pixel-scanned/OCR-tested against).
# This client does NOT expose Tactical Challenge as a bottom-nav icon like
# the reference's main-page nav -- it's a card inside the お仕事 (Work) hub,
# reached the same way story_sweep's 任務 card is (config.WORK_ICON).
ARENA_WORK_HUB_CARD = (1310, 985)  # 戦術対抗戦 card inside the WORK_ICON hub

# "保有チケット N/M" readout, left info panel. OCR-confirmed live (read as
# "5/5" against a real 5/5 balance) -- reference's own get_tickets splits on
# "/" and keeps the first number, ported the same way in arena.py.
ARENA_TICKET_OCR_RECT = (295, 780, 395, 812)
# "N位" rank readout, left info panel, tight-cropped to exclude both the
# rank-icon graphic (its own art was misread as spurious digits when
# included, e.g. "29" -> "207") and the trailing "位" glyph. OCR-confirmed
# live (read 29 against a real rank-29 display). Only needed if
# ARENA_STOP_FIGHT_WHEN_RANK1 is True.
ARENA_RANK_OCR_RECT = (208, 500, 285, 555)

# Time reward (時間報酬, continuous income meter -- reclaimable repeatedly
# as it re-accrues, confirmed live: button went claimable again within
# seconds of a claim once 90/1,000K had re-accumulated) and daily reward
# (デイリー報酬, genuinely once/day -- shows a countdown timer once claimed).
# Click points sit on the button's own label text; probes are offset left
# onto plain background fill, confirmed clean (no text) across every row of
# a live pixel grid-scan in both claimed and claimable states.
ARENA_TIME_REWARD_BUTTON = (525, 641)
ARENA_TIME_REWARD_PROBE = (455, 640)
ARENA_DAILY_REWARD_BUTTON = (525, 758)
ARENA_DAILY_REWARD_PROBE = (455, 757)
# Claimable = vivid gold fill; claimed/not-yet = flat neutral grey -- same
# two-state pattern as the reference's own JP.json rgb_in_range check for
# this exact feature, just recalibrated to this client's resolution/colors.
# Pixel-sampled live across both reward slots and both states.
ARENA_REWARD_CLAIMABLE_RGB = ((235, 205, 45), (255, 240, 95))
ARENA_REWARD_CLAIMED_RGB = ((200, 200, 200), (225, 225, 225))

# Season opponent list (3 rows). Row 1's click point is live-confirmed (it
# opened the opponent-info modal below); rows 2/3 are extrapolated from the
# same ~255px row spacing visible in scratchpad/arena_calib_05_after_close.png
# but not yet individually click-confirmed.
ARENA_OPPONENT_ROW_X = 900
ARENA_OPPONENT_ROW_Y = [400, 655, 910]
# "リスト更新" -- refreshes all 3 shown opponents at once (matches the
# reference's single refresh click for its 3 fixed slots, not a per-slot
# reroll). Not yet click-confirmed.
ARENA_REFRESH_LIST_BUTTON = (1750, 280)

# Opponent-info modal ("対戦相手"). This client merges the reference's two
# separate screens (opponent-info, then a distinct formation-edit/
# "攻撃編成" screen) into ONE modal that shows both the matchup and the
# attack-formation button together.
ARENA_MODAL_CLOSE_BUTTON = (1518, 207)  # live-confirmed: closes with no ticket cost
# navigation.is_modal_open's shared (960, 200) darkness probe does NOT work
# here -- confirmed live it reads INVERTED for this specific screen: the
# arena list's own background art at that point is already dark
# (91, 113, 165), while the opponent-info modal's white card is bright
# (247, 250, 252) there. Same probe point, opposite rule -- use r > 200 to
# mean "modal open", not r < 150.
ARENA_MODAL_PROBE = (960, 200)
ARENA_MODAL_OPEN_MIN_CHANNEL = 200
# "攻撃編成" (Attack Formation) button -- this is the actual fight-commit
# click; the modal shows a live ticket-count preview next to it (e.g.
# "5→4") confirming it's what spends the ticket. Same gold fill family as
# the reward buttons. Click-confirmed live 2026-07-09 (ticket went 5 -> 4,
# landed on the attack-formation/squad screen below).
ARENA_ATTACK_FORMATION_BUTTON = (958, 918)

# Live-tested for real on 2026-07-09 (one real ticket spent, one real ranked
# fight, WIN, rank 29 -> 21): see scratchpad/arena_fight_* for the captured
# screenshots. Confirmed:
#
# - ARENA_ATTACK_FORMATION_BUTTON's click DOES work as the fight-commit step
#   (ticket went 5 -> 4) and lands on a "攻撃編成" squad-formation screen,
#   matching the reference's edit-force screen.
# - "戦闘スキップ" (Battle Skip) was ALREADY ON by default on this account
#   (cyan checkmark confirmed via pixel-grid-scan) -- check_skip_button's
#   reroll-if-off logic still needs porting for accounts/states where it
#   isn't, but no live-confirmed "off" sample exists yet to calibrate that
#   state's color against.
# - The actual fight button is "出撃" (Sortie), bottom-right of the
#   attack-formation screen, also bound to Enter (confirmed via keypress).
ARENA_SORTIE_CONFIRM_KEY = "Return"  # attack-formation screen's 出撃 button responds to Enter

# IMPORTANT, live-discovered timing gotcha: after Sortie, the battle
# auto-resolves (skip is on) and the game queues a "対戦結果" (Battle
# Result) WIN/LOSE modal with a reward -- but it can take longer than a
# couple seconds to actually render. A screenshot taken ~2s after the Sortie
# keypress showed the arena list ALREADY updated (rank, ticket count,
# wait-time cooldown) with NO result modal visible at all -- looking like
# the reference's separate battle-win/battle-lost detection was unnecessary
# here. That was wrong: the WIN modal was still pending and only rendered
# on the NEXT click, confirmed by clicking an opponent row afterward and
# getting the queued WIN screen instead. Do not assume "list looks normal
# again" means the result was already handled.
#
# Two more real bugs were found live trying to precisely detect this
# modal's own confirm button, both on 2026-07-09, using two of the
# session's three real arena tickets:
#
# 1. WIN and LOSE modals are NOT the same height -- WIN shows a reward
#    showcase (credit points) above its confirm button, LOSE doesn't, so
#    LOSE's confirm button sits noticeably higher on screen (~y 710-810 vs
#    WIN's ~y 815-870). A fixed probe point calibrated only against WIN
#    missed LOSE entirely, which also made reward collection silently read
#    "not claimable" right after -- it was actually checking the reward
#    buttons while the still-undetected LOSE modal was covering them, not a
#    real reward-state problem.
# 2. Widening the search into a region spanning both button positions (the
#    same fix story_sweep.py's own two-position SKIP/OK button used) fixed
#    that, but then a live rerun found the region also caught stray
#    cyan-ish pixels from the opponent list's own portrait art -- a false
#    centroid match there was clicked and opened a completely unrelated
#    opponent's "対戦相手" info modal instead of confirming anything. A
#    narrower region (offline-validated against every saved WIN/LOSE/
#    opponent-info/plain-list screenshot before risking the session's last
#    ticket on it) still detected the *same* stuck state on the very next
#    live run -- the false-positive source is fundamentally unpredictable
#    per-refresh portrait art, not something a fixed region can rule out.
#
# Given the opponent-info modal's OWN attack-formation button responds to
# Enter and spends a real ticket, the close call here is real: this project
# already has a documented precedent (see CLAUDE.md's story_sweep writeup)
# for exactly "a mistimed keypress could have started a real battle."
#
# Fixed properly by abandoning per-button color detection entirely.
# ba_auto/tasks/arena.py's _wait_for_result instead presses Enter --
# confirmed to be the universal safe dismiss for both modals and for an
# unrelated "list refresh expired" notice that can also appear -- in a
# bounded blind-retry loop, the same pattern lesson.py's _run_one_schedule
# already uses for its own "variable sequence of post-action screens"
# problem. The one genuine hazard (the opponent-info modal's Enter-bound
# attack-formation button) is guarded by a HARD gate checked before every
# single press: if that specific modal is ever detected (via its own gold
# button at ARENA_ATTACK_FORMATION_BUTTON, a fixed, reliable, non-color-
# region check), the function stops immediately without pressing Enter,
# rather than risk spending a second ticket.
ARENA_RESULT_CONFIRM_KEY = "Return"  # universal safe dismiss for both WIN/LOSE and the list-refresh-expired notice

# Self/opponent level OCR, for choose_enemy's reroll logic -- read directly
# from the list screen (matching the reference's own self_level_region/
# opponent_level_region, both read there before any modal opens), not from
# inside the opponent-info modal. Live-calibrated 2026-07-09: the naive
# tight crop (just the "90" glyphs) OCR'd as None even with a correctly
# time-matched screenshot -- turned out to be a real crop-size problem, not
# a stale-screenshot one this time. Debugged by dumping the exact
# thresholded image tesseract sees (scratchpad/probe_arena_level_ocr*.py):
# the tight crop was legible to the eye but too marginal for tesseract at
# 3x upscale, succeeding on some rows/psm modes and not others. A few extra
# pixels of padding on each side fixed it outright across every row, still
# using the existing 3x OCR_UPSCALE pipeline -- no pipeline change needed,
# just a less tight crop.
ARENA_SELF_LEVEL_OCR_RECT = (288, 342, 335, 383)  # white-on-dark -- use read_int_white_on_dark
ARENA_OPPONENT_LEVEL_OCR_RECTS = [  # dark-on-light -- use plain read_int
    (735, 498, 782, 533),
    (735, 736, 782, 771),
    (735, 973, 782, 1008),
]

# Battle-skip toggle on the attack-formation screen (see
# ARENA_ATTACK_FORMATION_BUTTON above -- this is the screen it lands on).
# Pixel-grid-scanned live against a real ON state (cyan checkmark); no OFF
# sample has been seen yet since it was already on by default this session,
# so ARENA_SKIP_ON_RGB is only confirmed to correctly detect "on", not yet
# confirmed to correctly reject a real "off" state.
ARENA_SKIP_TOGGLE_PROBE = (1670, 1020)
ARENA_SKIP_TOGGLE_CLICK = (1670, 1020)
ARENA_SKIP_ON_RGB = ((60, 205, 235), (140, 255, 255))

# Still entirely unknown / unexercised:
# - the LOSE variant of the result modal
# - ARENA_REFRESH_LIST_BUTTON has not actually been click-confirmed -- this
#   session's one live fight never needed a reroll (the chosen opponent was
#   already an acceptable level), so choose_enemy's refresh path is
#   implemented per the reference but not yet exercised live
# - template images (see detector.find_template) for best-record/
#   season-record or any other screen this client might show between
#   confirming attack formation and the fight resolving, if one ever
#   appears (none did across this one live fight)