@a-company/paradigm 5.37.11 → 6.0.2

package/dist/university-content/quizzes/Q-para-501-advanced-workflows.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-advanced-workflows
+title: 'PARA 501: Advanced Systems — The Complete Workflow'
+description: 'Quiz for lesson: The Complete Workflow'
+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: In the complete workflow, why does `paradigm_habits_check(preflight)` run BEFORE `paradigm_ripple` and `paradigm_wisdom_context`?
+    choices:
+      A: To block the session if discovery habits were violated in the previous session
+      B: To verify that the agent intends to call discovery tools — the habit check reminds and tracks, while the actual tools provide the context
+      C: Because habits must always run first regardless of workflow position
+      D: To generate the list of symbols that ripple and wisdom should check
+      E: The order does not matter — they can run in any sequence
+    correct: B
+    explanation: The preflight habits check evaluates whether discovery habits (ripple, navigate, wisdom) are being followed. It runs early to remind and track compliance. The actual MCP tools (ripple, wisdom_context) run after to provide the substantive context. The habit check is about behavioral discipline; the tools are about information gathering.
+  - id: q2
+    question: An agent implements a feature, updates .purpose files, but forgets to record lore before committing. The session modified 5 source files. What sequence of events occurs?
+    choices:
+      A: Pre-commit hook blocks the commit until lore is recorded
+      B: Stop hook blocks, citing missing lore entry → agent records lore → re-attempts commit → stop hook passes
+      C: Commit succeeds but the next session receives a warning about missing lore
+      D: The post-write hook retroactively creates a lore entry from tracked files
+      E: The commit succeeds — lore is enforced by habits, not hooks
+    correct: B
+    explanation: The stop hook checks for lore entries when 3+ source files were modified. With 5 files and no lore entry, it blocks. The agent must then call `paradigm_lore_record` with the session summary, and re-attempt the commit. The pre-commit hook only rebuilds the index — it doesn't check compliance. Lore enforcement lives in the stop hook.
+  - id: q3
+    question: How does Sentinel benefit from the Habits system?
+    choices:
+      A: Sentinel directly calls habit checks during incident recording
+      B: Practice profiles show correlations between skipped habits and incident rates, providing evidence for severity upgrades
+      C: Habits automatically resolve Sentinel incidents when compliance is high
+      D: Sentinel and Habits are independent systems with no interaction
+      E: Habits disable Sentinel checks when compliance is above 90%
+    correct: B
+    explanation: The feedback loop between Habits and Sentinel works through practice profiles. When an agent frequently skips `ripple-before-modify` and the symbols it touches have higher incident rates, the practice profile surfaces this correlation. This provides data-driven evidence to upgrade the habit's severity from advisory to warn or block — closing the loop between behavior and outcomes.
+  - id: q4
+    question: What is the relationship between Lore entries and Session checkpoints?
+    choices:
+      A: They are the same thing — checkpoints are stored as lore entries
+      B: Checkpoints are ephemeral (7-day expiry) for crash recovery; lore entries are permanent for institutional memory
+      C: Lore entries are auto-generated from checkpoints at session end
+      D: Checkpoints replace lore entries in Paradigm v2
+      E: Lore entries expire after 30 days; checkpoints are permanent
+    correct: B
+    explanation: 'Checkpoints and lore serve different purposes with different lifespans. Checkpoints are ephemeral snapshots for crash recovery — they expire after 7 days because their value is immediate continuity. Lore entries are permanent project history — they capture decisions, learnings, and context that remain valuable months or years later. You need both: checkpoints for resilience, lore for memory.'
+  - id: q5
+    question: A team's practice profile shows high compliance across all categories, yet incidents keep occurring in `#payment-service`. What system should they investigate?
+    choices:
+      A: Habits — add more habits targeting the payment service
+      B: Hooks — the stop hook might not be running for payment-related changes
+      C: Sentinel — check `paradigm_sentinel_patterns` and `paradigm_sentinel_stats` for the symbol to identify recurring failure patterns and resolution gaps
+      D: Lore — the payment service lore entries might be inaccurate
+      E: Session Intelligence — breadcrumbs might be losing payment context
+    correct: C
+    explanation: High habit compliance means the behavioral discipline is fine — agents are doing the right things. If incidents persist despite good practices, the issue is likely in the code or architecture, not the process. Sentinel's pattern analysis (`paradigm_sentinel_patterns`) can reveal if the same failure keeps recurring despite resolutions, and `paradigm_sentinel_stats` can show the symbol's incident rate and resolution effectiveness. The answer lives in the incident data, not the compliance data.

