v0.5.0 release notes

v0.5.0 makes the setup of a job as durable as its execution. Two changes: every job now writes its deliverables into its own named folder instead of a shared directory, and recurring work codifies into Job Templates — the Leader’s own self-authored interview, parameter schema, and output contract for a whole class of job.

This is the Alfred loop reaching the other half of the work. v0.4.0 codified recurring failures — the defects QC kept rejecting — into skills. v0.5.0 codifies recurring setup — the questions you keep answering, the jobs you keep re-running — into templates. Generation learns; now setup learns too.

Every job gets its own folder

Before, the lead’s finished .docx deliverables all landed flat in ~/Documents/Modulatio/<project>/, so a new run’s products sat beside — and could overwrite — the last run’s. Now each job gets its own subfolder, named from the job and the date (Weekly competitor brief 20260601), with a short hex suffix added only if two same-named jobs land on the same day. The Product Quality Report ships inside the same folder, so each run is a self-contained package you can hand off or archive whole.

Nothing migrates and nothing breaks: a job with no name still resolves to the same flat path it used before, byte-for-byte. And because the folder name can originate from model output, the slug is path-traversal-safe — separators, leading dots, and bidi/control characters are stripped before it ever touches the filesystem.

Job Templates: setup that sticks

A Job Template is the Leader’s own script for a kind of job it has done before — its interview (the questions worth asking before planning), its parameter schema (what those answers are, and which are required), and its output contract (what the job produces, and in what shape).

It is domain-agnostic by design. A single research report, an anthology of N stories, a per-competitor brief over a list of companies are all the same primitive — the engine reads no job “type,” only a generic output cardinality (one, per-item, fixed:N). If a feature ever needed to know whether a job was “an anthology” or “a brief,” that would be the wrong design — the same discipline that keeps the engine free of fixed roles.

Templates live in a git-versioned library, the same machinery the skill library uses, with a name-dedup guard so you never get two templates fighting over one name. They resolve project-local first, then shared, then the seeds Modulatio ships.

The output contract is engine-enforced

Here is the sharp part. The planner batches small items together for efficiency — which is good, right up until a template says “one finished piece per item” over a twelve-item list, where batching would silently collapse twelve deliverables into three. You cannot reliably beat one prompt heuristic with another sentence; an LLM under token pressure regresses to batching.

So the engine binds the cardinality deterministically. It computes N from the bound parameters before planning, injects a non-negotiable “emit exactly N separate deliverables” directive that overrides the batching rule, and then post-validates that the plan actually produces N. A shortfall is reported firmly in the Product Quality Report rather than shipped quietly. (An empty list is a setup error, caught at bind time — never a silently empty job.) This logic is pure counting: it has no idea whether the N things are stories, briefs, or modules, and it does not need to.

A scheduled job is a bound template

A Job Template on its own is unbound — a schema waiting for answers. Bind it to a concrete answer set and it becomes runnable with no further questions: a payload a machine can dispatch. That is exactly what a cron job is.

modulatio cron add --name weekly-brief --schedule "weekly mon 09:00" \
  --code ACME --jt competitor-brief \
  --jt-params '{"competitors": ["Northwind", "Globex", "Initech"]}'

cron add validates the bound parameters against the template’s schema when you add it — so a misconfigured schedule fails at your keyboard, not at 3am in the daemon — and then runs headless on its timer, skipping the interview entirely. Existing crons with no template attached run exactly as before.

The team notices when you keep doing the same thing

The execution-side Alfred loop watches QC fail-verdicts. The setup-side loop watches job history. At the end of a run, the Leader reviews recent jobs, and when it sees the same kind of job recur — roughly three of a kind — or an operator redo (you re-ran a job because the first result missed), it judges whether that pattern is worth a template. The engine binds the trigger (a cheap model will never volunteer to template its own work, so the engine deterministically creates the “consider templating” moment); the Leader makes the judgment — create, improve, or leave it. A redo is the setup-side equivalent of a QC fail-verdict: a signal the setup wasn’t right the first time.

One invariant the engine enforces hard, because getting it wrong is catastrophic: a self-improvement to a template can never add a new required parameter without a default. A bound cron that was complete yesterday must stay complete after the template improves under it — otherwise a learned “improvement” would silently break a 3am job. Codification is best-effort, git-committed, and revertible, and you can turn it off with MODULATIO_JT_CODIFICATION=0.

What it means for you

The work you do once stays a one-off; the work you do repeatedly gets easier every time. The first weekly brief is an interview; the tenth is a button. Modulatio learns not just how to fix its mistakes (v0.4.0) but how you like your jobs set up — and the two loops compound: cheaper generation that improves itself, over a setup that codifies itself, each run dropping its products in its own tidy folder.

For the full engine contract and the honest ceilings, the Beta calibration page remains the source of truth. The CHANGELOG has the precise commit-level delta.