DEV Community: Roronoa

Before Your First Mobile AI PR, Put a Meter Between the Phone and the Model

Roronoa — Tue, 20 Oct 2026 09:18:59 +0000

The DEV front page this week is full of confident "AI features that actually work" demos, and that is exactly the mood in which a new engineer breaks something. My first week on a mobile AI repo looked productive from the outside: simulator open, record button tapped, replies streaming in. What I never saw was the shared test key quietly shrinking behind each retry, and neither did the person paying for it.

On a server you can watch the bill climb. On a phone the damage is invisible: a screen that spins, an automatic retry you did not write, a backgrounded request that keeps streaming after you walked away. Nobody asks "what did that cost?" during onboarding, because nobody instrumented it. So make the meter your first PR, not your fourth.

Why a junior should own the meter, not the model

Quota exhaustion is the one failure class that does not throw. A crash gives you a stack trace and a teammate who has seen it before; a leaked token budget gives you silence until a demo fails in front of someone important. The person most likely to generate that traffic is the person with the freshest fingers on the record button.

Owning the meter forces you to read the request path end to end before you change it. You learn where the device id comes from, how cancellation propagates, what happens when the OS kills your socket, and which calls are yours versus the SDK's. That is a better first week than shipping a prompt tweak nobody asked for.

It also makes your later PRs reviewable. "This retry adds at most N metered calls per user action" is a sentence a senior can approve or reject. "Should be fine" is not.

The artifact: three small pieces

You need a proxy that logs usage, a client that never retries silently, and a ledger query you can run in one line. Nothing here requires production access, and nothing here needs a cloud budget if you use the free server option.

This is where MonkeyCode fits honestly. It offers free model access with an operator-stated 10 million token allocation, plus a free server option you can use to host the meter instead of asking for a staging VM on day two. I have not independently verified current quotas or terms, so check them yourself before you plan around them; the point is that a sandbox budget for onboarding is exactly what this measurement work needs.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

1. The proxy (Node 20+, run it on the free server)

// meter/server.js
import express from "express";
import fs from "node:fs";

const app = express();
app.use(express.json({ limit: "1mb" }));

const LEDGER = "./ledger.jsonl";
const UPSTREAM = process.env.UPSTREAM_URL;
const UPSTREAM_KEY = process.env.UPSTREAM_KEY;
const DAY_CAP = Number(process.env.DAY_CAP ?? 20000); // estimated tokens, per device

// Deterministic and deliberately pessimistic. It is an estimate, never a receipt.
const estimateTokens = (text = "") => Math.ceil(text.length / 3);

app.post("/v1/chat", async (req, res) => {
  const { deviceId, requestId, messages } = req.body ?? {};
  if (!deviceId || !requestId || !Array.isArray(messages)) {
    return res.status(400).json({ error: "deviceId, requestId, messages required" });
  }

  const promptTokens = messages.reduce((n, m) => n + estimateTokens(m.content), 0);
  const startedAt = Date.now();
  const ac = new AbortController();
  req.on("close", () => ac.abort()); // the phone left: stop paying upstream

  try {
    const upstream = await fetch(UPSTREAM, {
      method: "POST",
      headers: { "content-type": "application/json", authorization: `Bearer ${UPSTREAM_KEY}` },
      body: JSON.stringify({ messages }),
      signal: ac.signal,
    });
    const json = await upstream.json();
    const text = json?.choices?.[0]?.message?.content ?? "";
    fs.appendFileSync(LEDGER, JSON.stringify({
      ts: new Date().toISOString(), deviceId, requestId,
      status: upstream.status, aborted: false, promptTokens,
      completionTokens: estimateTokens(text), ms: Date.now() - startedAt,
    }) + "\n");
    return res.json({ requestId, text });
  } catch (err) {
    fs.appendFileSync(LEDGER, JSON.stringify({
      ts: new Date().toISOString(), deviceId, requestId,
      status: "aborted_or_failed", aborted: ac.signal.aborted,
      promptTokens, completionTokens: 0, ms: Date.now() - startedAt,
      error: String(err?.name ?? err),
    }) + "\n");
    if (!res.headersSent) res.status(499).json({ requestId, error: "client_gone" });
  }
});

app.get("/v1/ledger/today", (_req, res) => {
  const today = new Date().toISOString().slice(0, 10);
  const rows = fs.existsSync(LEDGER)
    ? fs.readFileSync(LEDGER, "utf8").trim().split("\n").filter(Boolean).map(JSON.parse)
    : [];
  const mine = rows.filter((r) => r.ts.startsWith(today));
  const estimatedTokens = mine.reduce((n, r) => n + r.promptTokens + r.completionTokens, 0);
  res.json({ requests: mine.length, estimatedTokens, cap: DAY_CAP });
});

app.listen(process.env.PORT ?? 8080);

2. The client with no silent retry

// app/src/net/meteredChat.ts
type Msg = { role: "user" | "assistant"; content: string };
let seq = 0;

export async function meteredChat(messages: Msg[], deviceId: string) {
  const requestId = `${deviceId}-${Date.now()}-${++seq}`;
  const ac = new AbortController();
  const timer = setTimeout(() => ac.abort(), 15_000); // a ceiling, not a retry budget
  try {
    const res = await fetch(`${process.env.METER_URL}/v1/chat`, {
      method: "POST",
      headers: { "content-type": "application/json" },
      body: JSON.stringify({ deviceId, requestId, messages }),
      signal: ac.signal,
    });
    if (!res.ok) throw new Error(`meter_${res.status}`);
    return (await res.json()) as { requestId: string; text: string };
  } finally {
    clearTimeout(timer);
  }
}

3. The one-line check

curl -s "$METER_URL/v1/ledger/today" | jq .

Run it after every experiment. If requests grows while you are not touching the phone, you have found a background leak on your first week instead of your third month.

The lifecycle test plan you actually run

I have not run this on a physical device for this article, so the results column is yours to fill. Use a dev build that reads METER_URL from config, never a release build.

Condition	Exact step	Expected observation
Airplane mode mid-stream	Toggle airplane mode 2s after send	One ledger row, `aborted_or_failed`, no upstream completion
Background 30s	Press home during stream, wait, return	Stream ends or resumes once; ledger never shows two completions for one `requestId`
Permission revoke	Revoke microphone in Settings, relaunch	No new request until permission restored; no queued replay
Process kill	Swipe the app away mid-request	Server logs `client_gone` once; zero retries on next launch
Low power mode	Enable, repeat the same prompt	Same request count; timing may differ, so record it
Network swap	Wi-Fi to cellular mid-request	Exactly one outcome, never a duplicate `requestId`

Record device, OS build, framework and dependency versions, permission state, network, and power state next to each row. If a row is empty, say it is empty; a missing measurement is data too.

When to use which setup

Situation	Use
Learning the request path, need real model output	Free server proxy plus free model access
Testing cancellation and timeouts only	A local mock that returns slowly on purpose
Measuring battery or thermal cost	On-device path, physical phone, charger state recorded
Anything with real user data	Not this harness; talk to whoever owns the data policy

Limitations and who should skip this

Token counts here are character-based estimates, so they are useful for spotting leaks and useless for billing reconciliation. The proxy holds a single upstream key, so it is a development tool and never a public endpoint; add auth before it touches a shared network. And if your product ships inference fully on-device, a network meter solves a problem you do not have.

Skip this approach if you are already inside a metered platform with per-request accounting, or if your team's policy forbids routing prompts through an additional hop. In those cases, log locally and reconcile later.

If you try the lifecycle table, post the device, OS version, the transition steps, and whether the request recovered, restarted, or silently disappeared. Comparable evidence from one more phone is worth more than another demo that looks great on a simulator.

Make the Inference Upstream a Swap, Not a Rewrite: A Junior's First Week on a Mobile AI Repo

Roronoa — Mon, 19 Oct 2026 07:59:51 +0000

Your first week on a mobile AI repo usually starts with a task that sounds small: point the app at a different inference backend so you can test without touching production credentials. On a mid-range Android phone in a debug build, with the screen off for thirty seconds and Wi-Fi dropping to LTE mid-request, that "small" task is where juniors either learn the repo or quietly break it. The drill below turns that task into a repeatable swap with evidence, and it fits the first hour, first PR, first rollback shape of onboarding rather than a production migration.

Everything here is a proposed walkthrough, not a benchmark report. The numbers in the evidence table are yours to fill from your own device, and the code blocks are starting points you should adapt to your framework's actual versions.

Why the upstream is the right first task

An inference upstream is the seam between your app and every model you will ever call, so it attracts every bad habit at once. Juniors hardcode URLs in screens, paste keys into the bundle, and assume a request either succeeds or throws a clean error. A swap drill exposes all three before you write anything that ships.

It is reversible. One flag flips the upstream back, which means a mistake costs minutes, not a release.
It is measurable. You can timestamp request start, first byte, completion, and UI paint without touching model code.
It is mobile-specific. Backgrounding, network changes, and permission loss all change the outcome, and none of them appear in a desktop test.

Record the environment before you start, because a lifecycle result without versions is folklore. Note the device model, OS build, framework version, and the exact lockfile entries for any HTTP or AI SDK you touch.

Step 1: Define the adapter before you touch the network

Start by writing the interface your screens will call. The rule for the first PR is that no screen imports a vendor SDK directly, and the compiler enforces it.

// src/ai/upstream.ts
export type InferenceRequest = { prompt: string; maxTokens: number };

export type FailureReason = 'timeout' | 'network' | 'server' | 'cancelled';

export type InferenceResult =
  | { ok: true; text: string; upstream: string; elapsedMs: number }
  | { ok: false; reason: FailureReason; upstream: string; elapsedMs: number };

export interface InferenceUpstream {
  readonly name: string;
  infer(req: InferenceRequest, signal: AbortSignal): Promise<InferenceResult>;
}

A discriminated result type is the part juniors skip and later regret, because a thrown error loses the reason at the call site. With ok: false you can route timeout, offline, and server failure to different UI without string matching. Keep upstream in the payload so every log line names the backend that produced it.

The remote adapter with a hard deadline

// src/ai/remoteUpstream.ts
import type { InferenceUpstream, InferenceRequest } from './upstream';

const TIMEOUT_MS = 8000;

export function createRemoteUpstream(baseUrl: string, name: string): InferenceUpstream {
  return {
    name,
    async infer(req, outerSignal) {
      const started = Date.now();
      const controller = new AbortController();
      const timer = setTimeout(() => controller.abort(), TIMEOUT_MS);
      const onAbort = () => controller.abort();
      outerSignal.addEventListener('abort', onAbort);

      try {
        const res = await fetch(`${baseUrl}/v1/infer`, {
          method: 'POST',
          headers: { 'content-type': 'application/json' },
          body: JSON.stringify(req),
          signal: controller.signal,
        });
        const elapsedMs = Date.now() - started;
        if (!res.ok) return { ok: false, reason: 'server', upstream: name, elapsedMs };
        const data = (await res.json()) as { text?: string };
        if (typeof data.text !== 'string') {
          return { ok: false, reason: 'server', upstream: name, elapsedMs };
        }
        return { ok: true, text: data.text, upstream: name, elapsedMs };
      } catch (e) {
        const elapsedMs = Date.now() - started;
        const reason = outerSignal.aborted ? 'cancelled' : controller.signal.aborted ? 'timeout' : 'network';
        return { ok: false, reason, upstream: name, elapsedMs };
      } finally {
        clearTimeout(timer);
        outerSignal.removeEventListener('abort', onAbort);
      }
    },
  };
}

Two details matter more than the code style. First, the timer is cleared in finally, because a leaked timer keeps a wake lock alive and drains battery after the screen is off. Second, Date.now() is not monotonic, so if your runtime exposes a monotonic clock, use it for the deltas and keep wall time only for log correlation.

Step 2: Put the key on a server, not in the bundle

Mobile clients cannot keep a secret, and any build-time variable prefixed for bundler inlining ends up readable in the shipped app. So the app talks to a thin proxy, and the proxy holds the upstream credential.

