@a-company/paradigm 5.38.0 → 6.0.2

package/dist/university-content/quizzes/Q-para-401-mcp-tools-overview.yaml

@@ -0,0 +1,66 @@
+id: Q-para-401-mcp-tools-overview
+title: 'PARA 401: Orchestration — MCP Tools Overview'
+description: 'Quiz for lesson: MCP Tools Overview'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-401
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-401.json
+questions:
+  - id: q1
+    question: 'An agent needs to understand the full dependency tree before modifying #auth-service. Which MCP tool category should it use?'
+    choices:
+      A: Management -- to update the dependencies
+      B: Validation -- to check the dependencies are correct
+      C: Discovery -- specifically paradigm_ripple for dependency analysis
+      D: Knowledge -- to check team wisdom about dependencies
+      E: All categories must be used in sequence
+    correct: C
+    explanation: paradigm_ripple is a Discovery tool that shows what depends on a symbol at multiple depth levels. While you may also want to check Knowledge tools (wisdom) as part of the full workflow, the specific need to understand the dependency tree is served by the Discovery category.
+  - id: q2
+    question: An agent calls paradigm_navigate with intent='context' and task='add webhooks to payment processing'. What does it receive?
+    choices:
+      A: 'Only the file path of #payment-service'
+      B: A list of all symbols in the project
+      C: Relevant files, symbols, and patterns needed to complete the described task
+      D: The source code of all payment-related files
+      E: A diff of recent changes to payment files
+    correct: C
+    explanation: The 'context' intent is task-based discovery. It analyzes the task description and returns all relevant files, symbols, and existing patterns that the agent needs. This is the most comprehensive navigate intent, designed to answer 'what do I need to know to do this?'
+  - id: q3
+    question: Approximately how much more token-efficient is paradigm_navigate compared to reading multiple files to understand a feature?
+    choices:
+      A: About 2x more efficient
+      B: About the same cost
+      C: 5-50x more efficient depending on the number of files
+      D: MCP tools are actually more expensive
+      E: 10,000x more efficient
+    correct: C
+    explanation: A single paradigm_navigate call costs ~200 tokens, while reading even a small file costs ~500 tokens. An agent that reads 10 files (10,000+ tokens) versus calling navigate once (200 tokens) sees a 50x difference. The typical range is 5-20x for single comparisons and up to 50x when replacing multiple file reads.
+  - id: q4
+    question: Which tool should you use to add a new ^admin-only gate to portal.yaml?
+    choices:
+      A: paradigm_purpose_add_gate
+      B: paradigm_portal_add_gate
+      C: paradigm_purpose_add_component
+      D: paradigm_gates_for_route
+      E: paradigm_ripple
+    correct: B
+    explanation: paradigm_portal_add_gate adds gates to portal.yaml, the project-level gate definition file. paradigm_purpose_add_gate adds gates to a specific .purpose file's gates section, which is different. paradigm_gates_for_route suggests which gates a route should have but does not create them.
+  - id: q5
+    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_check
+      C: paradigm_aspect_check
+      D: paradigm_ripple
+      E: paradigm_search
+    correct: C
+    explanation: paradigm_aspect_check is specifically designed to verify that an aspect has valid code anchors. While paradigm_purpose_validate checks .purpose file integrity broadly, paradigm_aspect_check focuses on the anchor requirement that is unique to aspects (~).

package/dist/university-content/quizzes/Q-para-401-multi-agent-coordination.yaml

