@ijfw/memory-server 1.3.0 → 1.4.0

package/src/override-use-registry.js

@@ -0,0 +1,307 @@
+/**
+ * override-use-registry.js
+ *
+ * IJFW v1.4.0 Wave 3 / t14 — Cross-Project Override-Use Registry
+ *
+ * Per F8: replace SHA256 fingerprint + BM25 search with a STRUCTURED
+ * registry. When a user has the same overrides active in N+ projects, the
+ * prelude can suggest promoting them to user defaults.
+ *
+ * Storage: ~/.ijfw/state/override-use.json (kept SEPARATE from
+ * active-overrides.json per R12 — different concerns. active-overrides.json
+ * tracks per-project state for the resolver; this registry tracks
+ * cross-project signal for promotion intelligence and can include
+ * project_type and other analytic fields the resolver doesn't need).
+ *
+ * Shape:
+ *   {
+ *     "schema_version": "1.0",
+ *     "projects": {
+ *       "/abs/path/to/project": {
+ *         "project_type": "book",
+ *         "active_overrides": [
+ *           { "preset": "book", "scope": "project",
+ *             "applied_at": "ISO-8601" }
+ *         ]
+ *       }
+ *     }
+ *   }
+ *
+ * Zero new prod deps. Built-in Node only.
+ */
+
+import fs from 'node:fs/promises';
+import path from 'node:path';
+import os from 'node:os';
+
+const SCHEMA_VERSION = '1.0';
+
+// ---------------------------------------------------------------------------
+// Path helpers — read os.homedir()/HOME at call time so tests can swap HOME
+// via process.env between calls.
+// ---------------------------------------------------------------------------
+
+function homeDir() {
+  // os.homedir() honours process.env.HOME on POSIX, which is what the smoke
+  // test in the t14 brief assumes. Use os.homedir() to keep cross-platform
+  // semantics aligned with the rest of the codebase.
+  return os.homedir();
+}
+
+function registryPath() {
+  return path.join(homeDir(), '.ijfw', 'state', 'override-use.json');
+}
+
+function settingsPath() {
+  return path.join(homeDir(), '.ijfw', 'state', 'settings.json');
+}
+
+// ---------------------------------------------------------------------------
+// IO
+// ---------------------------------------------------------------------------
+
+async function readRegistry() {
+  const p = registryPath();
+  try {
+    const raw = await fs.readFile(p, 'utf8');
+    const parsed = JSON.parse(raw);
+    if (!parsed || typeof parsed !== 'object') {
+      return { schema_version: SCHEMA_VERSION, projects: {} };
+    }
+    if (!parsed.projects || typeof parsed.projects !== 'object') {
+      parsed.projects = {};
+    }
+    if (!parsed.schema_version) parsed.schema_version = SCHEMA_VERSION;
+    return parsed;
+  } catch (err) {
+    if (err && err.code === 'ENOENT') {
+      return { schema_version: SCHEMA_VERSION, projects: {} };
+    }
+    if (err instanceof SyntaxError) {
+      return { schema_version: SCHEMA_VERSION, projects: {} };
+    }
+    throw err;
+  }
+}
+
+async function writeRegistry(state) {
+  const p = registryPath();
+  await fs.mkdir(path.dirname(p), { recursive: true });
+  const tmp = `${p}.tmp`;
+  await fs.writeFile(tmp, JSON.stringify(state, null, 2), 'utf8');
+  await fs.rename(tmp, p);
+}
+
+async function readSettings() {
+  try {
+    const raw = await fs.readFile(settingsPath(), 'utf8');
+    const parsed = JSON.parse(raw);
+    return parsed && typeof parsed === 'object' ? parsed : {};
+  } catch {
+    return {};
+  }
+}
+
+// ---------------------------------------------------------------------------
+// Public API
+// ---------------------------------------------------------------------------
+
+/**
+ * Record (or update) an active override for a project in the registry.
+ * Idempotent — re-recording the same (project, preset) updates applied_at
+ * rather than duplicating the entry.
+ *
+ * @param {string} projectRoot
+ * @param {string} preset
+ * @param {string} scope          'base' | 'user' | 'org' | 'project'
+ * @param {string} [project_type] auto-detected project type, defaults to
+ *                                whatever is already on file or 'unknown'.
+ */
+export async function recordOverrideUse(projectRoot, preset, scope, project_type) {
+  if (typeof projectRoot !== 'string' || !projectRoot) {
+    throw new Error('recordOverrideUse: projectRoot must be a non-empty string');
+  }
+  if (typeof preset !== 'string' || !preset) {
+    throw new Error('recordOverrideUse: preset must be a non-empty string');
+  }
+  if (typeof scope !== 'string' || !scope) {
+    throw new Error('recordOverrideUse: scope must be a non-empty string');
+  }
+
+  const state = await readRegistry();
+  const proj = state.projects[projectRoot] || { active_overrides: [] };
+  if (!Array.isArray(proj.active_overrides)) proj.active_overrides = [];
+  if (project_type && typeof project_type === 'string') {
+    proj.project_type = project_type;
+  } else if (!proj.project_type) {
+    proj.project_type = 'unknown';
+  }
+
+  const appliedAt = new Date().toISOString();
+  const existingIdx = proj.active_overrides.findIndex(
+    (o) => o && o.preset === preset
+  );
+  if (existingIdx >= 0) {
+    proj.active_overrides[existingIdx] = {
+      ...proj.active_overrides[existingIdx],
+      preset,
+      scope,
+      applied_at: appliedAt,
+    };
+  } else {
+    proj.active_overrides.push({ preset, scope, applied_at: appliedAt });
+  }
+  state.projects[projectRoot] = proj;
+  await writeRegistry(state);
+}
+
+/**
+ * Remove a project's record of having an override active. Leaves the project
+ * entry in place with an empty active_overrides array so project_type and
+ * any other analytic fields persist for future signal.
+ *
+ * @param {string} projectRoot
+ * @param {string} preset
+ */
+export async function removeOverrideUse(projectRoot, preset) {
+  const state = await readRegistry();
+  const proj = state.projects[projectRoot];
+  if (!proj || !Array.isArray(proj.active_overrides)) return;
+  proj.active_overrides = proj.active_overrides.filter(
+    (o) => !(o && o.preset === preset)
+  );
+  // Intentionally do NOT delete state.projects[projectRoot] — see jsdoc.
+  state.projects[projectRoot] = proj;
+  await writeRegistry(state);
+}
+
+/**
+ * Find every project that has `preset` recorded as active.
+ *
+ * @param {string} preset
+ * @returns {Promise<Array<{project: string, project_type: string, applied_at: string}>>}
+ */
+export async function findProjectsWithOverride(preset) {
+  const state = await readRegistry();
+  const out = [];
+  for (const [project, entry] of Object.entries(state.projects || {})) {
+    if (!entry || !Array.isArray(entry.active_overrides)) continue;
+    const hit = entry.active_overrides.find(
+      (o) => o && o.preset === preset
+    );
+    if (hit) {
+      out.push({
+        project,
+        project_type: entry.project_type || 'unknown',
+        applied_at: hit.applied_at,
+      });
+    }
+  }
+  return out;
+}
+
+/**
+ * Find projects whose recorded override SET is similar (Jaccard) to
+ * currentOverrides above threshold. Excludes opts.excludeProject if given.
+ *
+ * @param {string[]} currentOverrides  preset names
+ * @param {number}   [threshold=0.5]
+ * @param {{excludeProject?: string}} [opts]
+ * @returns {Promise<Array<{project: string, project_type: string, overrides: string[], similarity: number}>>}
+ */
+export async function findProjectsWithSimilarOverrideSet(
+  currentOverrides,
+  threshold = 0.5,
+  opts = {}
+) {
+  if (!Array.isArray(currentOverrides) || currentOverrides.length === 0) {
+    return [];
+  }
+  const exclude = opts && typeof opts.excludeProject === 'string'
+    ? opts.excludeProject
+    : null;
+  const current = new Set(currentOverrides);
+  const state = await readRegistry();
+  const out = [];
+  for (const [project, entry] of Object.entries(state.projects || {})) {
+    if (exclude && project === exclude) continue;
+    if (!entry || !Array.isArray(entry.active_overrides)) continue;
+    const theirs = new Set(
+      entry.active_overrides
+        .filter((o) => o && typeof o.preset === 'string')
+        .map((o) => o.preset)
+    );
+    if (theirs.size === 0) continue;
+    let intersection = 0;
+    for (const p of current) if (theirs.has(p)) intersection += 1;
+    const union = new Set([...current, ...theirs]).size;
+    const similarity = union === 0 ? 0 : intersection / union;
+    if (similarity >= threshold) {
+      out.push({
+        project,
+        project_type: entry.project_type || 'unknown',
+        overrides: Array.from(theirs),
+        similarity,
+      });
+    }
+  }
+  // Sort highest similarity first for deterministic prelude output.
+  out.sort((a, b) => b.similarity - a.similarity || a.project.localeCompare(b.project));
+  return out;
+}
+
+/**
+ * Compose a promote-to-user-defaults suggestion when N+ projects share the
+ * current project's override set. Returns null if the threshold is not met.
+ *
+ * Threshold is configurable via ~/.ijfw/state/settings.json
+ * `override_promote_min_matches` (default 3) or opts.minMatches.
+ *
+ * @param {string}   currentProjectRoot
+ * @param {string[]} currentOverrides
+ * @param {{minMatches?: number, threshold?: number}} [opts]
+ * @returns {Promise<null | {message: string, projects: string[], suggestion: string}>}
+ */
+export async function getPromoteSuggestion(currentProjectRoot, currentOverrides, opts = {}) {
+  if (!Array.isArray(currentOverrides) || currentOverrides.length === 0) {
+    return null;
+  }
+  const state = await readRegistry();
+  const projectCount = Object.keys(state.projects || {}).length;
+  if (projectCount < 2) return null;
+
+  const settings = await readSettings();
+  const configuredMin = Number.isInteger(settings.override_promote_min_matches)
+    ? settings.override_promote_min_matches
+    : null;
+  const minMatches = Number.isInteger(opts.minMatches)
+    ? opts.minMatches
+    : (configuredMin ?? 3);
+  const threshold = typeof opts.threshold === 'number' ? opts.threshold : 0.5;
+
+  const matches = await findProjectsWithSimilarOverrideSet(
+    currentOverrides,
+    threshold,
+    { excludeProject: currentProjectRoot }
+  );
+  if (matches.length < minMatches) return null;
+
+  const presetList = currentOverrides.slice().sort().join(', ');
+  const presetArgs = currentOverrides.slice().sort().join(' ');
+  const message =
+    `You have [${presetList}] active in ${matches.length} other projects. ` +
+    `Consider promoting to user defaults so new projects pick them up automatically.`;
+  return {
+    message,
+    projects: matches.map((m) => m.project),
+    suggestion: `ijfw override promote --scope user ${presetArgs}`,
+  };
+}
+
+// Test seam — internal-only, do not import in production code.
+export const __test = {
+  registryPath,
+  settingsPath,
+  readRegistry,
+  writeRegistry,
+};