// config.ts — URLs are fine to inline; secrets are not
const BASE = process.env.EXPO_PUBLIC_AI_BASE_URL ?? 'http://10.0.2.2:8787';
const FLAG = process.env.EXPO_PUBLIC_AI_UPSTREAM ?? 'remote-free';

The free-server option is what makes this drill practical for a new hire, since it gives you a disposable host for that proxy instead of a staging cluster that requires three approvals. MonkeyCode's free model access and free server option are the availability claims the operator supplied for this workflow. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

A minimal proxy sketch, unexecuted here and deliberately boring:

// proxy/server.js — sketch, not production code
import express from 'express';
const app = express();
app.use(express.json());

app.post('/v1/infer', async (req, res) => {
  const { prompt, maxTokens } = req.body ?? {};
  if (typeof prompt !== 'string' || !prompt.length) return res.status(400).json({ error: 'bad_request' });
  try {
    const upstream = await fetch(process.env.MODEL_ENDPOINT, {
      method: 'POST',
      headers: { 'content-type': 'application/json', authorization: `Bearer ${process.env.MODEL_KEY}` },
      body: JSON.stringify({ prompt, max_tokens: Math.min(maxTokens ?? 256, 512) }),
    });
    if (!upstream.ok) return res.status(502).json({ error: 'upstream_failed' });
    const data = await upstream.json();
    return res.json({ text: data.text ?? '' });
  } catch {
    return res.status(504).json({ error: 'upstream_timeout' });
  }
});

app.get('/healthz', (_req, res) => res.json({ ok: true }));
app.listen(process.env.PORT ?? 8787);

Keep the proxy stateless for this exercise, log only timings and status codes, and never log prompts containing real user data. That single rule prevents the most common privacy incident in a first PR.

Step 3: Run the lifecycle matrix, not one happy path

Before you claim the swap works, run each row below on one physical device and write the observed result next to the expectation. Airplane mode and the app switcher are your two most valuable test tools in week one.

#	Transition	Expected observation
1	Cold start, Wi-Fi, tap once	`ok: true`, `upstream` matches flag
2	Background 30s mid-request, return	Request either completes or reports `cancelled`, never both
3	Wi-Fi to LTE during request	One terminal result, `reason` is `network` or success
4	Airplane mode on, tap	`ok: false`, `reason: network`, UI offers retry
5	Proxy stopped, tap	`ok: false`, `reason: server`, no crash
6	Flag flipped to fallback, tap	`upstream` changes, old path never called

Row 2 is the one that catches real bugs, because backgrounding can suspend timers and leave an AbortController that fires long after the user returned. If you see a success and a timeout for the same tap, you have two owners for one request and need to fix that before the PR review.

Capture the timings you can defend

Log four timestamps per request: tap, request dispatch, response received, and first frame after state update. Export the log with device, OS build, framework version, and network generation, then paste the raw numbers into the PR description instead of an average. Averages hide the tail, and the tail is what users on a train feel.

Step 4: Rehearse the swap and the revert

The rollback here is configuration, so practice it in this order and keep the steps in the PR body.

Flip the flag to the fallback upstream and confirm the old backend receives no traffic in its logs.
Restore the flag and confirm the fallback stops being called, with the same install and no reinstall.
Rotate the proxy credential once, to prove the app never depended on an embedded key.
Delete the proxy instance, rebuild, and record the user-visible failure message as your limitation note.

If step 1 cannot be verified from server logs, your evidence is a feeling rather than a measurement. Write that down too.

Limitations and who should skip this

This drill proves your app handles upstream substitution and failure on one device under a few transitions. It does not prove throughput, cost, model quality, or behavior across device classes, and a free shared endpoint is not a benchmark environment. Do not send real transcripts, health data, or anything user-identifying through a proxy you stood up for an exercise, and do not treat this setup as a production path with an availability promise.

Skip this approach if your feature requires a contractual latency or uptime target, if your data cannot leave the device at all, or if your team already has a staging inference service with real credentials. In those cases, the adapter and the lifecycle table still apply, but the disposable upstream does not.

If you are onboarding someone this month, hand them the adapter contract and the six-row matrix instead of a wiki page. If you want a throwaway upstream for that first swap, MonkeyCode's free model access and free server option are enough to stand one up before lunch.

What did your device actually do on row 2? Post the device, OS build, the transition steps, and whether the request recovered, restarted, or silently disappeared, because that comparison is the part no tutorial can give you.

Who Owns the In-Flight Request? A First-PR Harness for Mobile AI Features

Roronoa — Sun, 18 Oct 2026 06:47:14 +0000

It is 09:14 on your first Monday in a mobile AI repo, and you have been handed a file called useInference.ts with three TODOs and no tests.

The feature works on the demo phone in the meeting room: you tap the mic, wait a second, and a transcript appears. Then someone locks the screen mid-request, unlocks it, and the same sentence shows up twice with different wording.

That is not a model problem, and it is not a bug you should fix by tuning a prompt. It is an ownership problem, and you can prove it in the first hour with a stub endpoint that never touches a model at all.

The bug you inherit is not accuracy, it is ownership

On a phone, a request has a lifetime that is shorter than the network's willingness to answer it. The app can be backgrounded, the permission can be revoked, the process can be killed, and the radio can vanish for forty seconds while your fetch keeps a socket open.

If nobody decided who cancels the request and who is allowed to apply the result, the answer will arrive late and be applied anyway. That is how you get duplicate transcripts, stale UI, and a retry queue that quietly uploads audio the user thought was discarded.

Your first PR should make that decision explicit and testable, on a device you can hold, before you evaluate a single word of output quality.

Hour one: get a controllable endpoint, not a device farm

You cannot debug in-flight behavior against a real model endpoint, because you cannot ask it to be slow on demand. You need a stub that returns in exactly 3000 ms, or fails with a 503, or hangs until the client gives up.

I run that stub as a small Node service and deploy it to a throwaway backend so the whole team can hit the same URL from their own phones. MonkeyCode's free server option is a reasonable place to put it during onboarding, and its free model access means a new hire does not need a billing account or a cloud credential before their first commit.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The operator describes the free model access as including a 10M-token allowance, and free-tier terms change, so check the current project page instead of trusting a number in a blog post. Keep the stub stateless and tiny, and keep the real model behind the same route so swapping it later is a one-line change.

The stub contract you actually need

Four routes cover almost every lifecycle bug you will meet in your first month:

POST /echo returns immediately, so you can separate wiring bugs from timing bugs.
POST /slow?ms=8000 sleeps exactly as long as you ask, so you can background the app mid-flight.
POST /fail?code=503 fails deterministically, so you can rehearse the retry policy.
POST /slow?ms=8000&failAt=4000 dies halfway, which is the closest cheap approximation of a dropped cellular connection.

// stub.js - run locally, then deploy to a free server option
import http from 'node:http';

const sleep = (ms) => new Promise((r) => setTimeout(r, ms));
const json = (res, code, body) => {
  res.writeHead(code, { 'content-type': 'application/json' });
  res.end(JSON.stringify(body));
};

http.createServer(async (req, res) => {
  const url = new URL(req.url, 'http://localhost');
  const started = Date.now();
  let clientGone = false;
  req.on('close', () => { clientGone = true; });

  if (req.method === 'OPTIONS') { res.writeHead(204); return res.end(); }

  if (url.pathname === '/echo') {
    return json(res, 200, { servedAt: started, text: 'stub' });
  }

  if (url.pathname === '/slow') {
    const ms = Number(url.searchParams.get('ms') ?? 3000);
    const failAt = url.searchParams.get('failAt');
    if (failAt) {
      await sleep(Number(failAt));
      console.log(`aborted-after=${Date.now() - started} clientGone=${clientGone}`);
      return req.destroy();
    }
    await sleep(ms);
    console.log(`served=${Date.now() - started} clientGone=${clientGone}`);
    return json(res, 200, { servedAt: started, text: 'slow stub' });
  }

  if (url.pathname === '/fail') {
    return json(res, Number(url.searchParams.get('code') ?? 503), { error: 'forced' });
  }

  json(res, 404, { error: 'no route' });
}).listen(process.env.PORT ?? 8787, () => console.log('stub on 8787'));

That clientGone log is the most useful line in the file. If it stays true while your app still renders a result, you have found a duplicate-application bug without a model in the loop.

Decide who owns the request, in code

The rule I ask juniors to implement is short: one owner, one controller, and every new request supersedes the old one. Backgrounding, unmounting, and timeout all abort the same controller, and no callback applies a result it does not own.

// useOwnedRequest.tsx - React Native, AbortController-based
import { useEffect, useRef } from 'react';
import { AppState } from 'react-native';

export function useOwnedRequest() {
  const controllerRef = useRef<AbortController | null>(null);

  useEffect(() => {
    const sub = AppState.addEventListener('change', (next) => {
      if (next !== 'active') {
        controllerRef.current?.abort('backgrounded');
        controllerRef.current = null;
      }
    });
    return () => {
      sub.remove();
      controllerRef.current?.abort('unmounted');
    };
  }, []);

  async function send(url: string, body: unknown, timeoutMs = 8000) {
    controllerRef.current?.abort('superseded');
    const c = new AbortController();
    controllerRef.current = c;
    const timer = setTimeout(() => c.abort('client-timeout'), timeoutMs);
    const t0 = Date.now();

    try {
      const res = await fetch(url, {
        method: 'POST',
        headers: { 'content-type': 'application/json' },
        body: JSON.stringify(body),
        signal: c.signal,
      });
      return { status: res.status, ms: Date.now() - t0 };
    } catch (e) {
      return { aborted: c.signal.aborted, reason: c.signal.reason, ms: Date.now() - t0 };
    } finally {
      clearTimeout(timer);
      if (controllerRef.current === c) controllerRef.current = null;
    }
  }

  return { send };
}

Log reason on every abort. superseded, backgrounded, client-timeout, and unmounted tell completely different stories when you read the device log a week later, and the distinction is what turns a mystery into a regression test.

Run the four-transition matrix on one device

You do not need a lab for the first pass. One phone, the stub, and a log line per transition is enough to catch the bug that shipped last quarter.

Transition	Steps	Pass criteria	What to record
Background mid-flight	Tap mic, press home at ~1s, return at ~10s	No result applied; log shows `backgrounded`; stub logs `clientGone=true`	App state timeline, abort reason
Permission revoked	Grant mic, start capture, revoke in Settings, return	Explicit permission error, no silent retry upload	OS version, permission state before/after
Client timeout	Point at `/slow?ms=8000`, send with 8s timeout	Abort at 8s ±200 ms, UI reaches an error state	Client ms, server served ms
Reconnect replay	Send in airplane mode, restore network, relaunch	Exactly one request, no duplicate render	Network type, duplicate count

Write the environment at the top of the run, because a matrix without versions is a rumor: device model, OS build, framework and library versions, permission state, network type (Wi-Fi, LTE, airplane), and whether the app was cold-started between steps.

What usually leaks first

The reconnect row is where most first PRs fail, because a failed request gets queued and the retry fires after the app already restored optimistic UI. The second leak is the permission row, where the code treats a revoked microphone as a network error and retries forever.

Neither leak is visible in a happy-path demo, and neither will show up in a model evaluation table. They show up as a user hearing their own sentence read back twice.

Rehearse the rollback before you finish the PR

Your first PR should include a way to turn the feature off without a store release, and the stub lets you test that switch for free. Point the client at /fail?code=503, flip the flag, and confirm the fallback path renders in under a second instead of hanging.

If the fallback needs a network call, you have not built a fallback, you have built a second dependency. Keep the disabled state local and boring.

Limitations, and who should skip this

This harness says nothing about model quality, real tail latency, thermal throttling, or battery cost, and it cannot reproduce a genuine cellular handoff between towers. The stub also runs on the server, so clientGone proves the client stopped waiting, not that the OS released the radio.

Skip this approach if you are benchmarking on-device inference throughput, if your data flow is regulated end to end, or if you already have deterministic network-condition tooling in CI. Also re-check the free tier terms yourself before you plan a team onboarding around them.

What I want from your first hour

Run the four rows above on one device, keep the log lines, and note which transition failed first. Then open your PR with the matrix, the versions, and the abort reasons attached, because that turns a vague feature into a reviewable contract.

