Cultivating Antigravity Walkthroughs as a Regression Replay Memo: A Four-Month Operational Log

Why I settled on the RG-YYYYMM-{app}-{summary} naming scheme

Walkthroughs become hard to search once the count climbs. For the first three weeks, I named them in natural language — "wallpaper crash," "dark mode flicker." A month later, I could no longer tell what was what. I needed a scheme.

The scheme I settled on looks like this:

RG-202602-wallpaper-collectionview-index-out-of-range
RG-202602-zen-mode-darkmode-statusbar-flicker
RG-202603-affirmation-iap-receipt-validation-fail

The RG- prefix stands for "regression" and visually separates these memos from refactor-oriented Walkthroughs in the sidebar. The YYYYMM keeps the list in chronological order in the Manager Surface. {app} is the internal codename of the app. {summary} is a brief description of the crash or bug.

After switching to this scheme, my searches like "find past RG- memos that contain collectionview" started returning useful results consistently. Antigravity's native search is already strong at natural language, but pairing it with a structured prefix helps the Agent narrow candidates faster.

What goes inside one Walkthrough, in concrete terms

Abstract talk only goes so far. Here is the body of an actual memo, with some method names changed but the structure intact.

Walkthrough: RG-202602-wallpaper-collectionview-index-out-of-range
─────────────────────────────────────────────────────────────────
 
Step 1 — Preconditions
  - Build: 1.42.0 (build 4218)
  - OS: iOS 18.4 / iPad Pro 12.9 (3rd generation)
  - Purchase state: Pro not purchased
  - Launch type: warm start (second launch or later)
  - Initial tab: Favorites
 
Step 2 — Reproduction steps
  1. Launch the app
  2. Open the "Favorites" tab (0 items)
  3. Switch to the "Categories" tab
  4. Open the "Japanese Seasons" category
  5. Tap the first wallpaper
  6. Right-swipe 8 times on the preview screen
  7. Tap back to return to the list
  8. Return to "Favorites" ← crash here
 
Step 3 — Expected vs. actual
  - Expected: the Favorites empty state re-renders.
  - Actual: NSRangeException
    *** -[__NSArrayM objectAtIndex:]: index 8 beyond bounds [0..0]
 
Step 4 — Fix links
  - PR: github.com/dolice/wallpaper-app/pull/1842
  - Crashlytics issue: F-2026-02-1842
  - Related Walkthrough: RG-202010-wallpaper-collectionview-reload-crash

The most valuable line is in Step 4 — the link to a related Walkthrough. Whenever I notice that I have solved something similar before, I link to that older memo from the new one. Months later, when the next iteration of the same problem surfaces, I land on a chain of memos written by past versions of myself.

Wiring Crashlytics and TestFlight into the search loop

Writing a memo is not enough. The future me has to actually look at it. I had to bake that lookup into my daily workflow so that searching old memos became the default first move when a new crash appeared, not an afterthought.

The shape of the workflow today is this: when I open an issue on Crashlytics, the very first prompt I send to the Antigravity Agent is something like the following.

Search the existing Walkthroughs prefixed with RG- for any past
regression memo that matches the stack trace below. If a match
is found, return only the name and the Step 3 (expected vs.
actual) summary. If no match is found, respond with "no match".
 
[paste Crashlytics stack trace]

The Agent reads the body of the existing Walkthroughs and either returns a previous memo with its fix link, or tells me there is nothing on record. If the answer is "no match," that becomes my cue to create a new RG- memo before patching the bug.

Before this loop existed, I would go Crashlytics → source → git blame → past PR every time. Now it is Crashlytics → Antigravity search, which has cut my initial triage time by roughly two-thirds. There is a quiet feeling that the past self who wrote the note is helping the present self do the work — both grandfathers on my mother's and father's sides were temple carpenters, and I have heard about handwritten care notes that they pasted onto the handles of their tools. The mental image is similar.

Four months of numbers, and the three-strike rule

Four months in, a few changes are measurable.

