@a-company/paradigm 5.37.11 → 6.0.2

package/dist/university-content/quizzes/Q-para-301-history-system.yaml

@@ -0,0 +1,56 @@
+id: Q-para-301-history-system
+title: 'PARA 301: Operations — The History System'
+description: 'Quiz for lesson: The History System'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: Which tool do you use to log an implementation change in Paradigm's history system?
+    choices:
+      A: paradigm_history_context
+      B: paradigm_history_record
+      C: paradigm_wisdom_record
+      D: paradigm_history_fragility
+      E: paradigm_history_validate
+    correct: B
+    explanation: paradigm_history_record is the tool for logging implementation events. paradigm_history_context retrieves existing history, paradigm_wisdom_record captures preferences and antipatterns (architectural decisions go through paradigm_decision_record), and paradigm_history_fragility checks stability scores.
+  - id: q2
+    question: 'In one session you fixed a race condition in #checkout-flow, updated the $payment-flow to add retry logic, and added a new #refund-handler component. How would you record these three changes in the history system?'
+    choices:
+      A: One history_record call with all three changes combined
+      B: Three separate history_record calls — a "fix" for the race condition, a "change" for the flow update, and an "add" for the new component
+      C: Only record the new component — fixes and changes are tracked by git
+      D: Use paradigm_lore_record instead — history is deprecated
+      E: Record only the fix — it is the most important change
+    correct: B
+    explanation: 'The history system supports three change types: "add" (new symbols), "change" (modifications), and "fix" (bug fixes). Each change should be recorded separately so that future history queries can filter by type. Using the right type matters — when someone asks "what broke recently?" they want fixes, not additions.'
+  - id: q3
+    question: Why is the history log append-only?
+    choices:
+      A: To save disk space by avoiding updates
+      B: To make the log faster to write
+      C: To maintain a complete, trustworthy timeline that supports fragility analysis
+      D: Because the file format does not support editing
+      E: To prevent unauthorized modifications
+    correct: C
+    explanation: The append-only design ensures a complete timeline of every change. Nothing is deleted or overwritten, which makes the log trustworthy for computing fragility scores and understanding how symbols evolved over time.
+  - id: q4
+    question: 'Before modifying #user-service, which tool should you call to understand its recent changes?'
+    choices:
+      A: paradigm_history_record
+      B: paradigm_search
+      C: paradigm_history_context
+      D: paradigm_navigate
+      E: paradigm_ripple
+    correct: C
+    explanation: paradigm_history_context retrieves the implementation history for specified symbols. It tells you what changed recently, who worked on it, and how stable the symbol has been -- essential context before making modifications.

package/dist/university-content/quizzes/Q-para-301-navigation-system.yaml

@@ -0,0 +1,56 @@
+id: Q-para-301-navigation-system
+title: 'PARA 301: Operations — Codebase Navigation'
+description: 'Quiz for lesson: Codebase Navigation'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: You need to understand all the components involved in the payment system. Which paradigm_navigate intent should you use?
+    choices:
+      A: find
+      B: explore
+      C: context
+      D: search
+      E: browse
+    correct: B
+    explanation: The "explore" intent browses a functional area. Passing "payments" as the target returns all symbols, files, and structure in the payment domain. "find" is for specific symbol lookup, and "context" is for task-based discovery.
+  - id: q2
+    question: Approximately how many tokens does a paradigm_navigate query cost compared to reading a file?
+    choices:
+      A: About the same -- both are ~2000 tokens
+      B: Navigate costs more -- ~5000 tokens vs ~500 for file reads
+      C: Navigate costs ~100-200 tokens vs ~500-2000 for file reads
+      D: Navigate is free and does not count against token limits
+      E: Navigate costs ~1000 tokens vs ~100 for file reads
+    correct: C
+    explanation: MCP navigation queries cost approximately 100-200 tokens, while reading files costs 500-2000+ tokens depending on file size. This 10x efficiency is why the rule is 'MCP for discovery, file reads for implementation.'
+  - id: q3
+    question: How is navigator.yaml generated?
+    choices:
+      A: You write it manually when setting up the project
+      B: It is generated by paradigm scan from .purpose files
+      C: It is downloaded from the Paradigm registry
+      D: It is created by paradigm doctor as a health check artifact
+      E: It is copied from a template during paradigm shift
+    correct: B
+    explanation: navigator.yaml is generated by running paradigm scan, which reads all .purpose files, analyzes the directory structure, and produces a comprehensive structure map. You do not edit it manually -- it is always regenerated from the source .purpose files.
+  - id: q4
+    question: You want to add a search feature to the dashboard and need to know which files to modify. Which navigate intent is most appropriate?
+    choices:
+      A: 'find -- to locate #dashboard'
+      B: explore -- to browse the dashboard area
+      C: context -- with the task description to get all relevant files and patterns
+      D: Any intent will return the same results
+      E: None -- you should read files directly
+    correct: C
+    explanation: The "context" intent is designed for task-based discovery. Describing your task ('add search feature to dashboard') returns all the relevant files, symbols, and patterns you need. This is more comprehensive than find (specific symbol) or explore (area browsing).

