Practice the Rollback Before Your First Mobile Voice Pull Request

You join the voice repo on your first morning, and the ticket asks for a remote transcription route before standup. The loaner phone sits on cafe Wi-Fi that drops whenever someone else joins the network. Your reviewer wants the first pull request to roll back without a second binary or a quiet retry. You have one device, one hour, and no license to invent latency or battery figures.

Record the phone before you touch the route

Write the device model, OS build, and framework version at the top of your notes before you edit any file. Note whether the microphone permission is granted, denied, or still not requested on this fresh install. Record the network as Wi-Fi, cellular, or airplane mode, and note whether the screen is awake. Treat every later observation as tied to that snapshot, not as a claim about every phone in the fleet.

Snapshot fields

• Device model and OS build, including the patch level if the settings screen shows it.
• Framework and dependency versions for the audio and network libraries you will call.
• Microphone permission, network type, power source, and whether the app is foregrounded.
• The route flag default, which should stay off until a reviewer accepts the drill.

Keep the first pull request narrow

Your first change should add a route flag, a local disable path, and a rollback note in the pull request body. Do not add a new model file, a new analytics event, or a background upload in the same diff. A narrow diff lets a reviewer see the failure path without guessing which line keeps audio after a crash. If the flag defaults to off, a bad merge does not start sending audio on every install.

Decide the route before you write the client

Use a small decision table in the pull request so the reviewer can see when audio may leave the phone. Remote routing is allowed only when permission is granted, the app is foregrounded, and the network check just succeeded. Any other row must keep the buffer in process memory and show a local failure state. This table is a review aid, not a benchmark, and it does not prove energy use on your phone.

Review table

App state	Microphone	Network	Route	Buffer
Foreground	granted	reachable	remote	send, then drop the local copy
Foreground	granted	unreachable	stop	keep in memory, do not write disk
Background	any	any	stop	discard
Any	revoked or unknown	any	stop	discard and clear the visible text

Read the table from the device outward, and do not skip the background row because the demo only runs in the foreground. A junior often tests the happy path once, then treats the other rows as obvious follow-up work. Those other rows are the rollback, and they belong in this first pull request rather than a later ticket. If a row says discard, your code must not enqueue a retry for that same audio buffer.

Proposed route gate

The next function is a proposed example for the first pull request, and it is not a report from a device lab. It returns stop unless every gate passes, which is the behavior you want before you merge. You can unit test it without a phone, then repeat the same cases on the loaner device. A unit test does not replace the permission revoke check, because the OS can change state while your process sleeps.

type RouteInput = {
  mic: "granted" | "denied" | "unknown";
  scene: "foreground" | "background";
  network: "reachable" | "unreachable";
  flag: "remote" | "off";
};

export function chooseRoute(input: RouteInput): "remote" | "stop" {
  if (input.flag !== "remote") return "stop";
  if (input.mic !== "granted") return "stop";
  if (input.scene !== "foreground") return "stop";
  if (input.network !== "reachable") return "stop";
  return "remote";
}

Keep the function free of logging so a failure does not print the audio path, the endpoint, or the user text. Pass only the four fields above, and do not pass the captured samples into the decision. A later helper can send audio only after this function returns remote, and only for that one attempt. If you add a retry inside that helper, you have left the scope of this first pull request.

Proposed unit test

import { chooseRoute } from "./chooseRoute";

test("network loss stops the remote route", () => {
  expect(
    chooseRoute({
      mic: "granted",
      scene: "foreground",
      network: "unreachable",
      flag: "remote",
    })
  ).toBe("stop");
});

This test locks the unreachable row so a later edit cannot silently send audio when the cafe network drops. Add sibling cases for a denied microphone, a background scene, and a flag that is off. Label the file as a proposed example when your repository names tests or runners differently from this snippet. Do not assert a duration, a token count, or a battery delta anywhere in this file.

Use a dev server only as an optional branch

