ossclip 0.1.17 → 0.1.19

package/src/produce.ts

@@ -15,7 +15,6 @@ import {
   applyOverrides,
   applyRepairs,
   assembleScenes,
-  applyCaptionEdits,
   buildCaptionLines,
   buildCutlist,
   buildZoomPlan,
@@ -105,6 +104,8 @@ import {
   workdirBaseName,
 } from "./stranded-overrides";
 import { editHint } from "./interactive/edit-hint";
+import { reconcileCaptionEdits } from "./caption-report";
+import { overridesWriteLine, writeOverrideDoc } from "./overrides-write";
 import { recordedProduceArgs } from "./replay-argv";
 import { renderCover, renderProduction } from "@ossclip/renderer";
 import {
@@ -1595,7 +1596,8 @@ export async function produce(inputArg: string, opts: ProduceOptions): Promise<P
     clipStarts: map.spans.map((s) => s.outIn),
   });
   // User splits (R16 §61) — after the fill so takes split like scenes, and
-  // before the final override pass so edits on the `id@ms` halves land. A
+  // before the final override pass so edits on the `id@<split id>` halves land
+  // (the suffix is the split's own minted id, §137, not its time). A
   // split whose ROOT was a graphic scene already happened once inside
   // `splitThenDropHidden` above (PLAN 2026-08-04 Task 1) — re-running it here
   // is a no-op for that scene (the split point sits exactly on the joint
@@ -1607,7 +1609,7 @@ export async function produce(inputArg: string, opts: ProduceOptions): Promise<P
   }
   const { cues: mergedCues, orphans: rawOrphans } = applyOverrides(split, overrideDoc);
   // Halves of a TAKE the user deleted after splitting: a take id only exists
-  // once the fill above runs, so its `id@ms` half couldn't have been seen by
+  // once the fill above runs, so its `id@<split id>` half couldn't have been seen by
   // `splitThenDropHidden` earlier (that pass only ever saw graphic scenes).
   // Scene halves were already caught above; this is a no-op for them. Same
   // order as the editor's live memo.
@@ -1931,22 +1933,36 @@ export async function produce(inputArg: string, opts: ProduceOptions): Promise<P
     // caption output for zero visual reason (PLAN Task A4.4).
     breakpoints: graphicCues.flatMap((c) => [c.startSec, c.endSec]),
   });
-  // The user's retyped caption words (editor, PLAN 2026-07-29 Task 7 scope
-  // (a)). Guarded per word: a stale edit — the pipeline re-derived a
-  // different word at that position — is dropped LOUDLY, never applied to
-  // the wrong word and never silently forgotten.
-  const { lines: captionLines, dropped: staleCaptionEdits } = applyCaptionEdits(
-    baseCaptionLines,
-    overrideDoc.captions,
-  );
-  const liveCaptionEdits = Object.keys(overrideDoc.captions).length - staleCaptionEdits.length;
-  if (liveCaptionEdits > 0) console.log(`▸ ${liveCaptionEdits} caption word(s) retyped by the editor`);
-  for (const d of staleCaptionEdits) {
-    console.log(
-      `  ⚠ caption edit at word ${d.index} dropped: expected "${d.expected}" there, ` +
-        `the transcript now has "${d.found}"`,
-    );
-  }
+  // §137 (Task 6 review, Critical 1): the caption half of a run — migrate the
+  // doc's keys, apply what applies, and account for the rest — is one pure
+  // pass in `caption-report.ts`, and this is its I/O.
+  //
+  // MIGRATION RUNS HERE, not only in the editor. The editor's is in memory and
+  // `edits.load` leaves the doc CLEAN, so `onRender` (which saves only when
+  // dirty) sends a user who opened an old project, saw every retype come back
+  // on screen, and clicked Render straight into this function with the
+  // untouched legacy doc — and `applyCaptionEdits` matched nothing, so the
+  // render shipped without a single retype after showing a state strictly more
+  // convincing than the truth. None of the reasoning that keeps this call out
+  // of `edit.ts` applies: `buildCaptionLines` just stamped a real `srcStart`
+  // on every word above (`captions.ts:128`), so there is nothing to backfill
+  // and no repair rule to duplicate.
+  //
+  // THE MIGRATED DOC IS WRITTEN BACK — the decision, stated: through the one
+  // sanctioned `overrides.json` write further down, with its `.bak` and atomic
+  // rename, never a second write here. A legacy key's resolvability DECAYS (it
+  // is found by the word it names, so the next re-plan that rewrites that word
+  // loses it for good), and this is the only durable repair in the product —
+  // the editor's evaporates, as Critical 1 showed. The edits it could NOT
+  // place stay in the doc regardless (`captionEditsToKeep`): they are printed
+  // by name below, and a run that cannot anchor one today is not permission to
+  // delete it — the next run, against a different cut, may place it (final
+  // review, Critical 1).
+  const captionWork = reconcileCaptionEdits(overrideDoc, baseCaptionLines);
+  overrideDoc = captionWork.doc;
+  const captionLines = captionWork.lines;
+  const captionKeysReanchored = captionWork.reanchored;
+  for (const line of captionWork.log) console.log(line);
 
   // Micro zoom punches (FINDINGS §15) reversing at real phrase breaks (§18).
   // Breaths are source-time; TimeMap has no span mapper, so both ends go