package/dist/university-content/quizzes/Q-para-301-operations-review.yaml

@@ -0,0 +1,66 @@
+id: Q-para-301-operations-review
+title: 'PARA 301: Operations — Operational Excellence'
+description: 'Quiz for lesson: Operational Excellence'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: What is the correct order for the Paradigm operational loop?
+    choices:
+      A: Implement, validate, discover, orient
+      B: Orient, discover, assess risk, implement, validate, capture knowledge, monitor context
+      C: Discover, implement, commit, deploy
+      D: Assess risk, implement, test, deploy
+      E: Orient, implement, validate
+    correct: B
+    explanation: 'The full operational loop is: Orient (paradigm_status/session_recover), Discover (wisdom_context/navigate), Assess Risk (ripple/fragility), Implement (code + metadata), Validate (doctor/validate), Capture Knowledge (wisdom_record/history_record), Monitor Context (context_check).'
+  - id: q2
+    question: 'You are starting a new session to add a payment retry feature. #payment-service and $checkout-flow are involved. List the tools you should call in order BEFORE writing any code.'
+    choices:
+      A: paradigm_status, then paradigm_history_record
+      B: paradigm_status, paradigm_wisdom_context for both symbols, paradigm_ripple for both symbols, paradigm_history_fragility for flagged dependents
+      C: paradigm_search for 'payment', then start coding
+      D: paradigm_doctor, then start coding
+      E: paradigm_navigate with find intent, then start coding
+    correct: B
+    explanation: 'Before writing code, you should: (1) orient with paradigm_status, (2) check wisdom for the symbols you will modify, (3) run ripple analysis to see the blast radius, and (4) check fragility of any flagged dependents. This is the orient-discover-assess sequence of the operational loop.'
+  - id: q3
+    question: Which of these is a common operational pitfall in Paradigm projects?
+    choices:
+      A: Running paradigm doctor too frequently
+      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_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.'
+  - id: q4
+    question: What are the signs of a well-operated Paradigm project?
+    choices:
+      A: Minimal use of Paradigm tools to keep things simple
+      B: Accurate .purpose files, portal.yaml reflecting all protected routes, wisdom entries, history records, and context handoffs
+      C: A large number of .purpose files regardless of accuracy
+      D: No wisdom entries because the team never makes mistakes
+      E: Running paradigm scan before every commit
+    correct: B
+    explanation: A well-operated project has accurate (not just numerous) .purpose files, a portal.yaml that reflects reality, wisdom entries that prevent repeated mistakes, history records that enable fragility analysis, and context handoffs that allow seamless multi-session work.
+  - id: q5
+    question: You finished implementing a feature and discovered that directly modifying shared state outside of the intended pattern causes subtle bugs. What should you do before moving to your next task?
+    choices:
+      A: Just fix the bug and move on
+      B: Record an antipattern with paradigm_wisdom_record, record the implementation with paradigm_history_record, and run paradigm doctor
+      C: Only run paradigm doctor
+      D: Only call paradigm_history_record
+      E: Add a comment in the code and move on
+    correct: B
+    explanation: The capture phase of the operational loop involves recording both the antipattern (so future sessions avoid the same mistake) and the implementation history (so fragility tracking stays current), followed by validation to ensure metadata is consistent.

