Plan: Phase 2 reference notes, CLVM costing learnings and muladd

docs/execution-plan.md

@@ -102,6 +102,11 @@
 - [ ] **Adversarial regression corpus** in `vectors/matching/`: the duplicate-CREATE_COIN theft case as vector #1; batching-wallet scenarios; message forgery/replay shapes; mixed-tx edge cases.
 - [ ] Cross-check subset: for semantics that overlap Chia (timelock comparisons, dedup behavior), translate Chia consensus tests into bitlisp vectors.
 
+**Reference material for this phase (recorded 2026-07-29, per Evan):**
+
+- **Condition costing has five years of deployed CLVM learnings: read them before designing ours.** Chia's deployed per-condition costs are the baseline, and CHIP-0049 (the Chia 3.0 hard fork, in review) revises them: a base cost of 500 per condition beyond the first 100, announcement conditions always priced, and the hard 1,024-announcement cap removed in favor of pricing. That is the pricing-over-caps philosophy obligation 2 commits us to, applied by the team with production data. Two decisions to make deliberately rather than inherit: whether a free tier (their first-100 carve-out) is acceptable or a cliff we reject, and how their announcement pricing maps onto our tx-scoped SEND/RECV_MESSAGE conditions, their closest descendant.
+- **Taproot output construction belongs to the condition layer, not the VM (design question, decide in CONDITIONS.md).** bllsh ships `secp256k1_muladd`, a general EC linear-combination operator, largely so programs can verify taproot tweaks in-language. BitLisp will meet the same need when covenant recursion constructs a successor coin whose scriptPubKey is taproot(internal key, tree). The conditions-architecture answer is a condition form that commits to the taproot components and lets the one hardened validator compute the tweak natively, keeping EC arithmetic out of the consensus VM. Decide the form when CONDITIONS.md v0 is drafted, and record the muladd decline rationale next to it (VM.md section 8, D2 entry, already records the v0 decline).
+
 **Done when:** invariant suite green over large generated corpora; adversarial corpus ≥ 50 hand-designed vectors each citing a MATCHING.md rule; a reviewer can read MATCHING.md alone and predict every vector's outcome.
 
 **Claude Code fit:** strong for implementation + invariant/corpus generation; **design decisions stay in Fable 5 sessions** (this chat) and land in spec prose before Claude Code touches them. Session pattern: Fable 5 designs a matching rule → spec commit → Claude Code implements + generates vectors → Fable 5 reviews divergence reports.