structured-context 0.11.0 → 0.13.0

package/docs/schemas.md

@@ -1,3 +1,7 @@
+---
+title: "Schemas"
+---
+
 # Schemas
 
 This document explains schema usage, metadata shape, and composition semantics in `structured-context`.
@@ -6,7 +10,7 @@ This document explains schema usage, metadata shape, and composition semantics i
 
 A **schema** defines the valid structure for nodes in a `space`: entity types, field constraints, hierarchy behavior, type aliases, and executable rules.
 
-`structured-context` uses JSON Schema Draft-07 plus a custom top-level `$metadata` keyword.
+`structured-context` uses JSON Schema 2020-12 plus a custom top-level `$metadata` keyword.
 
 ## Selecting a schema
 
@@ -20,6 +24,11 @@ Set `schema` in the space config entry:
 }
 ```
 
+A schema can be specified as:
+- **Bundled schema**: simple filename like `strategy_general.json` or `strict_ost.json`.
+- **Local file**: relative path starting with `./` or `../` (resolved against config file directory), or absolute path.
+- **Plugin schema**: prefixed with the plugin name, e.g. `sctx-wardley-mapping/wardley_map.json` or `wardley-mapping/wardley_map.json`. When prefixed, structured-context automatically loads the plugin for that space. Alternatively, if the plugin is already declared under `plugins`, the simple filename (e.g. `wardley_map.json`) resolves directly from that plugin.
+
 Resolution order: space `schema` > global `schema`. Schema resolution fails if none is configured.
 
 ## Bundled schemas
@@ -46,7 +55,23 @@ Main types:
 - `solution`
 - `assumption_test`
 
-This schema composes shared structural defs and strict metadata/rules from partials.
+This schema reuses shared structural defs from partials via `$ref` and imports its hierarchy and rules from `_ost_strict` via `$metadata.imports`.
+
+### `knowledge_wiki.json`
+
+Flat, LLM-maintained knowledge base (after Karpathy's LLM Wiki pattern). No hierarchy or required parent links; wikilinks between any pages are valid. Validates structure and provenance, not meaning.
+
+Main types:
+- `source`
+- `concept`
+- `entity`
+- `synthesis`
+- `note`
+- `index`
+
+### `okf.json`
+
+[Open Knowledge Format](https://github.com/GoogleCloudPlatform/open-knowledge-format) (OKF v0.2) bundles, validated as plain markdown spaces. Any concept `type` is accepted and unknown fields are tolerated; provenance (`sources`), trust (`generated`, `verified`), lifecycle (`status`, `stale_after`) and the Attested Computation contract are checked when present. An Attested Computation needs its computation: a `computation` field, or a `# Computation` section in the body (found by matching that line in the body text, so a `# Computation` line inside a code fence also counts). Reserved `index.md` and `log.md` are reported as excluded during parsing.
 
 ## Custom format annotations
 
@@ -54,14 +79,16 @@ This schema composes shared structural defs and strict metadata/rules from parti
 
 | Format | Validates | Example |
 |--------|-----------|---------|