If you need a throwaway endpoint to point the client at, a free server option plus free model access is a low-friction way to get there, and you can swap in the real model once the ownership rules hold. Post your device, OS build, and the transition that broke, and say whether it recovered, restarted, or silently disappeared.

Your First PR on a Mobile AI Feature Should Be the Failure Path

Roronoa — Sat, 17 Oct 2026 05:51:25 +0000

Your First PR on a Mobile AI Feature Should Be the Failure Path

It is your first Monday in a mobile repo that recently grew an AI feature, and the ticket assigned to you says something like "add a summarize button." The endpoint lives in an environment variable that points at a shared dev backend, and nobody in standup can tell you what the app does when that backend is asleep. This is the most common onboarding gap I see right now: teams ship AI surfaces faster than they document what happens when the network, the server, or the OS says no.

So your first pull request should not be the happy path. It should be the failure path, written as a test matrix you can run on one device in under an hour. Everything below is a proposed drill, not a benchmark report; the timings you collect belong to your device and your build, and you should treat them as evidence only after you write down the environment that produced them.

Why the failure path is the safest first PR

A happy-path PR teaches you where the button is. A failure-path PR teaches you where the app is fragile, and it does so without asking you to understand the whole model integration on day one. You only need three things: the base URL, the request shape, and the state machine that decides what the user sees.

You cannot break production, because the drill runs against a stub you control.
You produce a reusable artifact (the matrix) that every future teammate runs during onboarding.
You force the team to name the retry policy, the timeout, and the offline behavior in review, not after an incident.

Keep the scope narrow. One screen, one request, one place in the code that owns timeout and retry, and one table in the PR description.

Build a stub you can break on purpose

You need an endpoint that misbehaves on command. The following file uses only the Python standard library, so a junior engineer can start it without touching the app's dependency tree.

# stub_model.py — stdlib only, no dependencies
import json, os, time
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer

MODE = os.environ.get("STUB_MODE", "ok")

class Handler(BaseHTTPRequestHandler):
    def do_POST(self):
        length = int(self.headers.get("Content-Length", 0))
        body = self.rfile.read(length)

        if MODE == "slow":
            time.sleep(30)          # longer than the client timeout on purpose
        if MODE == "429":
            self.send_response(429)
            self.send_header("Retry-After", "5")
            self.end_headers()
            return
        if MODE == "500":
            self.send_response(500)
            self.end_headers()
            return
        if MODE == "drop":
            self.close_connection = True   # no response bytes at all
            return

        payload = json.dumps({"text": "stub transcript", "echo_bytes": len(body)}).encode()
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.send_header("Content-Length", str(len(payload)))
        self.end_headers()
        self.wfile.write(payload)

    def log_message(self, *args):
        pass  # keep the console readable during the drill

if __name__ == "__main__":
    ThreadingHTTPServer(("0.0.0.0", 8787), Handler).serve_forever()

Start it, then exercise each mode from your laptop before you touch the phone:

STUB_MODE=ok python3 stub_model.py &
curl -s -X POST localhost:8787/v1/complete -H 'Content-Type: application/json' -d '{"text":"hello"}'
# {"text": "stub transcript", "echo_bytes": 17}

kill %1
STUB_MODE=429 python3 stub_model.py &
curl -i -s -X POST localhost:8787/v1/complete -d '{}' | head -n 3

Point the device at the stub without editing source

Mobile networking details eat more onboarding time than the HTTP code itself. On the Android emulator, localhost is the emulator, so use 10.0.2.2 or forward the port with adb reverse; on the iOS simulator, localhost does reach your Mac. A physical device needs your LAN address, and Android 9 and later block cleartext HTTP unless you add a debug-only network security config.

adb reverse tcp:8787 tcp:8787   # emulator/device now reaches the stub at localhost:8787

Keep every base URL in environment configuration. If a teammate has to edit a Kotlin constant or a TypeScript literal to run the drill, the artifact will rot within a sprint.

One client function that owns timeout and classification

// modelClient.ts — the only place that decides what the user sees
type SendState = "idle" | "sending" | "slow" | "retryable" | "failed" | "done";
const TIMEOUT_MS = 12_000;

export async function sendTranscript(text: string, onState: (s: SendState, detail?: string) => void) {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), TIMEOUT_MS);
  onState("sending");
  try {
    const res = await fetch(`${process.env.MODEL_BASE_URL}/v1/complete`, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ text }),
      signal: controller.signal,
    });
    if (res.status === 429 || res.status >= 500) {
      onState("retryable", `status=${res.status} retry-after=${res.headers.get("retry-after") ?? "-"}`);
      return;
    }
    if (!res.ok) { onState("failed", `status=${res.status}`); return; }
    onState("done");
  } catch {
    onState("retryable", controller.signal.aborted ? "client-timeout" : "network");
  } finally {
    clearTimeout(timer);
  }
}

Note what is deliberately absent: unbounded retries. A 429 with Retry-After should produce one scheduled retry, and a client timeout should be distinguishable from a transport error in your logs. That distinction is the whole point of the drill.

The matrix you actually put in the PR

Run each row twice, once on iOS and once on Android, and fill the last column with what you observed rather than what you hoped.

#	Condition	How to induce it	Expected user-visible state	Pass criteria
1	Endpoint cold or asleep	Start with the stub stopped, tap Send	Spinner, then inline retry banner	No crash, no infinite spinner
2	Slow response	`STUB_MODE=slow`	Spinner, then a "still working" state, cancel available	Cancel closes the socket
3	Rate limited	`STUB_MODE=429`	"Busy, retry in 5s" from `Retry-After`	No tight retry loop
4	Server error	`STUB_MODE=500`	Same retry affordance, error id surfaced	At most one automatic retry
5	Connection dropped mid-response	`STUB_MODE=drop`	Classified as retryable, not as a parse error	No half-parsed payload shown
6	Airplane mode	Toggle from Control Center or Quick Settings	Explicit offline state, request queued with a label	Queue survives force quit
7	Backgrounded mid-request	Home button, then return	Result delivered once or discarded, never duplicated	No double send after resume
8	Process death	`adb shell am kill <pkg>` during the request	Draft text still present after relaunch	Storage key survives restart

Record the device model, OS build, framework and dependency versions, network type, and battery state in the PR description. Without those, the table is an anecdote.

Where free model access and a free server fit

The drill needs two things a new hire usually cannot get on day one: a real model endpoint for the happy path, and somewhere to run a shared stub. The MonkeyCode open-source project currently offers free model access, described by the operator as 10M tokens, plus a free server option, which is enough to wire a device to something real without opening a budget request.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Three uses are honest and small. First, point MODEL_BASE_URL at a free model endpoint so the success path is real rather than mocked. Second, host the stateless stub on the free server option so your onboarding cohort shares one URL instead of five laptops. Third, re-run the matrix whenever the endpoint changes and diff the two log sets.

Limitations matter here. Free tiers are shared capacity, so cold starts and latency spikes are exactly the conditions you are testing, but you cannot attribute their cause from the client alone. Never send real transcripts, audio, or identifiers to a shared endpoint; use synthetic strings. Availability, the model list, and the token allowance are a snapshot that can change, so verify the current terms on the project page before you paste them into onboarding docs. There is no SLA, and nothing production-facing should route through a free endpoint.

You should skip this approach entirely if your data is regulated, if you need fixed latency SLOs, or if data residency is a requirement. Run the stub locally and keep the model endpoint internal in those cases.

What the reviewer should see

A good first PR from this drill is boring to review and expensive to lose. It contains the stub file, the filled matrix with your environment block, one screenshot per failure state, and a short paragraph on what still fails and why you left it out of scope. A reviewer should be able to reproduce any row in about ten minutes.

If you are in your first week, run the matrix once against the stub and once against a free model endpoint, then post both log sets side by side; that diff is the most useful onboarding document your team will read this quarter. When you report back, include your device, OS build, the transition that broke, and whether the app recovered, restarted, or silently dropped the request.

Your First Mobile AI PR: Point Inference at a Dev Backend, Then Cut the Network

Roronoa — Fri, 16 Oct 2026 04:47:14 +0000

A new engineer joined our mobile AI repo on a Tuesday, and by 10:40 she had the transcript feature working on her desk Wi-Fi. At 11:05 she walked into the stairwell, the request never returned, and the UI sat on a spinner for ninety seconds before she force-quit the app. Nobody had told her that the remote inference path was the part of the system most likely to fail first, and nobody had given her a backend she was allowed to break.

That is the onboarding gap this post closes. Everything below is a test plan plus code you can run yourself, not a benchmark report: the measurement columns stay empty until you fill them in on your own device, OS, and framework versions.

Why the remote path is the wrong first debugging target

When a feature calls a hosted model, the first hour of debugging usually happens against production credentials and production latency. That is a bad classroom, because you cannot make the endpoint fail on purpose, and every retry costs somebody money or quota.

Worse, the failure modes you need to see are not the ones a laptop reproduces. Airplane mode, Doze, a revoked microphone permission, and a backgrounded app all change what the client does before the network is even involved.

So the first task for a junior engineer should be split in two: get a dev inference endpoint that is disposable, then deliberately break the network around it.

Step 1: Give the new engineer one dev endpoint they cannot break

The practical blocker on day one is procurement: an API key, a spending limit, and a staging slot can take longer than the PR itself. For this repo we route the dev build at MonkeyCode's free model access and free server option, which the operator describes as including a token allowance (currently stated as 10 million tokens) plus a hosted server, so a new engineer gets a working endpoint without a purchase order. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Free-tier terms and allowances change, so verify the current numbers on the project's own page before you write them into a README.

Two rules keep this honest and useful:

The dev endpoint is a development backend, never a production dependency; no release build may point at it.
Only synthetic or published sample audio goes to it. A free endpoint is the wrong place for real user recordings, even during onboarding.

The goal is not to compare providers. The goal is to let a new engineer send one hundred deliberately broken requests before lunch without asking anyone for permission.

Step 2: Pin the endpoint in exactly one place

Most onboarding failures I have seen are configuration failures, not model failures. If the base URL appears in three files, the junior will edit the wrong two.

// lib/inference_config.dart
class InferenceConfig {
  // Inject at build time so no credential or URL lives in source control.
  static const baseUrl = String.fromEnvironment(
    'INFERENCE_BASE_URL',
    defaultValue: 'http://10.0.2.2:8787', // emulator loopback to your laptop proxy
  );

  static const requestTimeout = Duration(seconds: 6);
}

Run the app with the endpoint injected, and keep the default pointing at your laptop so the first build already talks to the fault proxy below:

flutter run --dart-define=INFERENCE_BASE_URL=http://10.0.2.2:8787

Note that 10.0.2.2 is the Android emulator's alias for the host machine. On a physical device you need the laptop's LAN address instead, and the phone and laptop must be on the same network.

Step 3: The artifact — a small fault proxy you run on your laptop

This Node script (Node 18 or newer, because it uses global fetch) sits between the app and the real dev endpoint. It can pass traffic through, inject a 500, add latency, or never answer at all so you can exercise the client timeout.

// tools/fault-proxy.mjs
// MODE=ok|500|delay|hang UPSTREAM=https://your-dev-endpoint node tools/fault-proxy.mjs
import http from 'node:http';

const UPSTREAM = process.env.UPSTREAM;
const MODE = process.env.MODE ?? 'ok';
const DELAY_MS = Number(process.env.DELAY_MS ?? 8000);
const PORT = Number(process.env.PORT ?? 8787);

if (!UPSTREAM) {
  console.error('UPSTREAM is required');
  process.exit(1);
}

http
  .createServer(async (req, res) => {
    if (MODE === 'hang') return; // never respond: exercise the client timeout
    if (MODE === '500') {
      res.writeHead(500, { 'content-type': 'application/json' });
      return res.end('{"error":"injected_failure"}');
    }
    if (MODE === 'delay') await new Promise((r) => setTimeout(r, DELAY_MS));

    const chunks = [];
    for await (const chunk of req) chunks.push(chunk);

    const upstream = await fetch(UPSTREAM + req.url, {
      method: req.method,
      headers: { ...req.headers, host: new URL(UPSTREAM).host },
      body: req.method === 'GET' ? undefined : Buffer.concat(chunks),
    });

    res.writeHead(upstream.status, Object.fromEntries(upstream.headers));
    res.end(Buffer.from(await upstream.arrayBuffer()));
  })
  .listen(PORT, () => console.log(`fault-proxy MODE=${MODE} on :${PORT}`));

