On set-top box settings screens, automated tests can’t verify focus handling or remote control key events—whether a button press lands on the right option, or whether focus drifts away after a dialog closes. These details can only be verified on a real device with a physical remote in hand. As a result, the acceptance method for this project relies on a live walkthrough: I sit in front of the TV operating the remote and verbally describing what happens on screen, while Claude catches adb logcat on the other end, matching my spoken observations against the traces in the logs. Only when the logs align does a test item count as passed.

This division of labor rests on an unstated premise: my spoken report is the sole clue Claude relies on to decide what to search for in the logs.

”This Screen” Was Mapped to the Active Context

The walkthrough reached the engineering authorization flow. The screen transition went like this: select “Search Channels” → a password input prompt for engineering authorization pops up (requiring the Master Key) → authorization passes → enter the frequency scanning screen.

At a certain moment, seeing a screen in English, I reported: “This screen is in English.”

I didn’t specify which screen. Claude was currently testing the engineering authorization prompt, so it attached my statement to that context, recording in the test log: Engineering authorization password prompt displays in English under Traditional Chinese mode.

The entire next round of debugging revolved around a single question: Why is the engineering authorization password prompt in English?

The Root Cause: Flawless Analysis of a Non-Existent Bug

Claude began investigating under the explicit premise that the password prompt was displaying in English. Yet the app’s locale was clearly Chinese—the settings list titles and all seven option labels were in Chinese, and the system property was persist.sys.locale = zh-TW. Why would only the password prompt revert to English? Claude listed five hypotheses, systematically tested them, and eliminated each one:

Hypothesis	Result	Evidence
The password prompt string lacks Traditional Chinese translation	Eliminated	values-zh-rTW/strings.xml contains 工程認證密碼 (Engineering Auth Password) and 請輸入工程認證密碼 (Please enter engineering auth password)
Erroneously used an API that locks the system locale	Eliminated	Settings components exclusively use appStringResource; grep found no alternative implementations locking system locale
Resource override by a specific build variant	Eliminated	Only src/main/res exists; no variant-specific resource directories
Password prompt sits in a separate window, missing the locale provider	Eliminated	It is an inline overlay inside the settings page, not an independent window
Traditional Chinese values dropped during packaging	Eliminated	aapt dump --values confirmed the APK contains both default="Authorization" and zh-rTW="工程認證密碼" for engineering_authorization

After eliminating all five hypotheses, Claude reached the following conclusion:

Within the same SettingsScreen composition, same LocalAppResources provider, and same appStringResource helper: appStringResource(R.string.setting_system_status) resolves to Chinese (verified by list) = provider resolves to zh-rTW; appStringResource(R.string.engineering_authorization) (PinAuthDialog title, SettingsScreen.kt:204) resolves to English (on device) = resolves to default. The APK contains Chinese values for both strings under zh-rTW config. Same provider, same Resources, yet one resolves to Chinese and the other to English—this presents an absolute contradiction at the static analysis level, pointing to a subtle Compose-level edge case involving runtime resolution / CompositionLocal / recomposition / configurationContext, requiring runtime logging to conclusively diagnose.

This analysis read as rigorous, professional, and logically sound. It even included a five-step debug session plan to dive into Compose’s CompositionLocal, recomposition, and configurationContext.

Its only flaw was that the premise was wrong. The password prompt was actually in Chinese. Every single one of those five hypothesis eliminations was entirely correct: the password prompt string indeed had a Chinese translation, used the correct API, and wasn’t overridden by build variants. The reasoning contained no flaws; only the starting point was broken—that initial premise of “the password prompt is in English” had never been verified.

A Single Log Line Overthrew the Entire Premise

Instead of diving straight into Compose runtime internals according to the debug plan, Claude did something much cheaper first: it added a temporary probe log to print the actual resolved string value at the exact moment the password prompt opened.

Running it on the device brought finality in a single log line:

PROBE_B site=engAuth provided=true locale=zh_TW engauth=工程認證密碼 sysstatus=系統狀態

provided=true, the resource provider delivered the context; locale=zh_TW, the active locale was Chinese; engauth=工程認證密碼—the password prompt title resolved on the actual device was in Chinese.

The “absolute contradiction” collapsed on the spot. There was no contradiction at all, because the password prompt had never been in English. That conclusion—“an absolute contradiction at the static analysis level pointing to a Compose runtime edge case”—had been answering a non-existent question.

The temporary log was reverted immediately after use, leaving a clean working tree.

