ctxr-cli 0.9.0 → 0.11.0

package/templates/notes/Deal.md

@@ -0,0 +1,25 @@
+---
+date_created: "{{date}}"
+title: "{{title}}"
+tags:
+  - Deal
+---
+# {{title}}
+
+## Terms
+<!-- Round size, valuation, instrument, lead, board seat. -->
+
+## Counterparty
+<!-- [[Company]] — what they do, team, key metrics. -->
+
+## Thesis
+<!-- Why this is compelling. -->
+
+## Key relationships
+<!-- [[wikilinks]] to investors, advisors, co-investors. -->
+
+## Interactions
+<!-- Dated entries: ### YYYY-MM-DD — stage or event -->
+
+## Follow-ups
+<!-- - [ ] Task text (added YYYY-MM-DD, due YYYY-MM-DD) -->

package/templates/notes/Note.md

@@ -0,0 +1,6 @@
+---
+date_created: "{{date}}"
+title: "{{title}}"
+tags: []
+---
+# {{title}}

package/templates/notes/People.md

@@ -0,0 +1,19 @@
+---
+date_created: "{{date}}"
+title: "{{title}}"
+tags:
+  - People
+---
+# {{title}}
+
+## Bio
+<!-- Who they are: current role, organization, relevant history. -->
+
+## Relationship
+<!-- How you know them, and in what context. -->
+
+## Communication Log
+<!-- Dated entries, one per exchange: ### YYYY-MM-DD — context -->
+
+## Follow-ups
+<!-- - [ ] Task text (added YYYY-MM-DD, due YYYY-MM-DD) -->

package/templates/notes/Project.md

@@ -0,0 +1,19 @@
+---
+date_created: "{{date}}"
+title: "{{title}}"
+tags:
+  - Project
+---
+# {{title}}
+
+## Goal
+<!-- What done looks like. Work with no end state is an area, not a project. -->
+
+## Open threads
+<!-- Unresolved decisions and blockers; each links where it was raised. -->
+
+## Follow-ups
+<!-- - [ ] Task text (added YYYY-MM-DD, due YYYY-MM-DD) -->
+
+## Related
+<!-- Links out to related notes. -->

package/templates/serve/shell.html

@@ -1,5 +1,5 @@
 <!doctype html>
-<html lang="en">
+<html lang="en" data-ctxr-theme="{{THEME}}" data-ctxr-nav="{{NAV_STATE}}">
 <head>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
@@ -7,7 +7,21 @@
 <link rel="stylesheet" href="/assets/style.css">
 </head>
 <body>
-<header class="ctxr-shell-header"><a href="/">contexture</a></header>
+<input type="checkbox" id="ctxr-nav-toggle" class="ctxr-visually-hidden">
+<header class="ctxr-shell-header">
+<div class="ctxr-shell-header-start">
+<label for="ctxr-nav-toggle" class="ctxr-nav-toggle-label"><span aria-hidden="true">☰</span><span class="ctxr-visually-hidden">Navigation</span></label>
+<a href="/" class="ctxr-shell-title">contexture</a>
+</div>
+<div class="ctxr-shell-header-end">
+<a class="ctxr-nav-collapse-link" href="{{NAV_TOGGLE_HREF}}"><span aria-hidden="true">☰</span><span class="ctxr-visually-hidden">{{NAV_TOGGLE_LABEL}}</span></a>
+<nav class="ctxr-theme-switcher" aria-label="Display theme">
+<a href="?ctxr-theme=light">Light</a>
+<a href="?ctxr-theme=dark">Dark</a>
+<a href="?ctxr-theme=system">System</a>
+</nav>
+</div>
+</header>
 <div class="ctxr-layout">
 {{NAV}}
 <main>

package/templates/serve/style.css

@@ -1,5 +1,12 @@
+/*
+ * serve-page-names-theme-and-nav-toggle design.md D8: the light palette
+ * lives on :root as the shared baseline. "light" mode needs nothing more
+ * than to pin color-scheme; "dark" overrides every custom property at
+ * higher specificity (html[data-ctxr-theme=...] beats a bare :root
+ * regardless of source order); "system" keeps the light baseline unless the
+ * dark media query — scoped to system alone, never left unscoped — applies.
+ */
 :root {
-  color-scheme: light dark;
   --ctxr-fg: #1a1a1a;
   --ctxr-bg: #ffffff;
   --ctxr-muted: #6b6b6b;
@@ -8,8 +15,26 @@
   --ctxr-broken: #b3261e;
 }
 