-| `date` | ISO 8601 date (`YYYY-MM-DD`) | `"2026-03-31"` |
+| `date` | ISO 8601 calendar date (`YYYY-MM-DD`) | `"2026-03-31"` |
+| `date-time` | ISO 8601 datetime with seconds and a UTC offset (`Z` or `±HH:MM`) | `"2026-03-31T09:15:00+10:00"` |
+| `date-or-date-time` | A date, or a datetime where seconds and offset are optional (as Obsidian's datetime property writes) | `"2026-03-31"`, `"2026-03-31T09:15"`, `"2026-03-31T09:15:00Z"` |
 | `path` | Non-empty filesystem path — absolute, relative, or a plain name | `"notes"`, `"./subdir/file.md"`, `"/abs/path"` |
 | `wikilink` | Obsidian wikilink syntax (`[[...]]`) | `"[[Parent Node]]"` |
 
 `path` and `wikilink` are also available as shared `$ref` definitions in `_sctx_base.json`:
 
 ```json
-{ "$ref": "sctx://_sctx_base#/$defs/wikilink" }
+{ "$ref": "sctx://core/_sctx_base#/$defs/wikilink" }
 ```
 
 Using `format` directly is more concise when the full definition isn't needed:
@@ -70,21 +97,25 @@ Using `format` directly is more concise when the full definition isn't needed:
 { "type": "string", "format": "wikilink" }
 ```
 
-### Date coercion
+### Dates and datetimes
 
-YAML parsers (gray-matter, js-yaml) coerce unquoted ISO dates to JavaScript `Date` objects:
+The markdown plugin reads frontmatter and embedded YAML blocks without YAML's timestamp type, so unquoted dates and datetimes stay as the strings written, at any depth (including inside lists):
 
 ```yaml
-published_date: 2026-03-31   # parsed as a Date object by gray-matter
+published_date: 2026-03-31          # "2026-03-31"
+updated: 2026-06-20T22:53:05+10:00  # "2026-06-20T22:53:05+10:00", offset kept
 ```
 
-The markdown plugin automatically coerces `Date` objects to `YYYY-MM-DD` strings before validation, so unquoted dates in frontmatter and embedded YAML blocks work correctly with `format: "date"` fields.
+Validate them with `format: "date"` or `format: "date-time"` when a field needs one precision, or `format: "date-or-date-time"` to accept either, and compare them in rules with JSONata's `$toMillis()` (see [Rules](rules.md#dates-and-times)).
 
 ## Metadata dialect
 
-Schemas use this metaschema URL:
+The dialect is JSON Schema 2020-12 plus the top-level `$metadata` keyword. Schemas set `$schema` to the metaschema URL:
+
+- `https://raw.githubusercontent.com/mindsocket/structured-context/main/schemas/generated/latest/_structured_context_schema_meta.json` follows the newest dialect.
+- `https://raw.githubusercontent.com/mindsocket/structured-context/main/schemas/generated/<version>/_structured_context_schema_meta.json` pins the dialect to the structured-context release that first shipped it. Versioned files never change once released. Releases that don't change the dialect add no folder, so a version number only appears when the dialect changed.
 
-- `https://raw.githubusercontent.com/mindsocket/structured-context/main/schemas/generated/_structured_context_schema_meta.json`
+Because the dialect is 2020-12, keywords may sit beside `$ref`, and `unevaluatedProperties: false` can close an object composed through `allOf`.
 
 Top-level metadata shape:
 
@@ -108,8 +139,8 @@ Top-level metadata shape:
         "id": "active-outcome-count",
         "category": "workflow",
         "description": "Only one outcome should be active at a time",
-        "scope": "global",
-        "check": "$count(nodes[resolvedType='outcome' and status='active']) <= 1"
+        "global": true,
+        "expression": "$count(nodes[resolvedType='outcome' and status='active']) <= 1"
       }
     ]
   }
@@ -120,12 +151,15 @@ Top-level metadata shape:
 
 | Field | Type | Notes |
 |---|---|---|