@@ -2185,23 +2201,32 @@ export async function produce(inputArg: string, opts: ProduceOptions): Promise<P
   // next run's `priorMap` then sees drift and re-anchors again, the same
   // recovery path finding 3 already has to support — never a false "nothing
   // changed" that quietly corrupts positions.
-  if (cutResult.changed) {
-    // Keep a `.bak` of whatever was on disk first — the same safety net
-    // `saveConfigPatch` keeps for a config file it's about to replace —
-    // before overwriting the user's own data. Atomic write via tmp+rename,
-    // matching the edit server's own `PUT /overrides` handler: the producer
-    // or a live editor session may read this file at any moment, and a
-    // half-written document would be worse than a stale one.
-    try {
-      const raw = await readFile(overridesPath, "utf8");
-      await writeFile(`${overridesPath}.bak`, raw);
-    } catch {
-      // Nothing on disk to back up (first cut ever applied here) — fine.
-    }
-    const tmp = `${overridesPath}.tmp`;
-    await writeFile(tmp, JSON.stringify(overrideDoc, null, 2));
-    await rename(tmp, overridesPath);
-    console.log("▸ overrides.json re-anchored to the new cut and saved (previous copy kept as .bak)");
+  // `cutResult.changed` OR a §137 caption-key migration that actually MOVED an
+  // edit — the second is why this is no longer a bare cut check. Both are
+  // re-anchorings of the user's doc to something the pipeline just recomputed,
+  // and both go through the one sanctioned write; a separate write for the
+  // migration would be a SECOND sanctioned write, which the comment above
+  // exists to prevent.
+  //
+  // "ACTUALLY MOVED" is load-bearing and was not there at first (final review,
+  // Critical 2). Gated on "the migration reported something" instead, this
+  // fires on a run that repaired NOTHING — and since a caption migration is
+  // independent of the cut, it fires on runs where the pre-§137 gate wrote
+  // nothing at all.
+  //
+  // THEY DO NOT SHARE THE `.bak`, THOUGH, and that is the rest of the same
+  // finding (final review round 2). `refreshBackup: cutResult.changed`, never
+  // the gate: on the field workdir the caption migration re-anchors THREE
+  // edits, so the gate legitimately fires while `cutResult.changed` is false —
+  // and an unconditional refresh would then copy the already-damaged
+  // `overrides.json` over `overrides.json.bak`, which is that user's only
+  // pre-cut save and the only artefact their deleted split half can still be
+  // recovered from (`legacySplitId`). Repairing the captions would destroy the
+  // evidence for the split. `writeOverrideDoc` carries the full argument for
+  // why a caption-only write has nothing worth backing up.
+  if (cutResult.changed || captionKeysReanchored) {
+    await writeOverrideDoc(overridesPath, overrideDoc, { refreshBackup: cutResult.changed });
+    console.log(overridesWriteLine(cutResult.changed));
   }
 
   if (!opts.render) {

package/src/program.ts

@@ -7,6 +7,21 @@ import { CleanupLevelSchema, SceneComponentIdSchema } from "@ossclip/core";
 import { STUDIO_ENTRY } from "@ossclip/renderer";
 import { loadEnvFiles } from "./env";
 import { produce } from "./produce";
+// The one interactive import that is STATIC rather than `await import()`: the
+// `resetInputSource()` run boundary in `buildProgram` has to run synchronously
+// while the program is being built, and `buildProgram` cannot await. The graph
+// already loads @ossclip/renderer and @ossclip/scenes eagerly through
+// produce.ts, so clack riding along costs ~14ms on a ~320ms startup — cheap
+// enough not to trade for a racy fire-and-forget import (§136).
+//
+// Consequence worth stating for whoever edits ask-input.ts next: this module,
+// and everything it imports (picker.ts, prompts.ts → @clack/prompts,
+// suggest-inputs.ts), is now EAGER on every ossclip invocation — `--version`
+// and `doctor` included. A heavy dependency added there is no longer free.
+// Removing this line to "restore laziness" deletes the run boundary with it:
+// `input_source` would then report the PREVIOUS run's branch, and the only
+// test that notices is the buildProgram case in telemetry.test.ts.
+import { inputSourceUsed, resetInputSource } from "./interactive/ask-input";
 import { setReplayArgv } from "./replay-argv";
 import {
   bootstrapTelemetry,
@@ -38,6 +53,19 @@ const envFiles = loadEnvFiles();
 export function buildProgram(): Command {
   const program = new Command();
 
+  // §136: the input-source telemetry is module state, so something has to say
+  // when a RUN begins. Not the produce action — every wizard route re-enters
+  // that same action through `program.parseAsync` (§129), so a reset there
+  // fires on the re-entered parse, AFTER `askInput` recorded the branch, and
+  // `input_source` would read "argv" for every wizard run: the feature would
+  // measure exactly nothing. Nor is the process the boundary — a batch or REPL
+  // driver runs produce more than once, and the second run would report the
+  // first one's branch. The PROGRAM CONSTRUCTION is the boundary: commander 12
+  // keeps option state across parseAsync calls (see the bare-`produce` refusal
+  // below), so any batch has to rebuild the program per run anyway, which makes
+  // one reset per `buildProgram` exactly one per run in both cases.
+  resetInputSource();
+
   // Before dispatch, so the one-time first-run notice precedes any command's
   // own output. Inert in this repo's tests by construction: while POSTHOG_KEY
   // is the placeholder, bootstrap touches no disk and sends nothing (FINDINGS
@@ -433,6 +461,10 @@ export function buildProgram(): Command {
           render: opts.render !== false,
           source_duration_bucket: durationBucket(result.sourceDurationSec),
           scenes: result.sceneCount,
+          // Which branch of the input prompt was used — a branch name, never
+          // the path itself (§136). The picker exists because typing a path
+          // blocked non-technical users; this is how we find out if it helped.
+          input_source: inputSourceUsed(),
         });
         if (!telemetry.disabled) {
           telemetry.state.produceCount += 1;

package/editor-dist/assets/index-C8IPo60X.css

@@ -1 +0,0 @@
-.ossclip-scroll-list{scrollbar-width:thin;scrollbar-color:#3a3a44 transparent}.ossclip-scroll-list::-webkit-scrollbar{width:8px}.ossclip-scroll-list::-webkit-scrollbar-track{background:transparent}.ossclip-scroll-list::-webkit-scrollbar-thumb{background:#3a3a44;border-radius:4px}