+html[data-ctxr-theme="light"] {
+  color-scheme: light;
+}
+
+html[data-ctxr-theme="system"] {
+  color-scheme: light dark;
+}
+
+html[data-ctxr-theme="dark"] {
+  color-scheme: dark;
+  --ctxr-fg: #e8e8e8;
+  --ctxr-bg: #121212;
+  --ctxr-muted: #9b9b9b;
+  --ctxr-border: #3a3a3a;
+  --ctxr-code-bg: #1e1e1e;
+  --ctxr-broken: #ff8a80;
+}
+
 @media (prefers-color-scheme: dark) {
-  :root {
+  html[data-ctxr-theme="system"] {
     --ctxr-fg: #e8e8e8;
     --ctxr-bg: #121212;
     --ctxr-muted: #9b9b9b;
@@ -28,6 +53,10 @@ body {
 }
 
 .ctxr-shell-header {
+  display: flex;
+  align-items: center;
+  justify-content: space-between;
+  gap: 1rem;
   padding: 0.75rem 1.5rem;
   border-bottom: 1px solid var(--ctxr-border);
 }
@@ -35,9 +64,96 @@ body {
 .ctxr-shell-header a {
   color: inherit;
   text-decoration: none;
+}
+
+.ctxr-shell-header-start,
+.ctxr-shell-header-end {
+  display: flex;
+  align-items: center;
+  gap: 0.75rem;
+}
+
+.ctxr-shell-title {
   font-weight: 600;
 }
 
+.ctxr-theme-switcher {
+  display: flex;
+  gap: 0.75rem;
+  font-size: 0.85rem;
+}
+
+.ctxr-theme-switcher a {
+  color: var(--ctxr-muted);
+}
+
+.ctxr-theme-switcher a:hover,
+.ctxr-theme-switcher a:focus-visible {
+  color: var(--ctxr-fg);
+}
+
+/*
+ * serve-page-names-theme-and-nav-toggle design.md D12: hidden off-screen
+ * rather than with display:none or visibility:hidden, either of which would
+ * drop the checkbox from the tab order and make the navigation unreachable
+ * by keyboard. Reused for the accessible-name text spans inside the two nav
+ * controls below, which need the identical off-screen treatment.
+ */
+.ctxr-visually-hidden {
+  position: absolute;
+  width: 1px;
+  height: 1px;
+  overflow: hidden;
+  clip-path: inset(50%);
+  white-space: nowrap;
+}
+
+/* design.md D12: the checkbox is the first element in <body>, so this general-sibling selector can reach the visible label on :checked. */
+#ctxr-nav-toggle:focus-visible ~ header .ctxr-nav-toggle-label {
+  outline: 2px solid currentColor;
+  outline-offset: 2px;
+}
+
+.ctxr-nav-toggle-label,
+.ctxr-nav-collapse-link {
+  display: none;
+  align-items: center;
+  justify-content: center;
+  min-width: 2.75rem;
+  min-height: 2.75rem;
+  padding: 0.25rem 0.5rem;
+  border-radius: 4px;
+  cursor: pointer;
+  color: var(--ctxr-muted);
+}
+
+.ctxr-nav-toggle-label:hover,
+.ctxr-nav-collapse-link:hover,
+.ctxr-nav-toggle-label:focus-visible,
+.ctxr-nav-collapse-link:focus-visible {
+  color: var(--ctxr-fg);
+}
+
+/*
+ * design.md D9: shown by default at a wide viewport, since a collapsed
+ * sidebar there must persist across navigation via the ctxr_nav cookie, not
+ * reset every page load the way the narrow-viewport checkbox does.
+ */
+.ctxr-nav-collapse-link {
+  display: inline-flex;
+}
+
+/* design.md D9/D10: gated to a viewport wide enough to show the navigation alongside the content, so it can never contradict the narrow-viewport checkbox below. */
+@media (min-width: 52.0625rem) {
+  html[data-ctxr-nav="collapsed"] .ctxr-layout {
+    grid-template-columns: minmax(0, 1fr);
+  }
+
+  html[data-ctxr-nav="collapsed"] .ctxr-nav {
+    display: none;
+  }
+}
+
 .ctxr-layout {
   display: grid;
   grid-template-columns: minmax(14rem, 18rem) minmax(0, 1fr);
@@ -54,7 +170,12 @@ body {
   font-size: 0.9rem;
 }
 
-/* Stack the navigation above the content once two columns stop fitting. */
+/*
+ * Stack the navigation above the content once two columns stop fitting, and
+ * hide it by default (design.md D9: a narrow viewport starts with the
+ * navigation hidden, revealed only by the checkbox below — the desktop
+ * ctxr_nav cookie above this breakpoint plays no part here).
+ */
 @media (max-width: 52rem) {
   .ctxr-layout {
     grid-template-columns: minmax(0, 1fr);
@@ -65,6 +186,27 @@ body {
     max-height: none;
     border-right: none;
     border-bottom: 1px solid var(--ctxr-border);
+    display: none;
+  }
+
+  #ctxr-nav-toggle:checked ~ .ctxr-layout .ctxr-nav {
+    display: block;
+  }
+
+  .ctxr-nav-toggle-label {
+    display: inline-flex;
+  }
+
+  .ctxr-nav-collapse-link {
+    display: none;
+  }
+}
+
+@media print {
+  .ctxr-nav,
+  .ctxr-nav-toggle-label,
+  .ctxr-nav-collapse-link {
+    display: none;
   }
 }
 

package/templates/skills/ctxr-ingest-orchestration.md

@@ -38,7 +38,10 @@ to put the file — "create a new note" is one option among several, never the d
    - Source discipline: a field the source does not confirm is "not reported" — never inferred from
      silence in either direction.
 5. Write the note the decision calls for — create it, expand it, merge, restructure, or add a section —
-   preserving prior content in every case but the deliberate rewrite.
+   preserving prior content in every case but the deliberate rewrite. A NEW note starts from a template
+   under `__TEMPLATES_PATH__`, with `{{title}}` and `{{date}}` substituted as you write (`ctxr-placement`
+   picks which). An EXISTING note is extended in place — never re-cut from a template, which would throw
+   away the content that made it worth expanding.
 6. Register the source against whatever note you just wrote:
    `ctxr ingest <path> --into <note> --source-type <type> --source-id <id>`. Every row of the table above
    ends here, not just the first: the command retains the capture under the capture tier's month, freezes

package/templates/skills/ctxr-placement.md

@@ -9,8 +9,20 @@ __LAYER_STEP__
 - Match on what the content IS. When two sibling locations both seem to fit, name the distinction between
   them (abstract vs concrete; outward-facing vs inward-facing; who-we-are vs how-it-runs) and pick by
   altitude and audience, not by keyword.
-- Read one or two sibling notes in the chosen location and match their shape — frontmatter keys, heading
-  style, bullets vs prose — before writing.
+- If the chosen location has a `README.md`, read it first: a folder with one answer about what its notes
+  look like states it there, and that answer wins over anything you would infer.
+
+## 2b. Which template?
+
+Start a new note from a template under `__TEMPLATES_PATH__` — never a blank file, and never by copying a
+sibling wholesale. List that directory and pick the kind the content actually is; `Note` is the base when
+nothing more specific fits, and it is also the file to copy when this store needs a kind it does not have.
+Substitute `{{title}}` and `{{date}}` as you write — no command expands them, and `ctxr lint` reports a
+note that lands with one still in it.
+
+The template is the starting shape, not a cage: delete a section that does not apply rather than leaving
+it empty, and add one the note needs. Read a sibling note only for what the template leaves open — house
+phrasing, bullets vs prose, which tags this location uses.
 
 ## 3. Sub-item under an existing location, or a new top-level one?
 
@@ -37,6 +49,13 @@ manufactures an artifact for the graveyard; capture the durable slice by hand in
 Add a one-line wikilink from the relevant hub note so the new note is not an orphan; `ctxr lint` flags
 orphans and notes without a catalog entry.
 
+## An existing note
+
+A note that already exists is EXTENDED, never restarted from a template: add the section it now needs,
+preserve what is there, and leave its frontmatter alone. Re-cutting a note from a template to "bring it up
+to standard" destroys the content that made it worth keeping — a note that has outgrown its starting shape
+is doing the right thing.
+
 ## Relocating an existing note
 
 `ctxr archive <path>` to retire it; a plain tracked `git mv` for an ordinary re-placement. Either way the

package/templates/skills/ctxr-session-capture.md

@@ -84,7 +84,11 @@ notes:
     path: <layer>/<location>/<Title>.md
     mode: create            # or: append
     body: |
-      matching the frontmatter and style of the sibling notes (`ctxr-placement` decides the location)
+      for create: started from a template under `__TEMPLATES_PATH__`, with {{title}} and {{date}}
+      substituted, sections that do not apply deleted rather than left empty
+      for append: only the new material, extending the note rather than restarting it — the
+      command appends your body verbatim and never rewrites what is already there
+      (`ctxr-placement` decides both the location and the template)
 ```
 
 Then run `ctxr session capture --proposal <file>`. It validates and writes every item independently —

package/templates/skills/ctxr-session-lifecycle.md

@@ -9,6 +9,26 @@ the two verbs at the seams; their steps are not repeated here.
 If you find yourself on the default branch or in the root checkout, stop — `ctxr session list` shows the
 active sessions to work in instead.
 
+Before starting, bring the store's canonical clone up to date — the repository's main worktree, not
+whichever checkout you are standing in. From the canonical clone: `git fetch origin`, then
+`git merge --ff-only origin/__DEFAULT_BRANCH__`. If it is on another branch, carries uncommitted
+changes, or the fast-forward fails because it has diverged from origin, report exactly that and start
+the session anyway — never check it out, reset it, stash, or force the merge to make it comply. The
+session's base is unaffected either way, because `ctxr session start` branches from the
+`origin/__DEFAULT_BRANCH__` it fetches itself. What a stale clone costs is the context you read out of
+it: notes, catalog sections, the graph document, and AGENTS.md would all be the versions it last had.
+
+`ctxr session start` names the start point it used. If it reports that it did not fetch, there was no
+remote branch to fetch from and it branched from the local default branch instead — say so plainly,
+because the session is then based on whatever that clone last had rather than on origin.
+
+If `ctxr session start` reports a `cli.update_available` finding, a newer `ctxr` than the one installed
+has been published. Name both versions to the operator and offer `ctxr-upgrade`; then continue the
+session either way. Do not upgrade unasked, and do not make continuing conditional on the answer —
+deferring is a normal answer, and the session is unaffected by it. A `cli.update_check_failed` finding
+means the check could not be completed; it says nothing about whether an upgrade is due, so proceed
+without mentioning it.
+
 ## Re-scan before any plan
 
 Re-scan whenever state may have moved under you — before presenting a plan, before running `ctxr-submit`,

package/templates/skills/ctxr-upgrade.md

@@ -0,0 +1,44 @@
+Upgrade the installed `ctxr` to the latest published release, then bring this store's
+contexture-owned files up to it. `ctxr-session-lifecycle` offers this skill at the start of a session
+when a newer release is published; it is equally valid to run it directly.
+
+Upgrading replaces the executable for every store on this machine, not only this one. That is why
+step 3 gates on the operator rather than proceeding from the fact that a newer release exists.
+
+1. Read the live answer — never act on a notice from earlier in the conversation, which may be
+   minutes stale: `ctxr version --check --json`. The envelope's `data` carries `version` (installed),
+   `latest` (published), `release_status`, `install_path`, and `install_kind`. Exit code `0` means
+   already current: say so and stop. A non-zero exit with `release_status` of `undetermined` means the
+   published version could not be resolved — report the reason the finding names, and stop; do not
+   guess whether an upgrade is due.
+
+2. Check `install_kind` before proposing anything.
+   - `global` — proceed to step 3.
+   - `linked` — this executable resolves to a working copy at `install_path`, not a package
+     installation. A global install would upgrade a different `ctxr` than the one running. Report the
+     path and stop.
+   - `undetermined` — the executable is inside a `node_modules` that is not the global one: a project
+     dependency, or an `npx` invocation. Report `install_path` and stop; upgrading it is the
+     operator's call about that project, not a global install.
+
+3. Gate on the operator. Name the installed version, the published version, and `install_path`, and
+   ask whether to upgrade. Wait for an explicit go. Having approval for the session's other work is
+   not approval for this — it changes software outside the store.
+
+4. Upgrade, then confirm: `npm install -g ctxr-cli@latest`, then `ctxr version`. Confirm the reported
+   version is the published one before continuing. If it still reports the old version, the shell is
+   resolving a different `ctxr` than the one npm wrote — report that and stop rather than continuing
+   into step 5, where the re-render would be performed by the executable you just tried to replace.
+
+5. Re-render this store with the upgraded executable, in that order — the generated files come from
+   the binary, so re-rendering first would only rewrite them at the old version. Work in a session
+   worktree (`ctxr session start`), never the root checkout: `ctxr update` writes contexture-owned
+   files, and those writes land through a reviewed pull request like any other change.
+
+6. Land the re-render as its own pull request. `ctxr update` produces generated-file churn — AGENTS.md
+   sections, skill copies, hooks, adapter outputs — and mixing it into unrelated work makes both
+   harder to review. Follow `ctxr-submit`, then `ctxr-land`.
+
+If step 4 or 5 fails, say which step and what the command reported. A partial upgrade — new executable,
+un-re-rendered store — is a real state worth naming: the store still works, and step 5 can be re-run on
+its own at any time.

package/dist/commands/migrate.d.ts

@@ -1,30 +0,0 @@
-import type { CommandOutcome, CommandRequires } from '../core/command.js';
-import type { MigrationDelta } from '../core/migrations/types.js';
-import type { Store } from '../core/store.js';
-export declare const requires: CommandRequires;
-export interface MigrateFlags {
-    dryRun?: boolean;
-}
-export interface MigrateMigrationResult {
-    id: string;
-    fromVersion: number;
-    toVersion: number;
-    deltas: MigrationDelta[];
-}
-export interface MigrateData {
-    currentVersion: number;
-    targetVersion: number;
-    applied: boolean;
-    migrations: MigrateMigrationResult[];
-}
-/**
- * store-lifecycle spec: `--dry-run` reports exact deltas with nothing
- * applied; a real run applies each pending migration in order, reloading
- * the store's config after each one so a later migration in the chain
- * (none exist yet, but the mechanism supports it) sees the version it
- * actually needs to start from. Resumability is a property of each
- * migration's own plan()/apply() (see core/migrations/types.ts) — this
- * command does no extra bookkeeping of its own.
- */
-export declare function execute(store: Store, flags: MigrateFlags): Promise<CommandOutcome<MigrateData>>;
-//# sourceMappingURL=migrate.d.ts.map

package/dist/commands/migrate.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"migrate.d.ts","sourceRoot":"","sources":["../../src/commands/migrate.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,cAAc,EAAE,eAAe,EAAE,MAAM,oBAAoB,CAAC;AAI1E,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,6BAA6B,CAAC;AAElE,OAAO,KAAK,EAAE,KAAK,EAAE,MAAM,kBAAkB,CAAC;AAE9C,eAAO,MAAM,QAAQ,EAAE,eAAuC,CAAC;AAE/D,MAAM,WAAW,YAAY;IAC3B,MAAM,CAAC,EAAE,OAAO,CAAC;CAClB;AAED,MAAM,WAAW,sBAAsB;IACrC,EAAE,EAAE,MAAM,CAAC;IACX,WAAW,EAAE,MAAM,CAAC;IACpB,SAAS,EAAE,MAAM,CAAC;IAClB,MAAM,EAAE,cAAc,EAAE,CAAC;CAC1B;AAED,MAAM,WAAW,WAAW;IAC1B,cAAc,EAAE,MAAM,CAAC;IACvB,aAAa,EAAE,MAAM,CAAC;IACtB,OAAO,EAAE,OAAO,CAAC;IACjB,UAAU,EAAE,sBAAsB,EAAE,CAAC;CACtC;AAED;;;;;;;;GAQG;AACH,wBAAsB,OAAO,CAAC,KAAK,EAAE,KAAK,EAAE,KAAK,EAAE,YAAY,GAAG,OAAO,CAAC,cAAc,CAAC,WAAW,CAAC,CAAC,CA4CrG"}

package/dist/commands/migrate.js

@@ -1,56 +0,0 @@
-import { readConfig } from '../config/load.js';
-import { SUPPORTED_SCHEMA_VERSION } from '../config/schema.js';
-import { ExitCode } from '../core/exit-codes.js';
-import { pendingMigrations } from '../core/migrations/registry.js';
-export const requires = { store: 'required' };
-/**
- * store-lifecycle spec: `--dry-run` reports exact deltas with nothing
- * applied; a real run applies each pending migration in order, reloading
- * the store's config after each one so a later migration in the chain
- * (none exist yet, but the mechanism supports it) sees the version it
- * actually needs to start from. Resumability is a property of each
- * migration's own plan()/apply() (see core/migrations/types.ts) — this
- * command does no extra bookkeeping of its own.
- */
-export async function execute(store, flags) {
-    const pending = pendingMigrations(store.config.schema_version);
-    const startingVersion = store.config.schema_version;
-    if (pending.length === 0) {
-        return {
-            exitCode: ExitCode.Ok,
-            data: { currentVersion: startingVersion, targetVersion: SUPPORTED_SCHEMA_VERSION, applied: false, migrations: [] },
-            findings: [],
-            humanSummary: `Already at schema_version ${startingVersion}; nothing to migrate.`,
-            storeRoot: store.root,
-            schemaVersion: store.config.schema_version,
-        };
-    }
-    const results = [];
-    let workingStore = store;
-    for (const migration of pending) {
-        if (flags.dryRun) {
-            const deltas = await migration.plan(workingStore);
-            results.push({ id: migration.id, fromVersion: migration.fromVersion, toVersion: migration.toVersion, deltas });
-            continue;
-        }
-        const deltas = await migration.apply(workingStore);
-        results.push({ id: migration.id, fromVersion: migration.fromVersion, toVersion: migration.toVersion, deltas });
-        workingStore = { root: workingStore.root, config: await readConfig(workingStore.root) };
-    }
-    return {
-        exitCode: ExitCode.Ok,
-        data: {
-            currentVersion: startingVersion,
-            targetVersion: SUPPORTED_SCHEMA_VERSION,
-            applied: !flags.dryRun,
-            migrations: results,
-        },
-        findings: [],
-        humanSummary: flags.dryRun
-            ? `--dry-run: ${results.reduce((n, r) => n + r.deltas.length, 0)} change(s) would be made across ${results.length} migration(s).`
-            : `Applied ${results.length} migration(s), now at schema_version ${workingStore.config.schema_version}.`,
-        storeRoot: store.root,
-        schemaVersion: flags.dryRun ? store.config.schema_version : workingStore.config.schema_version,
-    };
-}
-//# sourceMappingURL=migrate.js.map

package/dist/commands/migrate.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"migrate.js","sourceRoot":"","sources":["../../src/commands/migrate.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,UAAU,EAAE,MAAM,mBAAmB,CAAC;AAC/C,OAAO,EAAE,wBAAwB,EAAE,MAAM,qBAAqB,CAAC;AAC/D,OAAO,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AAEjD,OAAO,EAAE,iBAAiB,EAAE,MAAM,gCAAgC,CAAC;AAGnE,MAAM,CAAC,MAAM,QAAQ,GAAoB,EAAE,KAAK,EAAE,UAAU,EAAE,CAAC;AAoB/D;;;;;;;;GAQG;AACH,MAAM,CAAC,KAAK,UAAU,OAAO,CAAC,KAAY,EAAE,KAAmB;IAC7D,MAAM,OAAO,GAAG,iBAAiB,CAAC,KAAK,CAAC,MAAM,CAAC,cAAc,CAAC,CAAC;IAC/D,MAAM,eAAe,GAAG,KAAK,CAAC,MAAM,CAAC,cAAc,CAAC;IAEpD,IAAI,OAAO,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACzB,OAAO;YACL,QAAQ,EAAE,QAAQ,CAAC,EAAE;YACrB,IAAI,EAAE,EAAE,cAAc,EAAE,eAAe,EAAE,aAAa,EAAE,wBAAwB,EAAE,OAAO,EAAE,KAAK,EAAE,UAAU,EAAE,EAAE,EAAE;YAClH,QAAQ,EAAE,EAAE;YACZ,YAAY,EAAE,6BAA6B,eAAe,uBAAuB;YACjF,SAAS,EAAE,KAAK,CAAC,IAAI;YACrB,aAAa,EAAE,KAAK,CAAC,MAAM,CAAC,cAAc;SAC3C,CAAC;IACJ,CAAC;IAED,MAAM,OAAO,GAA6B,EAAE,CAAC;IAC7C,IAAI,YAAY,GAAG,KAAK,CAAC;IAEzB,KAAK,MAAM,SAAS,IAAI,OAAO,EAAE,CAAC;QAChC,IAAI,KAAK,CAAC,MAAM,EAAE,CAAC;YACjB,MAAM,MAAM,GAAG,MAAM,SAAS,CAAC,IAAI,CAAC,YAAY,CAAC,CAAC;YAClD,OAAO,CAAC,IAAI,CAAC,EAAE,EAAE,EAAE,SAAS,CAAC,EAAE,EAAE,WAAW,EAAE,SAAS,CAAC,WAAW,EAAE,SAAS,EAAE,SAAS,CAAC,SAAS,EAAE,MAAM,EAAE,CAAC,CAAC;YAC/G,SAAS;QACX,CAAC;QACD,MAAM,MAAM,GAAG,MAAM,SAAS,CAAC,KAAK,CAAC,YAAY,CAAC,CAAC;QACnD,OAAO,CAAC,IAAI,CAAC,EAAE,EAAE,EAAE,SAAS,CAAC,EAAE,EAAE,WAAW,EAAE,SAAS,CAAC,WAAW,EAAE,SAAS,EAAE,SAAS,CAAC,SAAS,EAAE,MAAM,EAAE,CAAC,CAAC;QAC/G,YAAY,GAAG,EAAE,IAAI,EAAE,YAAY,CAAC,IAAI,EAAE,MAAM,EAAE,MAAM,UAAU,CAAC,YAAY,CAAC,IAAI,CAAC,EAAE,CAAC;IAC1F,CAAC;IAED,OAAO;QACL,QAAQ,EAAE,QAAQ,CAAC,EAAE;QACrB,IAAI,EAAE;YACJ,cAAc,EAAE,eAAe;YAC/B,aAAa,EAAE,wBAAwB;YACvC,OAAO,EAAE,CAAC,KAAK,CAAC,MAAM;YACtB,UAAU,EAAE,OAAO;SACpB;QACD,QAAQ,EAAE,EAAE;QACZ,YAAY,EAAE,KAAK,CAAC,MAAM;YACxB,CAAC,CAAC,cAAc,OAAO,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,MAAM,CAAC,MAAM,EAAE,CAAC,CAAC,mCAAmC,OAAO,CAAC,MAAM,gBAAgB;YACjI,CAAC,CAAC,WAAW,OAAO,CAAC,MAAM,wCAAwC,YAAY,CAAC,MAAM,CAAC,cAAc,GAAG;QAC1G,SAAS,EAAE,KAAK,CAAC,IAAI;QACrB,aAAa,EAAE,KAAK,CAAC,MAAM,CAAC,CAAC,CAAC,KAAK,CAAC,MAAM,CAAC,cAAc,CAAC,CAAC,CAAC,YAAY,CAAC,MAAM,CAAC,cAAc;KAC/F,CAAC;AACJ,CAAC"}

package/dist/core/migrations/add-explanation-craft-skill.d.ts

@@ -1,26 +0,0 @@
-import type { Migration } from './types.js';
-/**
- * vendor-explanation-craft-skill: the shipped vendored set grew a second craft
- * skill, and `init` writes the RESOLVED list into `contexture.yaml` while
- * `reconcileStore` never rewrites configuration. So a change to the shipped
- * default reaches new stores only; without this migration every store already
- * on disk would keep a one-entry list and silently never receive the skill the
- * publish skill now tells it to load.
- *
- * The uncomfortable part, stated rather than implied: `config/schema.ts` says
- * the schema version bumps "only on a genuinely incompatible change, never on
- * an additive one," and adding a skill is additive. This bumps it anyway, which
- * means every existing store reports as needing `ctxr migrate` because a skill
- * was added. That was the accepted price of guaranteed propagation — the
- * alternatives were leaving the shipped default a lie for every store predating
- * it, or an update-time nag that would never stop firing in a store that
- * deliberately opted out. Do not read this as license to bump the version for
- * the next additive change; weigh that one on its own.
- *
- * Pending-ness is the recorded schema version, never the list's contents — the
- * rule 0002, 0004, 0005, and 0006 all follow, because the config schema fills
- * `skills.vendored` from the shipped default when the key is absent, so an
- * unmigrated store already reads as though it declared the new set.
- */
-export declare const addExplanationCraftSkillMigration: Migration;
-//# sourceMappingURL=add-explanation-craft-skill.d.ts.map

package/dist/core/migrations/add-explanation-craft-skill.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"add-explanation-craft-skill.d.ts","sourceRoot":"","sources":["../../../src/core/migrations/add-explanation-craft-skill.ts"],"names":[],"mappings":"AAKA,OAAO,KAAK,EAAE,SAAS,EAAkB,MAAM,YAAY,CAAC;AA6C5D;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,eAAO,MAAM,iCAAiC,EAAE,SA8B/C,CAAC"}

package/dist/core/migrations/add-explanation-craft-skill.js

@@ -1,94 +0,0 @@
-import path from 'node:path';
-import { DEFAULT_VENDORED_SKILLS } from '../../config/defaults.js';
-import { readConfig } from '../../config/load.js';
-import { renderStoreConfig } from '../../config/render.js';
-import { writeFileAtomic } from '../fs/atomic.js';
-/**
- * The shipped set as it stood before this change — a fixed historical literal,
- * never derived from `DEFAULT_VENDORED_SKILLS`. Deriving it would make the
- * "was this list ever customized?" test drift every time the shipped set grows
- * again, silently re-adding to lists a later operator had curated.
- */
-const PREVIOUS_SHIPPED_SET = ['frontend-design'];
-const SCHEMA_VERSION = 7;
-function configDelta(next) {
-    return {
-        path: 'contexture.yaml',
-        description: `set skills.vendored to [${next.join(', ')}] and schema_version to ${SCHEMA_VERSION}`,
-    };
-}
-function versionOnlyDelta() {
-    return {
-        path: 'contexture.yaml',
-        description: `set schema_version to ${SCHEMA_VERSION}, leaving this store's own skills.vendored list untouched`,
-    };
-}
-/**
- * The list to write, or undefined when this store's is not ours to rewrite.
- *
- * The heuristic 0004 and 0006 both used: a list still sitting exactly on the
- * previous shipped default was never curated, so growing it matches what the
- * operator already accepted. A list that was reordered, added to, or emptied to
- * opt out is a decision, and re-adding to it would overwrite that decision —
- * such a store gets the version bump alone.
- */
-function nextVendoredList(current) {
-    const unchanged = current.length === PREVIOUS_SHIPPED_SET.length && current.every((name, i) => name === PREVIOUS_SHIPPED_SET[i]);
-    if (!unchanged)
-        return undefined;
-    const shipped = [...DEFAULT_VENDORED_SKILLS];
-    const added = shipped.filter((name) => !current.includes(name));
-    return added.length > 0 ? shipped : undefined;
-}
-/**
- * vendor-explanation-craft-skill: the shipped vendored set grew a second craft
- * skill, and `init` writes the RESOLVED list into `contexture.yaml` while
- * `reconcileStore` never rewrites configuration. So a change to the shipped
- * default reaches new stores only; without this migration every store already
- * on disk would keep a one-entry list and silently never receive the skill the
- * publish skill now tells it to load.
- *
- * The uncomfortable part, stated rather than implied: `config/schema.ts` says
- * the schema version bumps "only on a genuinely incompatible change, never on
- * an additive one," and adding a skill is additive. This bumps it anyway, which
- * means every existing store reports as needing `ctxr migrate` because a skill
- * was added. That was the accepted price of guaranteed propagation — the
- * alternatives were leaving the shipped default a lie for every store predating
- * it, or an update-time nag that would never stop firing in a store that
- * deliberately opted out. Do not read this as license to bump the version for
- * the next additive change; weigh that one on its own.
- *
- * Pending-ness is the recorded schema version, never the list's contents — the
- * rule 0002, 0004, 0005, and 0006 all follow, because the config schema fills
- * `skills.vendored` from the shipped default when the key is absent, so an
- * unmigrated store already reads as though it declared the new set.
- */
-export const addExplanationCraftSkillMigration = {
-    id: '0007-add-explanation-craft-skill',
-    fromVersion: 6,
-    toVersion: SCHEMA_VERSION,
-    description: `Add the explanation craft skill to a store whose skills.vendored list still sits at the previous shipped default, and bump schema_version to ${SCHEMA_VERSION}.`,
-    async plan(store) {
-        if (store.config.schema_version >= SCHEMA_VERSION)
-            return [];
-        const next = nextVendoredList(store.config.skills.vendored);
-        return [next ? configDelta(next) : versionOnlyDelta()];
-    },
-    async apply(store) {
-        if (store.config.schema_version >= SCHEMA_VERSION)
-            return [];
-        // Re-read from disk rather than trusting the store snapshot: an interrupted
-        // run may have written the config already, and resumability means deciding
-        // from current state.
-        const currentConfig = await readConfig(store.root);
-        const next = nextVendoredList(currentConfig.skills.vendored);
-        const nextConfig = {
-            ...currentConfig,
-            schema_version: SCHEMA_VERSION,
-            skills: { ...currentConfig.skills, vendored: next ?? currentConfig.skills.vendored },
-        };
-        await writeFileAtomic(path.join(store.root, 'contexture.yaml'), renderStoreConfig(nextConfig));
-        return [next ? configDelta(next) : versionOnlyDelta()];
-    },
-};
-//# sourceMappingURL=add-explanation-craft-skill.js.map