package/dist/university-content/quizzes/Q-para-501-aspect-graph-advanced.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-aspect-graph-advanced
+title: 'PARA 501: Advanced Systems — The Aspect Graph at Scale'
+description: 'Quiz for lesson: The Aspect Graph at Scale'
+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: How many built-in detectors does paradigm_aspect_suggest_scan use, and which of these is NOT one of them?
+    choices:
+      A: 8 built-in detectors; 'database schema' is not one of them
+      B: 6 built-in detectors; 'magic numbers' is not one of them
+      C: 8 built-in detectors; 'rate limits' IS one of them (trick question)
+      D: 10 built-in detectors; 'feature flags' is not one of them
+      E: 5 built-in detectors; 'environment checks' is not one of them
+    correct: A
+    explanation: 'paradigm_aspect_suggest_scan uses 8 built-in detectors: magic numbers, hardcoded strings, rate limits, time values, environment checks, feature flags, regex patterns, and assertion guards. ''Database schema'' is not among them. Custom detectors can be added via .paradigm/aspect-detectors.yaml to extend the detection system.'
+  - id: q2
+    question: 'You want to find all rules that enforce constraints on #payment-service through the aspect graph. Which query approach is most effective?'
+    choices:
+      A: 'paradigm_aspect_search({ query: ''payment rules'' }) to find them by text'
+      B: 'paradigm_aspect_graph({ symbol: ''#payment-service'', hops: 1 }) filtered by ''enforced-by'' edge relation'
+      C: 'paradigm_aspect_heatmap({ limit: 100 }) and manually scan for payment-related aspects'
+      D: 'paradigm_aspect_drift({ aspectId: ''#payment-service'' }) to find stale rules'
+      E: 'paradigm_ripple({ symbol: ''#payment-service'' }) without any graph filtering'
+    correct: B
+    explanation: An edge-filtered graph query at 1 hop with the 'enforced-by' relation is the most direct approach. It returns exactly the aspects that enforce rules on the target component. Search (A) finds by text, not by graph relationship. Heatmap (C) ranks by usage, not by target. Drift (D) checks anchor freshness, not relationships.
+  - id: q3
+    question: Your CI pipeline should fail when aspect anchors have drifted. Which command configuration achieves this?
+    choices:
+      A: paradigm doctor with no flags — drift is always a blocking error
+      B: paradigm doctor --strict — treats drifted anchors as errors that cause a non-zero exit code
+      C: paradigm scan --fix — automatically fixes drifted anchors
+      D: paradigm_aspect_drift with no arguments — checks all aspects and exits non-zero on drift
+      E: paradigm lint --strict — lint checks include drift detection
+    correct: B
+    explanation: paradigm doctor --strict treats warnings (including drifted anchors) as errors, producing a non-zero exit code that fails the CI step. Without --strict, drifted anchors are warnings that do not block. paradigm scan rebuilds the index but does not check drift. paradigm lint checks .purpose file structure, not anchor content hashes.
+  - id: q4
+    question: A new project's aspect search always falls to Tier 3 (fuzzy matching). How do you warm the learning system so common queries use Tier 1?
+    choices:
+      A: Manually edit the search_weights SQLite table to insert mappings
+      B: Run paradigm_reindex with a --warm-search flag
+      C: Run common queries with paradigm_aspect_search, then confirm the best results with paradigm_aspect_confirm for each query
+      D: Wait for 100+ searches to accumulate — Tier 1 learns automatically without confirmation
+      E: Set limits.searchLearningRate to a higher value in config.yaml
+    correct: C
+    explanation: The learning system requires explicit confirmation via paradigm_aspect_confirm. When you search for a term and confirm the best result, the confirmed aspect gets +1.0 weight for that query. After 3-5 confirmations, the weight exceeds the Tier 1 threshold and future queries return instantly. There is no automatic learning without confirmation — the system relies on user feedback to improve.
+  - id: q5
+    question: During a quarterly governance review, the heatmap shows that 30 aspects out of 120 have zero access across all types (search, ripple, navigate, direct). What does this indicate and what should you do?
+    choices:
+      A: These aspects are well-documented and need no changes — zero access means no issues
+      B: Delete all 30 immediately — unused aspects are always stale
+      C: These aspects may be stale, poorly named, or irrelevant — evaluate each for removal, renaming, or consolidation as part of the governance review
+      D: Increase their severity to 'critical' to force agents to access them
+      E: Move them to a separate 'archive' section in the .purpose files
+    correct: C
+    explanation: Zero-access aspects are candidates for review, not automatic deletion. Some may be legitimate but poorly named (rename to improve discoverability). Some may be truly stale with drifted anchors (remove or update). Some may have been superseded by newer aspects (consolidate with supersedes edges). The governance review evaluates each case individually.

