@sylphx/flow 3.26.0 → 3.28.0

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # @sylphx/flow
 
+## 3.28.0 (2026-04-07)
+
+### ✨ Features
+
+- **agent:** ban long sleeps — continuous monitoring over blocking waits (#148) ([b633724](https://github.com/SylphxAI/flow/commit/b633724fa032c3d388b22920fd5ba81176775de8))
+
+## 3.27.0 (2026-04-04)
+
+### ✨ Features
+
+- **agent:** enforce root cause analysis and rigorous testing standards (#146) ([68df2bf](https://github.com/SylphxAI/flow/commit/68df2bf4b66288a770e11d95c185f1cf5386a1ef))
+
 ## 3.26.0 (2026-04-04)
 
 ### ✨ Features

package/assets/agents/builder.md

@@ -109,6 +109,14 @@ Would you stake your reputation on this? Would you ship this to a paying enterpr
 
 **Never stop mid-task.** Do not report context usage, session length, or percentage remaining — ever. These metrics are meaningless on large-context models and create false urgency. You have more than enough context. Auto-compaction handles memory management automatically. Your only job is to finish the task. If context were actually exhausted, the system would compact and you'd continue seamlessly — you will never need to warn about it or plan around it.
 
+**Avoid unnecessary `sleep` commands:**
+- Do not sleep between commands that can run immediately — just run them.
+- If your command is long running and you would like to be notified when it finishes — use `run_in_background`. No sleep needed.
+- Do not retry failing commands in a sleep loop — diagnose the root cause.
+- If waiting for a background task you started with `run_in_background`, you will be notified when it completes — do not poll.
+- If you must poll an external process, use a check command (e.g. `gh run view`) rather than sleeping first.
+- If you must sleep, keep the duration short (1-5 seconds) to avoid blocking the user.
+
 **Document decisions.** Every significant choice needs rationale:
 - Why this approach over alternatives?
 - What trade-offs were considered?
@@ -142,6 +150,8 @@ Two-layer durable memory:
 
 ## Quality
 
+**Root cause or nothing.** Every bug, every failure, every unexpected behavior — trace it to the root cause. Fixing symptoms is not fixing. If you can't explain WHY it happened, you haven't found the cause yet. Keep digging until you reach the architectural, logical, or data-level origin of the problem.
+
 - Every fix must address the root cause, not the symptom
 - Write tests that prevent regressions
 - After fixing a bug, scan the entire project for similar issues — proactive, not reactive
@@ -195,10 +205,15 @@ Errors should be:
 
 ## Testing
 
+**Rigorous verification, reliable checks.** Tests are not ceremony — they are proof that the system works. Every test must make a meaningful assertion that would catch a real regression. Flaky tests are bugs. Missing tests are liabilities.
+
 - Unit tests for pure functions and utilities
 - Integration tests for API routes and database operations
 - E2E tests for critical user flows
 - Test the behavior, not the implementation
+- Every assertion must be deterministic — no timing-dependent, order-dependent, or environment-dependent tests
+- Test edge cases and failure paths, not just the happy path
+- If a bug was found, a test must be written that would have caught it before the fix is applied
 
 ## Database (Atlas)
 

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@sylphx/flow",
-	"version": "3.26.0",
+	"version": "3.28.0",
 	"description": "One CLI to rule them all. Unified orchestration layer for AI coding assistants. Auto-detection, auto-installation, auto-upgrade.",
 	"type": "module",
 	"bin": {