Start it in one terminal, run the app in another, and switch MODE between sessions. If the app does something different for hang than for 500, you have already found the first review comment.

Step 4: The device matrix, with your numbers instead of mine

Fill this in for your own hardware; do not copy a row you have not run. Keep the evidence column literal, because "looked fine" is not a result.

State	How to enter it	Expected client behavior	Evidence to record
Airplane mode	`adb shell cmd connectivity airplane-mode enable`	Fallback to the on-device path or a clear offline state	outcome, elapsed ms
Injected timeout	proxy `MODE=hang`	Timeout at the configured deadline, then fallback	timeout value, fallback flag
Injected 500	proxy `MODE=500`	No infinite retry, no crash, user-visible state	retry count, error code
Background 30s	Home gesture, wait, return	No orphaned request, state restored	result after resume
Mic revoked	`adb shell pm revoke <pkg> android.permission.RECORD_AUDIO`	Feature degrades without a silent no-op	permission state in log
Doze	`adb shell dumpsys deviceidle force-idle`	Work is deferred or explicitly queued	queued vs dropped

On iOS, the simulator will not fake airplane mode reliably, so run the network rows on a physical device and use Network Link Conditioner for the latency rows. Record the device, OS build, framework version, and permission state next to every row, because a result without those fields cannot be reproduced next sprint.

Step 5: The fallback decision table your PR has to satisfy

Before the junior writes feature code, agree on what each outcome means. A short table in the PR description prevents a long argument in review.

Success: remote transcript returned within the deadline; store it, do not re-upload.
Timeout: fall back to on-device inference once, log outcome=timeout, and surface the source of the transcript.
HTTP 4xx: do not retry; this is a request problem and retrying hides a client bug.
HTTP 5xx: retry once with jitter, then queue or fall back, and never loop.
Permission revoked: block the action with a clear message; do not silently return an empty transcript.

The client side that implements the timeout row is small and reviewable:

Future<Transcript> transcribe(File audio) async {
  try {
    return await remote.transcribe(audio, timeout: InferenceConfig.requestTimeout);
  } on TimeoutException {
    log('infer_fallback', {
      'reason': 'timeout',
      'endpoint': InferenceConfig.baseUrl,
      'elapsed_ms': stopwatch.elapsedMilliseconds,
    });
    return local.transcribe(audio); // on-device path
  }
}

Step 6: Log fields that make the review reviewable

A fallback that works but cannot be observed is not finished. Ask for these fields in the first PR, and reject logs that contain the transcript text itself.

request_id — correlates client and endpoint without shipping audio.
endpoint — which base URL answered, without credentials.
mode — pass-through, injected failure, or delay.
elapsed_ms — from send to final outcome.
outcome — success, timeout, error, or fallback_local.
permission_state and foreground_state — the two fields most often missing.

Limitations and who should not do this

This workflow assumes one developer, one device, and a disposable dev endpoint. It does not prove anything about production traffic, and it will not catch model-quality regressions, because a free dev endpoint and your production model may not be the same thing.

Skip this approach if your app handles regulated audio or health data, since even synthetic-looking payloads on a free backend can violate your own policy. Skip it as a staging replacement too; a free server is not an availability guarantee, and routing release builds through it is how a demo becomes an incident. If you need deterministic outputs for regression tests, record fixtures once and replay them offline instead.

Who it does suit is the engineer on day one: someone who needs a real request, a real device, and permission to break both. If that is your onboarding problem, MonkeyCode's free models and free server are one way to get an endpoint in the first hour instead of the first week, and you can verify the current offer yourself before pointing a build at it.

What I want back from you is comparable evidence, not agreement. Tell me your device, OS build, framework version, the lifecycle transition you forced, and whether the feature recovered, restarted, or silently disappeared.

Your First Hour in a Mobile AI Repo: Audit the Environment, Then Ship a Boring First PR

Roronoa — Thu, 15 Oct 2026 11:08:54 +0000

Monday, 9:40 a.m. A new engineer has a mid-range Android phone plugged into a laptop and a repo that builds an on-device transcription feature. Their first ticket says "add a retry to the transcript upload path," and it looks like a two-hour job. The app builds, the simulator opens, and then the demo screen throws a network error, because the endpoint in the local config points to a colleague's laptop that is asleep in another timezone.

That is not a code problem, and it is not a knowledge problem. It is an environment problem wearing a feature ticket as a disguise, and it will eat the first day of a junior engineer every single time. Before you write a retry loop, you need three claims you can prove on your own machine. Everything else in this article is scaffolding around those three claims.

Start With Three Claims, Not a Feature

A clean clone builds and runs on this machine, with the toolchain versions written down.
The model call path completes against a documented endpoint, in a documented network state, with a recorded response shape.
Reverting your change returns the repo to a state where the contract test passes again.

Notice that none of these claims is "the feature works well." Quality comes later; reproducibility comes first, because a junior engineer cannot debug a system they cannot reproduce. If you can prove those three claims by lunch, your first pull request is already more valuable than a clever one.

First Hour: Record the Environment Before You Change Anything

Write the audit script before you write the feature. The point is not monitoring; the point is a fingerprint you can diff later when a test suddenly behaves differently. Here is the version I hand to new joiners, trimmed to the fields that have actually mattered:

#!/usr/bin/env bash
# scripts/first-hour-audit.sh
# Run BEFORE your first commit. Writes onboarding-evidence.json.
set -euo pipefail

OUT="${1:-onboarding-evidence.json}"
ENDPOINT="${MODEL_ENDPOINT:-http://127.0.0.1:8080/v1/models}"
SAMPLES="${SAMPLES:-5}"

git_sha="$(git rev-parse HEAD 2>/dev/null || echo unknown)"
node_v="$(node -v 2>/dev/null || echo absent)"
flutter_v="$(flutter --version 2>/dev/null | head -n 1 || echo absent)"
host_os="$(uname -srm)"

android_api="absent"
if command -v adb >/dev/null 2>&1; then
  android_api="$(adb shell getprop ro.build.version.release 2>/dev/null | tr -d '\r' || echo absent)"
fi

booted_sims="absent"
if command -v xcrun >/dev/null 2>&1; then
  booted_sims="$(xcrun simctl list devices booted 2>/dev/null | grep -c Booted || true)"
fi

tmp="$(mktemp)"
for _ in $(seq 1 "$SAMPLES"); do
  t="$(curl -s -o /dev/null -w '%{time_total}' --max-time 10 "$ENDPOINT" || echo -1)"
  echo "$t" >> "$tmp"
done
latencies="$(jq -R -s 'split("\n") | map(select(length > 0) | tonumber)' < "$tmp")"
rm -f "$tmp"

jq -n \
  --arg sha "$git_sha" \
  --arg node "$node_v" \
  --arg flutter "$flutter_v" \
  --arg host "$host_os" \
  --arg android "$android_api" \
  --arg ios "$booted_sims" \
  --arg endpoint "$ENDPOINT" \
  --argjson latency "$latencies" \
  '{git_sha:$sha, host_os:$host, node:$node, flutter:$flutter,
    android_api:$android, booted_simulators:$ios,
    endpoint:$endpoint, endpoint_latency_seconds:$latency}' > "$OUT"

echo "wrote $OUT"

Run it once, commit the output on a throwaway branch, and read it out loud in standup. The following record is illustrative of the shape only, not a benchmark of any device or service:

{
  "git_sha": "…",
  "host_os": "Darwin arm64",
  "node": "v22.x",
  "flutter": "absent",
  "android_api": "14",
  "booted_simulators": "0",
  "endpoint": "…/v1/models",
  "endpoint_latency_seconds": [0.04, 0.11, 0.05, 0.03, 4.80]
}

That last array is the useful part. Four requests in tens of milliseconds plus one five-second outlier tells you more about your network than any dashboard will, and it explains the "flaky test" you were about to blame on your own code. Do not treat those seconds as a service measurement; treat them as a fingerprint of your desk.

First PR: Assert the Contract, Never the Prose

A model endpoint returns text, and text changes. Assertions on text create a suite that fails for reasons unrelated to your change, which teaches a junior engineer to ignore red builds. Assert the envelope instead: status, shape, type, and a budget you control.

// tests/contract/model-contract.test.ts
// Node 20+: node --test tests/contract/model-contract.test.ts
import assert from "node:assert/strict";
import test from "node:test";

const ENDPOINT =
  process.env.MODEL_ENDPOINT ?? "http://127.0.0.1:8080/v1/chat/completions";

type Envelope = {
  choices?: Array<{ message?: { content?: unknown } }>;
  usage?: { total_tokens?: unknown };
};

test("transcript retry contract holds", async () => {
  const res = await fetch(ENDPOINT, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({
      messages: [{ role: "user", content: "Return the word: ok" }],
    }),
  });

  assert.equal(res.status, 200, `unexpected status ${res.status}`);

  const body = (await res.json()) as Envelope;
  const content = body.choices?.[0]?.message?.content;

  assert.equal(typeof content, "string", "content must be a string");
  assert.ok((content as string).length > 0, "content must be non-empty");

  // Do NOT assert the exact words. Assert the spending envelope instead.
  if (body.usage !== undefined) {
    assert.equal(typeof body.usage.total_tokens, "number");
  }
});

Assert this	Never assert this	Because
HTTP status and error codes	Wall-clock latency in CI	Latency measures your network, not the interface
Response field types	Exact generated wording	Wording is model behavior, not a contract
Non-empty content	A fixed character length	Length varies across providers and versions
Token usage, when documented	Token usage, when undocumented	Undocumented fields vanish without warning
Error shape for 4xx and 5xx	A specific error message string	Messages get reworded between releases

Where a Free Hosted Endpoint Fits on Day One

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The practical blocker for a new engineer is rarely the model; it is having an endpoint that answers at 9:40 a.m. on a company laptop. MonkeyCode is an open-source project that advertises free model access and a free server option, and the operator states the current free allowance as 10 million tokens. I have not independently verified that figure or the server's limits, so read the project's own current documentation instead of planning capacity from this paragraph.

What a free endpoint genuinely buys you is the ability to finish claims one and two above without waiting on procurement. It also lets you write the contract test against a real HTTP response rather than a mock you invented, which is the difference between testing your code and testing your imagination. What it cannot buy you is any measurement about your device, because it sits behind a network hop you do not control.

Day-one task	Free hosted endpoint	Why
Contract and schema tests	Yes	Needs a real envelope, not real hardware
Prompt regression fixtures	Yes, with cached responses	Keeps CI cheap and deterministic
Latency and battery measurements	No	You would be measuring the network
Permission revoke/restore drills	No	Needs real sensors and OS dialogs
App size and packaging checks	No	Independent of the model host
Thermal throttling observations	No	Requires sustained on-device load

First Rollback: Rehearse the Reverse Move

The rollback is the step juniors skip, and it is the step that protects them. Rehearse it while your change is small, so the mechanics are boring by the time the change is large.

Tag the commit you are reverting from: git tag before-retry-<sha>.
Revert without rewriting shared history: git revert --no-edit <sha>.
Re-run the contract test and confirm it passes on the reverted tree.
Re-run scripts/first-hour-audit.sh and diff the JSON against the committed fingerprint.
Write one sentence: what changed, what you expected, what you observed.
Push the revert as its own pull request, so the rollback is reviewable like any other change.

A rollback that reverts code but leaves MODEL_ENDPOINT pointing at a server you no longer intend to use is not a rollback. It is a rollback plus a future incident, and the fingerprint diff in step four is how you catch it before someone else does. If the diff shows the endpoint changed but the latency array looks identical, you probably reverted the wrong branch.

Limitations and Who Should Skip This