package/src/overrides/presets/academic.md

@@ -0,0 +1,101 @@
+---
+extends: []
+scope: base
+skill: ijfw-critique
+---
+
+# Academic / Research Writing Critique Preset
+
+This preset adapts `ijfw-critique` for academic papers, dissertations,
+literature reviews, conference submissions, and grant proposals. It
+replaces the default rubric, evidence, and output-format sections so
+the critique focuses on the standards of scholarly argument.
+
+<!-- ijfw-override: rubric -->
+Evaluate the manuscript against these criteria. Score each 1-5 and
+write feedback at the level of detail a reviewer for a respectable
+journal would expect.
+
+1. **Argument structure** -- Is there a thesis the rest of the paper
+   visibly supports? Can you reconstruct the argument as a numbered
+   chain of claims, or does the paper drift between adjacent topics
+   without a load-bearing spine?
+2. **Evidence sufficiency** -- For each major claim, is there enough
+   data, primary source, or prior result to carry the weight asked of
+   it? Distinguish claims that are demonstrated, claims that are
+   merely asserted, and claims that are smuggled past the reader.
+3. **Citation density and relevance** -- Are sources cited where the
+   reader needs them, not just sprinkled in the introduction? Are
+   the cited works the canonical anchors for their claims, or are
+   they convenience citations that look right but do not say what is
+   implied?
+4. **Definitional precision** -- Are key terms defined before they
+   are used, and used consistently after? Watch for slippage between
+   neighbouring concepts that the field treats as distinct.
+5. **Methodological transparency** -- Could a reader of the same
+   discipline reproduce the analysis from what is on the page?
+   Sample size, instrument, coding scheme, inclusion criteria, and
+   procedure must be legible.
+6. **Audience appropriate for field** -- Does the prose pitch itself
+   to readers of the named field at the named level, without either
+   over-explaining undergraduate fundamentals or omitting context a
+   sibling subfield would need?
+
+The artifact is scholarship. Do not evaluate it as software or as
+marketing; evaluate it as an argument that has to survive informed
+peer scrutiny.
+<!-- ijfw-override-end -->
+
+<!-- ijfw-override: evidence -->
+Quote the manuscript itself. For each observation, anchor with one
+or more of these passage types:
+
+- The **thesis statement** -- the sentence (often near the end of the
+  introduction) that names what the paper is arguing.
+- A **citation pattern** -- two or three nearby in-text citations
+  that together reveal whether sourcing is load-bearing or decorative.
+- A **gap-claim** -- a sentence asserting that the literature has
+  not yet addressed something. These deserve scrutiny: is the gap
+  real, or constructed by narrow framing?
+
+Quote 1-2 sentences and give a locator the author can find: section
+heading, paragraph position within the section, or page if the
+manuscript is paginated. Never refer to source lines, files, or
+other software locators; this is a paper.
+<!-- ijfw-override-end -->
+
+<!-- ijfw-override: output-format -->
+Return the critique as markdown with these five sections, in this
+order:
+
+## Thesis
+
+Quote the thesis as written, then restate the argument in your own
+words. If the thesis cannot be located or cannot be paraphrased
+without addition, say so.
+
+## Evidence
+
+For each major claim, name the evidence the paper offers and judge
+whether it is sufficient. Flag claims that rest on a single source
+where the field expects triangulation.
+
+## Method
+
+Summarise the method as a reader of the discipline would reconstruct
+it from the page. Note every place a competent reader would still
+have to guess.
+
+## Limitations
+
+What does the paper acknowledge, and what does it omit that a
+reviewer would press on? Be specific about which population, scope,
+or condition the conclusions cannot legitimately reach.
+
+## Missing citations
+
+List the works (or kinds of works) the argument needs but does not
+cite. Where possible, name the author or paradigm by surname rather
+than a placeholder; if you cannot, describe the work specifically
+enough that the author can search for it.
+<!-- ijfw-override-end -->

