@a-company/paradigm 5.37.11 → 6.0.2

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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