@a-company/paradigm 5.38.0 → 6.0.2

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.

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

@@ -0,0 +1,56 @@
+id: Q-para-401-agent-roles
+title: 'PARA 401: Orchestration — Agent Roles & Facets'
+description: 'Quiz for lesson: Agent Roles & Facets'
+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 about to add a payment refund feature that touches 5 files including auth middleware. The orchestrator composes a team. Which agents would you expect to see, and why?
+    choices:
+      A: Only builder — it is an implementation task
+      B: architect (5 files = multi-file design), security (auth middleware), builder (implementation), tester (testing), compliance (symbol planning)
+      C: Only architect and builder — the others are optional
+      D: All 54+ agents are always activated for every task
+      E: Only security — payment features are a security concern
+    correct: B
+    explanation: 'The orchestrator uses trigger patterns: 5 files triggers the architect for upfront design, auth middleware triggers security for review, implementation triggers builder, the complexity triggers tester for testing, and compliance runs for symbol planning on orchestrated tasks. This is how the "right team for the task" is composed automatically.'
+  - id: q2
+    question: 'After building a new feature, the compliance agent''s report shows: "3 components created, 1 aspect defined. Blocking: 2 components missing aspects (1:1 ratio violated)." What do you do?'
+    choices:
+      A: Ignore the report — aspects are optional metadata
+      B: Delete the 2 components to make the ratio work
+      C: Add aspects to the 2 uncovered components — define what rules, constraints, or configuration each component enforces
+      D: Reduce the aspect count to 0 so the ratio is consistently zero
+      E: Ask the architect to redesign the feature with fewer components
+    correct: C
+    explanation: The compliance agent enforces a 1:1 component-to-aspect ratio because every component should have at least one documented rule, constraint, or configuration. Adding aspects is the correct fix — it forces you to think about what rules govern each component. If a component truly has no rules, it may be too small to be its own component.
+  - id: q3
+    question: 'The reviewer runs Stage 1 (Spec Compliance) and finds that #checkout-form is not registered in any .purpose file. What happens?'
+    choices:
+      A: The reviewer proceeds to Stage 2 and includes the missing registration as a note
+      B: The reviewer stops immediately, reports a blocking finding, and hands back to the builder without Stage 2
+      C: The reviewer auto-creates the .purpose entry and continues
+      D: The reviewer skips both stages and approves with a warning
+      E: The reviewer asks the compliance agent to fix it
+    correct: B
+    explanation: 'The two-stage protocol is a hard gate: Stage 1 failure means immediate stop. There is no point reviewing code quality of spec-noncompliant code. The builder must fix the spec issue first, then resubmit. This ensures Paradigm metadata is always in sync with code before quality review begins.'
+  - id: q4
+    question: Your project is a React web app. After running paradigm shift, the roster includes architect, builder, reviewer, security, tester, documentor, ftux, advocate, compliance, plus accessibility and performance specialists. A teammate's Python ML project has a different roster. Why?
+    choices:
+      A: paradigm shift uses random selection
+      B: Each project type gets a tailored roster — web apps get accessibility/performance specialists, ML projects get data pipeline/model evaluation specialists
+      C: The Python project is missing agents and needs manual configuration
+      D: All projects get the same roster but with different model assignments
+      E: The difference is because of different Paradigm versions
+    correct: B
+    explanation: paradigm shift auto-detects project type from markers (package.json = web/node, requirements.txt = Python, etc.) and selects specialized agents that match. The core team appears in every roster, but specialized and ecosystem agents vary. A web app gets accessibility and performance; an ML project gets data pipeline and model evaluation.

package/dist/university-content/quizzes/Q-para-401-commit-conventions.yaml

@@ -0,0 +1,56 @@
+id: Q-para-401-commit-conventions
+title: 'PARA 401: Orchestration — Commit Conventions'
+description: 'Quiz for lesson: Commit Conventions'
+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: What is the purpose of the 'Symbols:' trailer in a Paradigm commit message?
+    choices:
+      A: It is purely decorative for human readers
+      B: It is parsed by the post-commit hook to automatically create paradigm_history_record entries
+      C: It triggers a deployment pipeline
+      D: It notifies symbol owners via email
+      E: It is required by git but has no Paradigm-specific purpose
+    correct: B
+    explanation: 'The Symbols: trailer is machine-readable. The post-commit hook parses it to automatically call paradigm_history_record with the commit hash, affected symbols, and description. This bridges git history with Paradigm''s history system.'
+  - id: q2
+    question: 'A commit has type ''fix'' and a Symbols: trailer listing #payment-service. What history record is created?'
+    choices:
+      A: 'type: rollback, intent: fix'
+      B: 'type: implement, intent: fix'
+      C: 'type: refactor, intent: fix'
+      D: 'type: implement, intent: feature'
+      E: No history record -- fix commits are not tracked
+    correct: B
+    explanation: A 'fix' commit type maps to history type 'implement' with intent 'fix'. This is distinct from 'feat' (implement/feature) and 'refactor' (refactor/refactor). The fix intent contributes to the fix-to-feature ratio used in fragility scoring.
+  - id: q3
+    question: Which of the following is a correctly formatted Paradigm commit subject line?
+    choices:
+      A: Added Apple Pay support to payments
+      B: 'feat(#payment-form): add Apple Pay support'
+      C: 'FEAT: payment-form Apple Pay'
+      D: '#payment-form feat: add Apple Pay'
+      E: 'feat(payment-form): add Apple Pay support'
+    correct: B
+    explanation: 'The correct format is type(#symbol): description. Option B follows this exactly: ''feat'' type, ''#payment-form'' symbol with the # prefix, and a concise description. Option E is missing the # prefix on the symbol.'
+  - id: q4
+    question: 'A developer writes a commit with a body referencing ^authenticated and !order-placed but forgets the Symbols: trailer. What is the impact?'
+    choices:
+      A: The commit is rejected by git
+      B: The symbols in the body are automatically parsed instead
+      C: The commit succeeds as a git commit but is NOT automatically tracked in Paradigm's history system
+      D: The post-commit hook will fail with an error
+      E: paradigm doctor will retroactively add the trailer
+    correct: C
+    explanation: 'Without the Symbols: trailer, the post-commit hook has nothing to parse, so no automatic paradigm_history_record entry is created. The commit is valid in git but invisible to Paradigm''s history, fragility, and wisdom systems. The body references are for human readers only.'