• Duplicate bug reports across four apps: down roughly 60 percent compared to the previous period, using Crashlytics' "regressed issues" label as the baseline.
• Average time to create one memo: about 12 minutes.
• Number of times an existing memo helped me re-fix something quickly: 23 instances over four months.
• Number of new memos created when "no match" was returned: 41 over four months.

Looking at those numbers, I realized something I had not expected. Not every bug deserves a memo. For the first month I dutifully created an RG- for every Crashlytics issue and burned myself out. The fix was a three-strike rule.

These are the three filters I use today to decide whether a regression deserves a memo:

1. Does it apply to more than one app? AdMob initialization order, for example, is a four-app concern, so it earns a memo.
2. Does it touch the older layers of the codebase? Old UIViewController files are the highest-recurrence zone, so they are worth memoizing.
3. Are there five or more occurrences per day on Crashlytics? Below that, I am unlikely to see this crash again next week, so the memo cost outweighs the benefit.

Filtered through those three rules, the memo creation count settled at ten to twelve per month. Not too many to maintain, not too few to be useful.

Failure modes, and the rules that keep the practice alive

The first failure mode was trying to memoize everything. Thirty crash reports a day cannot all become memos. I broke the practice within a week of starting it.

What rescued the practice was writing my own operational rules into the project's .context/ directory and asking the Agent to read them at the start of every crash triage session. The Agent now says things like "this does not meet the three-strike rule, so I will fix without memoizing," and that single sentence keeps the practice from collapsing under its own weight.

The second rule I added is about where the memos live. I do not keep them inside the application repository. They live in a separate knowledge repository, because the original code may be refactored away or removed entirely, while the memo about the bug should outlive the code that caused it. My current layout looks like this:

~/knowledge/regressions/
  ├── README.md
  ├── 2026-02/
  │   ├── RG-202602-wallpaper-collectionview-index.md
  │   └── RG-202602-zen-mode-darkmode-statusbar.md
  └── 2026-03/
      └── RG-202603-affirmation-iap-receipt-validation.md

Plain Markdown is intentional. Antigravity reads it. Other editors read it. Five years from now, if I have moved on to a different tool, the memos still open in any text editor. Indie development is a long game, and I try to avoid locking myself into one specific tool whenever the cost of avoiding it is small.

A one-line letter to the future self at the bottom of every memo

The smallest habit that gives the largest return is this: every memo ends with one line addressed to my future self. It is not a technical note. It is closer to a quiet letter.

Notes for future self:
  This crash came from initializing AdMob asynchronously in
  application:didFinishLaunchingWithOptions:. If you find yourself
  tempted to switch back to a synchronous call, please re-read
  Crashlytics issue F-2026-02-1842 first. You'll end up in the
  same place.

Future me forgets what past me was thinking. Leaving a one-sentence note about why a decision was made, and where to look if you are tempted to reverse it, saves an entire round of relearning. After my children — who do not live with me day to day — became my reference point for "what do I leave behind that lasts," I started writing this kind of one-line letter into my technical documents too. Slowly, the notes started feeling less like checklists and more like correspondence.

Where I am after four months, and what I would like to try next

Because I am using Walkthroughs slightly off-label, it is possible that a future Antigravity update changes the picture. Even so, the maintenance overhead has measurably dropped, and that result alone makes the practice worth continuing.

The next experiment I want to try is a monthly review pass. At the end of each month, I would like to ask the Agent to read all the RG- memos from that month and produce a structural summary of which apps have which kinds of weak surfaces. The hope is that individual reproduction memos will start to form a map — a picture of where the codebase is fragile, drawn from real incidents rather than gut feeling.

I am still in the middle of the practice, and four months is not enough to know whether the memo structure I have today will hold up over a full year. What I can say is that I wish I had started this three years ago. If you are also maintaining apps alone over a long horizon, I hope some part of this is useful.

Thank you for reading this far. The next time you are about to push a fix, please pause for thirty seconds and ask whether the bug you just patched is worth a regression replay memo. Half a year from now, a slightly tired version of you will be very grateful.