-| `hierarchy` | object | Optional per provider; at most one provider may define it after composition |
+| `imports` | `string[]` | Optional; `$id`s of schemas whose metadata is merged into this one. See [Composition and merge semantics](#composition-and-merge-semantics) |
+| `hierarchy` | object | Optional; declares this schema's hierarchy, or (root schema only) selects the main hierarchy with `{ "$ref": "<schema $id>#/$metadata/hierarchy" }`. See [Multiple hierarchies](#multiple-hierarchies) |
+| `hierarchy.name` | `string` | Optional short name; defaults to the declaring schema's file stem |
+| `hierarchy.override` | `boolean` | Optional; replaces an imported hierarchy with the same name |
 | `hierarchy.levels` | `(string \| HierarchyLevel)[]` | Ordered root→leaf types |
 | `hierarchy.allowSkipLevels` | `boolean` | Optional; allows parent to be any ancestor level |
-| `relationships` | `Relationship[]` | Optional; defines related node links outside the primary hierarchy |
-| `aliases` | `Record<string, string>` | Optional type alias map |
-| `rules` | `Rule[]` | Optional flat rule array |
+| `relationships` | `Relationship[]` | Optional; defines related node links outside the primary hierarchy. A relationship may set `override: true` |
+| `aliases` | `Record<string, string \| { type, override }>` | Optional type alias map. Use `{ "type": "goal", "override": true }` to replace an imported alias |
+| `rules` | `Rule[]` | Optional flat rule array. A rule has an `expression` (a JSONata test), a `semantic` part (evaluated by a model against a rubric), or both; see [Rules](rules.md) |
 
 ### Relationships
 
@@ -137,9 +171,9 @@ Relationships define links between node types that are not part of the primary s
 | `type` | `string` | **Required** | The child's canonical type name |
 | `field` | `string` | `"parent"` | The frontmatter field that holds the wikilink(s) for this relationship |
 | `fieldOn` | `string` | `"child"` | `"child"` (child holds a link to parent) or `"parent"` (parent holds an array of child links) |
-| `format` | `string` | `"page"` | Hint for `template-sync`: `"table"`, `"list"`, or `"heading"` |
+| `templateFormat` | `string` | `"page"` | Hint for `template-sync`: `"table"`, `"list"`, or `"heading"` |
 | `matchers` | `string[]` | `[]` | Heading text to match (strings or `/regex/`). Case-insensitive. |
-| `embeddedTemplateFields` | `string[]` | `[]` | Field names to include in templates when `format` is `"table"` |
+| `embeddedTemplateFields` | `string[]` | `[]` | Field names to include in templates when `templateFormat` is `"table"` |
 | `multiple` | `boolean` | `true` | Whether multiple children are expected |
 
 **`fieldOn: "child"` (default)** — child node has a field pointing to its parent. Embedded parsing sets this field on each child node; validation checks that it resolves to a node of the declared parent type.
@@ -153,7 +187,7 @@ Relationships define links between node types that are not part of the primary s
   {
     "parent": "opportunity",
     "type": "assumption",
-    "format": "table",
+    "templateFormat": "table",
     "matchers": ["Assumptions", "/assum.*/"],
     "embeddedTemplateFields": ["assumption", "status", "confidence"]
   }
@@ -169,7 +203,7 @@ Relationships define links between node types that are not part of the primary s
     "type": "task",
     "field": "tasks",
     "fieldOn": "parent",
-    "format": "list",
+    "templateFormat": "list",
     "matchers": ["Tasks"],
     "multiple": true
   }
@@ -188,7 +222,7 @@ With this configuration, embedded task items under an Activity's "Tasks" heading
 | `multiple` | `false` | Field contains array of wikilinks |
 | `selfRef` | `false` | Allows same-type parent |
 | `selfRefField` | _undefined_ | Separate field for same-type parent links |
-| `format` | _undefined_ | Embedding hint: `"list"`, `"table"`, or `"heading"` — enables hierarchy embedding when set |
+| `templateFormat` | _undefined_ | Embedding hint: `"list"`, `"table"`, or `"heading"` — enables hierarchy embedding when set |
 | `matchers` | _undefined_ | Heading text patterns (strings or `/regex/`) to detect embedding sections |
 | `embeddedTemplateFields` | _undefined_ | Column/field names for table stubs generated by `template-sync` |
 
@@ -197,7 +231,7 @@ String shorthand (`"goal"`) normalizes to:
 
 ### Hierarchy embedding
 
-When a hierarchy level has `format` and `matchers`, it participates in **hierarchy embedding** — the same section-based parsing used for relationships. Two patterns are supported:
+When a hierarchy level has `templateFormat` and `matchers`, it participates in **hierarchy embedding** — the same section-based parsing used for relationships. Two patterns are supported:
 
 **Child-level embedding** — a typed-page heading signals that following content should produce nodes of the child type (next level in hierarchy):
 
@@ -208,7 +242,7 @@ When a hierarchy level has `format` and `matchers`, it participates in **hierarc
     "type": "opportunity",
     "field": "parent",
     "fieldOn": "child",
-    "format": "list",
+    "templateFormat": "list",
     "matchers": ["Opportunities", "User Opportunities"]
   }
 ]
