modify --set-field on a block-scalar field leaves the old continuation lines, corrupting the YAML, and reports success

[avrabe]

rivet modify --set-field replaces the header line of a block scalar (> / |) but leaves the indented continuation lines behind. The result is unparseable YAML, and modify prints modified <ID> as if it succeeded. The next rivet validate fails on a file the tool itself just wrote.

rivet 0.32.0 (ec436b8 HEAD 2026-08-05), on pulseengine/meld.

Reproduction

SR-32 in safety/requirements/safety-requirements.yaml has a block-scalar field:

      verification-description: >
        Foundation: stackful_intrinsic_signatures_pinned +
        stackful_lift_is_async_without_callback. Emitter:
        sr32_has_callback_export_detects_companion (detection),
        ...

$ rivet validate | tail -1
Result: PASS (105 warnings)

$ rivet modify SR-32 --set-field "verification-description=SHORT TEST VALUE"
modified SR-32

$ rivet validate | tail -1
Result: FAIL (8 errors, 105 warnings, 0 broken cross-refs)

The file now reads:

      verification-description: SHORT TEST VALUE
        Foundation: stackful_intrinsic_signatures_pinned +
        stackful_lift_is_async_without_callback. Emitter:
        ...

The > header was replaced by the new scalar; its body was not removed. Errors reported are expected ':' after mapping key at each orphaned line.

Why it matters

The project instruction in this repo is to mutate artifacts only through the rivet CLI, never by hand-editing artifact YAML. This makes that impossible for any field stored as a block scalar, which is most long prose fields (verification-description, fix, scenario). The workaround is exactly what the rule forbids: hand-edit the YAML.

