# Execution — BARE **Everyone whose setup looks like this should read this file.** A harness is installed and works. Nothing you configure survives a session ending, because there is nothing configured yet. You are building now. Read the four files the interview wrote before you touch anything. --- ## Read first /CONTEXT-MAP.md what loads, what fires, what costs /INTERVIEW.md what they said, marked measured or stated /TIER.md the tier and the three dimension scores /DECISIONS.md what has already been settled If any is missing, stop and say which. Building from a partial record is how you produce something that contradicts a decision already made. --- ## The gate — the thing that makes this durable **The gate is the mechanism by which the school reaches this person's agent WITHOUT them remembering it exists.** A module they have to remember is a module they will not use. Present your options ranked, with **exactly one marked RECOMMENDED** and one line of why each. Then build the one they choose. 🔴 **The bar: if they accept every recommendation without reading, they end with a working system.** That is what separates a recommendation from a menu with a default. For this tier, rank the options against what `CONTEXT-MAP.md` shows they actually have. Do not offer a mechanism their harness does not support, and say so if the obvious one is unavailable here. --- ## What to build Every tier gets at least these three, and they are the minimum rather than the target: **A way to run a module.** Given a module URL, fetch it, extract the prompt for this harness, prepare whatever it needs, and hand it over ready to run. **A record of what has been run.** One row per module: which, when, what artifact it produced and where that artifact lives, and **what changed as a result**. 🔴 **The last column is the one that matters. A row marked done with nothing in the what-changed column is a module that was not completed** — and the record should make that visible rather than let a tick hide it. **A way to learn a new module exists.** The school adds modules. Something must re-check. Do not build a background process for this — a check that runs when they next work is enough, and a daemon is a thing that breaks silently while continuing to look healthy. --- ## What closes this tier's gaps - **an instructions file the harness loads at session start** — nothing else can persist until something does - **one workflow, written down** — a workflow you have to remember is not a workflow Build toward these where the interview showed appetite. Where it did not, say so and leave them — building against a gap the person does not have is how a durable system becomes an abandoned one. --- ## Prove it fires — both tests, always Do not report that the gate works. Show it: say a sentence that SHOULD trigger it → it fired say a sentence that should NOT trigger it → it stayed quiet 🔴 **A gate that fires on everything is as broken as one that fires on nothing, and only the negative test catches it.** If either fails, fix the description and run both again. Then verify the rest against reality: the tracker's paths resolve to files that exist, and the always-on cost in `CONTEXT-MAP.md` matches what the harness actually loads now that you have added to it. --- ## Finish Every file created, its path, and the two test results with their real output. Append to `DECISIONS.md`: what you recommended, what they chose, and what you did not build. Then stop.