@openparachute/vault 0.7.3-rc.12 → 0.7.3-rc.2

package/core/src/notes.ts

@@ -25,7 +25,6 @@ import { computeExpandedTagCounts, loadTagHierarchy, stripTagHash } from "./tag-
 import { chunkForInClause, IN_VIA_JSON_EACH, jsonEachParam } from "./sql-in.js";
 import {
   buildLiteralSearchQuery,
-  extractLiteralBoostTerms,
   SEARCH_WEIGHT_PATH,
   SEARCH_WEIGHT_CONTENT,
   type SearchMode,
@@ -1811,61 +1810,6 @@ function searchSyntaxError(rawQuery: string, err: unknown, mode: SearchMode): Qu
   });
 }
 
-/**
- * Post-rank a search result page (title axis, ratified 2026-07-17) so
- * notes whose display title (first line of content) contains EVERY boost
- * term outrank the rest — a title-match tier ahead of a body-only-match
- * tier. Stable partition: within a tier, the incoming order (FTS5
- * relevance, or an explicit `sort`) is preserved untouched — two notes
- * that both match, or both don't, keep their relative order.
- *
- * No-migration by design (see the search-seam note on `searchNotes`
- * below): re-orders the already-fetched page in memory instead of adding
- * a weighted title column to `notes_fts`, which would need a schema
- * migration + backfill. `notes_fts`'s existing `SEARCH_WEIGHT_PATH` bm25
- * weighting (above) already boosts by note PATH — a different axis from
- * the ratified title model (title = first line of CONTENT, not path).
- * This function is the one that boosts by the content-derived title.
- */
-function boostTitleMatches(notes: Note[], terms: string[]): Note[] {
-  if (terms.length === 0) return notes;
-  return notes
-    .map((note, index) => ({ note, index, titleMatch: titleMatchesAllTerms(note.content, terms) }))
-    .sort((a, b) => {
-      if (a.titleMatch === b.titleMatch) return a.index - b.index; // stable
-      return a.titleMatch ? -1 : 1;
-    })
-    .map((x) => x.note);
-}
-
-function titleMatchesAllTerms(content: string | null | undefined, terms: string[]): boolean {
-  const title = computeDisplayTitle(content);
-  if (!title) return false;
-  const lower = title.toLowerCase();
-  return terms.every((t) => lower.includes(t));
-}
-
-/**
- * Apply the title-boost post-rank to a fetched search page. Skipped
- * whenever it would fight the caller's intent:
- *   - an explicit `sort: "asc"|"desc"` means the caller wants chronological
- *     order, not relevance re-ranking;
- *   - `search_mode: "advanced"` text carries raw FTS5 syntax (boolean
- *     operators, column filters, prefix `*`) — naively tokenizing it into
- *     "terms" would misread operators as content (see
- *     `extractLiteralBoostTerms`'s doc comment). Only literal-mode queries
- *     (the default) get boosted today.
- */
-function applySearchTitleBoost(
-  notes: Note[],
-  mode: SearchMode,
-  rawQuery: string,
-  sort: "asc" | "desc" | undefined,
-): Note[] {
-  if (sort !== undefined || mode !== "literal") return notes;
-  return boostTitleMatches(notes, extractLiteralBoostTerms(rawQuery));
-}
-
 export function searchNotes(
   db: Database,
   query: string,
@@ -1902,14 +1846,6 @@ export function searchNotes(
   // The weights are our own numeric constants (not user input) interpolated
   // directly — bm25()'s weight arguments are positional per-column
   // multipliers, not general SQL expressions callers can influence.
-  //
-  // NOTE: "title" here means the note's `path` — this predates the title
-  // axis (ratified 2026-07-17), under which a note's title is its first
-  // CONTENT line, not its path. `applySearchTitleBoost` (below) is the
-  // mechanism for THAT axis: a post-rank pass over the already-scored page,
-  // not a third FTS column. The two are complementary, not redundant — a
-  // note can have a matching path with a non-matching first line, or vice
-  // versa.
   const scoreExpr = `(-1.0 * bm25(notes_fts, ${SEARCH_WEIGHT_PATH}, ${SEARCH_WEIGHT_CONTENT}))`;
 
   // `sort` honored under search (vault#551 WS2A item 3): default stays FTS5
@@ -1950,7 +1886,7 @@ export function searchNotes(
         ORDER BY ${orderBy}
         LIMIT ?
       `).all(ftsQuery, ...searchTags, limit) as (NoteRow & { score: number })[];
-      return applySearchTitleBoost(notesWithTags(db, rows, scoresById(rows)), mode, query, opts?.sort);
+      return notesWithTags(db, rows, scoresById(rows));
     } catch (err) {
       // Surface EVERY FTS5 error structured, never a raw rethrow (vault#551):
       // advanced mode expects it (the caller passed raw syntax); literal
@@ -1972,7 +1908,7 @@ export function searchNotes(
       ORDER BY ${orderBy}
       LIMIT ?
     `).all(ftsQuery, limit) as (NoteRow & { score: number })[];
-    return applySearchTitleBoost(notesWithTags(db, rows, scoresById(rows)), mode, query, opts?.sort);
+    return notesWithTags(db, rows, scoresById(rows));
   } catch (err) {
     if (err instanceof QueryError) throw err;
     throw searchSyntaxError(query, err, mode);
@@ -2766,142 +2702,10 @@ export function mergeTags(
 /** Max code points in a NoteIndex preview. */
 export const NOTE_INDEX_PREVIEW_LEN = 120;
 
-/** Max code points in a computed `displayTitle` (title axis, ratified 2026-07-17). */
-export const DISPLAY_TITLE_MAX_LEN = 120;
-
-/**
- * Bounded line-count a leading frontmatter block's closing fence is
- * searched within (see `computeDisplayTitle`). Frontmatter blocks are a
- * handful of lines in practice; capping the scan keeps a pathological
- * "content starts with `---` but never closes it" note O(1)-ish rather
- * than a full-content scan on every derivation.
- */
-const FRONTMATTER_SCAN_LINES = 100;
-
-/**
- * Shared by `computeDisplayTitle` and `computeLede`: given `content` already
- * split into `lines`, return the index of the first line that counts as the
- * start of the DOCUMENT body — after a leading closed frontmatter block, if
- * `content` opens with one (see `computeDisplayTitle`'s frontmatter-skip
- * doc for the full rationale). `0` when there's no leading frontmatter.
- */
-function skipLeadingFrontmatter(lines: string[]): number {
-  if (lines[0]?.trim() !== "---") return 0;
-  const scanLimit = Math.min(lines.length, FRONTMATTER_SCAN_LINES);
-  for (let i = 1; i < scanLimit; i++) {
-    if (lines[i]?.trim() === "---") return i + 1;
-  }
-  return 0;
-}
-
-/**
- * Derive a note's display title: the first non-empty line of `content`,
- * with a leading markdown heading marker (`#` through `######`) and its
- * following whitespace stripped, truncated to `DISPLAY_TITLE_MAX_LEN` code
- * points. `null` when content has no non-empty line (empty or
- * whitespace/heading-marker-only note).
- *
- * The ratified title model (2026-07-17): a note's title IS its first line
- * — derived from content, NEVER stored as its own column. This function is
- * the one place that derivation happens; callers (`toNoteIndex` below) call
- * it fresh at read time. Timestamp-path formatting — what a surface shows
- * in place of a `null` title — is deliberately NOT this function's job; it
- * reports the honest content-derived value (or its absence) and leaves
- * rendering to the caller.
- *
- * Frontmatter skip: normal ingestion strips a YAML frontmatter block into
- * `metadata` before create, so `content` never carries one — but a direct
- * MCP/REST create can paste raw frontmatter-bearing text
- * (`---\ntitle: X\n---\n# Real Title`), and the first line of that
- * DOCUMENT is not the first line of its delimiter. When `content` opens
- * with a `---` line, derivation starts after the matching CLOSING `---`
- * (searched within the first `FRONTMATTER_SCAN_LINES` lines). An
- * unterminated opening `---` falls back to the pre-existing behavior —
- * scanning from line 0 — so a note whose real first line is literally
- * `---` isn't mangled.
- */
-export function computeDisplayTitle(content: string | null | undefined): string | null {
-  if (!content) return null;
-  const lines = content.split("\n");
-  const startIndex = skipLeadingFrontmatter(lines);
-  for (let i = startIndex; i < lines.length; i++) {
-    const stripped = lines[i]!.replace(/^#{1,6}\s*/, "").trim();
-    if (stripped === "") continue;
-    // Iterate by Unicode code points so we don't split surrogate pairs mid-character.
-    const codePoints = Array.from(stripped);
-    return codePoints.length > DISPLAY_TITLE_MAX_LEN
-      ? codePoints.slice(0, DISPLAY_TITLE_MAX_LEN).join("")
-      : stripped;
-  }
-  return null;
-}
-
-/** Max code points in a computed `lede` (summaries-as-content, 2026-07-17 dialogue). */
-export const LEDE_MAX_LEN = 400;
-
-/**
- * Derive a note's "lede": the first non-empty PARAGRAPH after the title
- * line (a run of consecutive non-blank lines, whitespace-collapsed to one
- * line, truncated to `LEDE_MAX_LEN` code points). `null` when there's no
- * paragraph after the title — a title-only note has no lede to report, and
- * callers must not fall back to repeating the title itself.
- *
- * This is the machinery half of a soft convention (2026-07-17 dialogue):
- * summaries work better as visible CONTENT — a note's opening paragraph —
- * than as hidden metadata, because visible text gets corrected by the notes
- * that reference it while hidden metadata rots unnoticed. Nothing validates
- * that a note actually opens with a title + lede; this function just reports
- * what it finds, honestly, using the SAME title-line rule as
- * `computeDisplayTitle` (including its frontmatter skip) so a caller that
- * shows both title and lede sees them agree on where the title ends.
- */
-export function computeLede(content: string | null | undefined): string | null {
-  if (!content) return null;
-  const lines = content.split("\n");
-  const bodyStart = skipLeadingFrontmatter(lines);
-
-  let titleLine = -1;
-  for (let i = bodyStart; i < lines.length; i++) {
-    if (lines[i]!.replace(/^#{1,6}\s*/, "").trim() !== "") {
-      titleLine = i;
-      break;
-    }
-  }
-  if (titleLine === -1) return null; // no title at all — nothing to find a lede after
-
-  let i = titleLine + 1;
-  while (i < lines.length && lines[i]!.trim() === "") i++; // skip blank lines after the title
-
-  const paragraphLines: string[] = [];
-  while (i < lines.length && lines[i]!.trim() !== "") {
-    paragraphLines.push(lines[i]!);
-    i++;
-  }
-  if (paragraphLines.length === 0) return null; // title-only note
-
-  const paragraph = paragraphLines.join(" ").replace(/\s+/g, " ").trim();
-  if (paragraph === "") return null;
-
-  const codePoints = Array.from(paragraph);
-  return codePoints.length > LEDE_MAX_LEN
-    ? codePoints.slice(0, LEDE_MAX_LEN).join("")
-    : paragraph;
-}
-
 /**
  * Convert a full Note into its lean index shape:
- * drops `content`, adds `byteSize`, a whitespace-collapsed `preview`, and a
- * computed `displayTitle`. Shared between the `query-notes` MCP tool, HTTP
- * /notes endpoints, and /graph.
- *
- * Perf note: `displayTitle` costs nothing extra here — every caller of this
- * function already has the full `Note` (content included) in hand by the
- * time it's called. `queryNotes`'s two-phase page fetch selects a narrow
- * `id`-only column list for the ORDER BY/pagination phase, but the second
- * phase (`fetchNotesByIdsOrdered`) always `SELECT *`s the page's full rows
- * before `toNoteIndex` ever runs — same as `preview`/`byteSize` today. If a
- * future lean-list path is added that genuinely avoids a content read, it
- * must NOT call this function (or `toNoteIndex`) on a content-less row.
+ * drops `content`, adds `byteSize` and a whitespace-collapsed `preview`.
+ * Shared between the `query-notes` MCP tool, HTTP /notes endpoints, and /graph.
  */
 export function toNoteIndex(note: Note): NoteIndex {
   const content = note.content ?? "";
@@ -2928,7 +2732,6 @@ export function toNoteIndex(note: Note): NoteIndex {
     metadata: note.metadata,
     byteSize,
     preview,
-    displayTitle: computeDisplayTitle(note.content),
     ...(note.score !== undefined ? { score: note.score } : {}),
   };
 }

package/core/src/schema-defaults.ts

@@ -41,7 +41,6 @@
  */
 
 import { Database } from "bun:sqlite";
-import { timestampToMs } from "./cursor.js";
 
 // ---------------------------------------------------------------------------
 // Types
@@ -58,7 +57,7 @@ export interface SchemaField {
    * `type_mismatch` warning that previously fired on every integer-shaped
    * field because the validator had no `"integer"` case. See vault#310.
    */
-  type?: "string" | "number" | "integer" | "boolean" | "array" | "object" | "reference" | "date";
+  type?: "string" | "number" | "integer" | "boolean" | "array" | "object" | "reference";
   enum?: string[];
   description?: string;
   /**
@@ -321,82 +320,6 @@ export function resolveNoteSchemas(
   return { effectiveTags, mergedFields, conflicts };
 }
 
-/**
- * Normalize `date`-typed field VALUES in `metadata` to canonical UTC ISO
- * form (`Z`-suffixed) BEFORE persisting (vault#date-field-type — mixed-
- * offset corruption, caught in review).
- *
- * The bug: every consumer of an indexed `date` field — `buildOperatorClause`
- * (query-operators.ts), `date_filter` and `order_by` (notes.ts) — compares
- * the generated `meta_<field>` column as raw TEXT. ISO-8601 strings sort
- * correctly under a TEXT compare ONLY when every value shares the same
- * offset representation. `timestampToMs` (cursor.ts) — the validator both
- * `defaultMatchesType` and `valueMatchesType` reuse — correctly ACCEPTS an
- * explicit `±HH:MM` offset (validation was never the gap), but a value like
- * `"2026-07-16T10:00:00+02:00"` (= `08:00Z`) persisted VERBATIM sorts AFTER
- * `"2026-07-16T09:00:00Z"` (= `09:00Z`) under a raw string compare, even
- * though the actual instant is earlier — a mixed-offset vault silently gets
- * wrong range-query/order_by/date_filter results. This is the exact bug
- * class `updated_at` got a dedicated ms-mirror column for (vault#585/#586,
- * see `notes.ts`'s `dateFilter` block) that never extended to user-declared
- * `date` fields.
- *
- * The fix is normalize-on-write, not reject-on-write (matching the
- * "paths are normalized on write" precedent — instant preserved,
- * representation canonicalized) — rejecting offsets would defeat the
- * type's own motivation (calendar integrations and other emitters commonly
- * produce offset timestamps, not always `Z`). Only a FULL timestamp (has a
- * time component) is rewritten, to `new Date(ms).toISOString()` — always
- * UTC, millisecond precision, `Z`-suffixed. A bare `YYYY-MM-DD` value is
- * left untouched: it has no offset to normalize, is already canonical, and
- * prefix-sorts correctly against full timestamps sharing the same calendar
- * day. A value that fails `timestampToMs` is left untouched too — that's a
- * `type_mismatch` for `valueMatchesType` to catch, not this function's job.
- *
- * COPY-ON-WRITE, never mutates the input `metadata` object (vault#date-
- * field-type review round 2) — `core/` is a published library; a direct
- * embedder holding a reference to the object THEY passed in must never see
- * it change out from under them. Returns the SAME reference when nothing
- * needs rewriting (the common case — no unnecessary allocation on the
- * no-op path) or `metadata` is undefined; returns a freshly shallow-copied
- * object, with only the rewritten field(s) replaced, the first time a
- * rewrite is actually needed. Every call site must use the RETURNED value
- * (not assume its input was mutated) — see `store.createNote`/`updateNote`/
- * `createNotes`/`createNoteRaw`, all of which reassign their local
- * `opts`/`updates`/`input` binding from the return rather than relying on a
- * side effect.
- *
- * Called from `store.createNote`/`updateNote`/`createNotes`/`createNoteRaw`
- * — the lowest chokepoint every write path (MCP, REST, import) funnels
- * through — BEFORE the row is persisted, so the value that's validated by
- * `validateNote`/`valueMatchesType` upstream (offset-tolerant, so
- * normalization can't newly fail a write) and the value that's written +
- * echoed back on the response are the SAME normalized string.
- */
-export function normalizeDateFields(
-  resolved: ResolvedSchemas,
-  note: { tags?: string[]; metadata?: Record<string, unknown> },
-): Record<string, unknown> | undefined {
-  const metadata = note.metadata;
-  if (!metadata) return metadata;
-  const { mergedFields } = resolveNoteSchemas(resolved, note);
-  let copy: Record<string, unknown> | undefined;
-  for (const [fieldName, { spec }] of mergedFields) {
-    if (spec.type !== "date") continue;
-    const value = metadata[fieldName];
-    if (typeof value !== "string") continue;
-    // Bare `YYYY-MM-DD` (no time component) has no offset to normalize.
-    if (/^\d{4}-\d{2}-\d{2}$/.test(value)) continue;
-    const ms = timestampToMs(value);
-    if (ms === null) continue; // unparseable — valueMatchesType's job, not ours
-    const canonical = new Date(ms).toISOString();
-    if (canonical === value) continue;
-    if (!copy) copy = { ...metadata }; // lazy: only copy once a rewrite is due
-    copy[fieldName] = canonical;
-  }
-  return copy ?? metadata;
-}
-
 function fieldSpecsEqual(a: SchemaField, b: SchemaField): boolean {
   if (a.type !== b.type) return false;
   if (!stringArraysEqual(a.enum, b.enum)) return false;
@@ -467,13 +390,6 @@ function valueMatchesType(value: unknown, type: SchemaField["type"], cardinality
         return Array.isArray(value) && value.every((item) => typeof item === "string");
       }
       return typeof value === "string";
-    // `date` validates like `string` — an ISO-8601 date (`YYYY-MM-DD`) or
-    // full RFC3339 timestamp. Reuses `cursor.ts`'s `timestampToMs` (the SAME
-    // UTC-correct parser `date_filter`'s `updated_at` bound uses), not a
-    // second date parser — see tag-schemas.ts's `VALID_FIELD_TYPES` doc
-    // comment.
-    case "date":
-      return typeof value === "string" && timestampToMs(value) !== null;
   }
 }
 

package/core/src/search-fts-v25.test.ts

@@ -132,15 +132,7 @@ describe("search — v24 → v25 migration (legacy vault upgrade)", () => {
     );
     insert.run(
       "legacy-1",
-      // Deliberately multi-line, with the "propolis" mention on a LATER
-      // line — this fixture isolates the PATH-weighted bm25 axis (below)
-      // from the separate content-title-boost axis (title axis, ratified
-      // 2026-07-17): that boost derives a note's "title" from its FIRST
-      // content line, and a single-line note IS its own title in full, so
-      // a one-line body mentioning "propolis" would (correctly, under the
-      // newer axis) count as a title match and confound this test's
-      // path-only signal. See `search-title-boost.test.ts` for that axis.
-      "Notes on foraging patterns\n\na dedicated writeup mentioning propolis only once in passing text",
+      "a dedicated writeup mentioning propolis only once in passing text",
       "beekeeping-notes",
       "2026-01-01T00:00:00.000Z",
       "2026-01-01T00:00:00.000Z",

package/core/src/search-query.test.ts

@@ -4,7 +4,6 @@ import {
   escapeFtsToken,
   buildLiteralSearchQuery,
   isValidSearchMode,
-  extractLiteralBoostTerms,
 } from "./search-query.js";
 
 describe("escapeFtsToken", () => {
@@ -148,44 +147,3 @@ describe("isValidSearchMode / SEARCH_MODES", () => {
     expect(isValidSearchMode(["literal"])).toBe(false);
   });
 });
-
-describe("extractLiteralBoostTerms (search title-boost input, title axis)", () => {
-  it("lowercases and whitespace-splits", () => {
-    expect(extractLiteralBoostTerms("Budget Review")).toEqual(["budget", "review"]);
-  });
-
-  it("collapses whitespace runs", () => {
-    expect(extractLiteralBoostTerms("widgets    gadgets")).toEqual(["widgets", "gadgets"]);
-  });
-
-  it("trims leading/trailing whitespace", () => {
-    expect(extractLiteralBoostTerms("  widgets  ")).toEqual(["widgets"]);
-  });
-
-  it("strips literal quote characters a caller typed, unlike buildLiteralSearchQuery", () => {
-    // buildLiteralSearchQuery treats a manually-typed `"` as ordinary
-    // content (escaped into the FTS phrase); the boost-term extractor
-    // strips it instead, since a title-string comparison shouldn't
-    // require the title to contain a literal quote mark.
-    expect(extractLiteralBoostTerms(`"eleven-day capping delay"`)).toEqual([
-      "eleven-day",
-      "capping",
-      "delay",
-    ]);
-  });
-
-  it("preserves punctuation that isn't a quote (hyphen, period, apostrophe)", () => {
-    expect(extractLiteralBoostTerms("eleven-day")).toEqual(["eleven-day"]);
-    expect(extractLiteralBoostTerms("18.6")).toEqual(["18.6"]);
-    expect(extractLiteralBoostTerms("didn't")).toEqual(["didn't"]);
-  });
-
-  it("returns an empty array for blank/whitespace-only input", () => {
-    expect(extractLiteralBoostTerms("")).toEqual([]);
-    expect(extractLiteralBoostTerms("   ")).toEqual([]);
-  });
-
-  it("sanitizes control characters as separators, matching buildLiteralSearchQuery", () => {
-    expect(extractLiteralBoostTerms("hello\x00world")).toEqual(["hello", "world"]);
-  });
-});

package/core/src/search-query.ts

@@ -153,30 +153,3 @@ export function buildLiteralSearchQuery(raw: string): LiteralSearchQuery {
   const tokens = cleaned.trim().split(/\s+/).filter(Boolean);
   return { query: tokens.map(escapeFtsToken).join(" "), isEmpty: false };
 }
-
-/**
- * Extract lowercase whitespace-delimited terms from raw literal-mode search
- * text, for the search title-boost post-rank (title axis, ratified
- * 2026-07-17) — NOT used to build the FTS5 MATCH query itself (that's
- * `buildLiteralSearchQuery`, above). Sanitizes control characters the same
- * way, plus strips any literal `"` a caller typed (kept as ordinary content
- * by `buildLiteralSearchQuery`, but a display-title substring check
- * shouldn't require the title to contain a literal quote mark).
- *
- * This is a heuristic re-rank signal, not a second index — it deliberately
- * does not attempt FTS5-tokenizer parity (stemming, unicode normalization).
- * It only needs to answer "does the note's first line plausibly contain the
- * query," not reproduce FTS5's match semantics exactly. Restricted to
- * literal-mode callers by convention (see `core/src/notes.ts` `searchNotes`)
- * — `search_mode: "advanced"` text carries FTS5 boolean/column/prefix
- * operators (`AND`, `path:`, `foo*`) that would leak into the term list as
- * false "content" if tokenized the same naive way.
- */
-export function extractLiteralBoostTerms(raw: string): string[] {
-  const cleaned = raw.replace(CONTROL_CHARS, " ").toLowerCase();
-  return cleaned
-    .trim()
-    .split(/\s+/)
-    .map((t) => t.replace(/^"+|"+$/g, ""))
-    .filter(Boolean);
-}

package/core/src/seed-packs.test.ts

@@ -20,10 +20,7 @@
 
 import { describe, test, expect } from "bun:test";
 import {
-  ALL_NOTES_VIEW_PATH,
   applySeedPack,
-  ARCHIVE_VIEW_PATH,
-  ARCHIVED_TAG,
   CAPTURE_ANYTHING_PATH,
   CONNECT_AI_PATH,
   DEFAULT_VAULT_DESCRIPTION,
@@ -36,17 +33,11 @@ import {
   GUIDE_TAG,
   listSeedPacks,
   NOTES_REQUIRED_TAGS,
-  PINNED_TAG,
-  PINNED_VIEW_PATH,
-  RECENT_VIEW_PATH,
   SEED_PACK_NAMES,
-  STARTER_ONTOLOGY_PACK,
   SURFACE_STARTER_CONTENT,
   SURFACE_STARTER_PACK,
   SURFACE_STARTER_PATH,
   TAGS_GRAPH_PATH,
-  VIEW_TAG,
-  VIEWS_PATH_PREFIX,
   WELCOME_PATH,
   welcomePack,
   YOURS_TO_KEEP_PATH,
@@ -344,119 +335,12 @@ describe("surface-starter pack", () => {
   });
 });
 
-describe("starter-ontology pack", () => {
-  test("exactly four tags, in constitution order: view, archived, pinned, capture", () => {
-    expect(STARTER_ONTOLOGY_PACK.name).toBe("starter-ontology");
-    expect(STARTER_ONTOLOGY_PACK.tags.map((t) => t.name)).toEqual([
-      "view",
-      "archived",
-      "pinned",
-      "capture",
-    ]);
-  });
-
-  test("opt-in, not seeded by default", () => {
-    expect(STARTER_ONTOLOGY_PACK.description).toContain("Opt-in — not seeded by default.");
-  });
-
-  test("view is the one meta tag — carries the kind/query/lane_by/date_field schema", () => {
-    expect(VIEW_TAG.name).toBe("view");
-    expect(VIEW_TAG.description).toContain("meta tag");
-    expect(VIEW_TAG.fields).toBeDefined();
-    expect(Object.keys(VIEW_TAG.fields!)).toEqual([
-      "kind",
-      "query",
-      "lane_by",
-      "date_field",
-    ]);
-
-    const kind = VIEW_TAG.fields!.kind!;
-    expect(kind.type).toBe("string");
-    expect(kind.enum).toEqual(["list", "board", "calendar", "gallery"]);
-    expect(kind.default).toBe("list");
-
-    const query = VIEW_TAG.fields!.query!;
-    expect(query.type).toBe("string");
-
-    // lane_by / date_field are optional (no default — absent stays absent).
-    expect(VIEW_TAG.fields!.lane_by!.default).toBeUndefined();
-    expect(VIEW_TAG.fields!.date_field!.default).toBeUndefined();
-  });
-
-  test("archived + pinned are plain tags — no schema", () => {
-    expect(ARCHIVED_TAG.name).toBe("archived");
-    expect(ARCHIVED_TAG.fields).toBeUndefined();
-    expect(ARCHIVED_TAG.description).toContain("out of the flow of the present");
-
-    expect(PINNED_TAG.name).toBe("pinned");
-    expect(PINNED_TAG.fields).toBeUndefined();
-    expect(PINNED_TAG.description).toContain("partition");
-  });
-
-  test("capture is reused verbatim from NOTES_REQUIRED_TAGS — byte-equal, no drift risk", () => {
-    const capture = STARTER_ONTOLOGY_PACK.tags.find((t) => t.name === "capture");
-    expect(capture).toBe(NOTES_REQUIRED_TAGS[0]); // SAME object reference, not just equal content
-    expect(capture!.description).toBe(NOTES_REQUIRED_TAGS[0]!.description);
-  });
-
-  test("four seed #view notes mirroring the app's default pages", () => {
-    expect(STARTER_ONTOLOGY_PACK.notes.map((n) => n.path)).toEqual([
-      ALL_NOTES_VIEW_PATH,
-      RECENT_VIEW_PATH,
-      PINNED_VIEW_PATH,
-      ARCHIVE_VIEW_PATH,
-    ]);
-    for (const note of STARTER_ONTOLOGY_PACK.notes) {
-      expect(note.path.startsWith(VIEWS_PATH_PREFIX)).toBe(true);
-      expect(note.tags).toEqual(["view"]);
-      expect(note.metadata?.kind).toBe("list");
-      expect(typeof note.metadata?.query).toBe("string");
-      // Every seeded query must itself be valid JSON — a downstream reader
-      // parses it as query-notes params.
-      expect(() => JSON.parse(note.metadata!.query as string)).not.toThrow();
-    }
-  });
-
-  test("All notes / Recent exclude archived explicitly (authoring-time default, not magic)", () => {
-    for (const path of [ALL_NOTES_VIEW_PATH, RECENT_VIEW_PATH]) {
-      const note = noteAt(STARTER_ONTOLOGY_PACK, path);
-      const query = JSON.parse(note.metadata!.query as string);
-      expect(query.exclude_tags).toEqual(["archived"]);
-    }
-  });
-
-  test("Recent orders by updated_at desc", () => {
-    const query = JSON.parse(noteAt(STARTER_ONTOLOGY_PACK, RECENT_VIEW_PATH).metadata!.query as string);
-    expect(query.order_by).toBe("updated_at");
-    expect(query.sort).toBe("desc");
-  });
-
-  test("Pinned queries tag:pinned; Archive queries tag:archived (the deliberate exception to exclude_tags)", () => {
-    const pinnedQuery = JSON.parse(noteAt(STARTER_ONTOLOGY_PACK, PINNED_VIEW_PATH).metadata!.query as string);
-    expect(pinnedQuery.tag).toBe("pinned");
-
-    const archiveQuery = JSON.parse(noteAt(STARTER_ONTOLOGY_PACK, ARCHIVE_VIEW_PATH).metadata!.query as string);
-    expect(archiveQuery.tag).toBe("archived");
-    expect(archiveQuery.exclude_tags).toBeUndefined();
-  });
-
-  test("no dangling wikilinks within the pack", () => {
-    const seededPaths = new Set(STARTER_ONTOLOGY_PACK.notes.map((n) => n.path));
-    for (const note of STARTER_ONTOLOGY_PACK.notes) {
-      for (const target of wikilinkTargets(note.content)) {
-        expect(seededPaths.has(target)).toBe(true);
-      }
-    }
-  });
-});
-
 describe("pack registry", () => {
-  test("lists exactly the four packs, in order", () => {
+  test("lists exactly the three packs, in order", () => {
     expect([...SEED_PACK_NAMES]).toEqual([
       "welcome",
       "getting-started",
       "surface-starter",
-      "starter-ontology",
     ]);
     expect(listSeedPacks().map((p) => p.name)).toEqual([...SEED_PACK_NAMES]);
     for (const p of listSeedPacks()) {