package/dist/university-content/quizzes/Q-para-301-paradigm-shift.yaml

@@ -0,0 +1,46 @@
+id: Q-para-301-paradigm-shift
+title: 'PARA 301: Operations — The paradigm shift Command'
+description: 'Quiz for lesson: The paradigm shift Command'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: You just cloned a teammate's Paradigm project and want to start working. The project already has .paradigm/ and .purpose files. What command should you run?
+    choices:
+      A: paradigm init — to create a fresh .paradigm/ directory
+      B: paradigm shift — it detects the existing setup, migrates if needed, and installs hooks for your environment
+      C: paradigm scan — to rebuild the symbol index
+      D: paradigm sync — to generate your IDE files
+      E: No command needed — the project is already set up
+    correct: B
+    explanation: paradigm shift is the right choice even for existing projects. It detects that .paradigm/ exists, auto-migrates if the project uses an older version, installs Git and IDE hooks for YOUR environment, generates YOUR IDE instruction files, and suggests an agent roster. Just scan or sync alone would miss hooks and migration.
+  - id: q2
+    question: Your CI pipeline needs to initialize Paradigm quickly without scanning thousands of files. Which flag do you use?
+    choices:
+      A: paradigm shift --force — it runs faster by overwriting existing config
+      B: paradigm shift --quick — it skips symbol scanning for faster initialization
+      C: paradigm shift --verify — it verifies instead of scanning
+      D: paradigm init --minimal — it only creates the config file
+      E: paradigm shift --no-hooks — it skips the slowest step
+    correct: B
+    explanation: The --quick flag skips Step 3 (scan & index), which is the most time-consuming step because it reads every .purpose file in the codebase. In CI, you typically just need config, hooks, and IDE files — the full index can be built separately if needed.
+  - id: q3
+    question: 'After upgrading Paradigm from v4.x to v5.x, your project''s .purpose files use the old @feature syntax instead of #component. What should you do?'
+    choices:
+      A: 'Manually find-and-replace all @feature with #component across the codebase'
+      B: Run paradigm shift — Step 2 (auto-migrate) detects the version gap and applies breaking-change migrations
+      C: Delete .paradigm/ and start over with paradigm init
+      D: Run paradigm doctor to identify the issues, then fix them one by one
+      E: Ignore it — old syntax still works in v5.x
+    correct: B
+    explanation: paradigm shift's Step 2 (auto-migrate) exists for exactly this scenario. It detects that your project uses older conventions and applies the necessary migrations automatically. Manual find-and-replace risks missing files or misformatting YAML. Deleting .paradigm/ loses custom configuration. The old syntax does NOT work in v5.x — the symbol system changed.

package/dist/university-content/quizzes/Q-para-301-protocols.yaml

