AI Engineering Practice: ship and maintain AI-built software

Copy this, open Claude, paste it, and Claude will walk you through the lesson step by step.

For a grown-up: Claude is for adults (18+). Copy this, paste it into Claude, and use the answer to explain the lesson to your child.

I'm learning "AI Engineering Practice: ship and maintain AI-built software" on The Future Market. Lesson 1: "Engineering standards: say it once, enforce it where it counts".

What the lesson teaches:
- Anthropic's Claude Code best-practices page splits instructions in two kinds. Guidance (your prompt, CLAUDE.md, skills) is read by the model, which "usually follows" it but is not forced to. Enforced rules (hooks, permission rules, managed settings, tests, CI) are applied by Claude Code or by your pipeline and do not depend on the model's choice.
- The docs' advice: if you keep adding emphasis to a CLAUDE.md line and Claude still misses it, the line belongs in a hook. The reverse holds too: if you have hooks for things that are only preferences, delete them and let Claude decide.
- CLAUDE.md loads into every session, so each line costs a little attention on every task. Keep it for what Claude cannot work out from the code: the exact test, typecheck and lint commands, decisions that are not in the repo, and gotchas. Personal preferences go in CLAUDE.local.md, which you add to .gitignore.
- Claude Code reads settings from several places. The scope decides who a setting affects: user (~/.claude/settings.json, you in every project), shared project (.claude/settings.json, everyone in the repo if committed), project local (.claude/settings.local.json, you in one project) and managed (set by an organization; nothing in your own files overrides it).
- Precedence, highest first: managed settings, command-line --settings, project local, shared project, user. List settings such as permissions.allow merge across files instead of replacing each other.
- Some keys never take effect from a file committed in the repo, and some, such as allow rules, wait until each teammate trusts the folder. deny and ask rules apply right away. Run /status to see which settings sources are loaded.
- Standards are only useful if people can find and use them. Write one short engineering standards file (we call it ENGINEERING.md in this course) and link to it from CLAUDE.md.

The exercise I'm working on:
Write your team's rule list (at least ten rules), sort it into guidance and enforced, and create the files that hold each. Then write ENGINEERING.md on one page.

I'm stuck. Please:
1. Explain the main idea in plain, simple words with one everyday example.
2. Walk me through the exercise one small step at a time. Ask me what I've done so far before giving the next step.
3. Don't just give me the final answer. Help me do it myself, and check my work when I share it.

I'm a parent helping my child (about 8 years old) with a lesson called "Engineering standards: say it once, enforce it where it counts" from the course "AI Engineering Practice: ship and maintain AI-built software".

Here's what the lesson says:
A restaurant kitchen has a few rules on the wall ("wash hands") and a few rules built into the equipment (the oven turns off if the door opens). A wall poster can be forgotten. A built-in lock cannot. Good engineering standards use both, and they know which rule belongs where.

The activity:
Write your team's rule list (at least ten rules), sort it into guidance and enforced, and create the files that hold each. Then write ENGINEERING.md on one page.

Please explain this so an 8-year-old understands: short sentences, a fun everyday example, and no hard words.
Then give me 3 simple questions I can ask my child to check they understood, and a way to do the activity together, one tiny step at a time.