Stop 10 of 10 · Weekly
Dany's capstone
Three schedules that run the studio's tools without anyone watching, then the graded capstone: one tool you built, with tests, guardrails, an evaluation score and a cost line, out of a hundred.
Three schedules, and the row that proves they ran
Everything here runs without Dany. That only works if absence is visible.
| Schedule | When | Writes |
|---|---|---|
| Nightly checker | 02:00 | Check rows, findings, severity 1 and 2 tickets |
| Evaluation run | Sunday night, and every pull request | A score, and the failing cases with their axes |
| Usage report | Monday 07:00 | Spend by tool and client, cost per acted-on output |
Each writes a start row and a finish row to a runs table. A fourth job, four lines long, reports any schedule with a start and no finish, or no start at all. That job is the only one that mails Dany.
Add a runs table to my studio database: id, schedule name, started_at, finished_at, exit status, and a short note. Then write scripts/schedule-health.mjs. It reports any schedule with a start row and no finish row, any with no start row inside its expected interval, and any whose last three runs all failed. Take the intervals from a config object at the top of the file. Print nothing when everything is healthy, so it is safe to run from cron with mail on output.
The capstone
One tool of your choosing that your studio would miss. Not one of the six from this course: something your own week needs. It ships with five things and is graded out of a hundred.
The tool itself, in a repository with a readme. Its tests, on node --test against fixtures. Its writes, through the guard module or none at all. Thirty evaluation cases with a gate. And its line in the usage report.
[upload the capstone repository as a zip or paste the file tree with the readme, the guard usage, one module, its tests, the eval cases and the last usage report line] I am the studio owner and I built this. Grade it against the rubric below, out of 100, scoring each criterion separately and quoting the file and line you used as evidence. For every point not awarded, say what is missing and the smallest change that would earn it. Be strict about three things: any write that reaches a client system, a credential anywhere in the tree or the log, and any evaluation case whose expected answer looks written after the first run rather than before it.
The rubric
| Criterion | Points | Full marks means |
|---|---|---|
| Keys and client data | Gate | No credential, customer record or API key in the repository, a chat or a log. A breach fails the capstone whatever else scored |
| Tests you could hand to Mo | 20 | Every module has a test on node --test, running against fixtures rather than live systems, and the suite fails when you break the module on purpose |
| Guarded writes | 20 | Every write goes through guard, one allowlist entry per action, dry run by default, approval where the allowlist says, and a chained log |
| Measured, not assumed | 20 | Thirty frozen cases, expected answers written before the first run, three axes scored separately, a gate in the pull request, and one change the gate caught |
| Runs unattended | 15 | Scheduled, retries and backs off correctly, writes start and finish rows, and its silence is reported by something else |
| Deletable | 15 | A readme saying what it is for, what it must never do, what it costs per acted-on output, and what breaks if you delete it |
| Costs known | 10 | Every call carries a tool and a client, rates come from a dated file, and you can say the cost per acted-on output out loud |
Eighty passes. Under eighty it is nearly always the same two: tests that call a live system, and cases written after the outputs they grade.