@@ -0,0 +1,76 @@
+id: Q-para-401-multi-agent-coordination
+title: 'PARA 401: Orchestration — Multi-Agent Coordination'
+description: 'Quiz for lesson: Multi-Agent Coordination'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-401
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-401.json
+questions:
+  - id: q1
+    question: A task involves adding a new API endpoint that handles payment refunds with admin-only access. Which agents should be involved?
+    choices:
+      A: Builder only -- it is just one endpoint
+      B: Architect and builder
+      C: Architect, security, builder, and tester
+      D: Security only -- it involves access control
+      E: Reviewer and tester only
+    correct: C
+    explanation: This task involves architectural design (refund processing flow), security (admin-only access, payment data handling), implementation (the endpoint code), and testing (refund scenarios, gate checks). All four agent types are warranted when a task involves both security and multi-step implementation.
+  - id: q2
+    question: Why does the architect role use the opus model while the builder uses haiku?
+    choices:
+      A: Opus is newer and therefore always better
+      B: Architects need complex reasoning for design decisions; builders need speed for straightforward implementation
+      C: It is arbitrary -- any model works for any role
+      D: Haiku cannot understand architectural concepts
+      E: Opus is required for any task involving more than one file
+    correct: B
+    explanation: Model assignment matches task complexity to capability. Architects need deep reasoning for tradeoff analysis and design decisions (opus). Builders implement already-designed solutions where speed and cost efficiency matter more (haiku). This optimizes both quality and cost. These defaults are configured in .paradigm/agents.yaml and can be changed with paradigm team models.
+  - id: q3-models
+    question: A teammate has just added a new API key for a different model provider. How do they make the new models available for agent roles?
+    choices:
+      A: Delete .paradigm/agents.yaml and re-run paradigm shift
+      B: Run paradigm team models --refresh to re-discover models from the environment
+      C: Manually edit agents.yaml with the new model IDs
+      D: Models are auto-detected on every orchestration call
+      E: Run paradigm scan to rebuild the model index
+    correct: B
+    explanation: paradigm team models --refresh re-discovers available models from your environment (API keys, installed providers). This is the correct way to update the model roster after adding new providers. While you could manually edit agents.yaml (C), the refresh command handles discovery and validation automatically. paradigm shift also sets up models during initial project setup, but --refresh is the targeted command for this scenario.
+  - id: q3
+    question: You have an orchestration plan with 4 stages. Stage 3 (builder) depends on stages 1 and 2. Stage 4 (tester) depends on stage 3. Can stages 1 and 2 run in parallel?
+    choices:
+      A: No -- all stages must run sequentially
+      B: Yes, if they are independent of each other and the plan marks them as canRunParallel
+      C: Only if they use the same model
+      D: Parallel execution is never supported
+      E: Yes, but only if you use Claude Code Teams
+    correct: B
+    explanation: 'Stages that are independent of each other can run in parallel when the orchestration plan marks them as canRunParallel: true. The dependency is what matters -- stages 1 and 2 can run simultaneously if neither depends on the other, and stage 3 waits for both to complete.'
+  - id: q4
+    question: What is the first mode you should call paradigm_orchestrate_inline with, and why?
+    choices:
+      A: mode='execute' to start building immediately
+      B: mode='plan' to see the suggested agents, token estimate, and execution plan before committing
+      C: mode='review' to check existing orchestrations
+      D: mode='plan' is optional and can be skipped
+      E: Either mode works -- the order does not matter
+    correct: B
+    explanation: Always call mode='plan' first. It shows you the suggested agent team, estimated token cost, and stage breakdown. This lets you review and adjust before committing resources. Jumping straight to mode='execute' means you accept the default plan without review.
+  - id: q5
+    question: You want to spawn a single security agent to audit an existing endpoint, not a full multi-agent orchestration. Which tool do you use?
+    choices:
+      A: paradigm_orchestrate_inline with mode='execute' and agents=['security']
+      B: paradigm_agent_prompt with agent='security' and the specific task
+      C: paradigm_wisdom_expert to find a human security expert
+      D: paradigm_sentinel_triage to find security incidents
+      E: paradigm_navigate with intent='find' and target='security'
+    correct: B
+    explanation: paradigm_agent_prompt generates a full prompt for a single agent with the specified task. This is the right tool when you need one focused agent rather than a full orchestration pipeline. You could also use orchestrate_inline with an agents override, but agent_prompt is more direct for single-agent scenarios.

package/dist/university-content/quizzes/Q-para-401-notebooks-permissions.yaml