package/dist/university-content/quizzes/Q-para-501-aspect-graph-internals.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-aspect-graph-internals
+title: 'PARA 501: Advanced Systems — Aspect Graph Internals'
+description: 'Quiz for lesson: Aspect Graph Internals'
+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: What is the default maxDepth for recursive ripple in the aspect graph?
+    choices:
+      A: 3 — to keep traversals fast and focused
+      B: 5 — balancing depth of discovery with performance
+      C: 10 — the maximum allowed value
+      D: Unlimited — ripple traverses until minWeight is reached
+      E: 1 — only direct connections are followed by default
+    correct: B
+    explanation: The default maxDepth for recursive ripple is 5, with a maximum configurable value of 10. This default balances discovery depth with performance — at 5 hops, you see a meaningful neighborhood without traversing the entire graph. The minWeight threshold (default 0.1) provides additional pruning by cutting off low-confidence paths before they reach maxDepth.
+  - id: q2
+    question: What happens to search weights when a result is confirmed via paradigm_aspect_confirm?
+    choices:
+      A: The confirmed result gets +0.5 weight and all others are deleted
+      B: The confirmed result gets +1.0 weight and all other results for the same query decay by *0.95
+      C: All results for the query get +1.0 weight to reinforce the entire set
+      D: The confirmed result is permanently pinned and decay is disabled
+      E: The confirmed result replaces all other entries for that query
+    correct: B
+    explanation: The search learning system adds +1.0 to the confirmed result's weight for that query and multiplies all other existing results for the same query by 0.95 (a 5% decay). This self-correcting mechanism lets the best result rise to the top over time while alternatives gradually fade. The decay only applies to aspects that have existing search_weights entries for the query — it does not penalize unrelated aspects.
+  - id: q3
+    question: Which SQLite table stores aspect access frequency for the heatmap tool?
+    choices:
+      A: aspects — in an access_count column
+      B: edges — access frequency is tracked per edge
+      C: search_weights — all access types feed into search weights
+      D: heatmap — with columns for aspect_id, access_type, count, and last_accessed
+      E: anchors — access is tracked per anchor location
+    correct: D
+    explanation: The `heatmap` table stores aspect access frequency with columns for `aspect_id`, `access_type` (search, ripple, navigate, direct), `count`, and `last_accessed`. This dedicated table allows the `paradigm_aspect_heatmap` tool to rank aspects by usage frequency and break down how each aspect is typically discovered — whether through search, ripple analysis, navigation, or direct access.
+  - id: q4
+    question: What is the queue limit for recursive ripple BFS traversal?
+    choices:
+      A: 100 nodes — to keep memory usage minimal
+      B: 500 nodes — a balance between coverage and performance
+      C: 1000 nodes — preventing runaway traversals in dense graphs
+      D: Unlimited — the queue grows until maxDepth is reached
+      E: 10000 nodes — large enough for enterprise-scale graphs
+    correct: C
+    explanation: The BFS queue limit is 1000 nodes. This prevents runaway traversals in densely connected aspect graphs where the number of reachable nodes could grow exponentially with depth. When the queue exceeds 1000 entries, the oldest entries are dropped, ensuring the algorithm completes in bounded time and memory regardless of graph density.
+  - id: q5
+    question: How are aspect edges inferred from existing data during materialization?
+    choices:
+      A: By analyzing import statements in source code files
+      B: From applies-to references with weight 0.5 and origin 'inferred', and from shared lore references with origin 'learned'
+      C: By running static analysis on anchor code blocks
+      D: From git commit history showing which aspects changed together
+      E: Only explicit edges are created — no inference occurs
+    correct: B
+    explanation: The materialization pipeline creates inferred edges in two ways. First, `materializeAspects` generates edges from `applies-to` references with weight 0.5 and origin 'inferred' — when an aspect applies to a component, a relationship edge is created. Second, `inferLoreEdges` scans for aspects sharing lore references and creates edges with origin 'learned' and weight proportional to the overlap. These supplement explicit YAML edges to build a richer graph.

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.