@@ -0,0 +1,56 @@
+id: Q-para-301-protocols
+title: 'PARA 301: Operations — Protocols — Repeatable Patterns'
+description: 'Quiz for lesson: Protocols — Repeatable Patterns'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: What is the PRIMARY purpose of Paradigm protocols?
+    choices:
+      A: To enforce coding standards through automated linting
+      B: To provide step-by-step implementation patterns that save agents from re-exploring codebases
+      C: To track all changes made to the codebase in a history log
+      D: To generate code automatically from templates
+      E: To replace .purpose files with more detailed documentation
+    correct: B
+    explanation: Protocols are repeatable implementation patterns with exact file references. Their primary value is saving AI agents from spending thousands of tokens exploring a codebase to reverse-engineer patterns that are the same every time. They do not enforce linting (A), track history (C), generate code (D), or replace .purpose files (E).
+  - id: q2
+    question: When should an agent call paradigm_protocol_search?
+    choices:
+      A: After completing a task to verify the work matches a known pattern
+      B: Before implementing a task, to check if a repeatable pattern already exists
+      C: Only when the user explicitly asks for protocol guidance
+      D: During reindex to validate protocol references
+      E: When recording lore to check for protocol suggestions
+    correct: B
+    explanation: paradigm_protocol_search is the agent's first stop before exploring the codebase. When receiving a task like 'add a Settings page,' the agent searches for a matching protocol BEFORE spending tokens on exploration. If a match exists, the steps and exemplar provide everything needed. After completion (A) is when you record or refresh, not search.
+  - id: q3
+    question: When are protocols recorded?
+    choices:
+      A: Before starting work, to plan the implementation steps
+      B: During implementation, as each step is completed
+      C: After completing work, capturing the steps that were actually followed
+      D: During reindex, by analyzing git history
+      E: Only by project maintainers, never by AI agents
+    correct: C
+    explanation: 'Protocols are captured AFTER completing work, not before. This ensures the steps reflect what actually works, not what was planned. Two paths lead to recording: agent-initiated (calling paradigm_protocol_record with the steps followed) and lore-prompted (the lore_record response includes a protocol_suggestion hint when it detects repeatable patterns).'
+  - id: q4
+    question: A protocol's status is 'stale'. What does this mean?
+    choices:
+      A: The protocol has a syntax error in its YAML
+      B: The protocol's exemplar file has been modified since the protocol was last verified
+      C: The protocol has never been used by any agent
+      D: The protocol references files that no longer exist
+      E: The protocol was recorded more than 30 days ago
+    correct: B
+    explanation: A 'stale' status means the protocol's exemplar or referenced files have been modified since last_verified — the protocol's steps might no longer match the actual code patterns. 'Broken' (D) means referenced files are missing entirely. Stale protocols still work but should be reviewed and refreshed after successful use.

package/dist/university-content/quizzes/Q-para-301-ripple-analysis.yaml

@@ -0,0 +1,56 @@
+id: Q-para-301-ripple-analysis
+title: 'PARA 301: Operations — Ripple Analysis'
+description: 'Quiz for lesson: Ripple Analysis'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: What is the default depth for paradigm_ripple analysis?
+    choices:
+      A: 1 level
+      B: 2 levels
+      C: 3 levels
+      D: 5 levels
+      E: Unlimited
+    correct: B
+    explanation: The default depth is 2, which shows direct dependents and their dependents. You can increase to 3-5 for large refactors, but higher depths return more results and cost more tokens.
+  - id: q2
+    question: 'You are planning to refactor #auth-middleware. What should you call FIRST?'
+    choices:
+      A: paradigm_history_record to log the planned change
+      B: 'paradigm_ripple to see what depends on #auth-middleware'
+      C: paradigm_decision_record to capture the decision
+      D: paradigm_purpose_validate to check file integrity
+      E: paradigm_search to find the symbol
+    correct: B
+    explanation: 'Before modifying any symbol, the first step is paradigm_ripple to understand the full dependency tree. This tells you everything that depends on #auth-middleware, so you know the blast radius of your refactor.'
+  - id: q3
+    question: 'Ripple analysis reveals that your change to #user-service affects a fragile symbol #notification-handler (depth 2). What is the recommended approach?'
+    choices:
+      A: Ignore the fragility since it is an indirect dependency
+      B: Cancel the change entirely
+      C: Add extra safeguards, consider breaking the change into smaller increments, and test thoroughly
+      D: 'Only modify #user-service at depth 1 and skip depth 2'
+      E: Increase the ripple depth to 5 to find more dependencies
+    correct: C
+    explanation: When ripple analysis reveals that your change affects fragile symbols, the recommended approach is to add safeguards, break the change into smaller pieces, and test thoroughly. Fragile indirect dependencies deserve extra caution, not ignoring or canceling.
+  - id: q4
+    question: What types of relationships does paradigm_ripple track?
+    choices:
+      A: Only JavaScript import statements
+      B: Only component references
+      C: Component references, flow steps, gate protections, and signal listeners
+      D: Only file-level dependencies
+      E: Only git blame information
+    correct: C
+    explanation: 'Ripple analysis tracks semantic dependencies across all symbol types: which components reference the symbol, which flows include it as a step, which gates protect endpoints that use it, and which signals it emits that other components listen to.'

package/dist/university-content/quizzes/Q-para-301-sentinel-observability.yaml

