@a-company/paradigm 5.38.0 → 6.0.4

package/dist/university-content/quizzes/Q-para-501-assessment-loops.yaml

@@ -0,0 +1,46 @@
+id: Q-para-501-assessment-loops
+title: 'PARA 501: Advanced Systems — Lore as Unified Project Memory'
+description: 'Quiz for lesson: Lore as Unified Project Memory'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: You have completed a three-session effort to add rate limiting. You want to record a retrospective grouped with other rate-limiting work. What is the correct approach?
+    choices:
+      A: 'Call `paradigm_lore_record` with `type: "retro"`, a body with your reflection, and `tags: ["arc:rate-limiting"]`'
+      B: 'Call `paradigm_assessment_record` with `arc_id: "arc-rate-limiting"` and `type: "retro"`'
+      C: 'Call `paradigm_lore_record` with `type: "milestone"` — completing features is always a milestone'
+      D: Create a separate `.paradigm/assessments/` directory and write the entry manually
+      E: 'Call `paradigm_lore_record` with `type: "agent-session"` — all lore is session-level'
+    correct: A
+    explanation: 'Reflective entries are recorded via `paradigm_lore_record` with the appropriate type and arc tag. A retro with `tags: ["arc:rate-limiting"]` groups it with other entries in that arc. The body field holds the detailed reflection. The assessment tools (B) are deprecated wrappers. Milestones (C) mark significant project events, not feature completions. Agent-session (E) is for automated session records, not deliberate reflections.'
+  - id: q2
+    question: 'A lore entry has `linked_lore: [L-2026-02-10-003, L-2026-02-12-001]` and `linked_commits: [a1b2c3d]`. What does this cross-referencing enable?'
+    choices:
+      A: It automatically updates the linked entries with backlinks
+      B: It creates traceability — readers can drill from the synthesized insight down to the specific sessions and code changes
+      C: It prevents the referenced lore entries from being deleted
+      D: It triggers Sentinel to check those commits for incidents
+      E: It merges the linked entries into a single combined entry
+    correct: B
+    explanation: Cross-references create a traceability chain. A reader encountering an insight entry can follow `linked_lore` to see the full session context, and `linked_commits` to see the exact code changes. This is the core value of linking — each entry adds interpretation to what it references, with links to drill down for evidence.
+  - id: q3
+    question: You want to find every retrospective in the `arc:auth-hardening` arc that mentions `#payment-service`. Which approach is correct?
+    choices:
+      A: 'Call `paradigm_lore_search` with `tag: "arc:auth-hardening"`, `type: "retro"`, and `symbol: "#payment-service"`'
+      B: 'Call `paradigm_assessment_search` with `symbol: "#payment-service"` — it searches the old assessment system'
+      C: 'Call `paradigm_lore_search` with `tags: ["arc:auth-hardening", "retro"]`'
+      D: 'Call `paradigm_search` with `query: "payment retro auth"` — general search covers lore'
+      E: Read every file in `.paradigm/lore/entries/` and filter manually
+    correct: A
+    explanation: '`paradigm_lore_search` supports combining filters: `tag` for arc prefix matching, `type` for entry type, and `symbol` for symbol references. These filters combine (AND logic), so you get only retro entries in the auth-hardening arc that touch the payment service. The assessment tools (B) are deprecated. Using `tags` array (C) uses OR logic, not AND. General search (D) searches the symbol index, not lore content.'

package/dist/university-content/quizzes/Q-para-501-conductor-workspace.yaml

