@a-company/paradigm 5.38.0 → 6.0.4

package/dist/university-content/quizzes/Q-para-601-learning-loop.yaml

@@ -0,0 +1,56 @@
+id: Q-para-601-learning-loop
+title: 'PARA 601: Paradigm Ambient — The Learning Loop'
+description: 'Quiz for lesson: The Learning Loop'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-601
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-601.json
+questions:
+  - id: q1
+    question: An agent completes a session where it discovers that Express v5 requires explicit async error wrapping. It records this in a lore entry but no journal entry is created. Three weeks later, a different agent makes the same mistake. Which phase of the learning loop failed?
+    choices:
+      A: DO — the first agent should not have made the mistake
+      B: RECORD — the lore entry was insufficient
+      C: LEARN — the insight was captured in lore but never extracted into a journal entry that could feed back into future context
+      D: ADAPT — the context composition tool was broken
+      E: ASSESS — the event stream missed the original correction
+    correct: C
+    explanation: 'The LEARN phase failed. The observation was recorded (RECORD phase worked — there is a lore entry), but the insight was never extracted into a learning journal entry with a transferable pattern. Without a journal entry, the ADAPT phase has nothing to inject into future sessions. The fix is recording a journal entry with `transferable: true` and extracting a `LearningPattern` so it feeds into context composition.'
+  - id: q2
+    question: Why did Paradigm v5.0 reduce CLAUDE.md from ~856 lines to ~150 lines?
+    choices:
+      A: The old content was outdated and no longer relevant
+      B: Smaller files load faster from disk
+      C: Loading all guidance every session wastes tokens on content irrelevant to the current task — on-demand resources let agents load only what they need
+      D: Claude Code has a strict file size limit for CLAUDE.md
+      E: The content was moved to .paradigm/config.yaml instead
+    correct: C
+    explanation: Context engineering is about putting high-signal, task-relevant content in the context window. A 856-line CLAUDE.md loaded every session means hundreds of tokens spent on logging rules when the task is about testing, or portal conventions when the task is about lore. The slim CLAUDE.md provides universal orientation, and 12 `paradigm://guidance/{topic}` resources provide targeted guidance on demand.
+  - id: q3
+    question: Which phases of the learning loop existed before v5.0?
+    choices:
+      A: All six phases existed but were unreliable
+      B: Only DO existed — everything else is new in v5.0
+      C: DO, RECORD, and partial ASSESS (via ripple analysis) — LEARN, ADAPT, and full ASSESS were manual
+      D: DO, RECORD, ASSESS, and LEARN — only ADAPT was missing
+      E: DO and ADAPT — recording and assessment were added in v5.0
+    correct: C
+    explanation: Before v5.0, Paradigm had DO (agents perform work), RECORD (lore entries, .purpose files, portal.yaml), and partial ASSESS (ripple analysis could identify impact, but there was no event stream or attention filtering). The LEARN phase (journal entries, nominations) and ADAPT phase (context composition from learnings) were entirely manual — a human had to read lore and brief the next agent.
+  - id: q4
+    question: A security agent contributes a context section listing recently added gates. Where is this contribution defined?
+    choices:
+      A: In the security agent's `.agent` file under the `context.contributions` field
+      B: In `.paradigm/config.yaml` under a `context_sections` key
+      C: In CLAUDE.md as a static section
+      D: In `portal.yaml` under each gate definition
+      E: In the security agent's learning journal
+    correct: A
+    explanation: Agent context contributions are defined in the `AgentContext.contributions` array on the agent's profile (the `.agent` file). Each contribution specifies a `section` name, inline `content` or a `content_ref` MCP resource URI, and a `priority` (high, medium, low). High-priority contributions are always included; low-priority ones are loaded on demand. This allows each agent to inject task-relevant context without hardcoding it into CLAUDE.md.

package/dist/university-content/quizzes/Q-para-601-maestro-team-collab.yaml

