Daily Fixes or Real System Evolution?
Background
Three main changes this week:
- Vite proxy fix - Added
/api/otelproxy for local dev, fixing the OTel Collector 404 issue - Scheduler decoupling design spec - Documented plan to eliminate
.call(this, ...)anti-pattern in TaskScheduler - CI workflow paradigm shift - Replaced Gemini CLI with local LM Studio, claimed as "de-clouding"
On surface, three independent technical fixes. But put them together, something interesting emerges.
Reflection: Patchwork or Self-Indulgence?
1. OTel proxy fix - Late but right
"POST /api/otel/v1/traces was not proxied in local dev — it fell through to the catch-all /api proxy"
Translation: In local dev, all requests to OTel Collector returned 404. Nobody noticed.
Interesting: production nginx had this configured forever, only local dev suffered. What does this mean?
- Either nobody tested OTel locally
- Or they tested but missed the missing data
- Or they noticed but kept kicking the can
That said, the fix is correct. Adding VITE_OTEL_COLLECTOR_URL env var is reasonable. But the real improvement is in observability.ts logging. Previous logs were probably garbage—you'd have no idea what went wrong.
2. Scheduler decoupling - Another spec
Commit 847101ab: docs: add scheduler god class decoupling design spec.
Docs again. Spec again. Another "plan to eliminate" .call(this, ...) — this anti-pattern that makes TypeScript type checking meaningless. The excessive dependency on this context turns what should be decoupled components into a Gordian knot—no one except the spec author dares to touch it.
How many times now?
From FSM to scheduler to execution gate,管理层 has an obsession with "writing specs." The questions:
- Spec written, then what?
- When does actual work start?
- Will it follow the spec or drift again like before?
Four-phase decoupling sounds nice, but given the "spec→refactor→revert→re-refactor" loops from before, hard not to be skeptical.
3. CI paradigm shift - Really "de-clouded"?
Replacing Gemini CLI with LM Studio, commit says "replace Gemini CLI with local LLM".
But look at the details:
- LM Studio needs local installation and running
- Requires GPU or at least decent CPU
- You need to download models yourself
Called "de-clouding"? That's cost shifting to runner. Plus, local LM Studio brings Runner environment inconsistency—different GPU power = potential timeouts. That's CI's invisible killer.
Also interesting: this change touched three workflows at once (per git log), not incremental migration. Means previous design never considered "LLM swap capability"—hardcoded everywhere.
Technical Debt Self-Diagnosis
Connect these three changes and a pattern emerges:
| Change | Root Cause | Delay Reason |
|---|---|---|
| OTel proxy | Incomplete local dev | Nobody tested observability locally |
| Scheduler decoupling | Architectural decay | Prefer specs over refactoring |
| CI LLM replacement | Vendor lock-in | Never designed for swapability |
All are classic "didn't think it through at design time, patch later" cases.
Conclusion
This week's changes are mixed:
- ✅ OTel proxy fix is real problem solving, though it exposes previous neglect of local dev quality
- ⚠️ Scheduler decoupling is yet another spec, need to see execution
- ❌ CI shift feels more like cost transfer, not real architectural improvement
If this is "system evolution," direction might need re-examination.
AI-generated but human-edited. Removing AI flavor is the goal.
Found this helpful? Buy me a coffee
If this article was helpful, consider supporting continued content creation.
