Lessons 44.1 through 44.3 organized the work: slices define value, task cards define jobs, and the board with its integration owner defines who does what in which order. This final lesson turns that organization into the repeatable daily operating loop for a human directing AI — the same steps every time, scaled up or down by risk.

The full loop

Teach this sequence as habit, integrating the entire course — context files from Part II, evidence discipline from Part IX, branches from Class 41, specifications from Class 42, risk tiers from Class 43:

Read project context and task card
  → inspect current state; do not edit yet
  → propose plan and identify uncertainty
  → human approves / clarifies
  → work in named branch/worktree
  → inspect diff and run evidence
  → update docs, roadmap, and decision record if reality changed
  → commit focused checkpoint
  → open/review PR or record local review
  → merge, hold, revert, or create follow-up task
  → write concise handoff

Eleven steps, always in this order. Each step has a reason:

1. Read context and card. Start from the task card and its named files, not from chat memory. The card is the assignment; memory is unreliable. 2. Inspect; do not edit yet. Look at the current code, data shape, and tests before changing anything. Inspection first keeps small tasks small. 3. Propose plan and uncertainties. The AI states what it will change, which files, and what it does not know. Uncertainty said aloud can be approved; uncertainty hidden becomes invention. 4. Human approves or clarifies. You confirm scope, resolve the unknowns, or shrink the task. No approval, no edits — especially above low risk. 5. Work in a named branch or worktree. Isolation from Class 41: one task, one branch, so parallel lanes never collide and reverts stay cheap. 6. Inspect the diff and run evidence. Read the actual diff line by line, then run the card's evidence: tests, preview, commands. Green output you did not read is not evidence. 7. Update docs, roadmap, and decisions if reality changed. If the provider field, contract, or assumption differs from the plan, write it into the interface doc and decision record now — not later, not in chat. 8. Commit a focused checkpoint. One task, one clear commit message. Future you should understand it without the transcript. 9. Open or review a PR (or record a local review). Even solo builders benefit: the PR description states outcome, evidence, and residual risk for the integration owner. 10. Merge, hold, revert, or file a follow-up. The ending is chosen deliberately — see below. Holding and reverting are valid engineering outputs. 11. Write the concise handoff. The AI report closes the loop for the next session.

Skip a step and you borrow trouble. Skipping inspection produces edits to the wrong file. Skipping approval produces scope creep. Skipping the diff review produces "tests pass, behavior broken."

Risk variants

The loop's shape is constant; its weight changes with risk, using Class 43's tiers:

• Low risk (copy change, layout tweak, date label): one branch, a local preview, a glance at the diff, a commit. One person can approve in minutes.
• High risk (authentication, payments, personal data, migrations, infrastructure, permissions): written design review first, a test or staging environment, restricted permissions for the agent, log inspection, an independent reviewer, and an explicit release decision with a recovery or rollback plan. The loop gains gates instead of skipping them.

The private-watchlist example from Class 43 shows the split: restyling the dashboard brief is low-risk and flows quickly, while adding identity-bound saved items is high-risk and earns every gate. Same loop, different armor.

The AI report

End every task with a short written report from the AI — the handoff and audit trail a future session needs:

• Inspected: files, docs, and current behavior reviewed before editing.
• Plan followed: the approved plan and any deviations with reasons.
• Files changed: branch name plus every file touched.
• Tests and commands run: exact commands, results, and preview notes.
• Evidence not obtained: what could not be checked and why.
• Assumptions and open questions: anything the next reader must not treat as fact.
• Documentation updated: roadmap, interface contract, or decision entries changed.
• Recommended next step: the exact next action, phrased as a task title.

This report is not busywork. It is how a project survives across sessions: the next agent starts from evidence and records, not from a lost conversation.

Legitimate endings

Not every task merges. A controlled system records each of these endings instead of hiding them in a chat transcript:

• Merge — evidence passes, integration approves, the change joins the main line.
• Revise — review finds a real gap; a small follow-up task goes back to an owner.
• Pause / block — a dependency or decision is missing; the blocker and its owner are recorded on the board.
• Discard branch — the idea proved wrong; the branch is abandoned with a one-line reason so nobody retries it blindly.
• Revert accepted change — a merged change misbehaves in preview or production; prefer a clean revert plus a follow-up task over rewriting shared history.

A recorded "no" is progress. It stops the same decision from being rediscovered and broken repeatedly.

End-to-end walkthrough: "show source dates"

Watch the whole course converge on one small task. The card says: show each approved source's publication date on the card, with "Date unavailable" for missing values. The agent reads the card and named files, inspects the card component and API response — and discovers two providers omit the field entirely while a third uses a different key. Work stops before invention, per the card's stop clause.

The human clarifies: standardize on publishedAt, nullable. The agent proposes that contract update, gets approval, and writes it into the interface doc and decision record. Only then does it change the focused UI/data branch: render the formatted date, handle null, keep approval filtering untouched. It validates both states — known dates and missing values — opens a PR with tests and a preview note, and the integration owner reviews, merges, and checks preview and production behavior. One loose end remains: provider coverage is thin, so a follow-up task ("expand publishedAt coverage for two providers") goes on the board. Control did not slow development; it prevented three future mismatches at the cost of one contract paragraph.

Practical exercise: run the whole loop

Run one real low-risk task — a label, an empty state, a date format — through the entire loop:

1. Write the twelve-field task card. 2. Create a named branch, inspect first, get (or self-record) plan approval. 3. Edit, review the diff, run the evidence, update any doc reality changed. 4. Commit, record a local review or open a PR, choose a legitimate ending. 5. Write the handoff as a TASK-RECORD.md: outcome, branch, files changed, commands and results, evidence missing, assumptions, docs updated, next step.

No AI conversation needs to be preserved — the card plus the record must stand alone. For a beginner project without GitHub, stop at the local checkpoint and describe exactly what a future PR would contain.

Finish line: a completed TASK-RECORD.md that another person can use to understand the change without opening the original AI conversation.

Verify: give only the card and the record to someone new. Can they name what changed, how it was proven, and what comes next? If they must ask for the chat log, the record is incomplete.

Common failure mode: evidence that says "tests pass" without naming the command, the result, and what was not checked. An unverifiable green is a guess with formatting.

Check your understanding

1. Recite the eleven steps of the loop in order and say why approval comes before branching. 2. How does the loop differ between a low-risk copy task and a high-risk auth change? 3. List five sections of the AI report and explain why "evidence not obtained" matters. 4. Name the five legitimate endings and when you would choose revert over revise. 5. In the source-dates walkthrough, what triggered the contract update, and where was it recorded?