@a-company/paradigm 3.28.0 → 3.34.0

package/dist/{orchestrate-HMSQ2CED.js → orchestrate-3SI6ON33.js}

@@ -2,7 +2,7 @@
 import {
   BackgroundOrchestrator,
   Orchestrator
-} from "./chunk-ZOH24ZPF.js";
+} from "./chunk-3BGSDKWD.js";
 import "./chunk-6QC3YGB6.js";
 import "./chunk-J26YQVAK.js";
 import "./chunk-PBHIFAL4.js";
@@ -15,8 +15,8 @@ import {
   formatCost,
   formatTokens
 } from "./chunk-5JGJACDU.js";
-import "./chunk-6P4IFIK2.js";
-import "./chunk-MRENOFTR.js";
+import "./chunk-CTF6RHKG.js";
+import "./chunk-VUSCJJ4A.js";
 import "./chunk-IRKUEJVW.js";
 import "./chunk-ZXMDA7VB.js";
 

package/dist/{probe-SN4BNXOC.js → probe-ABMGCXQG.js}

@@ -2,15 +2,15 @@
 import {
   generateFlowIndex,
   generateNavigator
-} from "./chunk-W4VFKZVF.js";
+} from "./chunk-S5TDFT5Q.js";
 import {
   generateScanIndex,
   serializeScanIndex
-} from "./chunk-AK5M6KJB.js";
+} from "./chunk-36TKPM5Z.js";
 import {
   aggregateFromDirectory
-} from "./chunk-6P4IFIK2.js";
-import "./chunk-MRENOFTR.js";
+} from "./chunk-CTF6RHKG.js";
+import "./chunk-VUSCJJ4A.js";
 import "./chunk-IRKUEJVW.js";
 import "./chunk-Z7W7HNRG.js";
 import {

package/dist/{reindex-YG3KIXAK.js → reindex-YC7LD4MN.js}

@@ -3,7 +3,7 @@ import {
   getReindexToolsList,
   handleReindexTool,
   rebuildStaticFiles
-} from "./chunk-7IJ5JVKT.js";
+} from "./chunk-PFLWLC6J.js";
 import "./chunk-3DYYXGDC.js";
 export {
   getReindexToolsList,

package/dist/{remember-IEBQHXHZ.js → remember-WR6ZVXLT.js}

@@ -2,7 +2,7 @@
 import {
   aggregatePurposes,
   getAllPurposeFiles
-} from "./chunk-MRENOFTR.js";
+} from "./chunk-VUSCJJ4A.js";
 import "./chunk-ZXMDA7VB.js";
 
 // src/commands/purpose/remember.ts

package/dist/{ripple-DFMXLFWI.js → ripple-QTXKJCEI.js}

