ctxr-cli 0.8.0 → 0.10.0

package/templates/skills/ctxr-connection-finding.md

@@ -5,11 +5,13 @@ to synthesize an entity's current state from its sources, use `ctxr-rollup`.
    document it writes at `__GRAPH_DOCUMENT_PATH__` — hub notes by cluster, cross-cluster bridges,
    orphans — for the cluster context the point queries below do not summarize.
 2. To find what a note connects to or from, run `ctxr graph query neighbors <path>` (add `--depth` for
-   further hops, `--direction in|out|both`, `--type <relation>` to follow one configured relation,
-   `--as <context>` to see only what that context can see).
-3. To find a path between two notes, run `ctxr graph query path <from> <to>`.
-4. To find the most-referenced notes, run `ctxr graph query hubs`; to find unlinked ones,
+   further hops, `--direction in|out|both`, `--type <relation>` to follow one configured relation).
+3. To read a neighbourhood rather than enumerate one — every reachable note with its catalog gloss,
+   hop distance, and why it was reached — run `ctxr context gather --seed <path> --hops <n>`. Use it
+   when you need to judge which links matter; use the point queries below when you need the structure.
+4. To find a path between two notes, run `ctxr graph query path <from> <to>`.
+5. To find the most-referenced notes, run `ctxr graph query hubs`; to find unlinked ones,
    `ctxr graph query orphans`; `ctxr graph query clusters` and `ctxr graph query bridges` show the
    cluster structure and the notes that span it.
-5. Report what the graph says — it enumerates structure and ranks nothing; judgment about which links
+6. Report what the graph says — it enumerates structure and ranks nothing; judgment about which links
    matter is yours.

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

@@ -1,15 +1,16 @@
 Ingest is synthesis, not filing. The question is what the store should know after this source, not where
 to put the file — "create a new note" is one option among several, never the default.
 
