# Requirements review checklist

Software Level: **DAL-C** (DO-178C)
Reviewer: author — **review without independence**, which DO-178C permits at
Software Level C.
Scope: `docs/requirements/{hlr,llr,derived}.md`

Derived from DO-178C Table A-3 (verification of software requirements) and
Table A-4 (verification of the design), reduced to the objectives that apply at
DAL-C.

---

## High-level requirements

| # | Check | Result |
|---|---|---|
| 1 | Every HLR is traceable to a request in the originating task statement | **Pass** — the statement's scope items map to MJB-HLR-001…019 |
| 2 | HLRs are accurate and unambiguous | **Pass** with one note, below |
| 3 | HLRs are verifiable — each states an observable behaviour | **Pass** |
| 4 | HLRs do not specify implementation | **Pass**, except MJB-HLR-004 and MJB-HLR-014, where the rope and the TOML format were themselves requested |
| 5 | HLRs conform to a consistent standard | **Pass** — "shall" throughout, one behaviour per requirement |
| 6 | Conflicting requirements are identified and resolved | **Pass** — one conflict found, see below |

**Note on objective 2.** MJB-HLR-007 needed rewording during review. It
originally read "shall provide next-word-start … motions", which reads as a
cursor move and matches the wording of Helix's own keymap documentation. That
wording is misleading: Helix's `move_next_word_start` returns a *range*. The
requirement now states the selection behaviour explicitly, because the
misreading would have produced Vim semantics that pass a naive test.

**Conflict found and resolved (objective 6).** The task statement asked for a
"non-UTF-8 rejection path" *and* for full Helix save fidelity. Helix transcodes
via `encoding_rs` rather than rejecting, and the two initially looked mutually
exclusive; the conflict was recorded as **MJB-DR-001** and flagged.

It is now **resolved**, on the requester's direction to make UTF-8 an exception.
Splitting the behaviour by whether the encoding is *known* satisfies both
requests: a BOM-declared non-UTF-8 encoding is transcoded, because the
substitution is reproducible on write (MJB-LLR-113); UTF-8 is validated strictly
and refused when malformed, because nothing is known that would make a repair
reproducible (MJB-LLR-118). The lossy-save hazard that motivated the flag is
eliminated rather than accepted.

---

## Low-level requirements

| # | Check | Result |
|---|---|---|
| 7 | Every LLR traces to a parent HLR | **Pass** — `docs/traceability/trace.md`, HLR → LLR table |
| 8 | Every LLR is traceable to source | **Pass** — 98/98 tagged, verified by `grep`, not by inspection |
| 9 | LLRs are verifiable | **Pass** — 98/98 have a test named for them |
| 10 | LLRs are consistent with the HLRs they derive from | **Pass** |
| 11 | Algorithms are accurate | **Pass** with one caveat, below |
| 12 | LLRs describe behaviour, not code structure | **Pass** |

**Caveat on objective 11.** The viewport and word-motion algorithms were
translated from Helix, not ported: Helix indexes by character and mojibake by
byte. Every offset therefore changed meaning. This is the highest-risk area of
the change and is why `buffer/view.rs` (99.57%) and `buffer/movement.rs`
(97.98%) carry the highest coverage in the crate.

---

## Derived requirements

| # | Check | Result |
|---|---|---|
| 13 | Derived requirements are identified as such | **Pass** — seven, in `derived.md` |
| 14 | Each states what forced it | **Pass** |
| 15 | Each is flagged for the safety assessment | **Pass** — every entry carries a "Reviewer must judge" clause |
| 16 | Derived requirements do not silently weaken an HLR | **Pass** — MJB-DR-001 previously weakened the originating request; it has since been resolved so that both the transcoding and rejection behaviours hold, each in its own domain |

Seven derived requirements were recorded, of which **one (MJB-DR-001) is now
resolved** and six remain open. Two were found only during implementation and
could not have been anticipated:

- **MJB-DR-002** — byte indexing admits offsets inside a character, a failure
  mode char indexing cannot express.
- **MJB-DR-007** — `encoding_rs` decodes UTF-16 but silently refuses to encode
  it, substituting UTF-8. Found by a round-trip test, **not** by inspection.

---

## Open items for the safety assessment

**Six of seven** derived requirements remain open; MJB-DR-001 is resolved. The
most consequential remaining:

1. **MJB-DR-006** — ropey 2.0.0-beta.1 is a pre-release under a DAL-C
   classification. Raised before implementation, accepted by the requester,
   mitigated by confining the dependency to one module.
2. **MJB-DR-007** — `encoding_rs` refuses to encode UTF-16 and substitutes
   UTF-8 silently. Worked around; the reviewer must judge whether any other
   delegated encoding shares the asymmetry.
3. **MJB-DR-002** — byte indexing admits offsets inside a character. Guarded in
   two places; the reviewer must judge whether returning an error is right where
   a violated boundary may instead indicate a defect.

A residual item is noted under MJB-DR-001: with UTF-8 now strict, a binary file
cannot be opened at all, and no override is provided. That omission is
deliberate and its rationale is recorded, but it is a usability decision a
reviewer may want to revisit.

---

## Summary

Requirements review **complete**. 19 HLRs, 98 LLRs, 7 derived requirements.
One requirements conflict found and **resolved**; one HLR reworded for accuracy;
six derived requirements outstanding for the safety assessment.