friction: `modify --set-field` corrupts flow-style `fields: {...}` maps (file becomes unparseable, artifacts silently vanish)

[avrabe]

What I was trying to do: Add a release: field to requirements (release-planning workflow) in the agora project so I could scope artifacts to releases via rivet modify <ID> --set-field release=v0.1.0.

Tool + version: rivet 0.17.0 (d648ce4 main 2026-06-23)

What happened: rivet modify --set-field corrupts the YAML when the target artifact's fields: is written in flow style (fields: { priority: must, category: functional }). Instead of merging into the inline map, it appends a mis-indented block line right after it:

    fields: { priority: must, category: functional }
      release: v0.1.0          # <- invalid: block key under a flow mapping

This makes the whole file unparseable, so on the next load every artifact in that file silently vanishes (rivet list → 0 artifacts, with a WARN about a skipped source). A subsequent rivet modify on a sibling artifact then fails with artifact '...' does not exist even though it is still in the file. Data-loss-shaped: a routine planning command bricked the requirements file.

Block-style fields: is handled correctly — --set-field only mishandles the flow-style form.

Repro (minimal):

# artifacts/reqs.yaml
artifacts:
  - id: REQ-001
    type: requirement
    title: t
    status: draft
    description: d
    fields: { priority: must, category: functional }
  - id: REQ-002
    type: requirement
    title: t2
    status: draft
    description: d2
    fields: { priority: must, category: functional }

rivet list                                   # 2 artifacts
rivet modify REQ-001 --set-field release=v0.1.0
rivet list                                   # 0 artifacts (YAML parse error) — REQ-002 also gone

Workaround used: Hand-edited the YAML to convert flow-style fields: {...} to block style, added release: manually, re-ran rivet validate (PASS). After conversion, --set-field works fine.

Impact: Blocked (briefly) + data-corruption risk. The silent "0 artifacts" + later "does not exist" errors are especially dangerous — easy to not notice the file was bricked. Suggest: when --set-field targets a flow-style map, either normalize it to block style on write, or refuse with a clear error rather than emitting invalid YAML. Relatedly, a skipped-source parse error arguably should be a hard error for mutating commands, not a WARN that yields a silently-empty project.

[avrabe]

Triage from the issue-fixing routine (first pass on this issue).

The body has a clean repro, a workaround, and a **Suggest:** paragraph with two alternatives ("normalize to block style on write" OR "refuse with a clear error") plus a related "skipped-source parse error should be a hard error for mutating commands" call. The routine looks for an explicit ## Acceptance Criteria block with bulleted, testable statements of done — and this is data-corruption-shaped, so pinning which alternative ships first matters before any branch opens.

Sketch matching #532's kill-criterion shape — feel free to revise / re-scope. Recommend going with alternative B (refuse with a clear error) first because it's strictly safety-preserving and doesn't require any flow-style → block-style rewriting code that could itself introduce parse regressions; normalize-on-write can land as a follow-up if the friction warrants it.

## Acceptance Criteria — part 1 (stop the data corruption — refuse rather than emit invalid YAML)
- [ ] `rivet modify --set-field <key>=<value>` detects when the target artifact's `fields:` mapping is written in flow style (`fields: { ... }`) and **refuses the mutation** with a clear actionable error rather than emitting the mis-indented block line under the flow map. Error names the file + artifact id + the specific friction ("flow-style `fields: { ... }` cannot be safely extended by `--set-field`; rewrite as block style or use `--rewrite-flow-to-block`") and exits non-zero.
- [ ] Regression test: the body's minimal repro (REQ-001 + REQ-002 with `fields: { priority: must, category: functional }`) exercising `rivet modify REQ-001 --set-field release=v0.1.0` now exits non-zero with the named error; the file on disk is **unchanged byte-for-byte** afterward; `rivet list` continues to see both artifacts (no silent-vanish).
- [ ] Block-style `fields:` continues to work unchanged. Regression fixture covers both shapes side-by-side in the same file (one artifact with flow-style `fields`, one with block-style `fields`); `--set-field` on the block-style sibling succeeds and the flow-style sibling stays untouched.
- [ ] `cargo test -p rivet-core -p rivet-cli` green; `cargo fmt --check` / `clippy --all-targets -- -D warnings` clean; `rivet validate` on the rivet repo PASS unchanged.
- [ ] Commit trailers: `Fixes: REQ-NNN` (file a new REQ — e.g. "`modify --set-field` must not emit invalid YAML when `fields:` is flow-style") + `Refs: #573`.
- [ ] **Explicitly out of scope (file separately):** auto-rewriting flow-style `fields:` to block style on `--set-field` (part 2 — opt-in via `--rewrite-flow-to-block`, see below); the parse-error-on-mutate hard-fail behaviour (part 3 — separate posture call, see below).

