Stop 9 of 9 · Weekly
Dany's quarter and the capstone
Three schedules that carry the quarter, then the graded capstone: one client from Figma to a merged pull request with its retainer routines running.
The quarter that runs itself, up to a point
Eight stops of parts. This is how Dany arranges them into a quarter that runs whether or not she has a good week, and the capstone that proves the chain on one real client.
| When | What runs unattended |
|---|---|
| Monday 07:00, weekly | The studio digest: last week's walk against the week before, open tickets by client, anything a check could not reach |
| Tuesday 06:00, weekly | The quality walk across every site in clients.csv, findings filed as tickets |
| First working day 06:00 | The report pipeline over last month's exports, twenty drafts plus the QA file |
Each one reads, checks, compares and drafts. None of them merges a pull request, publishes a Wix page, edits a live site or sends anything to a client. That is the rule the whole studio rests on, and a schedule is exactly where people let it slip.
Every Monday at 07:00, read last week's quality walk tables for every client in clients.csv and compare them with the week before. Write one page: any site that could not be reached, problems that are new this week, problems now fixed, open tickets by client with their age, and the three clients I should look at myself today with one line each on why. Do not change anything and do not contact any client.
The capstone
Take one real client through the whole chain this quarter and keep the evidence. Five artefacts: the Claude Code brief and the merged pull request with its four check results, the studio-kit entry for anything reusable the build produced, the three configured routines with one month of their output, one monthly report with its three evidenced fixes and its priced line, and the deploy log covering every change that reached the live site.
[upload the five capstone artefacts: the brief and merged pull request, the studio-kit entry, the routine output, the monthly report, the deploy log] Grade this against the rubric below, out of 100, scoring each criterion separately and naming the evidence you used. For every point not awarded, say exactly what is missing and what would earn it. Be strict about any change that reached a live site with no named human, and about any figure in the report with no rows behind it.
The rubric
| Criterion | Points | Full marks means |
|---|---|---|
| Deploy guardrail integrity | 25 | Every live change has a named human on a merged pull request or a published version, and at least one refusal is logged with its reason |
| The build is testable | 20 | Four checks wired to pull requests, all passing at merge, and the phone pass recorded at 390 pixels |
| Reuse is real | 15 | The build names the kit components it used, and anything new has a doc entry and a demo |
| The retainer machine runs | 20 | Three routines against the client list, output arriving as tickets, and one exception handled with a written reason |
| The report earns next month | 20 | Three fixes each with a number and a page, and anything out of scope priced with a date |
Eighty passes. Under eighty, the gap is almost always the same two: a change on a live site with nobody's name against it, and a recommendation with no number behind it.