@@ -0,0 +1,61 @@
+id: Q-para-401-notebooks-permissions
+title: 'PARA 401: Orchestration — Agent Notebooks & Permission Scoping'
+description: 'Quiz for lesson: Agent Notebooks & Permission Scoping'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-401
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-401.json
+questions:
+  - id: Q-401-NP-001
+    question: Where are global notebook entries stored for the architect agent?
+    options:
+      - ~/.paradigm/notebooks/architect/
+      - .paradigm/notebooks/architect/
+      - ~/.paradigm/agents/architect/notebooks/
+      - .paradigm/agents/architect.notebooks
+    correct: 0
+    explanation: Global notebook entries are stored at ~/.paradigm/notebooks/{agent-id}/ and travel across projects.
+  - id: Q-401-NP-002
+    question: 'An agent has permissions.paths.deny: [".paradigm/agents/*"]. What happens if it tries to write to .paradigm/agents/builder.agent?'
+    options:
+      - The write succeeds if there's also a write pattern matching it
+      - The write is flagged as denied — deny patterns always override allow patterns
+      - The write succeeds but triggers an advisory
+      - The agent profile is deleted
+    correct: 1
+    explanation: Deny patterns always override allow patterns. checkPathPermission() checks deny first.
+  - id: Q-401-NP-003
+    question: You want to extract a reusable pattern from lore entry L-2026-03-10-001 into the architect's notebook. Which MCP tool?
+    options:
+      - paradigm_notebook_add with loreEntryId parameter
+      - paradigm_lore_promote with agentId parameter
+      - paradigm_notebook_promote with agentId + loreEntryId
+      - 'paradigm_agent_notebook with action: ''promote'''
+    correct: 2
+    explanation: paradigm_notebook_promote takes agentId + loreEntryId and creates a distilled notebook entry with provenance link.
+  - id: Q-401-NP-004
+    question: 'An architect agent has 3 notebook entries matching #auth-middleware. How does orchestration use them?'
+    options:
+      - They replace the agent's expertise section in the prompt
+      - buildProfileEnrichment() appends a 'Relevant Notebook Entries' section with context + snippet
+      - They are sent as separate tool calls before the main prompt
+      - They override the agent's personality settings
+    correct: 1
+    explanation: buildProfileEnrichment() appends notebook entries (up to 5) with context + truncated snippet to the orchestration prompt.
+  - id: Q-401-NP-005
+    question: A .agent file's integrityHash doesn't match the computed hash. What does this indicate?
+    options:
+      - The file was created before v4.0 and needs migration
+      - The file was modified without going through saveAgentProfile() — possible tampering
+      - The agent's expertise has been updated since the hash was computed
+      - The hash algorithm has changed between versions
+    correct: 1
+    explanation: verifyIntegrity() returns false when the stored hash doesn't match. The hash covers id+role+permissions, so changes to those fields without saveAgentProfile() indicate tampering.

package/dist/university-content/quizzes/Q-para-401-orchestration-workflow.yaml

@@ -0,0 +1,66 @@
+id: Q-para-401-orchestration-workflow
+title: 'PARA 401: Orchestration — Orchestration Workflow'
+description: 'Quiz for lesson: Orchestration Workflow'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-401
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-401.json
+questions:
+  - id: q1
+    question: You call paradigm_orchestrate_inline with mode='plan' and the suggested agents include tester, but you know the project has no test infrastructure yet. What do you do?
+    choices:
+      A: Accept the plan as-is -- the orchestrator knows best
+      B: Override the agents parameter to exclude tester when calling mode='execute'
+      C: Skip the plan step and go straight to mode='execute'
+      D: Cancel the entire orchestration
+      E: Add test infrastructure before proceeding
+    correct: B
+    explanation: The plan is a suggestion, not a mandate. When you disagree with the agent selection (e.g., tester is suggested but there is no test infrastructure), you override the agents parameter in the execute call. The plan step exists precisely to give you this review opportunity.
+  - id: q2
+    question: 'The orchestration plan shows: Stage 1 (architect, no deps), Stage 2 (security, no deps), Stage 3 (builder, depends on 1 and 2). How many total rounds of agent launches do you need?'
+    choices:
+      A: 1 round -- launch all three at once
+      B: 2 rounds -- stages 1 and 2 in parallel, then stage 3
+      C: 3 rounds -- each stage runs separately
+      D: It depends on the provider
+      E: 0 rounds -- the orchestrator launches them automatically
+    correct: B
+    explanation: Stages 1 and 2 have no dependencies, so they can launch in parallel (round 1). Stage 3 depends on both, so it must wait for their results (round 2). This gives 2 rounds total, which is optimal for this dependency graph.
+  - id: q3
+    question: When is the --solo flag appropriate for paradigm team orchestrate?
+    choices:
+      A: When the task involves security review
+      B: When the task affects 5+ files
+      C: When the task is straightforward and does not genuinely need multiple specialized agents
+      D: Always -- solo mode is always better
+      E: Never -- multi-agent is always better
+    correct: C
+    explanation: Solo mode is appropriate for straightforward tasks where orchestration overhead exceeds its value. A simple bug fix or small feature addition often does not benefit from architect-security-builder-tester decomposition. Use --compare to learn which tasks benefit from orchestration.
+  - id: q4
+    question: What happens after all agents complete their stages?
+    choices:
+      A: Changes are automatically merged and committed
+      B: The orchestrator sends a pull request
+      C: You review each agent's output, verify it, and integrate the changes as the final integrator
+      D: The tester agent automatically validates everything
+      E: Results are discarded and you start over
+    correct: C
+    explanation: The orchestrator does not auto-merge. You are the final integrator -- reviewing each agent's output, verifying it makes sense in context, and integrating the changes. This human-in-the-loop step is intentional for quality and safety.
+  - id: q5
+    question: Which task description would produce a better orchestration plan?
+    choices:
+      A: Fix the app
+      B: Make payments work better
+      C: Add Stripe webhook handler for payment.intent.succeeded with idempotency, ^authenticated gate, and !payment-completed signal
+      D: Do something with checkout
+      E: Refactor everything
+    correct: C
+    explanation: Specific task descriptions with clear scope, named symbols, and explicit requirements produce better plans. The orchestrator can identify exact agents needed (security for the gate, builder for implementation) and provide accurate token estimates. Vague descriptions lead to generic, less useful plans.