@@ -250,39 +284,79 @@ With this config, an application page may include `### capability` with wikilink
 - [[Zephyr]]             ← populates application.tools (fieldOn: parent)
 ```
 
+A node's body becomes its `content`; see [Node content](concepts.md#node-content).
+
 ## Composition and merge semantics
 
-Metadata is composed across the `$ref` graph with deterministic behavior:
+`$ref` and `$defs` are for **validation only**: a `$ref` to another schema (or to one of its `$defs`) reuses its JSON Schema definitions but brings none of its `$metadata`.
+
+Metadata travels only through **`$metadata.imports`**, a list of schema `$id`s:
+
+```json5
+"$metadata": {
+  "imports": ["sctx://core/_strategy_general"],
+  "rules": [ /* this schema's own rules */ ]
+}
+```
+
+- An import brings the imported schema's whole `$metadata` (hierarchy, relationships, aliases, rules).
+- Imports are transitive: an imported schema's own imports come too.
+- Merge order: imports in the order listed, depth-first, then the schema's own metadata last. Each schema is merged at most once.
+- An unresolvable import `$id` is an error.
 
-1. Traverse external `$ref` graph in DFS order.
-2. Apply root schema metadata last.
+One merge rule applies to every key. **A duplicate is an error unless the later entry sets `"override": true`**, in which case it replaces the earlier entry.
 
-Merge rules:
-- `hierarchy`: may be defined in partials; **last one wins**. This allows partials to define a default hierarchy that composing schemas can override.
-- `aliases`: shallow merged; later file wins per key.
-- `relationships`: collected from all files; order preserved.
-- `rules`: merged by `id`.
-- Duplicate rule `id` with different payload errors by default.
-- A later rule may replace an earlier one only with `"override": true`.
+| Key | Identity | How to mark `override` |
+|---|---|---|
+| `rules` | `id` | `"override": true` on the rule |
+| `relationships` | `parent` + `type` + `field` (default `"parent"`) | `"override": true` on the relationship |
+| `aliases` | alias name | `{ "type": "<target>", "override": true }` as the alias value |
+| `hierarchy` | `name` | `"override": true` on the hierarchy declaration |
+
+Overriding a hierarchy by name is how a schema replaces the levels of an imported hierarchy (declare it with the same `name` and `"override": true`).
 
 When no provider defines `hierarchy`, hierarchy-based behavior is disabled (`show` tree shape, hierarchy validation, parent-edge checks). `space_on_a_page` parsing still requires hierarchy and will error without it.
 
-### Rule imports via `$ref`
+### Multiple hierarchies
+
+A space has several hierarchies when its schema imports several schemas that each declare one. Each schema declares at most one hierarchy.
 
-Inside `$metadata.rules`, entries can be inline rules or `$ref` imports:
+- **Every imported schema contributes its hierarchy.** Each is kept as a separate named hierarchy; levels are never merged.
+- **Naming.** `hierarchy.name` defaults to the declaring schema's file stem (`_ost_strict` for `_ost_strict.json`). A duplicate name is an error unless the later hierarchy sets `"override": true`.
+- **Main hierarchy.**
+  - If the root schema declares a hierarchy, it is the main hierarchy.
+  - If the root declares none and exactly one hierarchy is imported, that one is the main hierarchy (for example `strict_ost`, which imports `_ost_strict`).
+  - If the root declares none and several are imported, the root must select one with `"hierarchy": { "$ref": "<schema $id>#/$metadata/hierarchy" }`, otherwise loading the schema fails.
+  - A root that both declares a hierarchy and uses `$ref` is an error.
+- **Each type belongs to at most one hierarchy.** A type claimed by two hierarchies is an error. To change an imported hierarchy's levels, override it by name.
+- **Selections are not imported.** A `hierarchy: { "$ref" }` selection only applies when its schema is the root, so an imported schema stays usable standalone as another space's root.
 
 ```json5
