Release 0.1.1: EB-13 procedure on the 271

.changeset/eb13-procedure-271.md

@@ -0,0 +1,23 @@
+---
+"@cosyte/x12": patch
+---
+
+**The 271 reads and builds the procedure a benefit line applies to (EB-13).**
+
+Dental payers send per-procedure coinsurance, frequency, age and maximum limits on 271 benefit lines,
+keyed by a CDT code in EB-13, and the CAQH CORE eligibility data content rule calls for it. Until now
+those lines read back with no procedure, and the 271 builder could not write one.
+
+- Reading: each `X12EligibilityBenefit` now carries `procedure`, an `X12EligibilityProcedure` with the
+  qualifier (EB-13-1), the code (EB-13-2), up to four modifiers in transmitted order (EB-13-3 to
+  EB-13-6) and the description (EB-13-7) when the sender sent one. It is `undefined` when EB-13 is
+  absent or has no qualifier. Components are split on the component separator the interchange
+  declares in ISA-16, never an assumed `:`.
+- Building: a 271 benefit takes an optional `procedure` (`Build271ProcedureSpec`: qualifier, code
+  and modifiers) and writes it as one composite. The builder refuses an empty qualifier or code, an
+  empty modifier, and more than four modifiers, because a fifth would land in the description
+  position and an empty one would shift later modifiers on read. It does not write a description.
+- The 270 reader's EQ-02 procedure decodes exactly as before; it now shares its decoder with the 271.
+
+If you build an `X12EligibilityBenefit` object literal yourself, such as a test double, add
+`procedure: undefined` to it. Code that reads benefits from `get271` needs no change.

CHANGELOG.md

@@ -7,6 +7,29 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.1.1] - 2026-10-07
+
+**What 0.1.1 means for you.** The 271 now reads and builds the procedure a benefit line applies to
+(EB-13), which dental payers use for per-procedure coinsurance, frequency, age and maximum limits.
+If you build an `X12EligibilityBenefit` object literal yourself, such as a test double, add
+`procedure: undefined` to it. Code that reads benefits from `get271` needs no change.
+
+### Added
+
+- **271 EB-13 read.** Each benefit's `procedure` carries the qualifier (EB-13-1), the code
+  (EB-13-2), up to four modifiers in transmitted order (EB-13-3 to EB-13-6) and the description
+  (EB-13-7) when the sender sent one, and is `undefined` when EB-13 is absent or has no qualifier.
+  Components are split on the component separator the interchange declares in ISA-16. New
+  package-root type export: `X12EligibilityProcedure`.
+- **271 EB-13 emit.** A 271 benefit takes an optional `procedure` (`Build271ProcedureSpec`, a new
+  package-root type export) with a qualifier, a code and modifiers, written as one composite. The
+  builder refuses an empty qualifier or code, an empty modifier, and more than four modifiers: a
+  fifth would land in the description position, and an empty one would shift later modifiers on
+  read. The description is not written.
+- The 270 reader's EQ-02 procedure decodes exactly as before and now shares its decoder with the 271.
+
+## [0.1.0] - 2026-09-25
+
 **What 0.1 means for you.** This release is the first whose public API we treat as settled: the
 exported readers, builders, types and warning codes are the surface we keep stable, and the warning
 registry only ever gains codes. It covers typed read and typed emit for 270, 271, 276, 277 and

docs/releases/0.1.0-readiness.md

@@ -3,8 +3,8 @@
 - Version prepared: `0.1.0`
 - Version currently recorded in the package manifest: `0.0.18`
 
-This document is read by `test/release/release-prep.test.ts`, which fails when
-any statement below disagrees with the repository. It prepares a release; it
+This document is the audit the 0.1.0 release was prepared against. It
+prepares a release; it
 performs none of it. The version bump, the changeset consumption, the tag and
 the publish all belong to the release run this document is written for.