@@ -0,0 +1,46 @@
+id: Q-para-301-sentinel-observability
+title: 'PARA 301: Operations — Sentinel & Observability'
+description: 'Quiz for lesson: Sentinel & Observability'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: What distinguishes Paradigm Sentinel from a generic error logging system?
+    choices:
+      A: It only logs errors from the Paradigm CLI
+      B: It maps runtime errors to Paradigm symbols and matches them against known failure patterns
+      C: It replaces console.error entirely
+      D: It only works in development environments
+      E: It sends all errors to Anthropic for analysis
+    correct: B
+    explanation: 'Sentinel''s key differentiator is symbol-aware error tracking. It maps errors back to #components, $flows, ^gates, and !signals, and matches incidents against defined failure patterns to suggest resolutions.'
+  - id: q2
+    question: Which of the following is NOT a valid Sentinel resolution strategy?
+    choices:
+      A: rollback
+      B: config-change
+      C: auto-deploy
+      D: investigate
+      E: scale-up
+    correct: C
+    explanation: 'Sentinel supports 10 resolution strategies: retry, fallback, fix-data, fix-code, rollback, config-change, scale-up, investigate, ignore, and escalate. ''auto-deploy'' is not a strategy — Sentinel suggests actions for humans to take, not automated deployments.'
+  - id: q3
+    question: 'You want to see all open incidents affecting #payment-service in production. Which tool and parameters do you use?'
+    choices:
+      A: paradigm_sentinel_show with incidentId
+      B: paradigm_sentinel_triage with symbol=#payment-service, status=open, environment=production
+      C: paradigm_sentinel_stats with symbol=#payment-service
+      D: paradigm_sentinel_patterns with symbol=#payment-service
+      E: paradigm_search with query='payment errors'
+    correct: B
+    explanation: 'paradigm_sentinel_triage is the filtering tool for viewing incidents. You can combine symbol, status, and environment filters to get exactly the incidents you need -- in this case, open incidents for #payment-service in production.'

package/dist/university-content/quizzes/Q-para-301-sync-and-maintenance.yaml

@@ -0,0 +1,46 @@
+id: Q-para-301-sync-and-maintenance
+title: 'PARA 301: Operations — Sync & Maintenance'
+description: 'Quiz for lesson: Sync & Maintenance'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: What is the difference between paradigm sync and paradigm scan?
+    choices:
+      A: They are the same command with different aliases
+      B: sync is a light reconciliation; scan is a full rebuild of the index and navigator.yaml
+      C: sync works on portal.yaml; scan works on .purpose files
+      D: sync runs locally; scan runs in the cloud
+      E: sync is for JavaScript projects; scan is for Rust projects
+    correct: B
+    explanation: paradigm sync is a lightweight operation that detects drift between metadata and code. paradigm scan is a heavier full rebuild that re-reads every .purpose file, rebuilds the symbol graph, and regenerates navigator.yaml.
+  - id: q2
+    question: You just added a new POST /api/invoices endpoint that requires authentication. What Paradigm files need updating?
+    choices:
+      A: Only the .purpose file for the invoices module
+      B: Only portal.yaml with the route and gates
+      C: Both the .purpose file (component registration) and portal.yaml (route with ^gates)
+      D: Only navigator.yaml
+      E: No Paradigm files need updating for API endpoints
+    correct: C
+    explanation: 'Adding a protected endpoint requires two updates: registering the component in the nearest .purpose file, and adding the route with its required gates to portal.yaml. The AI Maintenance Protocol requires both.'
+  - id: q3
+    question: Why is stale Paradigm metadata considered worse than no metadata?
+    choices:
+      A: It takes up more disk space
+      B: It causes compilation errors
+      C: It actively misleads AI agents, produces incorrect ripple analysis, and generates false positives in doctor
+      D: It slows down the Paradigm CLI
+      E: It prevents git commits
+    correct: C
+    explanation: Stale metadata is actively harmful because AI agents trust it for navigation, ripple analysis uses it for dependency graphs, and doctor validates against it. If the metadata does not match reality, all of these tools produce wrong results, which is worse than having no metadata at all.

