Merge branch 'buffer-implementation'HEADmain

Establishes the first working baseline: moji <file> opens a file into a
ropey rope and edits it with Helix selection-first modal editing, under a
DO-178C DAL-C requirements and traceability process.

Prior to this, main tracked four files and src/main.rs was still
println!("Hello, world!") — there was no buildable state to build on.

Verified on a fresh clone of the branch with no untracked files:
cargo build; clippy --all-targets -D warnings clean; 294 tests passing;
scripts/check-trace.sh reports 98/98 requirements traced in both
directions.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

1 files changed, 112 insertions, 0 deletions

diff --git a/docs/reviews/requirements-checklist.md b/docs/reviews/requirements-checklist.md
new file mode 100644
index 0000000..c6ced28
--- /dev/null
+++ b/docs/reviews/requirements-checklist.md
@@ -0,0 +1,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.