Take a bug fix from your phone to acceptance: an image-link case

A screenshot was visible inside a Tactic Remote article, but the link intended to open the original image was being rewritten as a page URL. In a Chinese article, that meant adding /zh-CN/ to a shared image address. The image itself was present; its link was wrong.

This is a useful size of task to direct from a phone: a specific symptom, a small change to inspect, and a result you can check yourself. It also exposes a common mistake in AI-assisted work: accepting “fixed” before checking the action that originally failed.

The case below comes from a real repair to this website. We reran the actual URL helper before and after that repair. The historical implementation and tests ran on a computer; the messages below are examples you can send through Tactic Remote, not a transcript of an all-phone repair. The iPhone screenshot is the real image resource used in the regression check. Code editing and tests run on your connected development computer, not locally on iOS.

1. Report the action, expected result, and boundary

“Fix the images” leaves too many interpretations. An Agent might replace working assets, rewrite the article, or change all language routing. A better opening message describes one action and what must stay working:

In the Chinese iPhone guide, the screenshot displays, but opening its original image uses the wrong address. Reproduce that link behavior first. Shared images should open at their existing /images/ URL; article and documentation links should still follow the selected language. Identify the smallest repair and a regression check before editing. Leave the article text and unrelated changes alone.

Before sending, select the website project and verify the conversation's directory and branch. If the Agent names a different repository, correct that before it edits anything. The iPhone setup guide covers getting connected; this case starts after the host and intended project are available.

The useful distinction in this report is the image displays, but the link changes. An image element loads its src; clicking it follows the enclosing link's href. Checking only the first action misses the second.

2. Ask for a failing example before a patch

The affected resource was:

/images/editorial/mobile-guides/iphone-chat-mode.png

The old helper treated that file address like a local page. Its output was:

Both versions should return the original image address above unchanged.

English was affected too: page normalization added a trailing slash. An image address with a query string and fragment also lost those parts. The shared file needed to bypass page localization altogether.

Our local HTTP check returned 200, image/png for the unchanged file address. The invalid /zh-CN/images/...png address returned 404. Those requests were made against the local candidate; they are not a measurement of historical production failures or affected visitors.

A useful follow-up from the phone is:

Show the input URL, actual output, and expected output for one failing case. Include an ordinary documentation link as a control. Do not change the expected result just to make the test pass.

3. Review the scope of the fix

The production helper already left downloadable examples alone. The repair added shared images to the same early return:

- if (href.startsWith('/examples/')) return href
+ if (href.startsWith('/examples/') || href.startsWith('/images/')) return href

Page links still use the existing language-routing function. This is deliberately tied to this website's two shared asset directories; it is not a rule that every URL containing a dot should bypass localization.

Ask the Agent to show the changed-file list and this diff in the conversation, then inspect the actual change in the app's available file/change view. Compare the displayed branch and paths with the project you selected. If the response proposes a broad routing rewrite, ask why that is necessary for this specific failure.

The historical repair was committed alongside article and date improvements. The link fix itself is the small condition above; the whole commit was not a one-line change. In your own task, review the whole diff and account for unrelated pre-existing work separately before accepting the patch.

4. Read the test result, not just the word “passed”

For this case, we executed six expectations in each of eight website languages:

That is 48 checks, with these recorded results:

The 16 failures are two image-related expectations across eight languages. They are not 16 broken articles, users, or separate bugs. The passing controls matter: a patch that simply stops localizing every link would repair the image example while breaking documentation navigation.

Download the runnable reproduction, inspect it, and run it on your development computer:

node image-link-regression.mjs

It uses Node's built-in assertions, runs in memory, and makes no network requests or file changes. It contains the relevant before/after URL behavior with TypeScript types removed. Its result matches the separate run against the actual repository revisions. It is a focused reproduction, not a substitute for your project's build or integration checks.

From your phone, ask for evidence you can tie to the reviewed change:

Report the exact command, directory, branch or commit, exit status, and failed assertions. Separate completed checks from checks you only recommend. If you edit the patch after testing, rerun the affected checks on that version.

For the original website repair, the repository lint, production build, and SEO checks also passed. Those broader checks cover different things; none of them by itself proves a person can open the original image in a browser.

5. Repeat the user's action in the local preview

Now return to the article that exposed the problem. Check that the inline image still loads, open the original, confirm it is an image rather than an error page, and return to the article. Check an ordinary documentation link as well. Repeat in English and a translated version, then at a narrow phone width.

When the preview is running on your computer, remember that a 127.0.0.1 address opened on a physical iPhone refers to the phone itself. Use your project's existing preview access route to check it from another device. A desktop browser set to a phone width is useful layout evidence, but is not a physical-iPhone test.

6. Accept the result at a specific stopping point

In this case, the repaired local site passed its checks and was accepted in local preview review. That acceptance covered the candidate website; it did not publish the update. Nor does it establish that the historical task was operated entirely from an iPhone.

For a similar task, your final message can be specific:

I have checked the original image and the documentation link in the local preview. Keep this patch and its regression check. Summarize the remaining limitations, then stop before publishing or making further changes.

If you have not opened the preview, say what remains instead: “The helper checks pass; visual acceptance is still pending.” An Agent's idle state, a green test summary, and your acceptance of the visible result answer different questions.

The reusable part of this case is the sequence: describe the failing action, preserve a control case, inspect the smallest justified change, tie checks to that version, and repeat the user's action before deciding the next step. A phone can carry those decisions while the development computer does the code work. If the conversation stops responding along the way, use the connection and delivery-state troubleshooting guide before sending the same instruction again.