package/dist/university-content/quizzes/Q-para-301-wisdom-system.yaml

@@ -0,0 +1,56 @@
+id: Q-para-301-wisdom-system
+title: 'PARA 301: Operations — Team Wisdom'
+description: 'Quiz for lesson: Team Wisdom'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: What are the three types of team wisdom in Paradigm?
+    choices:
+      A: Patterns, templates, examples
+      B: Preferences, antipatterns, decisions
+      C: Rules, guidelines, standards
+      D: Documentation, comments, readmes
+      E: Tests, benchmarks, audits
+    correct: B
+    explanation: 'Paradigm''s wisdom system has three types: preferences (how we do things), antipatterns (what not to do and what to do instead), and decisions (architectural choices with rationale).'
+  - id: q2
+    question: You just spent an hour debugging an issue caused by calling the Stripe API directly from a component. What should you do?
+    choices:
+      A: Fix the bug and move on
+      B: Record a wisdom antipattern with paradigm_wisdom_record documenting the mistake and the correct approach
+      C: Add a comment in the code
+      D: Send an email to the team
+      E: Record a preference using paradigm_history_record
+    correct: B
+    explanation: When you discover a recurring mistake pattern, you should record it as an antipattern using paradigm_wisdom_record. This captures the description of what went wrong, why it is problematic, and the correct alternative -- making it available to all future sessions and team members.
+  - id: q3
+    question: Which tool tells you who on the team is the expert for a specific symbol?
+    choices:
+      A: paradigm_wisdom_context
+      B: paradigm_history_context
+      C: paradigm_wisdom_expert
+      D: paradigm_search
+      E: paradigm_navigate
+    correct: C
+    explanation: paradigm_wisdom_expert finds the human experts who have the most knowledge about specific symbols or areas. It uses contribution history and ownership data to identify who to consult.
+  - id: q4
+    question: What is the correct timing for calling paradigm_wisdom_context?
+    choices:
+      A: After deploying to production
+      B: Only when you encounter a bug
+      C: Before making changes to symbols, to learn existing conventions and avoid known pitfalls
+      D: Only during code review
+      E: Once per week during sprint planning
+    correct: C
+    explanation: paradigm_wisdom_context should be called before making changes to symbols. It retrieves preferences, antipatterns, and decisions relevant to the symbols you are about to modify, helping you avoid known mistakes and follow established patterns.

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

