Concept design gives this project a clear architecture: independent concepts, explicit syncs, journaled state. But the design is an ideal, and the implementation has sharp edges. This post is the narrative form of the issue review.
The most important lesson: a list of then actions is not a transaction. If Filing.scan returns { error: "directory not found" }, the build sync still fires Building.complete, Filing.cleanOutput, and Commanding.succeed.
A build can fail to scan, read, render, or write files — and still report success. Destructive cleanup can run against an incomplete output. The sync layer needs explicit stage gates: "only proceed to the next stage if the previous stage succeeded."
See Sync Layer Issues.
The sync engine tracks which journal records have been consumed by which sync names. But the key is just the sync name — not which specific action IDs were matched.
This means a record consumed by one sync firing cannot participate in a later firing of the same sync, even with different partner records. Valid fan-out patterns can be silently skipped.
Evidence is also consumed before the then action runs. If the then action fails (throws), the evidence is gone and cannot be retried.
The fix is to store consumed match signatures: sync name + ordered action IDs, and only mark consumed after then succeeds.
See Engine Core Issues.
The dev loop has improved: public assets copy bytes safely, clean URLs receive the live-reload script, and rapid file changes are serialized through Coalescing instead of starting overlapping builds.
The remaining runtime sharp edge is startup and failure cleanup. Starting the server, watchers, and initial build still spans several effects, so partial startup failures need more explicit cleanup rules.
See Sync Layer Issues.
The model pays off in the core path. The project is readable because:
The friction log is a repair list, not a rejection.
If you are hardening the project, start here:
The full issue map starts at Issue Review.