package/dist/university-content/quizzes/Q-para-401-mastery-review.yaml

@@ -0,0 +1,66 @@
+id: Q-para-401-mastery-review
+title: 'PARA 401: Orchestration — Framework Mastery'
+description: 'Quiz for lesson: Framework Mastery'
+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 developer consistently updates .purpose files, runs doctor before committing, and records wisdom after debugging -- but does not use orchestration for complex tasks. What is their mastery level?
+    choices:
+      A: Beginner -- they are missing orchestration
+      B: Practitioner -- they follow the operational loop but have not internalized the full framework
+      C: Master -- operational excellence is sufficient
+      D: Expert -- they have surpassed the mastery framework
+      E: Cannot be determined from this description
+    correct: B
+    explanation: A practitioner follows the operational loop consistently (Phase 3) but has not yet internalized Phase 4 (orchestrated complexity). They are effective but have room to grow in multi-agent coordination and automated governance.
+  - id: q2
+    question: You are starting a brand new Paradigm project. What is the correct initialization sequence?
+    choices:
+      A: Write code first, then add .purpose files
+      B: paradigm shift, define symbols in .purpose files, set up portal.yaml, configure agents.yaml
+      C: paradigm scan, then paradigm doctor
+      D: Create portal.yaml first, then .purpose files, then paradigm shift
+      E: Install all MCP tools, then start coding
+    correct: B
+    explanation: 'Project initialization follows a specific sequence: paradigm shift creates the .paradigm directory structure, then you define symbols in .purpose files, set up portal.yaml for gates, and configure agent facets. The foundation must exist before the operational tools have anything to work with.'
+  - id: q3
+    question: 'The ''self-reinforcing flywheel'' means that skipping steps in the Paradigm workflow causes:'
+    choices:
+      A: Immediate build failures
+      B: Gradual degradation of navigation accuracy, fragility analysis, and team wisdom
+      C: No impact -- each step is independent
+      D: Only affects the developer who skipped the step
+      E: The project must be reinitialized
+    correct: B
+    explanation: 'Paradigm''s tools feed each other: .purpose files enable navigation, commit trailers feed history, history enables fragility analysis, wisdom prevents repeated mistakes. Skipping any step degrades downstream tools. The effect is gradual but cumulative -- stale metadata leads to unreliable navigation, missing history leads to inaccurate fragility scores, uncaptured wisdom leads to repeated mistakes.'
+  - id: q4
+    question: 'You face a complex task: ''Add multi-tenant support with per-tenant billing, admin dashboard, and tenant isolation gates.'' In which order should you proceed?'
+    choices:
+      A: Start coding immediately and figure it out as you go
+      B: paradigm_orchestrate_inline (plan) -> review agent team -> paradigm_orchestrate_inline (execute) -> launch agents by stage -> PM post-flight
+      C: paradigm_search for 'tenant' -> read all matching files -> start implementing
+      D: paradigm_decision_record the architecture choice -> then implement
+      E: paradigm doctor -> paradigm scan -> start implementing
+    correct: B
+    explanation: 'This is a complex multi-faceted task (5+ files, security + implementation + architecture). The correct approach is: plan the orchestration to get the right agent team, review and adjust, execute to get prompts, launch agents according to the stage plan, and run PM post-flight to verify compliance. This is the full Phase 4 workflow.'
+  - id: q5
+    question: What is the fundamental difference between a Paradigm master and a Paradigm practitioner?
+    choices:
+      A: Masters know more tools
+      B: Masters have used Paradigm for longer
+      C: Masters have internalized the workflows as habits -- the question triggers the tool automatically
+      D: Masters only use the CLI while practitioners use MCP tools
+      E: Masters do not need to update .purpose files
+    correct: C
+    explanation: The distinction is habit, not knowledge. Both masters and practitioners know the tools. The master has internalized the framework so deeply that reaching for paradigm_ripple before a modification is reflexive, not deliberate. The question ('what depends on this?') triggers the tool automatically.