@a-company/paradigm 5.38.0 → 6.0.2

package/dist/university-content/quizzes/Q-para-201-signal-patterns.yaml

@@ -0,0 +1,56 @@
+id: Q-para-201-signal-patterns
+title: 'PARA 201: Architecture — Signal Patterns'
+description: 'Quiz for lesson: Signal Patterns'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-201
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-201.json
+questions:
+  - id: q1
+    question: The order service needs to send a confirmation email after an order is placed. What is the correct architecture?
+    choices:
+      A: The order service directly calls the email service's sendEmail method
+      B: The order service emits !order-placed; the email service listens to that signal
+      C: The email service polls the order service every 5 seconds for new orders
+      D: A $send-email-flow orchestrates the interaction
+      E: The order service includes email logic internally
+    correct: B
+    explanation: Signal-based communication decouples the order service from the email service. The order service emits !order-placed and does not know who listens. The email service independently listens for that signal. This means you can add more listeners (analytics, loyalty points) without touching the order service.
+  - id: q2
+    question: Where are signal listeners documented in Paradigm?
+    choices:
+      A: On the signal definition in the 'listeners' field
+      B: On the listening component in a 'listens' field
+      C: In portal.yaml under a 'listeners' section
+      D: In .paradigm/config.yaml
+      E: They are not documented — only emitters are tracked
+    correct: B
+    explanation: Listeners are documented on the component that listens, using a 'listens' field. This asymmetry is intentional — the emitter declares what it emits (on the signal), and each listener independently declares what it consumes (on the component). This maintains true decoupling.
+  - id: q3
+    question: A failed login attempt from an unknown IP should emit what category of signal?
+    choices:
+      A: business — it affects the user's experience
+      B: system — it is an infrastructure event
+      C: security — it is an authentication event relevant to audit trails
+      D: error — it indicates a system failure
+      E: It should not emit a signal — failed logins are expected
+    correct: C
+    explanation: Failed login attempts are security events. They are critical for audit trails, intrusion detection, and monitoring suspicious activity. The signal (!login-failed) should include data like email, reason, and IP address to support security analysis.
+  - id: q4
+    question: A system currently has !order-placed consumed by 3 listeners. A developer needs to add a Slack notification when orders are placed. What must change?
+    choices:
+      A: The !order-placed signal definition must be updated to list the Slack notifier as an emitter
+      B: The $order-flow must add a Slack notification step
+      C: 'Only the new #slack-notifier component needs a ''listens: ["!order-placed"]'' declaration — nothing else changes'
+      D: 'The #order-service must be modified to call the Slack API'
+      E: portal.yaml must add a ^slack-authorized gate
+    correct: C
+    explanation: This is the power of signal-based decoupling. Adding a new listener requires only defining the new component with its 'listens' field. The signal definition, the emitting component, and all existing listeners remain untouched.

package/dist/university-content/quizzes/Q-para-201-symbol-naming.yaml

