Nushell 0.111 String Interpolation Compatibility Fix

Context

Nushell 0.111 introduced a breaking change in string interpolation parsing: expressions inside `$"..."` that match the pattern `(identifier: expr)` are now parsed as command calls rather than as record literals or literal text. This broke four print statements in reflection/bin/ontoref.nu that used patterns like `(kind: ($kind))`, `(logo: ($logo_file))`, `(parents: ($parent_slugs))`, and `(POST /actors/register)`. The bug manifested when running `ontoref setup` and `ontoref hooks-install` on any consumer project using Nu 0.111+. The minimum Nu version gate (>= 0.110.0) did not catch 0.111 regressions since it only guards the lower bound.

Decision

Fix all four affected print statements by removing the outer parentheses from label-value pairs inside string interpolations, or by removing the `$` prefix from strings that contain no variable interpolation. The fix is minimal and non-semantic: `(kind: ($kind))` becomes `kind: ($kind)` (literal label + variable), and `$"(POST /actors/register)"` becomes `"(POST /actors/register)"` (plain string). The fix is applied to both the dev repo (reflection/bin/ontoref.nu) and the installed copy (~/.local/bin/ontoref via just install-daemon). The minimum version gate remains >= 0.110.0 but 0.111 is now the tested floor.

Constraints

• Hard An unescaped `(...)` inside a `$"..."` is a subexpression Nushell executes — every such group must be a real expression. Parens meant as text must be written `\(` and `\)`
• Soft Print statements with no variable interpolation must use plain strings, not `$"..."`

Alternatives considered

• Raise minimum Nu version to 0.111 and document the breaking change — rejected: Does not fix the broken syntax — just makes the breakage explicit. Consumer projects already on 0.111 would still fail until the print statements are fixed.
• Use escape sequences or string concatenation to embed literal parens — rejected: ADOPTED 2026-08-30, and the reason first recorded here was false. Nushell DOES escape parens in string interpolation — `\(` and `\)` render literal parens, verified on 0.115.1 — and this ADR had already contradicted itself about it: the constraint's own 2026-07-27 comment calls `\(alias: ($alias)\)` "the ESCAPED form this ADR tells you to write". Escaping is now the prescription wherever the parens are part of the message, which is most of them; it is what all 29 repairs of 2026-08-30 used. What survives of the original rejection is the second half: string concatenation (e.g. `'(kind: ' + $kind + ')'`) works and is still less readable than either escaping or the bare `kind: ($kind)` form, which remains the fix for the label-value shape.