Merge worktree-wizards-purge-2026-05-27 — purge wizards references from all committed artifacts

Author: dmealing

CHANGELOG.md

@@ -99,8 +99,8 @@ this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.htm
 ### Changed
 - Conformance fixtures `provider-extension-new-subtype-success` and
   `provider-extension-missing-provider-fails` swap their test-only provider
-  from `wizards-template-toolcall` (now meaningless — toolcall is core) to
-  `wizards-template-briefing` (a hypothetical briefing template, clearly
+  from `example-template-toolcall` (now meaningless — toolcall is core) to
+  `example-template-briefing` (a hypothetical briefing template, clearly
   fictional). The fixtures still demonstrate `registry.register` of a new
   subtype, just using a name that doesn't collide with the new core
   subtype. TS / C# / Python adapter providers and fixture inputs/expected
@@ -176,7 +176,7 @@ documented behavior.
 - **5 conformance fixtures** under `fixtures/conformance/` exercising
   the contract cross-port:
   `provider-extension-new-subtype-success` (positive: a test-only
-  `wizards-template-toolcall` provider registers `template.toolcall`),
+  `example-template-toolcall` provider registers `template.toolcall`),
   `provider-extension-missing-provider-fails` (`ERR_UNKNOWN_SUBTYPE`),
   `provider-extension-dependency-cycle` (`ERR_PROVIDER_DEPENDENCY_CYCLE`),
   `provider-extension-missing-dependency`

docs/features/extending-with-providers.md

@@ -57,8 +57,8 @@ import {
   ATTR_SUBTYPE_STRING,
 } from "@metaobjectsdev/metadata";
 