package/src/overrides/presets/book.md

@@ -0,0 +1,87 @@
+---
+extends: []
+scope: base
+skill: ijfw-critique
+---
+
+# Book / Long-form Prose Critique Preset
+
+This preset adapts `ijfw-critique` for evaluating manuscripts, chapters,
+short stories, and other long-form prose. It replaces the default
+rubric, evidence, and output-format sections so the critique focuses
+on craft of language rather than software artifacts.
+
+<!-- ijfw-override: rubric -->
+Evaluate the prose against these criteria. Score each 1-5 and explain
+in plain language; the writer is not a programmer.
+
+1. **Clarity of voice** -- Is the narrator's perspective consistent
+   from paragraph to paragraph? Does the voice feel like one mind
+   speaking, or does it drift between registers without intent?
+2. **Pacing** -- Do scenes breathe where they should and compress
+   where they should? Flag pages where summary smothers scene, or
+   where scene drags past its emotional beat.
+3. **Scene specificity** -- Are settings rendered through sensory
+   detail that only this scene could have, or does the prose lean on
+   generic furniture (a room, a street, a window)?
+4. **Dialogue authenticity** -- Does each character sound distinct
+   when their attribution is removed? Are speech rhythms tied to
+   biography, mood, and stakes, or do they all sound like the author?
+5. **Character motivation** -- Can the reader name what each
+   point-of-view character wants in this passage, and what is in the
+   way? If motivation is absent or interchangeable, call it out.
+6. **Sentence variety** -- Are sentences shaped to the moment? Look
+   for monotony of length, repeated opening structures, and reliance
+   on the same conjunctions or verbs of being.
+
+Do not evaluate code quality or technical correctness; the artifact
+is prose. If the writer included code samples inside fiction (a
+hacker character, a thriller subplot), treat them as narrative
+texture, not as systems to audit.
+<!-- ijfw-override-end -->
+
+<!-- ijfw-override: evidence -->
+Ground every observation in the manuscript itself. Quote a 1-2
+sentence passage with a chapter and page reference (or section
+heading where pages are absent). Example shape:
+
+> Chapter 3, p. 47: "The kitchen smelled like onions and old rain."
+
+Then say what the passage does well or fails to do. Never cite by
+file path, function name, or line number; this is a manuscript, not a
+codebase. Avoid bullet-only feedback that floats free of the page --
+the writer needs to find the exact passage you mean.
+
+When a pattern repeats across the manuscript, quote two or three
+short examples from different chapters rather than one long block;
+the spread itself is the evidence.
+<!-- ijfw-override-end -->
+
+<!-- ijfw-override: output-format -->
+Return the critique as markdown with these four sections, in this
+order:
+
+## Voice
+
+What does the narrator sound like, and where does that voice waver?
+Quote the clearest example of the voice working, and the clearest
+example of it slipping.
+
+## Pacing
+
+Map the energy of the passage. Where does it move, where does it
+stall, and what should be cut or expanded? Reference chapters or
+scenes by name.
+
+## Specificity
+
+Where does the prose earn its world through sensory detail, and where
+does it rely on placeholders? Quote a strong line and a generic line
+side by side.
+
+## Suggested cuts
+
+List 3-7 specific passages that could be deleted or compressed
+without losing meaning. Quote the opening words of each so the writer
+can find them quickly.
+<!-- ijfw-override-end -->

