@a-company/paradigm 5.35.1 → 5.37.1

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

@@ -6,12 +6,12 @@
     {
       "id": "flows-deep-dive",
       "title": "Flows in Depth",
-      "content": "## When to Create a Flow\n\nNot every process needs a `$flow`. The rule of thumb is: **create a flow when logic spans three or more components in a specific order**. A two-component interaction (service A calls service B) is simple enough to document in the component's `.purpose` entry. But once a third component enters the picture — and the order matters — a flow captures the choreography that no single component can describe.\n\nConsider these scenarios:\n- User clicks \"Buy\" → cart validates → payment charges → order creates → email sends. That is four components in sequence. This needs a `$checkout-flow`.\n- A cron job triggers → data fetches → report generates → file uploads → Slack notifies. Five components. This needs a `$daily-report-flow`.\n- A controller calls a service which returns data. Two components, no sequence ambiguity. This does NOT need a flow.\n\n## Flow Step Structure\n\nEach step in a flow is a `component + action` pair. The component references a `#component` defined in a `.purpose` file, and the action describes what that component does in this step:\n\n```yaml\nflows:\n  $onboarding:\n    description: New user setup from registration to first project\n    steps:\n      - component: \"#auth-handler\"\n        action: create-account\n        description: Validates email, hashes password, creates user record\n      - component: \"#email-service\"\n        action: send-welcome\n        description: Sends welcome email with verification link\n      - component: \"#project-service\"\n        action: create-default-project\n        description: Creates a starter project for the new user\n      - component: \"#notification-service\"\n        action: notify-team\n        description: Alerts the team Slack channel about the new signup\n    signals: [\"!user-created\", \"!welcome-email-sent\"]\n    gates: []\n```\n\nThe `description` on each step is optional but valuable — it tells AI agents what happens at each point without reading the source code.\n\n## Documenting Flows in .purpose Files\n\nFlows are defined in the `flows` section of a `.purpose` file, usually in the directory of the *initiating* component. If the checkout flow starts in the cart module, define `$checkout-flow` in `src/cart/.purpose`. The flow references components from other directories — that is expected and correct.\n\nYou can also reference flows from component definitions:\n\n```yaml\ncomponents:\n  #cart-service:\n    description: Shopping cart management\n    flows: [\"$checkout-flow\", \"$cart-abandonment-flow\"]\n```\n\nThis bidirectional referencing lets `paradigm_ripple` calculate the full impact when you modify a component — it knows which flows pass through it.\n\n## Flow Validation\n\nParadigm provides `paradigm_flow_validate` to check that your flow definitions are consistent:\n\n```\nparadigm_flow_validate({ flowId: \"$checkout-flow\", checkImplementation: true })\n```\n\nWith `checkImplementation: true`, the validator goes beyond schema checks — it verifies that the referenced components exist in `.purpose` files, that the actions are implemented in the codebase, and that any signals listed are actually emitted. This catches drift between documentation and code.\n\nYou can also validate all flows at once by omitting the `flowId` parameter. This is useful as a pre-commit check or CI step.\n\n## Circular Dependency Detection\n\nWhen flows reference each other via `relatedFlows` or step-level `$flow` symbols, they form a dependency graph. Paradigm automatically detects circular dependencies in this graph using depth-first search.\n\nA circular dependency looks like this:\n\n```yaml\n$checkout-flow:\n  relatedFlows: [$payment-flow]\n$payment-flow:\n  relatedFlows: [$checkout-flow]  # Creates a cycle!\n```\n\nWhen you run `paradigm_flow_validate({})` (validate all flows), the output includes a `circularDependencies` section:\n\n```\n⚠ Circular Dependencies (1)\n\n  $checkout-flow → $payment-flow → $checkout-flow\n\n  Resolution: Break the cycle by extracting shared logic into a\n  separate flow, or remove one direction of the dependency.\n```\n\nTo resolve circular dependencies:\n1. **Extract shared logic** into a new flow that both original flows reference\n2. **Remove one direction** if only one flow truly depends on the other\n3. **Replace with signals** — use `!signal` communication instead of direct flow references\n\nCircular dependencies are not just a documentation problem — they indicate architectural coupling that can lead to cascading failures and maintenance difficulty.\n\n## Flows Are Documentation, Not Orchestration\n\nA critical distinction: flows describe *what happens*, not *how to make it happen*. They are not workflow engines or saga orchestrators. Your code still calls services, handles errors, and manages state however it needs to. The flow definition is metadata that helps humans and AI agents understand the sequence — it does not replace your implementation.",
+      "content": "## When to Create a Flow\n\nNot every process needs a `$flow`. The rule of thumb is: **create a flow when logic spans three or more components in a specific order**. A two-component interaction (service A calls service B) is simple enough to document in the component's `.purpose` entry. But once a third component enters the picture — and the order matters — a flow captures the choreography that no single component can describe.\n\nConsider these scenarios:\n- User clicks \"Buy\" → cart validates → payment charges → order creates → email sends. That is four components in sequence. This needs a `$checkout-flow`.\n- A cron job triggers → data fetches → report generates → file uploads → Slack notifies. Five components. This needs a `$daily-report-flow`.\n- A controller calls a service which returns data. Two components, no sequence ambiguity. This does NOT need a flow.\n\n## Flow Step Structure\n\nEach step in a flow is a `component + action` pair. The component references a `#component` defined in a `.purpose` file, and the action describes what that component does in this step:\n\n```yaml\nflows:\n  $onboarding:\n    description: New user setup from registration to first project\n    steps:\n      - component: \"#auth-handler\"\n        action: create-account\n        description: Validates email, hashes password, creates user record\n      - component: \"#email-service\"\n        action: send-welcome\n        description: Sends welcome email with verification link\n      - component: \"#project-service\"\n        action: create-default-project\n        description: Creates a starter project for the new user\n      - component: \"#notification-service\"\n        action: notify-team\n        description: Alerts the team Slack channel about the new signup\n    signals: [\"!user-created\", \"!welcome-email-sent\"]\n    gates: []\n```\n\nThe `description` on each step is optional but valuable — it tells AI agents what happens at each point without reading the source code.\n\n## Documenting Flows in .purpose Files\n\nFlows are defined in the `flows` section of a `.purpose` file, usually in the directory of the *initiating* component. If the checkout flow starts in the cart module, define `$checkout-flow` in `src/cart/.purpose`. The flow references components from other directories — that is expected and correct.\n\nYou can also reference flows from component definitions:\n\n```yaml\ncomponents:\n  #cart-service:\n    description: Shopping cart management\n    flows: [\"$checkout-flow\", \"$cart-abandonment-flow\"]\n```\n\nThis bidirectional referencing lets `paradigm_ripple` calculate the full impact when you modify a component — it knows which flows pass through it.\n\n## Flow Validation\n\nParadigm provides `paradigm_flow_check` to check that your flow definitions are consistent:\n\n```\nparadigm_flow_check({ flowId: \"$checkout-flow\", checkImplementation: true })\n```\n\nWith `checkImplementation: true`, the validator goes beyond schema checks — it verifies that the referenced components exist in `.purpose` files, that the actions are implemented in the codebase, and that any signals listed are actually emitted. This catches drift between documentation and code.\n\nYou can also validate all flows at once by omitting the `flowId` parameter. This is useful as a pre-commit check or CI step.\n\n## Circular Dependency Detection\n\nWhen flows reference each other via `relatedFlows` or step-level `$flow` symbols, they form a dependency graph. Paradigm automatically detects circular dependencies in this graph using depth-first search.\n\nA circular dependency looks like this:\n\n```yaml\n$checkout-flow:\n  relatedFlows: [$payment-flow]\n$payment-flow:\n  relatedFlows: [$checkout-flow]  # Creates a cycle!\n```\n\nWhen you run `paradigm_flow_check({})` (validate all flows), the output includes a `circularDependencies` section:\n\n```\n⚠ Circular Dependencies (1)\n\n  $checkout-flow → $payment-flow → $checkout-flow\n\n  Resolution: Break the cycle by extracting shared logic into a\n  separate flow, or remove one direction of the dependency.\n```\n\nTo resolve circular dependencies:\n1. **Extract shared logic** into a new flow that both original flows reference\n2. **Remove one direction** if only one flow truly depends on the other\n3. **Replace with signals** — use `!signal` communication instead of direct flow references\n\nCircular dependencies are not just a documentation problem — they indicate architectural coupling that can lead to cascading failures and maintenance difficulty.\n\n## Flows Are Documentation, Not Orchestration\n\nA critical distinction: flows describe *what happens*, not *how to make it happen*. They are not workflow engines or saga orchestrators. Your code still calls services, handles errors, and manages state however it needs to. The flow definition is metadata that helps humans and AI agents understand the sequence — it does not replace your implementation.",
       "keyConcepts": [
         "Create flows when 3+ components are involved in sequence",
         "Steps are component + action pairs",
         "Define flows in the .purpose file of the initiating component",
-        "paradigm_flow_validate checks consistency with codebase",
+        "paradigm_flow_check checks consistency with codebase",
         "Circular dependency detection catches cycles in flow relatedFlows references",
         "Flows are documentation, not orchestration code",
         "'paradigm flow diagram $flowId' generates Mermaid flowcharts — gates as diamonds, actions as rectangles, signals as rounded boxes"
@@ -45,7 +45,7 @@
         },
         {
           "id": "q3",
-          "question": "What does `paradigm_flow_validate` with `checkImplementation: true` verify?",
+          "question": "What does `paradigm_flow_check` with `checkImplementation: true` verify?",
           "choices": {
             "A": "That the flow executes correctly at runtime",
             "B": "That referenced components exist in .purpose files, actions are implemented, and signals are emitted",
@@ -71,7 +71,7 @@
         },
         {
           "id": "q5",
-          "question": "`$checkout-flow` lists `relatedFlows: [$payment-flow]` and `$payment-flow` lists `relatedFlows: [$checkout-flow]`. What does `paradigm_flow_validate` report?",
+          "question": "`$checkout-flow` lists `relatedFlows: [$payment-flow]` and `$payment-flow` lists `relatedFlows: [$checkout-flow]`. What does `paradigm_flow_check` report?",
           "choices": {
             "A": "No issues — bidirectional references are valid",
             "B": "A circular dependency: $checkout-flow → $payment-flow → $checkout-flow",
@@ -714,7 +714,7 @@
     {
       "id": "architecture-review",
       "title": "Putting It All Together",
-      "content": "## Building a Complete Feature\n\nYou have learned flows, gates, aspects, disciplines, naming conventions, component patterns, signal patterns, and cross-cutting concerns. Now let us walk through building a complete feature from scratch, using every tool in the Paradigm toolkit. The feature: **a team invitation system** where team admins can invite new members via email.\n\n## Step 1: Identify Components\n\nStart by listing the code units you will need:\n\n```yaml\n#invitation-service:\n  description: Creates and manages team invitations\n  tags: [feature, teams]\n\n#invitation-email:\n  description: Sends invitation emails via SendGrid\n  tags: [integration, sendgrid, email]\n\n#invitation-token:\n  description: Generates and validates secure invitation tokens\n  tags: [infrastructure, security]\n\n#invitation-store:\n  description: Persists invitations with status tracking\n  tags: [state, teams]\n```\n\nFour components — one feature, one integration, one infrastructure, one state. Each has a clear responsibility and appropriate tags.\n\n## Step 2: Define the Flow\n\nThe invitation process spans all four components in sequence:\n\n```yaml\n$team-invitation-flow:\n  description: Admin invites a user, email is sent, user accepts and joins team\n  steps:\n    - component: \"#invitation-service\"\n      action: create-invitation\n      description: Validates admin permissions and creates invitation record\n    - component: \"#invitation-token\"\n      action: generate-token\n      description: Creates a cryptographically secure token with 7-day expiry\n    - component: \"#invitation-store\"\n      action: persist-invitation\n      description: Saves invitation with pending status\n    - component: \"#invitation-email\"\n      action: send-invite\n      description: Sends email with accept link containing the token\n  signals: [\"!invitation-sent\", \"!invitation-accepted\"]\n  gates: [\"^authenticated\", \"^team-admin\"]\n```\n\n## Step 3: Add Gates\n\nTwo gates are needed. First, check `portal.yaml` for existing gates. `^authenticated` likely exists. `^team-admin` may need to be created:\n\n```yaml\n# In portal.yaml\ngates:\n  ^team-admin:\n    description: User must be an admin of the specified team\n    check: team.admins.includes(req.user.id)\n    type: role\n    requires: [^authenticated]\n    effects: []\n\nroutes:\n  \"POST /api/teams/:id/invitations\": [^authenticated, ^team-admin]\n  \"POST /api/invitations/:token/accept\": [^authenticated]\n  \"GET /api/teams/:id/invitations\": [^authenticated, ^team-admin]\n  \"DELETE /api/invitations/:id\": [^authenticated, ^team-admin]\n```\n\nNotice that accepting an invitation only requires `^authenticated` — any logged-in user with a valid token can accept. But creating, listing, and deleting invitations requires `^team-admin`.\n\n## Step 4: Define Signals\n\n```yaml\n!invitation-sent:\n  description: An invitation email was successfully sent to a prospective team member\n  emitters: [\"#invitation-service\"]\n  category: business\n  data:\n    invitationId: string\n    teamId: string\n    email: string\n\n!invitation-accepted:\n  description: A user accepted a team invitation and joined the team\n  emitters: [\"#invitation-service\"]\n  category: business\n  data:\n    invitationId: string\n    teamId: string\n    userId: string\n```\n\nThese business signals enable decoupled side effects — an analytics tracker can listen for `!invitation-accepted` to track conversion rates, and a notification service can alert existing team members.\n\n## Step 5: Apply Aspects\n\nCheck which aspects apply to the new components:\n\n- `~audit-required` applies to `#*Service` → `#invitation-service` is covered. Ensure the audit middleware is applied.\n- `~rate-limited` applies to `#*-handler` → Not directly applicable here (no handler component), but the API route should go through the rate limiter.\n- `~validated` applies to `#*-handler` → The invitation endpoint should validate input (email format, team existence).\n\n## Step 6: Write the .purpose File\n\nAssemble everything into `src/invitations/.purpose`:\n\n```yaml\nname: Team Invitations\ndescription: Team admin invitation system with email delivery and token-based acceptance\ncontext:\n  - Invitation tokens expire after 7 days\n  - Maximum 50 pending invitations per team\n  - Uses SendGrid for email delivery\n\ncomponents:\n  #invitation-service:\n    description: Creates and manages team invitations\n    file: invitation-service.ts\n    tags: [feature, teams]\n    flows: [\"$team-invitation-flow\"]\n    signals: [\"!invitation-sent\", \"!invitation-accepted\"]\n    gates: [\"^authenticated\", \"^team-admin\"]\n    aspects: [\"~audit-required\"]\n  # ... (remaining components)\n\nflows:\n  $team-invitation-flow:\n    # ... (as defined above)\n\nsignals:\n  !invitation-sent:\n    # ... (as defined above)\n  !invitation-accepted:\n    # ... (as defined above)\n```\n\n## Step 7: Validate\n\nBefore writing any implementation code, validate the Paradigm definitions:\n\n1. `paradigm_purpose_validate` — Checks the .purpose file for schema errors.\n2. `paradigm_flow_validate` — Verifies the flow references valid components.\n3. `paradigm_aspect_check` — Confirms aspect anchors are valid for applied aspects.\n4. `paradigm_ripple` — Shows what existing code is affected by the new components.\n\n## The Pattern\n\nEvery feature follows this pattern: **identify components** → **define flows** → **add gates** → **define signals** → **apply aspects** → **write .purpose** → **validate** → **implement**. The implementation comes last — after the architecture is documented and validated. This front-loaded documentation pays dividends: AI agents can navigate the new feature immediately, security is defined before code, and the team has a clear map of what will be built.",
+      "content": "## Building a Complete Feature\n\nYou have learned flows, gates, aspects, disciplines, naming conventions, component patterns, signal patterns, and cross-cutting concerns. Now let us walk through building a complete feature from scratch, using every tool in the Paradigm toolkit. The feature: **a team invitation system** where team admins can invite new members via email.\n\n## Step 1: Identify Components\n\nStart by listing the code units you will need:\n\n```yaml\n#invitation-service:\n  description: Creates and manages team invitations\n  tags: [feature, teams]\n\n#invitation-email:\n  description: Sends invitation emails via SendGrid\n  tags: [integration, sendgrid, email]\n\n#invitation-token:\n  description: Generates and validates secure invitation tokens\n  tags: [infrastructure, security]\n\n#invitation-store:\n  description: Persists invitations with status tracking\n  tags: [state, teams]\n```\n\nFour components — one feature, one integration, one infrastructure, one state. Each has a clear responsibility and appropriate tags.\n\n## Step 2: Define the Flow\n\nThe invitation process spans all four components in sequence:\n\n```yaml\n$team-invitation-flow:\n  description: Admin invites a user, email is sent, user accepts and joins team\n  steps:\n    - component: \"#invitation-service\"\n      action: create-invitation\n      description: Validates admin permissions and creates invitation record\n    - component: \"#invitation-token\"\n      action: generate-token\n      description: Creates a cryptographically secure token with 7-day expiry\n    - component: \"#invitation-store\"\n      action: persist-invitation\n      description: Saves invitation with pending status\n    - component: \"#invitation-email\"\n      action: send-invite\n      description: Sends email with accept link containing the token\n  signals: [\"!invitation-sent\", \"!invitation-accepted\"]\n  gates: [\"^authenticated\", \"^team-admin\"]\n```\n\n## Step 3: Add Gates\n\nTwo gates are needed. First, check `portal.yaml` for existing gates. `^authenticated` likely exists. `^team-admin` may need to be created:\n\n```yaml\n# In portal.yaml\ngates:\n  ^team-admin:\n    description: User must be an admin of the specified team\n    check: team.admins.includes(req.user.id)\n    type: role\n    requires: [^authenticated]\n    effects: []\n\nroutes:\n  \"POST /api/teams/:id/invitations\": [^authenticated, ^team-admin]\n  \"POST /api/invitations/:token/accept\": [^authenticated]\n  \"GET /api/teams/:id/invitations\": [^authenticated, ^team-admin]\n  \"DELETE /api/invitations/:id\": [^authenticated, ^team-admin]\n```\n\nNotice that accepting an invitation only requires `^authenticated` — any logged-in user with a valid token can accept. But creating, listing, and deleting invitations requires `^team-admin`.\n\n## Step 4: Define Signals\n\n```yaml\n!invitation-sent:\n  description: An invitation email was successfully sent to a prospective team member\n  emitters: [\"#invitation-service\"]\n  category: business\n  data:\n    invitationId: string\n    teamId: string\n    email: string\n\n!invitation-accepted:\n  description: A user accepted a team invitation and joined the team\n  emitters: [\"#invitation-service\"]\n  category: business\n  data:\n    invitationId: string\n    teamId: string\n    userId: string\n```\n\nThese business signals enable decoupled side effects — an analytics tracker can listen for `!invitation-accepted` to track conversion rates, and a notification service can alert existing team members.\n\n## Step 5: Apply Aspects\n\nCheck which aspects apply to the new components:\n\n- `~audit-required` applies to `#*Service` → `#invitation-service` is covered. Ensure the audit middleware is applied.\n- `~rate-limited` applies to `#*-handler` → Not directly applicable here (no handler component), but the API route should go through the rate limiter.\n- `~validated` applies to `#*-handler` → The invitation endpoint should validate input (email format, team existence).\n\n## Step 6: Write the .purpose File\n\nAssemble everything into `src/invitations/.purpose`:\n\n```yaml\nname: Team Invitations\ndescription: Team admin invitation system with email delivery and token-based acceptance\ncontext:\n  - Invitation tokens expire after 7 days\n  - Maximum 50 pending invitations per team\n  - Uses SendGrid for email delivery\n\ncomponents:\n  #invitation-service:\n    description: Creates and manages team invitations\n    file: invitation-service.ts\n    tags: [feature, teams]\n    flows: [\"$team-invitation-flow\"]\n    signals: [\"!invitation-sent\", \"!invitation-accepted\"]\n    gates: [\"^authenticated\", \"^team-admin\"]\n    aspects: [\"~audit-required\"]\n  # ... (remaining components)\n\nflows:\n  $team-invitation-flow:\n    # ... (as defined above)\n\nsignals:\n  !invitation-sent:\n    # ... (as defined above)\n  !invitation-accepted:\n    # ... (as defined above)\n```\n\n## Step 7: Validate\n\nBefore writing any implementation code, validate the Paradigm definitions:\n\n1. `paradigm_purpose_validate` — Checks the .purpose file for schema errors.\n2. `paradigm_flow_check` — Verifies the flow references valid components.\n3. `paradigm_aspect_check` — Confirms aspect anchors are valid for applied aspects.\n4. `paradigm_ripple` — Shows what existing code is affected by the new components.\n\n## The Pattern\n\nEvery feature follows this pattern: **identify components** → **define flows** → **add gates** → **define signals** → **apply aspects** → **write .purpose** → **validate** → **implement**. The implementation comes last — after the architecture is documented and validated. This front-loaded documentation pays dividends: AI agents can navigate the new feature immediately, security is defined before code, and the team has a clear map of what will be built.",
       "keyConcepts": [
         "Feature building follows: components → flows → gates → signals → aspects → .purpose → validate → implement",
         "Implementation comes LAST, after architecture is documented",

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

@@ -257,11 +257,11 @@
     {
       "id": "doctor-and-validation",
       "title": "Doctor & Validation",
-      "content": "## Doctor & Validation\n\nAs a Paradigm project evolves, its metadata can drift out of sync with the actual code. A component gets renamed but its `.purpose` file still references the old name. A gate is added to `portal.yaml` but never implemented. An aspect loses its code anchor when someone refactors the file it pointed to. Paradigm's validation tools catch these inconsistencies before they cause confusion.\n\nThe `paradigm doctor` CLI command runs a comprehensive health check across your entire project. It validates several categories of issues:\n\n- **Purpose file integrity**: Are all `.purpose` files valid YAML? Do all symbol references use correct prefixes?\n- **Portal.yaml consistency**: Do routes reference gates that are actually defined? Are there gates defined but never used?\n- **Aspect anchor verification**: Do all `~aspect` symbols have anchors? Do those anchors point to files and lines that still exist?\n- **Orphaned symbol detection**: Are there symbols defined in `.purpose` files that are never referenced anywhere else?\n- **Cross-reference validation**: When `#checkout-form` says it uses `$checkout-flow`, does that flow actually exist?\n\n```bash\n$ paradigm doctor\n\nChecking .purpose files...\n  src/features/checkout/.purpose - OK\n  src/features/auth/.purpose - WARNING: #legacy-login referenced but not defined\n  src/services/.purpose - OK\n\nChecking portal.yaml...\n  ^authenticated - OK (used in 12 routes)\n  ^project-admin - WARNING: defined but used in 0 routes\n\nChecking aspects...\n  ~audit-required - ERROR: anchor src/middleware/audit.ts:15-35 not found\n  ~rate-limited - OK\n\nResults: 2 warnings, 1 error\n```\n\nFor more targeted validation, the MCP tool `paradigm_purpose_validate` lets you check a specific `.purpose` file or validate all files. You can also include portal.yaml validation with the `includePortal` parameter. This is useful after making changes to a specific area -- run validation on just the files you touched rather than the entire project.\n\nThe `paradigm_flow_validate` tool specifically validates flow definitions. It checks that gates referenced in flow steps exist in `portal.yaml`, that actions described in steps have corresponding implementations in the codebase (when `checkImplementation` is true), and that signals emitted during the flow are properly defined.\n\nA good rhythm is to run `paradigm doctor` after major changes (adding features, refactoring, renaming symbols) and before committing. Many teams integrate it into their pre-commit hooks or CI pipelines. Think of it as a linter for your Paradigm metadata -- catching problems early is always cheaper than debugging them later.\n\n### Clarification Markers\n\nWhen a requirement is ambiguous or incomplete in a `.purpose` file, use the `[NEEDS CLARIFICATION: ...]` marker format instead of guessing. For example:\n\n```yaml\ncomponents:\n  payment-processor:\n    description: \"Processes payments via Stripe [NEEDS CLARIFICATION: should this support PayPal fallback?]\"\n```\n\nClarification markers are reported as **warnings** (not errors) by both `paradigm doctor` and `paradigm_purpose_validate`. They do not block validation or break builds, but they surface during health checks to remind the team that a design question remains open. The exact format `[NEEDS CLARIFICATION: <question>]` is required -- the tooling scans for this specific prefix in all description fields across `.purpose` files. Resolve all markers before shipping by replacing them with the clarified text.",
+      "content": "## Doctor & Validation\n\nAs a Paradigm project evolves, its metadata can drift out of sync with the actual code. A component gets renamed but its `.purpose` file still references the old name. A gate is added to `portal.yaml` but never implemented. An aspect loses its code anchor when someone refactors the file it pointed to. Paradigm's validation tools catch these inconsistencies before they cause confusion.\n\nThe `paradigm doctor` CLI command runs a comprehensive health check across your entire project. It validates several categories of issues:\n\n- **Purpose file integrity**: Are all `.purpose` files valid YAML? Do all symbol references use correct prefixes?\n- **Portal.yaml consistency**: Do routes reference gates that are actually defined? Are there gates defined but never used?\n- **Aspect anchor verification**: Do all `~aspect` symbols have anchors? Do those anchors point to files and lines that still exist?\n- **Orphaned symbol detection**: Are there symbols defined in `.purpose` files that are never referenced anywhere else?\n- **Cross-reference validation**: When `#checkout-form` says it uses `$checkout-flow`, does that flow actually exist?\n\n```bash\n$ paradigm doctor\n\nChecking .purpose files...\n  src/features/checkout/.purpose - OK\n  src/features/auth/.purpose - WARNING: #legacy-login referenced but not defined\n  src/services/.purpose - OK\n\nChecking portal.yaml...\n  ^authenticated - OK (used in 12 routes)\n  ^project-admin - WARNING: defined but used in 0 routes\n\nChecking aspects...\n  ~audit-required - ERROR: anchor src/middleware/audit.ts:15-35 not found\n  ~rate-limited - OK\n\nResults: 2 warnings, 1 error\n```\n\nFor more targeted validation, the MCP tool `paradigm_purpose_validate` lets you check a specific `.purpose` file or validate all files. You can also include portal.yaml validation with the `includePortal` parameter. This is useful after making changes to a specific area -- run validation on just the files you touched rather than the entire project.\n\nThe `paradigm_flow_check` tool specifically validates flow definitions. It checks that gates referenced in flow steps exist in `portal.yaml`, that actions described in steps have corresponding implementations in the codebase (when `checkImplementation` is true), and that signals emitted during the flow are properly defined.\n\nA good rhythm is to run `paradigm doctor` after major changes (adding features, refactoring, renaming symbols) and before committing. Many teams integrate it into their pre-commit hooks or CI pipelines. Think of it as a linter for your Paradigm metadata -- catching problems early is always cheaper than debugging them later.\n\n### Clarification Markers\n\nWhen a requirement is ambiguous or incomplete in a `.purpose` file, use the `[NEEDS CLARIFICATION: ...]` marker format instead of guessing. For example:\n\n```yaml\ncomponents:\n  payment-processor:\n    description: \"Processes payments via Stripe [NEEDS CLARIFICATION: should this support PayPal fallback?]\"\n```\n\nClarification markers are reported as **warnings** (not errors) by both `paradigm doctor` and `paradigm_purpose_validate`. They do not block validation or break builds, but they surface during health checks to remind the team that a design question remains open. The exact format `[NEEDS CLARIFICATION: <question>]` is required -- the tooling scans for this specific prefix in all description fields across `.purpose` files. Resolve all markers before shipping by replacing them with the clarified text.",
       "keyConcepts": [
         "paradigm doctor CLI command",
         "paradigm_purpose_validate MCP tool",
-        "paradigm_flow_validate",
+        "paradigm_flow_check",
         "Aspect anchor verification",
         "Orphaned symbol detection"
       ],
@@ -307,7 +307,7 @@
         },
         {
           "id": "q4",
-          "question": "What does paradigm_flow_validate check when checkImplementation is set to true?",
+          "question": "What does paradigm_flow_check check when checkImplementation is set to true?",
           "choices": {
             "A": "Only YAML syntax of the flow definition",
             "B": "That flow steps reference existing gates, actions are implemented in code, and signals are defined",
@@ -316,7 +316,7 @@
             "E": "Only that gate names match portal.yaml"
           },
           "correct": "B",
-          "explanation": "With checkImplementation enabled, paradigm_flow_validate performs a deep check: verifying that gates exist in portal.yaml, that actions described in flow steps have corresponding implementations in the codebase, and that emitted signals are properly defined."
+          "explanation": "With checkImplementation enabled, paradigm_flow_check performs a deep check: verifying that gates exist in portal.yaml, that actions described in flow steps have corresponding implementations in the codebase, and that emitted signals are properly defined."
         },
         {
           "id": "q5",
@@ -617,9 +617,9 @@
     {
       "id": "context-management",
       "title": "Context Management",
-      "content": "## Context Management\n\nAI agents operate within a finite context window. Every file read, every tool call response, and every message in the conversation consumes tokens from that budget. When the context fills up, the agent loses the ability to recall earlier information, make coherent plans, or maintain awareness of all the changes it has made. Paradigm provides tools to monitor, manage, and gracefully handle context limits.\n\n**`paradigm_context_check`** monitors current context usage. Call it periodically during long sessions (every 10-15 tool calls is a good cadence) to get a recommendation. The response tells you whether to \"continue\" (plenty of room), \"be-cautious\" (usage is climbing), or \"handoff-soon\" (>85% consumed). You can optionally pass your estimated total tokens and context window size for more accurate assessment.\n\n```\nparadigm_context_check({\n  contextWindowSize: 200000,\n  estimatedTotalTokens: 150000\n})\n// Recommendation: \"handoff-soon\" -- context at ~75%, prepare handoff\n```\n\nWhen a handoff is needed, **`paradigm_handoff_prepare`** creates a structured summary of the current session. It captures what was done, which symbols were touched, which files were modified, what still needs to happen, and any open questions. This summary becomes the starting point for the next session.\n\n```\nparadigm_handoff_prepare({\n  summary: \"Implemented Apple Pay in checkout flow\",\n  symbolsTouched: [\"#payment-service\", \"$checkout-flow\", \"#apple-pay-button\"],\n  modifiedFiles: [\"src/services/payment.ts\", \"src/components/checkout/ApplePayButton.tsx\"],\n  nextSteps: [\"Add unit tests for Apple Pay handler\", \"Update portal.yaml with new gates\"],\n  openQuestions: [\"Should we support Apple Pay in the mobile app too?\"]\n})\n```\n\nOn the receiving end, **`paradigm_session_recover`** loads breadcrumbs from the previous session. A new agent session calls this at startup to understand what was done before, pick up where the last session left off, and avoid redoing work.\n\nFor cost awareness, **`paradigm_session_stats`** shows the current session's MCP interactions, estimated token usage, and cost breakdown. This is useful for understanding which operations are expensive and optimizing your workflow.\n\nThe context management workflow forms a cycle: **monitor** usage with context_check, **prepare** handoff when limits approach, **recover** in new sessions with session_recover, and **track** costs with session_stats. Mastering this cycle means you can handle tasks that are larger than any single context window by splitting them across multiple sessions without losing progress.",
+      "content": "## Context Management\n\nAI agents operate within a finite context window. Every file read, every tool call response, and every message in the conversation consumes tokens from that budget. When the context fills up, the agent loses the ability to recall earlier information, make coherent plans, or maintain awareness of all the changes it has made. Paradigm provides tools to monitor, manage, and gracefully handle context limits.\n\n**`paradigm_session_health`** monitors current context usage. Call it periodically during long sessions (every 10-15 tool calls is a good cadence) to get a recommendation. The response tells you whether to \"continue\" (plenty of room), \"be-cautious\" (usage is climbing), or \"handoff-soon\" (>85% consumed). You can optionally pass your estimated total tokens and context window size for more accurate assessment.\n\n```\nparadigm_session_health({\n  contextWindowSize: 200000,\n  estimatedTotalTokens: 150000\n})\n// Recommendation: \"handoff-soon\" -- context at ~75%, prepare handoff\n```\n\nWhen a handoff is needed, **`paradigm_handoff_prepare`** creates a structured summary of the current session. It captures what was done, which symbols were touched, which files were modified, what still needs to happen, and any open questions. This summary becomes the starting point for the next session.\n\n```\nparadigm_handoff_prepare({\n  summary: \"Implemented Apple Pay in checkout flow\",\n  symbolsTouched: [\"#payment-service\", \"$checkout-flow\", \"#apple-pay-button\"],\n  modifiedFiles: [\"src/services/payment.ts\", \"src/components/checkout/ApplePayButton.tsx\"],\n  nextSteps: [\"Add unit tests for Apple Pay handler\", \"Update portal.yaml with new gates\"],\n  openQuestions: [\"Should we support Apple Pay in the mobile app too?\"]\n})\n```\n\nOn the receiving end, **`paradigm_session_recover`** loads breadcrumbs from the previous session. A new agent session calls this at startup to understand what was done before, pick up where the last session left off, and avoid redoing work.\n\nFor cost awareness, **`paradigm_session_stats`** shows the current session's MCP interactions, estimated token usage, and cost breakdown. This is useful for understanding which operations are expensive and optimizing your workflow.\n\nThe context management workflow forms a cycle: **monitor** usage with context_check, **prepare** handoff when limits approach, **recover** in new sessions with session_recover, and **track** costs with session_stats. Mastering this cycle means you can handle tasks that are larger than any single context window by splitting them across multiple sessions without losing progress.",
       "keyConcepts": [
-        "paradigm_context_check for monitoring",
+        "paradigm_session_health for monitoring",
         "paradigm_handoff_prepare for session transfer",
         "paradigm_session_recover for continuity",
         "paradigm_session_stats for cost tracking",
@@ -628,7 +628,7 @@
       "quiz": [
         {
           "id": "q1",
-          "question": "How often should you call paradigm_context_check during a long session?",
+          "question": "How often should you call paradigm_session_health during a long session?",
           "choices": {
             "A": "Only at the start of the session",
             "B": "Every 10-15 tool calls",
@@ -641,7 +641,7 @@
         },
         {
           "id": "q2",
-          "question": "paradigm_context_check returns 'handoff-soon'. What should you do?",
+          "question": "paradigm_session_health returns 'handoff-soon'. What should you do?",
           "choices": {
             "A": "Ignore it and keep working",
             "B": "Immediately stop all work",
@@ -750,7 +750,7 @@
     {
       "id": "operations-review",
       "title": "Operational Excellence",
-      "content": "## Operational Excellence\n\nThis lesson brings together everything from PARA 301 into a cohesive daily workflow. Operational excellence in Paradigm is not about memorizing individual tools -- it is about building habits that keep your project healthy, your metadata accurate, and your development sessions productive.\n\n### The Operational Loop\n\nEvery development session follows a predictable pattern:\n\n**1. Orient** -- Start by calling `paradigm_status` to see the project overview: how many symbols are defined, recent changes, any outstanding issues. If this is a continuation session, call `paradigm_session_recover` to load context from the previous session.\n\n**2. Discover** -- Before touching code, check for existing protocols: call `paradigm_protocol_search` with your task description. If a match exists, follow its steps and skip exploration. Otherwise, call `paradigm_wisdom_context` with the symbols you plan to modify to learn team conventions and avoid known pitfalls. Use `paradigm_navigate` with the \"context\" intent to find all relevant files for your task.\n\n**3. Assess Risk** -- Run `paradigm_ripple` on every symbol you plan to modify to understand the blast radius. Check `paradigm_history_fragility` on anything flagged as a dependency. If the task is complex (3+ files, security + implementation), call `paradigm_orchestrate_inline` with mode=\"plan\" to get the right agent team.\n\n**4. Implement** -- Write code, updating `.purpose` files as you go. If you add routes, update `portal.yaml`. If you add signals, register them. Do not defer metadata updates to \"later\" -- later never comes.\n\n**5. Validate** -- Run `paradigm doctor` or `paradigm_purpose_validate` to catch any drift. Use `paradigm_flow_validate` if you modified flows. Record the implementation with `paradigm_history_record`.\n\n**6. Capture Knowledge** -- Did you discover an antipattern? Record it with `paradigm_wisdom_record`. Did you make an architectural decision? Record that too. Did the implementation follow a repeatable pattern? Record a protocol with `paradigm_protocol_record`. Did the implementation reveal a fragile area? Note it for the team.\n\n**7. Monitor Context** -- Check `paradigm_context_check` periodically. If approaching limits, prepare a handoff.\n\n### Common Pitfalls\n\n- **Skipping wisdom checks**: Leads to repeating mistakes the team already knows about\n- **Skipping ripple analysis**: Leads to breaking downstream dependencies\n- **Deferring metadata updates**: Leads to stale `.purpose` files and misleading navigation\n- **Ignoring fragility warnings**: Leads to cascading failures in unstable areas\n- **Not recording history**: Loses the trail that fragility analysis depends on\n\n### The Measure of Excellence\n\nA well-operated Paradigm project has: accurate `.purpose` files that match the code, a `portal.yaml` that reflects all protected routes, wisdom entries that prevent repeated mistakes, history records that enable fragility analysis, and context handoffs that allow seamless multi-session work. When all of these are in place, every AI agent session starts with full context and every change is informed by the project's complete institutional knowledge.",
+      "content": "## Operational Excellence\n\nThis lesson brings together everything from PARA 301 into a cohesive daily workflow. Operational excellence in Paradigm is not about memorizing individual tools -- it is about building habits that keep your project healthy, your metadata accurate, and your development sessions productive.\n\n### The Operational Loop\n\nEvery development session follows a predictable pattern:\n\n**1. Orient** -- Start by calling `paradigm_status` to see the project overview: how many symbols are defined, recent changes, any outstanding issues. If this is a continuation session, call `paradigm_session_recover` to load context from the previous session.\n\n**2. Discover** -- Before touching code, check for existing protocols: call `paradigm_protocol_search` with your task description. If a match exists, follow its steps and skip exploration. Otherwise, call `paradigm_wisdom_context` with the symbols you plan to modify to learn team conventions and avoid known pitfalls. Use `paradigm_navigate` with the \"context\" intent to find all relevant files for your task.\n\n**3. Assess Risk** -- Run `paradigm_ripple` on every symbol you plan to modify to understand the blast radius. Check `paradigm_history_fragility` on anything flagged as a dependency. If the task is complex (3+ files, security + implementation), call `paradigm_orchestrate_inline` with mode=\"plan\" to get the right agent team.\n\n**4. Implement** -- Write code, updating `.purpose` files as you go. If you add routes, update `portal.yaml`. If you add signals, register them. Do not defer metadata updates to \"later\" -- later never comes.\n\n**5. Validate** -- Run `paradigm doctor` or `paradigm_purpose_validate` to catch any drift. Use `paradigm_flow_check` if you modified flows. Record the implementation with `paradigm_history_record`.\n\n**6. Capture Knowledge** -- Did you discover an antipattern? Record it with `paradigm_wisdom_record`. Did you make an architectural decision? Record that too. Did the implementation follow a repeatable pattern? Record a protocol with `paradigm_protocol_record`. Did the implementation reveal a fragile area? Note it for the team.\n\n**7. Monitor Context** -- Check `paradigm_session_health` periodically. If approaching limits, prepare a handoff.\n\n### Common Pitfalls\n\n- **Skipping wisdom checks**: Leads to repeating mistakes the team already knows about\n- **Skipping ripple analysis**: Leads to breaking downstream dependencies\n- **Deferring metadata updates**: Leads to stale `.purpose` files and misleading navigation\n- **Ignoring fragility warnings**: Leads to cascading failures in unstable areas\n- **Not recording history**: Loses the trail that fragility analysis depends on\n\n### The Measure of Excellence\n\nA well-operated Paradigm project has: accurate `.purpose` files that match the code, a `portal.yaml` that reflects all protected routes, wisdom entries that prevent repeated mistakes, history records that enable fragility analysis, and context handoffs that allow seamless multi-session work. When all of these are in place, every AI agent session starts with full context and every change is informed by the project's complete institutional knowledge.",
       "keyConcepts": [
         "The operational loop: orient, discover, assess, implement, validate, capture, monitor",
         "Combining tools for comprehensive safety",
@@ -793,7 +793,7 @@
             "B": "Recording too much history",
             "C": "Deferring .purpose file updates to 'later', causing metadata to go stale",
             "D": "Using paradigm_navigate instead of reading files",
-            "E": "Calling paradigm_context_check every 10 tool calls"
+            "E": "Calling paradigm_session_health every 10 tool calls"
           },
           "correct": "C",
           "explanation": "Deferring metadata updates is one of the most common pitfalls. When .purpose files go stale, navigation becomes misleading, ripple analysis produces incorrect results, and doctor generates false positives. The rule is: update metadata as you code, not after."

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

@@ -6,7 +6,7 @@
     {
       "id": "mcp-tools-overview",
       "title": "MCP Tools Overview",
-      "content": "## MCP Tools Overview\n\nModel Context Protocol (MCP) tools are the primary interface between AI agents and the Paradigm framework. Rather than reading raw files to understand project structure, agents call MCP tools that return structured, token-efficient responses. Understanding the full tool inventory and when to use each tool is fundamental to effective Paradigm orchestration.\n\nParadigm exposes approximately 15 tool modules, organized into four categories:\n\n### Discovery Tools\nThese tools help agents understand the codebase without reading files directly.\n\n- **`paradigm_search`** (~150 tokens) -- Fuzzy search across symbol names, descriptions, and tags. Supports type filtering (component, flow, gate, signal, aspect).\n- **`paradigm_navigate`** (~200 tokens) -- Three intents: `find` (symbol lookup), `explore` (area browsing), `context` (task-based discovery).\n- **`paradigm_ripple`** (~300 tokens) -- Dependency analysis showing what depends on a symbol, 1-5 levels deep.\n- **`paradigm_related`** (~200 tokens) -- All symbols connected to a given symbol, both upstream and downstream.\n\n### Knowledge Tools\nThese tools access the project's institutional memory.\n\n- **`paradigm_wisdom_context`** -- Retrieves preferences, antipatterns, and decisions for specified symbols.\n- **`paradigm_wisdom_record`** -- Captures new antipatterns or architectural decisions.\n- **`paradigm_wisdom_expert`** -- Identifies human experts for symbols or areas.\n- **`paradigm_history_context`** -- Retrieves implementation history for symbols.\n- **`paradigm_history_record`** -- Logs implementation events.\n- **`paradigm_history_fragility`** -- Checks stability scores.\n\n### Validation Tools\nThese tools verify metadata integrity.\n\n- **`paradigm_purpose_validate`** -- Validates `.purpose` files and optionally `portal.yaml`.\n- **`paradigm_flow_validate`** -- Validates flow definitions against the codebase.\n- **`paradigm_aspect_check`** -- Verifies that aspects have valid code anchors.\n\n### Management Tools\nThese tools modify Paradigm metadata.\n\n- **`paradigm_purpose_add_component`**, **`paradigm_purpose_add_signal`**, **`paradigm_purpose_add_flow`**, etc. -- Add symbols to `.purpose` files.\n- **`paradigm_portal_add_gate`**, **`paradigm_portal_add_route`** -- Manage `portal.yaml` gates and routes.\n- **`paradigm_purpose_rename`** -- Rename symbols across all `.purpose` files.\n- **`paradigm_tags`**, **`paradigm_tags_suggest`** -- Manage the tag bank.\n\n### Token Economics\n\nEvery tool call has a token cost. The general principle is that MCP queries are 5-20x cheaper than reading files:\n\n| Operation | Approximate Cost |\n|---|---|\n| `paradigm_status` | ~100 tokens |\n| `paradigm_search` | ~150 tokens |\n| `paradigm_navigate` | ~200 tokens |\n| `paradigm_ripple` | ~300 tokens |\n| Reading a small file | ~500 tokens |\n| Reading a large file | ~2000+ tokens |\n\nThe rule of thumb: **use MCP tools for discovery and knowledge retrieval; use file reads only when you need exact source code for implementation.** An agent that reads 10 files to understand a feature (10,000+ tokens) versus one that calls `paradigm_navigate` with context intent (200 tokens) has a 50x cost difference for the same information.\n\n### Practice Tools\n\nThese tools manage behavioral discipline and project memory.\n\n**Habits Tools:**\n- **`paradigm_habits_list`** -- List habit definitions with filters (category, trigger, severity, enabled status).\n- **`paradigm_habits_check`** -- Evaluate and record practice compliance. Triggers: `preflight`, `postflight`, `on-stop`, `on-commit`.\n- **`paradigm_habits_status`** -- Practice profile with compliance rates, category breakdowns, trends, and incident correlations.\n- **`paradigm_practice_context`** -- Proactive habit warnings before modifying symbols. Returns relevant habits and recent compliance rates.\n\n**Lore Tools:**\n- **`paradigm_lore_search`** -- Search lore entries by symbol, author, date range, tags, type, and review status.\n- **`paradigm_lore_record`** -- Record new entries (agent sessions, decisions, milestones, incidents, reviews).\n- **`paradigm_lore_get`** -- Fetch a single entry by ID with full detail.\n- **`paradigm_lore_update`** -- Update an existing entry's fields (title, summary, type, symbols, tags, learnings).\n- **`paradigm_lore_delete`** -- Delete an entry by ID. Requires `confirm: true` to prevent accidental deletion.\n- **`paradigm_lore_timeline`** -- Timeline overview with recent entries, hot symbols, and active authors.",
+      "content": "## MCP Tools Overview\n\nModel Context Protocol (MCP) tools are the primary interface between AI agents and the Paradigm framework. Rather than reading raw files to understand project structure, agents call MCP tools that return structured, token-efficient responses. Understanding the full tool inventory and when to use each tool is fundamental to effective Paradigm orchestration.\n\nParadigm exposes approximately 15 tool modules, organized into four categories:\n\n### Discovery Tools\nThese tools help agents understand the codebase without reading files directly.\n\n- **`paradigm_search`** (~150 tokens) -- Fuzzy search across symbol names, descriptions, and tags. Supports type filtering (component, flow, gate, signal, aspect).\n- **`paradigm_navigate`** (~200 tokens) -- Three intents: `find` (symbol lookup), `explore` (area browsing), `context` (task-based discovery).\n- **`paradigm_ripple`** (~300 tokens) -- Dependency analysis showing what depends on a symbol, 1-5 levels deep.\n- **`paradigm_related`** (~200 tokens) -- All symbols connected to a given symbol, both upstream and downstream.\n\n### Knowledge Tools\nThese tools access the project's institutional memory.\n\n- **`paradigm_wisdom_context`** -- Retrieves preferences, antipatterns, and decisions for specified symbols.\n- **`paradigm_wisdom_record`** -- Captures new antipatterns or architectural decisions.\n- **`paradigm_wisdom_expert`** -- Identifies human experts for symbols or areas.\n- **`paradigm_history_context`** -- Retrieves implementation history for symbols.\n- **`paradigm_history_record`** -- Logs implementation events.\n- **`paradigm_history_fragility`** -- Checks stability scores.\n\n### Validation Tools\nThese tools verify metadata integrity.\n\n- **`paradigm_purpose_validate`** -- Validates `.purpose` files and optionally `portal.yaml`.\n- **`paradigm_flow_check`** -- Validates flow definitions against the codebase.\n- **`paradigm_aspect_check`** -- Verifies that aspects have valid code anchors.\n\n### Management Tools\nThese tools modify Paradigm metadata.\n\n- **`paradigm_purpose_add_component`**, **`paradigm_purpose_add_signal`**, **`paradigm_purpose_add_flow`**, etc. -- Add symbols to `.purpose` files.\n- **`paradigm_portal_add_gate`**, **`paradigm_portal_add_route`** -- Manage `portal.yaml` gates and routes.\n- **`paradigm_purpose_rename`** -- Rename symbols across all `.purpose` files.\n- **`paradigm_tags`**, **`paradigm_tags_suggest`** -- Manage the tag bank.\n\n### Token Economics\n\nEvery tool call has a token cost. The general principle is that MCP queries are 5-20x cheaper than reading files:\n\n| Operation | Approximate Cost |\n|---|---|\n| `paradigm_status` | ~100 tokens |\n| `paradigm_search` | ~150 tokens |\n| `paradigm_navigate` | ~200 tokens |\n| `paradigm_ripple` | ~300 tokens |\n| Reading a small file | ~500 tokens |\n| Reading a large file | ~2000+ tokens |\n\nThe rule of thumb: **use MCP tools for discovery and knowledge retrieval; use file reads only when you need exact source code for implementation.** An agent that reads 10 files to understand a feature (10,000+ tokens) versus one that calls `paradigm_navigate` with context intent (200 tokens) has a 50x cost difference for the same information.\n\n### Practice Tools\n\nThese tools manage behavioral discipline and project memory.\n\n**Habits Tools:**\n- **`paradigm_habits_list`** -- List habit definitions with filters (category, trigger, severity, enabled status).\n- **`paradigm_habits_check`** -- Evaluate and record practice compliance. Triggers: `preflight`, `postflight`, `on-stop`, `on-commit`.\n- **`paradigm_habits_status`** -- Practice profile with compliance rates, category breakdowns, trends, and incident correlations.\n- **`paradigm_practice_context`** -- Proactive habit warnings before modifying symbols. Returns relevant habits and recent compliance rates.\n\n**Lore Tools:**\n- **`paradigm_lore_search`** -- Search lore entries by symbol, author, date range, tags, type, and review status.\n- **`paradigm_lore_record`** -- Record new entries (agent sessions, decisions, milestones, incidents, reviews).\n- **`paradigm_lore_get`** -- Fetch a single entry by ID with full detail.\n- **`paradigm_lore_update`** -- Update an existing entry's fields (title, summary, type, symbols, tags, learnings).\n- **`paradigm_lore_delete`** -- Delete an entry by ID. Requires `confirm: true` to prevent accidental deletion.\n- **`paradigm_lore_timeline`** -- Timeline overview with recent entries, hot symbols, and active authors.",
       "keyConcepts": [
         "Four tool categories: discovery, knowledge, validation, management — plus practice tools (habits + lore)",
         "Token economics of MCP vs file reads — each tool description now includes approximate token cost",
@@ -73,7 +73,7 @@
           "question": "You want to verify that ~audit-required still has valid code anchors after a refactor. Which tool do you use?",
           "choices": {
             "A": "paradigm_purpose_validate",
-            "B": "paradigm_flow_validate",
+            "B": "paradigm_flow_check",
             "C": "paradigm_aspect_check",
             "D": "paradigm_ripple",
             "E": "paradigm_search"
@@ -589,7 +589,7 @@
     {
       "id": "mastery-review",
       "title": "Framework Mastery",
-      "content": "## Framework Mastery\n\nThis final lesson synthesizes everything from PARA 101 through PARA 401 into a complete picture of what it means to master the Paradigm framework. Mastery is not about memorizing tool names -- it is about internalizing the workflows, knowing which tool to reach for in each situation, and understanding how the pieces fit together to create a self-documenting, self-healing development system.\n\n### The Complete Paradigm Workflow\n\n**Phase 1: Project Initialization**\n\nEvery Paradigm project starts with `paradigm shift`, which creates the `.paradigm/` directory, `config.yaml`, and initial structure. From there, you define symbols in `.purpose` files, set up `portal.yaml` for gates and condition checks, and configure agent facets in `agents.yaml`. The foundation must be solid -- everything else builds on accurate `.purpose` files and a complete `portal.yaml`.\n\n**Phase 2: Symbol-Driven Development**\n\nWith the foundation in place, development is symbol-driven. Every code unit has a `#component` identity. Multi-step processes are documented as `$flows`. Condition checkpoints are `^gates`. Events are `!signals`. Cross-cutting rules are `~aspects` with code anchors. Tags from the tag bank classify symbols by function: `[feature]`, `[integration]`, `[state]`, `[critical]`.\n\nThe power of symbols is that they create a semantic layer above the code. When an AI agent calls `paradigm_navigate` with intent \"context\" and task \"add retry logic to payments,\" it does not just get file paths -- it gets the full symbolic context: which components are involved, which flows will be affected, which gates protect the endpoints, and which wisdom entries are relevant.\n\n**Phase 3: Operational Excellence**\n\nDay-to-day development follows the operational loop from PARA 301: orient, discover, assess risk, implement, validate, capture knowledge, monitor context. Each step uses specific tools:\n\n| Step | Tools |\n|---|---|\n| Orient | `paradigm_status`, `paradigm_session_recover` |\n| Discover | `paradigm_wisdom_context`, `paradigm_navigate` |\n| Assess | `paradigm_ripple`, `paradigm_history_fragility` |\n| Implement | File edits + `.purpose` updates + `portal.yaml` updates |\n| Validate | `paradigm doctor`, `paradigm_purpose_validate`, `paradigm_flow_validate` |\n| Capture | `paradigm_wisdom_record`, `paradigm_history_record` |\n| Monitor | `paradigm_context_check`, `paradigm_session_stats` |\n\n**Phase 4: Orchestrated Complexity**\n\nComplex tasks are decomposed across specialized agents using `paradigm_orchestrate_inline`. The architect designs, security audits, the builder implements, and the tester validates. The PM layer enforces discipline with pre-flight and post-flight checks. Commits follow the Paradigm convention with `Symbols:` trailers that feed the history system automatically.\n\n### What Distinguishes Mastery\n\nA **beginner** uses Paradigm tools when reminded. They forget to update `.purpose` files, skip ripple analysis, and do not capture wisdom.\n\nA **practitioner** follows the operational loop consistently. They update metadata as they code, run doctor before committing, and record wisdom after debugging sessions.\n\nA **master** has internalized the framework to the point where it is invisible. They instinctively reach for `paradigm_ripple` before any modification. They write commit messages with `Symbols:` trailers without thinking. They call `paradigm_orchestrate_inline` when a task smells complex. They capture wisdom reflexively. Their `.purpose` files are always accurate because they update them in the same motion as writing code.\n\nThe difference is not knowledge -- it is habit. Every tool in Paradigm exists to answer a specific question: \"What depends on this?\" (`paradigm_ripple`), \"What do I need to know?\" (`paradigm_wisdom_context`), \"Is this area stable?\" (`paradigm_history_fragility`), \"What should I work on?\" (`paradigm_navigate`). A master does not think about which tool to use -- the question triggers the tool automatically.\n\n### The Self-Reinforcing System\n\nParadigm is designed as a flywheel. Accurate `.purpose` files make navigation reliable. Reliable navigation makes agents more efficient. Efficient agents produce better results. Better results with Symbols trailers feed the history system. Rich history enables fragility analysis. Fragility analysis informs risk assessment. Risk assessment guides implementation. Implementations update `.purpose` files. The cycle reinforces itself.\n\nEvery time you skip a step -- neglecting a `.purpose` update, omitting a `Symbols:` trailer, not recording wisdom -- you degrade the flywheel. Every time you complete the loop, you strengthen it. Framework mastery is the commitment to keep the flywheel spinning.",
+      "content": "## Framework Mastery\n\nThis final lesson synthesizes everything from PARA 101 through PARA 401 into a complete picture of what it means to master the Paradigm framework. Mastery is not about memorizing tool names -- it is about internalizing the workflows, knowing which tool to reach for in each situation, and understanding how the pieces fit together to create a self-documenting, self-healing development system.\n\n### The Complete Paradigm Workflow\n\n**Phase 1: Project Initialization**\n\nEvery Paradigm project starts with `paradigm shift`, which creates the `.paradigm/` directory, `config.yaml`, and initial structure. From there, you define symbols in `.purpose` files, set up `portal.yaml` for gates and condition checks, and configure agent facets in `agents.yaml`. The foundation must be solid -- everything else builds on accurate `.purpose` files and a complete `portal.yaml`.\n\n**Phase 2: Symbol-Driven Development**\n\nWith the foundation in place, development is symbol-driven. Every code unit has a `#component` identity. Multi-step processes are documented as `$flows`. Condition checkpoints are `^gates`. Events are `!signals`. Cross-cutting rules are `~aspects` with code anchors. Tags from the tag bank classify symbols by function: `[feature]`, `[integration]`, `[state]`, `[critical]`.\n\nThe power of symbols is that they create a semantic layer above the code. When an AI agent calls `paradigm_navigate` with intent \"context\" and task \"add retry logic to payments,\" it does not just get file paths -- it gets the full symbolic context: which components are involved, which flows will be affected, which gates protect the endpoints, and which wisdom entries are relevant.\n\n**Phase 3: Operational Excellence**\n\nDay-to-day development follows the operational loop from PARA 301: orient, discover, assess risk, implement, validate, capture knowledge, monitor context. Each step uses specific tools:\n\n| Step | Tools |\n|---|---|\n| Orient | `paradigm_status`, `paradigm_session_recover` |\n| Discover | `paradigm_wisdom_context`, `paradigm_navigate` |\n| Assess | `paradigm_ripple`, `paradigm_history_fragility` |\n| Implement | File edits + `.purpose` updates + `portal.yaml` updates |\n| Validate | `paradigm doctor`, `paradigm_purpose_validate`, `paradigm_flow_check` |\n| Capture | `paradigm_wisdom_record`, `paradigm_history_record` |\n| Monitor | `paradigm_session_health`, `paradigm_session_stats` |\n\n**Phase 4: Orchestrated Complexity**\n\nComplex tasks are decomposed across specialized agents using `paradigm_orchestrate_inline`. The architect designs, security audits, the builder implements, and the tester validates. The PM layer enforces discipline with pre-flight and post-flight checks. Commits follow the Paradigm convention with `Symbols:` trailers that feed the history system automatically.\n\n### What Distinguishes Mastery\n\nA **beginner** uses Paradigm tools when reminded. They forget to update `.purpose` files, skip ripple analysis, and do not capture wisdom.\n\nA **practitioner** follows the operational loop consistently. They update metadata as they code, run doctor before committing, and record wisdom after debugging sessions.\n\nA **master** has internalized the framework to the point where it is invisible. They instinctively reach for `paradigm_ripple` before any modification. They write commit messages with `Symbols:` trailers without thinking. They call `paradigm_orchestrate_inline` when a task smells complex. They capture wisdom reflexively. Their `.purpose` files are always accurate because they update them in the same motion as writing code.\n\nThe difference is not knowledge -- it is habit. Every tool in Paradigm exists to answer a specific question: \"What depends on this?\" (`paradigm_ripple`), \"What do I need to know?\" (`paradigm_wisdom_context`), \"Is this area stable?\" (`paradigm_history_fragility`), \"What should I work on?\" (`paradigm_navigate`). A master does not think about which tool to use -- the question triggers the tool automatically.\n\n### The Self-Reinforcing System\n\nParadigm is designed as a flywheel. Accurate `.purpose` files make navigation reliable. Reliable navigation makes agents more efficient. Efficient agents produce better results. Better results with Symbols trailers feed the history system. Rich history enables fragility analysis. Fragility analysis informs risk assessment. Risk assessment guides implementation. Implementations update `.purpose` files. The cycle reinforces itself.\n\nEvery time you skip a step -- neglecting a `.purpose` update, omitting a `Symbols:` trailer, not recording wisdom -- you degrade the flywheel. Every time you complete the loop, you strengthen it. Framework mastery is the commitment to keep the flywheel spinning.",
       "keyConcepts": [
         "Four phases: initialization, symbol-driven development, operational excellence, orchestrated complexity",
         "Beginner -> practitioner -> master progression",

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

@@ -284,7 +284,7 @@
     {
       "id": "habits-practice",
       "title": "Habits & Practice",
-      "content": "## Instinct vs Habit\n\nWhen you first learn to drive, you consciously think about every action — check mirrors, signal, check blind spot, change lanes. After thousands of miles, these become habits: automatic behaviors you execute without conscious effort. The Habits system brings this concept to AI-assisted development.\n\nWithout habits, an agent must be told every time: \"check ripple before modifying,\" \"validate flows after changing gates,\" \"record lore for significant sessions.\" With habits, these checks become automatic behavioral triggers — the system evaluates them at defined points and reports compliance. Over time, agents internalize the patterns, and the habit checks become confirmation rather than correction.\n\n## Habit Definitions\n\nEach habit is a structured rule with six fields:\n\n```yaml\nid: ripple-before-modify\nname: Check Ripple Before Modifying\ndescription: Always call paradigm_ripple before modifying any symbol\ncategory: discovery\ntrigger: preflight\nseverity: advisory\ncheck:\n  type: tool-called\n  params:\n    tools: [paradigm_ripple]\nenabled: true\n```\n\n**Categories** classify what kind of discipline the habit enforces. There are six:\n- `discovery` — Exploring before acting (ripple, navigate, search)\n- `verification` — Validating after implementing (postflight, reindex)\n- `testing` — Ensuring test coverage for new code\n- `documentation` — Keeping .purpose files and lore entries current\n- `collaboration` — Checking team wisdom and expert knowledge\n- `security` — Validating gates and portal.yaml compliance\n\n**Triggers** define when the habit is evaluated. There are four:\n- `preflight` — Before starting implementation\n- `postflight` — After completing implementation\n- `on-commit` — Before committing changes\n- `on-stop` — Before the session ends (stop hook)\n\n**Severity** determines what happens when a habit is violated:\n- `advisory` — Log a note, don't block anything\n- `warn` — Show a warning to the agent/user\n- `block` — Prevent session completion until resolved (enforced by stop hook)\n\n## Check Types\n\nHabits verify compliance through twelve check types:\n\n| Check Type | What It Verifies |\n|---|---|\n| `tool-called` | Specified MCP tools were invoked during the session |\n| `file-exists` | Files matching glob patterns exist (e.g., test files) |\n| `file-modified` | Files matching patterns were modified during session |\n| `lore-recorded` | A lore entry was created (for 3+ file sessions) |\n| `symbols-registered` | New code is registered in .purpose files |\n| `gates-declared` | Routes have corresponding gates in portal.yaml |\n| `tests-exist` | Test files exist for modified components |\n| `git-clean` | Git working tree is clean — all changes committed |\n| `commit-message-format` | Commit messages match regex patterns (default: conventional commit prefix + Symbols: trailer) |\n| `flow-coverage` | Changes spanning 3+ components have a documented $flow |\n| `context-checked` | Session context/recovery tools (paradigm_context_check, paradigm_session_recover) were called |\n| `aspect-anchored` | Touched aspects (~) have valid code anchors verified via paradigm_aspect_check |\n\n## The 14 Seed Habits\n\nParadigm ships with 14 built-in habits that establish baseline discipline:\n\n1. **explore-before-implement** (preflight/advisory/discovery) — Called paradigm_ripple, paradigm_navigate, paradigm_search, or paradigm_related before coding\n2. **ripple-before-modify** (preflight/advisory/discovery) — Called paradigm_ripple specifically before modifying symbols\n3. **check-fragility** (preflight/advisory/discovery) — Called paradigm_history_fragility before touching symbols\n4. **wisdom-before-implement** (preflight/advisory/collaboration) — Checked paradigm_wisdom_context or paradigm_wisdom_expert\n5. **verify-before-done** (on-stop/warn/verification) — Called paradigm_pm_postflight before finishing\n6. **postflight-compliance** (on-stop/advisory/verification) — Ran postflight and reindex\n7. **test-new-components** (postflight/advisory/testing) — Test files exist for new components\n8. **purpose-coverage** (postflight/warn/documentation) — .purpose files cover modified directories\n9. **record-lore-for-significant** (on-stop/warn/documentation) — Lore recorded for 3+ file sessions\n10. **gates-for-routes** (postflight/warn/security) — Routes have portal.yaml gate coverage\n11. **commit-message-symbols** (on-commit/advisory/documentation) — Commit messages follow type(#symbol): format with Symbols: trailer\n12. **flow-coverage-for-multi-component** (postflight/advisory/documentation) — Changes spanning 3+ components have a documented $flow\n13. **context-session-awareness** (preflight/advisory/discovery) — Session recovery or context check tools were called for continuity\n14. **aspect-anchors-valid** (postflight/advisory/verification) — Aspects touched during the session have valid code anchors\n\n## Habit Loading and Overrides\n\nHabits load from three sources, merged in order (later wins):\n\n1. **Seed habits** — The 10 built-in habits (always present)\n2. **Global habits** — `~/.paradigm/habits.yaml` (optional, applies to all projects)\n3. **Project habits** — `.paradigm/habits.yaml` (optional, project-specific)\n\nOverrides let you adjust severity or disable habits without redefining them:\n\n```yaml\n# .paradigm/habits.yaml\noverrides:\n  ripple-before-modify:\n    severity: block    # Upgrade from advisory to blocking\n  test-new-components:\n    enabled: false     # Disable for this project\ncustom:\n  - id: check-migrations\n    name: Verify DB Migrations\n    category: verification\n    trigger: on-commit\n    severity: warn\n    check:\n      type: file-exists\n      params:\n        patterns: [\"migrations/*.sql\"]\n```\n\n## Practice Profiles\n\nEvery habit evaluation is recorded as a practice event with a result: `followed`, `skipped`, or `partial`. These events accumulate into practice profiles that show compliance rates over time.\n\n`paradigm_habits_status` returns a practice profile with: overall compliance rate, strongest and weakest categories, per-category breakdowns, trend analysis (improving/declining/stable), and incident correlations — habits whose skipped evaluations correlate with higher incident rates.\n\nThe incident correlation is powerful: if skipping `ripple-before-modify` correlates with a 3x higher incident rate for the modified symbols, that is concrete evidence for upgrading the habit's severity.\n\n## MCP Tools\n\n**`paradigm_habits_check`** — Evaluate habits for a trigger point. Pass the trigger (`preflight`, `postflight`, `on-stop`), optionally with `filesModified` and `symbolsTouched` for context. Returns evaluations with follow/skip/partial results and whether any blocking violations exist.\n\n**`paradigm_habits_status`** — Get the practice profile for an engineer over a time period (7d, 30d, 90d, or all). Shows compliance rates, category breakdowns, trends, and incident correlations.\n\n**`paradigm_practice_context`** — Before modifying symbols, get habit-aware warnings. Pass the symbols you are about to touch, and it returns relevant habits, recent compliance rates, and suggestions based on your weak areas.\n\n## CLI Commands\n\nThe CLI provides full habit management:\n\n- `paradigm habits list` — List all habits with trigger, severity, and enabled status\n- `paradigm habits add` — Add a custom habit with check type, patterns, and tools\n- `paradigm habits edit <id>` — Edit habit fields (for seed habits: severity and enabled only)\n- `paradigm habits remove <id>` — Remove a custom habit\n- `paradigm habits enable/disable <id>` — Toggle a habit on or off\n- `paradigm habits check --trigger <trigger>` — Evaluate compliance for a specific trigger\n- `paradigm habits status` — Practice profile with compliance rates and trends\n- `paradigm habits init` — Initialize a habits.yaml file for the project\n\n## Platform Targeting\n\nHabits support a `platforms` field to restrict evaluation to specific platforms. For example, a habit with `platforms: ['claude', 'cursor']` will only be evaluated when running in those environments. A habit with `platforms: ['cli']` will only fire during CLI-driven workflows. When `platforms` is omitted, the habit applies everywhere.",
+      "content": "## Instinct vs Habit\n\nWhen you first learn to drive, you consciously think about every action — check mirrors, signal, check blind spot, change lanes. After thousands of miles, these become habits: automatic behaviors you execute without conscious effort. The Habits system brings this concept to AI-assisted development.\n\nWithout habits, an agent must be told every time: \"check ripple before modifying,\" \"validate flows after changing gates,\" \"record lore for significant sessions.\" With habits, these checks become automatic behavioral triggers — the system evaluates them at defined points and reports compliance. Over time, agents internalize the patterns, and the habit checks become confirmation rather than correction.\n\n## Habit Definitions\n\nEach habit is a structured rule with six fields:\n\n```yaml\nid: ripple-before-modify\nname: Check Ripple Before Modifying\ndescription: Always call paradigm_ripple before modifying any symbol\ncategory: discovery\ntrigger: preflight\nseverity: advisory\ncheck:\n  type: tool-called\n  params:\n    tools: [paradigm_ripple]\nenabled: true\n```\n\n**Categories** classify what kind of discipline the habit enforces. There are six:\n- `discovery` — Exploring before acting (ripple, navigate, search)\n- `verification` — Validating after implementing (postflight, reindex)\n- `testing` — Ensuring test coverage for new code\n- `documentation` — Keeping .purpose files and lore entries current\n- `collaboration` — Checking team wisdom and expert knowledge\n- `security` — Validating gates and portal.yaml compliance\n\n**Triggers** define when the habit is evaluated. There are four:\n- `preflight` — Before starting implementation\n- `postflight` — After completing implementation\n- `on-commit` — Before committing changes\n- `on-stop` — Before the session ends (stop hook)\n\n**Severity** determines what happens when a habit is violated:\n- `advisory` — Log a note, don't block anything\n- `warn` — Show a warning to the agent/user\n- `block` — Prevent session completion until resolved (enforced by stop hook)\n\n## Check Types\n\nHabits verify compliance through twelve check types:\n\n| Check Type | What It Verifies |\n|---|---|\n| `tool-called` | Specified MCP tools were invoked during the session |\n| `file-exists` | Files matching glob patterns exist (e.g., test files) |\n| `file-modified` | Files matching patterns were modified during session |\n| `lore-recorded` | A lore entry was created (for 3+ file sessions) |\n| `symbols-registered` | New code is registered in .purpose files |\n| `gates-declared` | Routes have corresponding gates in portal.yaml |\n| `tests-exist` | Test files exist for modified components |\n| `git-clean` | Git working tree is clean — all changes committed |\n| `commit-message-format` | Commit messages match regex patterns (default: conventional commit prefix + Symbols: trailer) |\n| `flow-coverage` | Changes spanning 3+ components have a documented $flow |\n| `context-checked` | Session context/recovery tools (paradigm_session_health, paradigm_session_recover) were called |\n| `aspect-anchored` | Touched aspects (~) have valid code anchors verified via paradigm_aspect_check |\n\n## The 14 Seed Habits\n\nParadigm ships with 14 built-in habits that establish baseline discipline:\n\n1. **explore-before-implement** (preflight/advisory/discovery) — Called paradigm_ripple, paradigm_navigate, paradigm_search, or paradigm_related before coding\n2. **ripple-before-modify** (preflight/advisory/discovery) — Called paradigm_ripple specifically before modifying symbols\n3. **check-fragility** (preflight/advisory/discovery) — Called paradigm_history_fragility before touching symbols\n4. **wisdom-before-implement** (preflight/advisory/collaboration) — Checked paradigm_wisdom_context or paradigm_wisdom_expert\n5. **verify-before-done** (on-stop/warn/verification) — Called paradigm_pm_postflight before finishing\n6. **postflight-compliance** (on-stop/advisory/verification) — Ran postflight and reindex\n7. **test-new-components** (postflight/advisory/testing) — Test files exist for new components\n8. **purpose-coverage** (postflight/warn/documentation) — .purpose files cover modified directories\n9. **record-lore-for-significant** (on-stop/warn/documentation) — Lore recorded for 3+ file sessions\n10. **gates-for-routes** (postflight/warn/security) — Routes have portal.yaml gate coverage\n11. **commit-message-symbols** (on-commit/advisory/documentation) — Commit messages follow type(#symbol): format with Symbols: trailer\n12. **flow-coverage-for-multi-component** (postflight/advisory/documentation) — Changes spanning 3+ components have a documented $flow\n13. **context-session-awareness** (preflight/advisory/discovery) — Session recovery or context check tools were called for continuity\n14. **aspect-anchors-valid** (postflight/advisory/verification) — Aspects touched during the session have valid code anchors\n\n## Habit Loading and Overrides\n\nHabits load from three sources, merged in order (later wins):\n\n1. **Seed habits** — The 10 built-in habits (always present)\n2. **Global habits** — `~/.paradigm/habits.yaml` (optional, applies to all projects)\n3. **Project habits** — `.paradigm/habits.yaml` (optional, project-specific)\n\nOverrides let you adjust severity or disable habits without redefining them:\n\n```yaml\n# .paradigm/habits.yaml\noverrides:\n  ripple-before-modify:\n    severity: block    # Upgrade from advisory to blocking\n  test-new-components:\n    enabled: false     # Disable for this project\ncustom:\n  - id: check-migrations\n    name: Verify DB Migrations\n    category: verification\n    trigger: on-commit\n    severity: warn\n    check:\n      type: file-exists\n      params:\n        patterns: [\"migrations/*.sql\"]\n```\n\n## Practice Profiles\n\nEvery habit evaluation is recorded as a practice event with a result: `followed`, `skipped`, or `partial`. These events accumulate into practice profiles that show compliance rates over time.\n\n`paradigm_habits_status` returns a practice profile with: overall compliance rate, strongest and weakest categories, per-category breakdowns, trend analysis (improving/declining/stable), and incident correlations — habits whose skipped evaluations correlate with higher incident rates.\n\nThe incident correlation is powerful: if skipping `ripple-before-modify` correlates with a 3x higher incident rate for the modified symbols, that is concrete evidence for upgrading the habit's severity.\n\n## MCP Tools\n\n**`paradigm_habits_check`** — Evaluate habits for a trigger point. Pass the trigger (`preflight`, `postflight`, `on-stop`), optionally with `filesModified` and `symbolsTouched` for context. Returns evaluations with follow/skip/partial results and whether any blocking violations exist.\n\n**`paradigm_habits_status`** — Get the practice profile for an engineer over a time period (7d, 30d, 90d, or all). Shows compliance rates, category breakdowns, trends, and incident correlations.\n\n**`paradigm_practice_context`** — Before modifying symbols, get habit-aware warnings. Pass the symbols you are about to touch, and it returns relevant habits, recent compliance rates, and suggestions based on your weak areas.\n\n## CLI Commands\n\nThe CLI provides full habit management:\n\n- `paradigm habits list` — List all habits with trigger, severity, and enabled status\n- `paradigm habits add` — Add a custom habit with check type, patterns, and tools\n- `paradigm habits edit <id>` — Edit habit fields (for seed habits: severity and enabled only)\n- `paradigm habits remove <id>` — Remove a custom habit\n- `paradigm habits enable/disable <id>` — Toggle a habit on or off\n- `paradigm habits check --trigger <trigger>` — Evaluate compliance for a specific trigger\n- `paradigm habits status` — Practice profile with compliance rates and trends\n- `paradigm habits init` — Initialize a habits.yaml file for the project\n\n## Platform Targeting\n\nHabits support a `platforms` field to restrict evaluation to specific platforms. For example, a habit with `platforms: ['claude', 'cursor']` will only be evaluated when running in those environments. A habit with `platforms: ['cli']` will only fire during CLI-driven workflows. When `platforms` is omitted, the habit applies everywhere.",
       "keyConcepts": [
         "Six categories: discovery, verification, testing, documentation, collaboration, security",
         "Four triggers: preflight, postflight, on-commit, on-stop",
@@ -353,7 +353,7 @@
     {
       "id": "session-intelligence",
       "title": "Session Intelligence",
-      "content": "## The Session Problem\n\nAI agent sessions are ephemeral. When a session ends — whether by completion, crash, context exhaustion, or human interruption — everything the agent knew vanishes. The next session starts blank, with no memory of what was explored, decided, or partially implemented. Session Intelligence solves this with checkpoints, breadcrumbs, and a global brain that persists knowledge across sessions and even across projects.\n\n## Session Checkpoints\n\nCheckpoints are deliberate snapshots saved at phase transitions. There are four phases:\n\n| Phase | When to Checkpoint | What to Capture |\n|---|---|---|\n| `planning` | After reading requirements, before coding | Plan, approach, key decisions |\n| `implementing` | After starting code changes | Modified files, symbols touched, decisions made |\n| `validating` | After implementation, before tests | All modified files, test plan |\n| `complete` | Task finished | Summary, final file list |\n\nCreate a checkpoint with `paradigm_session_checkpoint`:\n\n```\nparadigm_session_checkpoint({\n  phase: \"implementing\",\n  context: \"Adding JWT auth middleware — RS256 signing, httpOnly refresh tokens\",\n  modifiedFiles: [\"src/middleware/auth.ts\", \"src/handlers/refresh.ts\"],\n  symbolsTouched: [\"#auth-middleware\", \"^authenticated\"],\n  decisions: [\"RS256 over HS256 for public key verification\"]\n})\n```\n\nOnly `phase` and `context` are required — everything else is optional. The context field should be a concise 1-3 sentence summary of your current state of mind. Think of it as answering \"if I were teleported into this session right now, what would I need to know?\"\n\nCheckpoints are stored in `.paradigm/session-checkpoint.json` and auto-expire after 7 days.\n\n## Breadcrumb Tracking\n\nWhile checkpoints are deliberate, breadcrumbs are automatic. Every MCP tool call generates a breadcrumb recording the timestamp, tool name, symbol being modified (if applicable), and a human-readable summary. Breadcrumbs are stored in `.paradigm/session-breadcrumbs.json` with a maximum of 50 entries (auto-rotating — oldest dropped when full).\n\nBreadcrumbs capture the narrative of a session: \"searched for payment symbols → checked ripple on #payment-service → read auth middleware → modified #auth-handler → created ^refund-eligible gate.\" This trail lets the next session understand not just what was done but the reasoning path.\n\n## Session Recovery\n\nRecovery is the payoff. Call `paradigm_session_recover` (or let it happen automatically — recovery data is surfaced on your first Paradigm tool call in a new session) to get:\n\n- **breadcrumbs** — The last session's tool call trail\n- **lastCheckpoint** — The most recent checkpoint with phase, context, and details\n- **symbolsModified** — All symbols that were changed\n- **recentActivity** — A human-readable summary of what happened\n\nThis is crash recovery for AI agents. If a session dies at 87% context with half-finished auth middleware, the next session immediately knows: phase was `implementing`, auth middleware was being added, RS256 was chosen, these files were modified, and tests still need to be written.\n\n## The Global Brain\n\nSession Intelligence extends beyond individual projects through the Global Brain at `~/.paradigm/`. This user-level directory stores:\n\n- **Global wisdom** — Antipatterns and decisions that apply everywhere (e.g., \"never use HS256 for JWT signing in production\")\n- **Global habits** — Behavioral overrides that apply to all projects\n- **Cross-project practice events** — Compliance data aggregated across projects\n\nThe distinction between project scope and global scope is important:\n\n| Scope | Location | Applies To | Example |\n|---|---|---|---|\n| Project | `.paradigm/` | This project only | \"Use Redis for caching in this app\" |\n| Global | `~/.paradigm/` | All projects | \"Always check fragility before modifying critical symbols\" |\n\n## Wisdom Promotion\n\nWhen a project-local wisdom entry proves universally valuable, promote it to global scope with `paradigm_wisdom_promote`. This copies the entry from `.paradigm/wisdom/` to `~/.paradigm/wisdom/`, making it available in every project.\n\nFor example, if a team discovers that \"always wrap Express v5 async middleware in try-catch\" prevents errors across multiple projects, promoting this wisdom means every future project session gets this advice automatically when touching Express middleware.\n\n## Handoff Persistence\n\nWhen context usage exceeds 80-85%, `paradigm_context_check` recommends a handoff. `paradigm_handoff_prepare` creates a structured handoff document with: summary of work done, modified files, symbols touched, next steps, and open questions. This document is stored alongside session data so the receiving session can `paradigm_session_recover` and pick up exactly where the previous session left off.\n\nThe handoff is not just a note — it is a contract between sessions. The outgoing session declares what was done and what remains. The incoming session validates against the actual file state and continues.\n\n## Best Practices\n\n- Checkpoint at every phase transition — the cost is ~100 tokens, the value is crash recovery\n- Write `context` as if briefing a stranger with no prior knowledge\n- Promote wisdom that survives 3+ projects to global scope\n- Use handoffs proactively at 80% context, not reactively at 95%\n- Let breadcrumbs accumulate naturally — don't try to manage them manually",
+      "content": "## The Session Problem\n\nAI agent sessions are ephemeral. When a session ends — whether by completion, crash, context exhaustion, or human interruption — everything the agent knew vanishes. The next session starts blank, with no memory of what was explored, decided, or partially implemented. Session Intelligence solves this with checkpoints, breadcrumbs, and a global brain that persists knowledge across sessions and even across projects.\n\n## Session Checkpoints\n\nCheckpoints are deliberate snapshots saved at phase transitions. There are four phases:\n\n| Phase | When to Checkpoint | What to Capture |\n|---|---|---|\n| `planning` | After reading requirements, before coding | Plan, approach, key decisions |\n| `implementing` | After starting code changes | Modified files, symbols touched, decisions made |\n| `validating` | After implementation, before tests | All modified files, test plan |\n| `complete` | Task finished | Summary, final file list |\n\nCreate a checkpoint with `paradigm_session_checkpoint`:\n\n```\nparadigm_session_checkpoint({\n  phase: \"implementing\",\n  context: \"Adding JWT auth middleware — RS256 signing, httpOnly refresh tokens\",\n  modifiedFiles: [\"src/middleware/auth.ts\", \"src/handlers/refresh.ts\"],\n  symbolsTouched: [\"#auth-middleware\", \"^authenticated\"],\n  decisions: [\"RS256 over HS256 for public key verification\"]\n})\n```\n\nOnly `phase` and `context` are required — everything else is optional. The context field should be a concise 1-3 sentence summary of your current state of mind. Think of it as answering \"if I were teleported into this session right now, what would I need to know?\"\n\nCheckpoints are stored in `.paradigm/session-checkpoint.json` and auto-expire after 7 days.\n\n## Breadcrumb Tracking\n\nWhile checkpoints are deliberate, breadcrumbs are automatic. Every MCP tool call generates a breadcrumb recording the timestamp, tool name, symbol being modified (if applicable), and a human-readable summary. Breadcrumbs are stored in `.paradigm/session-breadcrumbs.json` with a maximum of 50 entries (auto-rotating — oldest dropped when full).\n\nBreadcrumbs capture the narrative of a session: \"searched for payment symbols → checked ripple on #payment-service → read auth middleware → modified #auth-handler → created ^refund-eligible gate.\" This trail lets the next session understand not just what was done but the reasoning path.\n\n## Session Recovery\n\nRecovery is the payoff. Call `paradigm_session_recover` (or let it happen automatically — recovery data is surfaced on your first Paradigm tool call in a new session) to get:\n\n- **breadcrumbs** — The last session's tool call trail\n- **lastCheckpoint** — The most recent checkpoint with phase, context, and details\n- **symbolsModified** — All symbols that were changed\n- **recentActivity** — A human-readable summary of what happened\n\nThis is crash recovery for AI agents. If a session dies at 87% context with half-finished auth middleware, the next session immediately knows: phase was `implementing`, auth middleware was being added, RS256 was chosen, these files were modified, and tests still need to be written.\n\n## The Global Brain\n\nSession Intelligence extends beyond individual projects through the Global Brain at `~/.paradigm/`. This user-level directory stores:\n\n- **Global wisdom** — Antipatterns and decisions that apply everywhere (e.g., \"never use HS256 for JWT signing in production\")\n- **Global habits** — Behavioral overrides that apply to all projects\n- **Cross-project practice events** — Compliance data aggregated across projects\n\nThe distinction between project scope and global scope is important:\n\n| Scope | Location | Applies To | Example |\n|---|---|---|---|\n| Project | `.paradigm/` | This project only | \"Use Redis for caching in this app\" |\n| Global | `~/.paradigm/` | All projects | \"Always check fragility before modifying critical symbols\" |\n\n## Wisdom Promotion\n\nWhen a project-local wisdom entry proves universally valuable, promote it to global scope with `paradigm_wisdom_promote`. This copies the entry from `.paradigm/wisdom/` to `~/.paradigm/wisdom/`, making it available in every project.\n\nFor example, if a team discovers that \"always wrap Express v5 async middleware in try-catch\" prevents errors across multiple projects, promoting this wisdom means every future project session gets this advice automatically when touching Express middleware.\n\n## Handoff Persistence\n\nWhen context usage exceeds 80-85%, `paradigm_session_health` recommends a handoff. `paradigm_handoff_prepare` creates a structured handoff document with: summary of work done, modified files, symbols touched, next steps, and open questions. This document is stored alongside session data so the receiving session can `paradigm_session_recover` and pick up exactly where the previous session left off.\n\nThe handoff is not just a note — it is a contract between sessions. The outgoing session declares what was done and what remains. The incoming session validates against the actual file state and continues.\n\n## Best Practices\n\n- Checkpoint at every phase transition — the cost is ~100 tokens, the value is crash recovery\n- Write `context` as if briefing a stranger with no prior knowledge\n- Promote wisdom that survives 3+ projects to global scope\n- Use handoffs proactively at 80% context, not reactively at 95%\n- Let breadcrumbs accumulate naturally — don't try to manage them manually",
       "keyConcepts": [
         "Four checkpoint phases: planning, implementing, validating, complete",
         "Breadcrumbs auto-track every MCP tool call (max 50, auto-rotating)",
@@ -410,12 +410,12 @@
           "choices": {
             "A": "Continue working — 82% is still plenty of room",
             "B": "Immediately stop and call `paradigm_handoff_prepare` with summary and next steps",
-            "C": "Call `paradigm_context_check` to confirm, then proactively prepare a handoff while finishing current work",
+            "C": "Call `paradigm_session_health` to confirm, then proactively prepare a handoff while finishing current work",
             "D": "Delete old messages to free up context space",
             "E": "Save a checkpoint and keep working until 95%"
           },
           "correct": "C",
-          "explanation": "At 80-85%, the recommendation is proactive handoff preparation. Call `paradigm_context_check` to confirm the recommendation, then prepare the handoff with `paradigm_handoff_prepare` while completing your current task. Waiting until 95% (E) risks running out of context mid-task. The sweet spot is preparing the handoff while you still have room to finish current work cleanly."
+          "explanation": "At 80-85%, the recommendation is proactive handoff preparation. Call `paradigm_session_health` to confirm the recommendation, then prepare the handoff with `paradigm_handoff_prepare` while completing your current task. Waiting until 95% (E) risks running out of context mid-task. The sweet spot is preparing the handoff while you still have room to finish current work cleanly."
         },
         {
           "id": "q5",
@@ -517,7 +517,7 @@
     {
       "id": "advanced-workflows",
       "title": "The Complete Workflow",
-      "content": "## Putting It All Together\n\nYou have learned the five advanced systems individually. Now let's see how they work together in a complete development workflow. Every system has a role, and the handoffs between them create a feedback loop that gets smarter with every session.\n\n## The Full Cycle\n\nHere is the complete Paradigm workflow for a non-trivial task:\n\n### Phase 1: Preflight\n\n```\n1. paradigm_session_recover       → Load previous session context\n2. paradigm_pm_preflight           → Get compliance plan for the task\n3. paradigm_habits_check(preflight) → Verify discovery habits are followed\n4. paradigm_ripple                 → Check impact of planned changes\n5. paradigm_wisdom_context         → Get team knowledge for affected symbols\n6. paradigm_practice_context       → Get habit-aware warnings for symbols\n7. paradigm_session_checkpoint(planning) → Save plan before coding\n```\n\nNotice the layering: session recovery provides continuity, preflight ensures preparation, habits check enforces discovery discipline, ripple and wisdom provide context, practice context adds behavioral awareness, and the checkpoint enables crash recovery.\n\n### Phase 2: Implementation\n\n```\n8. Write code                      → Implement the feature\n   → Post-write hook fires         → Tracks edited files in .pending-review\n   → Post-write advisory           → Reminds about .purpose coverage\n9. Update .purpose files           → Document new/changed symbols\n10. Update portal.yaml             → Add routes and gates (if applicable)\n11. paradigm_session_checkpoint(implementing) → Save progress\n```\n\nThe post-write hook acts as a running tally. Every source file edit is tracked, and periodic reminders keep documentation top of mind. Updating .purpose and portal.yaml during implementation (not after) prevents the stop hook from blocking at the end.\n\n### Phase 3: Validation\n\n```\n12. paradigm_flow_validate          → Verify flows are complete\n13. paradigm_aspect_check           → Verify aspect anchors are valid\n14. paradigm_pm_postflight          → Run post-implementation governance\n15. paradigm_habits_check(postflight) → Verify documentation/testing habits\n16. paradigm_session_checkpoint(validating) → Save pre-test state\n```\n\nValidation catches issues before they become stop hook violations. Flow validation ensures multi-step processes are complete. Aspect checks confirm anchors point to real code. Postflight governance catches missing .purpose files and undefined gates.\n\n### Phase 4: Recording\n\n```\n17. paradigm_lore_record            → Record the session's work\n18. paradigm_history_record         → Log implementation to symbol history\n19. paradigm_reindex                → Rebuild the symbol index\n20. paradigm_session_checkpoint(complete) → Mark task complete\n```\n\nRecording preserves institutional knowledge. The lore entry captures what was done and why. History record logs implementation details to individual symbol timelines. Reindexing ensures the symbol index reflects all changes.\n\n### Phase 5: Commit\n\n```\n21. git commit                      → Commit changes\n    → Pre-commit hook fires         → Auto-rebuilds index, stages updated files\n    → Stop hook fires               → Validates all compliance checks\n22. If stop hook blocks             → Fix violations, re-attempt\n23. If stop hook passes             → Session complete\n```\n\nThe commit phase is where enforcement happens. The pre-commit hook ensures the index is fresh. The stop hook validates everything: .purpose coverage, portal.yaml compliance, aspect anchors, lore recording, and pending review freshness.\n\n## How Systems Reinforce Each Other\n\nThe power of the complete workflow is in the feedback loops:\n\n**Sentinel catches what Habits miss.** If an agent skips the `ripple-before-modify` habit and introduces a breaking change, Sentinel records the incident. The practice profile then shows that skipping ripple correlates with incidents — evidence to upgrade the habit severity.\n\n**Lore preserves what Sessions forget.** Session breadcrumbs and checkpoints are ephemeral — they expire after 7 days. Lore entries are permanent. The checkpoint gets you through a crash; the lore entry gets the team through the next 6 months.\n\n**Wisdom surfaces what Lore accumulates.** Lore entries record individual sessions. Wisdom distills patterns across sessions: \"every time we modify #payment-service, check for null references on the refund object.\" Wisdom is lore, refined.\n\n**Hooks enforce what Habits recommend.** Habits at `advisory` severity are suggestions. The stop hook at `block` severity is enforcement. The workflow starts with advice (habits check) and ends with enforcement (stop hook). This graduated approach teaches good behavior before punishing bad behavior.\n\n## Capstone Scenario\n\nImagine you are adding a refund endpoint to a payment system. Here is how the complete workflow plays out:\n\n1. **Session recover** reveals the previous session added the payment processor but did not add refunds\n2. **Preflight** shows you need to check `#payment-service`, `$checkout-flow`, and `^authenticated`\n3. **Habits check** confirms you called ripple and wisdom — discovery habits followed\n4. **Ripple** shows `#payment-service` has 4 downstream dependents\n5. **Wisdom** warns: \"always null-check refund objects — see incident INC-042\"\n6. You implement the refund endpoint with proper null checks\n7. **Post-write hook** tracks 5 edited files in `.pending-review`\n8. You update .purpose with `#refund-handler` and portal.yaml with `^refund-eligible` gate\n9. **Postflight** confirms all gates are declared and flows are valid\n10. **Lore record** captures the session with the decision to require `^refund-eligible`\n11. **Commit** triggers pre-commit (index rebuild) and stop hook (all checks pass)\n12. Three weeks later, a similar null reference hits — **Sentinel** matches pattern `payment-null-ref-001` and resolves it in 5 minutes using the recorded fix\n\nThis is Paradigm at full power: every system contributing, every session building on the last, every incident making the next resolution faster.",
+      "content": "## Putting It All Together\n\nYou have learned the five advanced systems individually. Now let's see how they work together in a complete development workflow. Every system has a role, and the handoffs between them create a feedback loop that gets smarter with every session.\n\n## The Full Cycle\n\nHere is the complete Paradigm workflow for a non-trivial task:\n\n### Phase 1: Preflight\n\n```\n1. paradigm_session_recover       → Load previous session context\n2. paradigm_pm_preflight           → Get compliance plan for the task\n3. paradigm_habits_check(preflight) → Verify discovery habits are followed\n4. paradigm_ripple                 → Check impact of planned changes\n5. paradigm_wisdom_context         → Get team knowledge for affected symbols\n6. paradigm_practice_context       → Get habit-aware warnings for symbols\n7. paradigm_session_checkpoint(planning) → Save plan before coding\n```\n\nNotice the layering: session recovery provides continuity, preflight ensures preparation, habits check enforces discovery discipline, ripple and wisdom provide context, practice context adds behavioral awareness, and the checkpoint enables crash recovery.\n\n### Phase 2: Implementation\n\n```\n8. Write code                      → Implement the feature\n   → Post-write hook fires         → Tracks edited files in .pending-review\n   → Post-write advisory           → Reminds about .purpose coverage\n9. Update .purpose files           → Document new/changed symbols\n10. Update portal.yaml             → Add routes and gates (if applicable)\n11. paradigm_session_checkpoint(implementing) → Save progress\n```\n\nThe post-write hook acts as a running tally. Every source file edit is tracked, and periodic reminders keep documentation top of mind. Updating .purpose and portal.yaml during implementation (not after) prevents the stop hook from blocking at the end.\n\n### Phase 3: Validation\n\n```\n12. paradigm_flow_check          → Verify flows are complete\n13. paradigm_aspect_check           → Verify aspect anchors are valid\n14. paradigm_pm_postflight          → Run post-implementation governance\n15. paradigm_habits_check(postflight) → Verify documentation/testing habits\n16. paradigm_session_checkpoint(validating) → Save pre-test state\n```\n\nValidation catches issues before they become stop hook violations. Flow validation ensures multi-step processes are complete. Aspect checks confirm anchors point to real code. Postflight governance catches missing .purpose files and undefined gates.\n\n### Phase 4: Recording\n\n```\n17. paradigm_lore_record            → Record the session's work\n18. paradigm_history_record         → Log implementation to symbol history\n19. paradigm_reindex                → Rebuild the symbol index\n20. paradigm_session_checkpoint(complete) → Mark task complete\n```\n\nRecording preserves institutional knowledge. The lore entry captures what was done and why. History record logs implementation details to individual symbol timelines. Reindexing ensures the symbol index reflects all changes.\n\n### Phase 5: Commit\n\n```\n21. git commit                      → Commit changes\n    → Pre-commit hook fires         → Auto-rebuilds index, stages updated files\n    → Stop hook fires               → Validates all compliance checks\n22. If stop hook blocks             → Fix violations, re-attempt\n23. If stop hook passes             → Session complete\n```\n\nThe commit phase is where enforcement happens. The pre-commit hook ensures the index is fresh. The stop hook validates everything: .purpose coverage, portal.yaml compliance, aspect anchors, lore recording, and pending review freshness.\n\n## How Systems Reinforce Each Other\n\nThe power of the complete workflow is in the feedback loops:\n\n**Sentinel catches what Habits miss.** If an agent skips the `ripple-before-modify` habit and introduces a breaking change, Sentinel records the incident. The practice profile then shows that skipping ripple correlates with incidents — evidence to upgrade the habit severity.\n\n**Lore preserves what Sessions forget.** Session breadcrumbs and checkpoints are ephemeral — they expire after 7 days. Lore entries are permanent. The checkpoint gets you through a crash; the lore entry gets the team through the next 6 months.\n\n**Wisdom surfaces what Lore accumulates.** Lore entries record individual sessions. Wisdom distills patterns across sessions: \"every time we modify #payment-service, check for null references on the refund object.\" Wisdom is lore, refined.\n\n**Hooks enforce what Habits recommend.** Habits at `advisory` severity are suggestions. The stop hook at `block` severity is enforcement. The workflow starts with advice (habits check) and ends with enforcement (stop hook). This graduated approach teaches good behavior before punishing bad behavior.\n\n## Capstone Scenario\n\nImagine you are adding a refund endpoint to a payment system. Here is how the complete workflow plays out:\n\n1. **Session recover** reveals the previous session added the payment processor but did not add refunds\n2. **Preflight** shows you need to check `#payment-service`, `$checkout-flow`, and `^authenticated`\n3. **Habits check** confirms you called ripple and wisdom — discovery habits followed\n4. **Ripple** shows `#payment-service` has 4 downstream dependents\n5. **Wisdom** warns: \"always null-check refund objects — see incident INC-042\"\n6. You implement the refund endpoint with proper null checks\n7. **Post-write hook** tracks 5 edited files in `.pending-review`\n8. You update .purpose with `#refund-handler` and portal.yaml with `^refund-eligible` gate\n9. **Postflight** confirms all gates are declared and flows are valid\n10. **Lore record** captures the session with the decision to require `^refund-eligible`\n11. **Commit** triggers pre-commit (index rebuild) and stop hook (all checks pass)\n12. Three weeks later, a similar null reference hits — **Sentinel** matches pattern `payment-null-ref-001` and resolves it in 5 minutes using the recorded fix\n\nThis is Paradigm at full power: every system contributing, every session building on the last, every incident making the next resolution faster.",
       "keyConcepts": [
         "Five-phase workflow: preflight → implement → validate → record → commit",
         "Session recovery provides continuity between sessions",

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

@@ -607,7 +607,7 @@
     {
       "id": "maestro-team-collab",
       "title": "Maestro: Visible Team Orchestration",
-      "content": "## From Synthesized Summaries to Attributed Conversations\n\nTraditional multi-agent orchestration has a visibility problem. An orchestrator spawns three agents, waits for their responses, synthesizes a summary, and presents it to the human. The human sees one voice \u2014 the orchestrator's \u2014 and loses all nuance from individual agent perspectives. If the architect disagreed with the security agent, you would never know. If the builder had a novel approach, it gets flattened into a consensus view.\n\nThe Maestro model inverts this pattern. Every agent speaks for itself.\n\n## The Maestro Model\n\nMaestro is not a separate system \u2014 it is a behavior pattern for the active Claude Code session. When you ask a complex question that benefits from multiple perspectives, Maestro:\n\n1. **Evaluates expertise** \u2014 Which agents have the highest confidence scores on the relevant symbols?\n2. **Loads ambient context** \u2014 Recent team decisions, journal insights, pending nominations are injected into each agent's prompt via `buildProfileEnrichment()`.\n3. **Spawns subagents** \u2014 Each agent receives its full profile: personality, expertise history, transferable patterns, notebook entries, and the ambient context.\n4. **Presents attributed responses** \u2014 Each agent's response appears with a `[role]` or `[nickname (role)]` prefix. You see exactly who said what.\n5. **Records to Symphony** \u2014 Each contribution is written as a Symphony message, creating a persistent team thread visible in Conductor and the Platform dashboard.\n6. **Learns from feedback** \u2014 At session end, `paradigm_ambient_learn` adjusts each agent's attention threshold based on acceptance/dismissal rates.\n\n## Agent Profiles and Nicknames\n\nEach agent has an `.agent` YAML file in `~/.paradigm/agents/` with:\n\n- **personality** \u2014 style (deliberate/rapid/exploratory/methodical), risk tolerance, verbosity\n- **expertise** \u2014 per-symbol confidence scores, exponential moving average from lore\n- **attention** \u2014 threshold, symbol/path/concept/signal subscriptions\n- **collaboration** \u2014 default stance toward other agents, debate behavior\n- **nomination** \u2014 urgency patterns, communication style\n- **nickname** \u2014 optional display name (e.g., \"George\" for the architect)\n- **benched** \u2014 if true, Maestro skips this agent entirely\n\nThe `nickname` field makes agents feel like team members. Terminal output shows `[George (architect)]` instead of the generic `[architect]`.\n\n## Bench and Activate\n\nNot every agent should speak on every task. The bench system lets you silence noisy agents:\n\n- `paradigm agent bench security` \u2014 security agent stops nominating and is excluded from orchestration\n- `paradigm agent activate security` \u2014 restore to active status\n- `paradigm agent roster` \u2014 see who is active vs benched with stats\n\nBenched agents are skipped in both `paradigm_orchestrate_inline` and the nomination engine's `processEvent`. Their profiles remain intact \u2014 bench is a pause, not a delete.\n\n## Symphony Team Threads\n\nEvery orchestration creates a thread prefixed `thr-orch-`. Maestro writes each agent contribution as a Symphony message from the agent's identity (`{project}/{role}`). This creates:\n\n- **Persistent record** \u2014 The team conversation survives session restarts\n- **Conductor visibility** \u2014 The TeamThreadView shows messages with colored role prefixes\n- **Platform dashboard** \u2014 The Team section displays the same thread in a browser\n- **Recovery context** \u2014 Next session's handoff includes which agents contributed and what they said\n\n## The Neverland Test\n\nNamed after the validation criteria in the spec, the Neverland test tracks whether agent learning actually works across sessions:\n\n- **Sessions 1-3**: Agents accumulate \u2014 touching symbols, recording lore, discovering patterns\n- **Sessions 4-5**: Maestro routes based on learned confidence scores\n- **Sessions 6-10**: Accepted suggestions lower threshold (agent speaks more). Dismissed suggestions raise it (agent speaks less).\n\nMeasurable targets:\n- By session 10, Maestro routes to the right agent >80% of the time\n- Agent acceptance rate improves from ~50% (cold start) to >70%\n\nTrack progress with `paradigm_ambient_neverland` \u2014 returns per-agent stats and overall health status (cold-start \u2192 accumulating \u2192 calibrating \u2192 mature).\n\n## Postflight Learning Loop\n\nThe postflight skill closes the feedback loop after every task:\n\n1. **Step 8b** runs `paradigm_ambient_learn` for each contributing agent \u2014 adjusts attention thresholds based on accept/dismiss rates\n2. Runs `paradigm_ambient_promote` \u2014 auto-promotes high-confidence journal patterns to the agent's notebook\n3. Records contributions via Symphony if not already done during execution\n\nThis ensures every session makes agents incrementally smarter. The handoff skill captures agent performance summaries so the next session inherits this knowledge.\n\n## The Teacher Model\n\nThe learning loop has a quality problem: the nomination engine only sees file paths, never content. Briefs like \"review for consistency\" get dismissed, which raises the agent's threshold, which silences the agent. The system learns to be *silent* instead of *better*.\n\nThe Teacher Model fixes this. Maestro (the active session) acts as a teacher who observes the full session and writes targeted feedback.\n\n### Session Work Log\n\nDuring each session, a running JSONL log at `.paradigm/events/session-log.jsonl` captures:\n- **Agent contributions**: what each agent was asked to do (from orchestration)\n- **User verdicts**: accepted / dismissed / revised, with the reason why\n\nThis is the data Maestro reads at postflight to write meaningful learning feedback.\n\n### Postflight Learning Pass\n\nAt session end, Step 8b reads the session work log and writes journal entries per agent:\n\n- **Accepted** \u2192 `human_feedback` trigger, confidence 0.85, extract the pattern that was confirmed correct\n- **Dismissed** \u2192 `correction_received` trigger, confidence 0.4, explain what was wrong and what to do differently\n- **Revised** \u2192 `correction_received` trigger, confidence 0.65, include the delta between proposal and actual\n\nThese journal entries include `pattern.applies_when` and `pattern.correct_approach` fields \u2014 the exact knowledge that gets promoted to notebooks.\n\n### Training New Behaviors\n\nThe journal \u2192 notebook \u2192 `buildProfileEnrichment` pipeline is also how you teach agents new skills. If you say \"documentor, also update CHANGELOG from now on,\" Maestro writes a journal entry. It promotes to a notebook entry. Next session, that knowledge is in the agent's context. No configuration needed.\n\n## The Documentor Agent\n\nThe 6th core agent. Its sole job: maintain Paradigm metadata files after other agents finish their work.\n\n- Always runs as the **final orchestration stage**\n- Reviews what changed (git diff, session work log)\n- Updates .purpose files, portal.yaml, symbol registrations\n- Uses ONLY `paradigm_purpose_*`, `paradigm_portal_*`, and `paradigm_reindex` MCP tools\n- Never modifies source code\n- Relieves all other agents of Paradigm compliance\n\nThis separation of concerns means architect, builder, security, and reviewer can focus purely on their domain. The documentor handles the bookkeeping.",
+      "content": "## From Synthesized Summaries to Attributed Conversations\n\nTraditional multi-agent orchestration has a visibility problem. An orchestrator spawns three agents, waits for their responses, synthesizes a summary, and presents it to the human. The human sees one voice \u2014 the orchestrator's \u2014 and loses all nuance from individual agent perspectives. If the architect disagreed with the security agent, you would never know. If the builder had a novel approach, it gets flattened into a consensus view.\n\nThe Maestro model inverts this pattern. Every agent speaks for itself.\n\n## The Maestro Model\n\nMaestro is not a separate system \u2014 it is a behavior pattern for the active Claude Code session. When you ask a complex question that benefits from multiple perspectives, Maestro:\n\n1. **Evaluates expertise** \u2014 Which agents have the highest confidence scores on the relevant symbols?\n2. **Loads ambient context** \u2014 Recent team decisions, journal insights, pending nominations are injected into each agent's prompt via `buildProfileEnrichment()`.\n3. **Spawns subagents** \u2014 Each agent receives its full profile: personality, expertise history, transferable patterns, notebook entries, and the ambient context.\n4. **Presents attributed responses** \u2014 Each agent's response appears with a `[role]` or `[nickname (role)]` prefix. You see exactly who said what.\n5. **Records to Symphony** \u2014 Each contribution is written as a Symphony message, creating a persistent team thread visible in Conductor and the Platform dashboard.\n6. **Learns from feedback** \u2014 At session end, `paradigm_ambient_learn` adjusts each agent's attention threshold based on acceptance/dismissal rates.\n\n## Agent Profiles and Nicknames\n\nEach agent has an `.agent` YAML file in `~/.paradigm/agents/` with:\n\n- **personality** \u2014 style (deliberate/rapid/exploratory/methodical), risk tolerance, verbosity\n- **expertise** \u2014 per-symbol confidence scores, exponential moving average from lore\n- **attention** \u2014 threshold, symbol/path/concept/signal subscriptions\n- **collaboration** \u2014 default stance toward other agents, debate behavior\n- **nomination** \u2014 urgency patterns, communication style\n- **nickname** \u2014 optional display name (e.g., \"George\" for the architect)\n- **benched** \u2014 if true, Maestro skips this agent entirely\n\nThe `nickname` field makes agents feel like team members. Terminal output shows `[George (architect)]` instead of the generic `[architect]`.\n\n## Bench and Activate\n\nNot every agent should speak on every task. The bench system lets you silence noisy agents:\n\n- `paradigm agent bench security` \u2014 security agent stops nominating and is excluded from orchestration\n- `paradigm agent activate security` \u2014 restore to active status\n- `paradigm agent roster` \u2014 see who is active vs benched with stats\n\nBenched agents are skipped in both `paradigm_orchestrate_inline` and the nomination engine's `processEvent`. Their profiles remain intact \u2014 bench is a pause, not a delete.\n\n## Symphony Team Threads\n\nEvery orchestration creates a thread prefixed `thr-orch-`. Maestro writes each agent contribution as a Symphony message from the agent's identity (`{project}/{role}`). This creates:\n\n- **Persistent record** \u2014 The team conversation survives session restarts\n- **Conductor visibility** \u2014 The TeamThreadView shows messages with colored role prefixes\n- **Platform dashboard** \u2014 The Team section displays the same thread in a browser\n- **Recovery context** \u2014 Next session's handoff includes which agents contributed and what they said\n\n## The Neverland Test\n\nNamed after the validation criteria in the spec, the Neverland test tracks whether agent learning actually works across sessions:\n\n- **Sessions 1-3**: Agents accumulate \u2014 touching symbols, recording lore, discovering patterns\n- **Sessions 4-5**: Maestro routes based on learned confidence scores\n- **Sessions 6-10**: Accepted suggestions lower threshold (agent speaks more). Dismissed suggestions raise it (agent speaks less).\n\nMeasurable targets:\n- By session 10, Maestro routes to the right agent >80% of the time\n- Agent acceptance rate improves from ~50% (cold start) to >70%\n\nTrack progress with `paradigm_ambient_health` \u2014 returns per-agent stats and overall health status (cold-start \u2192 accumulating \u2192 calibrating \u2192 mature).\n\n## Postflight Learning Loop\n\nThe postflight skill closes the feedback loop after every task:\n\n1. **Step 8b** runs `paradigm_ambient_learn` for each contributing agent \u2014 adjusts attention thresholds based on accept/dismiss rates\n2. Runs `paradigm_ambient_promote` \u2014 auto-promotes high-confidence journal patterns to the agent's notebook\n3. Records contributions via Symphony if not already done during execution\n\nThis ensures every session makes agents incrementally smarter. The handoff skill captures agent performance summaries so the next session inherits this knowledge.\n\n## The Teacher Model\n\nThe learning loop has a quality problem: the nomination engine only sees file paths, never content. Briefs like \"review for consistency\" get dismissed, which raises the agent's threshold, which silences the agent. The system learns to be *silent* instead of *better*.\n\nThe Teacher Model fixes this. Maestro (the active session) acts as a teacher who observes the full session and writes targeted feedback.\n\n### Session Work Log\n\nDuring each session, a running JSONL log at `.paradigm/events/session-log.jsonl` captures:\n- **Agent contributions**: what each agent was asked to do (from orchestration)\n- **User verdicts**: accepted / dismissed / revised, with the reason why\n\nThis is the data Maestro reads at postflight to write meaningful learning feedback.\n\n### Postflight Learning Pass\n\nAt session end, Step 8b reads the session work log and writes journal entries per agent:\n\n- **Accepted** \u2192 `human_feedback` trigger, confidence 0.85, extract the pattern that was confirmed correct\n- **Dismissed** \u2192 `correction_received` trigger, confidence 0.4, explain what was wrong and what to do differently\n- **Revised** \u2192 `correction_received` trigger, confidence 0.65, include the delta between proposal and actual\n\nThese journal entries include `pattern.applies_when` and `pattern.correct_approach` fields \u2014 the exact knowledge that gets promoted to notebooks.\n\n### Training New Behaviors\n\nThe journal \u2192 notebook \u2192 `buildProfileEnrichment` pipeline is also how you teach agents new skills. If you say \"documentor, also update CHANGELOG from now on,\" Maestro writes a journal entry. It promotes to a notebook entry. Next session, that knowledge is in the agent's context. No configuration needed.\n\n## The Documentor Agent\n\nThe 6th core agent. Its sole job: maintain Paradigm metadata files after other agents finish their work.\n\n- Always runs as the **final orchestration stage**\n- Reviews what changed (git diff, session work log)\n- Updates .purpose files, portal.yaml, symbol registrations\n- Uses ONLY `paradigm_purpose_*`, `paradigm_portal_*`, and `paradigm_reindex` MCP tools\n- Never modifies source code\n- Relieves all other agents of Paradigm compliance\n\nThis separation of concerns means architect, builder, security, and reviewer can focus purely on their domain. The documentor handles the bookkeeping.",
       "keyConcepts": [
         "Maestro is a behavior pattern, not a separate system \u2014 the active session decides who to consult",
         "Attributed responses: [nickname (role)] prefix makes agents visible as distinct team members",

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

@@ -388,13 +388,13 @@
       "question": "What should you do before starting the refactor?",
       "choices": {
         "A": "Just continue \u2014 context management is handled automatically",
-        "B": "Call `paradigm_context_check` to see if a handoff is recommended",
+        "B": "Call `paradigm_session_health` to see if a handoff is recommended",
         "C": "Start a new Claude session immediately to get fresh context",
         "D": "Save all files and run `paradigm scan` to rebuild the index",
         "E": "Call `paradigm_session_stats` and if over 100 tool calls, panic"
       },
       "correct": "B",
-      "explanation": "The protocol says to call `paradigm_context_check` periodically (every 10-15 tool calls) during long sessions. At 47 tool calls, you're well overdue for a check. This tool analyzes your context window usage and recommends whether to continue, prepare a handoff, or urgently wrap up. If usage is over 85%, you should prioritize completing your current task and prepare a handoff with `paradigm_handoff_prepare`. Don't just start a new session (C) without preparing a handoff \u2014 you'd lose all context about what was done."
+      "explanation": "The protocol says to call `paradigm_session_health` periodically (every 10-15 tool calls) during long sessions. At 47 tool calls, you're well overdue for a check. This tool analyzes your context window usage and recommends whether to continue, prepare a handoff, or urgently wrap up. If usage is over 85%, you should prioritize completing your current task and prepare a handoff with `paradigm_handoff_prepare`. Don't just start a new session (C) without preparing a handoff \u2014 you'd lose all context about what was done."
     },
     {
       "id": "plsat-027",
@@ -552,14 +552,14 @@
       "scenario": "You're debugging an issue where the `$order-fulfillment` flow is failing at the 'ship order' step. The flow has 6 steps spanning 4 components. You suspect the gate `^warehouse-authorized` is rejecting valid requests.",
       "question": "Which combination of tools gives you the MOST diagnostic information?",
       "choices": {
-        "A": "`paradigm_flow_validate({ flowId: '$order-fulfillment' })` + `paradigm_sentinel_triage({ symbol: '^warehouse-authorized' })`",
+        "A": "`paradigm_flow_check({ flowId: '$order-fulfillment' })` + `paradigm_sentinel_triage({ symbol: '^warehouse-authorized' })`",
         "B": "`paradigm_search({ query: 'warehouse' })` + read all matching files",
         "C": "`paradigm_ripple({ symbol: '$order-fulfillment' })` only",
         "D": "`paradigm_history_context({ symbols: ['$order-fulfillment'] })` only",
         "E": "`paradigm_navigate({ intent: 'find', target: '^warehouse-authorized' })` + read the gate code"
       },
       "correct": "A",
-      "explanation": "The best combination is: (1) `paradigm_flow_validate` checks the flow definition against the codebase \u2014 are all steps implemented, do the gates exist, are signals emitted? This could reveal if the flow definition is out of sync with the code. (2) `paradigm_sentinel_triage` filtered by `^warehouse-authorized` shows if there are incidents or known patterns for this gate failing. Together, these give you structural validation AND operational history. Ripple (C) shows dependencies but not failures. History (D) shows changes but not current errors."
+      "explanation": "The best combination is: (1) `paradigm_flow_check` checks the flow definition against the codebase \u2014 are all steps implemented, do the gates exist, are signals emitted? This could reveal if the flow definition is out of sync with the code. (2) `paradigm_sentinel_triage` filtered by `^warehouse-authorized` shows if there are incidents or known patterns for this gate failing. Together, these give you structural validation AND operational history. Ripple (C) shows dependencies but not failures. History (D) shows changes but not current errors."
     },
     {
       "id": "plsat-038",
@@ -732,14 +732,14 @@
       "scenario": "You want to validate that a specific flow `$checkout-flow` is correctly implemented. The flow has 5 steps, involves 3 gates, and emits 2 signals. You want to verify that all steps have implementations, gates exist in portal.yaml, and signals are actually emitted in the code.",
       "question": "Which MCP tool call gives you this deep implementation check?",
       "choices": {
-        "A": "`paradigm_flow_validate({ flowId: '$checkout-flow' })` \u2014 validates flow definition only",
-        "B": "`paradigm_flow_validate({ flowId: '$checkout-flow', checkImplementation: true })` \u2014 deep check against codebase",
+        "A": "`paradigm_flow_check({ flowId: '$checkout-flow' })` \u2014 validates flow definition only",
+        "B": "`paradigm_flow_check({ flowId: '$checkout-flow', checkImplementation: true })` \u2014 deep check against codebase",
         "C": "`paradigm_purpose_validate()` \u2014 validates all purpose files including flows",
         "D": "`paradigm_ripple({ symbol: '$checkout-flow' })` \u2014 shows flow dependencies",
         "E": "`paradigm_related({ symbol: '$checkout-flow' })` \u2014 shows what's connected to the flow"
       },
       "correct": "B",
-      "explanation": "`paradigm_flow_validate` with `checkImplementation: true` performs a deep validation: it checks that gates exist in portal.yaml, actions are implemented in the codebase, and signals are emitted. Without `checkImplementation`, it only validates the YAML structure (A). `paradigm_purpose_validate` (C) checks structural validity of purpose files but doesn't do the deep codebase cross-reference. `paradigm_ripple` (D) shows what depends on the flow, not whether it's correctly implemented. The `checkImplementation` flag is the key to going from structural validation to implementation verification."
+      "explanation": "`paradigm_flow_check` with `checkImplementation: true` performs a deep validation: it checks that gates exist in portal.yaml, actions are implemented in the codebase, and signals are emitted. Without `checkImplementation`, it only validates the YAML structure (A). `paradigm_purpose_validate` (C) checks structural validity of purpose files but doesn't do the deep codebase cross-reference. `paradigm_ripple` (D) shows what depends on the flow, not whether it's correctly implemented. The `checkImplementation` flag is the key to going from structural validation to implementation verification."
     },
     {
       "id": "plsat-050",

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

@@ -617,13 +617,13 @@
           "question": "What should you do before starting the refactor?",
           "choices": {
             "A": "Just continue \u2014 context management is handled automatically",
-            "B": "Call `paradigm_context_check` to see if a handoff is recommended",
+            "B": "Call `paradigm_session_health` to see if a handoff is recommended",
             "C": "Start a new Claude session immediately to get fresh context",
             "D": "Save all files and run `paradigm scan` to rebuild the index",
             "E": "Call `paradigm_session_stats` and if over 100 tool calls, panic"
           },
           "correct": "B",
-          "explanation": "The protocol says to call `paradigm_context_check` periodically (every 10-15 tool calls) during long sessions. At 47 tool calls, you're well overdue for a check. This tool analyzes your context window usage and recommends whether to continue, prepare a handoff, or urgently wrap up. If usage is over 85%, you should prioritize completing your current task and prepare a handoff with `paradigm_handoff_prepare`. Don't just start a new session (C) without preparing a handoff \u2014 you'd lose all context about what was done."
+          "explanation": "The protocol says to call `paradigm_session_health` periodically (every 10-15 tool calls) during long sessions. At 47 tool calls, you're well overdue for a check. This tool analyzes your context window usage and recommends whether to continue, prepare a handoff, or urgently wrap up. If usage is over 85%, you should prioritize completing your current task and prepare a handoff with `paradigm_handoff_prepare`. Don't just start a new session (C) without preparing a handoff \u2014 you'd lose all context about what was done."
         }
       ]
     },
@@ -847,14 +847,14 @@
           "scenario": "You're debugging an issue where the `$order-fulfillment` flow is failing at the 'ship order' step. The flow has 6 steps spanning 4 components. You suspect the gate `^warehouse-authorized` is rejecting valid requests.",
           "question": "Which combination of tools gives you the MOST diagnostic information?",
           "choices": {
-            "A": "`paradigm_flow_validate({ flowId: '$order-fulfillment' })` + `paradigm_sentinel_triage({ symbol: '^warehouse-authorized' })`",
+            "A": "`paradigm_flow_check({ flowId: '$order-fulfillment' })` + `paradigm_sentinel_triage({ symbol: '^warehouse-authorized' })`",
             "B": "`paradigm_search({ query: 'warehouse' })` + read all matching files",
             "C": "`paradigm_ripple({ symbol: '$order-fulfillment' })` only",
             "D": "`paradigm_history_context({ symbols: ['$order-fulfillment'] })` only",
             "E": "`paradigm_navigate({ intent: 'find', target: '^warehouse-authorized' })` + read the gate code"
           },
           "correct": "A",
-          "explanation": "The best combination is: (1) `paradigm_flow_validate` checks the flow definition against the codebase \u2014 are all steps implemented, do the gates exist, are signals emitted? This could reveal if the flow definition is out of sync with the code. (2) `paradigm_sentinel_triage` filtered by `^warehouse-authorized` shows if there are incidents or known patterns for this gate failing. Together, these give you structural validation AND operational history. Ripple (C) shows dependencies but not failures. History (D) shows changes but not current errors."
+          "explanation": "The best combination is: (1) `paradigm_flow_check` checks the flow definition against the codebase \u2014 are all steps implemented, do the gates exist, are signals emitted? This could reveal if the flow definition is out of sync with the code. (2) `paradigm_sentinel_triage` filtered by `^warehouse-authorized` shows if there are incidents or known patterns for this gate failing. Together, these give you structural validation AND operational history. Ripple (C) shows dependencies but not failures. History (D) shows changes but not current errors."
         }
       ]
     },
@@ -1127,14 +1127,14 @@
           "scenario": "You want to validate that a specific flow `$checkout-flow` is correctly implemented. The flow has 5 steps, involves 3 gates, and emits 2 signals. You want to verify that all steps have implementations, gates exist in portal.yaml, and signals are actually emitted in the code.",
           "question": "Which MCP tool call gives you this deep implementation check?",
           "choices": {
-            "A": "`paradigm_flow_validate({ flowId: '$checkout-flow' })` \u2014 validates flow definition only",
-            "B": "`paradigm_flow_validate({ flowId: '$checkout-flow', checkImplementation: true })` \u2014 deep check against codebase",
+            "A": "`paradigm_flow_check({ flowId: '$checkout-flow' })` \u2014 validates flow definition only",
+            "B": "`paradigm_flow_check({ flowId: '$checkout-flow', checkImplementation: true })` \u2014 deep check against codebase",
             "C": "`paradigm_purpose_validate()` \u2014 validates all purpose files including flows",
             "D": "`paradigm_ripple({ symbol: '$checkout-flow' })` \u2014 shows flow dependencies",
             "E": "`paradigm_related({ symbol: '$checkout-flow' })` \u2014 shows what's connected to the flow"
           },
           "correct": "B",
-          "explanation": "`paradigm_flow_validate` with `checkImplementation: true` performs a deep validation: it checks that gates exist in portal.yaml, actions are implemented in the codebase, and signals are emitted. Without `checkImplementation`, it only validates the YAML structure (A). `paradigm_purpose_validate` (C) checks structural validity of purpose files but doesn't do the deep codebase cross-reference. `paradigm_ripple` (D) shows what depends on the flow, not whether it's correctly implemented. The `checkImplementation` flag is the key to going from structural validation to implementation verification."
+          "explanation": "`paradigm_flow_check` with `checkImplementation: true` performs a deep validation: it checks that gates exist in portal.yaml, actions are implemented in the codebase, and signals are emitted. Without `checkImplementation`, it only validates the YAML structure (A). `paradigm_purpose_validate` (C) checks structural validity of purpose files but doesn't do the deep codebase cross-reference. `paradigm_ripple` (D) shows what depends on the flow, not whether it's correctly implemented. The `checkImplementation` flag is the key to going from structural validation to implementation verification."
         }
       ]
     },
@@ -1348,7 +1348,7 @@
         },
         {
           "id": "plsat-059b",
-          "scenario": "Your project has three flows with these `relatedFlows` references:\n- `$checkout-flow` → `[$payment-flow]`\n- `$payment-flow` → `[$receipt-flow]`\n- `$receipt-flow` → `[$checkout-flow]`\n\nYou run `paradigm_flow_validate({})` to validate all flows.",
+          "scenario": "Your project has three flows with these `relatedFlows` references:\n- `$checkout-flow` → `[$payment-flow]`\n- `$payment-flow` → `[$receipt-flow]`\n- `$receipt-flow` → `[$checkout-flow]`\n\nYou run `paradigm_flow_check({})` to validate all flows.",
           "question": "What will the circular dependency detection report?",
           "choices": {
             "A": "No issues — each flow only references one other flow",
@@ -1458,7 +1458,7 @@
             "E": "Both partial — the agent did some work for each"
           },
           "correct": "B",
-          "explanation": "context-session-awareness checks if paradigm_context_check, paradigm_session_recover, or paradigm_session_checkpoint was called — paradigm_aspect_check does not count. aspect-anchors-valid checks if paradigm_aspect_check was called for touched aspects, which it was. So the first is skipped and the second is followed."
+          "explanation": "context-session-awareness checks if paradigm_session_health, paradigm_session_recover, or paradigm_session_checkpoint was called — paradigm_aspect_check does not count. aspect-anchors-valid checks if paradigm_aspect_check was called for touched aspects, which it was. So the first is skipped and the second is followed."
         }
       ]
     },