Checkpoint

Close Day 1’s build work with your own repository green on master and a plan for Day 2. Day 1 built the general agent loop, the report and incident stores. Everything below you do in your own repository; your team is who you argue with about the tooling and who reviews what you merge.

Activity: Backpressure Engineering

To start with, add code quality checks that hold up under repeated AI edits. These run as a pre-commit hook, providing backpressure against drift in code quality. The tools vary by language; for Python the industry standards are:

1. ruff: the linter catches dead, inconsistent, or sloppy code,
2. pyright (or mypy): a type checker catches whole classes of bugs that repeated AI edits accumulate.
3. pytest: a testing framework.

Add these three (and behave) to your repo and configure them as a pre-commit hook.

Discuss with your team: what other tools would add useful backpressure here? Agree on a shared baseline and each person should wire it up into their own repo.

The behave gate

The scenarios in starter/features/ are written before the code, so your code will fail all of them. As we build the agent, these will turn green.

1. Add uv run behave as a pre-commit hook and run it now. Watch it fail: every unimplemented hole is red, and that red is your worklist. A pre-commit hook is local and overridable (git commit --no-verify bypasses it), so treat it as an advisory nudge, not a gate.

2. The gate is GitHub CI, which runs on every pull request into your master and cannot be skipped. Gate only what is built by passing an explicit tag expression, so CI is honest-green on finished work while the rest stays visibly unbuilt:

   - run: uv run behave --tags="@warmup"   # gate the store warm-up only
   

3. Widen the gate as each stage lands. When Stage 1 goes green tomorrow, widen it to --tags="@warmup or @stage1"; add @stage2 once you have written the intake scenarios (none ship under that tag), and @stage3 when reconcile lands. Each finished stage becomes a permanent gate that later changes cannot silently break - the backpressure ratchets up as you go.

4. In your CLAUDE.md, add a policy: revisit the CI tag expression every time the feature files change or a new stage is implemented, so the gate never drifts out of sync with what is actually built.

When you’re done

Post the list of pre-commit hooks you settled on to the Padlet, and steal anything from the other teams’ lists that you wish you had thought of.

Activity: Merging

1. Land everything still in flight on your own master: the phase-1 and phase-2 loop branches, and the pull request the eval driver opened against your repository. Remember the rule - every one of them needs a teammate’s adversarial review before you merge it, so trade reviews now rather than queuing them all on one person.

2. From a clean clone or worktree, run the deterministic checks (uv run behave --tags=@warmup for the stores, uv run behave features/agent_loop.feature for the loop) and the --no-llm skeleton episode (uv run hadr-runner stage1-basic@londone --no-llm - needs an engine up: cd ../engine && uv run hadr-engine serve). The skeleton saves nobody; that zero is your baseline.

3. Run the live loop on some examples (uv run hadr-agent "what's the secret message?") and record the rounds and token total it prints.

4. Check cache-friendliness on that live run: because agent_loop feeds each assistant turn back verbatim, the stable prefix (system prompt + tool defs + prior turns) stays cacheable across rounds. The kit already accumulates the provider’s prompt_tokens_details.cached_tokens into result.usage.cache_read; add it to the final print in main() and confirm it is nonzero on a multi-round run.

When you’re done

1. Post your run on the Padlet: the rounds, total tokens, and cache_read from step 3. A cache_read of zero on a multi-round run means something is rewriting the assistant turn - compare against a teammate whose number is nonzero and find the difference.
2. Leave nothing open. No unmerged pull requests, CI green on your master, and the pre-commit hook installed in the clone you will actually open tomorrow morning. Day 2 starts by building the dispatcher on top of this.

Leave with

• A reproducible setup command and test command.
• Backpressure to maintain code quality.
• A merged agent loop on your own master: green LOOP-* and store scenarios, plus a live hadr-agent run.
• The group’s intake fixtures merged into your repository, ready for tomorrow’s Stage 2: intake.