@@ -0,0 +1,66 @@
+id: Q-para-201-symbol-naming
+title: 'PARA 201: Architecture — Symbol Naming Conventions'
+description: 'Quiz for lesson: Symbol Naming Conventions'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-201
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-201.json
+questions:
+  - id: q1
+    question: Which of these signal names follows Paradigm naming conventions?
+    choices:
+      A: '!processPayment'
+      B: '!payment-completed'
+      C: '!PaymentSignal'
+      D: '!creating-user'
+      E: '!payment_done'
+    correct: B
+    explanation: 'Signals use kebab-case and past-tense naming: !payment-completed. Option A uses camelCase and imperative mood. C uses PascalCase. D uses progressive tense. E uses underscores instead of hyphens.'
+  - id: q2
+    question: 'A flow that handles user registration from form submission to welcome email should be named:'
+    choices:
+      A: $doRegistration
+      B: $registerUser
+      C: $user-registration-flow
+      D: $REGISTRATION
+      E: $flow_register
+    correct: C
+    explanation: Flows use kebab-case with a noun-flow pattern. $user-registration-flow is descriptive and follows the convention. Imperative names (doRegistration, registerUser), ALL CAPS, and underscores all violate the naming rules.
+  - id: q3
+    question: What is wrong with the gate name `^check1`?
+    choices:
+      A: Nothing — it is valid kebab-case
+      B: Gates must start with a verb
+      C: The number 1 is not allowed in symbol names
+      D: It is non-descriptive — the name should describe what the gate verifies
+      E: Gates must end with '-gate'
+    correct: D
+    explanation: 'Gate names should describe what they verify: ^project-admin, ^email-verified, ^subscription-active. The name ^check1 tells you nothing about what condition is being checked. A developer or AI agent cannot infer the gate''s purpose from its name.'
+  - id: q4
+    question: A component wraps the Stripe API for payment processing. Its class is `StripePaymentClient`. What should its .purpose ID be?
+    choices:
+      A: '#StripePaymentClient'
+      B: '#stripe-payment-client'
+      C: '#stripe_payment_client'
+      D: '#stripePaymentClient'
+      E: '#STRIPE-CLIENT'
+    correct: B
+    explanation: 'All symbol IDs in .purpose files use kebab-case: #stripe-payment-client. The PascalCase class name (StripePaymentClient) is fine in code and descriptions, but the ID must be kebab-case.'
+  - id: q5
+    question: 'Which aspect name reads most naturally in the sentence: ''All financial services are ___''?'
+    choices:
+      A: ~doAudit
+      B: ~auditStuff
+      C: ~audit-required
+      D: ~auditService
+      E: ~the-audit-aspect
+    correct: C
+    explanation: 'Aspect names should read as adjectives or past-participles: ''All financial services are ~audit-required.'' Options A and B are informal/imperative, D sounds like a component name, and E is unnecessarily verbose.'

package/dist/university-content/quizzes/Q-para-301-context-management.yaml

@@ -0,0 +1,56 @@
+id: Q-para-301-context-management
+title: 'PARA 301: Operations — Context Management'
+description: 'Quiz for lesson: Context Management'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: How often should you call paradigm_session_health during a long session?
+    choices:
+      A: Only at the start of the session
+      B: Every 10-15 tool calls
+      C: Only when the AI starts forgetting things
+      D: Once per hour
+      E: Only before handoff
+    correct: B
+    explanation: The recommended cadence for context checks is every 10-15 tool calls. This proactive monitoring lets you prepare for handoff before context is exhausted, rather than discovering the limit when it is too late.
+  - id: q2
+    question: paradigm_session_health returns 'handoff-soon'. What should you do?
+    choices:
+      A: Ignore it and keep working
+      B: Immediately stop all work
+      C: Finish the current task, then call paradigm_handoff_prepare with summary and next steps
+      D: Delete old messages to free up context
+      E: Switch to a model with a larger context window
+    correct: C
+    explanation: When handoff is recommended, prioritize completing the current task (if close to done), then prepare a handoff summary. paradigm_handoff_prepare captures what was done, files modified, next steps, and open questions so the next session can continue seamlessly.
+  - id: q3
+    question: What is the first thing a new AI agent session should do to continue work from a previous session?
+    choices:
+      A: Read every file that was modified
+      B: Call paradigm_session_recover to load breadcrumbs from the previous session
+      C: Start the task from scratch
+      D: Call paradigm_doctor to validate the project
+      E: Run paradigm scan to rebuild the index
+    correct: B
+    explanation: paradigm_session_recover loads the breadcrumbs and handoff summary from the previous session. This tells the new agent what was done, what files were modified, what remains, and any open questions -- enabling seamless continuity.
+  - id: q4
+    question: At what context usage threshold does Paradigm recommend preparing a handoff?
+    choices:
+      A: 50%
+      B: 65%
+      C: 75%
+      D: 85%
+      E: 95%
+    correct: D
+    explanation: When context usage exceeds 85%, Paradigm recommends preparing a handoff. This leaves enough room to complete the current task and create a proper handoff summary without running out of context.

package/dist/university-content/quizzes/Q-para-301-decisions.yaml

