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.

Begin with the threshold defect. A total exactly equal to the caller's limit must require review. The initial implementation uses a strict comparison and gets equality wrong. This is deliberately easy to understand so you can spend attention on the surrounding system: what the worker sees, what it may change, how its result is checked and what survives interruption.

The product then grows. Buyers import policy revisions, inspect matching passages and return to earlier reading. Engineers use failed checks to repair the workbench. A graph makes the review and repair decisions visible. Finally, a procurement flow joins current order evidence with a proposal-bound approval and records the matching service receipt.

Read this diagram as product evolution, not a claim that 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.

Keep the artifacts that explain your next step

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

Start with the failure, then inspect the solution

For a project, read the customer behavior and acceptance cases first. Run the supplied failing baseline where one exists. Write down why it fails before opening the reference implementation. Then make a change and rerun the same checks plus the changed-input case.

The Premium companion now includes build_checks.py start, which creates a learner-owned controller.py with three incomplete functions. They control verification joins, failure routing and approval. Each stage has behavioral checks; the initial starter fails intentionally. 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 uses the companion so it can provide a complete tested reference, starter and persistent local application together.

Use persistent state when continuity is the lesson

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. Starting a new directory creates another experiment, which is useful for rejection and expiry cases but does not demonstrate recovery of the first one.

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.

That desk is a retrieval workbench with synthetic local identity. It does not claim to answer arbitrary questions semantically or authenticate real customers. The distinction makes the next integration job visible: connect trusted identity, a real source system and a model adapter only after their contracts are defined and tested.

Separate stores make the boundaries inspectable. 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.

Choose a route through the detailed material

Follow the syllabus for a first pass. 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. Read them as design studies and porting guides, not as claims that the course ran 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. In both cases, return to the other path before the capstone so you can explain why a passing patch and an authorized business effect require different evidence.

Know 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 why a specific check or feedback path changes the outcome of the recorded fixture. They do not rank live models. Model calls and model charges are zero in that experiment; machine time still exists, and a live comparison must 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 insufficient unless the underlying history survives reopening and retains 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