@a-company/paradigm 5.38.0 → 6.0.4

package/dist/university-content/quizzes/Q-para-301-doctor-and-validation.yaml

@@ -0,0 +1,66 @@
+id: Q-para-301-doctor-and-validation
+title: 'PARA 301: Operations — Doctor & Validation'
+description: 'Quiz for lesson: Doctor & Validation'
+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 of the following is NOT checked by paradigm doctor?
+    choices:
+      A: Purpose file YAML validity
+      B: Aspect anchor existence
+      C: Portal.yaml gate usage
+      D: JavaScript syntax errors in source code
+      E: Orphaned symbol detection
+    correct: D
+    explanation: 'paradigm doctor validates Paradigm metadata: .purpose files, portal.yaml, aspect anchors, and cross-references. It does not check source code syntax -- that is the job of your language''s compiler or linter.'
+  - id: q2
+    question: An aspect ~rate-limited has an anchor pointing to src/middleware/rate-limit.ts:10-25, but that file was recently renamed. What will paradigm doctor report?
+    choices:
+      A: Nothing -- it only checks YAML syntax
+      B: A warning about unused gates
+      C: An error because the anchor points to a file that no longer exists
+      D: It will automatically update the anchor
+      E: A suggestion to create the file
+    correct: C
+    explanation: Paradigm doctor verifies that aspect anchors point to files and line ranges that actually exist. If the file was renamed, the anchor is broken and doctor will report an error, prompting you to update the anchor.
+  - id: q3
+    question: When is the best time to run paradigm doctor?
+    choices:
+      A: Only during initial project setup
+      B: After major changes and before committing
+      C: Only when errors occur in production
+      D: Once per quarter
+      E: Only when adding new .purpose files
+    correct: B
+    explanation: paradigm doctor should be run after major changes (adding features, refactoring, renaming symbols) and before committing. Many teams also integrate it into pre-commit hooks or CI pipelines to catch metadata drift early.
+  - id: q4
+    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
+      C: Only that the flow has at least three steps
+      D: That the flow has been tested in production
+      E: Only that gate names match portal.yaml
+    correct: B
+    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
+    question: 'A .purpose file contains: `description: "Handles order processing [NEEDS CLARIFICATION: should cancelled orders trigger refunds?]"`. How do `paradigm doctor` and `paradigm_purpose_validate` treat this marker?'
+    choices:
+      A: As an error that blocks validation and must be fixed immediately
+      B: As a warning that surfaces during checks but does not block validation
+      C: They ignore it completely -- it is just text in a description field
+      D: As an info message that only appears in verbose mode
+      E: As a fatal error that prevents the .purpose file from being parsed
+    correct: B
+    explanation: 'Clarification markers (`[NEEDS CLARIFICATION: ...]`) are treated as warnings, not errors. Both `paradigm doctor` and `paradigm_purpose_validate` scan description fields for this exact pattern and report matches as warnings. They surface during health checks to remind the team of unresolved design questions, but they do not block validation or break builds. Resolve them before shipping.'

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

@@ -0,0 +1,46 @@
+id: Q-para-301-enforcement-levels
+title: 'PARA 301: Operations — Enforcement Levels'
+description: 'Quiz for lesson: Enforcement Levels'
+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: Your team is building a healthcare claims processing system that requires audit trails. A new developer joins and asks which enforcement level to use. What do you recommend?
+    choices:
+      A: Minimal — let the new developer learn without friction first
+      B: Balanced — it catches most issues without being too strict
+      C: Strict — healthcare is a regulated domain where every change must be documented and traceable
+      D: Minimal with lore-required overridden to block — just the audit trail matters
+      E: No enforcement — the team should self-police
+    correct: C
+    explanation: Healthcare is a regulated domain where compliance is not optional. Strict enforcement ensures every change has purpose files, portal gates, lore records, and passing drift checks — exactly the traceability an audit requires. The new developer should work within these constraints from day one rather than building habits that strict mode would later break.
+  - id: q2
+    question: Your project uses balanced enforcement but your team never records lore entries, causing constant warnings. What is the best fix?
+    choices:
+      A: Switch to minimal enforcement to silence all warnings
+      B: Override lore-required to off in config.yaml — your team does not need lore yet
+      C: Override lore-required to block — force the team to comply
+      D: Delete the enforcement section from config.yaml entirely
+      E: Ignore the warnings — they are just advisory
+    correct: B
+    explanation: Per-check overrides exist for exactly this situation. If your team is not ready for lore tracking, override lore-required to off rather than downgrading the entire enforcement level. This keeps all other balanced checks active while silencing the one that does not match your current workflow. You can re-enable it later when the team is ready.
+  - id: q3
+    question: A stop hook blocks your commit with "missing .purpose file for src/payments/". You are on balanced enforcement. What happened?
+    choices:
+      A: purpose-exists check failed — the .purpose file has a syntax error
+      B: purpose-coverage check blocked — you modified files in src/payments/ but that directory has no .purpose file
+      C: portal-gates check failed — src/payments/ has unprotected routes
+      D: purpose-freshness check failed — the .purpose file exists but is stale
+      E: aspect-anchors check failed — aspects in src/payments/ have broken anchors
+    correct: B
+    explanation: 'On balanced enforcement, purpose-coverage is the only check set to block (besides habits-blocking). The error message says "missing .purpose file" which means the directory lacks one entirely — that is purpose-coverage, not purpose-exists (which checks that referenced files exist) or purpose-freshness (which checks staleness). Fix: create a .purpose file in src/payments/ describing its components.'

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

@@ -0,0 +1,46 @@
+id: Q-para-301-fragility-tracking
+title: 'PARA 301: Operations — Fragility & Stability'
+description: 'Quiz for lesson: Fragility & Stability'
+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 factors does Paradigm's fragility analysis consider when computing stability scores?
+    choices:
+      A: Only the number of lines of code
+      B: Change frequency, rollback count, fix-to-feature ratio, and recency of changes
+      C: Only how many rollbacks have occurred
+      D: The number of developers who have modified the symbol
+      E: Test coverage percentage
+    correct: B
+    explanation: 'Fragility analysis considers multiple factors: how frequently the symbol changes, how many rollbacks occurred, the ratio of fixes to features (high fix ratio suggests instability), and how recently changes were made.'
+  - id: q2
+    question: 'You are about to modify #billing-engine, which paradigm_history_fragility reports as fragile. What should you do FIRST?'
+    choices:
+      A: Skip the change entirely
+      B: Refactor the symbol to improve stability
+      C: Read its full history and check team wisdom to understand why it is unstable
+      D: Delete the symbol and start fresh
+      E: Increase the stability score manually
+    correct: C
+    explanation: Before modifying a fragile symbol, you should first understand why it is fragile by reading its history (paradigm_history_context) and checking team wisdom (paradigm_wisdom_context). This context helps you avoid repeating past mistakes.
+  - id: q3
+    question: A symbol has a high count of 'refactor' type events in its history. What might this indicate?
+    choices:
+      A: The symbol is well-maintained and actively improved
+      B: The symbol has excellent test coverage
+      C: Unclear requirements, poor initial design, or a component doing too much
+      D: The symbol is ready for production
+      E: The development team is very productive
+    correct: C
+    explanation: Frequent refactors often indicate underlying issues -- unclear requirements that keep changing, a poor initial design that needs constant adjustment, or a component that has grown beyond its original scope. The fragility system surfaces these patterns for root cause analysis.

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.