@@ -0,0 +1,76 @@
+id: Q-para-301-decisions
+title: 'PARA 301: Operations — The Decision Store'
+description: 'Quiz for lesson: The Decision Store'
+author: paradigm
+created: '2026-04-18'
+updated: '2026-04-18'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: authored
+source: v6.0-content-fix
+questions:
+  - id: q1
+    question: In Paradigm v6.0, where do architectural decisions live?
+    choices:
+      A: '`.paradigm/wisdom/decisions.yaml` — written via `paradigm_wisdom_record({ type: ''decision'', ... })`'
+      B: '`.paradigm/lore/entries/{date}/L-*.yaml` — written via `paradigm_lore_record({ type: ''decision'', ... })`'
+      C: '`.paradigm/decisions/TD-*.yaml` — written via `paradigm_decision_record`, with a companion lore `insight` auto-written for timeline coverage'
+      D: '`.paradigm/history/decisions.jsonl` — written via `paradigm_history_record({ type: ''decision'', ... })`'
+      E: They live in commit messages with the `decision:` trailer
+    correct: C
+    explanation: 'In v6.0 decisions moved to a dedicated topic-addressable store at `.paradigm/decisions/`. Each decision is one `TD-*.yaml` file recorded via `paradigm_decision_record`. A companion lore entry of `type: ''insight''` is auto-written so the timeline still surfaces when the decision was made. Both `paradigm_wisdom_record({type:''decision''})` (A) and `paradigm_lore_record({type:''decision''})` (B) reject with a structured envelope pointing at the new tool.'
+  - id: q2
+    question: You call `paradigm_decision_record` and it succeeds. What gets written to disk?
+    choices:
+      A: Only the `TD-*.yaml` decision file
+      B: The `TD-*.yaml` decision file AND a companion lore `insight` entry with `references.decision_id` back-pointing to the TD- id
+      C: Only the companion lore entry — decisions are stored as a special lore type
+      D: Three files — one in decisions, one in wisdom, one in lore (for backward compat)
+      E: Nothing on disk — decisions are kept in memory only
+    correct: B
+    explanation: 'Two artifacts are written. (1) The canonical decision goes to `.paradigm/decisions/TD-*.yaml` — topic-addressable, with full ADR shape. (2) A companion lore entry of `type: ''insight''` goes to `.paradigm/lore/entries/{date}/L-*.yaml` with `references.decision_id` pointing back at the TD- id and the `companion-lore` + `decision-reference` tags. The lore entry keeps the project timeline complete; the TD- entry stays the source of truth. The companion write is best-effort — a failure to write the lore entry never blocks the decision record.'
+  - id: q3
+    question: 'A teammate has a v5 project with old `type: decision` lore entries in `.paradigm/lore/entries/`. They upgrade to v6.0 and run `paradigm_lore_search`. What happens to those old entries?'
+    choices:
+      A: They disappear — decisions are no longer a valid lore type
+      B: 'They are auto-deleted on the first read after upgrade'
+      C: 'They are remapped to `type: insight` on read and tagged `v6-migrated:from-decision`, so they remain searchable via the tag'
+      D: 'They throw errors and block lore-search until the user manually edits each one'
+      E: 'They are auto-converted into `paradigm_decision_record` entries in `.paradigm/decisions/`'
+    correct: C
+    explanation: 'v1/v2 entries with `type: decision` are remapped to `type: insight` on read with the `v6-migrated:from-decision` tag applied for forensic recovery. The old entries remain searchable (`paradigm_lore_search({ tag: ''v6-migrated:from-decision'' })`). There is no automatic conversion to canonical TD- records (E) — the v1/v2 entries lack the structured participant/alternative data the new shape requires, so promotion to the new store is deliberate, one-by-one.'
+  - id: q4
+    question: 'In v6.0, you call `paradigm_lore_record({ type: ''decision'', title: ''Use Redis'', ... })`. What is the response?'
+    choices:
+      A: 'The entry is recorded successfully — `decision` is still a valid lore type'
+      B: 'A structured rejection envelope (code: ''lore_type_decision_removed'', successor_tool: ''paradigm_decision_record'') so a calling agent can auto-retry against the right tool without human intervention'
+      C: A silent no-op — the call returns success but nothing is written
+      D: The entry is written but flagged as deprecated and hidden from search
+      E: The CLI prompts the user interactively to choose a different type
+    correct: B
+    explanation: 'The storage layer (in `packages/paradigm/src/core/lore/storage.ts`) hard-rejects `type: ''decision''` with a structured rejection envelope. The envelope includes `code: ''lore_type_decision_removed''`, `successor_tool: ''paradigm_decision_record''`, `removed_in: ''6.0.0''`, and `doc: ''docs/private/plans/v6.0-decisions-locked.md''`. Same shape applies if you call `paradigm_wisdom_record({type:''decision''})`. The structured shape lets a calling agent (LLM or script) auto-retry against the right tool — no human in the loop required.'
+  - id: q5
+    question: 'You finish a 40-minute work session that modified 5 files and decided to switch from PostgreSQL to CockroachDB. How should you record this in v6.0?'
+    choices:
+      A: 'Just `paradigm_decision_record` — it covers the choice; no lore needed'
+      B: 'Just `paradigm_lore_record({ type: ''agent-session'' })` with the choice in the `decisions` field'
+      C: 'Both: an `agent-session` lore entry covers the work session; if the DB choice also deserves canonical status (search by symbol, status lifecycle), call `paradigm_decision_record` separately. They are not mutually exclusive.'
+      D: 'Use `paradigm_wisdom_record({ type: ''decision'' })` — wisdom captures team choices'
+      E: 'Use `paradigm_history_record` — DB switches are implementation events'
+    correct: C
+    explanation: 'Lore and decisions are not mutually exclusive. The `agent-session` entry captures the work session (5 files modified, what was learned) — and its `decisions` field can hold a brief reference to the DB switch. If the DB choice also deserves canonical status (you want to search "what did we decide about the user-service database?" later), call `paradigm_decision_record` separately. The TD- entry is the canonical source; the agent-session lore covers "what happened that day." D is invalid in v6 (`paradigm_wisdom_record` rejects `type: ''decision''`).'
+  - id: q6
+    question: What does `paradigm_decision_record` give you that `paradigm_wisdom_record({type:''decision''})` (v5 style) did not?
+    choices:
+      A: Nothing — it is just a rename
+      B: Structured participants with stance enum (proposed/supported/dissented/abstained), structured alternatives_considered with rejected_because, status lifecycle (active/superseded/deprecated/rejected), bidirectional supersede tracking, and an automatic companion lore insight for timeline coverage
+      C: Faster writes — TD- files are smaller than wisdom entries
+      D: Encryption — decisions are encrypted at rest, wisdom was not
+      E: Public-key signing — every decision is cryptographically signed
+    correct: B
+    explanation: 'The new tool brings ADR-shape structure that the wisdom path never had: structured participants with a stance enum, structured alternatives_considered with `rejected_because`, a status lifecycle, bidirectional supersede tracking (`superseded_by` + `supersedes`), and the companion-lore pattern for automatic timeline coverage. None of A/C/D/E are real differences — the win is structured-data discipline plus the companion timeline write.'