@@ -0,0 +1,46 @@
+id: Q-para-501-conductor-workspace
+title: 'PARA 501: Advanced Systems — Conductor: Visual Mission Control'
+description: 'Quiz for lesson: Conductor: Visual Mission Control'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: During orchestration, the security agent sends an approval-request via Symphony asking to modify portal.yaml. Where would you see and respond to this in Conductor?
+    choices:
+      A: In the terminal session where the agent is running
+      B: In the Symphony thread view — approval-request is a task protocol intent that appears as a message you can approve or reject
+      C: In the agent health dashboard under the security agent's metrics
+      D: In the Sentinel event feed as a security incident
+      E: You cannot — approval requests only work via CLI
+    correct: B
+    explanation: Symphony messages, including task protocol intents like approval-request, appear in Conductor's thread view in real time. The task protocol is designed for human-agent coordination — you see the request, read the context, and respond with approval-response directly in the thread view. This is one of Conductor's key advantages over CLI-only workflows.
+  - id: q2
+    question: You want to work on the frontend and backend of a feature simultaneously with two Claude Code sessions. How would you set this up in Conductor?
+    choices:
+      A: Launch two separate Conductor apps
+      B: Use workspace mode with a split-h or split-v layout preset, launching one terminal session per pane
+      C: Conductor only supports one session at a time
+      D: Use the agent health dashboard to assign work to two agents
+      E: Use Symphony to relay messages between two CLI sessions instead
+    correct: B
+    explanation: Conductor's workspace mode is a tiling window manager for Claude Code sessions. Choose a split layout preset (horizontal or vertical), and each pane gets its own terminal session. Both sessions connect to Symphony, so they can coordinate via inter-agent messaging while you watch both in a single window.
+  - id: q3
+    question: Conductor's ML features (gaze tracking, gesture recognition, voice commands) all run locally via CoreML. Why is this significant?
+    choices:
+      A: CoreML is faster than cloud APIs for all tasks
+      B: It means zero cloud cost, zero data leaving your machine, and zero network latency — critical for a developer tool that sees your code and screen
+      C: Apple requires all macOS apps to use CoreML
+      D: Cloud ML services do not support gaze tracking
+      E: It is not significant — it is just an implementation detail
+    correct: B
+    explanation: For a developer tool that has access to your codebase, screen content, and camera feed, privacy is paramount. Local-only ML means your data never leaves your machine — no cloud processing, no storage, no costs. The zero-latency benefit is a bonus, but the privacy guarantee is the real reason this design choice matters.

package/dist/university-content/quizzes/Q-para-501-habits-practice.yaml

@@ -0,0 +1,56 @@
+id: Q-para-501-habits-practice
+title: 'PARA 501: Advanced Systems — Habits & Practice'
+description: 'Quiz for lesson: Habits & Practice'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: A project wants the `ripple-before-modify` habit to block session completion instead of just advising. How should they configure this?
+    choices:
+      A: 'Delete the seed habit and create a new one with `severity: block`'
+      B: 'Add an override in `.paradigm/habits.yaml` setting `severity: block` for `ripple-before-modify`'
+      C: Edit the seed-habits.json file directly in node_modules
+      D: Create a global override in `~/.paradigm/habits.yaml` — project-level overrides cannot change severity
+      E: Set `PARADIGM_HABIT_SEVERITY=block` environment variable
+    correct: B
+    explanation: Project-level overrides in `.paradigm/habits.yaml` can change any field of a seed habit, including severity. The three-layer merge means project settings override global settings, which override seed defaults. You never edit seed habits directly.
+  - id: q2
+    question: 'An agent''s practice profile shows: discovery compliance 95%, verification 40%, testing 30%. The agent frequently skips `verify-before-done` and `test-new-components`. What does this pattern reveal?'
+    choices:
+      A: The agent is good at exploring but poor at following through — it rushes to finish without validating
+      B: The discovery habits are too easy and should be made harder
+      C: The agent needs more seed habits in the testing category
+      D: This is a healthy pattern — discovery is the most important category
+      E: The verification and testing habits should be disabled since the agent skips them
+    correct: A
+    explanation: High discovery compliance with low verification and testing shows an agent that does good pre-work but doesn't follow through with validation. This is the 'explore well, ship hastily' antipattern. The fix is to upgrade verification and testing habits to `warn` or `block` severity, not to disable them.
+  - id: q3
+    question: The `record-lore-for-significant` habit fires on which trigger and at what threshold?
+    choices:
+      A: '`preflight` — checks if lore was recorded in the previous session'
+      B: '`on-stop` — checks if lore was recorded when 3+ source files were modified'
+      C: '`postflight` — always checks for lore regardless of file count'
+      D: '`on-commit` — requires lore for every commit'
+      E: '`on-stop` — checks if lore was recorded when any files were modified'
+    correct: B
+    explanation: The `record-lore-for-significant` habit triggers `on-stop` (before session end) and uses the `lore-recorded` check type, which fires when 3 or more source files were modified. This threshold captures significant sessions while ignoring trivial edits.
+  - id: q4
+    question: Practice profiles show that skipping `wisdom-before-implement` correlates with a 3x incident rate. What action should the team take?
+    choices:
+      A: Disable the habit since it is not preventing incidents anyway
+      B: Upgrade its severity from `advisory` to `warn` or `block` based on the evidence
+      C: Add more discovery habits to compensate
+      D: The correlation is coincidental — ignore it
+      E: Move the habit from `preflight` to `on-stop` trigger
+    correct: B
+    explanation: Incident correlations provide concrete evidence for severity decisions. A 3x incident rate when skipping wisdom checks is strong evidence that the check prevents real problems. Upgrading to `warn` makes it visible; upgrading to `block` enforces it. This is the feedback loop in action — practice data drives policy changes.