The audit script records what your shell can see; it makes no claim about NPU, GPU, or thermal headroom.
A passing contract test means the interface is compatible, not that the output is good or safe.
A hosted free endpoint cannot validate background execution, permission loss, or battery cost.
The 10 million token figure and the free server option are operator-supplied and may change; verify them at the source.
If your fixtures contain regulated user data, do not send them to a hosted endpoint at all.

Skip this approach if your onboarding blocker is hardware access, or if your repository already documents device, OS, framework, permission state, and network conditions for every test. Keep it if your first morning keeps disappearing into a config file that nobody owns.

If the thing blocking your first pull request is an endpoint rather than your code, a free tier plus a free server is a reasonable way to unblock the first hour.

When you run the audit, reply with your device model, OS version, toolchain versions, endpoint state, and whether the run recovered, restarted, or silently disappeared after the rollback. Comparable environment records are worth more than a green checkmark that nobody else can reproduce.

Practice the Rollback Before Your First Mobile Voice Pull Request

Roronoa — Mon, 12 Oct 2026 23:10:41 +0000

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

Set the route flag to remote, and confirm your notes still name this device, OS build, and network.
Start a short capture in the foreground, then enable airplane mode before a response can return.
Confirm the UI shows a local failure, and confirm no retry job remains for that capture.
Revoke the microphone permission, return to the app, and confirm the route would return stop.
Background the app for one minute, restore it, and confirm the previous buffer was discarded.
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.

Keep a Slept Voice Buffer Out of the First-Hour Retry Queue

Roronoa — Sun, 11 Oct 2026 20:17:07 +0000

You join the mobile repo on a Monday morning, and the first ticket asks for a remote voice dry-run before lunch. The handset on the desk is the repo's current debug phone, and the OS build is the one printed in the ticket. You start a capture, lock the screen while the request is in flight, and the process is frozen before any transcript returns. This opening is a proposed first-hour scenario, not a lab measurement from a device you can cite yet.

When the screen wakes, a naive client treats the frozen call as a transport error and enqueues the same audio buffer again. The retry record also keeps the free-server base URL, a session token, and a partial transcript so the next launch can resume. That record is exactly what a first rollback must not leave behind in DataStore, UserDefaults, or a debug log. You can catch this class of leak before the first pull request, if you separate retryable metadata from sensitive payload bytes.

What the first hour is proving

You are not proving that a model is accurate, and you are not proving that a free server will stay available next quarter. You are proving that a sleep transition drops in-flight audio, refuses to persist a session token, and still recovers a clean idle state. The expected observation is a redacted retry record, an empty audio directory, and a cold start that does not call the remote host. If any of those three checks fail, the first pull request is not ready, even when the happy-path demo sounds fine.

Power, network, and permission state belong in the notes beside the steps, because a later reader cannot reproduce a lifecycle result without them. For this proposed run, assume the phone is unplugged, Wi-Fi is on, cellular data is available, and the microphone permission stays granted through the sleep. Do not invent a battery percentage or a latency percentile for a run you have not executed on this handset. Write "not measured" in those columns until you have a trace from the same device and the same build.

Fields that may survive sleep

Use the table below as a review checklist in the first pull request, and keep it next to the client change. A field that is useful for debugging is still forbidden if it can reconstruct the user's voice or the host session. The reviewer should be able to accept the enum and still reject the row that stores a URL. That split matters more than a green demo, because the queue outlives the screen you just unlocked.

Field	After sleep	Retry queue	Rollback notes
New request id	Generate again	Yes, opaque	Yes, if redacted
Base URL	Drop from disk	No	No
Session token	Drop immediately	No	No
Audio bytes	Delete the file	No	No
Partial transcript	Drop	No	No
Failure class enum	Keep	Yes	Yes
Elapsed milliseconds	Keep only if measured	Yes	Label measured or not

What the reviewer accepts

The failure class should stay a closed enum, and it should never embed the response body or the request URL. Allowed values in this proposed policy are slept, revoked, offline, and timeout, with no free-text suffix attached. A partial transcript is not a failure class, even when the words look harmless in a debug build. If you need a human explanation, write it in the pull request from memory, not from a file the app still holds.

Proposed redaction helper

The TypeScript below is a proposed artifact for the first pull request, and it has not been executed against a device in this draft. You can port the same checks to Kotlin or Swift if the repo is not a React Native app. The function returns metadata only, and it refuses audio bytes, tokens, transcripts, and base URLs as retry input. A thrown error here is a successful privacy stop, not a cue to dump the raw object.

type FailureClass = "slept" | "revoked" | "offline" | "timeout";

type RetryMeta = {
  requestId: string;
  failureClass: FailureClass;
  elapsedMs: number | null;
};

const BLOCKED = ["audio", "token", "transcript", "authorization", "baseurl"];

export function redactForRetry(input: Record<string, unknown>): RetryMeta {
  for (const key of Object.keys(input)) {
    const lowered = key.toLowerCase();
    if (BLOCKED.some((word) => lowered.includes(word))) {
      throw new Error("retry record refused a sensitive field");
    }
  }
  const failureClass = input.failureClass;
  if (
    failureClass !== "slept" &&
    failureClass !== "revoked" &&
    failureClass !== "offline" &&
    failureClass !== "timeout"
  ) {
    throw new Error("retry record refused an unknown failure class");
  }
  const requestId =
    typeof input.requestId === "string" && input.requestId.length > 0
      ? input.requestId
      : `local-${Date.now()}`;
  const elapsedMs = typeof input.elapsedMs === "number" ? input.elapsedMs : null;
  return { requestId, failureClass, elapsedMs };
}

Call this helper before you write AsyncStorage, DataStore, SharedPreferences, or a file under the cache directory. If the helper throws, delete the capture file and leave the queue untouched, then surface a local idle state. Do not catch the error and serialize the original input as a fallback, because that fallback is the leak. If the runtime lacks a UUID helper, a local timestamp string is enough for this proposed check.

A free server is only the dry-run host

Disclosure: This article was prepared as part of MonkeyCode's product outreach. The outreach for this draft describes MonkeyCode as an open-source project with free model access and a free server option. That option can serve as a remote dry-run host when you do not want to stand up your own machine. Treat the availability note as operator-supplied, and re-read the project docs before you plan a soak.

Do not depend on a quota, a model name, a region, or a duration that this draft does not verify. This article does not measure latency, uptime, or token use, and it does not name a model or freeze a token allowance. You should keep the base URL in a debug-only config that the release build cannot read. You should never commit a session token beside that config, even when the dry-run lasts only an hour.

A free host does not relax the sleep rule, so audio bytes and partial text still stay off the retry queue. If the docs you open today list a free token allowance, copy that figure into your own test notes. A post should not freeze a token number that the project can change without a new release. Confirm the license in the repository before you vendor any client sample into the first pull request.

If you want to confirm the current free-model and free-server notes, start from the project docs. Stop when the offer no longer matches your plan, and do not treat this article as the source of those limits. That check belongs before the first pull request, not after a rollback has already shipped a hardcoded host. One mismatched doc page is a reason to pause the dry-run, not a reason to cache audio until the host returns.

Steps for the proposed sleep run

Work through these steps on the debug handset, and write the actual device and OS build beside step one before you lock the screen. Keep the phone unplugged for the whole pass, and do not start a second capture until the first cache check is done. Mark every observation as measured or proposed, so a later reader can tell a real trace from this draft. If the ticket names a different lifecycle event, write that event above the list before you change the steps.

Confirm the microphone permission is granted, the phone is unplugged, and Wi-Fi is the active network before you start the capture.
Start a short voice capture, lock the screen while the request is still in flight, and wait until the process has been frozen.
Wake the phone, unlock the app, and confirm the user-visible state is idle rather than a resumed recording.
Inspect the retry store and confirm it holds only a failure class, an opaque id, and an elapsed field marked measured or not.
Confirm the voice cache directory is missing or empty, and confirm no partial transcript file remains beside it.
Run the log scan below, and treat any token-shaped hit as a failed first-hour check rather than a logging nit.

Android log scan

These commands are a proposed observation method, and they do not replace the device run you still need to perform yourself. Replace the package name and the log tag after you read them from the repo, and do not assume the examples below match your application id. A clean proposed result is one slept line, no token-shaped hit, and an empty or missing voice cache after the wake. Save the command output next to the pull request, but only after the token scan has already passed.

adb logcat -d -s VoiceDryRun:I
adb logcat -d | rg -n "Bearer |sessionToken|partialTranscript" || echo "no token-shaped hit"
adb shell run-as com.example.voicedryrun ls cache/voice || echo "no voice cache"

iOS stream

On iOS, stream the subsystem you actually ship, then search for the same three patterns before you attach anything to the pull request. If rg is missing on the workstation, use findstr on Windows with the same patterns, and record which tool you ran. Do not paste a raw log that still contains a transcript into the pull request description or a public issue. A simulator log can hint at string leaks, but it does not replace the sleep transition on a physical phone.

log stream --predicate 'subsystem == "com.example.voicedryrun"' --level info

Rollback before you merge

After the dry-run, revert the client change on a branch and install that build over the same debug app without clearing data first. Cold start the app, leave the microphone idle, and confirm that no request leaves the device for the previous host. Then clear app data on purpose and repeat the cold start, so you can separate a leftover queue from a fresh install. The recovery outcome you want is restarted idle, not silently resumed, and not a retry of the slept buffer.

Uncleared reinstall

Record whether the result recovered, restarted, or silently disappeared, and attach the device, OS, and framework versions beside that sentence. A reviewer should reject the pull request if the reverted build still prints a resume line that names the old request id. That failure means the queue outlived the code you thought you had rolled back on this branch. Fix the storage path, repeat the uncleared install, and only then ask for another review from the same teammate.

adb shell pm clear com.example.voicedryrun
adb shell am start -n com.example.voicedryrun/.MainActivity
adb logcat -d -s VoiceDryRun:I

Who should skip this

Skip this workflow if the product must legally retain audio for a medical, legal, or accessibility record, because deletion on sleep would violate that requirement. Skip it if you cannot run a physical device, because an emulator sleep does not reproduce the same process freeze or radio handoff. Skip it if the first ticket is only a copy change, because this test plan is heavier than that review needs. Also skip a remote dry-run when on-device speech already meets the ticket and a network hop would add retention risk.

Limitations you should keep visible

This draft does not include a measured trace, a battery figure, or a latency table from a handset. Any number you add later must come from your own device, and it must name the build you actually ran. Example package names and log tags are placeholders, not a claim that a specific OS build was certified here. Android cached-app limits, iOS jetsam, and OEM task killers can delete files for reasons this policy does not control.

A redaction helper cannot see strings that a native SDK logs before your code runs, so you still need the log scan. Free model access and a free server option can change without notice, so re-read the docs on the day you run. A missing endpoint is not a reason to persist audio until the host returns and the queue can flush. Do not treat this article as a security audit, a compliance sign-off, or a benchmark of any vendor.

If your log scan finds a token, rotate that credential, delete the local capture, and do not file the raw line in a public issue. Pin the framework version from the lockfile you actually have, rather than from a blog post that will go stale. Ask a teammate to repeat the uncleared reinstall on a second handset before you call the check done. That second handset still needs its own OS build in the notes, because a matching result on one phone is not a class proof.

What to send back

If you run the same sleep and rollback on your own phone, reply with the device, the OS build, and the transition steps you actually used. Say whether the voice buffer recovered, restarted idle, or silently disappeared after you reverted the branch. Those three details are enough for another reader to compare environments without copying your audio or your tokens. Leave the capture file off the comment, even when the redaction helper already passed on your machine.

Keep a First-Hour Transcript Out of the Recording Notification

Roronoa — Sat, 10 Oct 2026 16:18:36 +0000

You open the voice ticket in your first hour, and the sample already starts a foreground recorder so Android will not kill the session. The notification title is fine, but the content line is the rolling transcript, which stays visible after the screen locks. A reviewer screenshot of that shade will keep the note even if your remote call never succeeds. Treat the notification text as production data, and fix it in the first pull request before you add any model call.

See the leak before you debate models

A laptop chat demo never shows you the lock screen, the shade, or a bug-report screenshot of that shade. Your phone does, and the operating system is allowed to display the text you put in a foreground-service notification. You should write down the device, the OS build, the framework version, and whether the microphone permission was granted or later revoked. Separate that record from any claim about model quality, because this test does not measure a model.

