Einen Bugfix vom Smartphone bis zur Abnahme führen: Der Fall eines Bild-Links

Ein Screenshot war in einem Artikel von Tactic Remote sichtbar, aber der Link zum Öffnen des Originalbildes wurde fälschlicherweise als Seiten-URL umgeschrieben. In einem chinesischen Artikel bedeutete dies das Voranstellen von /zh-CN/ vor eine freigegebene Bildadresse. Das Bild selbst war vorhanden; lediglich sein Link war fehlerhaft.

Dies ist ein idealer Aufgabenumfang, um ihn von einem Smartphone aus zu steuern: ein konkretes Symptom, eine kleine zu prüfende Änderung und ein Ergebnis, das Sie selbst überprüfen können. Es deckt zudem einen häufigen Fehler bei KI-gestützter Arbeit auf: den Status „behoben“ zu akzeptieren, bevor die Aktion überprüft wurde, die ursprünglich fehlschlug.

Der folgende Fall stammt von einer echten Reparatur an dieser Website. Wir haben die tatsächliche URL-Hilfsfunktion (helper) vor und nach dieser Korrektur erneut ausgeführt. Die damaligen Implementierungsarbeiten und Tests wurden auf einem Computer durchgeführt; die nachfolgenden Nachrichten sind Beispiele, die Sie über Tactic Remote senden können, und kein Protokoll einer rein mobilen Fehlerbehebung. Der iPhone-Screenshot ist die reale Bildressource, die bei der Regressionsprüfung verwendet wurde. Codebearbeitung und Tests laufen auf Ihrem verbundenen Entwicklungsrechner und nicht lokal unter iOS.

1. Aktion, erwartetes Ergebnis und Grenzen mitteilen

Die Aufforderung „Repariere die Bilder“ lässt zu viel Interpretationsspielraum. Ein Agent könnte funktionierende Assets ersetzen, den Artikel umschreiben oder das gesamte Sprach-Routing ändern. Eine bessere einleitende Nachricht beschreibt eine einzelne Aktion und was weiterhin funktionieren muss:

Im chinesischen iPhone-Leitfaden wird der Screenshot angezeigt, aber beim Öffnen des Originalbildes wird die falsche Adresse verwendet. Reproduziere zuerst dieses Link-Verhalten. Freigegebene Bilder sollten unter ihrer bestehenden /images/-URL geöffnet werden; Artikel- und Dokumentationslinks müssen weiterhin der ausgewählten Sprache folgen. Identifiziere die kleinste Reparatur sowie eine Regressionsprüfung, bevor Code bearbeitet wird. Lass den Artikeltext und nicht damit zusammenhängende Änderungen unberührt.

Wählen Sie vor dem Senden das Website-Projekt aus und überprüfen Sie Verzeichnis und Branch der Konversation. Wenn der Agent ein anderes Repository nennt, korrigieren Sie dies, bevor Änderungen vorgenommen werden. Die iPhone-Einrichtungsanleitung beschreibt die Verbindungsherstellung; dieser Fall setzt ein, sobald Host und Zielprojekt verfügbar sind.

Die entscheidende Unterscheidung in diesem Bericht lautet: Das Bild wird angezeigt, aber der Link verändert sich. Ein Bildelement lädt sein src-Attribut; ein Klick darauf folgt dem href-Attribut des umschließenden Links. Wer nur die erste Aktion prüft, übersieht die zweite.

2. Ein fehlschlagendes Beispiel vor dem Patch anfordern

Die betroffene Ressource lautete:

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

Die alte Hilfsfunktion behandelte diese Dateiadresse wie die Adresse einer Seite innerhalb derselben Website. Ihre Ausgabe war:

Bei beiden ausgewählten Sprachen sollte die oben stehende ursprüngliche Bildadresse unverändert zurückgegeben werden.

Englisch war ebenfalls betroffen: Die Seitennormalisierung fügte einen abschließenden Schrägstrich hinzu. Eine Bildadresse mit Query-String und Fragment verlor diese Teile ebenfalls. Die freigegebene Datei musste die Seitenlokalisierung vollständig umgehen.