@@ -7,8 +7,8 @@ import {
   getSymbol,
   getSymbolsByType,
   parseSymbol
-} from "./chunk-6P4IFIK2.js";
-import "./chunk-MRENOFTR.js";
+} from "./chunk-CTF6RHKG.js";
+import "./chunk-VUSCJJ4A.js";
 import "./chunk-IRKUEJVW.js";
 import {
   log

package/dist/sentinel.js

@@ -8,28 +8,28 @@ var { version: VERSION } = require2("../package.json");
 var program = new Command();
 program.name("sentinel").description("Semantic error monitoring \u2014 errors that speak your language").version(VERSION);
 program.command("defend", { isDefault: true }).description("Launch the Sentinel dashboard").option("-p, --port <port>", "Port number", "3838").option("--no-open", "Don't open browser").action(async (opts) => {
-  const { launchDashboard } = await import("./commands-6ZVTD74M.js");
+  const { launchDashboard } = await import("./commands-KPT2T2OZ.js");
   await launchDashboard(opts);
 });
 program.command("init").description("Initialize Sentinel in current project").option("--detect", "Auto-detect symbols from codebase").action(async (opts) => {
-  const { initProject } = await import("./commands-6ZVTD74M.js");
+  const { initProject } = await import("./commands-KPT2T2OZ.js");
   await initProject(opts);
 });
 var triage = program.command("triage").description("Incident triage");
 triage.command("list").description("List incidents").option("-s, --status <status>", "Filter by status (open, investigating, resolved, wont-fix)").option("-e, --env <env>", "Filter by environment").option("--symbol <symbol>", "Filter by symbol").option("-n, --limit <n>", "Max results", "10").action(async (opts) => {
-  const { triageList } = await import("./commands-6ZVTD74M.js");
+  const { triageList } = await import("./commands-KPT2T2OZ.js");
   await triageList(opts);
 });
 triage.command("show <id>").description("Show incident details").option("--timeline", "Include flow timeline").action(async (id, opts) => {
-  const { triageShow } = await import("./commands-6ZVTD74M.js");
+  const { triageShow } = await import("./commands-KPT2T2OZ.js");
   await triageShow(id, opts);
 });
 triage.command("resolve <id>").description("Resolve an incident").option("--pattern <id>", "Pattern that resolved it").option("--commit <hash>", "Fix commit").option("--notes <text>", "Resolution notes").action(async (id, opts) => {
-  const { triageResolve } = await import("./commands-6ZVTD74M.js");
+  const { triageResolve } = await import("./commands-KPT2T2OZ.js");
   await triageResolve(id, opts);
 });
 triage.command("stats").description("Show incident statistics").option("-p, --period <period>", "Period (7d, 30d, 90d)", "7d").action(async (opts) => {
-  const { triageStats } = await import("./commands-6ZVTD74M.js");
+  const { triageStats } = await import("./commands-KPT2T2OZ.js");
   await triageStats(opts);
 });
 program.parse();

package/dist/{setup-HOI52TN3.js → setup-ASR6OMKV.js}

@@ -2,14 +2,14 @@
 import {
   cursorrrulesExists,
   writeCursorrules
-} from "./chunk-KWDTBXP2.js";
-import "./chunk-AK5M6KJB.js";
+} from "./chunk-LHLIAYQ3.js";
+import "./chunk-36TKPM5Z.js";
 import {
   getDefaultPremiseContent
-} from "./chunk-6P4IFIK2.js";
+} from "./chunk-CTF6RHKG.js";
 import {
   getDefaultPurposeContent
-} from "./chunk-MRENOFTR.js";
+} from "./chunk-VUSCJJ4A.js";
 import "./chunk-IRKUEJVW.js";
 import {
   DEFAULT_CONVENTIONS,

package/dist/{shift-DRF5M3G6.js → shift-7XLSBLDW.js}

@@ -1,8 +1,8 @@
 #!/usr/bin/env node
 import {
   teamInitCommand
-} from "./chunk-N6RNYCZD.js";
-import "./chunk-ZOH24ZPF.js";
+} from "./chunk-UQNTJ5VB.js";
+import "./chunk-3BGSDKWD.js";
 import "./chunk-6QC3YGB6.js";
 import "./chunk-J26YQVAK.js";
 import "./chunk-PBHIFAL4.js";
