1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
|
# 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.
|