@@ -0,0 +1,66 @@
+id: Q-para-401-agent-identity
+title: 'PARA 401: Orchestration — Agent Identity & Expertise Profiles'
+description: 'Quiz for lesson: Agent Identity & Expertise Profiles'
+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 run `paradigm agent create architect --global`. Where is the file stored?
+    choices:
+      A: In the project's .paradigm/agents/architect.agent
+      B: In ~/.paradigm/agents/architect.agent
+      C: In .paradigm/agents.yaml as a new entry
+      D: In ~/.paradigm/score/agents/architect.agent
+      E: In the project's .paradigm/config.yaml under agents section
+    correct: B
+    explanation: The --global flag stores the .agent file in ~/.paradigm/agents/, the global scope that travels across projects. Without --global, it would go in the project's .paradigm/agents/ directory.
+  - id: q2
+    question: Both ~/.paradigm/agents/builder.agent and .paradigm/agents/builder.agent exist with different defaultModel. Which one wins?
+    choices:
+      A: The global one (~/.paradigm/agents/) always takes priority
+      B: The one with the newer 'updated' timestamp wins
+      C: Project-level .paradigm/agents/builder.agent takes priority
+      D: agents.yaml overrides both .agent files
+      E: An error is raised for the conflict
+    correct: C
+    explanation: 'Merge priority is: project .agent > global .agent > agents.yaml. Project-level overrides exist specifically so a project can customize model preferences or focus areas without changing the global identity.'
+  - id: q3
+    question: 'An agent records lore with confidence: 0.8 touching #auth-middleware. The agent''s existing expertise on that symbol is confidence: 0.9, sessions: 10. What''s the new confidence?'
+    choices:
+      A: 0.85 (simple average)
+      B: '0.87 (exponential moving average: 0.7 * 0.9 + 0.3 * 0.8)'
+      C: 0.80 (new value replaces old)
+      D: 0.90 (existing value preserved)
+      E: 0.88 (weighted by session count)
+    correct: B
+    explanation: 'Expertise uses exponential moving average with alpha=0.3: new = 0.7 * old + 0.3 * new_observation. So 0.7 * 0.9 + 0.3 * 0.8 = 0.63 + 0.24 = 0.87. This balances stability (70% old) with responsiveness to new data (30% new).'
+  - id: q4
+    question: 'You want to find which agent is best qualified to modify #payment-service. Which MCP tool do you call?'
+    choices:
+      A: paradigm_agent_list and manually compare expertise arrays
+      B: paradigm_agent_get with the symbol name
+      C: 'paradigm_agent_expertise with symbol: "#payment-service"'
+      D: 'paradigm_search with query: "payment-service agents"'
+      E: paradigm_orchestrate_inline with the task description
+    correct: C
+    explanation: paradigm_agent_expertise takes a symbol and returns all agents with expertise on that symbol, ranked by confidence score. This is the purpose-built tool for symbol-to-agent routing, costing only ~100 tokens.
+  - id: q5
+    question: A project has agents.yaml with 5 agents but no .agent files. What happens during orchestration?
+    choices:
+      A: 'An error: .agent files are required for orchestration'
+      B: agents.yaml is ignored and default agents are used
+      C: Empty .agent files are auto-created for each agent
+      D: Everything works exactly as before — .agent files are a pure overlay
+      E: Orchestration runs but warns about missing profiles
+    correct: D
+    explanation: .agent files are a pure overlay. No files = no enrichment, same behavior as pre-3.47.0. The system is fully backward compatible — agents.yaml continues to work unchanged, and .agent profiles only add capabilities when present.

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

@@ -0,0 +1,46 @@
+id: Q-para-401-agent-interop
+title: 'PARA 401: Orchestration — Agent Interoperability'
+description: 'Quiz for lesson: Agent Interoperability'
+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 new AI agent is spawned in isolation to implement a feature. What is the most token-efficient orientation sequence?
+    choices:
+      A: Read all .purpose files in the project
+      B: Read AGENTS.md, call paradigm_session_recover, call paradigm_navigate with context intent
+      C: Read package.json, then explore the src/ directory
+      D: Call paradigm_search for every symbol type
+      E: Read CLAUDE.md, then read every file in .paradigm/
+    correct: B
+    explanation: 'The Fresh Context Principle: AGENTS.md provides instructions and conventions, paradigm_session_recover provides previous session context, and paradigm_navigate with context intent provides task-relevant files. Total cost: ~500 tokens. Reading all .purpose files or exploring directories would cost thousands of tokens for the same information.'
+  - id: q2
+    question: What is the key difference between AGENTS.md and llms.txt?
+    choices:
+      A: AGENTS.md is for Claude, llms.txt is for other LLMs
+      B: AGENTS.md contains instructions (how to behave), llms.txt contains facts (what exists)
+      C: llms.txt replaces AGENTS.md in newer projects
+      D: AGENTS.md is human-readable, llms.txt is machine-only
+      E: They contain identical information in different formats
+    correct: B
+    explanation: AGENTS.md is prescriptive — it tells agents what tools to use, what conventions to follow, and what workflow to observe. llms.txt is descriptive — it tells agents what symbols exist, what flows are defined, and how the project is structured. Both serve distinct purposes and can coexist.
+  - id: q3
+    question: Why do enhanced MCP tool descriptions include token cost estimates?
+    choices:
+      A: To bill agents for tool usage
+      B: To enforce budget limits on agents
+      C: So agents can make informed cost/benefit decisions when choosing between tools and file reads
+      D: Token costs are required by the MCP specification
+      E: To discourage agents from using expensive tools
+    correct: C
+    explanation: Token cost estimates enable agents to evaluate tool selection before calling. An agent deciding between paradigm_search (~150 tokens) and reading 5 files (~2500 tokens) can make an informed cost/benefit decision. The goal is efficiency, not restriction.