Unsere lokale HTTP-Prüfung ergab 200, image/png für die unveränderte Dateiadresse. Die ungültige Adresse /zh-CN/images/...png lieferte einen Fehler 404. Diese Anfragen wurden an der lokalen Kandidatenversion durchgeführt; sie stellen keine Messung historischer Produktionsausfälle oder betroffener Besucher dar.

Eine nützliche Folgeanweisung vom Smartphone aus lautet:

Zeige die Eingabe-URL, die tatsächliche Ausgabe und die erwartete Ausgabe für einen fehlschlagenden Fall. Schließe einen normalen Dokumentationslink als Kontrollfall ein. Ändere nicht das erwartete Ergebnis, nur um den Test bestehen zu lassen.

3. Den Umfang des Fixes überprüfen

Die Hilfsfunktion in der Produktionsumgebung ließ die Adressen herunterladbarer Beispiele bereits unverändert. Die Reparatur bestand darin, freigegebene Bilder zur selben vorzeitigen Rückgabe (early return) hinzuzufügen:

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

Seitenlinks nutzen weiterhin die bestehende Sprach-Routing-Funktion. Dies ist bewusst an die beiden Verzeichnisse für freigegebene Ressourcen dieser Website gebunden; es handelt sich nicht um eine Regel, nach der jede URL mit einem Punkt die Lokalisierung umgehen sollte.

Bitten Sie den Agenten, die Liste der geänderten Dateien und dieses Diff in der Konversation anzuzeigen, und prüfen Sie dann die tatsächliche Änderung in der Datei-/Änderungsansicht der App. Vergleichen Sie den angezeigten Branch und die Pfade mit dem von Ihnen ausgewählten Projekt. Wenn die Antwort ein umfassendes Neuschreiben des Routings vorschlägt, fragen Sie nach, warum dies für diesen spezifischen Fehler erforderlich ist.

Die damalige Reparatur war im selben Commit enthalten wie die Verbesserungen an Artikeln und Datumsangaben. Der Link-Fix selbst ist die oben genannte kleine Bedingung; der gesamte Commit war keine einzeilige Änderung. Überprüfen Sie bei Ihrer eigenen Aufgabe das gesamte Diff und berücksichtigen Sie bereits vorhandene, nicht zusammenhängende Arbeiten separat, bevor Sie den Patch akzeptieren.

4. Das Testergebnis lesen, nicht nur das Wort „passed“

Für diesen Fall haben wir in jeder der acht Sprachen der Website sechs erwartete Ergebnisse überprüft:

Das ergibt 48 Prüfungen mit folgenden protokollierten Ergebnissen:

Die 16 Fehlschläge entsprechen zwei bildbezogenen Erwartungen über acht Sprachen hinweg. Es handelt sich nicht um 16 defekte Artikel, 16 Benutzer oder 16 getrennte Bugs. Die bestandenen Kontrollfälle sind entscheidend: Ein Patch, der einfach das Lokalisieren jedes Links einstellt, würde das Bildbeispiel reparieren, aber die Navigation in der Dokumentation beschädigen.

Laden Sie die ausführbare Reproduktion herunter, überprüfen Sie sie und führen Sie sie auf Ihrem Entwicklungsrechner aus:

node image-link-regression.mjs

Sie nutzt die integrierten Assertions von Node, läuft im Arbeitsspeicher und führt weder Netzwerkabfragen noch Dateiänderungen durch. Sie enthält das relevante URL-Verhalten vor und nach der Behebung, bereinigt um TypeScript-Typen. Ihr Ergebnis stimmt mit dem separaten Lauf gegen die tatsächlichen Revisionen des Repositories überein. Es handelt sich um eine fokussierte Reproduktion, nicht um einen Ersatz für die Build- oder Integrationstests Ihres Projekts.