package/dist/university-content/quizzes/Q-para-301-doctor-and-validation.yaml

@@ -0,0 +1,66 @@
+id: Q-para-301-doctor-and-validation
+title: 'PARA 301: Operations — Doctor & Validation'
+description: 'Quiz for lesson: Doctor & Validation'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: Which of the following is NOT checked by paradigm doctor?
+    choices:
+      A: Purpose file YAML validity
+      B: Aspect anchor existence
+      C: Portal.yaml gate usage
+      D: JavaScript syntax errors in source code
+      E: Orphaned symbol detection
+    correct: D
+    explanation: 'paradigm doctor validates Paradigm metadata: .purpose files, portal.yaml, aspect anchors, and cross-references. It does not check source code syntax -- that is the job of your language''s compiler or linter.'
+  - id: q2
+    question: An aspect ~rate-limited has an anchor pointing to src/middleware/rate-limit.ts:10-25, but that file was recently renamed. What will paradigm doctor report?
+    choices:
+      A: Nothing -- it only checks YAML syntax
+      B: A warning about unused gates
+      C: An error because the anchor points to a file that no longer exists
+      D: It will automatically update the anchor
+      E: A suggestion to create the file
+    correct: C
+    explanation: Paradigm doctor verifies that aspect anchors point to files and line ranges that actually exist. If the file was renamed, the anchor is broken and doctor will report an error, prompting you to update the anchor.
+  - id: q3
+    question: When is the best time to run paradigm doctor?
+    choices:
+      A: Only during initial project setup
+      B: After major changes and before committing
+      C: Only when errors occur in production
+      D: Once per quarter
+      E: Only when adding new .purpose files
+    correct: B
+    explanation: paradigm doctor should be run after major changes (adding features, refactoring, renaming symbols) and before committing. Many teams also integrate it into pre-commit hooks or CI pipelines to catch metadata drift early.
+  - id: q4
+    question: What does paradigm_flow_check check when checkImplementation is set to true?
+    choices:
+      A: Only YAML syntax of the flow definition
+      B: That flow steps reference existing gates, actions are implemented in code, and signals are defined
+      C: Only that the flow has at least three steps
+      D: That the flow has been tested in production
+      E: Only that gate names match portal.yaml
+    correct: B
+    explanation: 'With checkImplementation enabled, paradigm_flow_check performs a deep check: verifying that gates exist in portal.yaml, that actions described in flow steps have corresponding implementations in the codebase, and that emitted signals are properly defined.'
+  - id: q5
+    question: 'A .purpose file contains: `description: "Handles order processing [NEEDS CLARIFICATION: should cancelled orders trigger refunds?]"`. How do `paradigm doctor` and `paradigm_purpose_validate` treat this marker?'
+    choices:
+      A: As an error that blocks validation and must be fixed immediately
+      B: As a warning that surfaces during checks but does not block validation
+      C: They ignore it completely -- it is just text in a description field
+      D: As an info message that only appears in verbose mode
+      E: As a fatal error that prevents the .purpose file from being parsed
+    correct: B
+    explanation: 'Clarification markers (`[NEEDS CLARIFICATION: ...]`) are treated as warnings, not errors. Both `paradigm doctor` and `paradigm_purpose_validate` scan description fields for this exact pattern and report matches as warnings. They surface during health checks to remind the team of unresolved design questions, but they do not block validation or break builds. Resolve them before shipping.'