Tracing Back: The English Was on the Next Screen

With the false premise demolished, the real issue surfaced: since the password prompt was confirmed to be in Chinese, which screen was I actually referring to when I said “this screen is in English”?

In the screen flow, right after the password prompt passes comes the frequency scanning screen. Inspecting the strings for the scanning screen revealed that among 16 scan_* string keys, all default English values were present, while zh-rTW was completely missing:

scan_dialog_title / scan_btn_close / scan_btn_search
scan_field_frequency / scan_field_mode / scan_field_nid / scan_field_qam / scan_field_symbol_rate
scan_mode_auto / scan_panel_progress / scan_panel_status
scan_status_done / scan_status_failed / scan_status_saving / scan_status_scanning / scan_status_tuning

It was a straightforward missing translation, not a runtime resolution bug. The English screen I saw that day was the frequency scanning screen, not the password prompt.

Solution

The missing 16 zh-rTW translations were added to the scanning screen (ensuring scan_status_scanning correctly retained its format parameter: 掃描中 %1$d%%). Running aapt2 dump confirmed structural parity across English and Traditional Chinese:

() "Scanning %1$d%%"
(zh-rTW) "掃描中 %1$d%%"

Yet adding the missing translations only addressed the symptom. The true root cause was that I had omitted the phrase “which screen” during feedback, and Claude, without asking clarifying questions, filled that gap using “the active screen currently being tested.” Both my omission and its fill were completely natural: humans assume their conversational partner is looking at the same screen, while AI uses the most probable subject (the one currently being tested) to resolve ambiguous references—a gamble that pays off most of the time. This time it lost, and that failure caused an entire round of meticulous debugging to run in empty circles.

This was not a unilateral mistake by either side. I created the ambiguity, and Claude amplified that ambiguity into a bug that looked worthy of serious investigation.

Takeaways

Logs Only Answer What You Ask

Throughout this entire incident, the logs never lied. However, the saying “logs don’t hallucinate” hides something logs cannot do—they will never actively tell you the truth; they only answer the questions you ask.

The most paradoxical moment occurred mid-investigation: when Claude read the password prompt logs, it naturally saw Chinese (because the password prompt was Chinese all along). That Chinese log actually fueled the illusion of an “absolute contradiction”—“the list is in Chinese, the password prompt log shows Chinese, so why is the password prompt in English on the real device? There must be some runtime magic at play.” The log truthfully reported that the password prompt was in Chinese, but the question being asked was “why is the password prompt in English?”, feeding a truthful answer into a false premise.

Only when that probe log directly observed the runtime resolved value at that exact moment—looking at what it actually produced rather than inferring from symptoms—did the log finally puncture the premise itself.

The lesson is not that “logs are reliable.” Logs are indeed reliable—so reliable that they will faithfully cooperate with the wrong questions you ask. In a workflow driven by “human operating, AI cross-referencing logs,” both parties must confirm they are discussing the exact same screen before attempting to match observations against log entries.

An Unrecorded Anecdote

The following account does not exist in any session log or work record—for Claude, once the issue was verified and passed, it was resolved and not worth documenting. It survives only in my memory because I was the one who made the mistake. Recalling it after the fact relies entirely on memory without verbatim support from logs or notes, so details may lack precision. I record it here because it illustrates something about this entire workflow that execution logs fail to capture.

During that exact same walkthrough round, a similar situation occurred in reverse.

The test step unfolded like this: Claude read out the action steps for a specific test item, I operated the remote controller, reported completion after finishing, and Claude went to verify the logs. On one item, I missed a few steps halfway through, realized it mid-way, and went back to redo the missing actions from the top.

I assumed redoing them would leave no trace. But when Claude cross-referenced the logs, it noticed the trace for that item had executed twice, and asked me: Why did it run twice?

Only then did I confess: I just performed it twice.

At the exact moment my memory conflicted with the log, the log was right. I had missed steps and retried, assuming it was seamless, but the log faithfully recorded both attempts. That test item passed only after the logs and actions were reconciled.

The very reason this anecdote never made it into any official record is precisely why it is worth writing down: to Claude, “user performed an extra pass, verified and resolved” was merely transient noise—once explained, it was digested and not worth writing into project notes. Yet to me, it left the deepest impression because it was my error. A human mistake that lives only in human memory—and therefore never appears in AI-generated output—proves in reverse that a real human was genuinely present in this workflow, making mistakes that only humans make. A purely AI-generated article would never contain a story like this, because it would never have been remembered in the first place.