package/src/overrides/presets/campaign.md

@@ -0,0 +1,95 @@
+---
+extends: []
+scope: base
+skill: ijfw-critique
+---
+
+# Campaign / Marketing Copy Critique Preset
+
+This preset adapts `ijfw-critique` for marketing campaigns, product
+launches, email sequences, sales pages, ad copy, and other
+persuasion-driven artifacts. It replaces the default rubric,
+evidence, and output-format sections so the critique focuses on
+whether the copy moves the reader to act.
+
+<!-- ijfw-override: rubric -->
+Evaluate the campaign against these criteria. Score each 1-5 and
+write in language a copywriter or founder will recognise -- not the
+language of software engineering.
+
+1. **Call-to-action clarity** -- After the reader finishes, do they
+   know exactly one next step? Is the CTA verb-led, specific, and
+   placed where momentum is highest, or is it buried, hedged, or
+   multi-headed?
+2. **Audience fit** -- Does the copy speak to the named segment in
+   their own vocabulary, status concerns, and objections? Generic
+   "you" with no anchor is a fail; over-narrow jargon that excludes
+   the segment is also a fail.
+3. **Hook strength** -- Does the opening earn the next sentence?
+   Test the first 1-2 lines: do they promise something specific
+   enough to make the reader stay, or do they warm up before saying
+   anything?
+4. **Persuasion arc** -- Is there a recognisable shape (problem,
+   stakes, promise, proof, offer, close), and does each beat carry
+   weight? Flag missing beats and beats that repeat without adding.
+5. **Channel-appropriate format** -- Email reads like email; a
+   landing page reads like a landing page; a paid ad reads like an
+   ad. Length, density, and rhythm should match the medium and
+   placement.
+6. **Claim defensibility** -- Every superlative ("best", "only",
+   "guaranteed") and every number needs a believable source or a
+   concrete demonstration nearby. Unsupported claims cost trust.
+
+The artifact is copy, not software. Do not evaluate it as if it were
+a product or codebase; evaluate how it sells.
+<!-- ijfw-override-end -->
+
+<!-- ijfw-override: evidence -->
+Quote the actual words on the page. Pull out three anchor passages
+for almost every campaign you review:
+
+1. The **headline** (or subject line, or ad hook).
+2. The **CTA** in its surrounding sentence.
+3. The **close** -- the final paragraph or sign-off before the CTA.
+
+Quote them in full, then say what they do or fail to do. If the
+campaign has multiple sections (hero, social proof, FAQ, footer), name
+the section before the quote so the writer can navigate.
+
+Never cite by line number, file path, or any technical locator. The
+campaign is read top to bottom by a human; speak in those terms
+("the second paragraph", "the testimonial block", "the P.S. line").
+<!-- ijfw-override-end -->
+
+<!-- ijfw-override: output-format -->
+Return the critique as markdown with these five sections, in this
+order:
+
+## Hook
+
+Quote the opening line(s). Does it earn the next sentence? What
+would a sharper version look like?
+
+## Promise
+
+What is the campaign actually offering the reader, in plain language?
+Is the promise specific, believable, and worth their attention?
+
+## Proof
+
+What proof does the copy bring -- testimonials, case studies,
+numbers, demonstration, third-party validation? Where is proof
+missing where it would land hardest?
+
+## CTA
+
+Quote every call-to-action verbatim. Are they consistent in
+language? Is the primary CTA unambiguous? Where should it appear
+that it currently does not?
+
+## Friction points
+
+List the moments the reader is most likely to stall, doubt, or close
+the tab. Quote the exact phrase that creates the friction, and
+suggest a replacement.
+<!-- ijfw-override-end -->

