@a-company/paradigm 5.37.11 → 6.0.2

package/dist/university-content/quizzes/Q-para-601-event-stream.yaml

@@ -0,0 +1,66 @@
+id: Q-para-601-event-stream
+title: 'PARA 601: Paradigm Ambient — The Event Stream'
+description: 'Quiz for lesson: The Event Stream'
+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 adds a new POST route to `src/routes/payments.ts` and updates `portal.yaml` with a `^authenticated` gate. How many events are emitted, and of what types?
+    choices:
+      A: 'One event: `file-modified` for the route file'
+      B: 'Two events: `file-modified` for the route file and `file-modified` for portal.yaml'
+      C: 'At minimum two events: `route-created` (or `file-modified`) for the new route, and `gate-added` for the portal.yaml change — exact count depends on which hooks and tools fired'
+      D: No events — events are only emitted by MCP tool calls, not file edits
+      E: 'One event: `gate-added` — only portal.yaml changes produce events'
+    correct: C
+    explanation: Adding a route and a gate are distinct actions that produce distinct events. The route change produces at least a `file-modified` or `route-created` event (depending on whether the post-write hook recognizes it as a route file). The portal.yaml change produces a `gate-added` event. Additional events like `symbol-queried` may fire if the agent used ripple or navigate tools during the process. The exact count depends on the session's tool usage and hook configuration.
+  - id: q2
+    question: The event stream file at `.paradigm/events/stream.jsonl` grows to 600KB. What happens on the next `emitEvent` call?
+    choices:
+      A: The event is rejected — the file is too large
+      B: The file is deleted and a fresh one is started
+      C: The file is read, only the most recent 1000 lines are kept, and it is rewritten — then the new event is appended
+      D: A second file (`stream-2.jsonl`) is created for overflow
+      E: Nothing special — pruning only happens at startup
+    correct: C
+    explanation: The `pruneIfNeeded` function runs after every `emitEvent` call. When the file exceeds ~500KB (512 * 1024 bytes), it reads all lines, keeps only the most recent 1000 (`lines.slice(-DEFAULT_MAX_EVENTS)`), and rewrites the file. The new event has already been appended before pruning runs, so it is included in the kept lines. This bounded pruning ensures the stream never grows unbounded.
+  - id: q3
+    question: You want to see all compliance violations from the last hour. Which `queryEvents` call is correct?
+    choices:
+      A: '`queryEvents(rootDir, { type: ''compliance-violation'', since: oneHourAgo.toISOString() })`'
+      B: '`queryEvents(rootDir, { source: ''compliance'', limit: 100 })`'
+      C: '`queryEvents(rootDir, { symbol: ''compliance-violation'' })`'
+      D: '`queryEvents(rootDir, { type: ''error-encountered'', agent: ''compliance'' })`'
+      E: '`queryEvents(rootDir)` and filter in application code'
+    correct: A
+    explanation: The `type` filter matches the event classification (`'compliance-violation'` is one of the 12 event types), and the `since` filter restricts to events after the given ISO timestamp. Source `'compliance'` does not exist — valid sources are `post-write-hook`, `mcp-tool-call`, `stop-hook`, `conversation`, `agent-action`, and `error`. The `symbol` filter matches against the event's `symbols` array, not the event type.
+  - id: q4
+    question: File I/O fails when `emitEvent` tries to append to the JSONL file. What happens to the event?
+    choices:
+      A: The event is lost — it was not written anywhere
+      B: An exception is thrown and the calling tool fails
+      C: The event is still stored in the in-memory buffer — file write failure is non-fatal
+      D: The event is written to a fallback file at `/tmp/paradigm-events.jsonl`
+      E: The event is queued and retried on the next `emitEvent` call
+    correct: C
+    explanation: Events are always pushed to the memory buffer (`memoryStream`) before attempting file I/O. The file write is wrapped in a try/catch that silently absorbs failures. This design ensures that ambient coordination continues functioning even if the filesystem is temporarily unavailable. The memory buffer is independently bounded to 1000 events, providing the same capacity as the file-based stream.
+  - id: q5
+    question: A project wants ambient coordination but finds `symbol-queried` events too noisy. How should they configure the event stream?
+    choices:
+      A: 'Set `enabled: false` to disable the entire event stream'
+      B: 'Set `max_events: 100` to reduce the buffer size'
+      C: 'Add `suppress: [''symbol-queried'']` to the EventStreamConfig to silence that event type while keeping all others'
+      D: Remove all `paradigm_search` and `paradigm_navigate` tools from the MCP server
+      E: 'Set `storage: ''memory''` so noisy events are not persisted'
+    correct: C
+    explanation: 'The `suppress` array in `EventStreamConfig` blacklists specific event types. Adding `''symbol-queried''` to this list prevents those events from being emitted while preserving all other event types. This is the targeted solution — `enabled: false` would kill the entire ambient system, `max_events: 100` would reduce history but not noise, and `storage: ''memory''` would affect persistence but not which events fire.'