@@ -0,0 +1,86 @@
+id: Q-para-601-maestro-team-collab
+title: 'PARA 601: Paradigm Ambient — Maestro: Visible Team Orchestration'
+description: 'Quiz for lesson: Maestro: Visible Team Orchestration'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-601
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-601.json
+questions:
+  - id: q1
+    question: What is the primary difference between Maestro and traditional multi-agent orchestration?
+    choices:
+      A: Maestro uses more agents per task
+      B: Maestro presents each agent's response as an attributed message rather than synthesizing a single summary
+      C: Maestro runs agents in parallel instead of sequentially
+      D: Maestro eliminates the need for human approval
+      E: Maestro uses persistent background agents
+    correct: B
+    explanation: Maestro's key innovation is visibility. Instead of synthesizing agent responses into a single voice, each agent speaks for itself with an attribution prefix like [architect]. This preserves individual perspectives and lets the human see disagreements, novel approaches, and the reasoning behind each contribution.
+  - id: q2
+    question: When a security agent is consistently dismissed by the user (>60% dismissal rate), what happens at postflight?
+    choices:
+      A: The agent is automatically deleted
+      B: The agent is moved to a different project
+      C: paradigm_ambient_learn raises the agent's attention threshold, making it nominate less
+      D: The agent's expertise scores are reset to zero
+      E: Nothing changes — threshold adjustment is manual
+    correct: C
+    explanation: The learning loop is automatic. When dismissal rate exceeds 60%, paradigm_ambient_learn raises the agent's attention threshold by 0.05, meaning it requires higher relevance scores before nominating. This self-tunes the agent to speak less when it is being noisy. Conversely, >80% acceptance lowers the threshold, encouraging the agent to contribute more.
+  - id: q3
+    question: What ambient context is injected into agent profiles before Maestro spawns them?
+    choices:
+      A: Only the agent's expertise scores
+      B: The full project codebase
+      C: Recent team decisions, transferable journal insights, and pending nominations
+      D: The complete git history
+      E: Nothing — agents start fresh each session
+    correct: C
+    explanation: buildProfileEnrichment() accepts an ambientContext parameter containing recent team decisions (from decision-loader), transferable journal insights (from journal-loader), and pending nominations (from nomination-engine). This gives each agent awareness of what the team has decided, what patterns have been discovered, and what issues are outstanding — creating genuine team intelligence rather than isolated tool execution.
+  - id: q4
+    question: What does the Neverland test health status 'calibrating' indicate?
+    choices:
+      A: No agents have been created yet
+      B: Agents have fewer than 10 total nominations
+      C: Average acceptance rate is between 50% and 70% — agents are learning but haven't reached target
+      D: All agents have been benched
+      E: The system has reached maturity and needs no further adjustment
+    correct: C
+    explanation: 'The Neverland health statuses are: cold-start (<10 nominations), accumulating (<50% accept rate), calibrating (50-70% accept rate), and mature (>70%). ''Calibrating'' means agents are past the initial noise phase and their thresholds are actively being tuned by the learning loop, but haven''t yet reached the 70% target. This typically occurs around sessions 4-7.'
+  - id: q5
+    question: How does benching an agent differ from deleting it?
+    choices:
+      A: There is no difference — bench removes the agent profile
+      B: Benching sets benched=true — the profile stays intact but Maestro and the nomination engine skip it
+      C: Benching only affects CLI commands, not MCP tools
+      D: Benching removes expertise but keeps the profile
+      E: Benching is permanent while deletion can be undone
+    correct: B
+    explanation: Benching is a reversible pause. The agent's .agent file remains with all expertise, journal entries, notebooks, and transferable patterns intact. Both paradigm_orchestrate_inline and processEvent check profile.benched and skip the agent if true. paradigm agent activate restores the agent immediately with all its accumulated learning preserved.
+  - id: q6
+    question: Why does the Teacher Model write journal entries instead of adjusting thresholds directly?
+    choices:
+      A: Journal entries are cheaper in token cost
+      B: Thresholds can only go up, not down
+      C: Journal entries carry semantic knowledge (what to look for, what was wrong) while thresholds are just a single number that says 'speak more' or 'speak less'
+      D: The threshold system is being removed in favor of journals
+      E: Journal entries are visible to the user while thresholds are hidden
+    correct: C
+    explanation: 'Thresholds control volume (speak more/less) but not quality. A threshold can''t teach the security agent to distinguish audit logging from vulnerabilities. A journal entry can: ''When auth files change with logging additions, recognize these as security-positive — don''t flag as violations.'' This knowledge promotes to notebooks and appears in future prompts via buildProfileEnrichment, making the agent genuinely smarter rather than just quieter.'
+  - id: q7
+    question: What is the documentor agent's relationship to the stop hook?
+    choices:
+      A: The documentor replaces the stop hook entirely
+      B: The documentor runs before the stop hook and should prevent it from ever triggering, but the hook remains as a safety net
+      C: The stop hook runs the documentor automatically
+      D: They are unrelated systems
+      E: The documentor disables the stop hook for the session
+    correct: B
+    explanation: The stop hook blocks when .purpose files are missing for modified source directories. The documentor's job is to update these files as the final orchestration stage, so the stop hook should never need to block. However, the stop hook remains as a safety net — if the documentor misses something or orchestration wasn't used, the hook catches it. Defense in depth.

package/dist/university-content/quizzes/Q-para-601-nominations-debates.yaml

