@a-company/paradigm 5.37.11 → 6.0.2

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

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

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

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

package/dist/university-content/quizzes/Q-para-501-symphony-a-mail.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-symphony-a-mail
+title: 'PARA 501: Advanced Systems — Symphony: Multi-Agent Messaging with The Score'
+description: 'Quiz for lesson: Symphony: Multi-Agent Messaging with The Score'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: 'You have three Claude Code sessions open on your machine: one working on the core library, one on the backend API, and one on the frontend. You want them to communicate. What is the correct setup sequence?'
+    choices:
+      A: Start a Sentinel hub, then connect each session to the WebSocket endpoint
+      B: Install Conductor, which automatically links all sessions on the machine
+      C: Run `paradigm symphony join` to discover and connect the sessions, then run `/loop 10s paradigm_symphony_poll` in each session
+      D: Create a `.paradigm-workspace` file listing all three projects — workspace linking enables messaging
+      E: Run `paradigm team orchestrate` which automatically sets up inter-agent communication
+    correct: C
+    explanation: The Score is the CLI-only foundation that requires no Conductor, no Sentinel, and no workspace setup. `paradigm symphony join` discovers Claude Code sessions on the machine and creates mailboxes. Then each session needs `/loop 10s paradigm_symphony_poll` to poll for incoming messages. Conductor (B) auto-links sessions but is not required — The Score works standalone.
+  - id: q2
+    question: 'An agent sends a message with `intent: ''decision''` and the text ''Use Redis for session storage instead of in-memory.'' What happens beyond normal message delivery?'
+    choices:
+      A: The message is blocked — only humans can make decisions
+      B: Symphony automatically records a lore entry of type `decision` with the message text, linking it to the conversation thread and referenced symbols
+      C: The message is flagged for human review before delivery
+      D: Nothing special — intent is informational only and has no side effects
+      E: The decision is written to `.paradigm/config.yaml` as a project setting
+    correct: B
+    explanation: 'Messages with `intent: decision` trigger automatic Lore integration. Symphony records a lore entry with the decision text, links it to the conversation thread, and tags it with referenced symbols. This bridges ephemeral conversation to permanent project memory without manual recording.'
+  - id: q3
+    question: Agent A (on your machine) requests `src/types.ts` from Agent B (on a teammate's machine). What must happen before Agent A receives the file?
+    choices:
+      A: Agent B must call `paradigm_symphony_approve_file` — agents can approve their own file requests
+      B: The file is sent automatically since both agents are linked in the same Symphony network
+      C: The teammate (human) must explicitly approve the file transfer — every cross-agent file transfer requires human approval from the file owner's side
+      D: Agent A must have the `^file-access` gate declared in portal.yaml
+      E: The file is sent if it matches the auto-approve glob patterns, but there is no human gate
+    correct: C
+    explanation: The file pipeline's core security constraint is that every file transfer requires explicit human approval from the owner's side. When Agent A requests a file, the teammate sees a prompt (via Conductor or `paradigm symphony requests`) and must approve, deny, or approve with redaction. Even if auto-approve patterns exist in trust.yaml, the initial setup still requires human-configured trust levels.
+  - id: q4
+    question: An agent's `paradigm_symphony_poll` returns 3 new messages in a thread about a failing test. The agent reads them, investigates the code, and finds the bug. How should the agent communicate its findings?
+    choices:
+      A: Call `paradigm_lore_record` with the findings — lore is the communication channel
+      B: 'Call `paradigm_symphony_send` with `intent: ''context''` providing the investigation results, then `intent: ''proposal''` with the fix, writing to `outbox.jsonl` for delivery to the thread'
+      C: Write directly to the other agents' `inbox.jsonl` files for immediate delivery
+      D: Call `paradigm_sentinel_record` to log the bug as an incident
+      E: Call `paradigm symphony send` from the CLI — agents cannot use MCP tools to reply
+    correct: B
+    explanation: Agents communicate via `paradigm_symphony_send`, which writes structured messages to `outbox.jsonl`. Using multiple messages with appropriate intents (context for the investigation, proposal for the fix) gives other agents structured context. Writing directly to inbox files (C) bypasses the routing protocol. Lore (A) and Sentinel (D) are recording systems, not communication channels.
+  - id: q5
+    question: A thread about a serialization bug has been active for 20 minutes across 4 agents. The team agrees on a fix. What should happen next?
+    choices:
+      A: Delete the thread files from `~/.paradigm/score/threads/` to clean up
+      B: Let the thread expire naturally — threads auto-resolve after 1 hour of inactivity
+      C: Run `paradigm symphony resolve <thread-id>` which marks the thread as resolved and automatically creates a lore entry capturing the full conversation, decisions, and actions
+      D: Each agent independently records a lore entry about their contribution
+      E: Run `paradigm_reindex` to incorporate the thread into the project index
+    correct: C
+    explanation: Thread resolution via `paradigm symphony resolve` is the bridge between ephemeral conversation and permanent project memory. It marks the thread as resolved and automatically creates a comprehensive lore entry with the topic, participants, decisions, actions, and referenced symbols. This single action preserves the entire collaborative context for future reference.

package/dist/university-content/quizzes/Q-para-501-symphony-networking.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-symphony-networking
+title: 'PARA 501: Advanced Systems — Symphony Networking: Cross-Machine Relay'
+description: 'Quiz for lesson: Symphony Networking: Cross-Machine Relay'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: net-q1
+    question: Developer A runs `paradigm symphony serve` and sees pairing code 472831. Developer B runs `paradigm symphony join --remote 192.168.1.42:3939`. What happens next?
+    choices:
+      A: Developer B's agents automatically appear in A's inbox
+      B: Developer B is prompted to enter the 6-digit pairing code from A's terminal
+      C: The connection fails because Developer B didn't specify the --public flag
+      D: Developer B must also run `paradigm symphony serve` to create a peer-to-peer link
+      E: Developer B receives A's full agent list immediately without authentication
+    correct: B
+    explanation: 'When connecting via --remote without an embedded code (no # in the address), the user is prompted to enter the 6-digit pairing code displayed on the hub. The code is used to compute an HMAC proof for authentication. Only after successful verification does the agent list exchange occur.'
+  - id: net-q2
+    question: A spoke machine loses its network connection to the hub. What happens?
+    choices:
+      A: All local messages are deleted and the agent must re-pair from scratch
+      B: The spoke immediately attempts to reconnect using a fixed 5-second interval
+      C: The spoke schedules reconnect with exponential backoff (1s → 2s → 4s → ... → 30s max)
+      D: The spoke shuts down and the user must manually restart `paradigm symphony join`
+      E: The hub removes the spoke's peer record from peers.json
+    correct: C
+    explanation: 'The client-mode relay uses exponential backoff for auto-reconnect: starting at 1 second and doubling each attempt up to a maximum of 30 seconds. On successful reconnect, the delay resets to 1 second. Local messages are unaffected — they remain in the JSONL files.'
+  - id: net-q3
+    question: An attacker tries to brute-force the pairing code. After entering 3 wrong codes from IP 10.0.0.5, what happens on the next attempt?
+    choices:
+      A: The pairing code is rotated and a new code must be obtained from the hub
+      B: The hub blocks all incoming connections permanently until restarted
+      C: The connection is accepted but messages are quarantined for review
+      D: The hub sends `auth_fail` with 'Too many failed attempts' and enforces a 60-second cooldown for that IP
+      E: The hub disconnects but allows immediate retry with the correct code
+    correct: D
+    explanation: After 3 failed auth attempts from the same IP address, the relay enforces a 60-second cooldown. During this period, any connection from that IP receives an immediate auth_fail with the message 'Too many failed attempts — try again later' and is disconnected.
+  - id: net-q4
+    question: How does the relay prevent duplicate message delivery when two peers forward the same message?
+    choices:
+      A: Messages include a TTL counter that decrements on each hop
+      B: A bounded Set of seen message IDs (max 10,000) skips already-processed messages
+      C: Each peer maintains a sequence number and only accepts higher-numbered messages
+      D: The hub assigns unique relay IDs to prevent duplicates
+      E: Messages are only forwarded once per minute, allowing time for dedup
+    correct: B
+    explanation: The relay maintains a bounded Set<string> of message IDs it has already processed. When a message arrives, if its ID is in the set, the relay sends an ack but skips delivery. When the set exceeds 10,000 entries, the oldest half is evicted. This prevents both echo (receiving your own message back) and multi-path duplicates.
+  - id: net-q5
+    question: Developer B wants to connect to Developer A's machine over the internet. Developer A runs `paradigm symphony serve --public`. What is the correct command for Developer B?
+    choices:
+      A: '`paradigm symphony join --remote devA.example.com` and enter the code when prompted'
+      B: '`paradigm symphony join --remote 73.162.44.103:3939#847291` with the embedded code'
+      C: '`paradigm symphony serve --connect 73.162.44.103:3939`'
+      D: '`paradigm symphony peers add 73.162.44.103:3939 --code 847291`'
+      E: '`paradigm symphony join --public 73.162.44.103`'
+    correct: B
+    explanation: 'Internet direct connect uses the connection string format: address:port#code. The --public flag on the hub displays this connection string. The spoke parses the embedded code from after the # character and uses it automatically — no interactive prompt needed. Port 3939 must be reachable from the internet (port forward, VPN, or SSH tunnel).'

package/dist/university-content/quizzes/Q-para-501-task-management.yaml

@@ -0,0 +1,46 @@
+id: Q-para-501-task-management
+title: 'PARA 501: Advanced Systems — Task Management'
+description: 'Quiz for lesson: Task Management'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: You are midway through adding authentication when you notice the payment service has a null-check bug. You cannot fix it now. What is the correct action?
+    choices:
+      A: Record a lore entry describing the bug for future reference
+      B: Call `paradigm_task_create` with a blurb describing the null-check bug, priority high, and tags [bug, payments]
+      C: Add a TODO comment in the payment service code and move on
+      D: Call `paradigm_sentinel_record` to log it as an incident
+      E: Mention it in the session's handoff summary and hope the next session picks it up
+    correct: B
+    explanation: This is exactly what tasks are for — capturing work you cannot complete in the current session. A task with priority `high` ensures it surfaces at the top of the next session's recovery data. A lore entry (A) records what happened, not what needs to happen. A TODO comment (C) is invisible to Paradigm. Sentinel (D) is for production incidents. A handoff mention (E) is fragile — tasks are persistent.
+  - id: q2
+    question: A new session starts. The agent calls `paradigm_status`. Among the recovery data, it sees 3 high-priority tasks and 12 medium-priority tasks. How were these surfaced?
+    choices:
+      A: The agent must explicitly call `paradigm_task_list` to see tasks — they are not in recovery data
+      B: All 15 tasks appear in the recovery data automatically
+      C: The top 5 open tasks (sorted by priority then date) are automatically included in recovery data on the first Paradigm tool call
+      D: Only high-priority tasks are surfaced during recovery
+      E: Tasks are only surfaced if the previous session created a handoff
+    correct: C
+    explanation: Session recovery automatically includes the top 5 open tasks, sorted by priority (high first) then by date (newest first). So the agent would see the 3 high-priority tasks plus 2 of the most recent medium-priority tasks. The remaining 10 medium-priority tasks are available via `paradigm_task_list` but are not in the initial recovery data.
+  - id: q3
+    question: Your task list has grown to 35 open items. What should you do?
+    choices:
+      A: Delete the oldest tasks to keep the list manageable
+      B: Increase the session recovery limit from 5 to 35 so all tasks are visible
+      C: 'Triage: shelve low-priority items with `paradigm_task_shelve` and focus on what matters — tasks should not accumulate into a large backlog'
+      D: Convert all tasks to lore entries since the list is too long for task management
+      E: Tasks have no practical limit — 35 is fine, just filter by priority when working
+    correct: C
+    explanation: Tasks are meant to be a lightweight scratch pad, not a project management backlog. When the list grows beyond 20-30 items, it is time to triage. Use `paradigm_task_shelve` to park items that are not immediately relevant. Shelved tasks are not deleted — they remain searchable and can be reopened. This keeps the active list focused and the session recovery data meaningful.

package/dist/university-content/quizzes/Q-para-601-agent-renaissance.yaml

@@ -0,0 +1,66 @@
+id: Q-para-601-agent-renaissance
+title: 'PARA 601: Paradigm Ambient — Agent Manifest Renaissance'
+description: 'Quiz for lesson: Agent Manifest Renaissance'
+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 installed from a marketplace does not define an `intrinsic` learning section but has `platform` learning configured. Is this valid?
+    choices:
+      A: No — all agents must have intrinsic learning configured
+      B: Yes — intrinsic learning is optional (the agent's choice), but platform learning is mandated for marketplace agents
+      C: No — platform learning requires intrinsic learning as a prerequisite
+      D: Yes, but the agent will not be able to participate in ambient coordination
+      E: It depends on whether the agent has attention patterns configured
+    correct: B
+    explanation: 'Intrinsic learning is optional — it represents the agent''s own drive to improve and is a design choice by the agent creator. A marketplace agent might deliberately not implement intrinsic learning if it relies on periodic updates from its creator instead. Platform learning (`feedback_required: true`) is mandated for all marketplace agents to ensure quality signals flow back to creators. The two layers are independent.'
+  - id: q2
+    question: 'A builder agent is in a multi-agent session with an architect. The builder has `collaboration.with.architect.can_contradict: false`. The builder notices the architect''s approach will cause a performance regression. What should happen?'
+    choices:
+      A: The builder stays silent — it cannot contradict the architect
+      B: The builder can still nominate an observation or warning — `can_contradict` affects debate dynamics, not whether the agent can surface concerns
+      C: The builder overrides its collaboration stance because performance is critical
+      D: The builder files a nomination but it is automatically suppressed
+      E: The builder must wait for the reviewer to raise the concern
+    correct: B
+    explanation: 'The `can_contradict` field in collaboration affects debate dynamics — whether the agent will actively argue against the other agent''s position. It does not prevent the agent from surfacing observations or warnings via the nomination system. The builder can still create a nomination with `type: ''warning''` or `type: ''observation''` about the performance regression. The nomination is surfaced to the human, who decides how to proceed. Collaboration stance governs interaction style, not whether an agent can report concerns.'
+  - id: q3
+    question: 'An agent''s context contributions include a section with `priority: ''low''` and `content_ref: ''paradigm://guidance/portal''`. When is this content loaded?'
+    choices:
+      A: Always — all contributions are loaded regardless of priority
+      B: Never — low priority contributions are ignored
+      C: On demand — low priority contributions are loaded only when the agent or human explicitly requests them, not automatically included in composed context
+      D: Only during the first session — subsequent sessions cache it
+      E: Only when the agent's attention score exceeds 0.8
+    correct: C
+    explanation: Context contributions have three priority levels that control inclusion in composed context. High-priority contributions are always included. Medium-priority contributions are included if the token budget allows. Low-priority contributions are loaded only on demand — when the agent requests the resource or the human explicitly asks for it. The `content_ref` URI (`paradigm://guidance/portal`) means the content is fetched from the MCP resource system rather than stored inline, reducing the base context size.
+  - id: q4
+    question: What does `buildProfileEnrichment` produce, and when is it used?
+    choices:
+      A: It produces a YAML file that replaces the agent's `.agent` identity
+      B: It produces structured markdown combining all agent dimensions — identity, expertise, transferable patterns, attention, collaboration, nominations, and ambient context — injected into the agent's prompt during orchestration
+      C: It produces a JSON summary for the Conductor UI dashboard
+      D: It produces a diff between the current agent profile and its defaults
+      E: It produces a compliance report checking all six dimensions
+    correct: B
+    explanation: '`buildProfileEnrichment` takes the agent profile, relevant symbols, optional notebook entries, and optional ambient context (recent decisions, journal insights, pending nominations). It composes a structured markdown string with sections for Agent Identity, Expertise, Transferable Patterns, Notebook Entries, Attention patterns, Collaboration stance, Nomination preferences, and ambient context. This markdown is injected into the agent''s system prompt during orchestration, giving it full self-awareness and situational context.'
+  - id: q5
+    question: 'An agent has `learning.intrinsic.calibration.overconfidence_alert: 0.15` and its estimated confidence for `#auth-middleware` is 0.90 while its actual accuracy (from assessment verdicts) is 0.70. What happens?'
+    choices:
+      A: Nothing — the system does not track actual accuracy
+      B: The confidence is automatically reduced to 0.70
+      C: An overconfidence alert is triggered because the delta (0.90 - 0.70 = 0.20) exceeds the 0.15 threshold
+      D: The agent is prevented from working on `#auth-middleware`
+      E: The EMA alpha is increased to make confidence converge faster
+    correct: C
+    explanation: The `overconfidence_alert` threshold triggers when the gap between estimated confidence and actual accuracy exceeds the configured value. Here, the delta is 0.20 (0.90 - 0.70), which exceeds the 0.15 threshold. This alert signals that the agent is more confident than its track record warrants for this symbol. The agent's confidence will naturally adjust over time via the EMA formula as more assessment verdicts come in, but the alert provides an immediate signal that the agent should be more cautious on `#auth-middleware`.

package/dist/university-content/quizzes/Q-para-601-attention-scoring.yaml

@@ -0,0 +1,56 @@
+id: Q-para-601-attention-scoring
+title: 'PARA 601: Paradigm Ambient — Attention & Scoring'
+description: 'Quiz for lesson: Attention & Scoring'
+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 (threshold 0.4) evaluates an event where a new route was created (`type: ''route-created''`). The agent''s attention includes `signals: [{ type: ''route-created'' }]` but the event has no matching symbols, paths, or concepts. What is the overall score and does the agent nominate?'
+    choices:
+      A: Score 0.25 (average of 0, 0, 0, 1) — does not nominate (below 0.4)
+      B: Score 1.0 (max of 0, 0, 0, 1) — nominates (1.0 >= 0.4)
+      C: Score 0.0 — signal matching requires at least one other dimension to also match
+      D: Score 0.4 — signals are weighted at 0.4 for security agents
+      E: Score 1.0 but does not nominate — signal matches are informational only
+    correct: B
+    explanation: The score is `Math.max(0, 0, 0, 1.0) = 1.0`. Signal match is binary — the event type `'route-created'` matches the agent's signal pattern, so `signalMatch = 1.0`. The overall score uses max, not average, so a single dimension scoring 1.0 gives an overall score of 1.0. Since 1.0 >= 0.4 (the security agent's threshold), the agent self-nominates.
+  - id: q2
+    question: 'A reviewer agent watches 4 concepts: `[''code quality'', ''bug'', ''smell'', ''convention'']`. An event has `keywords: [''code'', ''quality'']` and `context: ''Fixed a bug in the validation logic''`. What is the conceptMatch score?'
+    choices:
+      A: 0.25 — only 'bug' matches (1 out of 4)
+      B: 0.50 — 'code quality' and 'bug' both match (2 out of 4)
+      C: 0.75 — 'code quality', 'bug', and partial 'convention' match
+      D: 1.0 — all keywords are present in the combined text
+      E: 0.0 — concepts must be exact matches against the keywords array only
+    correct: B
+    explanation: 'The event''s `context`, `keywords`, and `type` are joined into a lowercased text: `''code quality fixed a bug in the validation logic''` (keywords `[''code'', ''quality'']` become part of the joined text). The concept `''code quality''` appears in this text (substring match). The concept `''bug''` appears. The concepts `''smell''` and `''convention''` do not. So `matched = 2`, `total = 4`, `conceptMatch = 2/4 = 0.5`.'
+  - id: q3
+    question: Why does scoring use `Math.max` rather than an average of the four dimensions?
+    choices:
+      A: Max is faster to compute than average
+      B: Average would require all four dimensions to have non-zero values, which is too restrictive
+      C: Max ensures a single strong match in any domain-specific dimension is sufficient — averaging would dilute a perfect 1.0 match to 0.25
+      D: Max produces higher scores, making agents more talkative which is always desirable
+      E: The four dimensions are redundant so only the best one matters
+    correct: C
+    explanation: Max-based scoring respects domain-specific expertise. A security agent that matches a gate symbol perfectly (`symbolMatch = 1.0`) should absolutely speak up, even if the file path, concepts, and signals do not match. Averaging would reduce that 1.0 to 0.25, likely below the agent's threshold. Max scoring means that expertise in any single dimension is sufficient to trigger attention.
+  - id: q4
+    question: The security agent's default threshold is 0.4 while the builder's is 0.7. What is the practical effect of this difference?
+    choices:
+      A: The security agent's nominations are ranked higher in the UI
+      B: The security agent self-nominates on weaker matches because the cost of missing a security issue outweighs false alarms — the builder stays quiet unless directly relevant
+      C: The builder processes events faster because it rejects more of them
+      D: The security agent receives more events from the stream
+      E: There is no practical difference — thresholds only affect logging verbosity
+    correct: B
+    explanation: 'A lower threshold means the agent speaks up more often — even on partial matches. For security, this is the right tradeoff: a false alarm about a potential security issue costs little, but missing a real vulnerability can be catastrophic. For the builder, a higher threshold (0.7) means it only self-nominates when the event is strongly relevant to implementation work, avoiding noise from events that are merely tangentially related.'

package/dist/university-content/quizzes/Q-para-601-context-composition.yaml

@@ -0,0 +1,66 @@
+id: Q-para-601-context-composition
+title: 'PARA 601: Paradigm Ambient — Context Composition'
+description: 'Quiz for lesson: Context Composition'
+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 is working on test coverage and calls `paradigm_context_compose`. Which guidance resources are most likely loaded into the composed context?
+    choices:
+      A: All 12 guidance resources — the compose tool always includes everything
+      B: None — guidance resources are never included in composed context
+      C: Only the guidance resources relevant to the task — likely testing-related topics, not portal or orchestration guidance
+      D: Only `paradigm://guidance/troubleshooting` — it is always included
+      E: Whichever resources the agent loaded in the previous session
+    correct: C
+    explanation: '`paradigm_context_compose` selects guidance resources based on the current task and focus area. An agent working on test coverage would benefit from testing-related guidance but not portal conventions or multi-agent orchestration details. The on-demand model means only relevant guidance consumes context window tokens. The agent can always request additional guidance mid-session via the MCP resource URIs if needed.'
+  - id: q2
+    question: 'A security agent has a high-priority context contribution with inline content and a medium-priority contribution with `content_ref: ''paradigm://guidance/portal''`. Token budget is tight. What gets included?'
+    choices:
+      A: Both are included — priority does not affect inclusion
+      B: Only the high-priority contribution is included — the medium-priority contribution is omitted due to token budget constraints
+      C: Only the medium-priority contribution is included because it references official guidance
+      D: Neither is included — contributions are disabled when budget is tight
+      E: Both are included but the medium-priority content is truncated
+    correct: B
+    explanation: High-priority contributions are always included in composed context regardless of token budget. Medium-priority contributions are included only if the token budget allows. When budget is tight, medium and low priority contributions are omitted. The `content_ref` URI remains available — the agent can fetch `paradigm://guidance/portal` later if it discovers it needs portal guidance. This tiered inclusion ensures the most important context always fits.
+  - id: q3
+    question: 'In Session A, a builder records a journal entry with `transferable: true` and a `LearningPattern`. In Session B (different project), the same builder starts working on related code. How does the Session A insight reach Session B''s context?'
+    choices:
+      A: The human manually copies the journal entry to the new project
+      B: The journal entry is stored at `~/.paradigm/agents/builder/journal/` (user-scoped), and `buildProfileEnrichment` includes transferable insights in the composed context when the builder's profile is loaded
+      C: The insight is stored in `.paradigm/lore/` and shared via Symphony networking
+      D: The pattern is automatically added to CLAUDE.md in the new project
+      E: Cross-project transfer is not supported — insights stay in the originating project
+    correct: B
+    explanation: The journal entry is stored at `~/.paradigm/agents/builder/journal/` — a user-scoped location (trust ring 2) that persists across projects. When `paradigm_context_compose` runs in Session B, it loads the builder's profile and calls `buildProfileEnrichment`. This function includes transferable journal insights and patterns in the "Transferable Insights" section of the composed context. The builder in Session B sees the insight before writing any code. No manual copying or network sharing is needed — the user-scoped storage location is the mechanism.
+  - id: q4
+    question: What does `emitAndProcess` do differently from calling `emitEvent` and `scoreEventForAgent` separately?
+    choices:
+      A: It is faster because it batches file I/O
+      B: It unifies event emission with nomination processing in a single call, ensuring no event is emitted without being evaluated — preventing the race condition where scoring happens too late
+      C: It automatically records work log entries for every event
+      D: It skips the memory buffer and writes directly to disk
+      E: There is no functional difference — it is a convenience wrapper
+    correct: B
+    explanation: '`emitAndProcess` ensures atomicity between event emission and nomination processing. If you call `emitEvent` and `scoreEventForAgent` separately, there is a window where an event exists in the stream but has not been evaluated for nominations. Another process might read the event and miss the nominations. `emitAndProcess` emits the event, immediately scores it against all active agents'' attention patterns, and generates nominations for any agent exceeding its threshold — all in one call. It returns both the event and any generated nominations.'
+  - id: q5
+    question: Before v5.0, CLAUDE.md was ~856 lines. After v5.0, it is ~150 lines plus 12 guidance resources. What is the primary benefit?
+    choices:
+      A: The file is easier to edit because it is shorter
+      B: Agents load faster because there is less to parse
+      C: Context window tokens are spent on task-relevant content rather than a static wall of instructions — agents pay the token cost only for guidance they actually use
+      D: The guidance resources are more accurate because they are generated dynamically
+      E: The slim CLAUDE.md can be committed to version control while the old one could not
+    correct: C
+    explanation: The primary benefit is context window efficiency. A 856-line CLAUDE.md consumes thousands of tokens every session, most of which are irrelevant to the current task. The slim CLAUDE.md (~150 lines) provides universal orientation at minimal token cost, and guidance resources are loaded on demand only when needed. An agent working on test coverage does not pay the token cost for portal conventions, logging rules, or orchestration patterns. This leaves more of the context window available for actual code, tool results, and conversation.

package/dist/university-content/quizzes/Q-para-601-data-sovereignty.yaml

@@ -0,0 +1,56 @@
+id: Q-para-601-data-sovereignty
+title: 'PARA 601: Paradigm Ambient — Data Sovereignty'
+description: 'Quiz for lesson: Data Sovereignty'
+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's learning journal entry about JWT refresh token rotation in project A should be available when the same agent works on project B. Which trust ring enables this?
+    choices:
+      A: 'Ring 1: project-locked — journal entries stay in the project'
+      B: 'Ring 2: user-scoped — the journal travels with the agent across the user''s projects'
+      C: 'Ring 3: creator-upstream — the agent creator''s infrastructure bridges projects'
+      D: 'Ring 4: network-public — cross-project sharing requires public access'
+      E: No ring — cross-project sharing is not supported
+    correct: B
+    explanation: Learning journal entries are stored at `~/.paradigm/agents/{id}/journal/` (user-scoped, ring 2). This location is in the user's home directory, not the project directory, so it persists across projects. The same agent identity (`id`) is used across projects, giving the agent access to its own journal entries regardless of which project it is currently working in. Ring 2 is the minimum trust level needed for cross-project travel within the same user's scope.
+  - id: q2
+    question: 'A user creates a `data-policy.yaml` with `observation.deny: [''**/logs/**'']` but does NOT include `.env*` in their deny list. Can agents observe `.env` files?'
+    choices:
+      A: Yes — the user's policy replaces the default, and `.env*` is not in the user's deny list
+      B: No — deny lists are additive on merge. The default `.env*` deny is always present, and the user's `**/logs/**` is added to it
+      C: It depends on whether the agent has an override in `agent_overrides`
+      D: Yes, but the content will be redacted before storage
+      E: No — `.env` files are hardcoded as blocked regardless of policy
+    correct: B
+    explanation: The merge rule states that deny lists are additive, never replacing. The default policy denies `.env*`, `**/*.key`, `**/*.pem`, and `**/secrets/**`. The user's policy adds `**/logs/**` to this list. The merged deny list contains all five patterns. This design prevents users from accidentally exposing secret files by omitting them from their custom policy.
+  - id: q3
+    question: 'A work log entry is recorded with `summary: ''Fixed the API_SECRET_KEY rotation logic in auth.ts''`. The work log stream has `deny_content: [code_snippets]` but allows `file_paths` and `symbol_names`. What happens to the summary?'
+    choices:
+      A: The summary is stored as-is — `API_SECRET_KEY` is a symbol name, not a code snippet
+      B: The entire summary is blocked — it contains a reference to a secret
+      C: The summary is stored as-is because content category filtering only applies to structured fields, not free-text summaries
+      D: If the learning journal's redaction patterns are applied to the work log, `API_SECRET_KEY` would match `\b[A-Z_]{2,}_KEY\b` and be replaced with `[REDACTED]`
+      E: The summary is rejected and the work log entry fails to record
+    correct: D
+    explanation: Redaction patterns are regex-based and applied to content before storage. The pattern `\b[A-Z_]{2,}_KEY\b` matches `API_SECRET_KEY`. If this pattern is configured on the work log stream (or if the filtering function applies cross-stream redaction), the summary would become `'Fixed the [REDACTED] rotation logic in auth.ts'`. In the default policy, this specific redaction is configured on `learning_journal`, not `work_log` — but the `filterContent` function applies whatever redaction patterns are configured for the target stream.
+  - id: q4
+    question: What upstream data is allowed by default in the DEFAULT_DATA_POLICY?
+    choices:
+      A: Everything is allowed upstream — creators need full data for improvement
+      B: Only `task_type`, `outcome`, `helpfulness`, `duration_bucket`, and `error_category` — code, file paths, symbol names, conversation content, and user identity are explicitly denied
+      C: Nothing is allowed — upstream sharing is disabled by default
+      D: File paths and symbol names are allowed, but code content is denied
+      E: Only aggregated statistics, no individual session data
+    correct: B
+    explanation: 'The default upstream rules allow five high-level fields: `task_type` (what kind of work), `outcome` (success/failure), `helpfulness` (user rating), `duration_bucket` (how long it took, bucketed), and `error_category` (what went wrong, categorized). Five categories are explicitly denied: `code_of_any_kind`, `file_paths`, `symbol_names`, `conversation_content`, and `user_identity`. This ensures agent creators get enough signal to improve their agents without receiving any sensitive project data.'