iOS 専用から Android 対応へ

Android は iOS ではなく、緑色のコートを着ています

いわゆる「iOS から Android への適応」で最もよくある間違いは、ページのスクリーンショットをピクセルごとにコピーすることです。本当に移行する必要があるのは製品契約です。ユーザーはリモート エンドに漢字を 1 回しか入力できません。レンダラーに障害が発生した場合、SSH は切断できません。バックグラウンドから戻るときに新しいフレームが表示される必要があります。サブスクリプションを回復するには、現在のプランが認識される必要があります。 Padは横に拡大する携帯電話ではありません。

したがって、各機能は、共有セマンティクス、プラットフォーム実装、証拠境界の 3 つの層に変換されます。 iOS は独自のビューポート プリミティブを使用でき、Android は Ghostty ABI 3 を使用できます。ただし、「指を下に押して古い履歴を参照し、クリックしてライブに戻る」という動作は一貫している必要があります。

flowchart LR
  I["iOSにはすでにその機能があります"] --> C{"共有製品契約"}
  C --> A["Android ネイティブ実装"]
  A --> D["プラットフォームの差別化戦略"]
  D --> V["3つのデバイスと実際のサービスの検証"]
  V --> R{"証拠は渡されましたか？"}
  R -- "いいえ" --> F["根本原因を特定し、主張を絞り込む"]
  F --> V
  R -- "はい" --> S["ミニバッチレビューとアトミックサブミット"]
            

クロスプラットフォームとは、「見た目が同じ」ということではなく、「問題が発生した場合でも同じ約束を守る」ということです。

Ghostty を最初に失敗させてから、成功させます

Android Ghostty の最初のルールは、少し直観に反しています。決して楽観的に始めてはなりません。同期定数は常に最初に `ok=false` に設定されます。 xterm から Ghostty に切り替える前に、非同期セルフテストでネイティブ コア、ABI、VT、EGL、シェーダー、テクスチャ アップロード、描画、リードバックがすべて正しいことを証明する必要があります。

これにより、最初のフレームで「最初に暗くしてからそれについて話す」という古典的なモバイルの形而上学が回避されます。ヘルス認証には 2.5 秒の上限もあります。GPU が本当に瞑想に入りたい場合、ユーザーはスピナーを最大 2.5 秒間監視し、その後、Zen のような永久的なブランクの代わりに、動作する xterm を取得できます。

stateDiagram-v2
  [*] --> Pending
  Pending --> Ghostty: health proof succeeds before timeout
  Pending --> Xterm: timeout or proof fails
  Ghostty --> Xterm: runtime GL failure
  Xterm --> StableSession: same transport and ring replay
  Ghostty --> StableSession: native renderer active
  StableSession --> [*]
  note right of Ghostty
    Native VT plus full GL path
  end note
            

ターミナルフィルムは記事の修復を表現したものであり、操作背景のオリジナル画像ではありません。マーカー、結果、境界は実際の機器の証拠からのものです。

「簡単に」組み立てられる硬い骨

入力メソッドの構成、xterm キー シーケンス、タッチ選択、ActionMode コピー、ネイティブ スクロールバック、背景コンポジター、PixelCopy プローブ、CPU スナップショット、パッド キーボード フォーカス モード...各項目は個別には P3 のように見えますが、積み上げられると、「これは端末なのか、それとも点滅する黒い四角形なのか」が判断されます。

ブラウザに権限はあるが、既成のキーがない

Play Console の権限は、ログインした Chrome プロフィールにあります。組み込みの Playwright はクリーンなプロファイルであり、何も表示されません。 CDPはまだオープンされていません。最も簡単な答えは、「ユーザーに手動で行うように依頼する」です。 Goal は別の方法を選択しました。まず、どのブラウザ コンテキストに権限があるかを調べてから、ユーザーの参加を必要な同意に圧縮します。

既製のブリッジがない場合は、一時ディレクトリ (MCP SDK + `chrome-devtools-mcp` + Thin stdio client) にブリッジを生成し、永続的な PTY を使用して `スナップショット → クリック → スナップショット` を連続的に送信します。これは「プラットフォーム機能」としてパッケージ化されておらず、完了後にクリーンアップされます。真に再利用可能な結論は、専用プロファイル、オリジン許可リスト、修正バージョン、およびデフォルトの感度解除です。