@@ -0,0 +1,66 @@
+id: Q-para-601-nominations-debates
+title: 'PARA 601: Paradigm Ambient — Nominations & Debates'
+description: 'Quiz for lesson: Nominations & Debates'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-601
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-601.json
+questions:
+  - id: q1
+    question: 'A security agent creates a nomination with `urgency: ''medium''` and `type: ''warning''` about a missing gate. The user has configured the security agent''s `min_urgency` to `''high''`. What happens?'
+    choices:
+      A: The nomination is deleted — it does not meet the urgency threshold
+      B: The nomination is recorded but not surfaced — it falls below the user's configured minimum urgency for that agent
+      C: The nomination is surfaced anyway because warnings always override urgency settings
+      D: The nomination is upgraded to `high` urgency automatically
+      E: The user's setting is ignored because security nominations are always shown
+    correct: B
+    explanation: 'The nomination is still recorded in `.paradigm/events/nominations.jsonl` (all nominations are persisted), but surfacing rules respect the user''s configuration. Since `min_urgency: ''high''` means only `high` and `critical` nominations from the security agent are shown, a `medium` nomination is suppressed. The nomination remains available if the user later queries all nominations or lowers the threshold.'
+  - id: q2
+    question: An architect nominates "Use a message queue for async processing" while a builder nominates "Use direct HTTP calls for simplicity" — both triggered by the same `route-created` event. How does Paradigm classify this?
+    choices:
+      A: Two independent nominations — no debate is detected because different agents created them
+      B: A complementary debate — both are responding to the same event
+      C: A conflicting debate — the nominations share a `triggered_by` event but propose different approaches
+      D: An error — only one agent should nominate per event
+      E: The nomination with the higher relevance score wins automatically
+    correct: C
+    explanation: Debate detection checks for overlapping `triggered_by` event IDs. Both nominations reference the same `route-created` event, so they are grouped. Since they propose different approaches (message queue vs HTTP calls), the debate is classified as `conflicting`. The debate is surfaced as a group so the human sees both perspectives together rather than individual nominations. Resolution requires a human choice or consensus.
+  - id: q3
+    question: 'A nomination has `evidence: [{ symbol: ''^payment-authorized'', file: ''portal.yaml'', lines: { start: 42, end: 45 }, description: ''All /api/payments routes require this gate'' }]`. Why is this better than a nomination without evidence?'
+    choices:
+      A: Evidence makes the nomination sort higher in the UI
+      B: Nominations without evidence are automatically dismissed
+      C: Evidence transforms the nomination from opinion to argument — the human can verify the claim against specific code locations without investigating from scratch
+      D: Evidence is required for all nomination types
+      E: Evidence triggers automatic remediation
+    correct: C
+    explanation: Evidence gives the nomination credibility and actionability. Without evidence, "This route needs a gate" requires the human to verify the claim manually. With evidence pointing to portal.yaml line 42 and the specific gate symbol, the human can quickly confirm the pattern and act. Evidence is optional (the `evidence` field is nullable), but nominations with evidence are more likely to be accepted rather than dismissed.
+  - id: q4
+    question: 'A tester creates a nomination with `type: ''offer''` and `action_offered: ''Write integration tests for the new payment flow''`. The human responds via `paradigm_ambient_engage` with `response: ''accepted''`. What happens next?'
+    choices:
+      A: Paradigm automatically generates the test files
+      B: The nomination's `detail` and `evidence` are returned so the tester agent can proceed with the offered action
+      C: The nomination is moved to a task queue for later execution
+      D: The tester agent is immediately spawned in a new session
+      E: Nothing — acceptance is recorded but has no effect
+    correct: B
+    explanation: When a nomination is accepted via `paradigm_ambient_engage`, the full nomination including `detail` and `evidence` is returned. For `offer` type nominations, this signals that the agent should proceed with the offered action. The actual execution depends on the orchestration context — in a multi-agent session, the tester may act immediately; in a single-agent session, the offer acceptance is recorded for the next session. Paradigm does not auto-generate code; it surfaces the offer for the agent to execute.
+  - id: q5
+    question: Over 30 sessions, a reviewer agent's nominations are dismissed 80% of the time. What does this pattern suggest?
+    choices:
+      A: The reviewer agent should be removed from the project
+      B: The reviewer's attention threshold may be too low — it is nominating on weak matches, and raising the threshold would reduce false positives
+      C: The human is ignoring valid feedback and should be trained
+      D: Dismissed nominations indicate the system is working correctly — not all observations are actionable
+      E: The nomination storage file is corrupted
+    correct: B
+    explanation: An 80% dismissal rate is a strong signal that the agent is speaking up too often on weak matches. The most likely fix is raising the agent's attention threshold (e.g., from 0.6 to 0.75) so it only nominates on stronger matches. The `paradigm_ambient_engage` feedback loop exists precisely for this calibration — over time, the pattern of accepted vs dismissed nominations reveals whether an agent's threshold is well-tuned.

package/dist/university-content/quizzes/Q-para-701-agent-notebooks.yaml

