things-api 0.19.0 → 0.19.1

package/dist/write/commands.js

@@ -2,6 +2,7 @@ import { localToday, zonedWallInstant } from "../model/dates.js";
 import { byUuid } from "../read/detail.js";
 import { manualLogDateEpoch, pendingLogCount } from "../read/log-boundary.js";
 import { isLooseRef } from "../read/pseudo-area.js";
+import { RESOLUTION_TIMESTAMP_EXPECTED } from "../surface-copy.js";
 import { areaMemberCounts, childTagTitles, classifyHeadingConvert, classifyHeadingDissolve, classifyHeadingMoveToProject, classifyProjectRepeat, computeHeadingMovePre, computeReorderPre, emptyPreState, loadTarget, projectChildren, projectStatus, projectSubtreeUuids, resolveArea, resolveHeading, resolveProject, resolveTag, sameTitleTaskUuids, seriesRowUuids, trashedCount, } from "./pre-state.js";
 import { assertNotesModesExclusive, normalizeReminder, updateAssertions, updateWireParams, whenAssertions, whenWithReminder, } from "./update-fields.js";
 import { resolveTagRefs } from "./tag-refs.js";
@@ -10,7 +11,7 @@ import { assertRepeatRule } from "./repeat-rule.js";
 import { assessOffRuleFirst, deadlineDriveNext, deriveFixedAnchor } from "./repeat-anchor.js";
 import { expectedRuleAssertions } from "./repeat-asserts.js";
 import { escapeAppleScript } from "./vectors/applescript.js";
-import { areaReorderSidebarRecipe, convertToProjectRecipe, dissolveHeadingRecipe, headingConvertToProjectRecipe, moveHeadingToProjectRecipe, makeRepeatingRecipe, createNextCopyRecipe, pauseRepeatRecipe, projectMakeRepeatingRecipe, projectPauseRepeatRecipe, projectRescheduleRepeatRecipe, projectResumeRepeatRecipe, rescheduleRepeatRecipe, resumeRepeatRecipe, } from "./vectors/ui-recipes.js";
+import { areaReorderSidebarRecipe, convertToProjectRecipe, dissolveHeadingRecipe, headingConvertToProjectRecipe, moveHeadingChordRecipe, moveHeadingToProjectRecipe, makeRepeatingRecipe, createNextCopyRecipe, pauseRepeatRecipe, projectMakeRepeatingRecipe, projectPauseRepeatRecipe, projectRescheduleRepeatRecipe, projectResumeRepeatRecipe, rescheduleRepeatRecipe, resumeRepeatRecipe, } from "./vectors/ui-recipes.js";
 import { buildRepeatingFingerprint } from "./verify/delta.js";
 // ------------------------------------------------------------------ helpers
 function thingsUrl(command, params, token) {
@@ -1416,22 +1417,26 @@ const reorder = {
 };
 // ---- resolution-timestamp normalization (§5 of the plan) ------------------
 /**
- * Parse an ISO date (`2025-01-15`) OR datetime (`2025-01-15T09:30[:ss]`) and
- * resolve it to a single UTC instant in the effective `zone`. A date-only value
- * lands at NOON in that zone (B-DATEONLY: noon decodes to the intended calendar
- * date in every zone; midnight can slip a day). A datetime is read as wall-clock
- * time in the effective zone. `zone` undefined = the process-local (app host)
- * zone, which for a local CLI run IS the app's own zone.
+ * Parse a date (`2025-01-15`) OR datetime (`2025-01-15T09:30[:ss]`, or the same
+ * value spelled with a space — `2025-01-15 09:30`) and resolve it to a single
+ * UTC instant in the effective `zone`. Both separators are first-class
+ * spellings of the SAME instant: the space form is what a human (or a shell
+ * heredoc) types, the `T` form is what a serializer emits, and neither is
+ * rewritten into the other. A date-only value lands at NOON in that zone
+ * (B-DATEONLY: noon decodes to the intended calendar date in every zone;
+ * midnight can slip a day). A datetime is read as wall-clock time in the
+ * effective zone. `zone` undefined = the process-local (app host) zone, which
+ * for a local CLI run IS the app's own zone.
  */
 export function resolveResolutionInstant(input, zone) {
     const dateOnly = /^(\d{4}-\d{2}-\d{2})$/.exec(input);
     if (dateOnly !== null)
         return zonedWallInstant(dateOnly[1], 12, 0, 0, zone);
-    const dt = /^(\d{4}-\d{2}-\d{2})T(\d{2}):(\d{2})(?::(\d{2}))?$/.exec(input);
+    const dt = /^(\d{4}-\d{2}-\d{2})[T ](\d{2}):(\d{2})(?::(\d{2}))?$/.exec(input);
     if (dt !== null) {
         return zonedWallInstant(dt[1], Number(dt[2]), Number(dt[3]), dt[4] === undefined ? 0 : Number(dt[4]), zone);
     }
-    throw new RangeError(`invalid timestamp "${input}" — expected an ISO date (YYYY-MM-DD) or datetime (YYYY-MM-DDTHH:mm)`);
+    throw new RangeError(`invalid timestamp "${input}" — expected ${RESOLUTION_TIMESTAMP_EXPECTED}`);
 }
 const pad2 = (n) => String(n).padStart(2, "0");
 /** The host-local calendar date (`YYYY-MM-DD`) an instant renders as — what the verify layer observes for stopped/created. */
@@ -1662,9 +1667,18 @@ const headingAdd = {
         });
     },
 };