package/dist/university-content/quizzes/Q-para-501-hook-enforcement.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-hook-enforcement
+title: 'PARA 501: Advanced Systems — Hook Enforcement & Automation'
+description: 'Quiz for lesson: Hook Enforcement & Automation'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: You modified 4 source files and updated one .purpose file but did not record a lore entry. The stop hook runs. What happens?
+    choices:
+      A: It passes — the .purpose update satisfies all requirements
+      B: 'It blocks on two violations: .purpose freshness for the other 3 files, and missing lore entry for a 4-file session'
+      C: It blocks only on the missing lore entry — 4 files exceeds the 3-file threshold
+      D: It passes — .purpose coverage is sufficient, lore is optional
+      E: It blocks only on .purpose freshness — the other 3 files need coverage
+    correct: C
+    explanation: The stop hook checks multiple conditions independently. The '.purpose freshness' check passes because you did update a .purpose file (the '2+ source files with 0 paradigm updates' check fails only when zero paradigm files were touched). However, 4 modified source files exceeds the 3-file lore recording threshold, so the missing lore entry causes a block. Whether the other files need .purpose coverage depends on whether they have covering .purpose files in ancestor directories.
+  - id: q2
+    question: The post-write hook just fired after you edited `src/services/payment.ts`. Which of these files would it skip tracking?
+    choices:
+      A: '`src/services/payment.ts` — it tracks this file'
+      B: '`.paradigm/config.yaml` — it skips paradigm directory files'
+      C: '`src/middleware/auth.ts` — it would track this too'
+      D: '`package.json` — it skips .json files'
+      E: Both B and D are skipped
+    correct: E
+    explanation: The post-write hook skips non-source files (.json, .yaml, .md, .lock, .env, .gitignore) and paradigm directories (.paradigm/, .claude/, .cursor/). Both `.paradigm/config.yaml` (paradigm directory) and `package.json` (.json extension) are skipped. Only actual source code files like .ts, .js, .rs, .py are tracked in .pending-review.
+  - id: q3
+    question: What does the pre-commit hook do, and can it block a commit?
+    choices:
+      A: Runs all habit checks and blocks if any severity=block habits are violated
+      B: Validates portal.yaml and blocks if gates are undefined
+      C: Rebuilds the symbol index and stages the updated files — never blocks
+      D: Checks .purpose freshness and blocks if files are stale
+      E: Records a lore entry for the commit — never blocks
+    correct: C
+    explanation: 'The pre-commit hook has a single job: rebuild the symbol index (`paradigm index --quiet`) and stage the rebuilt files (scan-index.json, navigator.yaml, flow-index.json) so they are included in the commit. It always exits 0 — it never blocks. This ensures every commit has a fresh index without manual intervention.'
+  - id: q4
+    question: The stop hook detects that `src/routes/api.ts` contains Express `.post()` calls but `portal.yaml` does not exist. What happens?
+    choices:
+      A: Advisory warning — portal.yaml is recommended but not required
+      B: The hook blocks — route patterns detected without portal.yaml is a violation
+      C: The hook skips this check — portal.yaml is only required for projects that already have one
+      D: The hook creates a minimal portal.yaml automatically
+      E: The hook blocks only if the route handles user data
+    correct: B
+    explanation: The stop hook scans modified files for route declaration patterns (`.get()`, `.post()`, etc.). If route patterns are found and portal.yaml was neither present in the project nor modified during the session, the hook blocks. This enforces the rule that all protected routes must be declared in portal.yaml.
+  - id: q5
+    question: 'You are blocked by the stop hook. The violations list shows: ''stale aspect anchor: src/old/audit.ts no longer exists''. How do you fix this?'
+    choices:
+      A: Delete the aspect from the .purpose file — aspects with stale anchors are invalid
+      B: Create an empty file at `src/old/audit.ts` to satisfy the anchor check
+      C: Update the anchor path in the .purpose file to point to the new location of the audit code
+      D: Run `paradigm_aspect_check` — it auto-fixes stale anchors
+      E: Ignore it — stale anchors are advisory only
+    correct: C
+    explanation: Aspects require valid code anchors. If the file was moved or renamed, update the anchor path in the .purpose file to point to the new location. If the code was deleted entirely, you may need to remove the aspect or create new enforcement code. Creating an empty file (B) is a hack that defeats the purpose. `paradigm_aspect_check` validates but doesn't auto-fix.