@@ -0,0 +1,66 @@
+id: Q-para-701-agent-notebooks
+title: 'PARA 701: Agent Mastery — Lesson 3: Agent Notebooks'
+description: 'Quiz for lesson: Lesson 3: Agent Notebooks'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+questions:
+  - id: q1
+    question: A security agent has 30 notebook entries. During orchestration, how many are injected into its prompt?
+    choices:
+      A: All 30 — notebooks are always fully injected
+      B: The top 5 by concept match against the task's relevant symbols, sorted by appliedCount
+      C: The top 10, since 10 high-signal entries is the recommended maximum
+      D: Only entries with appliedCount > 0
+      E: A random selection of 5 entries
+    correct: B
+    explanation: 'buildProfileEnrichment() includes `notebookEntries.slice(0, 5)` — a hard limit of 5 entries. These are pre-filtered by concept match against the task''s relevant symbols and sorted by appliedCount descending (most-used first). The 5-entry budget is a deliberate token constraint: each entry consumes 100-300 tokens, so 5 entries use 500-1,500 tokens, which balances value against context budget.'
+  - id: q2
+    question: The security agent has a global notebook entry `nb-jwt-validation-001` and the current project has a project notebook entry with the same ID. Which one is used?
+    choices:
+      A: The global entry — global always takes precedence
+      B: Both entries are merged into one
+      C: The project entry wins — project overrides global on ID collision
+      D: An error is thrown for duplicate IDs
+      E: The entry with the higher appliedCount is used
+    correct: C
+    explanation: 'The notebook loader reads global entries first, then project entries. Entries are stored in a Map keyed by ID. When a project entry has the same ID as a global entry, the project entry overwrites the global one: `entries.set(entry.id, entry)`. This allows a project to customize an agent''s generic knowledge for project-specific needs — for example, overriding a generic JWT pattern with the project''s specific token rotation strategy.'
+  - id: q3
+    question: 'What is the difference between a notebook entry with `provenance.source: ''lore''` and one with `provenance.source: ''manual''`?'
+    choices:
+      A: Lore entries are read-only; manual entries are editable
+      B: Lore entries were promoted from session experience via promoteFromLore() and link to the original lore entry; manual entries were written directly without a session origin
+      C: Manual entries have higher confidence scores by default
+      D: Lore entries are global; manual entries are project-scoped
+      E: There is no functional difference — provenance is informational only
+    correct: B
+    explanation: 'Provenance tracks the origin of a notebook entry. `source: ''lore''` means the entry was created by `promoteFromLore()` — it links to the original lore entry via `loreEntryId` and was extracted from real session experience. `source: ''manual''` means someone wrote it directly (bootstrapping or direct curation). Lore-promoted entries have a verifiable chain of evidence (the session where the pattern was discovered), while manual entries rely on the author''s judgment. Both are functionally equivalent in how they''re used during enrichment.'
+  - id: q4
+    question: Why is `appliedCount` the primary sorting key for notebook entries rather than `confidence`?
+    choices:
+      A: appliedCount is easier to compute than confidence
+      B: Confidence is deprecated in favor of appliedCount
+      C: appliedCount is an empirical signal — an entry applied 15 times is proven useful in practice, while confidence is an initial estimate that may not reflect actual utility
+      D: appliedCount determines the entry's storage priority on disk
+      E: Confidence only applies to expertise scores, not notebook entries
+    correct: C
+    explanation: appliedCount tracks how many times an entry was actually used in orchestration. An entry with appliedCount of 15 has been surfaced and found useful in 15 sessions — this is empirical evidence of value. Confidence is an initial estimate (0.0-1.0) that may be set optimistically when the entry is created. A newly bootstrapped entry might have confidence 0.8 but appliedCount 0, meaning it looks good on paper but has never been validated. The system trusts what has been proven (appliedCount) over what has been estimated (confidence).
+  - id: q5
+    question: An agent's notebook entry snippet is 800 characters long. How does buildProfileEnrichment() handle this?
+    choices:
+      A: It injects the full 800-character snippet
+      B: It skips the entry entirely
+      C: It truncates the snippet to 300 characters and appends '...'
+      D: It splits the snippet across multiple prompt sections
+      E: It compresses the snippet using summarization
+    correct: C
+    explanation: 'buildProfileEnrichment() truncates long snippets: `nb.snippet.length > 300 ? nb.snippet.slice(0, 300) + ''...'' : nb.snippet`. The 300-character limit prevents a single large entry from consuming the entire notebook token budget. If the agent needs the full snippet, it can use `paradigm_notebook_search` to retrieve the complete entry on demand. This is the context engineering principle at work — inject enough to be useful, provide a retrieval path for more detail.'

package/dist/university-content/quizzes/Q-para-701-agent-pods-nevrland.yaml

@@ -0,0 +1,66 @@
+id: Q-para-701-agent-pods-nevrland
+title: 'PARA 701: Agent Mastery — Lesson 10: Agent Pods & nevr.land'
+description: 'Quiz for lesson: Lesson 10: Agent Pods & nevr.land'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+questions:
+  - id: q1
+    question: A developer activates the Ship Pod and then the Design Pod. How many agents are in the roster?
+    choices:
+      A: 6 — the Design Pod replaces the Ship Pod
+      B: 11 — Ship Pod (6) + Design Pod (5), no overlap
+      C: The union of both pods — pods are additive, agents from both are in the roster with no duplicates
+      D: Only the Design Pod agents — the last activated pod wins
+      E: All 54 agents — activating any pod enables all agents
+    correct: C
+    explanation: 'Pods are additive. Activating a pod adds its agents to the existing roster. The Ship Pod adds architect, builder, reviewer, tester, security, and documentor. The Design Pod adds designer, copywriter, a11y, creative, and presenter. The roster now contains the union of both: 11 unique agents (no overlap between these two pods). If pods had overlapping agents (e.g., both include reviewer), the agent would appear once in the roster.'
+  - id: q2
+    question: What is the difference between a pod and a roster?
+    choices:
+      A: They are the same thing with different names
+      B: A pod is a named preset of agents (a template); a roster is the actual list of active agents on a project. Activating a pod modifies the roster.
+      C: A pod modifies agent behavior; a roster just lists agent names
+      D: A roster can contain pods but not individual agents
+      E: Pods are for production; rosters are for development
+    correct: B
+    explanation: A pod is a template — a named group of agents optimized for a workflow (like "Ship Pod" = architect + builder + reviewer + tester + security + documentor). A roster is the actual configuration file (`.paradigm/roster.yaml`) that lists which agents are active on a project. The command `paradigm agents activate --pod ship-pod` reads the pod template and adds its agents to the roster. The pod is the input; the roster is the output.
+  - id: q3
+    question: A community-published agent from nevr.land is installed. How does it participate in the local Paradigm system?
+    choices:
+      A: It runs in a sandboxed mode with limited capabilities
+      B: 'It is installed to ~/.paradigm/agents/ and participates identically to built-in agents: same orchestration, attention scoring, learning loop, expertise tracking, and notebook system'
+      C: It can only be used manually, not through orchestration
+      D: It requires an API key from the publisher to function
+      E: It is read-only and cannot accumulate expertise or notebook entries
+    correct: B
+    explanation: 'An installed agent follows the standard `.agent` schema and is placed in `~/.paradigm/agents/`. The system treats it identically to a built-in agent: it is included in orchestration planning (if in the roster), scores events against its attention patterns, self-nominates contributions, accumulates expertise through verdicts, and builds notebook entries through the learning loop. Trust level affects installation warnings, not runtime capabilities.'
+  - id: q4
+    question: An agent package on nevr.land includes a `notebooks/` directory with 5 YAML files. Where are these installed?
+    choices:
+      A: In the project's .paradigm/notebooks/{agent-id}/
+      B: In ~/.paradigm/notebooks/{agent-id}/ as global entries that travel across all projects
+      C: They are not installed — notebooks must be created manually
+      D: In the agent's .agent file as inline snippets
+      E: In ~/.paradigm/agents/{agent-id}/notebooks/
+    correct: B
+    explanation: 'Notebook entries from an agent package are installed into `~/.paradigm/notebooks/{agent-id}/` as global entries. This means they are available on every project the agent joins, providing bootstrapping knowledge from day one. This matches the storage pattern: global notebooks at ~/.paradigm/notebooks/ travel with the agent, while project notebooks at .paradigm/notebooks/ are project-specific. Bootstrapping entries should be global because they represent the agent''s foundational knowledge, not project-specific patterns.'
+  - id: q5
+    question: Why does the agent package format use YAML files instead of a compiled binary format?
+    choices:
+      A: YAML is faster to parse than binary formats
+      B: Binary formats are not supported on all platforms
+      C: YAML is human-readable, enabling inspection, forking, and modification before installation — agents are knowledge, not code, and should be as shareable and composable as possible
+      D: YAML is required by the Paradigm schema validator
+      E: Binary formats would require code signing
+    correct: C
+    explanation: The design principle is that agents are knowledge, not compiled code. A human-readable YAML format means you can inspect an agent's personality, expertise, behaviors, and attention patterns before installing it. You can fork a community agent, modify its attention threshold, add a behavior, and republish. You can copy a single transferable pattern from one agent to another. A binary format would make all of this opaque. The package format (agent.yaml + notebooks/ + metadata.yaml) is intentionally the simplest possible structure that captures the complete agent identity.