-"rules": [
-  { "$ref": "sctx://my-pack#/$defs/workflowRule" },
-  { "$ref": "sctx://my-pack#/$defs/ruleSet" }
-]
+{
+  "$id": "sctx://team",
+  "oneOf": [
+    { "$ref": "sctx://_work#/$defs/goal" },
+    { "$ref": "sctx://_work#/$defs/task" },
+    { "$ref": "sctx://_skills#/$defs/skill_area" },
+    { "$ref": "sctx://_skills#/$defs/skill" }
+  ],
+  "$metadata": {
+    // _work.json and _skills.json each declare a hierarchy; select the main one.
+    "imports": ["sctx://_work", "sctx://_skills"],
+    "hierarchy": { "$ref": "sctx://_work#/$metadata/hierarchy" }
+  }
+}
 ```
 
-Import targets may be:
-- a single rule object
-- an object containing `rules: []`
+How hierarchies are used:
 
-Imported rules are normalized into one executable flat list before validation.
+| Behaviour | Hierarchies used |
+|---|---|
+| Layering, parent-type, skip-level and orphan checks | Each hierarchy, independently. A hierarchy edge whose parent belongs to another hierarchy is an invalid parent. |
+| Relationships | Connect types across hierarchies, as before |
+| `space_on_a_page` parsing, hierarchy embedding, `template-sync` | Main hierarchy |
+| `show`, `diagram`, `render` | Main hierarchy by default; `--hierarchy <name>` selects another |
+| `resolvedParents` | Hierarchy edges carry the `hierarchy` name |
 
 ### Override example
 
@@ -295,30 +369,56 @@ Imported rules are normalized into one executable flat list before validation.
         "override": true,
         "category": "workflow",
         "description": "Require exactly one active outcome",
-        "scope": "global",
-        "check": "$count(nodes[resolvedType='outcome' and status='active']) = 1"
+        "global": true,
+        "expression": "$count(nodes[resolvedType='outcome' and status='active']) = 1"
       }
     ]
   }
 }
 ```
 
+## Schema `$id` namespaces
+
+Every schema `$id` uses the `sctx://` scheme. The shape of the `$id` says where the schema comes from:
+
+| `$id` shape | Source | Example |
+|---|---|---|
+| `sctx://core/<name>` | Bundled with structured-context | `sctx://core/_sctx_base` |
+| `sctx://<plugin>/<name>` | Contributed by a plugin (its short name, without `sctx-`) | `sctx://wardley-mapping/_wardley` |
+| `sctx://<name>` | Local to a space's schema directory — a single name, no path | `sctx://team` |
+
+- Two schemas loaded for the same space may not share an `$id`; a collision is an error naming both sources.
+- `core` is reserved: no plugin may use it as its namespace.
+- **Legacy bundled ids:** before 1.0, bundled schemas used `sctx://<name>` (e.g. `sctx://_sctx_base`, `sctx://strategy_general`). References to those ids in `$ref` and `$metadata.imports` still resolve to their `sctx://core/` equivalents with a deprecation warning, and local schemas may not use them as their own `$id`. The aliases will be removed in 1.0.
+
 ## Partials and `$ref`
 
 - Files starting with `_` are auto-loaded partials.