package/dist/university-content/quizzes/Q-para-501-lore-system.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-lore-system
+title: 'PARA 501: Advanced Systems — The Lore System'
+description: 'Quiz for lesson: The Lore System'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: You just finished a 40-minute session where you added caching to the API, modifying 5 files and creating 2 new ones. You also decided to use Redis over in-memory caching. Which lore entry type is most appropriate?
+    choices:
+      A: '`paradigm_decision_record` for the Redis choice and skip the lore entry — the implementation rides along'
+      B: '`agent-session` — because this captures the full work session including the decision'
+      C: '`milestone` — because adding caching is a significant achievement'
+      D: '`review` — because you reviewed caching options before choosing'
+      E: '`human-note` — because you want to record the Redis rationale'
+    correct: B
+    explanation: 'When you have both implementation work AND an architectural choice, record an `agent-session` lore entry whose `decisions` field captures the Redis-vs-in-memory rationale; for a *standalone* decision without implementation, use `paradigm_decision_record` (the v6.0 dedicated decision store — the `decision` lore type was removed). Choice A would be correct for a standalone decision, but here you also have 5 modified files and 2 created — that''s session work that needs an `agent-session` entry.'
+  - id: q2
+    question: Where does a lore entry created on February 21, 2026 (the third entry that day) get stored?
+    choices:
+      A: '`.paradigm/lore/L-2026-02-21-003.yaml`'
+      B: '`.paradigm/lore/entries/2026-02-21/L-2026-02-21-003.yaml`'
+      C: '`.paradigm/lore/entries/L-2026-02-21-003.yaml`'
+      D: '`.paradigm/lore/2026/02/21/003.yaml`'
+      E: '`.paradigm/history/lore/2026-02-21-003.yaml`'
+    correct: B
+    explanation: 'Lore uses date-partitioned storage: `.paradigm/lore/entries/{YYYY-MM-DD}/L-{date}-{NNN}.yaml`. The date directory groups entries by day, and the sequence number (003) auto-increments within each day.'
+  - id: q3
+    question: You want to find all lore entries related to the payment system from the last month. Which MCP tool and approach is correct?
+    choices:
+      A: '`paradigm_lore_timeline` with a symbol filter'
+      B: '`paradigm_lore_search` with `symbol: ''#payment-service''` and `dateFrom` set to 30 days ago'
+      C: '`paradigm_search` with `query: ''payment''` and `type: ''lore''`'
+      D: Read all files in `.paradigm/lore/entries/` and grep for 'payment'
+      E: '`paradigm_lore_record` with a search query parameter'
+    correct: B
+    explanation: '`paradigm_lore_search` accepts filters including `symbol` (to match entries that touched a specific symbol) and `dateFrom`/`dateTo` for time ranges. `paradigm_lore_timeline` gives a high-level overview but doesn''t support detailed filtering. `paradigm_search` searches the symbol index, not lore entries.'
+  - id: q4
+    question: An agent modified 2 source files and did not record a lore entry. What happens at session end?
+    choices:
+      A: The stop hook blocks the session — all modifications require lore entries
+      B: Nothing — the 2-file threshold is below the recording trigger
+      C: A warning is issued but the session completes normally
+      D: The system auto-generates a lore entry from the git diff
+      E: The post-write hook retroactively creates a minimal entry
+    correct: B
+    explanation: The lore recording threshold is 3+ modified source files. With only 2 files modified, the session is not considered significant enough to require a lore entry. The stop hook only enforces lore recording when 3 or more source files were modified.
+  - id: q5
+    question: 'A team lead reviews a lore entry and gives it completeness: 3, quality: 5. What does this tell you?'
+    choices:
+      A: The entry is high quality but missing some information about what was done
+      B: The entry is poorly written but covers everything
+      C: The review scores are contradictory and invalid
+      D: The entry should be deleted and re-recorded
+      E: Both scores must be the same for a valid review
+    correct: A
+    explanation: Completeness and quality are independent scores. A completeness of 3 means the entry is missing some details (perhaps decisions weren't documented or files weren't fully listed). A quality of 5 means what IS there is excellent — well-written, accurate, and useful. The review suggests the entry should be enriched with more detail while preserving its good writing.