Fordern Sie von Ihrem Smartphone aus Nachweise an, die Sie der geprüften Änderung zuordnen können:

Berichte den genauen Befehl, das Verzeichnis, den Branch oder Commit, den Exit-Status und fehlgeschlagene Assertions. Trenne abgeschlossene Prüfungen von solchen, die du lediglich empfiehlst. Wenn du den Patch nach dem Testen bearbeitest, führe die betroffenen Prüfungen auf dieser Version erneut aus.

Bei der ursprünglichen Website-Reparatur wurden das Linting des Repositories, der Produktions-Build und die SEO-Prüfungen ebenfalls erfolgreich bestanden. Diese weiter gefassten Prüfungen decken andere Aspekte ab; keine von ihnen beweist für sich genommen, dass ein Nutzer das Originalbild tatsächlich in einem Browser öffnen kann.

5. Die Benutzeraktion in der lokalen Vorschau wiederholen

Kehren Sie nun zu dem Artikel zurück, der das Problem aufgedeckt hat. Überprüfen Sie, ob das eingebettete Bild weiterhin geladen wird, öffnen Sie das Original, bestätigen Sie, dass es sich um ein Bild und nicht um eine Fehlerseite handelt, und kehren Sie zum Artikel zurück. Prüfen Sie auch einen regulären Dokumentationslink. Wiederholen Sie dies auf Englisch und in einer übersetzten Fassung sowie bei schmaler Smartphone-Bildschirmbreite.

Wenn die Vorschau auf Ihrem Computer läuft, beachten Sie, dass eine auf einem physischen iPhone geöffnete Adresse wie 127.0.0.1 auf das Smartphone selbst verweist. Verwenden Sie den bestehenden Zugangspfad zur Vorschau Ihres Projekts, um sie von einem anderen Gerät aus zu testen. Ein Desktop-Browser, der auf die Breite eines Smartphones eingestellt ist, bietet nützliche Hinweise zum Layout, ist jedoch kein Test auf einem physischen iPhone.

6. Das Ergebnis an einem klaren Haltepunkt abnehmen

In diesem Fall bestand die reparierte lokale Website ihre Prüfungen und wurde im Rahmen der Überprüfung in der lokalen Vorschau abgenommen. Diese Abnahme bezog sich auf die Kandidatenversion der Website; sie bedeutete keine Veröffentlichung der Aktualisierung. Sie belegt auch nicht, dass die historische Aufgabe vollständig von einem iPhone aus gesteuert wurde.

Für eine ähnliche Aufgabe kann Ihre abschließende Anweisung präzise formuliert sein:

Ich habe das Originalbild und den Dokumentationslink in der lokalen Vorschau überprüft. Behalte diesen Patch und seine Regressionsprüfung bei. Fasse die verbleibenden Einschränkungen zusammen und halte dann an, bevor etwas veröffentlicht oder weiter verändert wird.

Wenn Sie die Vorschau nicht geöffnet haben, benennen Sie stattdessen den offenen Zustand: „Die Prüfungen der Hilfsfunktion sind bestanden; die visuelle Abnahme steht noch aus.“ Der Leerlaufzustand eines Agenten, eine grüne Testzusammenfassung und Ihre Abnahme des sichtbaren Ergebnisses beantworten jeweils unterschiedliche Fragen.

Der wiederverwendbare Kern dieses Falls liegt in der Abfolge: die fehlschlagende Aktion beschreiben, einen Kontrollfall beibehalten, die kleinste gerechtfertigte Änderung prüfen, Tests an diese Version binden und die Benutzeraktion wiederholen, bevor über den nächsten Schritt entschieden wird. Sie können diese Entscheidungen vom Smartphone aus treffen, während der Entwicklungsrechner die Code-Arbeit ausführt. Sollte die Konversation unterwegs nicht mehr reagieren, nutzen Sie den Leitfaden zur Fehlerbehebung von Verbindung und Übertragungsstatus, bevor Sie dieselbe Anweisung erneut senden.