-export const wizardsToolcallProvider: MetaDataTypeProvider = {
-  id: "wizards-template-toolcall",
+export const exampleToolcallProvider: MetaDataTypeProvider = {
+  id: "example-template-toolcall",
   dependencies: ["metaobjects-core-types"],
   description: "Adds template.toolcall for LLM tool-use templates.",
   registerTypes(registry) {
@@ -105,10 +105,10 @@ dependency order, skipping any ambient discovery.**
 ```ts
 // TypeScript
 import { loadMemory } from "@metaobjectsdev/sdk";
-import { wizardsToolcallProvider } from "./codegen/providers";
+import { exampleToolcallProvider } from "./codegen/providers";
 
 const root = await loadMemory("./", {
-  providers: [wizardsToolcallProvider],   // composed AFTER core providers
+  providers: [exampleToolcallProvider],   // composed AFTER core providers
 });
 ```
 
@@ -120,7 +120,7 @@ var loader = MetaDataLoader.FromDirectory("./metadata", registry);
 
 ```python
 # Python
-loader = MetaDataLoader.from_directory("./metadata", providers=[wizards_toolcall_provider])
+loader = MetaDataLoader.from_directory("./metadata", providers=[example_toolcall_provider])
 ```
 
 ```java

docs/ports/java.md

@@ -99,14 +99,14 @@ class on the classpath, list its FQCN in
 alongside the core providers:
 
 ```java
-// src/main/java/com/example/wizards/WizardsToolcallProvider.java
-package com.example.wizards;
+// src/main/java/com/example/providers/ExampleToolcallProvider.java
+package com.example.providers;
 
 import com.metaobjects.registry.MetaDataTypeProvider;
 import com.metaobjects.registry.MetaDataRegistry;
 
-public class WizardsToolcallProvider implements MetaDataTypeProvider {
-    @Override public String getProviderId()   { return "wizards-template-toolcall"; }
+public class ExampleToolcallProvider implements MetaDataTypeProvider {
+    @Override public String getProviderId()   { return "example-template-toolcall"; }
     @Override public String[] getDependencies() { return new String[] { "core-types" }; }
     @Override public void registerTypes(MetaDataRegistry registry) {
         // registry.register(...) — see the cross-port contract
@@ -116,7 +116,7 @@ public class WizardsToolcallProvider implements MetaDataTypeProvider {
 
 ```
 # src/main/resources/META-INF/services/com.metaobjects.registry.MetaDataTypeProvider
-com.example.wizards.WizardsToolcallProvider
+com.example.providers.ExampleToolcallProvider
 ```
 
 The provider contract is structurally identical to TS / C# / Python (id +

docs/recipes/extending-metaobjects-with-providers.md

@@ -1,7 +1,7 @@
 # Extending MetaObjects with a custom provider
 
 This recipe walks through adding a new metamodel subtype to a downstream
-project — using the same `wizards-template-toolcall` example the conformance
+project — using the same `example-template-toolcall` example the conformance
 fixtures use, so the example here matches a real test that runs in TS, C#,
 and Python.
 
@@ -24,7 +24,7 @@ envelope your app needs to drive Anthropic's `tool_use` mode. You want:
    functions.
 
 The recipe shows steps 1 + 2. Step 3 (the custom generator) follows the
-existing `wizardRegistry` pattern in this repo — see
+existing `exampleRegistry` pattern in this repo — see
 [`features/templates-and-payloads.md`](../features/templates-and-payloads.md)
 for how custom generators walk MO-typed metadata.
 
@@ -33,7 +33,7 @@ for how custom generators walk MO-typed metadata.
 A provider is ~25 lines. Drop it next to your codegen config:
 
 ```ts
-// src/codegen/wizards-provider.ts
+// src/codegen/example-provider.ts
 import {
   type MetaDataTypeProvider,
   TYPE_TEMPLATE,
@@ -44,8 +44,8 @@ import {
   ATTR_SUBTYPE_STRING,
 } from "@metaobjectsdev/metadata";
 
-export const wizardsProvider: MetaDataTypeProvider = {
-  id: "wizards-template-toolcall",
+export const exampleProvider: MetaDataTypeProvider = {
+  id: "example-template-toolcall",
   dependencies: ["metaobjects-core-types"],
   description: "Adds template.toolcall for LLM tool-use templates.",
   registerTypes(registry) {
@@ -89,12 +89,12 @@ Notable bits:
 // metaobjects.config.ts
 import { defineConfig } from "@metaobjectsdev/cli";
 import { entityFile, queriesFile, barrel, promptRender } from "@metaobjectsdev/codegen-ts/generators";
-import { wizardsProvider } from "./src/codegen/wizards-provider";
+import { exampleProvider } from "./src/codegen/example-provider";
 
 export default defineConfig({
   outDir: "src/db/generated",
   dialect: "sqlite",
-  providers: [wizardsProvider],                            // ← the new field
+  providers: [exampleProvider],                            // ← the new field
   generators: [entityFile(), queriesFile(), barrel(), promptRender()],
 });
 ```
@@ -108,20 +108,20 @@ tooling sees the same metamodel.
 ```jsonc
 // metaobjects/meta.toolcalls.json
 { "metadata.root": {
-    "package": "wizards",
+    "package": "examples",
     "children": [
       { "object.value": {
-        "name": "WizardCall",
+        "name": "ToolCall",
         "children": [
           { "field.string": { "name": "spell" } },
           { "field.string": { "name": "target" } }
         ]
       }},
       { "template.toolcall": {
-        "name": "InvokeWizard",
-        "@payloadRef": "WizardCall",
-        "@textRef": "wizards/invoke",
-        "@toolName": "invoke_wizard"
+        "name": "InvokeTool",
+        "@payloadRef": "ToolCall",
+        "@textRef": "tools/invoke",
+        "@toolName": "invoke_tool"
       }}
     ]
 }}
@@ -132,23 +132,23 @@ YAML works just as well:
 ```yaml
 # metaobjects/meta.toolcalls.yaml
 metadata:
-  package: wizards
+  package: examples
   children:
     - object.value:
-        name: WizardCall
+        name: ToolCall
         children:
           - field.string: { name: spell }
           - field.string: { name: target }
     - template.toolcall:
-        name: InvokeWizard
-        "@payloadRef": WizardCall
-        "@textRef": wizards/invoke
-        "@toolName": invoke_wizard
+        name: InvokeTool
+        "@payloadRef": ToolCall
+        "@textRef": tools/invoke
+        "@toolName": invoke_tool
 ```
 
 Run `meta gen` and the loader recognizes `template.toolcall`, validates the
 three required attrs, and resolves `@payloadRef` against the package's
-`WizardCall` value-object.
+`ToolCall` value-object.
 
 ## 4. What you get from this
 
@@ -160,8 +160,8 @@ Once the provider is wired, three things happen automatically:
 - **A traversable AST.** Custom code generators can walk
   `root.ownChildren().filter((c) => c.type === "template" && c.subType === "toolcall")`
   to find every toolcall declaration. The
-  [`wizards-template-toolcall` example in
-  the canonical pattern is the existing `wizardRegistry` generator: it walks
+  [`example-template-toolcall` example in
+  the canonical pattern is the existing `exampleRegistry` generator: it walks
   `root.ownChildren()` filtered by `(type, subType)` and emits one TS file per
   matched node. Custom toolcall generators do the same — emit
   `callEmit<Name>(params)` wrapper functions, one per toolcall declaration.
@@ -178,12 +178,12 @@ $ meta gen
 
 $ meta verify
 ✓ No metadata drift. 4 providers composed:
-    metaobjects-core-types, metaobjects-forge, metaobjects-documentation, wizards-template-toolcall
+    metaobjects-core-types, metaobjects-forge, metaobjects-documentation, example-template-toolcall
 ```
 
 ## What happens when the provider is missing
 
-Forget to add `providers: [wizardsProvider]` to `defineConfig` (or to delete
+Forget to add `providers: [exampleProvider]` to `defineConfig` (or to delete
 the provider entirely), and the same metadata fails to load:
 
 ```
@@ -208,7 +208,7 @@ is the API surface for loader composition. See the per-port quickstarts:
 
 The provider object itself is structurally identical across languages
 (id + dependencies + description + a body that calls `registry.register` or
-`registry.extend`). A C# port of `wizardsProvider` reads exactly like the TS
+`registry.extend`). A C# port of `exampleProvider` reads exactly like the TS
 version with C# spelling.
 
 ## When NOT to write a provider

fixtures/conformance/provider-extension-dependency-cycle/input/meta.empty.json

@@ -1,6 +1,6 @@
 {
   "metadata.root": {
-    "package": "wizards",
+    "package": "examples",
     "children": []
   }
 }

fixtures/conformance/provider-extension-duplicate-id/input/meta.empty.json

@@ -1,6 +1,6 @@
 {
   "metadata.root": {
-    "package": "wizards",
+    "package": "examples",
     "children": []
   }
 }

fixtures/conformance/provider-extension-missing-dependency/input/meta.empty.json

@@ -1,6 +1,6 @@
 {
   "metadata.root": {
-    "package": "wizards",
+    "package": "examples",
     "children": []
   }
 }

fixtures/conformance/provider-extension-missing-provider-fails/input/meta.briefing.json

@@ -1,6 +1,6 @@
 {
   "metadata.root": {
-    "package": "wizards",
+    "package": "examples",
     "children": [
       {
         "object.value": {

fixtures/conformance/provider-extension-new-subtype-success/expected.json

@@ -1,6 +1,6 @@
 {
   "metadata.root": {
-    "package": "wizards",
+    "package": "examples",
     "children": [
       {
         "object.value": {

fixtures/conformance/provider-extension-new-subtype-success/input/meta.briefing.json

@@ -1,6 +1,6 @@
 {
   "metadata.root": {
-    "package": "wizards",
+    "package": "examples",
     "children": [
       {
         "object.value": {