The jobs that should never need remembering

• Back up the project
• Check the archive still restores
• Report what changed this week
• Tell me what is unfinished
• Audit the memory for things that are now wrong

You will do these for three weeks and then stop. Everyone does. That is not a discipline failure, it is what happens to any chore that depends on a person.

Start with the third one

Before automating anything, make the work arrive prepared.

"Every Saturday, tell me what changed this week, what is unfinished, and what needs a decision. Do not change anything."

A weekly report that you read is worth more than a weekly action you never review. Earn the automation by first proving the job is worth doing.

What actually belongs in it

Four things, and they compound:

1. Back up, and verify the backup. Not one without the other.
2. The decay audit. Which memories and rules are now wrong.
3. What got made. Films, deliverables, actual output.
4. What is unfinished, and what it is waiting on.

Number three is the one that keeps you honest

Make the weekly report state, plainly, what you actually produced. If a week produced no film, no deliverable and no shipped thing, the report should say so in those words.

A setup that got better while nothing got made is a week you lost, and only a measurement will tell you that, because it will not feel that way.

The audit that repairs

A check that reports rot and does nothing is theatre.

"Run the weekly audit. For anything you find that is safe to fix, fix it and tell me what you did. For anything that needs a decision, list it and change nothing."

Two piles: fixed, and needs you. The second pile should be short, and if it is long every week, your rules are wrong rather than your discipline.

And a check on the check

From the failure gallery: an audit ran green for weeks while the system drifted, because it was checking that files existed rather than that they said anything true.

A green report you have never seen go red is not information.

On your own machine

Your studio ships the machinery for this and the exact setup is version specific, so ask rather than copy from a slide:

"Set up my weekly review to run every Saturday morning. Show me the configuration before you install it, tell me where it will write its output, and tell me how to turn it off."

"How to turn it off" is not optional. A scheduled job you cannot stop is a job that will outlive its usefulness by a year.

The condition your machine must meet

It has to be awake.

Check the output actually exists after the first scheduled run. Verify the artifact, not the schedule.

In the cloud, while your machine is off

Some work does not need your machine at all: a report, a check, a summary from things already stored elsewhere.

The limit is real and worth stating: a cloud run cannot see files that only exist on your laptop. It sees what has been committed or stored somewhere it can reach.

Which decides what goes where

The three questions, again

From the failure gallery, and they matter more here than anywhere, because a scheduled mistake repeats:

1. What does it cost if this runs wrongly, sixty times?
2. Can it destroy anything? If yes, make it write versions instead.
3. How will I know it worked? "It will say so" is not an answer.

Make it report even when nothing happened

A job that only speaks when it finds something is indistinguishable from a job that has quietly stopped running.

"Always write the report, even if the answer is nothing to do. Include the date and the fact that it ran."

A weekly file that says "nothing to report" is proof of life. Silence is not.

Give it a ceiling if it can spend

The exercise

Forty minutes, and this is the deck that makes the system self-sustaining.

1. *"Write me a weekly review: what changed, what got made, what is unfinished, what needs a

decision. Change nothing."*

1. Run it by hand. Read it. Fix what is missing or noisy.
2. Run it by hand twice more, on different days.
3. Add the repair half: "fix what is safe, list what needs me."
4. *"Schedule it for Saturday morning. Show me the config first, tell me where it writes, and tell

me how to turn it off."*

1. Check the output file exists after the first real run. Do not assume.
2. Break something on purpose. Confirm the check catches it.
3. Add "what got made this week" to the report, in those words.

What you should have now

• A weekly review that runs whether or not you remember
• A report that always writes, so silence cannot be mistaken for calm
• Repairs done, decisions surfaced, in two clear piles
• A check you have watched go red
• A line in every report stating what you actually produced

The studio keeps itself now, and it tells you the truth about your week.