package/dist/university-content/quizzes/Q-para-401-pm-governance.yaml

@@ -0,0 +1,66 @@
+id: Q-para-401-pm-governance
+title: 'PARA 401: Orchestration — PM Governance'
+description: 'Quiz for lesson: PM Governance'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-401
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-401.json
+questions:
+  - id: q1
+    question: An agent implements a new POST /api/refunds endpoint but does not add it to portal.yaml. What does the PM post-flight check report?
+    choices:
+      A: Nothing -- portal.yaml is optional
+      B: A suggestion to consider adding the endpoint
+      C: An error or warning for portal non-compliance -- the endpoint is unprotected
+      D: It automatically adds the endpoint to portal.yaml
+      E: It deletes the endpoint from the code
+    correct: C
+    explanation: The PM post-flight checks portal compliance by verifying all new endpoints are listed in portal.yaml with appropriate gates. An endpoint missing required gate checks is flagged as a compliance issue. The PM reports but does not auto-fix.
+  - id: q2
+    question: What is the purpose of the PM's pre-flight ripple analysis?
+    choices:
+      A: To automatically cancel dangerous changes
+      B: To map the blast radius and flag fragile dependents before agents start implementing
+      C: To generate unit tests for affected symbols
+      D: To choose which AI model to use
+      E: To update the .purpose files automatically
+    correct: B
+    explanation: The pre-flight ripple analysis maps all direct and indirect dependencies before implementation begins. If fragile symbols are in the blast radius, agents are warned and can take extra precautions. This prevents breaking changes by surfacing risk upfront.
+  - id: q3
+    question: 'A PM post-flight check returns: 2 errors, 1 warning, 3 suggestions. What should you address before committing?'
+    choices:
+      A: Only errors -- they are mandatory
+      B: Errors and warnings -- suggestions are optional
+      C: All six items must be resolved
+      D: None -- post-flight checks are informational only
+      E: Only suggestions -- errors and warnings auto-resolve
+    correct: B
+    explanation: Errors must be fixed before proceeding -- they represent compliance failures. Warnings should be fixed -- they represent best practices that are being violated. Suggestions are optional improvements that represent good practice but are not required.
+  - id: q4
+    question: Which flag enables PM governance on CLI orchestration?
+    choices:
+      A: '--validate'
+      B: '--strict'
+      C: '--pm'
+      D: '--governance'
+      E: '--enforce'
+    correct: C
+    explanation: The --pm flag on paradigm team orchestrate enables the PM governance layer, adding pre-flight checks before the first agent and post-flight checks after the last agent.
+  - id: q5
+    question: Why is PM governance especially valuable for teams working with AI agents?
+    choices:
+      A: AI agents cannot write code without PM approval
+      B: The PM layer replaces the need for human code review
+      C: AI agents may not have deep project familiarity and might skip metadata updates, portal compliance, or wisdom capture
+      D: PM governance makes AI agents run faster
+      E: It is required by Anthropic's terms of service
+    correct: C
+    explanation: AI agents, especially in their first interactions with a project, may not know all the conventions, required metadata updates, or portal requirements. The PM layer acts as a safety net ensuring that Paradigm discipline is maintained regardless of the implementer's familiarity level.

package/dist/university-content/quizzes/Q-para-401-provider-cascade.yaml