+/**
+ * project.move-heading — within-project heading order, on the ARROW-CHORD ui
+ * vector (CHORDMH1, on the HEADORD1 law). Things 3.23 left the private reorder
+ * command declared and inert, which took heading order offline entirely; the
+ * replacement is the app's own keyboard affordance (⌘↑/⌘↓/⌘⌥↑/⌘⌥↓ on a selected
+ * heading row), driven as a verified closed loop by src/write/vectors/ui-chord.ts.
+ * This is the ONE reorder that leaves the `privateReorderIsNoOp` range — every
+ * other scope still routes through its own gate.
+ */
 const projectMoveHeading = {
     op: "project.move-heading",
-    hazards: ["H-UNKNOWN-DESTINATION", "H-HEADING-ORDER"],
+    hazards: ["H-UNKNOWN-DESTINATION", "H-HEADING-ORDER", "H-UI-DRIVE"],
     preRead(db, params) {
         const pre = emptyPreState();
         pre.destProject = resolveProject(db, params.project);
@@ -1672,24 +1686,41 @@ const projectMoveHeading = {
         return pre;
     },
     expectedDelta(pre) {
-        // The reorder wire re-ranks the FULL heading list; verify the whole target
-        // order (strictly ascending "index"). Children follow their heading (scf
-        // P1), so no per-child assertion is needed.
-        return { mode: "ordering", key: "index", sequence: pre.headingMove?.targetOrder ?? [] };
+        const move = pre.headingMove;
+        return {
+            mode: "ordering",
+            key: "index",
+            // The full end state: every heading of the project, strictly ascending.
+            sequence: move?.targetOrder ?? [],
+            // RRF1: the headings the caller did NOT name must hold their EXACT prior
+            // rank — a chord is a single-row write, and this is what proves the one
+            // that landed was the row the plan addressed (a heading row exposes no
+            // title to read the selection back through).
+            unchanged: move?.untouched ?? [],
+            // Children follow their heading through an intact FK, un-renumbered and
+            // un-touched (no userModificationDate bump — that is what `frozen` adds).
+            frozen: (move?.children ?? []).map((c) => ({
+                uuid: c.uuid,
+                assert: [{ field: "heading.uuid", equals: c.heading }],
+            })),
+            ...(move?.targetOrder[0] !== undefined && { subject: move.targetOrder[0] }),
+        };
     },
-    compile(_params, vector, pre) {
-        // The same native private-reorder wire the old `reorder --scope headings`
-        // used (experimental — gated by allow-experimental + the sdef canary),
-        // fed the computed full order.
-        if (vector !== "applescript")
+    compile(params, vector, pre) {
+        if (vector !== "ui")
             unsupportedVector(this.op, vector);
-        // #V11: send the MINIMAL front-cluster wire, not the full order — an archived
-        // heading that need not move stays out of it (untouched, HEADSORT H-UNSWEPT);
-        // any archived heading the target FORCES in (pre.headingMove.reopened) is
-        // reopened and disclosed. NEVER put un-targeted rows into the wire.
-        const order = pre.headingMove?.wire ?? [];
-        return osa(`${PRIVATE_REORDER_COMMAND} project id ${q(pre.destProject?.resolved?.uuid ?? "")} ` +
-            `with ids ${q(order.join(","))}`);
+        const move = pre.headingMove;
+        if (move === null || move.problems.length > 0) {
+            // The membership/anchor refusals are surfaced by H-HEADING-ORDER
+            // before compile; reaching here with one means the guard was bypassed.
+            throw new Error(`project.move-heading: ${move === null ? "no heading move computed (guard bypassed?)" : move.problems.join("; ")}`);
+        }
+        // The movee set is EXACTLY what the caller named — never derived from the
+        // untouched set, which fences a different (smaller) thing: a bystander whose
+        // POSITION shifts is still a bystander no chord may move.
+        return uiDrive(moveHeadingChordRecipe(pre.destProject?.resolved?.uuid ?? "", move.targetOrder, [
+            ...params.headings,
+        ]));
     },
 };
 const todoClearDatedReminder = {
@@ -1738,11 +1769,41 @@ function uiDrive(recipe) {
 // the validator from commands.ts; the implementation + the full combination
 // matrix live in repeat-rule.ts.
 export { assertRepeatRule };
+/**
+ * The recipe extras for a MAKE-REPEATING drive: {@link ruleExtras} with the
+ * "Next:" drive date deadline-adjusted, exactly as {@link reschedRuleExtras}
+ * does for a reschedule.
+ *
+ * ONE MEANING FOR `next`, ONE PLACE THAT SHIFTS IT (NEXTPOP1). `next` is the
+ * requested first-occurrence START — what `--when` means to a caller — in every
+ * params bag, at every layer. A DEADLINED rule anchors the dialog on the
+ * DEADLINE (YANCH1 #493), so the date the "Next:" control must carry is
+ * `next + startDaysEarlier`; that conversion belongs to the compile, where the
+ * dialog is, and nowhere else.
+ *
+ * It used to happen upstream too: the promote orchestrators shifted `next`
+ * before handing the bag to this op, so the SAME field meant a START coming from
+ * a caller and a DUE date coming from a composite. Everything downstream that
+ * shifts — `assessOffRuleFirst`, via `assertRepeatRule` in preRead — then shifted
+ * a second time, and a deadlined MONTHLY promote was refused before it ran with
+ * a message about a date the caller never asked for (`--deadline 2026-08-20`
+ * + `--when 2026-08-06` → "a first occurrence on 2026-08-20 would not hold",
+ * measured in-lab). The orchestrators now pass `--when` through unshifted.
+ */
+function makeRuleExtras(params) {
+    const base = ruleExtras(params);
+    const drive = deadlineDriveNext(params);
+    return drive !== undefined ? { ...base, next: drive } : base;
+}
 /**
  * The extended-vocabulary fields of a rule as a recipe `extras` bag, including
  * ONLY the keys that are present (exactOptionalPropertyTypes: never set an
  * optional field to undefined). A bare `{ uuid, frequency, interval }` yields
  * `{}`, so the recipe drives exactly the certified two-control path.
+ *
+ * `next` is copied through VERBATIM — a START. Every compile that drives the
+ * dialog wraps this with its own deadline shift ({@link makeRuleExtras},
+ * {@link reschedRuleExtras}); this function never shifts (NEXTPOP1).
  */
 function ruleExtras(params) {
     return {
@@ -1785,15 +1846,31 @@ function reschedEffParams(params) {
  * `--when` is the scheduled START, but a deadlined rule anchors on the DEADLINE,
  * so the dialog's "Next:" field is driven with `when + startDaysEarlier` and the
  * app back-shifts the instance start to `--when`. The expectedDelta keeps the RAW
- * `params.next` (the cursor asserts the START). make/add-repeating apply this shift
- * upstream (promote-clone.ts) and pass an already-adjusted rule, so only the
- * reschedule compile needs it here.
+ * `params.next` (the cursor asserts the START). {@link makeRuleExtras} is the
+ * make/add-repeating twin of this — the shift lands in the compile on every verb
+ * that drives the dialog, and nowhere upstream of it (NEXTPOP1).
  */
 function reschedRuleExtras(params) {
     const base = ruleExtras(reschedEffParams(params));
     const drive = deadlineDriveNext(params);
     return drive !== undefined ? { ...base, next: drive } : base;
 }
+/**
+ * The rule-vocabulary keys this reschedule REQUESTED — the input to the
+ * unexplained-delta check (CGRD1 guard 3): every decoded-rule field that moves
+ * must be attributable to one of these, or to a mapped co-mover of one.
+ *
+ * Built from the EFFECTIVE params, the same bag the recipe drives, so a
+ * `--when`-only reschedule that DERIVES a calendar anchor counts that anchor as
+ * requested rather than as an unexplained move (RSPA1 / YANCH1 #493) — the drive
+ * really does address those pop-ups. `uuid` is the target, not a rule field.
+ */
+function requestedRuleKeys(params) {
+    const eff = reschedEffParams(params);
+    return Object.entries(eff)
+        .filter(([key, value]) => key !== "uuid" && value !== undefined)
+        .map(([key]) => key);
+}
 /** ui ops all guard existence/type + the H-UI-DRIVE acknowledgement. */
 const UI_HAZARDS = ["H-UNKNOWN-DESTINATION", "H-UI-DRIVE"];
 const todoMakeRepeating = {
@@ -1841,7 +1918,7 @@ const todoMakeRepeating = {
     compile(params, vector) {
         if (vector !== "ui")
             unsupportedVector(this.op, vector);
-        return uiDrive(makeRepeatingRecipe(params.uuid, params.frequency, params.interval, ruleExtras(params)));
+        return uiDrive(makeRepeatingRecipe(params.uuid, params.frequency, params.interval, makeRuleExtras(params)));
     },
 };
 const todoRescheduleRepeat = {
@@ -1879,6 +1956,12 @@ const todoRescheduleRepeat = {
                 includeCursor: assessOffRuleFirst(eff)?.kind !== "honored",
             }),
             capture: [{ field: "repeating.rule" }, { field: "repeating.deadlined" }],
+            // UNEXPLAINED-DELTA DETECTION (CGRD1 guard 3). The assertions above prove
+            // the requested rule landed; this proves nothing ELSE did. A reschedule
+            // rewrites an EXISTING rule, so there is a full pre-state to diff against —
+            // which is why make-repeating / add-repeating do not carry it: they mint the
+            // rule, so every field is new by construction and there is nothing to compare.
+            collateral: { requested: requestedRuleKeys(params) },
         };
     },
     compile(params, vector) {
@@ -2018,6 +2101,12 @@ const projectRescheduleRepeat = {
                 includeCursor: assessOffRuleFirst(eff)?.kind !== "honored",
             }),
             capture: [{ field: "repeating.rule" }, { field: "repeating.deadlined" }],
+            // UNEXPLAINED-DELTA DETECTION (CGRD1 guard 3). The assertions above prove
+            // the requested rule landed; this proves nothing ELSE did. A reschedule
+            // rewrites an EXISTING rule, so there is a full pre-state to diff against —
+            // which is why make-repeating / add-repeating do not carry it: they mint the
+            // rule, so every field is new by construction and there is nothing to compare.
+            collateral: { requested: requestedRuleKeys(params) },
         };
     },
     compile(params, vector) {
@@ -2127,7 +2216,7 @@ const projectMakeRepeating = {
             // Unreachable in practice: the guards block refuse/anytime before compile.
             throw new Error("project.make-repeating: no selectable-row taxonomy resolved (guard bypassed?)");
         }
-        return uiDrive(projectMakeRepeatingRecipe(tax.containerReveal, params.uuid, tax.title, params.frequency, params.interval, ruleExtras(params)));
+        return uiDrive(projectMakeRepeatingRecipe(tax.containerReveal, params.uuid, tax.title, params.frequency, params.interval, makeRuleExtras(params)));
     },
 };
 // project.add-repeating is delivered by the runAddRepeatingProject