@a-company/paradigm 5.37.11 → 6.0.2

package/dist/university-content/quizzes/Q-para-201-flows-deep-dive.yaml

@@ -0,0 +1,66 @@
+id: Q-para-201-flows-deep-dive
+title: 'PARA 201: Architecture — Flows in Depth'
+description: 'Quiz for lesson: Flows in Depth'
+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: A controller calls a service, which queries a database and returns a result. Should this be a $flow?
+    choices:
+      A: Yes — any multi-step process should be a flow
+      B: Yes — database queries always require flow documentation
+      C: No — this is a two-component interaction with no sequence ambiguity
+      D: No — flows can only be used for user-facing features
+      E: It depends on whether the service emits a signal
+    correct: C
+    explanation: A flow is warranted when logic spans three or more components in a specific order. A controller calling a service (with its database query) is a straightforward two-component interaction that can be documented on the component itself.
+  - id: q2
+    question: Where should a $checkout-flow be defined if the checkout process starts in the cart module?
+    choices:
+      A: In .paradigm/flows/checkout.yaml
+      B: In portal.yaml under a flows section
+      C: In src/cart/.purpose, since the cart module initiates the flow
+      D: In every .purpose file of every component involved in the flow
+      E: In a standalone checkout-flow.purpose file at the project root
+    correct: C
+    explanation: Flows are defined in the .purpose file of the initiating component's directory. Since the checkout flow starts in the cart module, it belongs in src/cart/.purpose. The flow will reference components from other directories.
+  - id: q3
+    question: 'What does `paradigm_flow_check` with `checkImplementation: true` verify?'
+    choices:
+      A: That the flow executes correctly at runtime
+      B: That referenced components exist in .purpose files, actions are implemented, and signals are emitted
+      C: That the flow has fewer than 10 steps
+      D: That all flows use the same naming convention
+      E: That the flow is referenced in portal.yaml
+    correct: B
+    explanation: 'With checkImplementation: true, the validator performs deep checks: it verifies that referenced #components exist in .purpose files, that the named actions are implemented in the actual codebase, and that listed signals are actually emitted. This catches documentation-code drift.'
+  - id: q4
+    question: What is the fundamental nature of a Paradigm flow?
+    choices:
+      A: A workflow engine that orchestrates service calls at runtime
+      B: A saga implementation with rollback support
+      C: Documentation metadata describing what happens in a sequence, not how to execute it
+      D: A state machine that transitions between components
+      E: An event bus configuration defining message routing
+    correct: C
+    explanation: Flows are documentation, not orchestration. They describe the sequence of operations for humans and AI agents to understand. Your code still handles the actual service calls, error handling, and state management however you choose to implement it.
+  - id: q5
+    question: '`$checkout-flow` lists `relatedFlows: [$payment-flow]` and `$payment-flow` lists `relatedFlows: [$checkout-flow]`. What does `paradigm_flow_check` report?'
+    choices:
+      A: No issues — bidirectional references are valid
+      B: 'A circular dependency: $checkout-flow → $payment-flow → $checkout-flow'
+      C: A missing step error — related flows must appear as steps
+      D: A naming violation — flows cannot reference each other
+      E: A warning about duplicate flow definitions
+    correct: B
+    explanation: When flows reference each other in a cycle via relatedFlows, Paradigm detects it as a circular dependency using depth-first search. The resolution is to extract shared logic into a third flow, remove one direction of the dependency, or replace direct flow references with signal-based communication.

package/dist/university-content/quizzes/Q-para-201-gates-deep-dive.yaml