package/dist/university-content/quizzes/Q-para-701-agent-profiles.yaml

@@ -0,0 +1,66 @@
+id: Q-para-701-agent-profiles
+title: 'PARA 701: Agent Mastery — Lesson 2: Agent Profiles Deep Dive'
+description: 'Quiz for lesson: Lesson 2: Agent Profiles Deep Dive'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+questions:
+  - id: q1
+    question: 'A security agent has `confidence: 0.85` on `#auth-security`. Over the next 5 sessions, its security review contributions are accepted 4 times and dismissed 1 time. What is the approximate new confidence score?'
+    choices:
+      A: 0.85 — confidence does not change automatically
+      B: ~0.95 — 4 accepts at +0.03 each, 1 dismiss at -0.02 = +0.10 net
+      C: 1.0 — confidence maxes out after enough acceptances
+      D: ~0.80 — the single dismissal outweighs the acceptances
+      E: Depends on the reviewer, not the verdicts
+    correct: B
+    explanation: 'Expertise confidence adjusts per verdict: `+0.03` for accepted, `-0.02` for dismissed, `-0.01` for revised. Four acceptances: `4 * 0.03 = +0.12`. One dismissal: `1 * -0.02 = -0.02`. Net delta: `+0.10`. Starting from 0.85, the new confidence is approximately 0.95. In practice, confidence is clamped to `[0.0, 1.0]`, so it would be `min(1.0, 0.95) = 0.95`.'
+  - id: q2
+    question: What is the difference between `collaboration.stance` and `collaboration.with.{agent}.stance`?
+    choices:
+      A: They are the same field with different syntax
+      B: '`collaboration.stance` is the default stance toward all agents; `collaboration.with.{agent}.stance` overrides it for a specific agent'
+      C: '`collaboration.with` is deprecated in favor of `collaboration.stance`'
+      D: '`collaboration.stance` applies to humans; `collaboration.with` applies to agents'
+      E: '`collaboration.stance` only applies during orchestration; `collaboration.with` applies in Symphony'
+    correct: B
+    explanation: 'The top-level `collaboration.stance` (e.g., `advisory`) is the default relationship the agent has with all other agents. The `collaboration.with.{agent}.stance` (e.g., `with.architect.stance: peer`) overrides it for a specific agent. This allows fine-grained relationships: the security agent is `advisory` by default but treats the architect as a `peer` with `can_contradict: true`.'
+  - id: q3
+    question: 'An agent has a transferable pattern with `successRate: 0.5`. How does this affect its inclusion in orchestration prompts?'
+    choices:
+      A: It is included with a warning label
+      B: It is always included — all patterns are injected regardless of success rate
+      C: It is excluded — buildProfileEnrichment() only includes patterns with successRate >= 0.7
+      D: It is included but with reduced priority
+      E: It triggers a notification to the human to update the pattern
+    correct: C
+    explanation: 'The `buildProfileEnrichment()` function filters transferable patterns: `(profile.transferable || []).filter(p => p.successRate >= 0.7)`. Patterns with a success rate below 0.7 are excluded from prompt enrichment. A 0.5 success rate means the pattern works only half the time — injecting it into every orchestration prompt would waste context tokens on unreliable guidance. The agent needs to improve the pattern (or it will naturally improve as the system tracks successes) before it gets promoted to prompt enrichment.'
+  - id: q4
+    question: Why does the security agent's description explicitly state "He flags issues but does NOT implement fixes — that's the Builder's job"?
+    choices:
+      A: It is a style preference with no functional impact
+      B: The description is injected into the agent's prompt during orchestration, so explicit boundaries prevent the security agent from writing implementation code when it should only be reviewing
+      C: It is documentation for the human developer only
+      D: It prevents the security agent from being activated on implementation tasks
+      E: It triggers the orchestrator to always pair security with builder
+    correct: B
+    explanation: The agent's `description` field is injected into the orchestration prompt. When the LLM receives the security agent's prompt, it reads this boundary statement and constrains its behavior accordingly. Without explicit boundaries in the description, the LLM might generate implementation code when it should only flag issues for the builder. Clear description boundaries are how you enforce separation of concerns between agents that share the same underlying LLM.
+  - id: q5
+    question: What happens when the orchestrator calls buildProfileEnrichment() for an agent?
+    choices:
+      A: It writes the agent's profile to disk in a new format
+      B: It compiles the agent's .agent file into a binary prompt template
+      C: It assembles the agent's personality, relevant expertise, transferable patterns, notebook entries, and agent state into a markdown prompt section that makes the base LLM behave as that specific agent
+      D: It validates the agent's profile for schema errors
+      E: It sends the profile to the Conductor UI for display
+    correct: C
+    explanation: buildProfileEnrichment() is the function that transforms a static .agent file into a dynamic prompt enrichment section. It takes the agent's profile, the relevant symbols for the current task, notebook entries matched by concept, ambient context (decisions, journal insights, nominations), and agent state (last session, pending work). It assembles all of this into markdown that includes sections like '## Agent Identity', '## Your Expertise on Relevant Symbols', '## Transferable Patterns', '## Relevant Notebook Entries', and '## Your Recent Work on This Project'. This prompt enrichment is what makes the same base LLM behave differently as each agent.