package/dist/university-content/quizzes/Q-para-601-knowledge-streams.yaml

@@ -0,0 +1,66 @@
+id: Q-para-601-knowledge-streams
+title: 'PARA 601: Paradigm Ambient — Knowledge Streams'
+description: 'Quiz for lesson: Knowledge Streams'
+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 discovers during a session that JWT refresh tokens must be rotated on every use (not just on expiry). This insight applies to every project that uses JWTs. Where should this be recorded?
+    choices:
+      A: Work log — it is work the agent performed
+      B: Team decisions — the team needs to know about JWT rotation
+      C: 'Learning journal with `transferable: true` — it is an agent-learned insight that applies across projects'
+      D: Lore entry with type `agent-session`
+      E: CLAUDE.md as a permanent instruction
+    correct: C
+    explanation: 'This is a learning moment — the agent discovered a pattern (`pattern_discovered` or `correction_received` trigger) that applies beyond the current project. Recording it in the learning journal with `transferable: true` ensures it travels with the agent to future projects via `~/.paradigm/agents/{id}/journal/`. A work log entry would capture what was done but not the reusable insight. A team decision would capture a project-specific choice but not the cross-project pattern.'
+  - id: q2
+    question: Where are learning journal entries stored, and why?
+    choices:
+      A: '`.paradigm/journal/` — project-scoped because learnings are project-specific'
+      B: '`~/.paradigm/agents/{id}/journal/` — user-scoped because learnings travel with the agent across projects'
+      C: '`.paradigm/lore/entries/` — in the same location as all other lore entries'
+      D: '`~/.paradigm/journal/` — global but not agent-specific'
+      E: In memory only — journal entries are ephemeral
+    correct: B
+    explanation: Journal entries are stored at `~/.paradigm/agents/{id}/journal/` — in the user's home directory, scoped to the specific agent. This location is user-scoped (ring 2) rather than project-locked (ring 1) because learning is not project-specific. An insight about JWT handling discovered in project A should be available when the same agent works on project B.
+  - id: q3
+    question: 'A lore entry of type `incident` is recorded with `stream: ''auto''`. Which knowledge streams receive data?'
+    choices:
+      A: Only the work log — incidents are about what happened
+      B: Only the learning journal — incidents are about what was learned
+      C: Work log, learning journal, and team decisions — incidents split across all three streams
+      D: Only team decisions — incidents result in policy changes
+      E: The entry is rejected — incidents cannot use auto-classification
+    correct: C
+    explanation: 'The `LORE_TYPE_TO_STREAM` mapping routes `incident` to all three streams: the work log captures what happened (the incident timeline), the learning journal captures what was learned (failure analysis), and team decisions capture the prevention strategy. This is because incidents naturally contain all three kinds of knowledge — facts about the event, insights from investigation, and decisions about prevention.'
+  - id: q4
+    question: 'A team decision has two participants: `human/matt` with stance `proposed` and `a-paradigm/security` with stance `dissented`. Six months later, the team revisits this decision. Why is the recorded dissent valuable?'
+    choices:
+      A: It proves the human was wrong and the agent was right
+      B: It provides an audit trail for compliance purposes
+      C: It immediately surfaces the security agent's original concerns, saving time re-analyzing the tradeoffs
+      D: It triggers an automatic alert to the security agent
+      E: It prevents the same decision from being proposed again
+    correct: C
+    explanation: Recording dissent captures the counter-arguments at the time of the decision. When the decision is revisited, the team can immediately see what the security agent objected to rather than re-analyzing from scratch. This is especially valuable when the original participants have moved on or forgotten the context. The `dissented` stance does not imply the decision was wrong — it preserves the full deliberation for future reference.
+  - id: q5
+    question: You want to find all work done by the builder agent this sprint that resulted in a `blocked` outcome. Which tool and parameters do you use?
+    choices:
+      A: '`paradigm_lore_search` with `author: ''builder''` and `type: ''agent-session''`'
+      B: '`paradigm_work_log_search` with `agent: ''builder''`, `outcome: ''blocked''`, and `dateFrom` set to sprint start'
+      C: '`paradigm_journal_search` with `agent: ''builder''` and `trigger: ''failure_analysis''`'
+      D: '`paradigm_decision_search` with `participant: ''builder''`'
+      E: '`paradigm_work_log_search` with `summary: true` only'
+    correct: B
+    explanation: '`paradigm_work_log_search` is purpose-built for answering "what got done" questions. Passing `agent: ''builder''`, `outcome: ''blocked''`, and `dateFrom` set to the sprint start date filters to exactly the entries needed. The journal would show what the agent learned, not what work was blocked. The lore search would work but returns the old unified format rather than the structured work log fields like `outcome`, `blockers`, and `next_steps`.'

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.'