package/dist/university-content/quizzes/Q-para-501-platform-agent-ui.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-platform-agent-ui
+title: 'PARA 501: Advanced Systems — Platform & Agent-Driven UI'
+description: 'Quiz for lesson: Platform & Agent-Driven UI'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: 'An AI agent calls `paradigm_platform_navigate({ section: ''graph'', symbol: ''#payment-service'' })` while the user is actively typing in the lore section. What happens in the browser?'
+    choices:
+      A: The browser immediately switches to the graph section and selects the node
+      B: The command fails with an error because the user is in a different section
+      C: 'A prompt appears: ''Agent wants to show you #payment-service — [Go there] [Dismiss]'' — the user decides'
+      D: The agent's command is queued and executes when the user next switches sections
+      E: The browser switches to graph but keeps the lore section visible in a split view
+    correct: C
+    explanation: 'When the user is active (last interaction <5s ago), the agent''s navigation creates a pending navigation prompt instead of auto-navigating. The user sees ''Agent wants to show you #payment-service — [Go there] [Dismiss]'' and chooses whether to follow. This is the conflict resolution model: user always wins.'
+  - id: q2
+    question: What is the communication pipeline when an MCP tool like `paradigm_platform_highlight` sends a command to the browser?
+    choices:
+      A: MCP tool → direct WebSocket connection to browser → UI update
+      B: MCP tool → writes to file → browser polls file every 500ms → UI update
+      C: MCP tool → HTTP POST to Platform server → server broadcasts via WebSocket → browser Zustand store → UI update
+      D: MCP tool → writes to scan-index.json → browser watches index file → UI update
+      E: MCP tool → sends message via Symphony mailbox → browser reads mailbox → UI update
+    correct: C
+    explanation: The pipeline is MCP → HTTP POST → WebSocket broadcast → browser. The MCP tool calls the platform-bridge helper which POSTs to /api/platform/agent-command. The server validates the command, updates server-side state (presence, highlights), and broadcasts a typed WebSocket message (e.g., agent:highlight) to all connected browsers. The browser's useAgentEffects hook receives the message and dispatches to the Zustand agentStore.
+  - id: q3
+    question: 'The user clicks the ''Mute'' button in the Platform header. An agent then calls `paradigm_platform_annotate({ type: ''toast'', message: ''Found a bug in #auth'' })`. What happens?'
+    choices:
+      A: The toast appears but with reduced opacity
+      B: 'The command returns `{ annotated: false, reason: ''Agent actions are muted by user'' }` and no toast appears'
+      C: The toast is queued and shown when the user unmutes
+      D: The command throws an error that the agent must handle
+      E: The toast appears regardless — mute only affects navigation, not annotations
+    correct: B
+    explanation: 'When the user mutes agent actions, ALL agent effects are silently discarded — navigate, highlight, annotate, and clear commands all return a response with `reason: ''Agent actions are muted by user''`. The server checks UserStateTracker.isMuted() before broadcasting. The agent can detect this via `paradigm_platform_observe` which returns `{ muted: true }`.'
+  - id: q4
+    question: How does the Platform determine an agent's display color in the header presence indicator?
+    choices:
+      A: Each agent chooses its color when connecting via WebSocket
+      B: Colors are assigned sequentially from a fixed palette (first agent = blue, second = green, etc.)
+      C: The color is deterministically computed from a hash of the agent's Symphony identity string ({project}/{role})
+      D: Colors are stored in .paradigm/config.yaml under platform.agentColors
+      E: All agents share the same color — they're distinguished by name only
+    correct: C
+    explanation: 'Agent colors are deterministic: the AgentPresenceManager computes a hash of the agentId string (e.g., ''a-paradigm/core'') and maps it to one of 8 predefined colors. This means the same agent always gets the same color across sessions, making it recognizable. The identity reuses Symphony''s {project}/{role} pattern.'
+  - id: q5
+    question: An agent wants to understand what the user is currently looking at before deciding what to highlight. Which approach is correct?
+    choices:
+      A: Read the platformStore.ts file to check the activeSection variable
+      B: Call `paradigm_platform_observe()` which returns the current section, selected symbol, theme, mute state, and connected agents
+      C: Call `paradigm_status` which includes the Platform UI state in its output
+      D: Check the browser's localStorage via a Bash command
+      E: 'Call `paradigm_navigate({ intent: ''context'' })` which includes Platform UI state'
+    correct: B
+    explanation: 'paradigm_platform_observe is the dedicated tool for reading UI state. It sends an ''observe'' command to the Platform server, which returns the UserStateTracker''s accumulated state: current section, selected symbol, theme, mute status, connected agents, and optionally active highlights/annotations. This is real-time data from the server, not a file read.'