The same mistake appears on iOS when a Live Activity or Now Playing line carries the partial note. Widgets, the lock screen, and a screen recording can all retain that line after your view controller is gone. You are not testing recents thumbnails, crash payloads, or phone-backup archives in this first pull request. You are testing one surface only, which is text the system shows because your process asked it to.

Decide what the system surface may say

Your first pull request may show a stable status such as Listening or Saving on this phone. It may not show the transcript, the prompt, a user name, or a summary that came back from a server. It also may not update the notification every second with a longer string, because each update is another copy the shade can capture. If the session ends, you cancel the notification immediately and you leave no inbox entry behind.

You should hold the draft in process memory until a later foreground gate allows a deliberate user action. If the user locks the phone, backgrounds the app, or revokes the microphone, you stop the recorder and you drop the draft. A rollback of this branch should restore a notification that still says only Listening, even if the previous channel identifier remains installed. Write that expected rollback result in the pull request so a reviewer can check it without guessing.

Build the notification from a fixed label

The Android snippet below is a proposed pattern, not a log from a device run you can cite as evidence. You can mirror the same rule in Swift by keeping Live Activity content state free of note text. The helper returns a label, and the caller never passes the transcript into the builder.

fun recordingLabel(state: String): String = when (state) {
  "listening" -> "Listening"
  "saving" -> "Saving on this phone"
  else -> "Voice session"
}

fun buildRecordingNotification(context: Context, state: String): Notification {
  val label = recordingLabel(state)
  return NotificationCompat.Builder(context, "voice-session")
    .setSmallIcon(R.drawable.ic_mic)
    .setContentTitle("Voice note")
    .setContentText(label)
    .setVisibility(NotificationCompat.VISIBILITY_SECRET)
    .setOnlyAlertOnce(true)
    .setOngoing(true)
    .build()
}

Create the channel once with low importance and secret lock-screen visibility, and leave the channel id unchanged. Android keeps existing channel settings after you roll back, so a renamed channel can leave the old public channel installed. Document an uninstall on the test phone if that was the only way you cleared a channel you had already published. On a shared client, reject any attempt to interpolate the draft into the label before it reaches native code.

val channel = NotificationChannel(
  "voice-session",
  "Voice session status",
  NotificationManager.IMPORTANCE_LOW
).apply {
  lockscreenVisibility = Notification.VISIBILITY_SECRET
  setShowBadge(false)
  description = "Status only. No note text."
}

export function notificationLabel(state: "listening" | "saving" | "idle"): string {
  if (state === "listening") return "Listening";
  if (state === "saving") return "Saving on this phone";
  return "Voice session";
}

export function labelExcludesDraft(label: string, draft: string): boolean {
  const allowed = new Set(["Listening", "Saving on this phone", "Voice session"]);
  if (!allowed.has(label)) return false;
  if (draft && label.includes(draft.trim())) return false;
  return true;
}

The string check is a proposed unit test for the contract, and it does not prove what the shade rendered. You still need one physical phone, because a green test can hide a native call that appends the draft later. Run the check in the pull request so a junior change cannot smuggle note text through the shared layer.

Confirm the shade with a fixture, not a real note

Use one physical phone and a fixture string you can safely lose, such as FIXTURE_NOTE_ALPHA. Do not dictate a real message, and do not paste raw dumps into the pull request. The dumpsys command can print notification text, so treat its output as sensitive even when you expect a label.

adb shell dumpsys notification --noredact | head -n 40
adb shell dumpsys deviceidle | head
adb shell dumpsys battery | head

If the fixture appears in that output, the test failed, even if the remote call never started. If only the fixed label appears, record that observation with the device name and the OS version. An inconclusive dump is not a pass, and a simulator run is not a substitute for the lock screen. You should run the following steps in one sitting so the permission state stays easy to explain.

Install the branch on one phone, grant the microphone, and start a session that uses the fixture string only.
Open the notification shade and the lock screen, and confirm both show the fixed label rather than the fixture.
Background the app and then return, and confirm the shade did not gain a second entry that contains the fixture.
Revoke the microphone permission, and confirm the notification is cancelled and the fixture is not replayed from memory.
Restore the permission, lock the phone while listening, and confirm no new note text appears on the lock screen.
Roll back the branch and reinstall the previous build, then confirm the channel still cannot display note text.
Attach a screenshot only after you have checked that the fixture string is absent from the shade.

Use the table when the ticket grows a remote call

What you want to add	Allowed in this pull request	Required behavior
Status notification while recording	Yes	Fixed label only, secret lock-screen visibility, cancel on stop
Partial transcript in the shade or a Live Activity	No	Keep the draft in memory, and never pass it to the notification API
Remote summary while the screen is locked	No	Abort the call, and do not retry from a background worker
Remote summary after an explicit foreground tap	Only as a follow-up	Send a short draft the user can see, with no device identifier
Log or bug-report line that contains the fixture	No	Log a reason code only, and review dumpsys output locally
Channel id change bundled with the copy fix	No	Leave the id stable so rollback does not orphan a public channel

A follow-up may call a remote model only after the user is in the foreground and the notification still shows a fixed label. That follow-up is a different pull request, because mixing both changes makes a rollback harder to trust. You still do not put the model response into the notification, or the response becomes a second copy on the lock screen.

Where a prototype endpoint can sit

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

MonkeyCode's free model access and free server option can serve as that temporary prototype endpoint for the allowed draft. This draft does not verify a quota, a model list, a hardware size, or how long that access remains available. The endpoint does not relax the notification rule, and a free server is not a reason to put note text in the shade. Keep the URL in a debug configuration, send text only, and remove or flag it before anyone cuts a release build.

If your team already has that free access, try the foreground row only, and write the device result beside the pull request.

Limitations and who should skip this

This method does not tell you latency, battery cost, or whether any summary the server returned was accurate. It does not certify backup exclusion, crash redaction, or on-device speech, which need their own evidence. Channel behavior also differs by OEM skin, so one phone result must not be generalized to every Android device. iOS Live Activities have separate lifecycle rules, and a SwiftUI preview will not reveal the lock screen.

You should not use this approach for health, payment, or other notes your policy forbids leaving process memory. You should also skip it if you cannot install a build on a physical phone, because an emulator will not show the shade. Teams that need a fully offline voice product should not add a prototype server in the same first pull request.

Ask for a comparable phone, not a vibe check

Invite reviewers to repeat the fixture test and to reply with environment facts rather than a general impression. Ask for the device, the OS, the transition they tried, and whether the fixture stayed absent after rollback. A matching failure on their phone is useful evidence, and a simulator-only approval is not evidence at all.

Name the device, the OS, the framework, and the notification channel id you actually exercised.
State the microphone permission and whether the screen was locked, awake, or in battery saver.
Report only the label you saw in the shade, not a transcript and not a dumpsys paste.
Say whether rollback recovered the old label, restarted the channel, or left the fixture visible.

Your first pull request is done when a stranger can lock the phone and still see no note text in the shade. Model choice can wait until that surface stays empty on the same device you named in the test notes. Keep the fixture result, the channel id, and the rollback outcome together so the next engineer can repeat the hour.

Keep a Revoked-Mic Failure Log Out of Your First PR Prompt

Roronoa — Thu, 08 Oct 2026 09:20:37 +0000

You cloned the voice repo just after standup, and the staff engineer wants a first pull request before lunch. The bug is narrow: on-device inference still shows a partial result after the user revokes microphone permission mid-utterance. You open a remote coding workspace so an assistant can help you read the failing local test. The laptop log still holds a PCM path, a short transcript, and a debug token from that run.

The phone-side model never needed that workspace, but your prompt can still carry the residue off the device. This checklist splits phone evidence from anything you paste while you learn the repo in the first hour. Treat the steps as a proposed experiment, and replace every placeholder with the handset you actually hold. A conclusion without those fields is a story, not a measurement you can defend in review.

What your first pull request should prove

You are not trying to show that on-device speech is cheaper or more accurate than a hosted model. You are trying to show that a revoke stops capture, drops in-memory samples, and writes a redacted failure row. That row should name the lifecycle transition and the permission state, and it should omit what the user said. Your first rollback should remove the patch without leaving the raw log in either the phone sandbox or the remote workspace.

A single borrowed phone is enough if you write the transition down before you edit any production code. You do not need a device farm, a battery rig, or a latency number you never recorded on this handset. Copy the OS build and framework versions from the device and the lockfile, then keep those strings in the pull request. If the bridge caches a granted flag after the system has already denied the mic, record that as a separate failure.

Decide what the coding server is allowed to see

A remote editor helps when you are new and want a careful review of a small diff. It is the wrong disk for microphone buffers, packaged weights, or an unredacted session log from the failed run. Run inference on the phone, store raw files in an ignored local directory, and send the coding server a skeleton. That skeleton should still let a reviewer follow the bug without reconstructing the spoken words from the session.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. This draft treats free model access and a free server option as operator-supplied availability, not as a verified quota or hardware profile. This article does not name models or token ceilings, because those details were not verified against a primary source here. If you use that server, edit the harness there, then read the current project terms before you depend on the offer.

Safe to paste

Test name, OS family, and a permission state such as revoked during an active capture.
Elapsed milliseconds you timed yourself, plus the clock source you used on that specific run.
Booleans for capture stopped, buffer cleared, and whether the interface recovered, restarted, or stalled.
Framework and dependency versions taken from the lockfile rather than recalled from memory.

Keep off the server

PCM, WAV, or Opus paths, and any filename that embeds a session identifier from the failed run.
Partial transcripts, prompt text, speaker labels, or contact strings taken from the captured utterance.
Model weight directories, tokenizer files, and any license key shipped beside the packaged model.
Debug tokens, crash identifiers, and backup paths left behind by the previous local run.

Run the proposed permission-revoke pass

The following pass is a procedure for you to execute, not a result collected for this article. Stop when a step disagrees with the handset, and write the disagreement instead of smoothing it into a pass. Do not claim a recovery you did not watch on that specific device, OS build, and permission path. Leave network, power, and permission state in the notes, because a later reader cannot reconstruct them from a green check.

Write the device model, OS build, app version, and speech dependency version into env.txt before you launch.
Cold-start the debug build with microphone permission granted and with the network left in a known state.
Start a short on-device session and wait until the first partial callback is visible on screen.
Revoke microphone permission in system settings while that session is still marked as capturing on the device.
Return to the app and note whether capture stopped, the buffer cleared, and the screen avoided transcript text.
Force-stop the process, relaunch it, and confirm the sandbox has no new raw audio file from the attempt.
Roll the patch back, repeat the revoke, and confirm the old bug returns only as a redacted table row.

Observation table

Use the table as the only artifact you attach to the pull request from this first-hour pass. Leave the observation column blank in the repo template, and fill it on your machine after the run. Do not paste the filled table into a public issue if any cell still contains utterance text. Replace the sample package name before you run a shell command against a phone you do not own.

Step	Expected if the patch holds	Your observation
Revoke mid-session	Capture stops and no new partial is shown
Return to the app	UI names permission loss and hides utterance text
Relaunch	Sandbox has no new raw audio file
After rollback	The bug returns only as a redacted row

Redact the log before the prompt

Run the filter on your laptop before you paste any failure log into a remote assistant prompt. It preserves the shape of the failure while stripping paths, token assignments, and long quoted strings from the file. It is a guardrail for a first pull request, not a guarantee that a clever encoding was fully removed. Read the redacted file yourself, and keep the original log outside any directory the coding server syncs.

#!/usr/bin/env bash
set -euo pipefail

# Proposed local filter. Never aim it at a folder of real user audio.
input="${1:-failure.log}"
test -f "$input"

sed -E \
  -e 's#(/(data|storage|var|Users|tmp)/[^[:space:]]+)#<path>#g' \
  -e 's#([A-Za-z0-9_]*([Tt]oken|[Ss]ecret|[Kk]ey)[A-Za-z0-9_]*=)[^[:space:]]+#\1<redacted>#g' \
  -e 's#"[^"]{12,}"#"<text>"#g' \
  "$input" > failure.redacted.log