@@ -15,7 +15,7 @@ import {
 } from "./chunk-DS5QY37M.js";
 import {
   detectProjectRole
-} from "./chunk-OXG5GVDJ.js";
+} from "./chunk-WOONGZ3C.js";
 import "./chunk-MW5DMGBB.js";
 import {
   doctorCommand
@@ -23,13 +23,13 @@ import {
 import "./chunk-5JGJACDU.js";
 import {
   initCommand
-} from "./chunk-SCC77UUP.js";
+} from "./chunk-H4TVBJD4.js";
 import {
   indexCommand
-} from "./chunk-W4VFKZVF.js";
-import "./chunk-AK5M6KJB.js";
-import "./chunk-6P4IFIK2.js";
-import "./chunk-MRENOFTR.js";
+} from "./chunk-S5TDFT5Q.js";
+import "./chunk-36TKPM5Z.js";
+import "./chunk-CTF6RHKG.js";
+import "./chunk-VUSCJJ4A.js";
 import "./chunk-IRKUEJVW.js";
 import "./chunk-Z7W7HNRG.js";
 import {
@@ -116,6 +116,16 @@ discipline: ${detected}`
       }
     }
   }
+  if (isInitialized) {
+    spinner.start("Step 1b/6: Checking for migrations...");
+    try {
+      const { migrateCommand } = await import("./migrate-HRN5TUBQ.js");
+      await migrateCommand({ apply: true, quiet: true, noSync: true });
+      spinner.succeed(chalk.green("Migrations applied"));
+    } catch (error) {
+      spinner.warn(chalk.yellow(`Migration warning: ${error.message}`));
+    }
+  }
   {
     const configPath = path.join(paradigmDir, "config.yaml");
     if (options.workspace && fs.existsSync(configPath)) {
@@ -256,7 +266,7 @@ workspace: "${relPath}"
         if (configForWs.workspace) {
           spinner.start("Step 3b/6: Reindexing workspace members...");
           try {
-            const { workspaceReindexCommand } = await import("./workspace-L27RR5MF.js");
+            const { workspaceReindexCommand } = await import("./workspace-5RBSALXC.js");
             await workspaceReindexCommand({ quiet: true });
             spinner.succeed(chalk.green("Workspace members reindexed"));
           } catch (e) {

package/dist/{snapshot-XHINQBZS.js → snapshot-QZFD7YBI.js}

@@ -3,8 +3,8 @@ import {
   createSnapshot,
   parsePremiseFile,
   serializePremiseFile
-} from "./chunk-6P4IFIK2.js";
-import "./chunk-MRENOFTR.js";
+} from "./chunk-CTF6RHKG.js";
+import "./chunk-VUSCJJ4A.js";
 import "./chunk-IRKUEJVW.js";
 import "./chunk-ZXMDA7VB.js";
 

package/dist/{summary-NV7SBV5O.js → summary-R4CSYNNP.js}

@@ -1,8 +1,8 @@
 #!/usr/bin/env node
 import {
   aggregateFromDirectory
-} from "./chunk-6P4IFIK2.js";
-import "./chunk-MRENOFTR.js";
+} from "./chunk-CTF6RHKG.js";
+import "./chunk-VUSCJJ4A.js";
 import "./chunk-IRKUEJVW.js";
 import {
   detectIDE,

package/dist/{team-YOGT2Q2X.js → team-VH3HYABB.js}

@@ -8,8 +8,8 @@ import {
   teamModelsCommand,
   teamResetCommand,
   teamStatusCommand
-} from "./chunk-N6RNYCZD.js";
-import "./chunk-ZOH24ZPF.js";
+} from "./chunk-UQNTJ5VB.js";
+import "./chunk-3BGSDKWD.js";
 import "./chunk-6QC3YGB6.js";
 import "./chunk-J26YQVAK.js";
 import "./chunk-PBHIFAL4.js";
@@ -17,8 +17,8 @@ import "./chunk-5SXMV4SP.js";
 import "./chunk-PMXRGPRQ.js";
 import "./chunk-MW5DMGBB.js";
 import "./chunk-5JGJACDU.js";
-import "./chunk-6P4IFIK2.js";
-import "./chunk-MRENOFTR.js";
+import "./chunk-CTF6RHKG.js";
+import "./chunk-VUSCJJ4A.js";
 import "./chunk-IRKUEJVW.js";
 import "./chunk-ZXMDA7VB.js";
 export {

package/dist/university-content/courses/para-101.json

@@ -557,6 +557,59 @@
           "explanation": "A common pitfall is trying to document everything on day one. The recommended approach is to start with the most critical module, create one .purpose file, and expand incrementally as the project grows."
         }
       ]
+    },
+    {
+      "id": "component-types",
+      "title": "Component Types & Hierarchy",
+      "content": "## Why Component Types?\n\nComponents (`#`) are the most common symbol in any Paradigm project. A large project might have hundreds of components — services, views, utilities, routers, filters, models, and more. Without further classification, an AI agent triaging 'where is access control handled?' has to read every component to understand what kind of thing it is.\n\nComponent types solve this by adding an optional `type` field that describes a component's **structural role** — what the code IS, not what domain it belongs to.\n\n## The `type` Field\n\nAdd `type` to any component in a `.purpose` file:\n\n```yaml\ncomponents:\n  PaymentService:\n    description: Coordinates payment processing\n    type: service\n  PaymentForm:\n    description: Credit card input form\n    type: view\n  format-currency:\n    description: Formats numbers as currency strings\n    type: utility\n```\n\nTypes are **open strings** — each project defines its own vocabulary in the `component_types` glossary in `.paradigm/config.yaml`. There is no fixed enum. Common types include: `view`, `service`, `model`, `tool`, `utility`, `engine`, `loader`, `provider`, `manager`, `router`, `filter`, `handler`, `config`.\n\n## The `parent` Field\n\nComponents can declare a parent to establish hierarchy:\n\n```yaml\ncomponents:\n  InputOrchestrator:\n    description: Coordinates all input sources\n    type: manager\n  GazeRouter:\n    description: Maps gaze coordinates to dispatch targets\n    type: router\n    parent: \"#InputOrchestrator\"\n  KalmanFilter2D:\n    description: Smooths noisy gaze signal\n    type: filter\n    parent: \"#GazeRouter\"\n```\n\nParent is declared on the **child**, not maintained as a roster on the parent. This keeps `.purpose` files decentralized.\n\n## Type vs Tag\n\nThis is a common source of confusion:\n\n- **`type`** = structural role (what the code IS). One per component. Examples: `service`, `view`, `router`\n- **`tags`** = behavioral or domain classification. Many per component. Examples: `[feature]`, `[security]`, `[integration]`\n\nA component can be `type: service` with `tags: [feature, security]`. Type tells you the architecture; tags tell you the domain.\n\n## Config Glossary\n\nProjects define their vocabulary in `.paradigm/config.yaml`:\n\n```yaml\ncomponent_types:\n  service: \"Business logic coordinator — orchestrates tools, loaders, writers\"\n  view: \"UI rendering unit — SwiftUI view, React component\"\n  utility: \"Shared helper function or module — no side effects, pure logic\"\n  router: \"Maps input signals to targets based on rules\"\n```\n\nThe glossary is **descriptive only** — it helps agents understand types but does not enforce them.\n\n## MCP Integration\n\nComponent types integrate with MCP tools:\n\n- `paradigm_search` with `componentType: \"service\"` finds all services\n- `paradigm_status` shows a component type breakdown\n- `paradigm_purpose_add_component` accepts `type` and `parent` parameters\n- `paradigm_reindex` aggregates type counts into `$meta.componentTypes`",
+      "keyConcepts": [
+        "Component type describes structural role (what the code IS)",
+        "Types are open strings defined per project vocabulary",
+        "Parent field establishes hierarchy (declared on child)",
+        "Type vs tag: type = architecture, tags = domain/behavior",
+        "Config glossary describes types but does not enforce them"
+      ],
+      "quiz": [
+        {
+          "id": "q1",
+          "question": "What does the `type` field on a component describe?",
+          "choices": {
+            "A": "The programming language the component is written in",
+            "B": "The structural role of the component (e.g., service, view, router)",
+            "C": "The business domain the component belongs to",
+            "D": "The test coverage level of the component",
+            "E": "The deployment environment for the component"
+          },
+          "correct": "B",
+          "explanation": "The `type` field describes a component's structural role — what the code IS architecturally (service, view, router, filter, etc.). Business domain classification uses tags instead."
+        },
+        {
+          "id": "q2",
+          "question": "Where should the `parent` relationship be declared?",
+          "choices": {
+            "A": "On the parent component, listing all children",
+            "B": "In a separate relationships.yaml file",
+            "C": "On the child component, referencing the parent with a # symbol",
+            "D": "In portal.yaml alongside gate definitions",
+            "E": "In the config.yaml component_types glossary"
+          },
+          "correct": "C",
+          "explanation": "Parent is declared on the child component using a `parent: \"#parent-name\"` field. This keeps .purpose files decentralized — you don't need to maintain rosters on parent components."
+        },
+        {
+          "id": "q3",
+          "question": "A `PaymentService` handles payment processing and integrates with Stripe. How should it be documented?",
+          "choices": {
+            "A": "`type: integration` with no tags",
+            "B": "`type: service` with `tags: [integration, feature]`",
+            "C": "`tags: [service, integration]` with no type",
+            "D": "`type: feature` with `tags: [service]`",
+            "E": "`type: service-integration` combining both concepts"
+          },
+          "correct": "B",
+          "explanation": "Type describes what the code IS (a service), while tags describe behavior and domain (it's an integration and a feature). The correct approach is `type: service` with `tags: [integration, feature]`."
+        }
+      ]
     }
   ]
 }

