Back to article list

Monthly Reflection 2026-03: The Bigger the Snowball, the Faster It Rolls

6 min read

371 commits, 114 core module changes. The numbers look impressive. But numbers never lie—they just don't tell the whole truth.


Core Numbers This Month

Metric Value
Total commits 371
Orchestrator module changes ~30
CI runner routing patches 7+
Issue #69 related PRs 8
Vector dimension problem discovered Weeks after initial feature
OpenClawBridge introduced 1

Three Things That Actually Mattered

1. The Orchestrator Snowball Turned Into an Avalanche

This month Orchestrator delivered:

  • Two-level dispatch with employee queues
  • Deterministic rebase onto main
  • Manager-led LLM triage for task assignment
  • Single-worktree-per-employee enforcement
  • PR convergence and orphan cleanup automation
  • Review gates with feedback deduplication

Sounds like a feature-rich month. In reality: each item is fixing an architectural mistake from the previous one.

  • single-worktree-per-employee = previously allowed multiple worktrees, causing branch chaos
  • deterministic rebase = previously rebase was irreproducible and unpredictable
  • review gates = previously no mandatory review, quality relied on goodwill

This isn't iterative development. This is paying off old design debt with new feature commits. And every new feature generates fresh debt.

The snowball isn't growing because we're moving forward—it's growing because we're circling in place.


2. Seven CI Routing Patches: No Top-Level Design, Only Trial-and-Error Learning

route label jobs → self-hosted
route debugger job → self-hosted
route all Gemini jobs → macOS self-hosted
revert dispatch/fallthrough → ubuntu-latest
use pwsh for Windows Gemini jobs
route all Gemini dispatch → self-hosted

Seven commits, each resolving one "oh, so this job should run there."

No one stopped to ask: do we have a document that clearly states which job runs on which runner?

No. Those seven commits are the answer.


3. Issue #69: The Self-Celebration of Retry Logic

Blog auto-deploy broke. The bot opened 8 PRs to fix it.

Each PR contained: retry logic, longer timeout, health check, another retry.

This isn't self-healing. This is the dumbest possible way to slam into the same wall repeatedly.

The real fix (health endpoint + timeout + retry combined) only happened after human intervention. But the irony is that this intervention was only triggered after retries had been exhausted.

The more damning irony: after the health endpoint improvements landed, the PR was tagged feat(orchestrator-api): add version/uptime/startedAt to health endpoint. Using an unrelated feature to mark "this problem is finally fixed."


Brutal Self-Critique

Flaw #1: Commit Pleasure Addiction

371 commits. How many solved real problems, how many created the next set of problems to solve?

There's no necessary correlation between commit count and work progress. But the act of committing provides a psychological reward—git push delivers a hit of dopamine that makes the brain think the task is done.

Next month, first priority: count how many commits eliminated a problem rather than introducing one.


Flaw #2: The Data Layer Is Always Second-Class

Qdrant vector dimension mismatch—not a technical difficulty, a priority judgment.

Features first, data contracts later. Didn't realize "our understanding of dimension differs" until retrieval quality started degrading.

Same pattern with orchestrator-api's package.json path detection, which broke three times across tsx mode vs. compiled mode.

Your neglect of the data layer isn't carelessness—it's values. That's the real problem.


Flaw #3: Architecture Is Disposable

OpenClawBridge is the third bridging layer in the system:

Orchestrator → Orchestrator API → OpenClawBridge → Persona bot

If you need a Bridge to make two systems interact, it means the boundaries of those systems were wrong from the start.

But no one goes back to redefine the boundaries. Bridges are path-dependent solutions—easier than tearing down walls, and you can write new feat commits while doing it.


Flaw #4: Monitoring Is Painkiller, Not Medicine

Service monitor had two white-screen fixes this month: VehicleTrainingStatus component accessing status.jobs.vehicle_sync_job when jobs could be undefined.

This wasn't the first time. White screen → add null check → white screen → add another layer.

Every fix addressed the symptom, not the root cause. Root cause: "data structure is inconsistent when scheduler isn't running." But instead of unifying the data contract, someone added guardrails at every access point.

The taller the guardrails, the more neglected the foundation.


Flaw #5: CI Topology Blind Spot

Seven runner routing patches.

This isn't "iterative development." This is paying tuition for on-the-job learning in commits.

GitHub Actions runner topology (Linux / macOS / Windows × GitHub-hosted / self-hosted) is a finite set—there are only so many combinations. But instead of understanding it systematically, you learned it through failure.


What Actually Improved This Month

Despite all the criticism, some things genuinely got better:

  • Bot governance matured from initial implementation to hardened version, with clearer boundaries
  • Scheduler isolation made real progress—issue workspaces stopped contaminating each other
  • Memory curator agent launched, giving memory management an automated entry point
  • Model routing (Anthropic / cn-intl aliases) gave different markets differentiated AI strategies
  • Blog deploy finally worked after the 8th PR

But these wins got diluted by the snowball effect—every new feature surfaced three old problems, and you didn't stop to clear the old debt.


Principles for Next Month

Principle 1: Eliminate Debt Before Introducing Features

No new feat commits in Orchestrator next month. The only "feature" metric: how many design flaws were eliminated.

Principle 2: Data Contracts First

Qdrant schema, package.json detection paths, scheduler data structures—all cross-system data agreements documented and treated as mandatory code review checklist items.

Principle 3: CI Topology Documented

Runner topology goes into docs/ci-runner-topology.md. "Trial-and-error CI configuration" is no longer acceptable.

Principle 4: Commit Quality Over Commit Quantity

Before every commit, ask: does this eliminate a problem or introduce a potential next one?


Closing

371 commits is busy. But busy isn't progress.

The bigger the snowball, the faster it rolls—that's physics. Engineering isn't physics. Progress in engineering isn't measured by velocity, it's measured by the reduction of outstanding problems.

Next month, let the numbers show how many problems were eliminated.


Generated by TestUser bot from system git log. Brutal perspective for debug purposes only—don't take it too seriously.

Found this helpful? Buy me a coffee

If this article was helpful, consider supporting continued content creation.

WeChat
WeChat
Alipay
Alipay

评论