Diagnostic — Her CI Migration As Baseline

Learning objective

(Bloom's: Analyze) Analyze your team's actual failing CI run, review-checklist.md, and your current backlog well enough to state, in checkable terms, where your specification, verification, and delegation habits stand right now — establishing your starting point on AIHC.2.A1 (Specification), AIHC.2.B1 (Verification), and AIHC.1.D1 (Orchestration). This lesson does not teach new moves; it measures the ones you already have, on your own work, so the next five lessons can fade scaffolding correctly instead of guessing.

Work at hand: you're migrating payments-service's brittle CI-review pipeline into an agent-assisted workflow — subagents doing first-pass review, you as verifier. Right now, CI is red and review-checklist.md is a list you paste into every PR and check by hand. Nothing here is hypothetical; it's this morning's build.

SSD cycle 1 — what does "specified" actually mean on this repo, today

• SAY: A specification isn't a description — it's something a second reader can check without asking you a follow-up question. Before this lesson teaches you anything about writing sharper specs, it needs to know: which of your existing artifacts are already checkable, and which only look that way.
• SEE: Your repo's actual failing run, as CI reported it — $ pytest tests/payments -q ... F ======================= FAILURES ======================= _______________ test_calculate_fee_rounds_half_up _______________ assert calculate_fee(Decimal("50.25")) == Decimal("1.01") AssertionError: assert Decimal('1.0') == Decimal('1.01') 1 failed, 14 passed in 0.42s Error: Process completed with exit code 1. Next to it, your review-checklist.md item 1, verbatim: "Payment/fee math uses Decimal, not float; rounding mode stated in a comment." One of these two things is a specification you can check against (the failing assertion). One is a rule your team has agreed on but has never mechanically enforced against this exact file. (Ground truth: this is your own CI output and your own checklist — nothing here is drawn from the doc-set; the diagnostic reads your artifacts, it doesn't yet teach a doc-set mechanism.)
• DO: Open review-checklist.md. Next to each of its 6 items, write one word: CHECKABLE (a machine or a second reader could verify it without asking you) or VIBE (it depends on what you personally noticed). No scoring yet — just sort. This sort is the raw material lesson 2 will turn into contracts.

SSD cycle 2 — do you verify, or do you trust the color of the CI badge

• SAY: AIHC.2.B1 asks whether you verify against sources or against confidence. Today, before any subagent is in the loop at all: when payments-service's CI goes green, what do you actually check before you merge — the diff, the test names, or just that the badge turned green?
• SEE: A transcript-style self-audit prompt (yours to answer honestly, not graded against anything but your own next answer): Last three PRs you merged on payments-service: PR #241 — CI green. Did you open the diff? [yes/no] PR #238 — CI green. Did you re-run tests locally? [yes/no] PR #235 — CI green. Did you check what changed vs. what the ticket asked for? [yes/no]
• DO: Answer the three lines above from memory, honestly, for real recent work (or your best real estimate if you don't recall exactly). Then write one sentence: "Right now I verify by ______." This sentence is your AIHC.2.B1 baseline — the next verification lesson (lesson 5) will hold it against what "verify against the contract's own checks" actually requires.

SSD cycle 3 — what would you hand off, before any framework tells you how

• SAY: AIHC.1.D1 (Orchestration) starts at band 1 for you because you've never split work across an agent team — you've used Claude Code solo. That's not a deficit to fix by reading more; it's a starting point to measure honestly, the same way you wouldn't skip a diagnostic on a new codebase just because you're a strong engineer elsewhere.
• SEE: Your current backlog, as six lines pulled straight from review-checklist.md plus the CI failure — no framework applied yet, just the list: 1. Fix calculate_fee() rounding bug (the failing test above) 2. Check new endpoint diffs against docs/api-contract.md 3. Review the pending ledger-table migration 4. Scrub logs for PII before next release 5. Confirm ledger writes are idempotent + have a rollback plan 6. Grep the diff for stray secrets
• DO: Next to each of the 6 items, write ME or SOMEONE/SOMETHING ELSE — your gut call, right now, with no reversibility/blast-radius framework yet (that framework is lesson 3). This gut-call list is the exact artifact lesson 3 will place on a 2×2 and check against a real criterion — so today's calls, right or wrong, are the baseline, not a grade.

SSD cycle 4 — naming the gap out loud

• SAY: A diagnostic that doesn't produce a named gap wasn't a diagnostic, it was busywork. Look at your three answers (cycles 1–3) together: where they disagree with what you'd want a reviewer at your level to be able to say, that disagreement is the content of lessons 2–6.
• SEE: A simple three-row summary table, populated with what YOU just wrote (not a model answer — there isn't one yet):

• DO: Circle the ONE row where your own answer surprised you most. Write one sentence on why. That sentence becomes this lesson's journal prompt seed (below) — it's the thing lesson 2 opens by addressing directly, on the same calculate_fee() bug, the same checklist, the same repo. (Like scouting your own team before opening day: you don't skip it just because you know the roster — you write down what you actually see them do, not what you assume.)

Independent at-bat

No new at-bat today — the four cycles above are the at-bat. Nothing in this lesson was demonstrated to you first; every DO was you looking at your own artifacts cold. That's deliberate: a diagnostic that shows you the "right" sort before asking you to sort isn't measuring your baseline, it's coaching your answer.

Exit ticket

(Graded against your own cycle answers above and your artifacts — never against a model answer, since a diagnostic has none. "Correct" here means internally consistent and specific, not matching a key.)

1. (Remember) Which of review-checklist.md's 6 items did you mark CHECKABLE, and which VIBE?
2. (Understand) In one sentence: why is "CI turned green" not the same claim as "I verified the diff"?
3. (Analyze) Look at your cycle-3 ME/OTHER list. Pick the one item you marked "someone/ something else" that you're least sure about — what made that one uncertain, specifically?
4. (Analyze) Compare your cycle-1 sort to your profile's AIHC.2.A1 starting mastery (0.55). Does your own sort suggest that number is about right, too high, or too low — and why?
5. (Evaluate) Of the three anchors this lesson measured, which one, if it doesn't improve in the next five lessons, would hurt this migration the most? Defend the choice in 1–2 sentences using your own backlog as evidence.

ledger_write

ledger_write:
  learner_id: L1-DEV-MAYA
  lesson_id: L1-dev-maya-01-diagnostic
  anchors: [AIHC.2.A1, AIHC.2.B1, AIHC.1.D1]
  bloom_reached: Analyze
  exit_ticket_score: ""
  auto_score: ""
  self_score: ""
  calibration_gap: " — computed once Maya's self_score exists"
  starting_mastery:
    AIHC.2.A1: 0.55
    AIHC.2.B1: 0.40
    AIHC.1.D1: 0.30
  journal_prompt: >
    Which of the three anchor rows surprised you most when you actually looked at your own
    work instead of your instinct about your own work — and what's one guess about why?
  structure_used: PBL
  referents_used: [baseball-mets]
  next_lesson_seed: >
    Lesson 2 opens on the same calculate_fee() failure and the same review-checklist.md,
    turning today's CHECKABLE/VIBE sort into contract-spec elements for a real delegation.

RUBRIC SELF-AUDIT (against exemplars-and-rubrics/developers/Exemplar_and_Rigor_Rubric_ClaudeCode_x_AIAgents_2026-07-19_v01_I.md)

Escalation: all load-bearing indicators PASS → auto-ships per the cell's versioned escalation policy (Playbook §5, AIHC X2/B3).