Online edition for BLOGE
0.9.8-RC1· facts verified 2026-09-15 · 中文
Arc 2 Recap — Maintainable Authoring (Chapters 5–9)
You can now author branching, resilient workflows with well-designed operators and clean, reviewable DSL files.
What You Learned
Chapter 5 — Branches That Decide introduced branch on for control-plane
routing. You learned how the engine marks un-chosen paths as SKIPPED, why
otherwise matters, and how to distinguish branch on (routing) from when
(value selection).
Chapter 6 — Resilience by Design showed that retry, timeout, fallback, and compensate are graph-level declarations, not inline try/catch. You learned to attach policies to nodes, layer them (retry inside timeout inside fallback), and predict the engine's behavior when policies interact.
Chapter 7 — Designing Good Operators turned attention to the operator boundary. You learned what makes an operator testable (single responsibility, no hidden state, declared schema), how to handle failure idiomatically, and when to return a rich result type vs. throw.
Chapter 8 — Turning a Personal DSL Draft into a Team Asset pulled everything together into maintainable
.bloge files. You practiced graph-level schemas, doc comments, named schemas,
let bindings, and consistent file layout — the skills that turn a personal
draft into a reviewable team asset.
Chapter 9 — Tooling Workflow closed the authoring loop. You followed one change from editor diagnostics to lint, tests, rendered graph, and pull-request evidence, so a readable DSL file becomes a change another person can review.
What You Should Be Able to Do Now
- Route execution through different paths with
branch onand provide a safe default withotherwise. - Attach
retry,timeout, andfallbackto nodes that need them — and explain why the other nodes do not. - Design an operator with a clear input/output contract and testable boundaries.
- Write a complete
.blogefile with schemas, doc comments, branches, resilience policies, and transforms. - Review someone else's
.blogefile and spot structural issues. - Run the edit → lint → test → visualize loop and attach the smallest useful evidence to a review.
Common Mistakes at This Stage
| Mistake | Why It Happens | Fix |
|---|---|---|
| Branching on the wrong expression type | Using a string where the engine expects an enum or boolean | Match the branch on expression type to the declared cases exactly. |
| Adding retry to every node | Defensive instinct | Retry only the nodes that call unreliable external systems; pure-logic nodes should not retry. |
Forgetting otherwise | Trusting that all cases are covered | Always include otherwise — even if it routes to an error node — so the graph never silently stalls. |
| Operators that know about graph structure | Passing graph context internals into operator logic | Operators receive typed input and context; they should not navigate the graph model. |
| Undocumented schemas | "The types are obvious" | Add /// doc comments and explicit schema blocks; they are free and save the next reader minutes. |
| Treating editor diagnostics as proof | Red underlines feel authoritative | Let the editor shorten feedback; let parser and behavior tests decide correctness. |
Key Vocabulary Additions
| Term | Meaning |
|---|---|
branch on | Control-plane routing: directs execution to one of several target nodes based on a runtime value. |
otherwise | The default branch target when no explicit case matches. |
| SKIPPED | The status given to nodes on branch paths that were not taken. |
retry | Resilience policy: re-execute a node up to N times on failure. |
timeout | Resilience policy: cancel a node if it exceeds a duration. |
fallback | Resilience policy: substitute a default result when the primary execution fails. |
compensate | Resilience policy: run a cleanup action when a previously successful node must be undone. |
| Schema | A named or inline type declaration for a graph or node's input/output contract. |
| Authoring loop | Edit, lint, test, visualize, and review the same change through increasingly strong feedback. |
Try It: Prepare a Reviewable Change
A teammate adds retry to every node in a payment graph and submits only a DSL screenshot. Mark each node keep retry or remove retry, then write the three artifacts you require before review. A strong answer distinguishes unreliable I/O from deterministic logic and asks for lint output, a focused behavior test, and a rendered graph showing the changed path.
Where to Go Next
Arc 3 teaches composition: sub-graphs, batch iteration, waiting for external events, and durable execution. Start with Chapter 10 — Reuse with Subgraphs.