jeopi-hashline 16.4.2 → 16.4.3

package/CHANGELOG.md

@@ -2,6 +2,13 @@
 
 ## [Unreleased]
 
+## [16.4.3] - 2026-07-22
+
+### Fixed
+
+- Rejected ambiguous swaps that risk silent deletion of range boundaries: a one-sided boundary echo (payload restates the keeper line just outside the range) is only auto-repaired when the payload is long enough to be the widened range's full content — a shorter payload could instead mean the range itself shifted by the echo, which keeps the far boundary line(s) the repair would otherwise silently delete. The edit is now rejected with a message telling the author to re-issue it. Ported from oh-my-pi (upstream `e45796908`).
+- Prevented ambiguous auto-repairing of structural closing lines when payload placement is unclear: sparing a deleted closer re-inserts it after the payload, which claims the payload belongs inside the block the closer terminates. That claim now requires evidence — the payload carries the closer's unmatched opener, or its indentation sits deeper than the closer — otherwise the edit is rejected instead of guessing whether the new content belongs before or after the closer. Ported from oh-my-pi (upstream `e45796908`).
+
 ## [16.2.14] - 2026-07-02
 
 ### Changed

package/dist/types/messages.d.ts

@@ -49,6 +49,23 @@ export declare function insertAfterBlockCloserLoweredWarning(line: number): stri
  * applying with a warning beats failing the patch.
  */
 export declare function insertAfterBlockUnresolvedLoweredWarning(line: number): string;
+/**
+ * A one-sided boundary echo whose payload is too short to be the widened
+ * range's full content: dropping the echo deletes range line(s) the payload
+ * never restates (the "widened range" reading), while the "range shifted by
+ * the echo" reading keeps them. The readings produce different files, so the
+ * edit is rejected instead of repaired.
+ */
+export declare function ambiguousBoundaryEchoMessage(startLine: number, endLine: number, side: "leading" | "trailing", count: number): string;
+/**
+ * A replacement range deletes trailing structural closer(s) the payload never
+ * restates, and nothing anchors the payload inside the block those closers
+ * terminate: the payload has no unmatched opener for them and its indentation
+ * is not deeper than the closer. Sparing the closer would have to guess
+ * whether the payload belongs before it (inside the block) or after it (a
+ * sibling), so the edit is rejected instead of repaired.
+ */
+export declare function ambiguousCloserSpareMessage(startLine: number, endLine: number, closerLine: number, count: number): string;
 /**
  * Internal invariant: `applyEdits` received an unresolved `replace_block N:`
  * edit; `resolveBlockEdits` must run first. Wiring bug, not authored input.

package/package.json

@@ -1,7 +1,7 @@
 {
 	"type": "module",
 	"name": "jeopi-hashline",
-	"version": "16.4.2",
+	"version": "16.4.3",
 	"description": "Hashline: a compact, line-anchored patch language and applier. Pluggable FS/IO so it works over disk, in-memory, or any custom backend.",
 	"homepage": "https://github.com/akillness/jeopi",
 	"author": "Can Boluk",

package/src/apply.ts

@@ -7,7 +7,13 @@
  * which absorbs common model mistakes where a payload restates unchanged range
  * boundaries or duplicates/drops structural closers.
  */
-import { afterInsertLandingShiftWarning, blockInsertLandingShiftWarning, UNRESOLVED_BLOCK_INTERNAL } from "./messages";
+import {
+	afterInsertLandingShiftWarning,
+	ambiguousBoundaryEchoMessage,
+	ambiguousCloserSpareMessage,
+	blockInsertLandingShiftWarning,
+	UNRESOLVED_BLOCK_INTERNAL,
+} from "./messages";
 import { cloneCursor } from "./tokenizer";
 import type { Anchor, ApplyResult, Cursor, Edit } from "./types";
 
@@ -702,6 +708,12 @@ function describeBoundaryRepair(group: ReplacementGroup, action: string): string
  * carries no delimiter-balance signal itself, such as a JSX `</section>` close.
  * The dropped lines must keep the already-balanced result balanced, and must
  * not consume the whole payload.