echo "Paste failure.redacted.log only. Leave ${input} off the coding server."

Commit the ignore rules with the test so a later rollback does not teach the next junior to check raw logs in. The redacted file is also ignored, because a weak filter can still leave a quote you missed on the first pass. If your editor auto-uploads the workspace, confirm those patterns are excluded before you open the remote project. Treat a sync client that uploads ignored files anyway as a failed setup, not as a minor warning.

failure.log
failure.redacted.log
*.pcm
*.wav
*.opus
session-*/
models/

Android grant line, not a full dump

On Android, record only the permission snapshot, and avoid dumping audio buffers or a full package report. Run the shell check only against a debug package you own, then paste the redacted grant line. A full dumpsys transcript can include paths and identifiers that do not belong in a coding-server prompt. Replace the sample application id with the id declared in this repository before you execute the command.

# Proposed check. Replace the application id with the one in this repo.
adb shell dumpsys package com.example.voice | awk '/RECORD_AUDIO/{print}'

If the grant line is missing, write that absence in the table instead of assuming the permission call succeeded. If adb is unavailable, use the system settings screen and write the same states by hand. Either path still needs the device model and OS build written beside the note you keep. A screenshot of the utterance itself does not belong in the pull request or the remote prompt.

Put a tiny guard in the first patch

The TypeScript below is illustrative pseudocode for a session guard you can adapt to the repo permission bridge. Comments describe the intended branch, and they are not evidence collected from a device in this draft. Ask a reviewer to look for revoke-before-start and revoke-after-stop, which this sketch does not fully model. Keep the function free of string fields that could hold a transcript, a file path, or a debug token.

type SessionPhase = "idle" | "capturing" | "revoked" | "cleared";

export function onPermissionRevoked(phase: SessionPhase): SessionPhase {
  if (phase !== "capturing") return phase;
  // Proposed: stop capture, drop in-memory samples, and skip transcript UI.
  return "revoked";
}

export function failureRow(phase: SessionPhase, elapsedMs: number) {
  return {
    phase,
    elapsedMs,
    transcriptIncluded: false,
    audioPathIncluded: false,
  };
}

You can ask the free model to search the diff for a log line that still interpolates utterance text. Paste the redacted row and the function above, and reject any suggestion that writes the spoken words to disk. Say that rejection in the pull request so the next junior sees the boundary before copying the snippet. If the model proposes a cloud upload for debugging, decline it and keep the failure row local to the device.

Roll back without a leftover file

A first rollback should be dull and complete, not a heroic rewrite of the session stack during lunch. Revert the commit, rerun the ignore check, and search both workspaces for raw audio suffixes and token strings. If the remote workspace still contains the original log or a token from the prompt, delete the file and rotate the token. Clean means both places lack the recording, not merely that the app still compiles after you revert the patch.

Limitations, and who should not use this

This pass does not measure battery drain, thermal throttling, or recognition accuracy, so do not cite it as a benchmark. The filter misses multiline secrets, binary audio, and text hidden as base64, so you still read the redacted file before any upload. iOS and Android revoke at different moments, and a cross-platform bridge may cache a granted flag after the system denial. A React Native or Flutter plugin can also replay a cached partial after process restart, which you should record as its own row.

Do not use this path if your employer forbids source from leaving the laptop, even after a local regex pass. Do not use it when the audio might include health data, financial details, or a child's voice, because redaction is not consent. Do not file a conclusion if you cannot name the device, the OS build, and the permission state you actually changed. Teams that already have a locked-down debug pipeline should keep using that pipeline instead of a personal coding server.

What to attach when you open the pull request

Send the device model, the OS build, the exact revoke steps, and whether the session recovered, restarted, or silently kept a partial. Treat a matching environment as comparable evidence, and treat an unnamed phone as an anecdote rather than a result. If a remote editor would help you draft only the redacted harness, read the current free-server terms before you create the workspace. Leave the raw log on the phone, and ask reviewers to compare your transition notes rather than to rerun private audio.

Gate Device Context Before Your First Remote Mobile AI Call

Roronoa — Thu, 08 Oct 2026 06:33:23 +0000

You join a React Native repo on a Tuesday morning, and the first ticket is already waiting. A senior asks you to add a caption helper before lunch, because the on-device package is not merged yet. The phone on your desk is a shared Android handset, the office Wi-Fi is noisy, and the sample photo belongs to a teammate. You open the prompt builder and almost append the file path, the account id, and the device model string.

Treat the scene as a proposed first-hour drill, not as a measurement from a named lab. This article gives you a gate, a decision table, and a rollback path you can run yourself. It does not report battery minutes, latency percentiles, or a device matrix that someone already passed. Record your own device, OS, framework versions, permission state, and network before you trust any result.

Public posts this week celebrate fast demos, which can tempt a new teammate to ship a remote helper that afternoon. Your first mobile pull request still has to survive a permission change and a rollback, even when that demo path looks finished. A caption that works on office Wi-Fi is not the same as a caption that stays safe after you background the app. Keep the demo impulse, but put the gate and the revert drill in the same pull request.

What leaves the phone on a first pull request

A remote caption call is a product decision, not a convenient debug shortcut you hide inside a helper. Your first pull request should name the fields that may leave the device, and it should name the fields that must stay local. If you cannot explain a field to a reviewer in one sentence, do not put that field in the request body. Use this table as a review checklist, and do not treat it as a legal opinion about privacy duties.

Field	First-PR default	Why it matters	Rollback check
Short user-typed caption hint	May send if the screen says so	The user can see the text	Confirm the hint is absent from logs
Image bytes or file path	Keep local unless the ticket requires upload	Paths reveal usernames and album layout	Confirm no path remains in the client log
Account id or email	Do not send	It links the prompt to a person	Search the diff for id fields
Device model, OS build, advertising id	Do not send	It is not needed to draft a caption	Confirm the client sends a fixed context object
Microphone buffer	Do not send in this pull request	Voice capture is a separate permission story	Confirm the microphone permission is untouched
Crash id or session token	Do not send	Tokens outlive the screen you are editing	Rotate any token already pasted into a prompt

Adjust every row to match your app's actual data classes before you open the pull request. A field that looks harmless in a demo photo can still be identifying in a support screenshot. When a row says to keep a value local, the client should not log that value either. The rollback column is there so a later revert does not leave a quieter copy behind.

Build a local gate before the network call

The gate below is proposed TypeScript for a React Native client, and it is meant for review first. This draft has not executed that function on a device, so treat it as a review artifact. You should run it in your own app, with your own versions, before you ask for review. A passing unit test on your laptop does not prove that the handset blocked the socket.

type CaptionRequest = {
  hint: string;
};

type GateResult =
  | { ok: true; body: CaptionRequest }
  | { ok: false; reason: string };

const BLOCKED = [
  /[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}/i,
  /\b(file|content):\/\//i,
  /\b(account|user|device|session)Id\b/i,
];

export function gateCaptionHint(raw: string): GateResult {
  const hint = raw.trim().slice(0, 120);
  if (hint.length < 2) {
    return { ok: false, reason: "hint_too_short" };
  }
  if (BLOCKED.some((rule) => rule.test(hint))) {
    return { ok: false, reason: "hint_looks_like_context" };
  }
  return { ok: true, body: { hint } };
}

Keep the allowed body small

Call the gate in the same function that would otherwise build the fetch body for the caption. If the gate fails, show a local message and do not open a socket to the endpoint. That failure should stay boring, visible to the user, and free of the rejected hint text. Keep the allowed body to the single hint field so a later edit cannot smuggle a device object back in.

export async function requestCaption(rawHint: string, endpoint: string) {
  const gated = gateCaptionHint(rawHint);
  if (!gated.ok) {
    return { status: "blocked", reason: gated.reason };
  }
  const response = await fetch(endpoint, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify(gated.body),
  });
  return { status: response.ok ? "sent" : "remote_error" };
}

Lifecycle steps that belong in the same pull request

Run these steps on one physical device, and write the observed result next to each step. Do not average several phones into one score, because this drill is only a single-device note. The expected result in your notes is only a proposal, so replace it when your run disagrees.

Record the device name, the OS version, the React Native version, and the app build you installed.
Start on Wi-Fi with the caption screen open and with the microphone permission still denied.
Submit one normal hint, then submit a second hint that contains an email and a file path.
Enable airplane mode, submit the normal hint again, and write down whether a socket opened.
Background the app for one minute, resume it, and submit the same normal hint one more time.
Revoke network access for the app where the OS allows it, then restore that access and retry.
Point the endpoint at an unreachable host and confirm the screen does not retry without a stop.
Roll back the remote call as the later section describes, then repeat the blocked-hint and airplane-mode steps.

You want three observations from that session, not a benchmark chart for the release note. Note whether the blocked hint stayed on screen, whether any request left the device, and whether resume created a second request. If a log line still includes the rejected hint, the gate is not finished for review. A small proposed search script can keep the code review honest before you push the branch.

# Proposed local check. Adapt the paths, then run it in your app repository.
rg -n 'deviceId|advertisingId|file://|content://' src/caption || echo 'no obvious context keys'
rg -n 'gateCaptionHint' src/caption || echo 'gate not referenced'

It does not replace the device pass above, so keep both results in the pull request. If rg is missing, use the search in your editor and paste the same two queries into the test note. A clean search plus a failed device check still means the feature is not ready to merge. A dirty search means you stop and remove the extra field before you talk about servers.

Separate what you measured from what you only read

Your reviewer will ask which steps you ran, and which behavior you only read in documentation. Mark the device pass as measured only after you perform it, and mark the table as a proposed default. If documentation lists a quota or a region, copy that sentence into your notes with the date you read it. Do not turn a documentation sentence into a performance claim about the handset in your hand.

Latency on office Wi-Fi is not latency on a subway handover, and a single success is not a battery result. Sleep, backgrounding, and a permission revoke can each change the outcome without changing your code at all. Write those transitions as their own rows, even when the happy path already looks fine to you. A junior note that separates those rows is more useful than a confident summary with no device attached.

Where a temporary remote endpoint fits

The drafting brief for this article supplied two availability claims about MonkeyCode: free model access, and a free server option.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The same brief describes the project as open source, which you should confirm in the repository license. This draft does not verify a token quota, a model list, a hardware size, or an uptime promise. Those details change quickly, and they were not checked against a primary source for this article. You should read the current project documentation before you plan a demo around any numeric limit.

A free remote endpoint can help you learn the client contract while the on-device package is still in review. It should not become the place where you paste device context, session tokens, or a teammate's photo path. Use it only after the gate returns ok, and keep the endpoint in one config value for an easy rollback.

If you need a temporary remote target while you practice that gate, check the current MonkeyCode docs yourself. Confirm the free model access and free server option there, including whatever limit the docs list today. Stop if the docs disagree with this article, and follow the docs rather than this draft. A missing limit in the docs is a reason to pause the demo, not a reason to guess a number.

Roll the remote path back on purpose

Your first rollback should be rehearsed before anyone lets the feature flag default to on. Create a branch, add the gate and the endpoint, then remove only the network call and leave the gate in place. The same local gate remains useful later, after the caption helper moves fully onto the device. You are practicing a clean deletion, not a rewrite of the whole screen during an incident.

# Proposed rollback drill. Do not run this against a shared release branch.
git switch -c caption-remote-scaffold
# Commit the gate and the endpoint wrapper, then note that commit hash.
git revert --no-edit <scaffold-commit>
rg -n 'fetch\(' src/caption || echo 'remote call removed'

Name the recovery, do not summarize it

After you finish the revert, open the caption screen and confirm the blocked-hint message still appears. Then confirm the app does not crash if the endpoint configuration variable is now absent. A rollback that deletes the gate and keeps the fetch is the wrong direction for this ticket. You should describe the screen recovery in the pull request as recovered, restarted, or silently dropped.

Ask a teammate to repeat the same transition on their phone, and ask them to include the device and OS in the comment. If their result disappears after resume, do not call the drill passed because your phone looked fine. Compare the two notes before you merge, and keep the stricter result in the pull request. A silent disappearance is still a failed recovery, even when no exception reaches the developer console.

