How We Patched 100+ PRs Across Our App Empire in One Day

Last updated: May 6, 2026

The Audit#

The Developers Digest empire is now 31 apps deployed across *.developersdigest.tech (see the full apps directory). That number snuck up on me. Each app started life from the same starter template, but templates drift the moment you fork them. Favicons go missing. Someone forgets to wire Google Analytics. The OG card pattern that worked last quarter quietly stops getting copied forward. By the time you have 24 production apps, the variance between them is louder than the consistency.

So I ran a parallel curl audit across all 31 hosts. The matrix that came back was not pretty.

Reachability: 24 of 31 apps responded with a 200. Seven were down - three returning 5xx (agentfs, hookyard, tracetrail) and four totally unreachable (agent-eval-bench, cost-tape, hooks-directory, migrate, skill-builder). Two of the dead hosts were still being linked from the public /apps page. That alone was an emergency.

Drift across the 24 reachable apps:

The Sentry zero stung. The favicon number was the embarrassing one - empty browser tabs across most of the empire.

The Fanout#

The interesting part is what happened next. Instead of opening one big "fix everything" PR, I treated each missing piece as a fanout job. One audit, one fix template, dozens of agents, one PR per repo.

Here is the day's PR ledger:

• 9 chore: add llms.txt PRs
• 17 chore: add favicon.ico PRs
• 4 chore: add Google Analytics tracking PRs
• 16 chore: add Sentry PRs (queued; pending source-tree confirmation)
• 4 robots.txt + sitemap.xml route handler PRs
• 8 OG image / metadata PRs
• 35 migrate: replit -> coolify + neon + clerk PRs (a separate but parallel migration sweep)
• 2 developers-digest-site apps-page PRs (one to add Neon Data Lite, one to mark unreachable apps as Coming Soon so the public page stops linking to dead hosts)

Total open PRs by end of day: 58, with a separate ledger of in-progress Sentry/OG batches still being prepped. Counted with the not-yet-opened batches, the day's pipeline was over 100 PRs.

Status by Merge State#

Of the 58 PRs that landed in GitHub today:

• 40 are CLEAN - no failing checks, ready for @devin-ai-integration review and merge.
• 18 are blocked by a single failing build check - almost always pnpm-lock sync drift between the agent's working tree and CI. The fix is mechanical; the cost is that they cannot auto-merge.
• 0 changes-requested (none of these repos have formal review gates configured).
• 51 awaiting first-pass Devin review.

The two PRs against developers-digest-site itself are the worst stuck - they fail four checks each (analyze, check, lighthouse, typecheck) because the marketing site has the strictest CI in the empire. That's by design and I am not going to soften it.

The Pattern: Audit Once, Fix in Fanout, Document in Skills#

The thing worth extracting from this day is not any individual fix. It is the loop:

1. Audit once. A single 30-second curl -P 10 sweep across all hosts produced a complete drift matrix. No app-by-app investigation, no spreadsheet maintenance.
2. Fix in fanout. Each row of the matrix becomes a templated PR job. Agents clone to /tmp/<slug>/ (in-place agents collide on branch switches), apply the same patch, push, open a private PR, tag Devin. One per repo. This only works with the same merge discipline any parallel agent fanout needs - narrow file ownership per agent, one PR per concern.
3. Document in skills. Every recurring pattern from the day gets promoted into ~/.claude/skills/ so the next audit is faster and the next fanout has a tighter template. Today's session added entries for dd-pr (the branch → PR → tag-Devin convention) and the parallel-clone strategy.

The key insight is that consistency across an app empire is not a one-time job. It is a recurring drift problem. The only durable answer is to run the audit weekly via cron and keep the fanout templates warm.

What's Outstanding#

Two things did not get fixed today:

• GitHub Actions billing. A handful of CI checks are queued behind an Actions usage cap on the org. Until that's resolved, even the CLEAN PRs can't auto-run their final checks. Migration to a higher tier is on tomorrow's list.
• Coolify dashboard work. The seven down hosts all need triage in Coolify - some are 5xx (deploy broken, fixable via lockfile sync), some are 000 (DNS / TLS / image build). Each requires hands-on dashboard time. I will not be batching this; the failure modes are too varied.

What This Cost#

The cost of this kind of day is mostly agent time, not human time. I spent about 90 minutes actively driving - writing the audit script, reviewing the drift matrix, queuing the fanouts, spot-checking Devin reviews. The agents did the rest in parallel. Three things made it tractable:

• One source of truth. apps-data.ts on this site is the canonical list of every deployed app. Every audit script reads from it.
• Tight per-PR scope. Each fanout PR touches one or two files. No PR ever combined "add favicon" with "fix Sentry" - that's how you get rejections.
• Honest skip allowed. Agents that hit a repo with non-standard structure are allowed to skip with a written reason instead of forcing a broken PR. About 12% of the queued jobs ended up in the skip pile, which is fine.

If you are running more than five deployed apps from the same starter, you already have this drift problem. The longer you wait to audit, the worse the matrix gets. Run the curl sweep this week. For the receipts side of this workflow, see why agent swarms need receipts and the earlier build log on shipping 24 apps with AI agents.

FAQ#

How do you audit drift across many deployed apps?#

Run a single parallel curl sweep across every host. Here a 30-second curl -P 10 sweep across all 31 hosts produced a complete drift matrix covering reachability, favicon.ico, llms.txt, OG tags, sitemap.xml, robots.txt, the GA tag and Sentry init, with no app-by-app investigation.

Why open one PR per repo instead of one big fix?#

Each missing piece becomes a templated fanout job: one audit, one fix template, many agents, one PR per repo. Each PR touches one or two files and never combines concerns such as "add favicon" with "fix Sentry", which is how you avoid rejections.

What blocked the PRs from merging?#

Of the 58 PRs opened, 40 were clean and 18 were blocked by a single failing build check, almost always pnpm-lock sync drift between the agent's working tree and CI. The two PRs against the main site failed four stricter checks, and some CI was queued behind a GitHub Actions usage cap.

How do you keep app consistency from drifting again?#

Treat it as a recurring drift problem rather than a one-time job. Run the audit weekly via cron, keep the fanout templates warm, and promote every recurring pattern into skills so the next audit and fanout are faster.