+ *
+ * A detected echo is only *repairable* when the payload is long enough to be
+ * the widened range's full content (`payload ≥ range + echo`). Shorter
+ * payloads are ambiguous — the echo may instead mean the range itself was
+ * shifted by the echo, which keeps the far boundary line(s) the repair would
+ * delete — and the caller rejects the edit instead of guessing.
  */
 function findOneSidedBoundaryEcho(
 	group: ReplacementGroup,
@@ -800,6 +812,12 @@ function slotPatchDelta(slot: RepairSlot, fileLines: readonly string[]): Delimit
  * deleted is only kept when the patch as a whole is missing it — never when
  * another hunk already removed the matching opener. Returns the repaired edits
  * plus one warning per repaired group.
+ *
+ * Repairs fire only when exactly one reading explains the mistake. When the
+ * evidence is ambiguous — a one-sided echo whose payload is too short for the
+ * widened range, or a spared closer the payload neither opens nor indents
+ * into — the function throws instead of guessing, so the author re-issues the
+ * edit rather than shipping silently corrupted content.
  */
 function repairReplacementBoundaries(
 	edits: readonly AppliedEdit[],
@@ -842,6 +860,15 @@ function repairReplacementBoundaries(
 		if (balanceIsZero(delta)) {
 			const oneSided = findOneSidedBoundaryEcho(group, fileLines);
 			if (oneSided) {
+				// A payload shorter than range+echo cannot be the widened
+				// range's full content: the repair would delete range line(s)
+				// the payload never restates, while the "shifted range"
+				// reading keeps them. Reject rather than guess.
+				if (group.payload.length < group.deleteIndices.length + oneSided.count) {
+					throw new Error(
+						ambiguousBoundaryEchoMessage(group.startLine, group.endLine, oneSided.side, oneSided.count),
+					);
+				}
 				const trimmed =
 					oneSided.side === "leading"
 						? inserts.slice(oneSided.count)
@@ -934,6 +961,29 @@ function repairReplacementBoundaries(
 			insertedLineMaps,
 		);
 		if (droppedClosers) {
+			// Sparing a closer re-inserts it *after* the payload, which claims
+			// the payload lives inside the block the closer terminates. That
+			// claim needs evidence: the payload carries the closer's unmatched
+			// opener itself, or its indentation sits deeper than the closer.
+			// Without either, "before or after the closer" is a coin flip —
+			// reject rather than guess (e.g. a statement swapped onto a lone
+			// `}` at the closer's own depth belongs after the block).
+			const keptIndent = leadingIndent(fileLines[droppedClosers.startLine - 1] ?? "");
+			const payloadIndent = bodyTargetIndent(slot.group.payload);
+			const payloadOpens = balanceCovers(
+				computeDelimiterBalance(slot.group.payload),
+				balanceNegate(droppedClosers.balance),
+			);
+			if (!payloadOpens && !(payloadIndent !== undefined && isIndentDeeper(payloadIndent, keptIndent))) {
+				throw new Error(
+					ambiguousCloserSpareMessage(
+						slot.group.startLine,
+						slot.group.endLine,
+						droppedClosers.startLine,
+						droppedClosers.count,
+					),
+				);
+			}
 			warnings.push(
 				describeBoundaryRepair(
 					slot.group,

package/src/messages.ts

@@ -108,6 +108,55 @@ export function insertAfterBlockCloserLoweredWarning(line: number): string {
 export function insertAfterBlockUnresolvedLoweredWarning(line: number): string {
 	return `\`INS.BLK.POST ${line}:\` could not resolve a syntactic block on line ${line}, so it was applied as plain \`INS.POST ${line}:\`. Verify the landing line; anchor on a line that OPENS a construct.`;
 }
+/**
+ * A one-sided boundary echo whose payload is too short to be the widened
+ * range's full content: dropping the echo deletes range line(s) the payload
+ * never restates (the "widened range" reading), while the "range shifted by
+ * the echo" reading keeps them. The readings produce different files, so the
+ * edit is rejected instead of repaired.
+ */
+export function ambiguousBoundaryEchoMessage(
+	startLine: number,
+	endLine: number,
+	side: "leading" | "trailing",
+	count: number,
+): string {
+	const where =
+		side === "leading"
+			? `opens by restating the ${count} line(s) just above the range`
+			: `ends by restating the ${count} line(s) just below the range`;
+	return (
+		`\`SWAP ${startLine}${HL_RANGE_SEP}${endLine}:\` rejected: the body ${where}, ` +
+		`but is too short to be the full final content of the widened range — applying it as-is or ` +
+		`auto-repairing would delete range line(s) the body never restates. ` +
+		`Re-issue with the range covering exactly the lines that change and the body as their complete ` +
+		`final content: drop the restated keeper from the body, or widen the range to consume it.`
+	);
+}
+
+/**
+ * A replacement range deletes trailing structural closer(s) the payload never
+ * restates, and nothing anchors the payload inside the block those closers
+ * terminate: the payload has no unmatched opener for them and its indentation
+ * is not deeper than the closer. Sparing the closer would have to guess
+ * whether the payload belongs before it (inside the block) or after it (a
+ * sibling), so the edit is rejected instead of repaired.
+ */
+export function ambiguousCloserSpareMessage(
+	startLine: number,
+	endLine: number,
+	closerLine: number,
+	count: number,
+): string {
+	const closers = count === 1 ? `line ${closerLine}` : `lines ${closerLine}-${closerLine + count - 1}`;
+	return (
+		`\`SWAP ${startLine}${HL_RANGE_SEP}${endLine}:\` rejected: the range deletes the closing-delimiter ` +
+		`${closers} but the body never restates it, and the body claims no position inside that block ` +
+		`(no unmatched opener, indentation not deeper than the closer) — whether the new content belongs ` +
+		`before or after the closer is ambiguous. Restate the closer in the body at the intended position, ` +
+		`or use \`INS.PRE ${closerLine}:\` / \`INS.POST ${closerLine}:\` instead.`
+	);
+}
 
 /**
  * Internal invariant: `applyEdits` received an unresolved `replace_block N:`