@@ -0,0 +1,56 @@
+id: Q-para-401-provider-cascade
+title: 'PARA 401: Orchestration — Provider Cascade'
+description: 'Quiz for lesson: Provider Cascade'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-401
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-401.json
+questions:
+  - id: q1
+    question: You are running in a fresh terminal with only the Claude CLI installed. Which provider will the cascade select?
+    choices:
+      A: claude -- the Anthropic API
+      B: claude-code -- the Task tool
+      C: claude-cli -- spawning CLI processes
+      D: manual -- file-based handoffs
+      E: The cascade will fail with an error
+    correct: C
+    explanation: 'The cascade tries providers in order: claude (needs API key -- not available), claude-code-teams (not available), claude-code (needs Max subscription -- not in this scenario), cursor-cli (not in Cursor -- not available), claude-cli (CLI is installed -- available). It selects claude-cli.'
+  - id: q2
+    question: You set PARADIGM_AGENT_PROVIDER=cursor-cli but you are not running inside Cursor. What happens?
+    choices:
+      A: An error is thrown and orchestration fails
+      B: The cascade falls through to the next available provider
+      C: Cursor is automatically launched
+      D: The manual provider is always used as override
+      E: The setting is ignored entirely
+    correct: B
+    explanation: Setting a preferred provider changes the cascade starting point but does not disable it. If cursor-cli is not available (not in Cursor), the cascade continues to claude-cli, then manual. The fallback chain always works.
+  - id: q3
+    question: Which provider is always available regardless of environment?
+    choices:
+      A: claude (Anthropic API)
+      B: claude-code (Task tool)
+      C: cursor-cli
+      D: manual (file-based handoffs)
+      E: claude-code-teams
+    correct: D
+    explanation: The manual provider writes agent prompts to files for human or tool execution. It requires no API keys, subscriptions, or specific IDE -- just a filesystem. This universal fallback ensures orchestration works in every environment.
+  - id: q4
+    question: You just added a new ANTHROPIC_API_KEY to your environment. What command should you run to update Paradigm's awareness of available models?
+    choices:
+      A: paradigm scan
+      B: paradigm team providers --set claude
+      C: paradigm team models --refresh
+      D: paradigm doctor
+      E: paradigm sync
+    correct: C
+    explanation: paradigm team models --refresh re-discovers available models from all providers. After adding a new API key, this command detects the newly available models and updates the model assignments.

package/dist/university-content/quizzes/Q-para-401-quick-check.yaml

@@ -0,0 +1,46 @@
+id: Q-para-401-quick-check
+title: 'PARA 401: Orchestration — Quick-Check: Ask Before You Build'
+description: 'Quiz for lesson: Quick-Check: Ask Before You Build'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-401
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-401.json
+questions:
+  - id: q1
+    question: You need to rename a CSS class from .btn-primary to .btn-main across 2 files. Your project uses balanced enforcement with orchestration-required set to warn. What do you do?
+    choices:
+      A: Run full orchestration — any change should go through the full pipeline
+      B: Run quick-check — it is a scoped, low-risk change that will likely get GREENLIGHT
+      C: Skip orchestration entirely — CSS changes do not count as "complex tasks"
+      D: Ask the architect to plan the rename first
+      E: Disable orchestration-required for this one task
+    correct: B
+    explanation: A CSS class rename across 2 files is exactly the kind of scoped, low-risk change quick-check is designed for. It will likely GREENLIGHT. Skipping orchestration entirely would trigger the enforcement warning. Running full orchestration would waste tokens on a trivial change. Quick-check gives you the compliance checkmark at minimal cost.
+  - id: q2
+    question: Quick-check returns ESCALATE for your task "add user deletion endpoint." You are short on time and want to build it anyway. What are the consequences?
+    choices:
+      A: Nothing — ESCALATE is just a suggestion
+      B: The build will fail at compile time
+      C: The stop hook will flag that you bypassed an ESCALATE recommendation, and the verdict is recorded for traceability
+      D: Your code will be automatically reverted
+      E: The orchestrator will refuse to run any further tasks
+    correct: C
+    explanation: ESCALATE is a recorded recommendation, not a hard block (unless orchestration-required is set to block in strict enforcement). However, the stop hook flags the bypass, and the verdict is traceable in the session history. A user deletion endpoint likely needs security review and architectural planning — skipping that introduces real risk.
+  - id: q3
+    question: 'During quick-check, Jinx asks: "What if the email service is down when sending password reset?" and the reviewer notes "touches auth, new endpoint, email infra — estimated 4+ files." The verdict is ESCALATE. Which agents would full orchestration likely include?'
+    choices:
+      A: Only builder — the task is clearly defined
+      B: architect (4+ files), security (auth + password reset), builder, tester, compliance (symbols)
+      C: Only security — it is a security task
+      D: All 54 agents to be thorough
+      E: Jinx and reviewer again, but with more tokens
+    correct: B
+    explanation: 'Full orchestration composes the team from trigger patterns: 4+ files triggers architect for multi-file design, auth/password triggers security for review, implementation triggers builder, complexity triggers tester for testing, and compliance runs for symbol planning. This is the value of ESCALATE — it routes you to the right team composition.'