-1. Capture: write a plain markdown file directly into the inbox (see AGENTS.md's capture section) — no
-   provenance frontmatter; contexture assigns it at ingest.
+1. Capture: write the material into the inbox (see AGENTS.md's capture section). It may already carry
+   `source_type` and `source_id`; it must carry neither `source_hash` nor `ingested`, which ingest assigns.
+   The capture is kept — it is the store's record of what arrived, and it never becomes the note.
 2. Check: run `ctxr source check <path> --source-id <id>` and read the verdict — `new`, `already_ingested`,
    `drift` (same identity, the source's content moved — read what changed and decide whether to update the
    note, then `ctxr source stamp <path> --id <id>` once resolved), `alternate_source_match`, or
    `multiple_matches`. On `multiple_matches`, stop and resolve the ambiguity yourself; never guess which
-   existing note it is. A legacy note with an identity but no hash on file: `ctxr source stamp` backfills
-   it. A source re-published under a new URL you've confirmed is the same material:
-   `ctxr source add-alt <path> --id <new-id>` on the existing note, not a second ingest.
+   existing record it is. A record with an identity but no hash on file: `ctxr source stamp` backfills it.
+   A source re-published under a new URL you've confirmed is the same material:
+   `ctxr source add-alt <path> --id <new-id>` on the existing capture, not a second ingest.
 3. Read the source fully. Then read the existing cluster BEFORE writing anything: the catalog section for
    the domain (`ctxr catalog show --section <id>`), every related note in it (all of them, not one or two),
    and the graph (`ctxr graph build`, then read the graph document it writes at
@@ -36,7 +37,12 @@ to put the file — "create a new note" is one option among several, never the d
      headline is worse than either alone.
    - Source discipline: a field the source does not confirm is "not reported" — never inferred from
      silence in either direction.
-5. Write: for a new note, `ctxr ingest <path> --source-type <type> --source-id <id>` (stamps provenance and
-   gives it a catalog entry). Updates to existing notes are ordinary edits that preserve prior content
-   (a deliberate ingest despite an `alternate_source_match` is the same command).
-6. Verify: `ctxr lint` (orphans, broken links, leftover inbox material) and `ctxr catalog check`.
+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.
+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
+   its hash, cites it from the note, and rebuilds the catalog. A note that was expanded rather than created
+   records its provenance exactly as a new one does, and a note built from several sources cites all of
+   them. A deliberate ingest despite an `alternate_source_match` is the same command.
+7. Verify: `ctxr lint` (orphans, broken links, material still in the inbox) and `ctxr catalog check`.

package/templates/skills/ctxr-publish.md

@@ -1,7 +1,6 @@
-Turn store content into a shareable HTML page for a subject — a store subtree, a single note, a
-concept whose sources aren't co-located, or everything a named context admits. The gate below is the
-one step no convention can enforce by itself; everything else here is a decision procedure, not a
-mechanism.
+Turn store content into a shareable HTML page for a subject — a store subtree, a single note, or a
+concept whose sources aren't co-located. Deciding what belongs on the page is the one step no
+convention can enforce for you; everything else here is a decision procedure, not a mechanism.
 
 ## 1. Does this earn a page over a note?
 
@@ -51,10 +50,10 @@ notes came from, so the notes' shorthand does not survive the copy out. Load the
 store carries by default (or whichever explanation-focused skill it's configured instead), settle who
 the reader is before writing, and pitch every definition, analogy, and level of detail at them.
 
-Both skills say "audience", and neither means step 3's. There, `--audience` names who the store is
-being asked to disclose to and the answer is a verdict; here it names how much a reader already knows
-and the answer is a register. A comprehension level is never a value you pass to `--audience`, and
-writing plainly never widens what the page may contain — the gate in step 3 already settled that.
+Both skills say "audience", and here it means one thing only: how much the reader already knows,
+which is a question about register. It is never a reason to put more on the page. Step 3 settled what
+the page may carry, and writing that content more plainly never widens it — an explanation pitched
+lower is the same material in shorter words.
 
 ## 6. Verify the output invariants
 

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

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

@@ -1 +0,0 @@
-{"version":3,"file":"add-explanation-craft-skill.js","sourceRoot":"","sources":["../../../src/core/migrations/add-explanation-craft-skill.ts"],"names":[],"mappings":"AAAA,OAAO,IAAI,MAAM,WAAW,CAAC;AAC7B,OAAO,EAAE,uBAAuB,EAAE,MAAM,0BAA0B,CAAC;AACnE,OAAO,EAAE,UAAU,EAAE,MAAM,sBAAsB,CAAC;AAClD,OAAO,EAAE,iBAAiB,EAAE,MAAM,wBAAwB,CAAC;AAC3D,OAAO,EAAE,eAAe,EAAE,MAAM,iBAAiB,CAAC;AAGlD;;;;;GAKG;AACH,MAAM,oBAAoB,GAAG,CAAC,iBAAiB,CAAC,CAAC;AAEjD,MAAM,cAAc,GAAG,CAAC,CAAC;AAEzB,SAAS,WAAW,CAAC,IAAuB;IAC1C,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,2BAA2B,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,2BAA2B,cAAc,EAAE;KACnG,CAAC;AACJ,CAAC;AAED,SAAS,gBAAgB;IACvB,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,yBAAyB,cAAc,2DAA2D;KAChH,CAAC;AACJ,CAAC;AAED;;;;;;;;GAQG;AACH,SAAS,gBAAgB,CAAC,OAA0B;IAClD,MAAM,SAAS,GACb,OAAO,CAAC,MAAM,KAAK,oBAAoB,CAAC,MAAM,IAAI,OAAO,CAAC,KAAK,CAAC,CAAC,IAAI,EAAE,CAAC,EAAE,EAAE,CAAC,IAAI,KAAK,oBAAoB,CAAC,CAAC,CAAC,CAAC,CAAC;IACjH,IAAI,CAAC,SAAS;QAAE,OAAO,SAAS,CAAC;IAEjC,MAAM,OAAO,GAAG,CAAC,GAAG,uBAAuB,CAAC,CAAC;IAC7C,MAAM,KAAK,GAAG,OAAO,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC,OAAO,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC;IAChE,OAAO,KAAK,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,SAAS,CAAC;AAChD,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,MAAM,CAAC,MAAM,iCAAiC,GAAc;IAC1D,EAAE,EAAE,kCAAkC;IACtC,WAAW,EAAE,CAAC;IACd,SAAS,EAAE,cAAc;IACzB,WAAW,EAAE,gJAAgJ,cAAc,GAAG;IAE9K,KAAK,CAAC,IAAI,CAAC,KAAK;QACd,IAAI,KAAK,CAAC,MAAM,CAAC,cAAc,IAAI,cAAc;YAAE,OAAO,EAAE,CAAC;QAC7D,MAAM,IAAI,GAAG,gBAAgB,CAAC,KAAK,CAAC,MAAM,CAAC,MAAM,CAAC,QAAQ,CAAC,CAAC;QAC5D,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,WAAW,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,gBAAgB,EAAE,CAAC,CAAC;IACzD,CAAC;IAED,KAAK,CAAC,KAAK,CAAC,KAAK;QACf,IAAI,KAAK,CAAC,MAAM,CAAC,cAAc,IAAI,cAAc;YAAE,OAAO,EAAE,CAAC;QAE7D,4EAA4E;QAC5E,2EAA2E;QAC3E,sBAAsB;QACtB,MAAM,aAAa,GAAG,MAAM,UAAU,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;QACnD,MAAM,IAAI,GAAG,gBAAgB,CAAC,aAAa,CAAC,MAAM,CAAC,QAAQ,CAAC,CAAC;QAE7D,MAAM,UAAU,GAAG;YACjB,GAAG,aAAa;YAChB,cAAc,EAAE,cAAc;YAC9B,MAAM,EAAE,EAAE,GAAG,aAAa,CAAC,MAAM,EAAE,QAAQ,EAAE,IAAI,IAAI,aAAa,CAAC,MAAM,CAAC,QAAQ,EAAE;SACrF,CAAC;QACF,MAAM,eAAe,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,EAAE,iBAAiB,CAAC,EAAE,iBAAiB,CAAC,UAAU,CAAC,CAAC,CAAC;QAE/F,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,WAAW,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,gBAAgB,EAAE,CAAC,CAAC;IACzD,CAAC;CACF,CAAC"}

package/dist/core/migrations/archive-destination-from-taxonomy.d.ts

@@ -1,35 +0,0 @@
-import type { Migration } from './types.js';
-/**
- * archive-destination-from-taxonomy: `ctxr init` wrote a fixed
- * `DEFAULT_ARCHIVE_PATH` regardless of the taxonomy it had just resolved, so
- * every PARA store was born with `archive/` while its own taxonomy declared
- * `archives/` — a config key pointing at a directory the store does not have.
- * Init now asks the profile; this migration does the same for stores already
- * on disk.
- *
- * Two independent halves, and the second is conditional:
- *
- * 1. The key rename is unconditional — every schema-5 store gets
- *    `archive_destination`. `OrganizeSchema`'s fallback transform has already
- *    resolved the old spelling by the time `readConfig` returns, so writing
- *    the parsed config back is what drops `archive_path` from disk.
- * 2. The value only changes when the store never customized it AND its
- *    profile declares a destination of its own. An operator who deliberately
- *    set some other path keeps it; a Zettelkasten or Diataxis store, whose
- *    profile declares none, keeps `archive/` — for them this is a pure key
- *    rename. A custom taxonomy resolves to no shipped profile and is left
- *    alone for the same reason.
- *
- * Like 0004, the directory move is a plain filesystem rename (migrations see
- * only `Store` — `root` + `config`, no `GitRunner`), and it is skipped when
- * the old directory was never created. History survives either way: whatever
- * commits this output stages a coherent delete-old/add-new diff, which
- * `git log --follow`'s rename detection reads identically to a `git mv`.
- *
- * Pending-ness is `schema_version < 6`, not key presence — the rule 0002,
- * 0004, and 0005 established, for the same reason: the fallback transform
- * populates `archive_destination` on an unmigrated store too, so its presence
- * cannot distinguish migrated from not.
- */
-export declare const archiveDestinationFromTaxonomyMigration: Migration;
-//# sourceMappingURL=archive-destination-from-taxonomy.d.ts.map

package/dist/core/migrations/archive-destination-from-taxonomy.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"archive-destination-from-taxonomy.d.ts","sourceRoot":"","sources":["../../../src/core/migrations/archive-destination-from-taxonomy.ts"],"names":[],"mappings":"AAQA,OAAO,KAAK,EAAE,SAAS,EAAkB,MAAM,YAAY,CAAC;AAc5D;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+BG;AACH,eAAO,MAAM,uCAAuC,EAAE,SA4CrD,CAAC"}

package/dist/core/migrations/archive-destination-from-taxonomy.js

@@ -1,109 +0,0 @@
-import { existsSync } from 'node:fs';
-import { rename } from 'node:fs/promises';
-import path from 'node:path';
-import { readConfig } from '../../config/load.js';
-import { DEFAULT_ARCHIVE_DESTINATION } from '../../config/defaults.js';
-import { renderStoreConfig } from '../../config/render.js';
-import { profileById } from '../../taxonomy/profiles.js';
-import { writeFileAtomic } from '../fs/atomic.js';
-const CONFIG_DELTA = {
-    path: 'contexture.yaml',
-    description: 'rename organize.archive_path to organize.archive_destination and set schema_version to 6',
-};
-function destinationDelta(from, to) {
-    return {
-        path: to,
-        description: `adopt the taxonomy's own archive destination, moving the default-valued archive directory from ${from} to ${to}`,
-    };
-}
-/**
- * archive-destination-from-taxonomy: `ctxr init` wrote a fixed
- * `DEFAULT_ARCHIVE_PATH` regardless of the taxonomy it had just resolved, so
- * every PARA store was born with `archive/` while its own taxonomy declared
- * `archives/` — a config key pointing at a directory the store does not have.
- * Init now asks the profile; this migration does the same for stores already
- * on disk.
- *
- * Two independent halves, and the second is conditional:
- *
- * 1. The key rename is unconditional — every schema-5 store gets
- *    `archive_destination`. `OrganizeSchema`'s fallback transform has already
- *    resolved the old spelling by the time `readConfig` returns, so writing
- *    the parsed config back is what drops `archive_path` from disk.
- * 2. The value only changes when the store never customized it AND its
- *    profile declares a destination of its own. An operator who deliberately
- *    set some other path keeps it; a Zettelkasten or Diataxis store, whose
- *    profile declares none, keeps `archive/` — for them this is a pure key
- *    rename. A custom taxonomy resolves to no shipped profile and is left
- *    alone for the same reason.
- *
- * Like 0004, the directory move is a plain filesystem rename (migrations see
- * only `Store` — `root` + `config`, no `GitRunner`), and it is skipped when
- * the old directory was never created. History survives either way: whatever
- * commits this output stages a coherent delete-old/add-new diff, which
- * `git log --follow`'s rename detection reads identically to a `git mv`.
- *
- * Pending-ness is `schema_version < 6`, not key presence — the rule 0002,
- * 0004, and 0005 established, for the same reason: the fallback transform
- * populates `archive_destination` on an unmigrated store too, so its presence
- * cannot distinguish migrated from not.
- */
-export const archiveDestinationFromTaxonomyMigration = {
-    id: '0006-archive-destination-from-taxonomy',
-    fromVersion: 5,
-    toVersion: 6,
-    description: "Rename the organize.archive_path config key to organize.archive_destination, adopt the taxonomy profile's own archive destination when the value still sat at the shipped default, and bump schema_version to 6.",
-    async plan(store) {
-        if (store.config.schema_version >= 6)
-            return [];
-        const deltas = [CONFIG_DELTA];
-        const target = taxonomyDestination(store.config.taxonomy.profile, store.config.organize.archive_destination);
-        if (target)
-            deltas.push(destinationDelta(DEFAULT_ARCHIVE_DESTINATION, target));
-        return deltas;
-    },
-    async apply(store) {
-        if (store.config.schema_version >= 6)
-            return [];
-        const configPath = path.join(store.root, 'contexture.yaml');
-        const currentConfig = await readConfig(store.root);
-        const appliedDeltas = [CONFIG_DELTA];
-        let destination = currentConfig.organize.archive_destination;
-        const target = taxonomyDestination(currentConfig.taxonomy.profile, destination);
-        if (target) {
-            const oldDir = path.join(store.root, DEFAULT_ARCHIVE_DESTINATION);
-            const newDir = path.join(store.root, target);
-            // Absent whenever nothing was ever archived — only the config changes.
-            if (existsSync(oldDir) && !existsSync(newDir)) {
-                await rename(oldDir, newDir);
-            }
-            destination = target;
-            appliedDeltas.push(destinationDelta(DEFAULT_ARCHIVE_DESTINATION, target));
-        }
-        const nextConfig = {
-            ...currentConfig,
-            schema_version: 6,
-            organize: { ...currentConfig.organize, archive_destination: destination },
-        };
-        await writeFileAtomic(configPath, renderStoreConfig(nextConfig));
-        return appliedDeltas;
-    },
-};
-/**
- * The profile's own destination, but only when adopting it is safe: the
- * store must still be sitting on the shipped default (otherwise the value is
- * the operator's, not ours to rewrite), the profile must be a shipped one
- * that declares a destination, and it must actually differ from what's
- * already configured.
- */
-function taxonomyDestination(profileId, current) {
-    if (current !== DEFAULT_ARCHIVE_DESTINATION)
-        return undefined;
-    if (profileId === null)
-        return undefined;
-    const declared = profileById(profileId)?.archiveDestination;
-    if (declared === undefined || declared === current)
-        return undefined;
-    return declared;
-}
-//# sourceMappingURL=archive-destination-from-taxonomy.js.map

package/dist/core/migrations/archive-destination-from-taxonomy.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"archive-destination-from-taxonomy.js","sourceRoot":"","sources":["../../../src/core/migrations/archive-destination-from-taxonomy.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,SAAS,CAAC;AACrC,OAAO,EAAE,MAAM,EAAE,MAAM,kBAAkB,CAAC;AAC1C,OAAO,IAAI,MAAM,WAAW,CAAC;AAC7B,OAAO,EAAE,UAAU,EAAE,MAAM,sBAAsB,CAAC;AAClD,OAAO,EAAE,2BAA2B,EAAE,MAAM,0BAA0B,CAAC;AACvE,OAAO,EAAE,iBAAiB,EAAE,MAAM,wBAAwB,CAAC;AAC3D,OAAO,EAAE,WAAW,EAAE,MAAM,4BAA4B,CAAC;AACzD,OAAO,EAAE,eAAe,EAAE,MAAM,iBAAiB,CAAC;AAGlD,MAAM,YAAY,GAAmB;IACnC,IAAI,EAAE,iBAAiB;IACvB,WAAW,EAAE,0FAA0F;CACxG,CAAC;AAEF,SAAS,gBAAgB,CAAC,IAAY,EAAE,EAAU;IAChD,OAAO;QACL,IAAI,EAAE,EAAE;QACR,WAAW,EAAE,kGAAkG,IAAI,OAAO,EAAE,EAAE;KAC/H,CAAC;AACJ,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+BG;AACH,MAAM,CAAC,MAAM,uCAAuC,GAAc;IAChE,EAAE,EAAE,wCAAwC;IAC5C,WAAW,EAAE,CAAC;IACd,SAAS,EAAE,CAAC;IACZ,WAAW,EACT,kNAAkN;IAEpN,KAAK,CAAC,IAAI,CAAC,KAAK;QACd,IAAI,KAAK,CAAC,MAAM,CAAC,cAAc,IAAI,CAAC;YAAE,OAAO,EAAE,CAAC;QAChD,MAAM,MAAM,GAAqB,CAAC,YAAY,CAAC,CAAC;QAChD,MAAM,MAAM,GAAG,mBAAmB,CAAC,KAAK,CAAC,MAAM,CAAC,QAAQ,CAAC,OAAO,EAAE,KAAK,CAAC,MAAM,CAAC,QAAQ,CAAC,mBAAmB,CAAC,CAAC;QAC7G,IAAI,MAAM;YAAE,MAAM,CAAC,IAAI,CAAC,gBAAgB,CAAC,2BAA2B,EAAE,MAAM,CAAC,CAAC,CAAC;QAC/E,OAAO,MAAM,CAAC;IAChB,CAAC;IAED,KAAK,CAAC,KAAK,CAAC,KAAK;QACf,IAAI,KAAK,CAAC,MAAM,CAAC,cAAc,IAAI,CAAC;YAAE,OAAO,EAAE,CAAC;QAEhD,MAAM,UAAU,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,EAAE,iBAAiB,CAAC,CAAC;QAC5D,MAAM,aAAa,GAAG,MAAM,UAAU,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;QACnD,MAAM,aAAa,GAAqB,CAAC,YAAY,CAAC,CAAC;QAEvD,IAAI,WAAW,GAAG,aAAa,CAAC,QAAQ,CAAC,mBAAmB,CAAC;QAC7D,MAAM,MAAM,GAAG,mBAAmB,CAAC,aAAa,CAAC,QAAQ,CAAC,OAAO,EAAE,WAAW,CAAC,CAAC;QAChF,IAAI,MAAM,EAAE,CAAC;YACX,MAAM,MAAM,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,EAAE,2BAA2B,CAAC,CAAC;YAClE,MAAM,MAAM,GAAG,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,EAAE,MAAM,CAAC,CAAC;YAC7C,uEAAuE;YACvE,IAAI,UAAU,CAAC,MAAM,CAAC,IAAI,CAAC,UAAU,CAAC,MAAM,CAAC,EAAE,CAAC;gBAC9C,MAAM,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;YAC/B,CAAC;YACD,WAAW,GAAG,MAAM,CAAC;YACrB,aAAa,CAAC,IAAI,CAAC,gBAAgB,CAAC,2BAA2B,EAAE,MAAM,CAAC,CAAC,CAAC;QAC5E,CAAC;QAED,MAAM,UAAU,GAAG;YACjB,GAAG,aAAa;YAChB,cAAc,EAAE,CAAC;YACjB,QAAQ,EAAE,EAAE,GAAG,aAAa,CAAC,QAAQ,EAAE,mBAAmB,EAAE,WAAW,EAAE;SAC1E,CAAC;QACF,MAAM,eAAe,CAAC,UAAU,EAAE,iBAAiB,CAAC,UAAU,CAAC,CAAC,CAAC;QAEjE,OAAO,aAAa,CAAC;IACvB,CAAC;CACF,CAAC;AAEF;;;;;;GAMG;AACH,SAAS,mBAAmB,CAAC,SAAwB,EAAE,OAAe;IACpE,IAAI,OAAO,KAAK,2BAA2B;QAAE,OAAO,SAAS,CAAC;IAC9D,IAAI,SAAS,KAAK,IAAI;QAAE,OAAO,SAAS,CAAC;IACzC,MAAM,QAAQ,GAAG,WAAW,CAAC,SAAS,CAAC,EAAE,kBAAkB,CAAC;IAC5D,IAAI,QAAQ,KAAK,SAAS,IAAI,QAAQ,KAAK,OAAO;QAAE,OAAO,SAAS,CAAC;IACrE,OAAO,QAAQ,CAAC;AAClB,CAAC"}

package/dist/core/migrations/drop-access-axes.d.ts

@@ -1,24 +0,0 @@
-import type { Migration } from './types.js';
-/**
- * retire-the-access-axes: the visibility and disclosure axes are removed, and
- * with them `fields.visibility` (the configurable name of the visibility
- * frontmatter key).
- *
- * Unlike 0005, this migration cannot lean on `readConfig` having already
- * stripped the legacy shape: all three keys are TOP-LEVEL, and
- * `StoreConfigSchema` is `.passthrough()`, so they survive parsing intact.
- * Deleting them explicitly is the whole job.
- *
- * No note is rewritten (design.md D3). A note's retired visibility-field key
- * stays in its frontmatter, unread — `parseNote` reads frontmatter into a
- * `Record<string, unknown>` and nothing consumes that key any more, so it
- * costs nothing at runtime and keeps the removal cheap to reverse. Stripping
- * it would make re-entry a hand re-labelling pass over every note.
- *
- * Pending-ness is `schema_version < 8`, not key presence — the rule every
- * migration from 0002 onward established. A store could have had its config
- * hand-edited to drop the keys while still sitting at an older version, and
- * it still needs the version bump.
- */
-export declare const dropAccessAxesMigration: Migration;
-//# sourceMappingURL=drop-access-axes.d.ts.map

package/dist/core/migrations/drop-access-axes.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"drop-access-axes.d.ts","sourceRoot":"","sources":["../../../src/core/migrations/drop-access-axes.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EAAE,SAAS,EAAkB,MAAM,YAAY,CAAC;AAU5D;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,eAAO,MAAM,uBAAuB,EAAE,SAuBrC,CAAC"}