Which Generation Introduced This Bug? Building Provenance Into Rork Apps

Build Stamp — Burning In the Generation ID

First, decide on a string that uniquely names a generation. I use sequence number + short label (for example, g047-pricing). A bare number is hard to recall; a bare label collides.

For Expo (React Native), feed a build-time environment variable into extra in app.config.ts.

// app.config.ts
export default ({ config }) => ({
  ...config,
  extra: {
    ...config.extra,
    generationId: process.env.GENERATION_ID ?? "dev-local",
    builtAt: new Date().toISOString(),
  },
});

In the app, read this value from a single provenance module. Scatter the references and you invite stale copies, so keep the read point to exactly one.

// src/provenance.ts
import Constants from "expo-constants";
 
const extra = Constants.expoConfig?.extra ?? {};
 
export const PROVENANCE = {
  generationId: extra.generationId ?? "unknown",
  builtAt: extra.builtAt ?? "unknown",
} as const;

The build just passes the variable: GENERATION_ID=g047-pricing eas build --profile production, updated on every generation. Show a small g047-pricing in a corner of your settings screen and you can read the generation off a device you handed out by QR at a glance.

The idea is the same on the Swift side that Rork Max generates. Put the value in a User-Defined build setting and read it back through Info.plist.

enum Provenance {
    static let generationId =
        Bundle.main.infoDictionary?["GenerationId"] as? String ?? "unknown"
}

Why make the generation ID the primary key instead of the timestamp? A timestamp says "when it was built" but not "which intent it came from." When you investigate a bug, the latter is what you actually want. Keep the timestamp only as a secondary detail.

Generation Ledger — One Line per Generation

Put the ledger in GENERATIONS.md at the repo root. It needs no tooling, and it lives alongside your git history. Keep each entry short and at a grain you can grep later.

## g047-pricing — 2026-07-07
- Intent: locale support for price display (fix currency symbol position)
- Scope touched: PricingScreen, useLocalePrice
- Suspected side effect: state initialization (watch)
- Credits spent: 12
- Build: eas build production (no TestFlight; QR device only)

The two lines that matter are "Intent" and "Suspected side effect." Right after a generation, glance at the diff once to check whether anything you didn't ask for has changed, and jot down whatever caught your eye. Those few dozen seconds of note-taking save you half a day weeks down the line.

Left to human memory alone, the ledger goes unwritten on exactly the busy days. So pair it with a small script that mechanically attaches the files that actually changed between generations. Tag each generation with git tag, and you can summarize the diff against the previous one.

// scripts/gen-diff.mjs
import { execSync } from "node:child_process";
 
const [prev, curr] = process.argv.slice(2);
if (!prev || !curr) {
  console.error("usage: node scripts/gen-diff.mjs <prevTag> <currTag>");
  process.exit(1);
}
 
const stat = execSync(`git diff --stat ${prev} ${curr}`, { encoding: "utf8" });
console.log(`### ${prev} → ${curr}\n\n\`\`\`\n${stat}\`\`\`\n`);

Run node scripts/gen-diff.mjs g046-home g047-pricing and you get a summary of changed files and line counts. Paste it into the matching ledger entry and "intent" sits next to "what actually got touched," making any gap between them obvious. If you only asked about the pricing screen but store/auth.ts changed, that is your future fire.

Stamp the Generation Onto Telemetry

Even once your local build and the ledger connect, production bugs happen on users' devices. Attach the generation ID to crash reports and key events, and you can reverse-map from your dashboards to a generation.

import * as Sentry from "@sentry/react-native";
import { PROVENANCE } from "./provenance";
 
Sentry.setTag("generation_id", PROVENANCE.generationId);
 
// Pass the same value to analytics as a super property
analytics.setSuperProperty({ generation_id: PROVENANCE.generationId });

Now you can group your crash list by generation_id. Comparisons like "crash rate went from 0.3% on g046 to 1.1% on g047" become something you state with numbers, not a guess. Slice AdMob impressions or purchase conversion by generation and you may find that a regenerated UI quietly dropped revenue.

Once the numbers point at a generation, open that generation's ledger entry and read the line you wrote under "suspected side effect." More often than not, the culprit is already noted there.

A Triage Sequence for When a Bug Appears

Once all three layers are in place, investigation becomes a fixed sequence of steps. This is the order I follow myself.

1. Group crashes and key metrics by generation_id and identify the generation where the numbers started to slip. Data is the starting point, not a hunch.
2. Open that generation's ledger entry and read "intent" and "suspected side effect." The gap between what you asked for and what happened shows up here.
3. Look at the gen-diff output and check for files touched outside your instruction. In most cases the cause of the production bug is somewhere in that list.
4. If your local build stamp matches the generation, reproduce on that version and roll back to the previous generation to see whether the symptom disappears.

The virtue of this order is that a hunch never enters until the very end. An investigation that used to mean trying reproduction conditions at random becomes a narrowing driven by generations.

How Far to Take It — Knowing Where to Stop

Provenance is insurance, not a goal. Try to record every generation perfectly and the recording itself becomes the burden, and you stop doing it. Here is the line I hold.

For the places that hurt when they break—billing, the data layer—a thin net of automated tests on top of provenance buys peace of mind. If a generation rolls something distant back, the test goes red and you notice. I go into this in "Adding a Minimal Test Safety Net to Rork-Generated Screens." If you want the wider view of long-term maintenance, "Maintenance Design to Keep a Rork-Built Personal App Alive Past Three Years" is a good companion.

Recording provenance takes roughly a minute per generation. Even at a dozen-plus generations a month, that's a dozen-plus minutes. Cut a single half-day investigation just once and it has more than paid for itself.

Wrapping Up

AI builders make "easy to regenerate" their sharpest edge. To wield that edge safely over the long run, you need the discipline of recording the fact of regeneration itself. The build stamp for your local version, the ledger for the intent, telemetry for the production impact—thread those three with the same generation ID and bug investigation shifts from hunch to reverse lookup.

Starting with your next generation, add just one line to GENERATIONS.md. The first line does nothing for you. It starts to pay off on the day a bug comes back for the third time.

It's a small habit I picked up in day-to-day operation, but if it trims anyone's investigation time, I'll be glad. Thank you for reading.