Cross-Project Synthesis: February 27, 2026

The Supabase Migration Problem Is a Governance Problem

Two projects independently hit the same wall today — and neither knows the other did. Authexis has migrations being applied manually via SQL editor because supabase db push is out of sync with the migration table. Skillexis applied six migrations directly to production via psql, bypassing Supabase’s tracking entirely, and now carries the same risk: a future db push could try to re-apply them. Both projects added idempotency guards (IF NOT EXISTS, ON CONFLICT) as a safety net, but safety nets aren’t strategies.

What’s interesting isn’t the technical fix — it’s that this pattern emerged independently in two codebases with no shared infrastructure. The root cause is the same: rapid parallel development (overnight pipeline runs, multi-agent grinds) generates schema changes faster than the migration tracking system can absorb them. When you’re shipping 19 PRs overnight or grinding 6 issues in parallel, the migration file becomes a bottleneck, and developers route around bottlenecks. The question is whether Supabase’s migration model is fundamentally incompatible with this velocity of work, or whether there’s a discipline fix that doesn’t slow things down. Either way, this needs a shared solution before it becomes a shared crisis.

Parallel Agent Workflows Are Productive but Fragile

The multi-agent grind pattern — spinning up parallel worktree agents to tackle batches of issues simultaneously — appeared in three projects today, and each one surfaced a different failure mode. Paulos ran six agents in parallel and had one die mid-run (recovered). Authexis ground six Apple issues in two rounds of three and hit a pbxproj merge conflict between targets. Skillexis had the most instructive failure: stage_all=true caused cross-contamination between worktrees, producing three corrupted PRs that had to be closed and redone manually.

The pattern is clearly worth pursuing — Paulos shipped four clean PRs from a single /grind batch, and Authexis completed its entire v1-apple milestone in one session. But the failure modes are all different, which means there’s no single fix. Merge conflicts in shared files (pbxproj, migration files), agent death and recovery, and staging configuration that bleeds across boundaries are three distinct problems requiring three distinct solutions. Skillexis’s flag — “need to fix the grind skill to use explicit file staging instead” — is the most actionable, but the broader question is whether the grind infrastructure has outpaced its reliability engineering. The ratio of shipped PRs to wasted PRs matters, and today it wasn’t great everywhere.

Empty Backlogs Are as Dangerous as Full Ones

Synaxis-h shipped its workshop landing page and then hit a wall: zero open issues on GitHub, an empty backlog, and no queued work for the next session. The entire next session plan is “run /scout to generate issues.” Meanwhile, Authexis decomposed a too-large audit issue (GH-581) into four grindable children, and Paulos used /scout to find six post-refactor issues that became immediate work. The contrast is stark — projects with healthy issue pipelines had productive days; the project without one shipped a single page and stalled.

This reveals something about the /scout → /prep → /grind workflow that’s easy to miss: the bottleneck isn’t execution, it’s issue generation. Paulos and Authexis both demonstrated that grinding is fast once issues exist with good specs. The constraint is having well-specified work ready to grind. Synaxis-h also flagged that its “Content alignment Q1 2026” milestone has minimal progress and no target date, with Q1 ending in a month. An empty backlog isn’t just an operational gap — it’s a strategic signal that the project lacks a clear next milestone. Polymathic-h is in better shape (five scout-generated issues filed with specs), but the lesson is the same: scout passes aren’t optional maintenance, they’re the fuel supply for the entire workflow.

The Content Pipeline Is Becoming Real Infrastructure

Paulos wired /close → /sum-up → /reflect into a single pipeline that goes from work log to published podcast with audio, and it touches three repos (the project repo, polymathic-h for content storage, and Cloudflare for deployment). Polymathic-h fixed 31 broken URL aliases on reflection posts and hardened its pre-commit hook to abort on audio generation failures. Authexis unblocked the paulos CLI’s ability to push ideas via API by fixing auth to use database-backed API keys instead of JWT-only. These are three different projects solving three different pieces of the same problem: turning daily work into published content automatically.

The ambition is real — one command from “session ends” to “podcast is live” — but the coupling is tight. The ElevenLabs voice ID is hardcoded via env var in at least two places (paulos and polymathic-h’s pre-commit hook). The Authexis API key auth was rewritten today because the old approach didn’t work for CLI callers. The polymathic-h pre-commit hook now blocks commits if ElevenLabs is down. Each fix makes the pipeline more capable and more brittle simultaneously. The question isn’t whether this pipeline works — it clearly does — but whether it degrades gracefully when any single piece fails.

Questions This Raises

• Should there be a shared Supabase migration strategy across Authexis and Skillexis, or are they different enough that independent solutions make sense?
• What’s the acceptable failure rate for parallel grind runs before the infrastructure needs a reliability pass? Is one corrupted PR out of six a problem or a cost of doing business?
• How should projects signal “backlog empty, needs scout” so it doesn’t get discovered at the start of a session when it’s already too late?
• Is the content pipeline’s tight coupling to ElevenLabs, Cloudflare, and cross-repo commits a temporary bootstrapping cost or an architectural risk that compounds?
• The Synaxis-h Q1 milestone has a month left — is anyone tracking cross-project milestone health?

What Matters About This

The workflow tooling — scout, prep, grind, close, reflect — is no longer experimental. It’s the production system. Today’s logs show it working well (Authexis completing an entire Apple milestone, Paulos shipping a full content pipeline) and failing in specific, diagnosable ways (Skillexis cross-contamination, Synaxis-h backlog starvation). The interesting phase is over; the reliability phase has started. That means the bugs in the workflow tooling itself — staging behavior, migration tracking, backlog generation cadence — deserve the same rigor as bugs in the products.

The content pipeline crossing from “neat idea” to “infrastructure that blocks commits” is a milestone worth noting. When your pre-commit hook calls an external API and your CLI authenticates against a different project’s database to push content ideas, you’ve built a system, not a script. Systems need monitoring, fallback paths, and someone thinking about what happens when ElevenLabs is down at 11pm and you just want to commit your work log.

Where This Could Go

• Shared migration playbook: Write a runbook for Supabase migration recovery that both Authexis and Skillexis can use. Test db push in a branch environment before production.
• Grind reliability pass: Fix explicit file staging in the grind skill (Skillexis’s flag), then audit the other projects for the same stage_all risk.
• Backlog health check: Add a step to /close that flags when a project has fewer than 3 open grindable issues, triggering a scout recommendation for next session.
• Content pipeline circuit breakers: Add timeout and fallback behavior to the ElevenLabs integration so audio failures degrade to “publish without audio” rather than blocking commits or failing silently.
• Q1 milestone audit: Synaxis-h’s Q1 deadline is real. Triage it before it’s March.