## Acceptance Criteria — part 2 (opt-in normalize: `--rewrite-flow-to-block`)
- [ ] `rivet modify --set-field <k>=<v> --rewrite-flow-to-block <id>` (flag name TBD) rewrites the target artifact's flow-style `fields: { ... }` to block style as part of the same edit, preserving keys, values, and ordering — then applies the `--set-field` write. Idempotent: re-running on already-block-style `fields:` is a no-op for the normalization.
- [ ] Regression: same repro as part 1 but with the flag set — `rivet modify REQ-001 --set-field release=v0.1.0 --rewrite-flow-to-block` produces a valid YAML file, both artifacts are still loadable, and `rivet list` shows both.
- [ ] Per-artifact scoping: the rewrite touches only the targeted artifact's `fields:` block, not other artifacts in the same file, and not other flow-style mappings in the same artifact. Fixture covers a file with one flow-style `fields:` adjacent to one flow-style `tags: [ ... ]` to confirm `tags:` is untouched.
- [ ] **Explicitly out of scope:** project-wide bulk normalization (`rivet fmt` / `rivet rewrite-flow`); rewriting flow style in any field other than the targeted artifact's `fields:` map.

## Acceptance Criteria — part 3 (mutating commands hard-fail on skipped sources)
- [ ] When a mutating command (`rivet modify`, `rivet add`, `rivet stamp`, etc.) loads a project where any source produced a parse error (today's WARN + skip), the command **exits non-zero before any write** rather than proceeding against a silently-empty project. Read-only commands (`rivet list`, `rivet validate`) keep current WARN-and-continue behaviour.
- [ ] Regression: with a deliberately-broken file in `artifacts/`, `rivet modify <some-id> --set-field x=y` exits non-zero with a message naming the unparseable file and pointing at `rivet validate` to investigate; before-and-after `git diff` is empty.
- [ ] Compose with part 1: in the body's repro path, if part 1 ever regresses and the file becomes unparseable, part 3 ensures the *next* `rivet modify` on a sibling artifact fails loudly with "source skipped" instead of "artifact does not exist" — the two safety nets stack.
- [ ] **Explicitly out of scope:** auto-recovery / auto-repair of unparseable sources; promoting `rivet validate` itself to exit non-zero on skipped sources (a bigger posture call worth its own issue).

Each part is independently shippable; part 1 is the urgent safety fix and should land first. Part 2 is opt-in convenience that depends on part 1's refuse-by-default posture being in place. Part 3 is the broader "mutating commands shouldn't operate on a project that didn't fully load" posture — adjacent to the file-loader behaviour around skipped sources and worth a maintainer call on its own.

Process side-rail (carried from every recent triage thread): https://pulseengine.eu/blog/ is still HTTP 503 — re-verified three times this run (WebFetch → HTTP 503 Service Unavailable, same long-standing expired-TLS / site-infra symptom flagged across the last ~30 triage threads: #350, #420, #422, #431, #436, #456, #468, #479, #482, #488, #490, #500, #508, #509, #516, #522, #523, #530, #532, #538, #543, #546, #547, #548, #549, #550, #552, #554, #555, #556, #557, #567). The binding workflow guidance can't be consulted, so no PR will land from this triage regardless — consistent with the draft-PR posture on PRs #525, #537, #539, #541 against the same outage. Comment is the AC ask only.

Not implemented this run.

---

Generated by Claude Code — issue-triage agent run 2026-06-24.

---

Generated by Claude Code