Worse than the corruption is the exit status: modify returns 0 and prints modified SR-32. A script that edits several artifacts and checks exit codes will keep going over a corrupted file. I hit this while correcting stale test citations (meld#411) and only noticed because I ran rivet validate afterwards.

--set-description on the same run did not corrupt sw-verifications.yaml, so this looks specific to --set-field (or to how that file's fields are emitted).

Suggested

1. Replace the whole field node, not the header line — or re-emit the artifact through the YAML writer instead of patching text.
2. Until that lands, modify should at minimum re-parse the file it wrote and fail loudly (non-zero) rather than reporting success.

Happy to test a fix against meld's record, which has plenty of block-scalar fields.

[avrabe]

Triage note (scheduled routine, first pass on this issue — filed 2026-09-18, zero prior comments).

Well-scoped mutation-safety finding with an end-to-end reproduction on pulseengine/meld at rivet 0.32.0 (ec436b89): modify --set-field replaces the block-scalar header line (> / |) but leaves the indented continuation lines behind, producing unparseable YAML while exit=0 and the tool prints modified <ID>. --set-description on the same run doesn't corrupt sibling files, so this is --set-field-specific (or specific to how that file's fields are emitted). Two proposed fixes: (1) replace the whole field node or re-emit through the YAML writer, (2) as an interim guard, re-parse the file after write and fail non-zero on invalid.

This is the same class as the mutation-safety lineage already tracked in the codebase — #806 is called out in #809's table under the exact heading "--set-field orphans multi-line values", so #979 is either a live repro of #806 or a sibling on the block-scalar side. Also directly parallel to #965 (modify --where non-atomic) and #955 (batch non-atomic with no rollback) under the "one invariant, four data-loss bugs, no property test" umbrella in #809. The scheduled routine can't gate on that alone — the AC-ask below is the shape adjacent triage threads (#468, #557, #809, #838, #930, #951, #952, #955, #956, #957, #958, #962, #965) have converged on.

Sketch matching the kill-criterion shape used across adjacent triage threads:

## Acceptance Criteria — --set-field respects block-scalar extent (and can't lie about success)

- [ ] `YamlEditor::set_field` (or the custom-`fields:` loop in the sibling path #806/#809 identified) consumes the full on-disk extent of the field being replaced — the invariant #809 names: *"Replacing a key must consume that key's entire on-disk extent — and change nothing else."* Both block-scalar headers (`>` / `|` / `|-` / `|+` / `|2`) and their indented continuation lines are treated as one unit.
- [ ] Regression fixture (the maintainer-reproduced one, minimised): a requirement with `verification-description: >\n        line 1\n        line 2\n        line 3\n`. `rivet modify <ID> --set-field "verification-description=SHORT"` produces a file whose next `rivet validate` PASSes AND the block-scalar body lines are gone. Currently: `Result: FAIL (8 errors)` with orphaned continuation lines.
- [ ] Belt-and-braces (either as the primary fix, or as an interim guard behind the structural fix): `modify` re-parses the file it wrote AND cross-checks the mutation applied. On mismatch it either (a) restores the original file (transactional) and exits non-zero with a specific error, or (b) at minimum exits non-zero with a diagnostic naming what corruption was detected. "`modify` reports success on a corrupted file" is the failure mode the fix must close.
- [ ] Corpus coverage: the mutation-safety scalar-style axis #809 enumerates for the property harness (plain · single-quoted · double-quoted · folded `>` · literal `|` · `|-` / `|+` / `|2` · flow map · flow seq · body containing `:` / `#` / a leading `-` · internal blank line · CRLF · tabs · last-field-of-last-artifact) is exercised — this fix can seed the harness proposed in #809 rather than duplicating its coverage.
- [ ] Property assertion (matches #809's exact-equality clause): after `--set-field f=v`, `parse(D')[f] == v` AND `parse(D')[p] == parse(D)[p]` for every path `p != f`. Byte-identity outside the target field.
- [ ] `cargo test --workspace` green; `rivet validate` PASS on the rivet repo; the two YAML fuzz targets (`fuzz_targets/yaml_footguns.rs`, `fuzz_targets/fuzz_yaml_artifact.rs`) still pass.
- [ ] Commit trailers: `Fixes: REQ-<N>` (either the existing mutation-safety REQ from #809's lineage, or a new one if this ships before #809's harness) + `Refs: #979, #806, #809`.

## Explicitly out of scope for the first slice (file separately if wanted)

- [ ] The full mutation-safety property harness (#809) — this fix can be a first regression fixture *for* the harness, not the harness itself.
- [ ] Migration of the yaml_edit writer to the rowan CST (the alternative #809 flags as the class-closer but explicitly leaves for maintainer scoping).
- [ ] Fixing the custom-`fields:` loop 700 lines below `set_field` — if this fix is targeted at `set_field`'s path only, the sibling path #809 highlights may still need its own PR.

Two coordination items worth a maintainer call before AC is locked:

• Relationship to P0 data loss: modify --set-field orphans multi-line values in fields: (exit 0) #806. Mutation-safety harness: one invariant, four data-loss bugs, no property test (#573/#618/REQ-287/#806) #809's table names P0 data loss: modify --set-field orphans multi-line values in fields: (exit 0) #806 as --set-field orphans multi-line values, which is exactly what modify --set-field on a block-scalar field leaves the old continuation lines, corrupting the YAML, and reports success #979 reproduces. Either P0 data loss: modify --set-field orphans multi-line values in fields: (exit 0) #806 was never fixed (in which case modify --set-field on a block-scalar field leaves the old continuation lines, corrupting the YAML, and reports success #979 supersedes it with a fresh repro on 0.32.0), or P0 data loss: modify --set-field orphans multi-line values in fields: (exit 0) #806 was fixed for one path and left the block-scalar sibling — matching Mutation-safety harness: one invariant, four data-loss bugs, no property test (#573/#618/REQ-287/#806) #809's diagnosis that "three separate bug reports hardened one path; nobody propagated the fix to its sibling". Worth confirming P0 data loss: modify --set-field orphans multi-line values in fields: (exit 0) #806's state before scoping the PR.
• Structural fix vs interim guard. The body's fix (1) — replace the whole field node — is the durable answer. Fix (2) — re-parse and fail loudly — is a smaller diff that at least closes the "reports success on a corrupted file" mode. Landing (2) first as a one-liner safety net while (1) is scoped is defensible; landing only (2) is not, because it leaves the corruption in place. Pinning which the PR does (or both) affects its shape.

Adjacent state worth flagging:

• Mutation-safety harness: one invariant, four data-loss bugs, no property test (#573/#618/REQ-287/#806) #809 (mutation-safety harness umbrella) is the parent lens; this is a fresh instance under it.
• rivet batch applies mutations non-atomically with no rollback, and has zero tests #955 (batch non-atomic), modify --where is not atomic: an external artifact in the match set fails mid-write after 11 files are already rewritten #965 (modify --where non-atomic) are sibling mutation-atomicity issues on adjacent commands.
• Prior fix history in yaml_edit.rs::set_field explicitly cites friction: modify --set-field corrupts flow-style fields: {...} maps (file becomes unparseable, artifacts silently vanish) #573/rivet modify --set-release corrupts YAML when an earlier field is a folded/literal multiline scalar #613/🚨 CI runner pool liveness alert #618 as "same class" — the pattern is well-documented at the fix site, which strengthens the case for a property test rather than a fifth example-based fix.
• The reporter's constraint ("mutate artifacts only through the rivet CLI, never by hand-editing artifact YAML") is what makes this a hard block for downstream projects like meld — the workaround the bug forces (hand-edit) is exactly what the project rule forbids.

Process side-rail: https://pulseengine.eu/blog/ fetched at the start of this run (200 OK). No post speaks to per-issue AC shape or mutation-safety convention, so the kill-criterion posture used across adjacent triage threads remains the working default.

Not implemented this run — no PR opened; the AC block on the body is the gating input. Once you pin the structural-fix-vs-guard direction and the relationship to #806, the next routine pass can open a focused branch.

---

Generated by Claude Code

[avrabe]

Working on this in #982.

Two-part resolution:

1. The primary corruption is already fixed on main. The reproduction you filed against 0.32.0 no longer reproduces on current main: --set-field verification-description=… cleanly replaces the block-scalar node, and rivet validate returns PASS afterwards. That fix landed as part of the P0 data loss: modify --set-field orphans multi-line values in fields: (exit 0) #806 hardening of field_block_end in v0.36.0 (post-0.32.0).

2. Your second ask — "modify should re-parse the file it wrote and fail loudly" — was not in place. fix(modify): re-parse output as a post-write safety gate (#979) #982 adds a post-write parse gate to modify_artifact_yaml that round-trips the emitted string through serde_yaml::from_str and refuses to return it (so the file write never happens) if the output does not parse. A future regression in any editor path that produces syntactically-invalid YAML now fails with a Validation error naming the artifact id and the parser's own diagnostic, instead of exiting 0 with modified <ID> on a corrupted file.

Regression tests pinned to this issue's number:

• set_field_replaces_verification_description_folded_scalar_issue_979 — reproduces your exact shape (verification-description: > under fields: with commas and parens in the continuation) and asserts the replacement is clean.
• modify_artifact_yaml_refuses_to_return_unparseable_output_issue_979 — hand-corrupts an artifact block to the exact shape from your issue (a plain-scalar header with orphaned Foundation: continuation lines) and asserts the parse gate refuses it with the id-tagged diagnostic.

Both pass on the patched tree. Will keep this open until #982 merges.

---

Generated by Claude Code

[avrabe]

Fixed on main. The commit from PR #982 (af8184b — fix(modify): re-parse output as a post-write safety gate (#979)) landed verbatim via #984 (merge commit 3432a17), which batched six PRs plus a Kani fix into one CI cycle.

Both acceptance criteria are met by the merged change:

1. Whole field node is replaced, not just the header line — already the case since v0.36.0 via P0 data loss: modify --set-field orphans multi-line values in fields: (exit 0) #806; pinned to this issue's exact verification-description: > shape by set_field_replaces_verification_description_folded_scalar_issue_979.
2. modify re-parses the file it wrote and fails loudly on corruption — added as the post-write parse gate in modify_artifact_yaml, asserted by modify_artifact_yaml_refuses_to_return_unparseable_output_issue_979 — a hand-corrupted artifact block of the exact modify --set-field on a block-scalar field leaves the old continuation lines, corrupting the YAML, and reports success #979 shape is now refused with a post-write parse check message naming the artifact id, instead of returning Ok with the corrupt output.

Closing.

---

Generated by Claude Code