Who should skip this scaffold

You should skip the remote scaffold when the caption text is health, payment, or account-recovery content. Skip it if your ticket already includes microphone audio, because audio needs a separate permission and retention review. Skip it if you cannot name the endpoint owner, the log sink, and the person who can revoke the client configuration. This approach also fails when a reviewer wants a latency claim or a battery claim from you.

This article does not give you those numbers, and you should not invent them from one cafe session. A free server does not remove mobile constraints: backgrounding, permission loss, flaky Wi-Fi, and backup of local logs still belong in the test note. The sample is React Native shaped, so an iOS or Flutter port still needs its own permission and logging check. If your team already has an on-device model package ready, use that path and keep this remote scaffold out of the first pull request.

What to bring back to review

Paste a short evidence block into the pull request, and use only values you actually observed. Leave any unknown field blank rather than guessing a version, a network state, or a result. The block is how a reviewer can repeat your transition without trusting a summary adjective alone.

Device and OS:
React Native version and app build:
Network, power, and permission state:
Steps you ran, including the lifecycle transition:
Whether the bad hint was blocked locally:
Whether rollback recovered, restarted, or dropped the hint:
Limitation you will not claim:

That evidence block is the useful artifact from your first hour on this caption ticket. The remote call is optional scaffolding, and the gate is the change you can defend after the scaffold is gone. Bring the blank fields back filled with your own run, or bring them back blank and say the device pass is still open.

Keep Partial Transcripts Out of Crash Upload Payloads

Roronoa — Thu, 24 Sep 2026 18:22:57 +0000

You join the voice-notes repo on a Monday morning, and the open bug is already older than your laptop setup. The on-device recognizer drops the last partial utterance when an incoming phone call kills the app process. In the first hour you add a crash breadcrumb that stores that partial text so the next fatal error is easier to explain. By the afternoon that same string sits inside a vendor upload collected from the shared QA phone on the desk.

This opening is a proposed failure path, not a measurement taken from a named handset anywhere in this article. You should treat every version, permission bit, and power state below as a field you fill on your own device. The goal is to stop your first pull request from teaching the crash pipeline how to remember spoken content. A redacted breadcrumb can still explain the process death without copying the utterance into the outbound upload.

What you inherit in the first hour

Separate this leak from older ones

You are not retesting keyboard learning, phone backup, recents capture, or the remote debug host during this pass. Those leaks need their own experiments, and mixing them in one matrix hides which control actually failed. This pass covers crash breadcrumbs, native tombstones, and the log buffer that a reporter attaches after the process dies. If a unique sentence can be rebuilt from any of those three places, the first-hour patch is not finished.

Write the environment header first

Write the device model, OS build, framework version, and crash SDK version at the top of your notes. Also record microphone permission, network type, and whether the phone is on battery saver or wall power. A junior rollback is safer when that header remains in the pull request after the diff has already moved. Without the header, the next person cannot separate a scrub failure from an OS change they never reproduced.

Decide what a breadcrumb may keep

Use a contract, not a vibe

Use the table as the contract for the first pull request, and review every row before you add an SDK call. It is a review aid, not a claim that every crash vendor behaves the same way on every OS build. If your pinned SDK disagrees with a row, follow the current vendor guide and record that exception in the pull request. Do not copy an older sample that attaches the raw message string just because a tutorial did that last year.

Field	Allowed in crash payload	Reason
Partial transcript text	No	Speech content is user data, even when recognition ran on device.
Transcript length bucket	Yes, coarse only	Empty, short, or long helps triage without storing words.
Locale tag	Yes	Language id explains model choice and does not reveal the utterance.
Model package id	Yes, if non-secret	Identifies the on-device bundle you shipped, not the audio.
Audio bytes or file path	No	Paths often include user ids, and bytes are the recording itself.
Permission state at crash	Yes	Revoked versus granted microphone changes the expected failure.
Lifecycle transition	Yes	Background, call interruption, or low-power entry is the variable.
Exception class and stack	Yes, after scrub	Keep the type, and drop messages that echo the utterance.

When support asks for the words

If a teammate says support cannot debug the death without the words, move that debate out of the first hour. Ship the redacted payload first, then design a consented debug build that never ships on the public store track. A store build that sometimes includes speech is harder to roll back than a flag that never attached the text. Keep the debate in the ticket, and keep the words out of the payload while the team waits for a decision.

Build the breadcrumb in one place

Proposed Kotlin scrub

Put the scrub in one function so a later feature cannot invent a second logger that still holds the raw text. The Kotlin snippet below is proposed example code, and you should rename the types to match the crash SDK you link. It has not been timed on a device for this article, so do not read it as a latency or battery result. Run it only after you confirm the method names against the SDK version pinned in your dependency lockfile.

data class VoiceCrashCrumb(
    val lengthBucket: String,
    val locale: String,
    val modelPackageId: String,
    val micGranted: Boolean,
    val lifecycle: String,
    val errorClass: String,
)

fun lengthBucket(partial: String?): String = when {
    partial.isNullOrEmpty() -> "empty"
    partial.length < 40 -> "short"
    partial.length < 160 -> "medium"
    else -> "long"
}

fun voiceCrumb(
    partial: String?,
    locale: String,
    modelPackageId: String,
    micGranted: Boolean,
    lifecycle: String,
    error: Throwable,
): VoiceCrashCrumb {
    // Never pass partial or error.message into the SDK map.
    return VoiceCrashCrumb(
        lengthBucket = lengthBucket(partial),
        locale = locale,
        modelPackageId = modelPackageId,
        micGranted = micGranted,
        lifecycle = lifecycle,
        errorClass = error::class.java.simpleName,
    )
}

Register the same rule on iOS and cross-platform shells

Never pass the partial string or the exception message into the map that the crash SDK will serialize and send. On iOS, apply the same rule to every custom key you set before the reporter builds its outbound payload. Metric and diagnostic APIs differ by OS version, so read the guide that matches the SDK version you actually link. If that SDK offers a log scrubber callback, register it beside the crumb builder rather than in a random extension.

A second registration point is how the first rollback leaves one path still attaching speech after the flag looks off. Search the repo for the partial variable name before review, including instrumentation tests and leftover sample activities. A unit test that asserts the serialized map lacks that variable is worth more than a comment about being careful. Add the test in the same pull request so a rollback cannot delete the only guard you had.

If you are in React Native or Flutter, keep the scrub on the native crash bridge, not only in the Dart or JavaScript logger. A redacted JS breadcrumb does nothing once the native module still forwards the utterance in its own map. Name that bridge method in the pull request so the reviewer knows which side you actually changed. Cross-platform shells fail this test when only one language was searched for the partial string before review.

Run the first-hour experiment

Follow one order

The steps below are a procedure for you to run, not a result reported from a lab phone in this article. Fill the environment header, follow the order, and stop when the payload still contains the unique synthetic sentence. A pass on a plugged-in phone does not prove the same scrub under battery saver or after a microphone revoke. Those transitions belong in this pull request because they are how on-device voice sessions actually die in the field.

Record device model, OS version, app version, crash SDK version, network type, battery saver state, and microphone permission before you start.
Install a debug build that calls the crumb builder, and keep any raw logger behind a flag that defaults to off.
Speak a unique synthetic sentence that appears nowhere else in the repo, using an animal name plus a four-digit code.
Force a crash from the voice screen after the partial text is visible, using the test hook you already ship for QA.
Collect the local crash file or the debug upload, then search for that sentence, the raw partial, and the exception message.
Repeat the crash once after you background the app, and once after you revoke the microphone and return to the same screen.
Toggle airplane mode before the reporter flushes, restore the network, and search the retried payload for the same sentence.
Confirm the payload still has the length bucket, locale, model package id, permission bit, lifecycle label, and exception class.

Capture commands you can adapt

Replace the sample package name, and do not collect logcat from a phone that already holds real user audio from customers. If the search tool in the sample is missing on your host, use grep with the same pattern and paste the command into the pull request. On a shared QA phone, clear the log buffer before the run so an older session cannot masquerade as a fresh pass. A dirty buffer is the usual reason a junior marks the scrub finished while yesterday's sentence is still sitting there.

adb shell getprop ro.build.version.release
adb shell dumpsys package com.example.voicenotes | grep -i permission
adb logcat -c
adb logcat -d -t 200 | grep -E "transcript|voiceCrumb|PARTIAL"

Record the iOS outcome separately

iOS needs a different capture path, because Console and the crash reporter do not share a single ring buffer. Export the pending report from the device, or open the SDK debug viewer, then search for the same unique sentence. Write whether that report recovered after relaunch, restarted as a new session, or silently disappeared from the pending queue. Keep that observation next to the Android notes, and do not invent a battery figure to make the two platforms look comparable.

Roll back without restoring the leak

Your first rollback should disable the flag that attaches breadcrumbs, not delete the scrub function from the module. If the redacted crumb crashes inside the crash SDK, turn attachment off and keep forbidden fields out of every other logger. Do not fix a bad upload by putting the raw partial back while you wait for a vendor support reply. That shortcut becomes the next release incident, and it is harder to see because the flag was described as temporary.

A rollback note in the pull request can stay this concrete:

The attachment flag defaults to false on the store track, and a debug build may enable it only after the unique-sentence search passes.
Reverting that flag does not revert the rule that partial text never enters the upload map, the log line, or the native message.
If QA needs the words, they use a local-only overlay that the release build compiles out, rather than a hidden gesture in production.

If the flag-off build still uploads the sentence, the leak sits outside this patch and needs a wider search before you blame the crumb. Check analytics events, native standard error, and any attach-log checkbox that the reporter settings screen still leaves enabled. Also search for string interpolation that builds a log line before your scrub function has a chance to run. The first hour is long enough to miss a debug print that a sample activity left behind during the previous sprint.

Draft fixtures away from production speech

You will want synthetic utterances and a second reading of the scrub rules before you open the first pull request. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode's free model access and free server option can host that drafting when you paste only synthetic sentences and the redaction function. Do not paste customer audio, device logs, or crash archives just because that server is free and the first hour feels short.

This article does not name a model, a token quota, a machine shape, or a duration you should plan a release around. An allowance you remember from an older post is not evidence, so treat the live limit as unknown until the project page states it. If the project publishes a repository or a pricing note, read that page yourself rather than trusting a recap from chat. Use the free model access on the free server to generate length-bucket cases from invented sentences only.

Then ask whether a proposed log line still holds recoverable speech, after you confirm the current terms on the project page. If your workplace forbids external code tools, skip the drafting server and review the contract table with a teammate on your own network. The handset experiment still stands on its own, and a local review is enough to open a careful first pull request. A free server is only a convenience for synthetic fixtures, not a store for the speech this patch is trying to keep on device.

Who should skip this pattern

Skip this pattern when you must retain verbatim speech for a medical, legal, or accessibility record inside an already approved system. Also skip it when the crash SDK cannot attach custom keys without also capturing the full log buffer on that OS version. In that case the first pull request should disable log attachment, rather than encode the sentence into a clever numeric bucket. A one-character length bucket is the transcript with extra steps, and review should reject that encoding as a leak.

Employee debug screens can remain when they are local-only and compiled out of the release variant you actually ship. They must not call the upload API, even behind a hidden gesture that the QA group believes nobody outside the team will find. Hidden gestures leak because crash reporters and screen recordings both outlive the person who added them during onboarding. If you need consented capture, put it in a separate build flavor whose name a reviewer cannot miss in the diff.

What you should send back

Reply with the device, the OS build, the crash SDK version, and the lifecycle step you actually executed on that hardware. Say whether the unique sentence recovered in a later upload, stayed only in the local log, or disappeared after the scrub. If you rolled the flag back, say whether the flag-off build still contained the sentence inside some other attachment. Those three outcomes are more useful than a vague note that the crash flow felt acceptable on your desk.

This article measured no handset, and vendor behavior changes with the SDK version you pin during the following week. A scrub that passes a logcat search can still fail inside a native minidump or an attached console export from the same run. Re-read the SDK notes for your exact dependency before you merge, and link that note from the pull request description. If you cannot name the device and the transition, you do not yet have a result, only a plan you still need to run.