Follow the project from one defect to an operating workbench

TL;DR: Build the course as a sequence of changes to Northstar's purchasing workbench. Keep the candidate, policy state, failure evidence and review decisions between milestones so each new mechanism solves a problem you have already observed.

Where you are. You have seen the minimal harness. This map explains what the later projects add, where their working state lives and how to use the starter and reference implementations without mistaking reproduction for independent work.

One customer, two kinds of work

Northstar's buyers need to understand purchasing policy and prepare a quantity amendment. Its engineers need to maintain the application that supports those buyers. The coding worker changes source; the procurement workflow changes a business record. They can share context, verification and recovery mechanisms while keeping different permissions and acceptance criteria.

The course begins with the threshold defect. A total exactly equal to the caller's limit must require review, but the initial implementation uses a strict comparison and gets equality wrong. The defect is deliberately simple, so your attention can go to the system around it: what the worker sees, what it may change, how its result is checked and what survives an interruption.

From there the product grows. Buyers import policy revisions, inspect matching passages and return to earlier reading, while engineers use failed checks to repair the workbench. A graph then makes the review and repair decisions visible. Finally, a procurement flow combines current order evidence with an approval bound to a specific proposal, and records the matching service receipt.

The diagram shows how the product evolves. It does not mean every earlier lab.py command modifies one shared directory; some commands are small, disposable demonstrations. The persistent coding graph and policy desk introduced below supply the continuing workspaces; the milestone table tells you which artifacts to carry forward.

Artifacts to carry between milestones

Keep a small task registry alongside your work. Each row should name the requirement, the allowed outputs, the acceptance command, the status and the last verified revision. A bare “done” with no candidate identity cannot tell the next session whether a later edit invalidated the result.

Failure first, then the solution

For each project, read the customer behavior and acceptance cases first. Where a failing baseline is supplied, run it and write down why it fails before you open the reference implementation. Then make your change and rerun the same checks, plus the changed-input case.

The Premium companion includes build_checks.py start, which creates a controller.py for you to complete. Its three unfinished functions control verification joins, failure routing and approval. Each stage has behavioral checks, and the starter fails them on purpose until you fill it in. The complete implementation is separate in graph_policy.py, with the reasoning in the coding-graph lesson and BUILD.md.

Public and free-account lessons retain their self-contained examples. You do not need the paid source download to complete the early exercises or understand the architecture. The later build path relies on the companion because it supplies a tested reference, a starter and a persistent local application together.

Persistent state for the continuity exercises

The coding graph stores its candidate snapshot, phase, attempts, diagnostics and approval request in a SQLite file under the state directory you choose. Run the same directory again to resume. Pointing it at a new directory starts a separate experiment. That is useful for rejection and expiry cases, but it does not demonstrate recovery of the first run.

The policy desk uses separate index and history databases under its state directory. Its browser interface supports importing text, opening policy details, searching for matching authorized extracts, copying a passage and associating a follow-up with an earlier result. Restarting the process preserves that history. Importing a new policy revision marks old evidence stale and withholds the old passages from the history response.

The desk is a retrieval workbench with a synthetic local identity. It does not answer arbitrary questions semantically, and it does not authenticate real customers. Stating that plainly shows what the next integration job is: connect trusted identity, a real source system and a model adapter, but only after their contracts are defined and tested.

Keeping the stores separate makes the boundaries easy to inspect. A reading-history row is neither a buyer approval nor a service receipt. The domain graph continues to own the exact amendment and effect recovery.

Routes through the material

On a first pass, follow the syllabus. The workspace and tool modules teach what a worker can discover and execute. The context module prepares authorized evidence. Continuity and verification explain how to recover and assess work. Loops and graphs then combine those mechanisms.

The runtime-design module gives four architectural case studies: repository-centered development, lifecycle hooks and specialists, session-tree context construction, and replaceable services with event replay. Their October field notes connect those designs to current products. Treat them as design studies and porting guides; the course did not run every vendor integration.

If your immediate job is coding automation, concentrate on the workspace, repair and coding-graph artifacts. If it is a customer operations assistant, keep the policy desk and procurement graph visible throughout. Either way, come back to the other path before the capstone, so that you can explain why a passing patch and an authorized business effect need different evidence.

What the experiments establish

The companion's experiment.py executes three controller variants from the same broken source and budget. One checks only the familiar threshold. One uses both thresholds and consumes feedback. One repeats a failed proposal. A fresh limit provides a separate confirmation case.

Those runs show how a specific check or feedback path changes the outcome on the recorded fixture. They do not rank live models. The experiment makes no model calls and incurs no model charges, though it still uses machine time; a live comparison has to measure its own attempts, usage and missing outcomes.

Do this before moving on

Deliverable: create a milestone ledger with one row for each artifact in the table. Mark the first observed failure, the next behavior you will add and the exact evidence needed to call that behavior working. Leave unrun checks as unrun.

Worked review. A useful first row says that the equality case fails in the initial source, identifies the contract and names both threshold checks. A weak row says “build a reliable agent” and has no observable result. Later, the history row must demonstrate a process restart; an in-memory list that survives only a browser interaction cannot satisfy it.

Change the input. The buyer now works across midnight and follows up on yesterday's policy result. Add a persisted parent identity and an explicit date-grouping rule. A new heading in the browser is not enough on its own; the underlying history must survive reopening and keep the right relationship.

Go deeper

• Workspace project: Create the repository contract consumed by the later coding task.
• Evidence pipeline project: Carry source revisions and authorization into the persistent workbench.
• Coding graph project: Build the learner controller and inspect its actual transition ledger.
• Capstone: Apply the accumulated artifacts to a changed customer brief.
• Agent memory: Separate conversational history from authoritative application state.

Key takeaways

• Carry artifacts and failed evidence between milestones, not just completion marks.
• Use persistent directories for recovery exercises and fresh directories for comparisons.
• Treat the reference as an inspectable solution after attempting the contract.

Check yourself

Answer before you look. Recalling it is what makes it stick; recognising it does not.

1. 1Which demonstrates continuity: starting a new fixture successfully or reopening the previous state directory?

   Answer it, then reveal

2. 2Why is a matching policy passage not an approval to amend an order?

   Answer it, then reveal