package/dist/university-content/plsat/v3.0.json

@@ -2,7 +2,7 @@
   "version": "3.0",
   "frameworkVersion": "2.0",
   "timeLimit": 5400,
-  "totalSlots": 99,
+  "totalSlots": 102,
   "passThreshold": 0.8,
   "title": "The PLSAT \u2014 Paradigm Licensure Standardized Assessment Test",
   "description": "99 questions. 90 minutes. 80% to pass. Good luck, scholar.",
@@ -2489,6 +2489,83 @@
           "explanation": "Stack presets include scan hints — framework-specific patterns that tell the auto-scanner where to look and what patterns to match. The django preset knows that views.py files contain route handlers, models.py files contain data models, and urls.py files define URL routing. This is why stack presets solve the cold-start problem: they bring framework knowledge that makes auto-scanning productive for existing projects."
         }
       ]
+    },
+    {
+      "type": "standalone",
+      "slot": "slot-100",
+      "course": "para-101",
+      "variants": [
+        {
+          "id": "plsat-100",
+          "scenario": "Your project has a `#PaymentService` that coordinates payment processing and integrates with Stripe. A new developer asks whether they should use `type: integration` or `tags: [integration]` to capture the Stripe relationship.",
+          "question": "What is the correct approach?",
+          "choices": {
+            "A": "`type: integration` — because the Stripe integration is the most important thing about this component",
+            "B": "`type: service` with `tags: [integration]` — type describes structural role, tags describe domain/behavior",
+            "C": "Both `type: integration` and `tags: [integration]` — redundancy is good for search",
+            "D": "Neither — integration is a v1 concept replaced by `&` prefix in v2",
+            "E": "`type: stripe` — use the specific integration name as the type"
+          },
+          "correct": "B",
+          "explanation": "The `type` field describes a component's structural role — what the code IS architecturally. PaymentService is a service, so `type: service`. The Stripe integration is a behavioral/domain concern, captured with `tags: [integration]`. Type and tags serve different classification axes: type = architecture, tags = domain."
+        },
+        {
+          "id": "plsat-100b",
+          "scenario": "A developer adds a new `#EmailValidator` utility and sets `type: validator` in the .purpose file. Another developer points out that `validator` is not in the project's `component_types` glossary in config.yaml.",
+          "question": "Is `type: validator` valid?",
+          "choices": {
+            "A": "No — types must exactly match the glossary entries or they are rejected",
+            "B": "Yes — types are open strings and the glossary is descriptive only, not enforced",
+            "C": "No — you must add it to the glossary first before using it",
+            "D": "Yes — but only if the developer also adds a `~validator` aspect",
+            "E": "It depends on the `strict-types` setting in config.yaml"
+          },
+          "correct": "B",
+          "explanation": "Component types are open strings — any project can invent its own vocabulary. The glossary in config.yaml is descriptive only (it helps agents understand types) but does not enforce or block unknown types. The developer can use `type: validator` freely."
+        }
+      ]
+    },
+    {
+      "type": "standalone",
+      "slot": "slot-101",
+      "course": "para-101",
+      "variants": [
+        {
+          "id": "plsat-101",
+          "scenario": "You have a `#GazeRouter` component that maps gaze coordinates to dispatch targets. It is managed by `#InputOrchestrator`. You want to express this hierarchy in the .purpose file.",
+          "question": "How should the parent relationship be declared?",
+          "choices": {
+            "A": "On `#InputOrchestrator` with `children: [\"#GazeRouter\"]`",
+            "B": "On `#GazeRouter` with `parent: \"#InputOrchestrator\"`",
+            "C": "In a separate `relationships` section at the top of the .purpose file",
+            "D": "In portal.yaml alongside route gates",
+            "E": "Using `tags: [child-of-InputOrchestrator]` on GazeRouter"
+          },
+          "correct": "B",
+          "explanation": "Parent relationships are declared on the child component using the `parent` field with a `#` symbol reference. This keeps .purpose files decentralized — you don't need to maintain a children roster on the parent. The parent field is computed upward, not maintained downward."
+        }
+      ]
+    },
+    {
+      "type": "standalone",
+      "slot": "slot-102",
+      "course": "para-101",
+      "variants": [
+        {
+          "id": "plsat-102",
+          "scenario": "An AI agent needs to find all router components in a project to understand the dispatch architecture. The project uses component types consistently.",
+          "question": "What is the most efficient MCP tool call?",
+          "choices": {
+            "A": "`paradigm_search` with `query: \"router\"` — search by name",
+            "B": "`paradigm_search` with `query: \"*\"` and `componentType: \"router\"` — filter by type",
+            "C": "`paradigm_navigate` with `intent: \"find\"` and `target: \"router\"` — navigate to routers",
+            "D": "`paradigm_ripple` with `symbol: \"#router\"` — check router dependencies",
+            "E": "Read every .purpose file and grep for `type: router`"
+          },
+          "correct": "B",
+          "explanation": "The `paradigm_search` tool accepts a `componentType` filter that directly queries the symbol index for components of a specific type. This is the most efficient approach — it uses the index instead of reading files, and returns exactly the components with `type: router`."
+        }
+      ]
     }
   ]
 }