package/dist/university-content/quizzes/Q-para-301-enforcement-levels.yaml

@@ -0,0 +1,46 @@
+id: Q-para-301-enforcement-levels
+title: 'PARA 301: Operations — Enforcement Levels'
+description: 'Quiz for lesson: Enforcement Levels'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: Your team is building a healthcare claims processing system that requires audit trails. A new developer joins and asks which enforcement level to use. What do you recommend?
+    choices:
+      A: Minimal — let the new developer learn without friction first
+      B: Balanced — it catches most issues without being too strict
+      C: Strict — healthcare is a regulated domain where every change must be documented and traceable
+      D: Minimal with lore-required overridden to block — just the audit trail matters
+      E: No enforcement — the team should self-police
+    correct: C
+    explanation: Healthcare is a regulated domain where compliance is not optional. Strict enforcement ensures every change has purpose files, portal gates, lore records, and passing drift checks — exactly the traceability an audit requires. The new developer should work within these constraints from day one rather than building habits that strict mode would later break.
+  - id: q2
+    question: Your project uses balanced enforcement but your team never records lore entries, causing constant warnings. What is the best fix?
+    choices:
+      A: Switch to minimal enforcement to silence all warnings
+      B: Override lore-required to off in config.yaml — your team does not need lore yet
+      C: Override lore-required to block — force the team to comply
+      D: Delete the enforcement section from config.yaml entirely
+      E: Ignore the warnings — they are just advisory
+    correct: B
+    explanation: Per-check overrides exist for exactly this situation. If your team is not ready for lore tracking, override lore-required to off rather than downgrading the entire enforcement level. This keeps all other balanced checks active while silencing the one that does not match your current workflow. You can re-enable it later when the team is ready.
+  - id: q3
+    question: A stop hook blocks your commit with "missing .purpose file for src/payments/". You are on balanced enforcement. What happened?
+    choices:
+      A: purpose-exists check failed — the .purpose file has a syntax error
+      B: purpose-coverage check blocked — you modified files in src/payments/ but that directory has no .purpose file
+      C: portal-gates check failed — src/payments/ has unprotected routes
+      D: purpose-freshness check failed — the .purpose file exists but is stale
+      E: aspect-anchors check failed — aspects in src/payments/ have broken anchors
+    correct: B
+    explanation: 'On balanced enforcement, purpose-coverage is the only check set to block (besides habits-blocking). The error message says "missing .purpose file" which means the directory lacks one entirely — that is purpose-coverage, not purpose-exists (which checks that referenced files exist) or purpose-freshness (which checks staleness). Fix: create a .purpose file in src/payments/ describing its components.'