@@ -0,0 +1,66 @@
+id: Q-para-201-gates-deep-dive
+title: 'PARA 201: Architecture — Gates in Depth'
+description: 'Quiz for lesson: Gates in Depth'
+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: A gate checks whether a user's subscription is active before allowing access to premium content. What type should this gate be?
+    choices:
+      A: auth — it verifies the user's identity
+      B: role — it checks the user's permission level
+      C: ownership — it verifies resource ownership
+      D: state-precondition — it verifies the system is in the right condition
+      E: integration — it checks a third-party service
+    correct: D
+    explanation: This gate verifies system state — whether the subscription is active — rather than identity (auth), permission level (role), or resource ownership. State-precondition gates check conditions about the current state of data.
+  - id: q2
+    question: 'What is wrong with this gate check expression: `check: user is admin`?'
+    choices:
+      A: Nothing — it is clear and concise
+      B: It should use JavaScript syntax, not English
+      C: It is too vague — a developer cannot implement it without more information
+      D: It is missing the req. prefix
+      E: Gate checks must be written in YAML, not pseudo-code
+    correct: C
+    explanation: 'Check expressions should be precise enough to implement from reading the expression. ''user is admin'' does not specify how admin status is determined — is it a boolean field? A role in an array? A separate table? A better expression: project.admins.includes(req.user.id).'
+  - id: q3
+    question: 'A route requires `[^authenticated, ^org-admin, ^billing-enabled]`. The `^org-admin` gate has `requires: [^authenticated]`. What happens at runtime?'
+    choices:
+      A: ^authenticated runs twice — once from the route, once from ^org-admin's requires
+      B: ^authenticated runs once, ^org-admin runs once, ^billing-enabled runs once — in that order
+      C: An error is thrown because ^authenticated is listed both in the route and in requires
+      D: All three gates run in parallel for performance
+      E: Only ^billing-enabled runs because the other two are implicit from requires
+    correct: B
+    explanation: 'Gate chains prevent redundant checks. ^authenticated is required by ^org-admin, but since the route lists ^authenticated first, it runs once and subsequent gates know it already passed. The three gates execute in order: authenticated, org-admin, billing-enabled.'
+  - id: q4
+    question: When should the `effects` field be an empty array `[]`?
+    choices:
+      A: Never — every gate must have at least one prize
+      B: When the gate has no side effects to trigger on pass
+      C: When the gate is of type 'auth'
+      D: When the gate is used on GET routes only
+      E: When the gate has been deprecated
+    correct: B
+    explanation: 'Use effects: [] when the gate has no side effects. Most gates simply allow or deny access without triggering additional actions. Effects are for special cases like gamification badges, onboarding rewards, or analytics events.'
+  - id: q5
+    question: 'portal.yaml says `"DELETE /api/posts/:id": [^authenticated, ^post-author]`, but the route handler only checks authentication, not authorship. What is the consequence?'
+    choices:
+      A: No consequence — portal.yaml is just documentation
+      B: The route will return 403 automatically based on portal.yaml
+      C: Any authenticated user can delete any post — a security vulnerability caused by the implementation not matching the specification
+      D: The paradigm scan command will fix the discrepancy automatically
+      E: The delete will fail silently
+    correct: C
+    explanation: portal.yaml defines what SHOULD happen, but your code must implement it. If the middleware only checks authentication without verifying post authorship, any logged-in user can delete any post. This is a security vulnerability caused by specification-implementation drift.

package/dist/university-content/quizzes/Q-para-201-portal-protocol.yaml

@@ -0,0 +1,56 @@
+id: Q-para-201-portal-protocol
+title: 'PARA 201: Architecture — The Portal Protocol'
+description: 'Quiz for lesson: The Portal Protocol'
+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: You need to add `DELETE /api/teams/:id`. What is the FIRST step in the Portal Protocol?
+    choices:
+      A: Write the delete handler and add authentication middleware
+      B: Add the route to portal.yaml with [^authenticated]
+      C: Call paradigm_gates_for_route to get gate suggestions
+      D: Write a test for the 403 response
+      E: Create a ^team-admin gate in middleware
+    correct: C
+    explanation: The Portal Protocol starts with asking Paradigm. Call paradigm_gates_for_route with the route and method to get suggestions based on existing patterns. This ensures you consider all necessary gates before implementation.
+  - id: q2
+    question: 'Your portal.yaml specifies `"PUT /api/posts/:id": [^authenticated, ^post-author]`. Your middleware only checks ^authenticated. What is the security impact?'
+    choices:
+      A: None — portal.yaml automatically enforces all listed gates
+      B: Any authenticated user can edit any post, because the ^post-author check is missing from the implementation
+      C: The route will return 500 because of the missing gate
+      D: Paradigm will block the request at the framework level
+      E: The post-author gate runs automatically via the requires field
+    correct: B
+    explanation: portal.yaml is a specification, not enforcement. If the middleware does not implement the ^post-author check, any authenticated user can edit any post. This is a security vulnerability caused by the implementation not matching the specification.
+  - id: q3
+    question: In a web API, which HTTP status code should a failed authentication gate return, versus a failed authorization gate?
+    choices:
+      A: Both return 403 Forbidden
+      B: Authentication returns 401 Unauthorized; authorization returns 403 Forbidden
+      C: Authentication returns 403 Forbidden; authorization returns 401 Unauthorized
+      D: Both return 401 Unauthorized
+      E: Authentication returns 400 Bad Request; authorization returns 403 Forbidden
+    correct: B
+    explanation: In the HTTP discipline, the standard distinguishes between authentication (who are you?) and authorization (are you allowed?). A failed auth gate (^authenticated) returns 401 Unauthorized. A failed role/ownership gate (^project-admin) returns 403 Forbidden. Note that this is the web API implementation — other disciplines express gate failure differently (a mobile app might show a login screen or disable a button; a CLI might exit with an error code).
+  - id: q4
+    question: Why does the Portal Protocol require defining gates BEFORE writing handler code?
+    choices:
+      A: Because Paradigm cannot parse handler code that already exists
+      B: Because it creates an auditable specification separate from implementation, preventing conditions as an afterthought
+      C: Because TypeScript requires gate types to be defined before use
+      D: Because AI agents refuse to write code without portal.yaml
+      E: Because gate middleware must be loaded before route handlers in the server stack
+    correct: B
+    explanation: The Portal Protocol's core principle is specification before implementation. By specifying gates in portal.yaml first, you create an auditable specification that is separate from (and checkable against) the implementation. This prevents the common pattern of building features first and bolting on checks later.

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.