You may point the remote branch at a development server while you learn the failure path. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The operator describes MonkeyCode as offering free model access and a free server option for this kind of trial.

This article does not name a model, a quota, a region, or a period, because those details were not verified here. Do not hardcode a base URL, a token, or a sample utterance in the repository or in a screenshot. Read the endpoint from a local untracked file, and keep that file out of the first commit. If the free server is unreachable, your flag returns to off and the phone keeps the buffer out of any retry queue.

Local config you do not commit

# local only; do not commit
.dev-server.env

# Proposed untracked file. Replace the host with the server you were actually given.
# DEV_SERVER_BASE_URL=https://your-dev-host.example

Load that file only in a debug build, and fail closed when the variable is missing. A release build should keep the route flag off unless a separate, reviewed config path exists. Do not print the resolved URL in a toast, a log line, or a pull request screenshot. If you cannot explain where the URL came from, leave the remote branch unpushed until you can.

Commands before you open the pull request

# Proposed local checks. They do not measure a device.
git status --short
git diff --stat
rg -n -i "api[_-]?key|bearer |transcript|audio_buffer" --glob '!*.lock'
rg -n "chooseRoute" src
npm test -- --testPathPattern=chooseRoute

Run these checks in your clone so the pull request does not carry a token, a transcript, or an unexplained route change. The search is only a hint, and it does not prove that audio never left the process on a phone. Replace the test command if this repo uses Gradle, Flutter, or another runner you already documented. If a match appears in a fixture, delete that fixture from the pull request instead of explaining it away in a comment.

Practice the rollback before you merge

Proposed sequence

1. Set the route flag to remote, and confirm your notes still name this device, OS build, and network.
2. Start a short capture in the foreground, then enable airplane mode before a response can return.
3. Confirm the UI shows a local failure, and confirm no retry job remains for that capture.
4. Revoke the microphone permission, return to the app, and confirm the route would return stop.
5. Background the app for one minute, restore it, and confirm the previous buffer was discarded.
6. Set the flag to off, reopen the app, and confirm the remote path stays idle on this install.

Treat this sequence as a proposed test, and write what you actually saw beside each step before you request review. Expected behavior is a stopped route, a cleared buffer, and no new upload after the flag returns to off. If the capture reappears after restore, stop the pull request and file that as a failure rather than a follow-up. Do not publish a latency or battery number from this pass, because one cafe session is not a measurement method.

Write the pull request so the rollback is visible

Put the device snapshot and the drill result in the pull request body, above any screenshot you attach. A reviewer should see the flag default and the stop conditions without opening the code diff. If you did not run a step, write not run instead of guessing what the phone would have done. That honesty is the point of the first hour, and it keeps a later rollback from depending on a story.

Device:
OS:
Framework:
Network at start:
Permission at start:
Flag default: off
Drill: network loss, permission revoke, background, flag off
Result: recovered / restarted / disappeared / not run

What the first rollback must not keep

Your rollback is incomplete if a copy of the utterance remains in a log, a crash payload, or a screenshot attached to the ticket. Clear the in-memory buffer when the route returns stop, and avoid writing that buffer to disk for a later retry. Remove partial text from the screen when the app backgrounds, so the recents view does not show it. Ask the reviewer to look for those copies, because a green unit test will not catch a screenshot.

Who should not use this drill

Skip this drill if you need a production capacity plan, a model comparison, or a battery budget for a release review. It also does not fit a team that already has a signed device lab and a required energy harness. A junior on a loaner phone can use it to keep the first pull request reversible and quiet. A platform owner should not treat a single cafe session as evidence that a development server is fast, durable, or always available.

What to send back

If you run the drill, reply with the device, the OS build, the transition you forced, and whether the buffer recovered, restarted, or disappeared. That report helps the next junior compare notes without copying an unverified number into the README. You can try the same flag against the development server you were given, then turn the flag off before you leave the branch. Keep the server optional, and keep the first merged path able to stop on the phone.