Background

The 2026-04-24 fork-vs-upstream audit (against v2026.3.22) queued 116 paths under `apps/android/.../ai/openclaw/...` and `apps/shared/OpenClawKit/...` as "rebrand-below-threshold" — git rename detection at `-M50%` did not match these because the rebrand made content too different. Most have rebranded equivalents already in the fork; some don't.

A 2026-04-26 file-existence sweep using a simple rebrand transform (`ai/openclaw/` → `org/remoteclaw/`, `OpenClaw` → `RemoteClaw`) resolved 52 of 116. The remaining ~64 unresolved paths are mostly Android files where the rebrand involved more than a one-to-one path translation (e.g., `ai/openclaw/app/MainViewModel.kt` may have moved to `org/remoteclaw/android/MainViewModel.kt`, not `org/remoteclaw/app/MainViewModel.kt`).

Scope

For each of the ~64 unresolved upstream paths:

1. Locate the fork equivalent — try multiple rebrand transforms (`ai/openclaw/app` → `org/remoteclaw/{app,android}`), check the basename anywhere under `apps/android/` and `apps/shared/`, fall back to content fingerprinting if path-based lookup fails.
2. Decide per file:
   • Equivalent exists (most expected): the upstream change for this path can be applied to the fork's rebranded path via a small per-file cherry-pick + rebrand transform; record the path mapping.
   • No equivalent (rare): file was either intentionally not ported to fork (mark EXCLUDE) or is genuinely missing (cherry-pick + rebrand).
3. Apply the changes in batches grouped by app surface (android, shared/RemoteClawKit, watchOS, macOS) to keep PRs reviewable.

Source of truth

Original audit-side queue listing for Cat A (116 paths under the "Likely rebrand-below-threshold renames" section) is in the audit repo's `upstream/pending-sync-review/2026-04-24.md`. The 2026-04-26 sweep narrowed it to ~64 unresolved before this issue was filed.

How to verify

• Per-file: `git log -1 --format=%H -- {fork-equivalent-path}` should show the cherry-pick (or trailer `Cherry-picked-from: {upstream-sha}`)
• Bulk: re-run a fresh fork-vs-upstream audit against `v2026.3.22` after this PR; the Cat A bucket should drop to zero or very few residuals (each remaining residual gets explicit EXCLUDE disposition)
• `pnpm -w build` passes (or platform-equivalent for native apps)
• `pnpm -w test` passes (or platform-equivalent)

Acceptance criteria

• Each of the ~64 unresolved Cat A paths has either a cherry-picked upstream change (with rebrand transform) OR an explicit EXCLUDE decision documented in the disposition registry
• No new build / test failures
• CI green
• Bulk verification re-run shows Cat A residual = 0

Out of scope

• Cat B (12 channel test files) — separate issue
• Cat C (126 genuine upstream files) — separate issue
• B11 sync batch (v2026.3.22 → v2026.4.19-beta.2) — to be scheduled AFTER this issue + Cat B + Cat C close

Why now

The fork-governance cycle decided to process the v2026.3.22 backlog before scheduling the next sync batch (B11). This issue is one of three (Cat A / Cat B / Cat C) that together clear the queue.