# Session handoff

Update this at the end of every session. Keep it to what the next session can't
infer from `progress.md` + `feature_list.json`.

## State at last handoff
- Harness fully scaffolded: `AGENTS.md`, `feature_list.json`, `init.sh`,
  `verify_crm_automation.py`, `samples/good/*` (6), `samples/bad/*` (6),
  `progress.md`, `session-handoff.md`, `playbooks/` (9 files).
- `./init.sh` verified green: every good sample passes, every bad sample fails,
  on every one of the 6 rubric'd deliverable types.
- No real deliverable has been produced into `workspace/` yet — all 6 features
  are `status: "todo"`.

## What the next session should do first
1. Read `progress.md`, then `feature_list.json`.
2. Run `./init.sh` — expect PASS (exit 0). If it fails, the gate itself broke;
   fix that before touching any feature.
3. Pick a feature with no unmet dependencies (everything except `journey-map`
   qualifies) and produce a real deliverable.

## Gotchas / notes
- `verify_crm_automation.py` strips HTML comments (`<!-- ... -->`) before
  linting. This was a real bug caught while building the bad samples: the
  explanatory comments describing *why* a sample is broken accidentally
  contained rubric keywords ("decay", "Goodhart") that made the checks
  false-pass. If you add annotation comments to a deliverable for any reason,
  remember the linter now ignores them entirely — they cannot rescue a failing
  check, and they cannot poison a passing one either.
- The linter requires a `Deliverable-Type: <type>` header as line 1 (or near
  the top) of every deliverable file. A file without it fails immediately,
  by design — a deliverable that doesn't declare what it is cannot be
  verified against the right rubric.
- Every deliverable type's checks are regex/structure-based against a specific
  markdown convention (e.g. `## Automation: <name>` blocks for automation-spec,
  `### Segment: <name>` for segmentation-plan, `### Stage: <name>` for
  journey-map). Match those heading conventions exactly or the parser won't
  find your blocks. See `samples/good/*.md` for the exact shape each type
  expects.
- The secret-scan in `integration-runbook` is deliberately generous (would
  rather false-positive on a weird-looking legit string than let a real key
  through). If a legit runbook trips it on a non-secret value, tighten the
  regex in `verify_crm_automation.py` — don't just delete the offending line
  from the deliverable to dodge it.
- `journey-map`'s trigger inventory check just looks for a `.md` reference in
  that section — it does not currently verify the referenced automation-spec
  file actually exists on disk or actually passes its own gate. That's a
  reasonable next hardening pass if this becomes load-bearing.

## Open questions for the user
- None currently. First real deliverable to produce is 19Keys' call — the
  `speed-to-lead-sla` automation-spec (playbooks/speed-to-lead-sla.md) is the
  highest-ROI single build per MANUAL.md §7.1 and unblocks `journey-map`.