package/dist/university-content/quizzes/Q-para-501-advanced-workflows.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-advanced-workflows
+title: 'PARA 501: Advanced Systems — The Complete Workflow'
+description: 'Quiz for lesson: The Complete Workflow'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: In the complete workflow, why does `paradigm_habits_check(preflight)` run BEFORE `paradigm_ripple` and `paradigm_wisdom_context`?
+    choices:
+      A: To block the session if discovery habits were violated in the previous session
+      B: To verify that the agent intends to call discovery tools — the habit check reminds and tracks, while the actual tools provide the context
+      C: Because habits must always run first regardless of workflow position
+      D: To generate the list of symbols that ripple and wisdom should check
+      E: The order does not matter — they can run in any sequence
+    correct: B
+    explanation: The preflight habits check evaluates whether discovery habits (ripple, navigate, wisdom) are being followed. It runs early to remind and track compliance. The actual MCP tools (ripple, wisdom_context) run after to provide the substantive context. The habit check is about behavioral discipline; the tools are about information gathering.
+  - id: q2
+    question: An agent implements a feature, updates .purpose files, but forgets to record lore before committing. The session modified 5 source files. What sequence of events occurs?
+    choices:
+      A: Pre-commit hook blocks the commit until lore is recorded
+      B: Stop hook blocks, citing missing lore entry → agent records lore → re-attempts commit → stop hook passes
+      C: Commit succeeds but the next session receives a warning about missing lore
+      D: The post-write hook retroactively creates a lore entry from tracked files
+      E: The commit succeeds — lore is enforced by habits, not hooks
+    correct: B
+    explanation: The stop hook checks for lore entries when 3+ source files were modified. With 5 files and no lore entry, it blocks. The agent must then call `paradigm_lore_record` with the session summary, and re-attempt the commit. The pre-commit hook only rebuilds the index — it doesn't check compliance. Lore enforcement lives in the stop hook.
+  - id: q3
+    question: How does Sentinel benefit from the Habits system?
+    choices:
+      A: Sentinel directly calls habit checks during incident recording
+      B: Practice profiles show correlations between skipped habits and incident rates, providing evidence for severity upgrades
+      C: Habits automatically resolve Sentinel incidents when compliance is high
+      D: Sentinel and Habits are independent systems with no interaction
+      E: Habits disable Sentinel checks when compliance is above 90%
+    correct: B
+    explanation: The feedback loop between Habits and Sentinel works through practice profiles. When an agent frequently skips `ripple-before-modify` and the symbols it touches have higher incident rates, the practice profile surfaces this correlation. This provides data-driven evidence to upgrade the habit's severity from advisory to warn or block — closing the loop between behavior and outcomes.
+  - id: q4
+    question: What is the relationship between Lore entries and Session checkpoints?
+    choices:
+      A: They are the same thing — checkpoints are stored as lore entries
+      B: Checkpoints are ephemeral (7-day expiry) for crash recovery; lore entries are permanent for institutional memory
+      C: Lore entries are auto-generated from checkpoints at session end
+      D: Checkpoints replace lore entries in Paradigm v2
+      E: Lore entries expire after 30 days; checkpoints are permanent
+    correct: B
+    explanation: 'Checkpoints and lore serve different purposes with different lifespans. Checkpoints are ephemeral snapshots for crash recovery — they expire after 7 days because their value is immediate continuity. Lore entries are permanent project history — they capture decisions, learnings, and context that remain valuable months or years later. You need both: checkpoints for resilience, lore for memory.'
+  - id: q5
+    question: A team's practice profile shows high compliance across all categories, yet incidents keep occurring in `#payment-service`. What system should they investigate?
+    choices:
+      A: Habits — add more habits targeting the payment service
+      B: Hooks — the stop hook might not be running for payment-related changes
+      C: Sentinel — check `paradigm_sentinel_patterns` and `paradigm_sentinel_stats` for the symbol to identify recurring failure patterns and resolution gaps
+      D: Lore — the payment service lore entries might be inaccurate
+      E: Session Intelligence — breadcrumbs might be losing payment context
+    correct: C
+    explanation: High habit compliance means the behavioral discipline is fine — agents are doing the right things. If incidents persist despite good practices, the issue is likely in the code or architecture, not the process. Sentinel's pattern analysis (`paradigm_sentinel_patterns`) can reveal if the same failure keeps recurring despite resolutions, and `paradigm_sentinel_stats` can show the symbol's incident rate and resolution effectiveness. The answer lives in the incident data, not the compliance data.