package/dist/university-content/quizzes/Q-para-501-review-compliance.yaml

@@ -0,0 +1,61 @@
+id: Q-para-501-review-compliance
+title: 'PARA 501: Advanced Systems — Automated Review Pipeline & Compliance Checking'
+description: 'Quiz for lesson: Automated Review Pipeline & Compliance Checking'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: Q-501-RC-001
+    question: paradigm review --ci finds 2 blocking and 3 improvement findings. What's the exit code?
+    options:
+      - Exit code 0 — improvements are non-blocking
+      - Exit code 1 — any blocking findings cause non-zero exit in CI mode
+      - Exit code 2 — one per blocking finding
+      - Exit code 5 — total findings count
+    correct: 1
+    explanation: In CI mode, any blocking findings cause exit code 1. Improvements and notes do not affect the exit code.
+  - id: Q-501-RC-002
+    question: 'A project has no features: section in config.yaml. How many MCP tools are loaded?'
+    options:
+      - Only core tools (~15)
+      - Core + explicitly enabled features
+      - All of them — auto-detection is generous, defaulting to current behavior
+      - None — features must be explicitly configured
+    correct: 2
+    explanation: No features config + generous auto-detection = all tools loaded, matching pre-4.0 behavior for backward compat.
+  - id: Q-501-RC-003
+    question: 'You call paradigm_search with response_format: ''concise''. What fields are returned?'
+    options:
+      - Full results with descriptions, paths, and fuzzy matches
+      - Only { symbol, type } per result — descriptions and secondary data stripped
+      - Only symbol names as a flat array
+      - Compressed binary format
+    correct: 1
+    explanation: Concise mode strips results to { symbol, type } per entry and removes fuzzyMatched, fuzzyNote, suggestions, workspace data.
+  - id: Q-501-RC-004
+    question: An agent needs the graph generation tool but it's in the advanced tier. What does it do?
+    options:
+      - Request an admin to enable it in config.yaml
+      - 'Call paradigm_tool_activate with feature: ''graph'''
+      - Modify the agent's permissions to include graph tools
+      - Restart the session with --enable-graph flag
+    correct: 1
+    explanation: paradigm_tool_activate enables advanced-tier modules for the current session. The tools become available immediately.
+  - id: Q-501-RC-005
+    question: What's the relationship between paradigm review Stage 1 and paradigm_pm_postflight?
+    options:
+      - They are completely independent with different checks
+      - paradigm review calls paradigm_pm_postflight internally
+      - They share the same compliance logic extracted into compliance-checker.ts
+      - paradigm_pm_postflight is deprecated in favor of paradigm review
+    correct: 2
+    explanation: Both use compliance-checker.ts for shared compliance logic — purpose coverage, portal gates, aspect anchors, and broken refs.

package/dist/university-content/quizzes/Q-para-501-sentinel-deep-dive.yaml