package/dist/university-content/quizzes/Q-para-701-agent-roster.yaml

@@ -0,0 +1,66 @@
+id: Q-para-701-agent-roster
+title: 'PARA 701: Agent Mastery — Lesson 1: The Agent Roster'
+description: 'Quiz for lesson: Lesson 1: The Agent Roster'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+questions:
+  - id: q1
+    question: A new SaaS web app project needs to build a payment flow with Stripe integration. The task touches `^authenticated`, `$checkout-flow`, and `#payment-service`. Which agents would the orchestrator most likely include, and why?
+    choices:
+      A: Only the builder — it is a coding task
+      B: The architect (plans the flow), builder (implements), security (gates on ^authenticated), reviewer (quality check), and documentor (.purpose updates) — because their attention patterns match the symbols involved
+      C: All 54 agents — payments are critical and need full coverage
+      D: The designer and copywriter — it is a user-facing payment page
+      E: The devops agent — Stripe is infrastructure
+    correct: B
+    explanation: The orchestrator matches task symbols against agent attention patterns. The architect's `$*` pattern matches `$checkout-flow`. Security's `^*` pattern matches `^authenticated`. The builder's path patterns match source files. The reviewer watches all symbol types. The documentor has the lowest threshold (0.3) and matches symbol patterns. The designer and copywriter might be included if UI work is required, but the core selection is driven by symbol matching against attention patterns.
+  - id: q2
+    question: Why does the security agent have an attention threshold of 0.45 while the builder has 0.75?
+    choices:
+      A: The security agent is more important than the builder
+      B: The builder writes more code and needs to be more selective about when it speaks up
+      C: The cost of missing a security issue (low threshold = more alerts) far outweighs the cost of a false alarm, while the builder should only engage when directly relevant to implementation
+      D: Lower thresholds mean the agent runs faster
+      E: The thresholds are arbitrary defaults with no design rationale
+    correct: C
+    explanation: Threshold values encode the asymmetry of costs. A security agent that stays quiet when a gate is missing creates a vulnerability — the cost of a false negative is high. So it uses a low threshold (0.45) to speak up early and often. The builder speaking up on tasks not directly relevant to implementation just adds noise. The cost of a builder false positive is wasted context tokens. So it uses a higher threshold (0.75) to stay focused.
+  - id: q3
+    question: What is the purpose of the Meta tier agents (forge, trainer, documentor, mediator)?
+    choices:
+      A: They manage the codebase directly, writing and reviewing source files
+      B: They manage other agents — designing new agents, training existing ones, maintaining Paradigm files, and resolving agent disagreements
+      C: They are administrative agents that handle user authentication
+      D: They provide backup for the builder when it is unavailable
+      E: They are deprecated and no longer used in the roster
+    correct: B
+    explanation: Meta agents operate on the agent system itself rather than on the codebase directly. Loid (forge) designs and builds new agents by understanding the full .agent profile schema. Sensei (trainer) reviews agent performance and curates notebook entries to improve them. The documentor maintains .purpose and portal.yaml files after other agents finish. Bridge (mediator) resolves disagreements between agents. They are the agents that make other agents better.
+  - id: q4
+    question: A developer is working on a game project built with Godot. Which of these agents would likely NOT be in the project roster?
+    choices:
+      A: The gamedev agent (Pixel)
+      B: The 3d agent (Neon)
+      C: The audio agent (Echo)
+      D: The SEO agent (Beacon)
+      E: The builder agent
+    correct: D
+    explanation: The SEO agent (Beacon) specializes in search engine optimization — concepts like meta tags, crawlability, structured data, and organic traffic. A Godot game project has no web pages to optimize for search engines. The game project type suggests a roster including architect, builder, reviewer, tester, documentor, gamedev (Pixel), 3d (Neon), audio (Echo), designer, performance, and debugger. SEO is irrelevant to this domain.
+  - id: q5
+    question: What distinguishes Jinx (advocate) from the reviewer in the Reviewers tier?
+    choices:
+      A: Jinx writes code and the reviewer does not
+      B: Jinx is a devil's advocate who stress-tests assumptions and challenges approaches, while the reviewer checks code correctness, quality, and Paradigm compliance
+      C: Jinx is the reviewer's backup — they do the same work
+      D: Jinx only works on security-related code
+      E: Jinx has a higher attention threshold than the reviewer
+    correct: B
+    explanation: 'Jinx and the reviewer serve fundamentally different purposes. The reviewer checks code quality: correctness, naming conventions, .purpose coverage, aspect anchors, test coverage. Jinx''s job is to argue against the current approach entirely — she stress-tests assumptions, finds edge cases nobody considered, and asks uncomfortable questions. Her personality is confrontational and aggressive, while the reviewer is deliberate and conservative. Jinx attacks the design; the reviewer evaluates the implementation.'

