Design doc: anemia lens (§2 leaf-side decomposition) — for review

[gunbai-bot]

Design doc for joint review — not an implementation. Per the lane brief, this is a written proposal for the operator/parent to review together; it does not ship a lens.

Resolves the DESIGN.md parked open thread: can a lens mechanically diagnose the leaf-side of decomposition (§2 anemia)?

The crux

The structural law forbids a lens reading a leaf's characters, so "a String whose values parse as a URL/semver" is banned. The doc's reframe: anemia is a property of the program around the value, not the value. Hidden structure must live in some declared program shape, giving three contents-free signals:

• A — existing-authority coincidence (base_url: String while type Url exists; digest → ContentHash)
• B — closed-set-by-comparison (a String only ==-compared to a finite literal set = an enum; OCI arch/os already done-right this way)
• C — consumer-cracks-the-leaf (a split/slice/parse op's existence proves hidden parts; host_language_transport_script is this for one leaf)

What it covers (per the brief)

• detection signal · false-positive guards (Other/Unknown escape payload, parse-input vs stored field, cited SKU, pipeline-subject) · mechanically-decidable vs human-judgment boundary (version strings = the residual; future cited-grammar oracle) · proposed lens shape (fact-cardinality family, confidence-tiered, leaf-side dual of fact_density).

Grounded throughout in the live dsl/extdeps/** anemia corpus. §8 lists open questions for the review discussion.

docs/plans/anemia-lens.md

🤖 Generated with Claude Code

[gunbai-bot]

Both findings were valid — fixed in fe46060 (docs-only).

1. host_language_transport_script ≠ Signal C. Confirmed: it classifies the producer-side parse-tree shape of the script: arg (BareStringLiteral/LetBound/Interp/ComputedApplication, :26-31/:47-54) and REDs on a literal blob — it never scans for a consumer cracking the leaf. Reframed: §3 now motivates Signal C with the Add embedded host-language Node lens with execution-grounded witnesses #5132 EmbeddedShellExecFact char-scan trap and explicitly flags that this lens is not a Signal-C detector but the interim migration guard for an already-known anemic leaf; §7/§9 recast it as the template for HardViolation enforcement (interim arg-shape guard → terminal type flip), complementary to this lens rather than absorbed by it.
2. Verdict carrier. Confirmed fact_density returns Outcome<Witness> (:96), not LensVerdict — only host_language_transport_script returns LensVerdict (:100-108). §6 corrected: the family is not yet verdict-unified; this lens should be authored on LensVerdict and converging the carrier is a noted follow-up.

The three-signal reframe, structural-law constraint, calibration-before-gating posture, and corpus citations are unchanged. — sent from cool-fox-835

[gunbai-bot]

Valid finding — fixed in d6dbde9 (docs-only).

Confirmed: type SemVer = String exists (std/types.dag:272, itself a brand-deferred alias) and is consumed (OciRuntimeVersion = SemVer, oci/types.dag:162). My §4 "no authority exists" was wrong. Reframed:

• An exact version String is now correctly a Signal A nickname for SemVer, not a residual.
• The genuine residual is a version constraint: cargo RegistryDep.version (cargo.dag:54) is a requirement grammar (^1.0 / >=1.2, <1.5) — a relation of operator + SemVer bound(s) that SemVer (a single point) does not cover. Residual on both counts: no VersionConstraint authority exists, and the program never decomposes it (stored, handed to cargo). The map-then-mint is over the existing SemVer (reuse for bounds, mint the constraint relation = legit net+1, not re-invention).
• Dropped the cloud.dag:75 / gcp.dag:114 examples — those are API version labels (v1), a third concept, neither SemVer nor a constraint.
• §8.2 sharpened: the version field's three possible meanings (exact SemVer / constraint / API label) mean name alone can't pick the target type → argues name-only coincidence should be SoftCandidate, not HardViolation.

— sent from cool-fox-835