package/dist/university-content/quizzes/Q-para-301-fragility-tracking.yaml

@@ -0,0 +1,46 @@
+id: Q-para-301-fragility-tracking
+title: 'PARA 301: Operations — Fragility & Stability'
+description: 'Quiz for lesson: Fragility & Stability'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: Which factors does Paradigm's fragility analysis consider when computing stability scores?
+    choices:
+      A: Only the number of lines of code
+      B: Change frequency, rollback count, fix-to-feature ratio, and recency of changes
+      C: Only how many rollbacks have occurred
+      D: The number of developers who have modified the symbol
+      E: Test coverage percentage
+    correct: B
+    explanation: 'Fragility analysis considers multiple factors: how frequently the symbol changes, how many rollbacks occurred, the ratio of fixes to features (high fix ratio suggests instability), and how recently changes were made.'
+  - id: q2
+    question: 'You are about to modify #billing-engine, which paradigm_history_fragility reports as fragile. What should you do FIRST?'
+    choices:
+      A: Skip the change entirely
+      B: Refactor the symbol to improve stability
+      C: Read its full history and check team wisdom to understand why it is unstable
+      D: Delete the symbol and start fresh
+      E: Increase the stability score manually
+    correct: C
+    explanation: Before modifying a fragile symbol, you should first understand why it is fragile by reading its history (paradigm_history_context) and checking team wisdom (paradigm_wisdom_context). This context helps you avoid repeating past mistakes.
+  - id: q3
+    question: A symbol has a high count of 'refactor' type events in its history. What might this indicate?
+    choices:
+      A: The symbol is well-maintained and actively improved
+      B: The symbol has excellent test coverage
+      C: Unclear requirements, poor initial design, or a component doing too much
+      D: The symbol is ready for production
+      E: The development team is very productive
+    correct: C
+    explanation: Frequent refactors often indicate underlying issues -- unclear requirements that keep changing, a poor initial design that needs constant adjustment, or a component that has grown beyond its original scope. The fragility system surfaces these patterns for root cause analysis.

package/dist/university-content/quizzes/Q-para-301-history-system.yaml