sequenceDiagram
  actor U as ユーザー
  participant A as Goal Agent
  participant B as Chrome
  participant G as gcloud
  participant P as Play Publisher API
  participant R as RevenueCat API
  A->>B: ログイン状態とターゲット アカウント コンテキストがすでに存在することが判明しました
  U->>B: リモート デバッグを明示的に許可する
  B-->>A: CDPページコントロールが利用可能
  A->>G: API を有効にして、最小権限の ID セットを 2 つ作成します。
  A->>B: Play Console でアプリの権限をバインドする
  A->>P: カタログを冪等に作成し、内部 AAB をアップロードする
  A->>R: Android アプリと製品のマッピングを作成する
  P-->>A: トラックとアーティファクトのステータス
  R-->>A: 権利と提供ステータス
  A-->>U: ビジネス上の事実と取り消せないリリースの決定のみを要求してください
            

スクリーンショットは黒です。まだ GPU への賛辞を書かないでください。

Android スマートフォンの認証において最も危険な瞬間は、最初のスクリーンショットが非常に説得力があるように見えるときです。システムのスクリーンショットでは、SurfaceView が完全に黒になる場合があります。 Xiaomi スクリーンキャップは 0 バイトである可能性があります。 screenrecord はハードウェア層のない世界のみを記録できます。逆に、リモート tmux がマーカーを認識すると、トランスポートが生きていることが証明されるだけで、ローカル コンポジターがそれを描画したことは証明されません。

したがって、証拠は、一意のマーカー、UI ツリー、PixelCopy、CPU ラスター、PID、dumpsys、logcat、リモート ペインなどの複数のオラクルとして設計されています。彼らは並んで拍手するのではなく、お互いを偽らなければなりません。

flowchart TB
  M["固有のマーカーを挿入する"] --> U["UIツリーとコントロールステータス"]
  M --> X["スクリーンショットまたはピクセルコピー"]
  M --> S["PID · dumpsys · logcat"]
  M --> T["リモート SSH/Mosh/tmux ステータス"]
  U --> C{"複数のオラクルは一貫していますか?"}
  X --> C
  S --> C
  T --> C
  C -- "いいえ" --> A["テスト成果物の分類"]
  A --> N["nonce と oracle を置き換えて再実行します"]
  N --> M
  C -- "はい" --> B["限定された結論を書く"]
            

「完全自動化」の真実：人がいないのではなく、価値のあるところにだけ人が現れる

今回の目標の論理的な期間は 21 時間 54 分 42 秒ですが、マシンの稼働時間はそれより短くなります。これはスリープしないことを主張する謎のプロセスではなく、Git、tmux、ポーリング可能ツール、計画ステータス、レビューハンドオフ、および外部システムステータスに依存してコンテキストを継続的に復元します。

このラウンドにおけるユーザーの実際の参加はほとんどありません。RevenueCat にログインし、アカウント所有者による確認が必要な Chrome/Google デベロッパー コンソールで少数のクリックを完了し、コミット/プッシュなどの取り消しできないアクションに対する明示的な承認を与えます。ログイン ステータスの検出、ほとんどの Play フォームの入力とファクト チェック、gcloud/権限のオープン、API の生成、デバイスの検証、購入/復元のテスト、スクリーンショットの記録、エラーの回復と並べ替えはすべて Goal 自体によってクローズド ループで行われます。

flowchart TB
  O["安定のゴールゴール"] --> P["段階計画と証拠の閾値"]
  P --> G["Git アトミック コミット"]
  P --> T["tmux とポーリング可能なツール"]
  P --> E["デバイスと外部サービスのステータス"]
  P --> R["独立した査読者の評決"]
  G --> C["プロセスまたはブート変更後に続行する"]
  T --> C
  E --> C
  R --> C
  C --> P
            

最終差分では分からない 10 のこと

次のアプリから直接コピーできるものは何ですか?

直感に反する最後の結論

本当に伝えられる AI エンジニアリングの話は、「22 時間連続で動作した」ということではなく、「AI は、いつ自ら動作するのか、いつ証拠を探すのか、いつスクリーンショットが信頼できないことを認めるのか、そしていつ人々にクリックさせるのかを知っていた」ということです。自動化の上限はクリック数ではなく、境界線の感覚によって決まります。

最良のエージェントがすべての決定を下してくれるわけではありません。本当に決定が必要な場合にのみ参加することができます。