package/dist/university-content/quizzes/Q-para-701-agent-state.yaml

@@ -0,0 +1,66 @@
+id: Q-para-701-agent-state
+title: 'PARA 701: Agent Mastery — Lesson 4: Agent State & Continuity'
+description: 'Quiz for lesson: Lesson 4: Agent State & Continuity'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+questions:
+  - id: q1
+    question: The security agent reviewed 5 files in session A, deferred 2 items, then in session B completed 1 of those items and deferred 1 new item. How many pending items does the agent see at the start of session C?
+    choices:
+      A: 0 — pending work resets each session
+      B: 1 — only the item deferred in session B
+      C: 2 — the 1 remaining from session A plus the 1 new from session B
+      D: 3 — all items ever deferred
+      E: It depends on the project roster configuration
+    correct: C
+    explanation: 'Pending work accumulates across sessions and persists until explicitly completed via `completePendingWork()`. Session A deferred 2 items. Session B completed 1 (leaving 1 from A) and added 1 new item. At the start of session C, the agent sees 2 pending items: the 1 remaining from session A and the 1 added in session B. This is the key value of pending work tracking — nothing falls through the cracks across session boundaries.'
+  - id: q2
+    question: What is the difference between `recentPatterns` in project state and `transferable` patterns in the .agent file?
+    choices:
+      A: They are the same thing stored in different locations
+      B: recentPatterns are project-specific and do not travel; transferable patterns apply across all projects and are included in prompt enrichment when successRate >= 0.7
+      C: recentPatterns are more important and always override transferable patterns
+      D: transferable patterns are deprecated in favor of recentPatterns
+      E: recentPatterns are automatically promoted to transferable after 10 sessions
+    correct: B
+    explanation: 'recentPatterns live in the project state file and capture knowledge specific to one project (e.g., ''This project uses sliding-window JWT rotation''). They are injected as ''**Project patterns you''ve learned:**'' in the prompt, but only for that project. Transferable patterns live in the .agent file and apply everywhere (e.g., ''always check RLS policies''). They travel across projects and are included in prompt enrichment when successRate >= 0.7. The distinction is scope: project vs universal.'
+  - id: q3
+    question: 'An agent''s global state shows `totalSessions: 47` with 30 sessions on project A and 2 on project B. The agent is now starting work on project B. How does the orchestrator use this information?'
+    choices:
+      A: It rejects the agent — 2 sessions is insufficient expertise
+      B: It ignores global state — only project state matters
+      C: The low session count on project B (relative to the agent's 47 total sessions) may trigger a fresh onboarding pass, and the project state's lastSession age indicates how much context refresh is needed
+      D: It assigns the agent to project A instead, where it has more experience
+      E: Global state is only used for dashboard display, not orchestration decisions
+    correct: C
+    explanation: Global state provides experience context. An agent with 47 total sessions is experienced overall, but only 2 sessions on project B means limited project-specific knowledge. The orchestrator can use this to trigger the agent's `onboarding` procedure (defined in the collaboration block), ensuring the agent re-reads the project's .purpose files, config, and portal.yaml before making recommendations. The project state's `lastSession.date` shows how stale the context is — if the 2 sessions were 3 months ago, a full onboarding is warranted.
+  - id: q4
+    question: Where does project state live and why is it committed to the repository?
+    choices:
+      A: ~/.paradigm/agent-state/ — it is user-scoped, not committed
+      B: .paradigm/agent-state/{id}.yaml — it is committed so that when another team member works on the project, agents remember what was done, not just what one person's agents did
+      C: In memory only — state is ephemeral and reconstructed from lore
+      D: .paradigm/config.yaml — state is a config value
+      E: node_modules/.paradigm/ — it is a build artifact
+    correct: B
+    explanation: 'Project state at `.paradigm/agent-state/{id}.yaml` is committed to the repository. This is important for team continuity: if developer A''s security agent reviews files and defers items, developer B''s security agent should see those deferred items in the next session. The state is project-scoped (different from global state at ~/.paradigm/agents/ which is user-scoped), so it captures the collective agent experience on the project, not just one user''s sessions.'
+  - id: q5
+    question: The recentPatterns array in project state has a maximum of 10 entries. An agent learns an 11th pattern. What happens?
+    choices:
+      A: The 11th pattern is rejected — the agent must manually remove an old one
+      B: All patterns are cleared and replaced with the 11th
+      C: The oldest pattern is dropped and the new one is added — `recentPatterns.slice(-10)` keeps only the most recent 10
+      D: The array expands to 11 — the limit is advisory
+      E: The pattern is added to the agent's transferable array instead
+    correct: C
+    explanation: 'The `addProjectPattern()` function enforces a hard limit of 10 recent patterns: `if (state.recentPatterns.length > 10) { state.recentPatterns = state.recentPatterns.slice(-10); }`. The oldest pattern is dropped and the newest is kept. This bounded window ensures the prompt enrichment section stays within token budgets while always showing the most recent project-specific knowledge. Patterns that prove universally useful should be promoted to the agent''s `transferable` array in the .agent file, which has no such limit.'

package/dist/university-content/quizzes/Q-para-701-learning-feedback-loop.yaml

@@ -0,0 +1,66 @@
+id: Q-para-701-learning-feedback-loop
+title: 'PARA 701: Agent Mastery — Lesson 9: The Learning Feedback Loop'
+description: 'Quiz for lesson: Lesson 9: The Learning Feedback Loop'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+questions:
+  - id: q1
+    question: The security agent's contribution is revised by the human (partially correct). What happens to its expertise confidence on the relevant symbols?
+    choices:
+      A: No change — revised contributions have no effect
+      B: Confidence decreases by 0.02 (same as dismissed)
+      C: Confidence decreases by 0.01 — the revised verdict means the agent was partially right, so the penalty is smaller than dismissed (-0.02)
+      D: Confidence increases by 0.01 (partially correct is still partially positive)
+      E: Confidence is reset to 0.5 (neutral)
+    correct: C
+    explanation: Revised verdicts trigger a -0.01 adjustment. This is smaller than dismissed (-0.02) because the agent was in the right direction — the human modified the contribution rather than rejecting it entirely. The asymmetric reinforcement scheme (+0.03 accept / -0.02 dismiss / -0.01 revise) is designed so that a mix of mostly-accepted with occasional revisions still trends upward, while consistent dismissals trend downward.
+  - id: q2
+    question: The Teacher Model runs at postflight and reads the session work log. What is it looking for?
+    choices:
+      A: Code syntax errors in agent contributions
+      B: Patterns in user verdicts — which agents were accepted, dismissed, or revised, and what insights can be extracted for journal entries
+      C: Missing .purpose file updates
+      D: Whether the orchestrator was called
+      E: Token usage metrics for cost optimization
+    correct: B
+    explanation: 'The Teacher Model''s postflight learning pass reads agent-contribution and user-verdict entries from the session work log. It looks for patterns: which agents were consistently accepted (confirming their expertise), which were revised (indicating partial knowledge gaps), and what specific corrections the human made (revisionDelta). It synthesizes these patterns into journal entries with extracted LearningPatterns that describe when to apply the corrected approach. The Teacher Model does not check code quality or Paradigm compliance — those are the reviewer''s and stop hook''s jobs.'
+  - id: q3
+    question: 'A journal entry about JWT refresh token rotation has appeared in 4 different sessions with `transferable: true`. Sensei is evaluating whether to promote it to a notebook entry. What criteria does Sensei use?'
+    choices:
+      A: Only the transferable flag — if true, it is automatically promoted
+      B: The number of sessions (4 is enough) — promotion is count-based
+      C: Whether the insight is transferable, actionable, confirmed by multiple sessions, and high enough confidence to be reliable
+      D: Whether the human explicitly requests promotion
+      E: Whether the agent's overall acceptance rate is above 80%
+    correct: C
+    explanation: 'Sensei evaluates multiple criteria: (1) Is it transferable to other projects? (`transferable: true` confirms this). (2) Is it actionable — specific enough to apply, not just a vague observation? (3) Has it appeared across multiple sessions — 4 appearances confirms the pattern. (4) Is the confidence high enough? A pattern discovered through `correction_received` with `confidence_after: 0.9` is more reliable than one from `self_reflection` with `confidence_after: 0.6`. The promotion is a quality gate, not automatic.'
+  - id: q4
+    question: Why is the expertise adjustment +0.03 for accepted but only -0.02 for dismissed (asymmetric rather than symmetric)?
+    choices:
+      A: Positive reinforcement is always stronger than negative in learning theory
+      B: The asymmetry prevents a single bad session from collapsing an otherwise reliable agent's confidence — it takes more dismissals than acceptances to significantly change confidence
+      C: Symmetric adjustments would cause confidence to oscillate unstably
+      D: The specific values are arbitrary and have no design rationale
+      E: Accepted contributions are more common, so they need a larger weight
+    correct: B
+    explanation: The asymmetry is deliberate. If an agent has been consistently good (confidence 0.9) and has one bad session where a contribution is dismissed, symmetric -0.03 would drop it to 0.87. With asymmetric -0.02, it drops to 0.88. This matters because a single bad session should not outweigh multiple good ones. The agent needs more dismissals than acceptances to trend downward, which matches the expectation that occasionally wrong agents are still net-positive contributors.
+  - id: q5
+    question: An agent's nomination was deferred (not accepted, not dismissed). How does this affect the learning loop?
+    choices:
+      A: The expertise confidence decreases slightly
+      B: The nomination is marked for re-evaluation in the next session
+      C: No expertise change occurs — deferred says nothing about correctness, only timing. The journal entry (if written) would use trigger `self_reflection` rather than `human_feedback`.
+      D: The agent is temporarily benched until the deferred item is resolved
+      E: The Teacher Model treats deferred as a weaker form of dismissal
+    correct: C
+    explanation: A deferred verdict means the contribution is not relevant right now, but may be valid. The expertise adjustment for deferred is 0 (no change) because deferral carries no signal about whether the agent was right or wrong. The agent's confidence remains unchanged. If the Teacher Model writes a journal entry about the deferred contribution, it would use `self_reflection` as the trigger rather than `human_feedback`, since the human did not evaluate correctness.