@@ -0,0 +1,56 @@
+id: Q-para-301-history-system
+title: 'PARA 301: Operations — The History System'
+description: 'Quiz for lesson: The History System'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: Which tool do you use to log an implementation change in Paradigm's history system?
+    choices:
+      A: paradigm_history_context
+      B: paradigm_history_record
+      C: paradigm_wisdom_record
+      D: paradigm_history_fragility
+      E: paradigm_history_validate
+    correct: B
+    explanation: paradigm_history_record is the tool for logging implementation events. paradigm_history_context retrieves existing history, paradigm_wisdom_record captures preferences and antipatterns (architectural decisions go through paradigm_decision_record), and paradigm_history_fragility checks stability scores.
+  - id: q2
+    question: 'In one session you fixed a race condition in #checkout-flow, updated the $payment-flow to add retry logic, and added a new #refund-handler component. How would you record these three changes in the history system?'
+    choices:
+      A: One history_record call with all three changes combined
+      B: Three separate history_record calls — a "fix" for the race condition, a "change" for the flow update, and an "add" for the new component
+      C: Only record the new component — fixes and changes are tracked by git
+      D: Use paradigm_lore_record instead — history is deprecated
+      E: Record only the fix — it is the most important change
+    correct: B
+    explanation: 'The history system supports three change types: "add" (new symbols), "change" (modifications), and "fix" (bug fixes). Each change should be recorded separately so that future history queries can filter by type. Using the right type matters — when someone asks "what broke recently?" they want fixes, not additions.'
+  - id: q3
+    question: Why is the history log append-only?
+    choices:
+      A: To save disk space by avoiding updates
+      B: To make the log faster to write
+      C: To maintain a complete, trustworthy timeline that supports fragility analysis
+      D: Because the file format does not support editing
+      E: To prevent unauthorized modifications
+    correct: C
+    explanation: The append-only design ensures a complete timeline of every change. Nothing is deleted or overwritten, which makes the log trustworthy for computing fragility scores and understanding how symbols evolved over time.
+  - id: q4
+    question: 'Before modifying #user-service, which tool should you call to understand its recent changes?'
+    choices:
+      A: paradigm_history_record
+      B: paradigm_search
+      C: paradigm_history_context
+      D: paradigm_navigate
+      E: paradigm_ripple
+    correct: C
+    explanation: paradigm_history_context retrieves the implementation history for specified symbols. It tells you what changed recently, who worked on it, and how stable the symbol has been -- essential context before making modifications.

package/dist/university-content/quizzes/Q-para-301-navigation-system.yaml

@@ -0,0 +1,56 @@
+id: Q-para-301-navigation-system
+title: 'PARA 301: Operations — Codebase Navigation'
+description: 'Quiz for lesson: Codebase Navigation'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: You need to understand all the components involved in the payment system. Which paradigm_navigate intent should you use?
+    choices:
+      A: find
+      B: explore
+      C: context
+      D: search
+      E: browse
+    correct: B
+    explanation: The "explore" intent browses a functional area. Passing "payments" as the target returns all symbols, files, and structure in the payment domain. "find" is for specific symbol lookup, and "context" is for task-based discovery.
+  - id: q2
+    question: Approximately how many tokens does a paradigm_navigate query cost compared to reading a file?
+    choices:
+      A: About the same -- both are ~2000 tokens
+      B: Navigate costs more -- ~5000 tokens vs ~500 for file reads
+      C: Navigate costs ~100-200 tokens vs ~500-2000 for file reads
+      D: Navigate is free and does not count against token limits
+      E: Navigate costs ~1000 tokens vs ~100 for file reads
+    correct: C
+    explanation: MCP navigation queries cost approximately 100-200 tokens, while reading files costs 500-2000+ tokens depending on file size. This 10x efficiency is why the rule is 'MCP for discovery, file reads for implementation.'
+  - id: q3
+    question: How is navigator.yaml generated?
+    choices:
+      A: You write it manually when setting up the project
+      B: It is generated by paradigm scan from .purpose files
+      C: It is downloaded from the Paradigm registry
+      D: It is created by paradigm doctor as a health check artifact
+      E: It is copied from a template during paradigm shift
+    correct: B
+    explanation: navigator.yaml is generated by running paradigm scan, which reads all .purpose files, analyzes the directory structure, and produces a comprehensive structure map. You do not edit it manually -- it is always regenerated from the source .purpose files.
+  - id: q4
+    question: You want to add a search feature to the dashboard and need to know which files to modify. Which navigate intent is most appropriate?
+    choices:
+      A: 'find -- to locate #dashboard'
+      B: explore -- to browse the dashboard area
+      C: context -- with the task description to get all relevant files and patterns
+      D: Any intent will return the same results
+      E: None -- you should read files directly
+    correct: C
+    explanation: The "context" intent is designed for task-based discovery. Describing your task ('add search feature to dashboard') returns all the relevant files, symbols, and patterns you need. This is more comprehensive than find (specific symbol) or explore (area browsing).

