# 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 scaffolded: `AGENTS.md`, `feature_list.json`, `init.sh`, `verify_funnel_psychology.py`,
  `samples/good/`, `samples/bad/`, `playbooks/` (10 files), `progress.md`, this file.
- `MANUAL.md` was pre-existing (written in the Manual phase) — not modified by this harness.
- Zero deliverable features started. `workspace/` is empty.
- `./init.sh` verified green: linter passes the good sample, correctly fails the bad sample
  on 13 named checks (hype words, missing sophistication level, offer-stack labels, double
  CTA, orphan stage, untagged conversion numbers, missing instrumentation, missing section).

## What the next session should do first
1. Read `progress.md`, then `feature_list.json`.
2. Run `./init.sh` (expect exit 0 — the gate itself, not a deliverable).
3. Start feature `funnel-blueprint`: write `workspace/funnel-blueprint.md`, run the linter
   against it with `--type funnel-blueprint`, iterate until it exits 0.

## Gotchas / notes
- The linter (`verify_funnel_psychology.py`) parses markdown by `## ` top-level headers and
  `### ` stage/sub-entry headers. Deliverables MUST use that exact heading depth for sections
  the linter looks for, or `find_section()` won't match and it'll report "missing section"
  even if the content is present under a differently-leveled or renamed heading.
- Labeled fields (e.g. `Price:`, `Promise:`, `CTA:`, `Next stage:`, `Metric:`, `Event:`,
  `Hypothesis:`, `Decision Rule:`) are matched by regex on the label text, case-insensitive,
  at start of line (optionally after a `-`/`*`/number bullet marker). Follow the exact label
  vocabulary shown in `samples/good/funnel-blueprint-ziion-ascension.md` — synonyms will not
  match and will read as missing.
- The five deliverable types share some conventions (bracket tags `[benchmark|historical|guess]`
  for numbers, `[testimonial|data|demo|authority]` for proof, `[real|absent]` for scarcity) —
  reuse them consistently; the linter's regexes are type-specific but the tag vocabulary is
  shared across the discipline.
- `init.sh` only runs the gate against `funnel-blueprint`-type samples (the one pair that
  exists). The other four deliverable types are exercised by their own `feature_list.json`
  `verify` commands once a workspace artifact of that type exists — `init.sh` doesn't need
  good/bad pairs for all five to prove the gate is real, but if you add samples for another
  type, wire them into `init.sh` too.
- `verify_funnel_psychology.py` is stdlib-only (argparse + re + sys) — do not add dependencies.

## Open questions for the user
- Which deliverable should get built first against a REAL 19Keys situation (not just the
  sample): the 4,591-buyer ascension blueprint (MANUAL.md §9.2) is the obvious candidate and
  already has real numbers ($611K revenue, 0 ascension emails sent) to build the Conversion
  Math / Failure Exits sections against honest `[historical]` tags instead of `[guess]`.