package/dist/{upgrade-65QOQXRC.js → upgrade-ANX3LVSA.js}

@@ -35,6 +35,7 @@ async function upgradeCommand(targetPath, options) {
   const rootDir = targetPath ? path.resolve(targetPath) : process.cwd();
   const projectName = path.basename(rootDir);
   const spinner = ora();
+  console.log(chalk.yellow("\n  `paradigm upgrade` is deprecated. Use `paradigm migrate` instead.\n"));
   console.log(chalk.blue("\n\u{1F504} Paradigm Upgrade\n"));
   if (options.fromHorizon) {
     const result = await migrateFromHorizon(rootDir, projectName, options, spinner);

package/dist/{validate-TKKRGJKC.js → validate-OUHUBZPO.js}

@@ -3,7 +3,7 @@ import {
   formatValidationResult,
   getAllPurposeFiles,
   validatePurposeFile
-} from "./chunk-MRENOFTR.js";
+} from "./chunk-VUSCJJ4A.js";
 import "./chunk-ZXMDA7VB.js";
 
 // src/commands/purpose/validate.ts

package/dist/{workspace-L27RR5MF.js → workspace-5RBSALXC.js}

@@ -4,11 +4,11 @@ import {
   workspaceInitCommand,
   workspaceReindexCommand,
   workspaceStatusCommand
-} from "./chunk-OXG5GVDJ.js";
-import "./chunk-W4VFKZVF.js";
-import "./chunk-AK5M6KJB.js";
-import "./chunk-6P4IFIK2.js";
-import "./chunk-MRENOFTR.js";
+} from "./chunk-WOONGZ3C.js";
+import "./chunk-S5TDFT5Q.js";
+import "./chunk-36TKPM5Z.js";
+import "./chunk-CTF6RHKG.js";
+import "./chunk-VUSCJJ4A.js";
 import "./chunk-IRKUEJVW.js";
 import "./chunk-Z7W7HNRG.js";
 import "./chunk-4NCFWYGG.js";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@a-company/paradigm",
-  "version": "3.28.0",
+  "version": "3.34.0",
   "description": "Unified CLI for Paradigm developer tools",
   "type": "module",
   "main": "./dist/index.js",