From 180af46879a4acc315ce28a96009c8516b813bea Mon Sep 17 00:00:00 2001 From: sjat Date: Fri, 19 Jun 2026 10:40:29 +0200 Subject: [PATCH] docs(friction): log the Molecule input_only-accept coverage gap Final-review finding: the default Molecule scenario only renders the forward drop (input_only off) branch; the accept branch is covered by the integration harness only. Tracked for a kaizen decision (2nd scenario vs accept the split). Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/FRICTION.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/FRICTION.md b/docs/FRICTION.md index fdcc2ac..2ce85fa 100644 --- a/docs/FRICTION.md +++ b/docs/FRICTION.md @@ -186,6 +186,17 @@ harness on ubongo and shaking it down against real KVM (spec/plan in docs/superp still need a go-ahead). Ties to the `test-risky-infra-before-live-deploy` + `dont-reask-settled-defaults` memories + ADR-025. +- `[gotcha]` **Molecule covers only the `input_only`-OFF (forward drop) branch of the base + firewall** (2026-06-19): mesh-hardening 2/3 added `base__firewall_input_only` (forward policy + drop↔accept). The `default` Molecule scenario renders ONE fixture, set to the secure default + (drop) — so the fast `make test ROLE=base` gate locks the drop default (security-critical for + service hosts) but does NOT exercise the `=true` → forward-`accept` rendering; only `make + test-integration HOST=ubongo` does (passed GREEN). An in-converge re-render can't cheaply + cover it (role defaults aren't in scope outside the role run). → decide in kaizen: a second + Molecule scenario (`molecule/input-only/`) asserting forward `policy accept`, vs accepting the + integration-only coverage. Final-review finding; not a cutover blocker (the accept branch is a + literal, and a var-name break would fail the drop branch too → caught). + --- ## Kaizen reviews — decisions ledger