package/dist/university-content/quizzes/Q-para-501-aspect-graph-advanced.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-aspect-graph-advanced
+title: 'PARA 501: Advanced Systems — The Aspect Graph at Scale'
+description: 'Quiz for lesson: The Aspect Graph at Scale'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: How many built-in detectors does paradigm_aspect_suggest_scan use, and which of these is NOT one of them?
+    choices:
+      A: 8 built-in detectors; 'database schema' is not one of them
+      B: 6 built-in detectors; 'magic numbers' is not one of them
+      C: 8 built-in detectors; 'rate limits' IS one of them (trick question)
+      D: 10 built-in detectors; 'feature flags' is not one of them
+      E: 5 built-in detectors; 'environment checks' is not one of them
+    correct: A
+    explanation: 'paradigm_aspect_suggest_scan uses 8 built-in detectors: magic numbers, hardcoded strings, rate limits, time values, environment checks, feature flags, regex patterns, and assertion guards. ''Database schema'' is not among them. Custom detectors can be added via .paradigm/aspect-detectors.yaml to extend the detection system.'
+  - id: q2
+    question: 'You want to find all rules that enforce constraints on #payment-service through the aspect graph. Which query approach is most effective?'
+    choices:
+      A: 'paradigm_aspect_search({ query: ''payment rules'' }) to find them by text'
+      B: 'paradigm_aspect_graph({ symbol: ''#payment-service'', hops: 1 }) filtered by ''enforced-by'' edge relation'
+      C: 'paradigm_aspect_heatmap({ limit: 100 }) and manually scan for payment-related aspects'
+      D: 'paradigm_aspect_drift({ aspectId: ''#payment-service'' }) to find stale rules'
+      E: 'paradigm_ripple({ symbol: ''#payment-service'' }) without any graph filtering'
+    correct: B
+    explanation: An edge-filtered graph query at 1 hop with the 'enforced-by' relation is the most direct approach. It returns exactly the aspects that enforce rules on the target component. Search (A) finds by text, not by graph relationship. Heatmap (C) ranks by usage, not by target. Drift (D) checks anchor freshness, not relationships.
+  - id: q3
+    question: Your CI pipeline should fail when aspect anchors have drifted. Which command configuration achieves this?
+    choices:
+      A: paradigm doctor with no flags — drift is always a blocking error
+      B: paradigm doctor --strict — treats drifted anchors as errors that cause a non-zero exit code
+      C: paradigm scan --fix — automatically fixes drifted anchors
+      D: paradigm_aspect_drift with no arguments — checks all aspects and exits non-zero on drift
+      E: paradigm lint --strict — lint checks include drift detection
+    correct: B
+    explanation: paradigm doctor --strict treats warnings (including drifted anchors) as errors, producing a non-zero exit code that fails the CI step. Without --strict, drifted anchors are warnings that do not block. paradigm scan rebuilds the index but does not check drift. paradigm lint checks .purpose file structure, not anchor content hashes.
+  - id: q4
+    question: A new project's aspect search always falls to Tier 3 (fuzzy matching). How do you warm the learning system so common queries use Tier 1?
+    choices:
+      A: Manually edit the search_weights SQLite table to insert mappings
+      B: Run paradigm_reindex with a --warm-search flag
+      C: Run common queries with paradigm_aspect_search, then confirm the best results with paradigm_aspect_confirm for each query
+      D: Wait for 100+ searches to accumulate — Tier 1 learns automatically without confirmation
+      E: Set limits.searchLearningRate to a higher value in config.yaml
+    correct: C
+    explanation: The learning system requires explicit confirmation via paradigm_aspect_confirm. When you search for a term and confirm the best result, the confirmed aspect gets +1.0 weight for that query. After 3-5 confirmations, the weight exceeds the Tier 1 threshold and future queries return instantly. There is no automatic learning without confirmation — the system relies on user feedback to improve.
+  - id: q5
+    question: During a quarterly governance review, the heatmap shows that 30 aspects out of 120 have zero access across all types (search, ripple, navigate, direct). What does this indicate and what should you do?
+    choices:
+      A: These aspects are well-documented and need no changes — zero access means no issues
+      B: Delete all 30 immediately — unused aspects are always stale
+      C: These aspects may be stale, poorly named, or irrelevant — evaluate each for removal, renaming, or consolidation as part of the governance review
+      D: Increase their severity to 'critical' to force agents to access them
+      E: Move them to a separate 'archive' section in the .purpose files
+    correct: C
+    explanation: Zero-access aspects are candidates for review, not automatic deletion. Some may be legitimate but poorly named (rename to improve discoverability). Some may be truly stale with drifted anchors (remove or update). Some may have been superseded by newer aspects (consolidate with supersedes edges). The governance review evaluates each case individually.