package/dist/university-content/quizzes/Q-para-301-operations-review.yaml

@@ -0,0 +1,66 @@
+id: Q-para-301-operations-review
+title: 'PARA 301: Operations — Operational Excellence'
+description: 'Quiz for lesson: Operational Excellence'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+questions:
+  - id: q1
+    question: What is the correct order for the Paradigm operational loop?
+    choices:
+      A: Implement, validate, discover, orient
+      B: Orient, discover, assess risk, implement, validate, capture knowledge, monitor context
+      C: Discover, implement, commit, deploy
+      D: Assess risk, implement, test, deploy
+      E: Orient, implement, validate
+    correct: B
+    explanation: 'The full operational loop is: Orient (paradigm_status/session_recover), Discover (wisdom_context/navigate), Assess Risk (ripple/fragility), Implement (code + metadata), Validate (doctor/validate), Capture Knowledge (wisdom_record/history_record), Monitor Context (context_check).'
+  - id: q2
+    question: 'You are starting a new session to add a payment retry feature. #payment-service and $checkout-flow are involved. List the tools you should call in order BEFORE writing any code.'
+    choices:
+      A: paradigm_status, then paradigm_history_record
+      B: paradigm_status, paradigm_wisdom_context for both symbols, paradigm_ripple for both symbols, paradigm_history_fragility for flagged dependents
+      C: paradigm_search for 'payment', then start coding
+      D: paradigm_doctor, then start coding
+      E: paradigm_navigate with find intent, then start coding
+    correct: B
+    explanation: 'Before writing code, you should: (1) orient with paradigm_status, (2) check wisdom for the symbols you will modify, (3) run ripple analysis to see the blast radius, and (4) check fragility of any flagged dependents. This is the orient-discover-assess sequence of the operational loop.'
+  - id: q3
+    question: Which of these is a common operational pitfall in Paradigm projects?
+    choices:
+      A: Running paradigm doctor too frequently
+      B: Recording too much history
+      C: Deferring .purpose file updates to 'later', causing metadata to go stale
+      D: Using paradigm_navigate instead of reading files
+      E: Calling paradigm_session_health every 10 tool calls
+    correct: C
+    explanation: 'Deferring metadata updates is one of the most common pitfalls. When .purpose files go stale, navigation becomes misleading, ripple analysis produces incorrect results, and doctor generates false positives. The rule is: update metadata as you code, not after.'
+  - id: q4
+    question: What are the signs of a well-operated Paradigm project?
+    choices:
+      A: Minimal use of Paradigm tools to keep things simple
+      B: Accurate .purpose files, portal.yaml reflecting all protected routes, wisdom entries, history records, and context handoffs
+      C: A large number of .purpose files regardless of accuracy
+      D: No wisdom entries because the team never makes mistakes
+      E: Running paradigm scan before every commit
+    correct: B
+    explanation: A well-operated project has accurate (not just numerous) .purpose files, a portal.yaml that reflects reality, wisdom entries that prevent repeated mistakes, history records that enable fragility analysis, and context handoffs that allow seamless multi-session work.
+  - id: q5
+    question: You finished implementing a feature and discovered that directly modifying shared state outside of the intended pattern causes subtle bugs. What should you do before moving to your next task?
+    choices:
+      A: Just fix the bug and move on
+      B: Record an antipattern with paradigm_wisdom_record, record the implementation with paradigm_history_record, and run paradigm doctor
+      C: Only run paradigm doctor
+      D: Only call paradigm_history_record
+      E: Add a comment in the code and move on
+    correct: B
+    explanation: The capture phase of the operational loop involves recording both the antipattern (so future sessions avoid the same mistake) and the implementation history (so fragility tracking stays current), followed by validation to ensure metadata is consistent.