-- Both bundled partials and local schema-directory partials are registered.
-- Local partial `$id` values must not collide with bundled IDs.
+- Bundled partials, local schema-directory partials, and partials from loaded plugins are all registered.
+- `$id` values follow the [namespace rules](#schema-id-namespaces) and must not collide across bundled, plugin and local schemas.
 - `$ref` resolution is transitive across files.
-- Partials with no `$metadata` should prefer `$schema: "http://json-schema.org/draft-07/schema#"` so they validate standalone as plain JSON Schema fragments.
-- **Bundled partials as entity libraries**: `_sctx_base.json`, `_strategy_general.json`, `_knowledge_wiki.json`, and `_ost_strict.json` provide reusable entity definitions and metadata. Composing schemas can reference these via `$ref` rather than redefining common entity types.
-- **Partials can carry metadata**: Partials may include `$metadata` (hierarchy, aliases, relationships, rules). This makes them self-contained units that bundle both type definitions and behavioral metadata.
+- Partials with no `$metadata` should prefer `$schema: "https://json-schema.org/draft/2020-12/schema"` so they validate standalone as plain JSON Schema fragments.
+- **Bundled partials as entity libraries**: `_sctx_base.json`, `_strategy_general.json`, `_knowledge_wiki.json`, `_okf.json`, and `_ost_strict.json` provide reusable entity definitions and metadata. Composing schemas can reference their entity types via `$ref` rather than redefining them.
+- **Partials can carry metadata**: Partials may include `$metadata` (hierarchy, aliases, relationships, rules). A schema gets it only by listing the partial in `$metadata.imports`; `$ref` alone brings none.
+
+## Plugin-contributed schemas
+
+Plugins contribute schemas and partials by standard directory convention: placing schema files in `<pluginRoot>/schemas/` (or declaring `"sctx": { "schemas": "./path" }` in `package.json`).
+
+Because schemas are resolved statically by convention from the filesystem, structured-context does not need to execute plugin JavaScript code during schema validation, context creation, or schema inspection.
+
+When a space uses a plugin schema:
+- **Registry registration**: All partials (`_*`) in the plugin's `schemas/` directory are automatically indexed in the schema registry.
+- **Namespace conventions**: Schemas contributed by a plugin must use `sctx://<pluginName>/...` for their `$id` (e.g. `sctx://wardley-mapping/_wardley`), where the prefix is the plugin's short name (without the `sctx-` prefix). See [Schema `$id` namespaces](#schema-id-namespaces).
+- **Collision protection**: If two plugins register schemas with the same `$id`, or a plugin or local schema collides with a bundled schema, schema loading throws an error.
+- **Imports and $ref**: Plugin schemas can `$ref` or `$metadata.imports` bundled schemas (e.g. `sctx://core/_sctx_base`) as well as other partials within their own namespace. Schema composition rules from #122 apply.
 
 ## Editor expectations
 
-Use the shipped metaschema URL in `$schema` for best cross-tool behavior.
+Use the shipped metaschema URL in `$schema` for best cross-tool behavior; pin a `<version>` URL if you need the dialect to stay fixed.
 
 Notes:
-- Custom `$id` values like `sctx://...` are still supported by the CLI registry.
+- `sctx://` `$id`s are resolved by the CLI registry (see [Schema `$id` namespaces](#schema-id-namespaces)).
 - Some generic editors may not resolve custom URI schemes for `$ref`; CLI behavior is authoritative.
 - Do not rely on editor-only mappings for runtime correctness.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "structured-context",
-  "version": "0.11.0",
+  "version": "0.13.0",
   "description": "Keep your content clean and your thinking clear with assistive tools for structured knowledge",
   "module": "./dist/index.js",
   "type": "module",
@@ -25,47 +25,53 @@
     "./types": {
       "types": "./dist/types.d.ts",
       "default": "./dist/types.js"
+    },
+    "./testing": {
+      "types": "./dist/testing.d.ts",
+      "default": "./dist/testing.js"
     }
   },
   "scripts": {
     "clean": "rm -rf dist",
     "generate:schema-meta": "bun run scripts/generate-schema-meta.ts",
     "typecheck": "tsc --noEmit",
-    "build": "bun run clean && bun run generate:schema-meta && tsc -p tsconfig.build.json && cp -r schemas dist/ && chmod +x dist/index.js",
+    "build": "bun run clean && bun run generate:schema-meta && tsc -p tsconfig.build.json && tsc-alias -p tsconfig.build.json && cp -r schemas dist/ && chmod +x dist/index.js",
     "prepublishOnly": "bun run build",
     "validate": "bun run src/index.ts validate",
     "diagram": "bun run src/index.ts diagram",
     "test": "bun test tests/",
     "test:smoke": "bun test smoke/",
+    "test:judge": "SCTX_LIVE_JUDGE_TESTS=1 bun test tests/judge/live.test.ts",
+    "test:models": "SCTX_MODEL_VALIDATION=1 bun test tests/judge/model-validation.test.ts",
     "test:hook": "bun test hook-test/unit/",
     "test:hook:e2e": "bun test hook-test/hooks.test.ts",
     "test:all": "bun test",
     "lint": "biome check",
     "lint:fix": "biome check --write",
     "preversion": "bun run generate:schema-meta && bun run lint:fix && bun run test",
-    "version": "git add -A",
+    "version": "bun run generate:schema-meta --release && git add -A",
     "postversion": "git push --follow-tags"
   },
   "devDependencies": {
-    "@anthropic-ai/claude-agent-sdk": "^0.2.92",
-    "@biomejs/biome": "^2.4.10",
+    "@anthropic-ai/claude-agent-sdk": "^0.3.191",
+    "@biomejs/biome": "^2.5.15",
     "@types/bun": "latest",
-    "@types/js-yaml": "^4.0.9",
     "json-schema-to-ts": "^3.1.1",
-    "lefthook": "^2.1.4"
+    "lefthook": "^2.1.9",
+    "tsc-alias": "^1.9.1"
   },
   "peerDependencies": {
     "typescript": "^5"
   },
   "dependencies": {
-    "ajv": "^8.18.0",
+    "ajv": "^8.20.0",
     "chokidar": "^5.0.0",
-    "commander": "^14.0.3",
+    "commander": "^15.0.0",
     "fast-glob": "^3.3.3",
     "gray-matter": "^4.0.3",
-    "js-yaml": "^4.1.1",
+    "js-yaml": "^5.4.3",
     "json5": "^2.2.3",
-    "jsonata": "^2.1.0",
+    "jsonata": "^2.2.1",
     "mdast-util-to-string": "^4.0.0",
     "remark-gfm": "^4.0.1",
     "remark-parse": "^11.0.0",

package/schemas/_knowledge_wiki.json

@@ -1,6 +1,6 @@
 {
-  "$schema": "https://raw.githubusercontent.com/mindsocket/structured-context/main/schemas/generated/_structured_context_schema_meta.json",
-  "$id": "sctx://_knowledge_wiki",
+  "$schema": "https://raw.githubusercontent.com/mindsocket/structured-context/main/schemas/generated/latest/_structured_context_schema_meta.json",
+  "$id": "sctx://core/_knowledge_wiki",
   // Shared entity definitions for knowledge wiki schemas.
   // Provides aliases, relationships, rules, and entity type $defs.
   // This partial has no hierarchy — wiki entities are flat with no required parent links.
@@ -50,14 +50,14 @@
         "category": "coherence",
         "description": "Syntheses should reference at least one contributing source in their sources array",
         "type": "synthesis",
-        "check": "$exists(current.sources) and $count(current.sources) >= 1"
+        "expression": "$exists(current.sources) and $count(current.sources) >= 1"
       },
       {
         "id": "concept-has-summary",
         "category": "best-practice",
         "description": "Concept pages should have a short summary for index discoverability",
         "type": "concept",
-        "check": "$exists(current.summary) and $length(current.summary) > 0"
+        "expression": "$exists(current.summary) and $length(current.summary) > 0"
       }
     ]
   },
@@ -65,18 +65,18 @@
     "source": {
       "type": "object",
       "description": "A processed summary of a raw source (article, paper, book, video, thread, podcast, etc.). Captures key information from the source in structured form with provenance.",
-      "allOf": [{ "$ref": "sctx://_sctx_base#/$defs/baseNodeProps" }],
+      "allOf": [{ "$ref": "sctx://core/_sctx_base#/$defs/baseNodeProps" }],
       "properties": {
         "type": { "const": "source" },
         "summary": {
-          "$ref": "sctx://_sctx_base#/$defs/summary"
+          "$ref": "sctx://core/_sctx_base#/$defs/summary"
         },
         "url": {
           "type": "string",
           "description": "URL of the original source"
         },
         "local_copy": {
-          "$ref": "sctx://_sctx_base#/$defs/wikilink",
+          "$ref": "sctx://core/_sctx_base#/$defs/wikilink",
           "description": "Wikilink to a local copy of the source (e.g. a saved PDF or clipped note)"
         },
         "author": {
@@ -89,7 +89,7 @@
         },
         "published_date": {
           "type": "string",
-          "format": "date",
+          "format": "date-or-date-time",
           "description": "Original publication date"
         },
         "source_type": {
@@ -98,7 +98,7 @@
         },
         "sources": {
           "type": "array",
-          "items": { "$ref": "sctx://_sctx_base#/$defs/wikilink" },
+          "items": { "$ref": "sctx://core/_sctx_base#/$defs/wikilink" },
           "description": "Wikilinks to other source pages that this one references or extends"
         }
       },
@@ -117,20 +117,20 @@
     "concept": {
       "type": "object",
       "description": "A concept page — defines and frames a specific idea, mechanism, or domain term. May draw from multiple sources. The building blocks of the wiki's knowledge graph.",
-      "allOf": [{ "$ref": "sctx://_sctx_base#/$defs/baseNodeProps" }],
+      "allOf": [{ "$ref": "sctx://core/_sctx_base#/$defs/baseNodeProps" }],
       "properties": {
         "type": { "const": "concept" },
         "summary": {
-          "$ref": "sctx://_sctx_base#/$defs/summary"
+          "$ref": "sctx://core/_sctx_base#/$defs/summary"
         },
         "sources": {
           "type": "array",
-          "items": { "$ref": "sctx://_sctx_base#/$defs/wikilink" },
+          "items": { "$ref": "sctx://core/_sctx_base#/$defs/wikilink" },
           "description": "Wikilinks to source pages that contributed to this concept"
         },
         "related": {
           "type": "array",
-          "items": { "$ref": "sctx://_sctx_base#/$defs/wikilink" },
+          "items": { "$ref": "sctx://core/_sctx_base#/$defs/wikilink" },
           "description": "Wikilinks to related concept or synthesis pages"
         }
       },
@@ -147,20 +147,20 @@
     "entity": {
       "type": "object",
       "description": "A concrete entity — a person, organisation, product, model, or other named thing. The building blocks of the wiki's knowledge graph alongside concepts. Entities are distinct from concepts: a concept frames an idea or mechanism; an entity is a specific, identifiable thing in the world.",
-      "allOf": [{ "$ref": "sctx://_sctx_base#/$defs/baseNodeProps" }],
+      "allOf": [{ "$ref": "sctx://core/_sctx_base#/$defs/baseNodeProps" }],
       "properties": {
         "type": { "const": "entity" },
         "summary": {
-          "$ref": "sctx://_sctx_base#/$defs/summary"
+          "$ref": "sctx://core/_sctx_base#/$defs/summary"
         },
         "sources": {
           "type": "array",
-          "items": { "$ref": "sctx://_sctx_base#/$defs/wikilink" },
+          "items": { "$ref": "sctx://core/_sctx_base#/$defs/wikilink" },
           "description": "Wikilinks to source pages that contributed to this entity page"
         },
         "related": {
           "type": "array",
-          "items": { "$ref": "sctx://_sctx_base#/$defs/wikilink" },
+          "items": { "$ref": "sctx://core/_sctx_base#/$defs/wikilink" },
           "description": "Wikilinks to related entity, concept, or synthesis pages"
         }
       },
@@ -177,20 +177,20 @@
     "synthesis": {
       "type": "object",
       "description": "A synthesis page — connects multiple concepts and sources into a coherent model, framework, or thesis. The highest-value pages in a knowledge wiki. Must reference contributing sources.",
-      "allOf": [{ "$ref": "sctx://_sctx_base#/$defs/baseNodeProps" }],
+      "allOf": [{ "$ref": "sctx://core/_sctx_base#/$defs/baseNodeProps" }],
       "properties": {
         "type": { "const": "synthesis" },
         "summary": {
-          "$ref": "sctx://_sctx_base#/$defs/summary"
+          "$ref": "sctx://core/_sctx_base#/$defs/summary"
         },
         "sources": {
           "type": "array",
-          "items": { "$ref": "sctx://_sctx_base#/$defs/wikilink" },
+          "items": { "$ref": "sctx://core/_sctx_base#/$defs/wikilink" },
           "description": "Wikilinks to source pages this synthesis draws from"
         },
         "concepts": {
           "type": "array",
-          "items": { "$ref": "sctx://_sctx_base#/$defs/wikilink" },
+          "items": { "$ref": "sctx://core/_sctx_base#/$defs/wikilink" },
           "description": "Wikilinks to concept pages this synthesis connects"
         }
       },
@@ -208,12 +208,12 @@
     "note": {
       "type": "object",
       "description": "Personal notes, journal entries, talk notes, or rough thoughts not drawn from an external URL.",
-      "allOf": [{ "$ref": "sctx://_sctx_base#/$defs/baseNodeProps" }],
+      "allOf": [{ "$ref": "sctx://core/_sctx_base#/$defs/baseNodeProps" }],
       "properties": {
         "type": { "const": "note" },
         "date": {
           "type": "string",
-          "format": "date",
+          "format": "date-or-date-time",
           "description": "Date this entry was created or relates to"
         }
       },
@@ -230,7 +230,7 @@
     "index": {
       "type": "object",
       "description": "The wiki index — a catalog of all pages with links, summaries, and metadata. Updated by the agent on ingest. Used as the primary navigation entry point.",
-      "allOf": [{ "$ref": "sctx://_sctx_base#/$defs/baseNodeProps" }],
+      "allOf": [{ "$ref": "sctx://core/_sctx_base#/$defs/baseNodeProps" }],
       "properties": {
         "type": { "const": "index" }
       },