package/dist/university-content/quizzes/Q-para-501-aspect-graph-internals.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-aspect-graph-internals
+title: 'PARA 501: Advanced Systems — Aspect Graph Internals'
+description: 'Quiz for lesson: Aspect Graph Internals'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: What is the default maxDepth for recursive ripple in the aspect graph?
+    choices:
+      A: 3 — to keep traversals fast and focused
+      B: 5 — balancing depth of discovery with performance
+      C: 10 — the maximum allowed value
+      D: Unlimited — ripple traverses until minWeight is reached
+      E: 1 — only direct connections are followed by default
+    correct: B
+    explanation: The default maxDepth for recursive ripple is 5, with a maximum configurable value of 10. This default balances discovery depth with performance — at 5 hops, you see a meaningful neighborhood without traversing the entire graph. The minWeight threshold (default 0.1) provides additional pruning by cutting off low-confidence paths before they reach maxDepth.
+  - id: q2
+    question: What happens to search weights when a result is confirmed via paradigm_aspect_confirm?
+    choices:
+      A: The confirmed result gets +0.5 weight and all others are deleted
+      B: The confirmed result gets +1.0 weight and all other results for the same query decay by *0.95
+      C: All results for the query get +1.0 weight to reinforce the entire set
+      D: The confirmed result is permanently pinned and decay is disabled
+      E: The confirmed result replaces all other entries for that query
+    correct: B
+    explanation: The search learning system adds +1.0 to the confirmed result's weight for that query and multiplies all other existing results for the same query by 0.95 (a 5% decay). This self-correcting mechanism lets the best result rise to the top over time while alternatives gradually fade. The decay only applies to aspects that have existing search_weights entries for the query — it does not penalize unrelated aspects.
+  - id: q3
+    question: Which SQLite table stores aspect access frequency for the heatmap tool?
+    choices:
+      A: aspects — in an access_count column
+      B: edges — access frequency is tracked per edge
+      C: search_weights — all access types feed into search weights
+      D: heatmap — with columns for aspect_id, access_type, count, and last_accessed
+      E: anchors — access is tracked per anchor location
+    correct: D
+    explanation: The `heatmap` table stores aspect access frequency with columns for `aspect_id`, `access_type` (search, ripple, navigate, direct), `count`, and `last_accessed`. This dedicated table allows the `paradigm_aspect_heatmap` tool to rank aspects by usage frequency and break down how each aspect is typically discovered — whether through search, ripple analysis, navigation, or direct access.
+  - id: q4
+    question: What is the queue limit for recursive ripple BFS traversal?
+    choices:
+      A: 100 nodes — to keep memory usage minimal
+      B: 500 nodes — a balance between coverage and performance
+      C: 1000 nodes — preventing runaway traversals in dense graphs
+      D: Unlimited — the queue grows until maxDepth is reached
+      E: 10000 nodes — large enough for enterprise-scale graphs
+    correct: C
+    explanation: The BFS queue limit is 1000 nodes. This prevents runaway traversals in densely connected aspect graphs where the number of reachable nodes could grow exponentially with depth. When the queue exceeds 1000 entries, the oldest entries are dropped, ensuring the algorithm completes in bounded time and memory regardless of graph density.
+  - id: q5
+    question: How are aspect edges inferred from existing data during materialization?
+    choices:
+      A: By analyzing import statements in source code files
+      B: From applies-to references with weight 0.5 and origin 'inferred', and from shared lore references with origin 'learned'
+      C: By running static analysis on anchor code blocks
+      D: From git commit history showing which aspects changed together
+      E: Only explicit edges are created — no inference occurs
+    correct: B
+    explanation: The materialization pipeline creates inferred edges in two ways. First, `materializeAspects` generates edges from `applies-to` references with weight 0.5 and origin 'inferred' — when an aspect applies to a component, a relationship edge is created. Second, `inferLoreEdges` scans for aspects sharing lore references and creates edges with origin 'learned' and weight proportional to the overlap. These supplement explicit YAML edges to build a richer graph.