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.
Filing, Serving, and Publishing all join path components directly. A content file with ../../etc/passwd in its route, or a CLI invocation with --output ., can escape the intended root directory.
This is a demo with trusted inputs, so the risk is theoretical. But the fix is not concept-specific — it requires path resolution, escape detection, and output root validation in every concept that touches the filesystem.
See Filesystem 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.