@@ -0,0 +1,86 @@
+id: Q-para-501-sentinel-deep-dive
+title: 'PARA 501: Advanced Systems — Sentinel Deep Dive'
+description: 'Quiz for lesson: Sentinel Deep Dive'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: An incident record shows `flowPosition.actual` has 3 entries and `flowPosition.expected` has 5. The `failedAt` field points to the third step. What does this tell you?
+    choices:
+      A: Three out of five flow steps completed successfully before the failure
+      B: The flow is missing 2 step definitions and needs to be updated
+      C: The third step failed, preventing the last 2 steps (including their signals) from executing
+      D: Only the last 2 steps need to be investigated
+      E: The flow validation is broken and should be re-run
+    correct: C
+    explanation: The `actual` array shows what actually executed, `expected` shows what should have. Three steps executed, meaning the first two succeeded and the third (`failedAt`) is where the failure occurred. The remaining 2 expected steps (in `missing`) never ran because execution stopped at the failure point.
+  - id: q2
+    question: 'A failure pattern has confidence scores: timesMatched=20, timesResolved=15, timesRecurred=5. What does a recurrence rate of 25% suggest?'
+    choices:
+      A: The pattern is highly effective and should be trusted
+      B: The resolution strategy may not fully address the root cause — the fix works sometimes but the issue returns
+      C: The pattern's matching criteria are too broad and catching unrelated incidents
+      D: 25% is normal and healthy for any pattern
+      E: The pattern should be deleted and replaced
+    correct: B
+    explanation: timesRecurred (5) out of timesResolved (15) gives a 33% recurrence rate after resolution. This suggests the resolution strategy addresses symptoms but not the root cause. The pattern still has value (it resolves 67% permanently), but the resolution description should be updated with a more thorough fix, or a second pattern created for the recurring variant.
+  - id: q3
+    question: You receive a 2 AM production alert. What is the correct Sentinel-powered response sequence?
+    choices:
+      A: '`paradigm_sentinel_triage` → `paradigm_sentinel_record` → fix → `paradigm_sentinel_resolve`'
+      B: '`paradigm_sentinel_record` → `paradigm_sentinel_patterns` → `paradigm_wisdom_context` → fix → `paradigm_sentinel_resolve`'
+      C: '`paradigm_status` → read all files → find bug → `paradigm_sentinel_record`'
+      D: '`paradigm_sentinel_stats` → identify hotspot → fix → `paradigm_sentinel_resolve`'
+      E: '`paradigm_sentinel_record` → `paradigm_orchestrate_inline` → deploy agents → wait'
+    correct: B
+    explanation: First, record the incident with `paradigm_sentinel_record` to start the clock and capture the error. Then check `paradigm_sentinel_patterns` for known fixes — this could save hours if the failure matches an existing pattern. Then check `paradigm_wisdom_context` for antipatterns on the failing component. Fix with full context, then resolve. Recording first is critical — you can't triage what you haven't recorded.
+  - id: q4
+    question: Sentinel ships with 26 seed patterns. Which pattern source would a team-created pattern from a post-mortem use?
+    choices:
+      A: '`community`'
+      B: '`imported`'
+      C: '`manual`'
+      D: '`suggested`'
+      E: '`seed`'
+    correct: C
+    explanation: 'Patterns have four sources: `manual` (team-created), `suggested` (auto-generated by Sentinel from incident groups), `imported` (from another project), and `community` (shared open-source patterns). A pattern created by the team during a post-mortem is `manual`. The seed patterns that ship with Paradigm use `manual` source as well.'
+  - id: q5
+    question: Two incidents share the same component (#auth-service) and error type (TypeError) but different flows. Sentinel's similarity threshold is 0.6. Will they be grouped?
+    choices:
+      A: Yes — sharing a component and error type exceeds the 0.6 threshold
+      B: No — different flows always prevent grouping
+      C: It depends on what other symbolic context they share — 0.6 means 60% overlap required
+      D: Only if they occurred within the same hour
+      E: Only if a human manually groups them
+    correct: C
+    explanation: The 0.6 similarity threshold means 60% of symbolic context must overlap. Sharing a component and error type provides some overlap, but different flows reduce it. Whether they cross 0.6 depends on other shared context — same gate, same environment, similar error message. Grouping is automatic but similarity-driven, not based on any single field.
+  - id: q6
+    question: How do you connect the Paradigm logger to Sentinel's observability pipeline?
+    choices:
+      A: Replace all `log.component()` calls with `sentinel.log()` calls throughout your codebase
+      B: 'Call `enableSentinel({ endpoint: ''...'' })` once — it registers a SentinelTransport via addTransport with zero changes to existing logging code'
+      C: Configure a `sentinel` key in `.paradigm/config.yaml` and restart the application
+      D: Import SentinelTransport in every file that uses the logger
+      E: Set the `SENTINEL_ENDPOINT` environment variable — the logger auto-detects it
+    correct: B
+    explanation: The SentinelTransport bridge is designed for zero-code-change adoption. Calling `enableSentinel()` once creates a SentinelTransport and registers it with the logger via `addTransport`. From that point, all existing `log.component()`, `log.gate()`, and `log.signal()` calls are automatically forwarded to Sentinel. No changes to individual logging calls are needed.
+  - id: q7
+    question: You want to track API response latency in Sentinel. Which metric type should you use?
+    choices:
+      A: '`counter` — increment it by the latency value on each request'
+      B: '`gauge` — set it to the current response time'
+      C: '`histogram` — record each response time to build a distribution over time'
+      D: '`timer` — Sentinel has a dedicated timer metric type for latency'
+      E: '`counter` with a `latency` label containing the value'
+    correct: C
+    explanation: Histogram is the correct metric type for distributions like response latency. A histogram records individual values and lets you compute percentiles (p50, p95, p99), averages, and distributions over time. A counter only tracks cumulative totals, a gauge only captures point-in-time snapshots, and there is no dedicated timer type — histograms serve that purpose.

package/dist/university-content/quizzes/Q-para-501-session-intelligence.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-session-intelligence
+title: 'PARA 501: Advanced Systems — Session Intelligence'
+description: 'Quiz for lesson: Session Intelligence'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: You have finished implementing a feature and are about to write tests. Which checkpoint phase should you save?
+    choices:
+      A: '`implementing` — you just finished implementing'
+      B: '`validating` — you are transitioning from implementation to validation'
+      C: '`complete` — the feature code is done'
+      D: '`testing` — you are about to test'
+      E: '`planning` — you need to plan the tests first'
+    correct: B
+    explanation: Checkpoint at the phase you are entering, not the one you are leaving. The `validating` phase captures the state after implementation is complete but before tests/review. If the session crashes now, recovery knows implementation is done and testing is the next step. `complete` is only for when everything (including tests) is finished.
+  - id: q2
+    question: What is the maximum number of breadcrumbs stored, and what happens when the limit is reached?
+    choices:
+      A: 100 breadcrumbs, then the file is archived and a new one starts
+      B: 50 breadcrumbs, then the oldest are dropped as new ones are added
+      C: Unlimited — breadcrumbs grow until the session ends
+      D: 50 breadcrumbs, then tracking stops until the next session
+      E: 25 breadcrumbs per phase, resetting at each checkpoint
+    correct: B
+    explanation: Breadcrumbs have a hard cap of 50 entries with auto-rotation — when the 51st breadcrumb is recorded, the oldest one is dropped. This keeps the file small and focused on recent activity while still providing enough trail for meaningful recovery.
+  - id: q3
+    question: A team discovers that 'always validate JWT expiry before refresh' prevents bugs across 4 different projects. What should they do?
+    choices:
+      A: Add the wisdom to each project's `.paradigm/wisdom/` individually
+      B: Use `paradigm_wisdom_promote` to move it to `~/.paradigm/wisdom/` for global scope
+      C: Create a new seed habit for JWT validation
+      D: Add it to the CLAUDE.md file in each project
+      E: Record it as a lore entry in the most recent project
+    correct: B
+    explanation: When wisdom proves valuable across multiple projects, `paradigm_wisdom_promote` copies it from project scope (`.paradigm/wisdom/`) to global scope (`~/.paradigm/wisdom/`). This makes it available automatically in every future session across all projects. Adding it individually (A) or to CLAUDE.md (D) works but doesn't leverage the Global Brain.
+  - id: q4
+    question: Your session is at 82% context usage. What should you do?
+    choices:
+      A: Continue working — 82% is still plenty of room
+      B: Immediately stop and call `paradigm_handoff_prepare` with summary and next steps
+      C: Call `paradigm_session_health` to confirm, then proactively prepare a handoff while finishing current work
+      D: Delete old messages to free up context space
+      E: Save a checkpoint and keep working until 95%
+    correct: C
+    explanation: At 80-85%, the recommendation is proactive handoff preparation. Call `paradigm_session_health` to confirm the recommendation, then prepare the handoff with `paradigm_handoff_prepare` while completing your current task. Waiting until 95% (E) risks running out of context mid-task. The sweet spot is preparing the handoff while you still have room to finish current work cleanly.
+  - id: q5
+    question: A new session starts and the agent calls `paradigm_status`. What happens with session recovery?
+    choices:
+      A: The agent must explicitly call `paradigm_session_recover` — recovery is never automatic
+      B: Recovery data is automatically surfaced on the first Paradigm tool call
+      C: Recovery only works if the previous session saved a checkpoint
+      D: The agent must read `.paradigm/session-checkpoint.json` manually
+      E: Recovery data is shown only if the previous session crashed
+    correct: B
+    explanation: Auto-recovery is triggered on the first Paradigm MCP tool call in a new session — whether that is `paradigm_status`, `paradigm_navigate`, or any other tool. The system surfaces the last checkpoint and recent breadcrumbs without the agent needing to explicitly request recovery. This ensures continuity even if the agent doesn't know to ask.