package/src/overrides/presets/screenplay.md

@@ -0,0 +1,99 @@
+---
+extends: []
+scope: base
+skill: ijfw-critique
+---
+
+# Screenplay / Script Critique Preset
+
+This preset adapts `ijfw-critique` for film, television, and short-form
+scripts -- features, pilots, episodes, shorts, and stage plays where
+the conventions hold. It replaces the default rubric, evidence, and
+output-format sections so the critique reads like coverage from a
+working development executive, not like a code review.
+
+<!-- ijfw-override: rubric -->
+Evaluate the script against these criteria. Score each 1-5 and write
+in the language of a story editor or showrunner.
+
+1. **Scene-level conflict** -- Does every scene have a protagonist
+   pursuing a tangible want against a tangible obstacle, with the
+   scene ending in change (got it, denied, or got something worse)?
+   Flag scenes that exist only to deliver information.
+2. **Character agency** -- Do the leads drive events through choices,
+   or are they reactive vehicles for the plot? When a character
+   acts, can you trace the want and the cost? Passive protagonists
+   should be called out, especially in the first and third acts.
+3. **Pacing per act** -- Does each act do its structural work
+   (setup, escalation, crisis, climax) at roughly the page count the
+   format expects? Flag soggy middles, late inciting incidents, and
+   climaxes that arrive without setup paying off.
+4. **Dialogue distinctness per character** -- Cover the character
+   names and read three pages aloud: can you still tell who is
+   speaking? Flag characters who share vocabulary, rhythm, or
+   posture without the script earning the resemblance.
+5. **Visual storytelling** -- Are emotional beats rendered as images,
+   blocking, and behaviour, or do characters announce their feelings
+   in dialogue? Showing over telling is the rule; flag exposition
+   that should be on screen instead of in the mouth.
+6. **Genre conventions** -- Does the script honour or deliberately
+   subvert the audience contract of its genre (thriller pace, comedy
+   beats, horror dread, procedural structure)? Subversion is fine;
+   accidental drift out of genre is not.
+
+The artifact is a script. Do not treat it as code or as a marketing
+deck; treat it as something a room will shoot.
+<!-- ijfw-override-end -->
+
+<!-- ijfw-override: evidence -->
+Quote the script as it is written, in screenplay shorthand. Three
+anchor types do most of the work:
+
+- **Slug lines** -- e.g. `INT. WAREHOUSE -- NIGHT`. Quote the slug
+  when calling out scene economy, location bloat, or geography that
+  is impossible to shoot.
+- **Action lines** -- the prose between slug and dialogue. Quote
+  short passages (one to four lines) to evaluate visual specificity,
+  overwriting, or unfilmable description (an internal feeling with
+  no behaviour attached).
+- **Dialogue exchanges** -- quote a 2-6 line back-and-forth, with
+  character names, to evaluate distinctness, pace, or on-the-nose
+  exposition.
+
+Anchor each quote with the scene number or slug ("the diner scene on
+p. 22"). Never use software locators; this is industry-standard
+formatted material and should be referenced as such.
+<!-- ijfw-override-end -->
+
+<!-- ijfw-override: output-format -->
+Return the critique as markdown with these four sections, in this
+order:
+
+## Conflict per scene
+
+Walk through the script scene by scene (or in clusters for longer
+scripts) and name the want, obstacle, and change for each. Flag
+every scene that fails this test and propose either a cut or a
+reframe.
+
+## Character voices
+
+For each principal, characterise their voice in two or three traits
+(diction, rhythm, what they will and will not say). Quote a passage
+where the voice is clearest, and a passage where the character bleeds
+into another. Suggest a fix for the bleed.
+
+## Visual specificity
+
+Pull the most cinematic moments the script already contains and
+celebrate them. Then list the beats that are currently spoken or
+narrated which should instead be shown. Quote the dialogue or action
+line you would convert.
+
+## Pacing
+
+Note the page where each act break lands, where the inciting incident
+appears, and where the climax begins. Compare against format
+expectations and call out the lag or rush. Recommend two or three
+specific compressions or expansions.
+<!-- ijfw-override-end -->