; Makes data/ef/*.sexp part of the DEFAULT build target (`dune build`, no ; args), not only whatever individual stanzas elsewhere happen to declare as ; their own deps. Without this, `rm -rf _build && dune build && dune exec ; colitur -- day 2026` failed: bare `dune build` resolves to the workspace ; root's own `default` alias, which -- absent this file -- is implicitly ; bound to `@install` alone and never reaches data/ef/dune's own `default` ; alias (that alias only participates in an EXPLICIT `@default`/`@dir` ; recursive request, e.g. `dune build @default`, not in the plain no-target ; invocation; verified empirically -- see the task report). `test/dune`'s ; cram stanza masked this: it declares its own (deps ../data/ef/*.sexp), ; which materialises them as a side effect of `dune build @runtest`, so the ; test suite could not have caught this on its own -- it took a genuinely ; clean rebuild to surface it. ; ; (alias_rec install) keeps whatever `default` would otherwise resolve to ; (the package's own install artifacts -- executables, libraries, reached ; recursively through every subdirectory's own `install` alias) so this ; ADDS a requirement rather than replacing dune's own default behaviour. ; ; data/ef/lectionary.sexp added here for the identical reason (Task 4 fix ; round 1, coordinator review): `colitur day ` needs it at runtime ; (bin/main.ml's own [load_ef_lectionary]), and the same clean-build gap ; this file was originally written to close applied to it too -- a fresh ; `dune build` left it absent from _build/default/data/ef/, only ever ; materialised there as a side effect of test/dune's own deps. (alias (name default) (deps (alias_rec install) data/ef/sanctoral.sexp data/ef/adjustments.sexp data/ef/lectionary.sexp))