@a-company/paradigm 5.38.0 → 6.0.2

package/dist/university-content/quizzes/Q-plsat-v3.yaml

@@ -0,0 +1,2909 @@
+id: Q-plsat-v3
+title: The PLSAT — Paradigm Licensure Standardized Assessment Test
+description: 99 questions. 90 minutes. 90% to pass. Good luck, scholar.
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - plsat
+  - certification
+symbols: []
+difficulty: advanced
+passThreshold: 0.9
+timeLimit: 5400
+totalSlots: 128
+exam:
+  kind: proctored
+category: paradigm-core
+origin: imported
+source: plsat/v3.0.json
+questions:
+  - id: plsat-001
+    scenario: You've just joined a team that uses Paradigm. You open the project and see directories like `.paradigm/`, several `.purpose` files, and a `portal.yaml` at the root. A colleague asks you to document a new utility function they wrote in `src/lib/format-currency.ts`.
+    question: Which symbol prefix should you use to document this utility?
+    choices:
+      A: '`$format-currency` — because it describes a process (formatting)'
+      B: '`!format-currency` — because it signals a transformation event'
+      C: '`#format-currency` — because it is a documented code unit'
+      D: '`~format-currency` — because it applies a rule (formatting rules)'
+      E: '`^format-currency` — because it gates what format is allowed'
+    correct: C
+    explanation: In Paradigm, every documented code unit uses the `#` (Component) symbol. There are only 5 operational symbols, and `#` is the universal prefix for any code unit — utilities, services, handlers, components, hooks, you name it. `$` is for multi-step flows, `!` for signals/events, `~` for aspects with code anchors, and `^` for condition gates. A simple utility function is a component.
+    slot: slot-001
+    section: para-101
+    variants:
+      - id: plsat-001b
+        scenario: A teammate wrote a helper function in `src/utils/validate-email.ts` that checks email format. They want to document it in Paradigm but aren't sure which symbol to use.
+        question: Which symbol prefix is correct for documenting this utility?
+        choices:
+          A: '`$validate-email` — it describes a validation process'
+          B: '`!validate-email` — it signals whether an email is valid'
+          C: '`#validate-email` — it is a documented code unit'
+          D: '`~validate-email` — it enforces a validation rule'
+          E: '`^validate-email` — it gates what emails are accepted'
+        correct: C
+        explanation: 'Every documented code unit in Paradigm uses the `#` (Component) symbol. A utility function is a code unit — it gets `#`. The other symbols have specific meanings: `$` for multi-step flows, `!` for signals/events, `~` for aspects with code anchors, and `^` for condition gates.'
+  - id: plsat-002
+    scenario: A component manages user authentication state — tracking the current user, login status, and session tokens. You need to document it in a `.purpose` file.
+    question: How should this component be documented in Paradigm?
+    choices:
+      A: '`#auth-state` with no tags — the component name is descriptive enough'
+      B: '`#auth-state` with `tags: [state]` — the `[state]` tag classifies its role'
+      C: '`!auth-state` — authentication state changes should be modeled as signals'
+      D: '`$auth-state` — state management is a multi-step flow'
+      E: '`~auth-state` — authentication state is a cross-cutting concern requiring an aspect'
+    correct: B
+    explanation: State management components use the `#` (Component) symbol with a `[state]` tag from the tag bank. Paradigm uses only 5 operational symbols for structure, and a tag bank for classification. The `[state]` tag tells humans and AI agents that this component's primary role is managing state, while `#` identifies it as a documented code unit. Signals (`!`) are for events, flows (`$`) are for multi-step processes, and aspects (`~`) are for enforced rules with code anchors.
+    slot: slot-002
+    section: para-101
+  - id: plsat-003
+    scenario: Your team is debating logging practices. One developer argues that using `console.log` everywhere is fine because logs are just for debugging. Another insists on using structured, symbol-aware logging with Paradigm's logger (e.g., `log.component('#checkout-service').info('Processing payment', { amount })`).
+    question: What is the STRONGEST argument for using Paradigm's structured logger over raw `console.log`?
+    choices:
+      A: Structured logging is faster at runtime than `console.log`
+      B: Paradigm's logger automatically fixes bugs when it detects errors in the logs
+      C: Symbol-aware logging connects runtime behavior to the documented architecture, making it possible to trace issues back to specific components, flows, and gates
+      D: Using `console.log` will cause Paradigm's CI checks to fail
+      E: Structured logging is required by law for production applications
+    correct: C
+    explanation: 'The core value of Paradigm''s structured logger is traceability: every log line is tagged with a symbol (`#component`, `^gate`, `!signal`, etc.), which means you can correlate runtime behavior with the architectural documentation. When something goes wrong, you can trace from the log back to the component in the `.purpose` file, understand its flows, check its gates, and review its history. Raw `console.log` loses this connection. Performance (A) is not the primary benefit. Paradigm doesn''t auto-fix bugs (B) or enforce logging by law (E). CI checks (D) depend on team configuration, not a universal rule.'
+    slot: slot-003
+    section: para-101
+    variants:
+      - id: plsat-003b
+        scenario: During a code review, you notice a developer replaced all `log.component('#user-service').info(...)` calls with plain `console.log(...)` to 'simplify things.' The PR has 15 files changed.
+        question: What is the MOST important reason to reject this change?
+        choices:
+          A: '`console.log` is slower than Paradigm''s structured logger'
+          B: Paradigm's logger automatically prevents bugs in production
+          C: Removing symbol-aware logging breaks the connection between runtime behavior and documented architecture, making it impossible to trace issues to specific components
+          D: The CI pipeline requires Paradigm logger calls to pass
+          E: It violates JavaScript best practices to use `console.log`
+        correct: C
+        explanation: The fundamental value of Paradigm's structured logger is traceability. Each log line tagged with a symbol (#, ^, !, etc.) creates a bridge between runtime behavior and the architectural documentation. Removing this breaks the ability to trace from a log entry back to a component, its flows, gates, and history in .purpose files.
+  - id: plsat-004
+    scenario: You're setting up a brand new project with Paradigm. You run `paradigm shift` and it creates the `.paradigm/` directory structure. Your project will have a REST API with several endpoints that require condition checks — such as authentication, feature flags, and rate limiting.
+    question: Which file MUST you create at the project root?
+    choices:
+      A: '`auth.yaml` — Paradigm''s dedicated authentication config'
+      B: '`gates.yaml` — where all `^gate` definitions live'
+      C: '`portal.yaml` — where gates and protected routes are defined'
+      D: '`.paradigm/security.yaml` — security config goes in the paradigm directory'
+      E: No file needed — gates are defined inline in `.purpose` files only
+    correct: C
+    explanation: '`portal.yaml` is REQUIRED at the project root whenever your project has protected routes. It defines gates (`^` symbols) with their check expressions, and maps routes to the gates that protect them. Gates can represent any condition checkpoint — authentication, authorization, feature flags, rate limits, or custom business rules. Gates can also appear in `.purpose` files for documentation, but `portal.yaml` is the authoritative source for route protection.'
+    slot: slot-004
+    section: para-101
+  - id: plsat-006
+    scenario: |-
+      Your team uses the following directory structure:
+
+      ```
+      src/
+        middleware/auth.ts
+        events/payment-events.ts
+        services/billing.ts
+        flows/onboarding.ts
+        aspects/rate-limiter.ts
+      ```
+
+      A new developer asks which Paradigm logger method to use in each file. Your team follows the conventional directory-to-symbol mapping as a guideline.
+    question: Which file-to-logger mapping is INCORRECT?
+    choices:
+      A: '`middleware/auth.ts` → `log.gate(''^auth-check'')`'
+      B: '`events/payment-events.ts` → `log.signal(''!payment-received'')`'
+      C: '`services/billing.ts` → `log.component(''#billing-service'')`'
+      D: '`flows/onboarding.ts` → `log.signal(''!onboarding-started'')`'
+      E: '`aspects/rate-limiter.ts` → `log.aspect(''~rate-limited'')`'
+    correct: D
+    explanation: 'Files in the `flows/` directory conventionally correspond to `$` (Flow) symbols and should use `log.flow()`, not `log.signal()`. The correct call would be `log.flow(''$onboarding'').info(...)`. The conventional directory-to-symbol mapping is: middleware/auth/guards → `^` (gate), events/handlers/listeners → `!` (signal), services/lib/components → `#` (component), flows/sagas/workflows → `$` (flow), aspects/rules → `~` (aspect). While teams may adapt these conventions to their needs, this mapping provides a consistent default that helps developers and AI agents reason about the codebase.'
+    slot: slot-006
+    section: para-101
+    variants:
+      - id: plsat-006b
+        scenario: Your team follows directory-to-symbol conventions. A new file `src/guards/feature-flags.ts` is created to check whether features are enabled before allowing access. A developer uses `log.component('#feature-flags')` in the file.
+        question: Is this logger usage correct according to conventional directory mapping?
+        choices:
+          A: Yes — all code units use `log.component()`
+          B: No — `guards/` maps to `^` (gate), so it should be `log.gate('^feature-flags')`
+          C: No — feature flags are signals, so it should be `log.signal('!feature-flags')`
+          D: No — feature flags are aspects, so it should be `log.aspect('~feature-flags')`
+          E: Yes — but the symbol should be `#feature-flags-guard` for clarity
+        correct: B
+        explanation: The `guards/` directory conventionally maps to `^` (gate) symbols and should use `log.gate()`. Guards, middleware, and auth directories all map to gates because they represent condition checkpoints. Feature flags check conditions before allowing access — that's a gate. The correct call is `log.gate('^feature-flags').info(...)`.
+  - id: plsat-007
+    scenario: Your team is prototyping a new feature — an experimental search widget that may or may not ship. You've built the component and want to document it in a `.purpose` file. You also want to make it clear to other developers and AI agents that this is an idea in progress, not a committed part of the product.
+    question: How should you classify this component to indicate it is experimental?
+    choices:
+      A: Use a special `?experimental-widget` symbol prefix reserved for ideas
+      B: 'Add `status: experimental` to the component definition'
+      C: 'Add the `[idea]` tag to the component: `tags: [idea]`'
+      D: Create an aspect `~experimental` and apply it to the component
+      E: Comment it out in the `.purpose` file with `# EXPERIMENTAL`
+    correct: C
+    explanation: 'Paradigm''s tag bank includes the `[idea]` tag for exactly this purpose. You''d define the component as `#experimental-widget` with `tags: [idea]`. Tags are the classification layer in Paradigm: the 5 operational symbols (`#`, `$`, `^`, `!`, `~`) provide structure, while tags from the tag bank provide classification metadata like `[idea]`, `[feature]`, `[state]`, `[integration]`, `[critical]`, etc. Choice B (status field) is plausible but `status` is typically for lifecycle states like `active` or `deprecated`, not for ideation. There is no `?` symbol prefix in Paradigm (A). Commenting it out (E) removes it from the symbol graph entirely.'
+    slot: slot-007
+    section: para-101
+  - id: plsat-008
+    scenario: 'A `.paradigm/tags.yaml` file has three sections: `core`, `project`, and `suggested`. The `core` section contains tags like `[feature]`, `[integration]`, `[state]`, `[critical]`, and `[security]`.'
+    question: What is the `suggested` section for?
+    choices:
+      A: Tags that Paradigm automatically generates based on code analysis
+      B: Tags proposed by AI agents awaiting human approval before use
+      C: Tags from the Paradigm community marketplace that can be installed
+      D: Tags that are deprecated and will be removed in the next version
+      E: Tags that the framework suggests but are optional to implement
+    correct: B
+    explanation: 'The `suggested` section in `tags.yaml` holds tags proposed by AI agents (via `paradigm_tags_suggest`) that haven''t been approved by a human yet. This is part of Paradigm''s governance model: AI can propose new classifications, but a human must promote them to `project` or `core` before they become official. This prevents tag sprawl and keeps the taxonomy intentional. The `core` tags ship with Paradigm, `project` tags are team-defined, and `suggested` are AI proposals awaiting review.'
+    slot: slot-008
+    section: para-101
+  - id: plsat-009
+    scenario: |-
+      You're reading a project's `.paradigm/config.yaml` and see:
+
+      ```yaml
+      discipline: fullstack
+      conventions:
+        naming: kebab-case
+        components: PascalCase
+      ```
+    question: Based on these conventions, which symbol ID is correctly formatted?
+    choices:
+      A: '`#paymentService` — camelCase for services'
+      B: '`#payment-service` — kebab-case for IDs, PascalCase for class-like references'
+      C: '`#Payment_Service` — PascalCase with underscores'
+      D: '`#PAYMENT_SERVICE` — SCREAMING_SNAKE for services'
+      E: '`#payment.service` — dot notation for namespaced components'
+    correct: B
+    explanation: 'Paradigm conventions specify kebab-case for all symbol IDs. The `components: PascalCase` convention means that when referring to class-like components in prose or code, you use PascalCase (e.g., `#PaymentService`), but the canonical ID in `.purpose` files is kebab-case (`#payment-service`). This dual convention is documented in the CLAUDE.md: ''Use kebab-case for all symbol IDs'' and ''Use PascalCase for class-like components''.'
+    slot: slot-009
+    section: para-101
+  - id: plsat-011
+    scenario: 'You''re designing an e-commerce checkout process that involves: (1) validating the cart, (2) checking inventory, (3) processing payment via Stripe, (4) creating the order record, and (5) sending a confirmation email. This spans 5 different components across 3 directories.'
+    question: How should this be documented in Paradigm?
+    choices:
+      A: As a single `#checkout` component with sub-steps in its description
+      B: As a `$checkout-flow` with ordered steps referencing each component
+      C: As five separate `!` signals chained together
+      D: As a `~checkout-required` aspect applied to all five components
+      E: As five `^` gates that must be passed sequentially
+    correct: B
+    explanation: 'A multi-step process spanning 3+ components is the textbook definition of a Flow (`$`). You''d define `$checkout-flow` with ordered steps, each referencing the responsible component and action: `#cart-validator` validates, `#inventory-checker` checks stock, `#stripe-service` processes payment, `#order-service` creates the record, `#email-sender` confirms. Flows document the sequence and make it visible to `paradigm_flows_affected` for impact analysis. Signals (`!`) may be emitted during the flow, but they don''t define the sequence.'
+    slot: slot-011
+    section: para-201
+    variants:
+      - id: plsat-011b
+        scenario: 'Your team is building a user registration process: (1) validate form input, (2) check if email is taken, (3) hash the password, (4) create the user record, (5) send a welcome email, (6) trigger analytics. This spans components across `validators/`, `services/`, and `integrations/`.'
+        question: What is the correct Paradigm symbol for documenting this process?
+        choices:
+          A: '`#user-registration` — it''s a single feature component'
+          B: '`$user-registration` — it''s a multi-step flow spanning multiple components'
+          C: '`!user-registered` — it''s an event that triggers side effects'
+          D: '`~registration-required` — it''s a cross-cutting concern'
+          E: '`^registration-valid` — it''s a validation gate'
+        correct: B
+        explanation: A multi-step process spanning 3+ components is a Flow (`$`). You'd define `$user-registration` with ordered steps referencing each responsible component. Flows make the sequence visible for impact analysis via `paradigm_flows_affected`. While `!user-registered` might be emitted at the END of the flow, the process itself is the flow.
+  - id: plsat-pg1-q1a
+    scenario: ''
+    question: A new endpoint `DELETE /api/projects/:id` needs to be added. Only project admins should be able to delete projects. What is the correct route entry in portal.yaml?
+    choices:
+      A: '`"DELETE /api/projects/:id": [^authenticated, ^project-admin]`'
+      B: '`"DELETE /api/projects/:id": [^project-admin]`'
+      C: '`"DELETE /api/projects/:id": [^authenticated]`'
+      D: '`"DELETE /api/projects/:id": [^project-admin, ^authenticated]`'
+      E: '`"DELETE /api/projects/:id": [^admin]`'
+    correct: B
+    explanation: 'Since `^project-admin` already has `requires: ["^authenticated"]`, listing `^authenticated` in the route is redundant. The gate dependency chain means `^project-admin` will automatically enforce `^authenticated` first. The route only needs to specify `[^project-admin]`.'
+    slot: pg-portal-q1
+    section: para-201
+    passageId: passage-portal-review
+    passage: |-
+      Your team's portal.yaml for a project management app:
+
+      ```yaml
+      version: "1.0"
+      gates:
+        ^authenticated:
+          description: User must be logged in
+          check: req.user != null
+        ^project-member:
+          description: User must be a member of the project
+          check: project.members.includes(req.user.id)
+          requires: ["^authenticated"]
+        ^project-admin:
+          description: User must be an admin of the project
+          check: project.admins.includes(req.user.id)
+          requires: ["^authenticated"]
+        ^comment-author:
+          description: User must be the comment author
+          check: comment.authorId === req.user.id
+
+      routes:
+        "GET /api/projects": [^authenticated]
+        "POST /api/projects": [^authenticated]
+        "GET /api/projects/:id": [^authenticated, ^project-member]
+        "PUT /api/projects/:id": [^project-admin]
+        "DELETE /api/projects/:id": [^project-admin]
+        "POST /api/projects/:id/comments": [^authenticated, ^project-member]
+      ```
+  - id: plsat-pg1-q2a
+    scenario: ''
+    question: 'A colleague adds a new endpoint: `DELETE /api/projects/:id/comments/:commentId`. Only the comment author should be able to delete their own comment. Which gate configuration follows Paradigm best practices?'
+    choices:
+      A: Add `[^authenticated, ^project-admin]` — admins can delete anything
+      B: Add `[^authenticated, ^project-member, ^comment-author]` — must be a member AND the author
+      C: Add `[^comment-author]` — authorship implies authentication and membership
+      D: Add `[^authenticated, ^comment-author]` — logged in and owns the comment
+      E: Don't add it to portal.yaml — handle it in the route handler code only
+    correct: B
+    explanation: 'The correct approach is `[^authenticated, ^project-member, ^comment-author]`. Being the comment author doesn''t automatically mean you''re authenticated or a project member. Each gate has one responsibility: `^authenticated` checks login, `^project-member` checks project access, `^comment-author` checks ownership. Choice E violates the cardinal rule: all protected routes MUST be in portal.yaml.'
+    slot: pg-portal-q2
+    section: para-201
+    passageId: passage-portal-review
+    passage: |-
+      Your team's portal.yaml for a project management app:
+
+      ```yaml
+      version: "1.0"
+      gates:
+        ^authenticated:
+          description: User must be logged in
+          check: req.user != null
+        ^project-member:
+          description: User must be a member of the project
+          check: project.members.includes(req.user.id)
+          requires: ["^authenticated"]
+        ^project-admin:
+          description: User must be an admin of the project
+          check: project.admins.includes(req.user.id)
+          requires: ["^authenticated"]
+        ^comment-author:
+          description: User must be the comment author
+          check: comment.authorId === req.user.id
+
+      routes:
+        "GET /api/projects": [^authenticated]
+        "POST /api/projects": [^authenticated]
+        "GET /api/projects/:id": [^authenticated, ^project-member]
+        "PUT /api/projects/:id": [^project-admin]
+        "DELETE /api/projects/:id": [^project-admin]
+        "POST /api/projects/:id/comments": [^authenticated, ^project-member]
+      ```
+  - id: plsat-pg1-q3a
+    scenario: ''
+    question: Looking at the existing routes, the `PUT /api/projects/:id` route uses `[^project-admin]` without `^authenticated`. Is this a problem?
+    choices:
+      A: Yes — every route must explicitly list `^authenticated` for security
+      B: 'No — `^project-admin` has `requires: ["^authenticated"]`, so authentication is enforced implicitly'
+      C: Yes — the `requires` field is only documentation, not enforcement
+      D: No — PUT requests don't need authentication because they're idempotent
+      E: Yes — portal.yaml should always list gates in order of evaluation
+    correct: B
+    explanation: 'This is correct portal.yaml usage. The `^project-admin` gate has `requires: ["^authenticated"]`, which means authentication is automatically enforced as a prerequisite. Listing `^authenticated` explicitly would be redundant. The `requires` field creates a dependency chain that gates must satisfy before evaluation.'
+    slot: pg-portal-q3
+    section: para-201
+    passageId: passage-portal-review
+    passage: |-
+      Your team's portal.yaml for a project management app:
+
+      ```yaml
+      version: "1.0"
+      gates:
+        ^authenticated:
+          description: User must be logged in
+          check: req.user != null
+        ^project-member:
+          description: User must be a member of the project
+          check: project.members.includes(req.user.id)
+          requires: ["^authenticated"]
+        ^project-admin:
+          description: User must be an admin of the project
+          check: project.admins.includes(req.user.id)
+          requires: ["^authenticated"]
+        ^comment-author:
+          description: User must be the comment author
+          check: comment.authorId === req.user.id
+
+      routes:
+        "GET /api/projects": [^authenticated]
+        "POST /api/projects": [^authenticated]
+        "GET /api/projects/:id": [^authenticated, ^project-member]
+        "PUT /api/projects/:id": [^project-admin]
+        "DELETE /api/projects/:id": [^project-admin]
+        "POST /api/projects/:id/comments": [^authenticated, ^project-member]
+      ```
+  - id: plsat-pg2-q1a
+    scenario: ''
+    question: What is the correct way to reference `#email-sender` from another `.purpose` file in a different directory?
+    choices:
+      A: '`notifications/#email-sender` — use the directory path as a namespace'
+      B: '`#email-sender` — symbol IDs are globally unique across the project'
+      C: '`&email-sender` — integrations use the `&` prefix when cross-referenced'
+      D: '`#notifications.email-sender` — use dot notation for cross-module references'
+      E: '`import: #email-sender from notifications` — use import syntax'
+    correct: B
+    explanation: Symbol IDs are globally unique across the entire Paradigm project. You reference `#email-sender` the same way everywhere — no namespacing, no path prefixes, no import syntax. Paradigm's index tracks where each symbol is defined.
+    slot: pg-purpose-q1
+    section: para-101
+    passageId: passage-purpose-review
+    passage: |-
+      You're reviewing a `.purpose` file submitted in a pull request for `src/notifications/`:
+
+      ```yaml
+      name: Notifications
+      components:
+        #email-sender:
+          description: Sends transactional emails
+          file: email.ts
+          tags: [integration, sendgrid]
+        #push-notifier:
+          description: Sends push notifications
+          file: push.ts
+        #notification-preferences:
+          description: User notification settings
+          file: preferences.ts
+          tags: [state]
+      signals:
+        !notification-sent:
+          description: Fires after any notification is delivered
+          emitters: ["#email-sender", "#push-notifier"]
+        !preferences-updated:
+          description: User changed notification settings
+          emitters: ["#notification-preferences"]
+      ```
+  - id: plsat-pg2-q2a
+    scenario: ''
+    question: This `.purpose` file is missing a critical top-level field. What is it?
+    choices:
+      A: '`version` — every purpose file must specify a schema version'
+      B: '`description` — every purpose file should describe what the module does'
+      C: '`tags` — top-level tags are required for indexing'
+      D: '`gates` — every module must define its authorization requirements'
+      E: '`flows` — signals require at least one flow to be meaningful'
+    correct: B
+    explanation: Every `.purpose` file should have a `description` field explaining what the module/directory does. While `name` identifies it, `description` provides the context that AI agents and developers need to understand the module's role.
+    slot: pg-purpose-q2
+    section: para-101
+    passageId: passage-purpose-review
+    passage: |-
+      You're reviewing a `.purpose` file submitted in a pull request for `src/notifications/`:
+
+      ```yaml
+      name: Notifications
+      components:
+        #email-sender:
+          description: Sends transactional emails
+          file: email.ts
+          tags: [integration, sendgrid]
+        #push-notifier:
+          description: Sends push notifications
+          file: push.ts
+        #notification-preferences:
+          description: User notification settings
+          file: preferences.ts
+          tags: [state]
+      signals:
+        !notification-sent:
+          description: Fires after any notification is delivered
+          emitters: ["#email-sender", "#push-notifier"]
+        !preferences-updated:
+          description: User changed notification settings
+          emitters: ["#notification-preferences"]
+      ```
+  - id: plsat-pg2-q3a
+    scenario: ''
+    question: A developer wants to add a new component `#sms-sender` to this module that sends SMS via Twilio. Which definition follows the existing patterns in this file?
+    choices:
+      A: '`#sms-sender: { description: Sends SMS, file: sms.ts, tags: [integration, twilio] }` and add it to `!notification-sent` emitters'
+      B: '`!sms-sent: { description: SMS notification signal }` — SMS is an event'
+      C: '`#sms-sender: { description: Sends SMS, file: sms.ts }` with no tags or signal updates'
+      D: '`~sms-required: { description: SMS must be available }` — SMS availability is an aspect'
+      E: '`$sms-flow: { description: Send SMS process }` — sending SMS is a flow'
+    correct: A
+    explanation: 'Following the file''s existing pattern: `#email-sender` has `tags: [integration, sendgrid]` and is listed in `!notification-sent` emitters. The new `#sms-sender` should mirror this: use `tags: [integration, twilio]` for classification and add it as an emitter of `!notification-sent`. Consistency with existing patterns is key.'
+    slot: pg-purpose-q3
+    section: para-101
+    passageId: passage-purpose-review
+    passage: |-
+      You're reviewing a `.purpose` file submitted in a pull request for `src/notifications/`:
+
+      ```yaml
+      name: Notifications
+      components:
+        #email-sender:
+          description: Sends transactional emails
+          file: email.ts
+          tags: [integration, sendgrid]
+        #push-notifier:
+          description: Sends push notifications
+          file: push.ts
+        #notification-preferences:
+          description: User notification settings
+          file: preferences.ts
+          tags: [state]
+      signals:
+        !notification-sent:
+          description: Fires after any notification is delivered
+          emitters: ["#email-sender", "#push-notifier"]
+        !preferences-updated:
+          description: User changed notification settings
+          emitters: ["#notification-preferences"]
+      ```
+  - id: plsat-014
+    scenario: 'You''re implementing a webhook handler that receives events from a third-party payment provider. When a payment succeeds, your system needs to: update the order status, send a receipt email, and notify the analytics service. These are independent side effects that don''t need to happen in order.'
+    question: What is the MOST appropriate Paradigm modeling for these independent side effects?
+    choices:
+      A: A `$payment-webhook-flow` with three sequential steps
+      B: A `!payment-succeeded` signal with three subscriber components
+      C: Three separate `^` gates that the webhook must pass
+      D: A `~payment-side-effects` aspect applied to the webhook handler
+      E: Three `#` components with no formal connection between them
+    correct: B
+    explanation: When side effects are independent and don't require ordering, a Signal (`!`) is the right model. You define `!payment-succeeded` and document three subscriber components (`#order-service`, `#email-sender`, `#analytics-tracker`) that react to it. Signals are for events that trigger side effects. A Flow (`$`) would be appropriate if the steps needed to happen in a specific order or if one step depended on the output of another. Gates (`^`) are for condition checks, not business logic.
+    slot: slot-014
+    section: para-201
+    variants:
+      - id: plsat-014b
+        scenario: 'When a user completes their profile, three independent things should happen: (1) update the user''s completion badge, (2) notify their team admin, (3) log the event to analytics. None of these depend on each other.'
+        question: How should these independent reactions be modeled in Paradigm?
+        choices:
+          A: A `$profile-completion-flow` with three sequential steps
+          B: A `!profile-completed` signal with three subscriber components
+          C: Three `^` gates that must all pass
+          D: A single `#profile-handler` component that does all three things
+          E: Three `~` aspects applied to the profile component
+        correct: B
+        explanation: Independent side effects that don't require ordering are modeled as Signal (`!`) subscribers. Define `!profile-completed` and document three subscriber components that react to it. A Flow (`$`) would be appropriate only if the steps needed specific ordering or depended on each other's output.
+  - id: plsat-015
+    scenario: 'Your project''s discipline is `fullstack`. You''re adding a new feature: team invitations. The feature involves a UI component for the invite form, an API endpoint, a service for generating invite tokens, and an email sender. You create a new directory `src/features/team-invites/`.'
+    question: What should the `.purpose` file in this directory contain at minimum?
+    choices:
+      A: Just a `name` field — Paradigm will auto-discover the rest
+      B: A `name`, `description`, and at least one `#component` entry
+      C: A full `$flow` definition with all steps documented
+      D: Gate definitions (`^`) for all protected endpoints in this feature
+      E: Signal definitions (`!`) for all events this feature emits
+    correct: B
+    explanation: At minimum, a `.purpose` file needs a `name` and `description` (to orient agents and developers) and at least one `#component` documenting a code unit. Gates go in `portal.yaml` (the authoritative source for route protection), not in purpose files. Flows and signals are important but not required for every feature — they should be added when the feature has multi-step processes or emits events. Paradigm does not auto-discover components; they must be explicitly documented.
+    slot: slot-015
+    section: para-201
+  - id: plsat-017
+    scenario: |-
+      Your team defines the following flow:
+
+      ```yaml
+      flows:
+        $user-onboarding:
+          description: New user setup after registration
+          steps:
+            - component: "#email-verifier"
+              action: send-verification-email
+            - component: "#profile-wizard"
+              action: collect-profile-data
+            - component: "#team-assigner"
+              action: assign-default-team
+            - component: "#welcome-emailer"
+              action: send-welcome-email
+          signals: ["!user-onboarded"]
+      ```
+
+      You need to modify `#email-verifier` to use a new email provider.
+    question: Before making the code change, what should you do FIRST?
+    choices:
+      A: Run `paradigm_search` to find all references to `#email-verifier`
+      B: Read the `#email-verifier` source file to understand the current implementation
+      C: Call `paradigm_ripple` on `#email-verifier` to understand the impact
+      D: Call `paradigm_orchestrate_inline` to plan the migration
+      E: Update the `.purpose` file first to reflect the new provider
+    correct: C
+    explanation: Before modifying ANY symbol, the first step is always `paradigm_ripple`. This shows you what depends on `#email-verifier` directly and indirectly — in this case, you'd discover it's part of `$user-onboarding` and any other flows or components that reference it. This prevents you from making changes that break downstream dependencies. After ripple analysis, you'd read the source (B), check wisdom/history, and then implement. Orchestration (D) is for complex multi-file tasks, not single-component changes.
+    slot: slot-017
+    section: para-201
+  - id: plsat-018
+    scenario: You're defining a gate for a multi-tenant SaaS application. Users can belong to multiple organizations, and each organization has its own resources. You need a gate that checks whether the requesting user is a member of the organization that owns the requested resource.
+    question: Which gate definition follows the Paradigm portal pattern?
+    choices:
+      A: |-
+        ```yaml
+        ^org-member:
+          description: User is a member of the organization AND has read permission
+          check: org.members.includes(req.user.id) && req.user.permissions.read
+        ```
+      B: |-
+        ```yaml
+        ^org-member:
+          description: User is a member of the resource's organization
+          check: org.members.includes(req.user.id)
+        ```
+      C: |-
+        ```yaml
+        ^org-access:
+          description: User can access organization resources with full CRUD
+          check: org.members.includes(req.user.id) && req.user.role !== 'viewer'
+        ```
+      D: |-
+        ```yaml
+        ^resource-check:
+          description: Validates resource exists and user has access
+          check: resource != null && org.members.includes(req.user.id)
+        ```
+      E: |-
+        ```yaml
+        ^member-or-admin:
+          description: User is either a member or an admin of the organization
+          check: org.members.includes(req.user.id) || org.admins.includes(req.user.id)
+        ```
+    correct: B
+    explanation: 'Paradigm''s gate philosophy is ''one responsibility per gate.'' Choice B does exactly one thing: checks organization membership. Choice A bundles membership with permissions (two responsibilities). Choice C adds a role check. Choice D validates resource existence (that''s a different concern). Choice E conflates membership and admin roles. If you need permission checks, create `^org-reader`, `^org-writer` as separate gates with `requires: ["^org-member"]`. Keep gates minimal and composable.'
+    slot: slot-018
+    section: para-201
+  - id: plsat-020
+    scenario: 'You open `.paradigm/config.yaml` and see `discipline: fullstack`. You''re curious what this means and whether it affects how symbols are mapped.'
+    question: What does the `discipline` field control in Paradigm?
+    choices:
+      A: It determines which programming language the project uses
+      B: It configures the symbol-to-directory mapping and recommended patterns for the project type
+      C: It restricts which symbols are allowed — e.g., some disciplines don't use flows
+      D: It's purely cosmetic — shown in the dashboard but has no functional effect
+      E: It determines the deployment pipeline configuration
+    correct: B
+    explanation: The `discipline` field tells Paradigm what kind of project this is, which influences symbol mappings (e.g., where components vs. gates typically live), suggested patterns, and how AI agents reason about the codebase. A `fullstack` discipline suggests `middleware/` maps to gates, `services/` to components, etc. Different disciplines (e.g., `cli`, `library`, `embedded`) would have different default mappings. Since v2, Paradigm auto-detects the discipline from project structure at init time. It doesn't restrict symbols — all 5 are always available.
+    slot: slot-020
+    section: para-201
+  - id: plsat-021
+    scenario: |-
+      While reviewing a PR, you notice a developer added a new webhook endpoint:
+
+      ```typescript
+      // src/api/webhooks/stripe.ts
+      app.post('/api/webhooks/stripe', async (req, res) => {
+        const event = verifyStripeSignature(req);
+        if (event.type === 'payment_intent.succeeded') {
+          await updateOrderStatus(event.data);
+          await sendReceipt(event.data);
+        }
+        res.json({ received: true });
+      });
+      ```
+
+      The developer did not update any Paradigm files.
+    question: Which Paradigm files should be updated? Select the MOST complete answer.
+    choices:
+      A: Only `portal.yaml` — add the webhook route with appropriate gates
+      B: Only the nearest `.purpose` file — add `#stripe-webhook-handler` as a component
+      C: Both `portal.yaml` and the nearest `.purpose` file
+      D: The `.purpose` file, `portal.yaml`, and add a `!payment-succeeded` signal definition
+      E: No updates needed — webhooks are external and don't need Paradigm documentation
+    correct: D
+    explanation: 'The most complete answer includes: (1) The `.purpose` file needs a `#stripe-webhook-handler` component with `tags: [integration, stripe]`. (2) `portal.yaml` needs the route — even webhook endpoints may need gates (e.g., signature verification as `^stripe-signature-valid`). (3) The payment success event should be documented as `!payment-succeeded` since it triggers side effects (order update, receipt). This is the Paradigm principle: if it exists in code, it should exist in the symbol graph.'
+    slot: slot-021
+    section: para-201
+  - id: plsat-022
+    scenario: |-
+      A developer writes this commit message:
+
+      ```
+      added apple pay button and updated checkout
+      ```
+    question: What is wrong with this commit message according to Paradigm conventions?
+    choices:
+      A: It should use past tense ('added' is correct, actually)
+      B: It's missing the conventional commit type, primary symbol in parentheses, and the `Symbols:` trailer
+      C: It should be in ALL CAPS for visibility
+      D: It should reference the Jira ticket number instead of symbols
+      E: Nothing is wrong — commit messages are personal preference
+    correct: B
+    explanation: |-
+      Paradigm commit messages follow a strict format: `type(#primary-symbol): description` in the subject, symbol references in the body, and a `Symbols:` trailer for machine parsing. The correct message would be:
+
+      ```
+      feat(#payment-form): add Apple Pay support
+
+      - Add #apple-pay-button component
+      - Update $checkout-flow with new payment step
+
+      Symbols: #payment-form, #apple-pay-button, $checkout-flow
+      ```
+
+      The `Symbols:` trailer is parsed by the post-commit hook for automatic history capture.
+    slot: slot-022
+    section: para-201
+  - id: plsat-023
+    scenario: You're building a real-time notification system. Notifications can arrive via WebSocket, and the user can mark them as read, archive them, or delete them. The system also needs to handle notification preferences (email, push, in-app) and batching for high-volume scenarios.
+    question: A team member suggests modeling each notification action (read, archive, delete) as a separate `$` flow. What is the BEST response?
+    choices:
+      A: Agree — each action is a distinct process that should have its own flow
+      B: Disagree — single actions are not flows; use `#` components for each action and a `$notification-lifecycle` flow for the overall process
+      C: Disagree — these should all be `!` signals since they're user-triggered events
+      D: Agree, but only if each action involves 3+ components
+      E: Disagree — model them as `^` gates since they require condition checks
+    correct: B
+    explanation: 'Flows (`$`) are for multi-step processes spanning 3+ components. A single action like ''mark as read'' is just a component method, not a flow. The correct modeling is: `#notification-reader`, `#notification-archiver`, etc. as components, with `!notification-read`, `!notification-archived` as signals for side effects. If the OVERALL lifecycle (receive → display → interact → archive/delete) is worth documenting, THAT is the flow: `$notification-lifecycle`. Choice D gets close but misses the key insight about modeling the lifecycle.'
+    slot: slot-023
+    section: para-201
+  - id: plsat-024
+    scenario: |-
+      Your project has the following aspect definition:
+
+      ```yaml
+      ~audit-required:
+        description: Financial operations must produce audit logs
+        anchors:
+          - src/middleware/audit.ts:15-35
+          - src/decorators/auditable.ts:1-20
+        applies-to: ["#*Service"]
+        enforcement: middleware
+      ```
+
+      A colleague refactors `audit.ts` and moves the audit logic from lines 15-35 to lines 50-70.
+    question: What happens if the anchors are not updated?
+    choices:
+      A: Nothing — anchors are just documentation hints and aren't validated
+      B: '`paradigm doctor` will report stale anchors, and `paradigm_aspect_check` will flag the mismatch'
+      C: The application will crash because the aspect can't find its enforcement code
+      D: The audit middleware will stop working because Paradigm controls execution
+      E: The CI pipeline will block the merge due to anchor validation
+    correct: B
+    explanation: Paradigm is a documentation/intelligence layer, not a runtime. Stale anchors won't crash your app or stop middleware from working. However, `paradigm doctor` (the validation command) and `paradigm_aspect_check` (the MCP tool) will detect that the anchored lines no longer match the expected code. This is important because anchors are the mechanism that keeps aspects grounded in real code rather than becoming aspirational documentation. The developer should update anchors to `src/middleware/audit.ts:50-70` as part of the refactor.
+    slot: slot-024
+    section: para-201
+  - id: plsat-025
+    scenario: You're adding a new API endpoint `POST /api/billing/invoices` to your project. Before writing any code, you want to follow Paradigm best practices.
+    question: What is the recommended sequence of steps?
+    choices:
+      A: Write the code → Update `.purpose` file → Update `portal.yaml` → Commit
+      B: Call `paradigm_gates_for_route` → Update `portal.yaml` → Write the code → Update `.purpose` file → Commit
+      C: Update `portal.yaml` → Write the code → Run `paradigm doctor` → Commit
+      D: Write the code → Run `paradigm scan` → Let it auto-generate the purpose file → Commit
+      E: Call `paradigm_orchestrate_inline` → Spawn agents → Let agents handle everything
+    correct: B
+    explanation: 'The recommended flow for adding endpoints is: (1) Call `paradigm_gates_for_route` to get gate suggestions for `POST /api/billing/invoices`, (2) Update `portal.yaml` with the route and its gates, (3) Implement the endpoint with proper gate enforcement, (4) Update the nearest `.purpose` file with the new `#` component, signals, etc. (5) Commit with proper Paradigm commit format. This ''portal first'' approach ensures security is designed before implementation. Choice D is wrong because `paradigm scan` discovers existing symbols but doesn''t auto-generate purpose files from code.'
+    slot: slot-025
+    section: para-201
+  - id: plsat-026
+    scenario: You're in the middle of a long Claude Code session. You've made 47 tool calls, modified 12 files, and you're about to start a complex refactor of the payment system. You vaguely recall something about context management but can't remember the details.
+    question: What should you do before starting the refactor?
+    choices:
+      A: Just continue — context management is handled automatically
+      B: Call `paradigm_session_health` to see if a handoff is recommended
+      C: Start a new Claude session immediately to get fresh context
+      D: Save all files and run `paradigm scan` to rebuild the index
+      E: Call `paradigm_session_stats` and if over 100 tool calls, panic
+    correct: B
+    explanation: The protocol says to call `paradigm_session_health` periodically (every 10-15 tool calls) during long sessions. At 47 tool calls, you're well overdue for a check. This tool analyzes your context window usage and recommends whether to continue, prepare a handoff, or urgently wrap up. If usage is over 85%, you should prioritize completing your current task and prepare a handoff with `paradigm_handoff_prepare`. Don't just start a new session (C) without preparing a handoff — you'd lose all context about what was done.
+    slot: slot-026
+    section: para-301
+  - id: plsat-027
+    scenario: |-
+      You run `paradigm doctor` and get the following output:
+
+      ```
+      WARNING: #payment-processor has been modified 7 times in 14 days
+      WARNING: #payment-processor has 3 rollbacks in history
+      FRAGILITY SCORE: 0.85 (HIGH)
+      ```
+    question: What does a fragility score of 0.85 indicate, and what should you do?
+    choices:
+      A: The component has a bug 85% of the time — rewrite it from scratch
+      B: 85% of the codebase depends on it — extract it into a separate service
+      C: The component is highly unstable due to frequent changes and rollbacks — proceed with extra caution, review wisdom, and consider refactoring
+      D: The component needs 85% more test coverage — write tests first
+      E: The score is informational only — ignore it and proceed normally
+    correct: C
+    explanation: 'A fragility score of 0.85 (out of 1.0) means the component is highly unstable. It''s been changed 7 times in 2 weeks with 3 rollbacks — a clear pattern of churn. Before modifying it: (1) Call `paradigm_wisdom_context` to check for antipatterns and `paradigm_decision_search` for prior decisions about it, (2) Call `paradigm_history_context` to understand the recent changes, (3) Consider whether a refactor is needed before adding more changes. The score doesn''t mean ''has bugs 85%'' or ''needs 85% coverage'' — it''s a stability metric based on change frequency and rollback rate.'
+    slot: slot-027
+    section: para-301
+  - id: plsat-028
+    scenario: 'After a production incident where the payment system double-charged a customer, the team discovers the root cause: a developer removed a deduplication check while refactoring `#payment-processor`. The team wants to prevent this from happening again.'
+    question: What is the MOST appropriate Paradigm response to this incident?
+    choices:
+      A: 'Add a comment in the code: `// DO NOT REMOVE THIS CHECK`'
+      B: 'Record an antipattern in wisdom: ''Never remove deduplication from #payment-processor'' with the alternative approach'
+      C: Create a `^deduplication-enforced` gate in portal.yaml
+      D: Add `#payment-processor` to a 'do not touch' list in `.paradigm/config.yaml`
+      E: Record the incident in Sentinel AND record an antipattern in wisdom
+    correct: E
+    explanation: 'The most complete response uses both Sentinel and Wisdom. (1) Record the incident with `paradigm_sentinel_record` so it appears in incident tracking with symbolic context (the `#payment-processor` symbol, error details, timeline). (2) Record an antipattern with `paradigm_wisdom_record` so future AI agents and developers are warned before modifying `#payment-processor`. The antipattern would say: ''Never remove deduplication logic'' with alternative: ''If refactoring payment processing, always preserve the deduplication middleware and add tests for it.'' A code comment (A) is easily missed. A gate (C) is for condition checks on routes, not business logic.'
+    slot: slot-028
+    section: para-301
+  - id: plsat-029
+    scenario: You need to understand the impact of changing `^authenticated` — the main authentication gate used across your entire application. You want to know what depends on it.
+    question: Which MCP tool call gives you the MOST useful dependency information?
+    choices:
+      A: '`paradigm_search({ query: ''^authenticated'' })` — find all references'
+      B: '`paradigm_related({ symbol: ''^authenticated'' })` — show direct relations'
+      C: '`paradigm_ripple({ symbol: ''^authenticated'', depth: 3 })` — show direct AND indirect dependencies up to 3 levels'
+      D: '`paradigm_navigate({ intent: ''find'', target: ''^authenticated'' })` — locate the gate'
+      E: '`paradigm_flows_affected({ symbol: ''^authenticated'' })` — show affected flows'
+    correct: C
+    explanation: '`paradigm_ripple` with a depth parameter gives you the cascading dependency analysis. For a widely-used gate like `^authenticated`, you need to see not just what directly references it, but what depends on things that depend on it (transitive dependencies). At depth 3, you''d see: Level 1 — all gates with `requires: [^authenticated]`, all routes using it. Level 2 — all components behind those routes. Level 3 — flows involving those components. `paradigm_related` (B) only shows direct connections. `paradigm_search` (A) finds textual references but doesn''t analyze the dependency graph.'
+    slot: slot-029
+    section: para-301
+  - id: plsat-030
+    scenario: It's Monday morning. You open Claude Code to continue work on a project. Last Friday, a different Claude session was making changes to the user management module. You have no idea what state things are in.
+    question: What is the FIRST thing you should do?
+    choices:
+      A: Run `git log` to see recent commits
+      B: Call `paradigm_session_recover` to load breadcrumbs from the previous session
+      C: Call `paradigm_status` for a general project overview
+      D: Read the `.paradigm/config.yaml` to understand the project
+      E: Start fresh — don't worry about what the previous session did
+    correct: B
+    explanation: '`paradigm_session_recover` is designed exactly for this scenario. It loads breadcrumbs from previous sessions, showing you what was done, what files were modified, what symbols were touched, and what the next steps were. This is more useful than `paradigm_status` (C) because status gives you general project info, not session-specific context. After recovering the session, THEN you''d call `paradigm_status` and check the relevant files. Starting fresh (E) risks duplicating work or missing important context.'
+    slot: slot-030
+    section: para-301
+  - id: plsat-031
+    scenario: Your application is experiencing intermittent 500 errors on the checkout flow. You suspect it's related to the Stripe integration. You want to check if there's a known pattern for this type of failure.
+    question: Which sequence of Sentinel tools should you use?
+    choices:
+      A: '`paradigm_sentinel_triage` to see open incidents, then `paradigm_sentinel_patterns` to find matching failure patterns'
+      B: '`paradigm_sentinel_stats` to see overall health, then guess at the root cause'
+      C: '`paradigm_sentinel_record` to create a new incident immediately'
+      D: '`paradigm_sentinel_suggest_pattern` without any incident context'
+      E: '`paradigm_sentinel_resolve` to close any open incidents and hope it goes away'
+    correct: A
+    explanation: 'The diagnostic workflow is: (1) `paradigm_sentinel_triage` with a filter like `search: ''500''` or `symbol: ''#stripe-service''` to see if there are existing open incidents matching your symptoms. (2) `paradigm_sentinel_patterns` to find known failure patterns (with confidence scores) that match the error. If a pattern matches, it includes resolution steps and code hints. You''d only record a NEW incident (C) if triage shows this is a novel failure. Resolving without investigating (E) is never the right answer. Stats (B) give you health metrics but not diagnostic details.'
+    slot: slot-031
+    section: para-301
+  - id: plsat-032
+    scenario: You want to find who on your team has the most expertise with the payment system before making a significant architectural change.
+    question: Which Paradigm tool helps you find the right person?
+    choices:
+      A: '`paradigm_search({ query: ''payments'' })` and look at file authors in git blame'
+      B: '`paradigm_wisdom_expert({ area: ''payments'' })` to find recognized experts'
+      C: '`paradigm_history_context({ symbols: [''#payment-service''] })` and infer from commit history'
+      D: '`paradigm_navigate({ intent: ''explore'', target: ''payments'' })` and read the code to figure out who wrote it'
+      E: Ask in Deus / Slack / Teams
+    correct: B
+    explanation: '`paradigm_wisdom_expert` is purpose-built for finding human experts by area or symbol. It returns people who are recognized as knowledgeable about the payment system, based on recorded wisdom and history. While `paradigm_history_context` (C) can show who recently worked on the code, that doesn''t mean they''re the expert — they might have just fixed a typo. `paradigm_wisdom_expert` tracks deliberate expertise attribution, not just commit frequency.'
+    slot: slot-032
+    section: para-301
+  - id: plsat-033
+    scenario: After completing a significant refactor of the authentication module, you want to record what you did for future sessions and team members.
+    question: What is the correct way to record this in Paradigm's history system?
+    choices:
+      A: Write a detailed comment in the `.purpose` file
+      B: Call `paradigm_history_record` with type 'refactor', affected symbols, and description
+      C: Update `.paradigm/docs/changelog.md` with the changes
+      D: Just commit with a good message — git history is sufficient
+      E: Call `paradigm_decision_record` with title, rationale, and participants explaining the refactor rationale
+    correct: B
+    explanation: '`paradigm_history_record` is the right tool for recording implementation events. You''d call it with `type: ''refactor''`, `symbols: [''^authenticated'', ''#auth-middleware'', ...]`, and a description of what was changed. This feeds into the history system that powers `paradigm_history_context` and `paradigm_history_fragility`. A good commit message (D) is important but separate — Paradigm''s history provides symbolic context that git alone doesn''t. If the refactor involved an architectural DECISION, you''d ALSO record it via `paradigm_decision_record` (E), but that''s supplementary, not a replacement — the implementation event itself belongs in the history system. (Note: `paradigm_wisdom_record` no longer accepts `type: ''decision''` in v6.0; decisions live in the dedicated decision store.)'
+    slot: slot-033
+    section: para-301
+  - id: plsat-034
+    scenario: You've run tests after implementing a new feature. 15 tests passed, 2 failed, and 1 was skipped. You previously recorded the implementation with `paradigm_history_record` and got back an implementation ID.
+    question: How should you record the test results?
+    choices:
+      A: Update the implementation record by calling `paradigm_history_record` again
+      B: Call `paradigm_history_validate` with result 'partial' and the test counts
+      C: Call `paradigm_history_validate` with result 'fail' because not all tests passed
+      D: Don't record it — fix the failing tests first, then record a 'pass'
+      E: Call `paradigm_sentinel_record` to log the test failures as incidents
+    correct: B
+    explanation: '`paradigm_history_validate` is the validation companion to `paradigm_history_record`. With 15 passed, 2 failed, and 1 skipped, the result is ''partial'' (not full pass, not complete failure). You''d call it with `result: ''partial''` and `tests: { passed: 15, failed: 2, skipped: 1 }`. This creates a validation record linked to the implementation. Recording it as ''fail'' (C) is too harsh — partial acknowledges progress. Waiting to record (D) loses valuable history about the initial state. Test failures aren''t production incidents (E) unless they indicate a production problem.'
+    slot: slot-034
+    section: para-301
+  - id: plsat-035
+    scenario: |-
+      A context check returns the following:
+
+      ```
+      Context usage: ~82%
+      Recommendation: prepare-handoff
+      Message: Context getting full. Complete current task and prepare handoff.
+      ```
+
+      You're in the middle of implementing a feature that's about 70% done.
+    question: What is the correct course of action?
+    choices:
+      A: Ignore the warning and finish the feature — 82% means you still have 18% left
+      B: Stop immediately and call `paradigm_handoff_prepare` with what you've done so far
+      C: Finish the current task as quickly as possible, then call `paradigm_handoff_prepare` with a summary, modified files, and next steps
+      D: Delete some earlier context by running `paradigm_session_recover` to free up space
+      E: Switch to a different, smaller task that can be completed in the remaining context
+    correct: C
+    explanation: 'At 82% with a ''prepare-handoff'' recommendation, you should complete your current task (not start new ones) and then hand off. The protocol says: when context usage is high but not critical (>85%), prioritize completing the current task, then prepare a handoff. `paradigm_handoff_prepare` takes your summary, modified files, symbols touched, and next steps — giving the next session everything it needs to pick up where you left off. Ignoring it (A) risks running out of context mid-task. Stopping immediately (B) wastes the 70% progress. You can''t delete context (D).'
+    slot: slot-035
+    section: para-301
+  - id: plsat-036
+    scenario: You want to understand the complete structure of the authentication module without reading every file. The project has 200+ files across nested directories.
+    question: What is the MOST token-efficient way to explore this?
+    choices:
+      A: Read every file in `src/auth/` one by one
+      B: 'Call `paradigm_navigate({ intent: ''explore'', target: ''auth'' })` to browse the area'
+      C: 'Run `paradigm_search({ query: ''auth'' })` and read every matching file'
+      D: Read `.paradigm/navigator.yaml` and then every file it references
+      E: Call `paradigm_status` and hope it includes auth module details
+    correct: B
+    explanation: '`paradigm_navigate` with intent ''explore'' is designed for exactly this: browsing an area of the codebase without reading individual files. At ~200 tokens per call, it''s vastly more efficient than reading files (~500-2000 tokens each). It returns the structural overview of the auth area — components, gates, flows, signals — from the indexed symbols. If you need specific implementation details AFTER exploring, then you read individual files. The rule is: MCP for discovery, files for implementation.'
+    slot: slot-036
+    section: para-301
+  - id: plsat-037
+    scenario: You're debugging an issue where the `$order-fulfillment` flow is failing at the 'ship order' step. The flow has 6 steps spanning 4 components. You suspect the gate `^warehouse-authorized` is rejecting valid requests.
+    question: Which combination of tools gives you the MOST diagnostic information?
+    choices:
+      A: '`paradigm_flow_check({ flowId: ''$order-fulfillment'' })` + `paradigm_sentinel_triage({ symbol: ''^warehouse-authorized'' })`'
+      B: '`paradigm_search({ query: ''warehouse'' })` + read all matching files'
+      C: '`paradigm_ripple({ symbol: ''$order-fulfillment'' })` only'
+      D: '`paradigm_history_context({ symbols: [''$order-fulfillment''] })` only'
+      E: '`paradigm_navigate({ intent: ''find'', target: ''^warehouse-authorized'' })` + read the gate code'
+    correct: A
+    explanation: 'The best combination is: (1) `paradigm_flow_check` checks the flow definition against the codebase — are all steps implemented, do the gates exist, are signals emitted? This could reveal if the flow definition is out of sync with the code. (2) `paradigm_sentinel_triage` filtered by `^warehouse-authorized` shows if there are incidents or known patterns for this gate failing. Together, these give you structural validation AND operational history. Ripple (C) shows dependencies but not failures. History (D) shows changes but not current errors.'
+    slot: slot-037
+    section: para-301
+  - id: plsat-038
+    scenario: 'Your team has been using Paradigm for 6 months. A new developer joins and asks: ''How do I know if the Paradigm files are actually accurate? What if the code has drifted from the documentation?'''
+    question: What is the correct answer?
+    choices:
+      A: Trust the Paradigm files — they're always accurate because they're machine-generated
+      B: Run `paradigm doctor` to validate consistency between Paradigm files and the codebase, and check `paradigm_aspect_check` for aspect anchor drift
+      C: Paradigm files are aspirational — they describe what the code SHOULD be, not what it IS
+      D: Run `paradigm scan` to regenerate all Paradigm files from scratch
+      E: Check the git blame on `.purpose` files to see when they were last updated
+    correct: B
+    explanation: '`paradigm doctor` is the validation tool that checks for inconsistencies between Paradigm files and the codebase. It flags missing anchors, undefined symbols referenced in flows, gates referenced in portal.yaml that don''t have implementations, and more. `paradigm_aspect_check` specifically validates that aspect anchors still point to valid code. `paradigm_purpose_validate` checks `.purpose` file structural validity. These tools are how you verify accuracy. Paradigm files are NOT auto-generated (A) or aspirational (C) — they''re maintained documentation that has validation tools.'
+    slot: slot-038
+    section: para-301
+    variants:
+      - id: plsat-038b
+        scenario: |-
+          While writing a `.purpose` file for a new feature, you aren't sure whether the notification service should send emails or push notifications. Rather than guessing, you write:
+
+          ```yaml
+          components:
+            notification-dispatcher:
+              description: "Routes notifications to users [NEEDS CLARIFICATION: email, push, or both?]"
+          ```
+
+          You then run `paradigm doctor` and `paradigm_purpose_validate`.
+        question: 'How do these tools treat the `[NEEDS CLARIFICATION: ...]` marker?'
+        choices:
+          A: As an error — the `.purpose` file fails validation until the marker is removed
+          B: As a warning — it surfaces during checks but does not block validation or break builds
+          C: They ignore it — it's just text in a YAML string
+          D: As a fatal parse error — the square brackets break YAML syntax
+          E: As an info-level message only visible with `--verbose` flag
+        correct: B
+        explanation: 'Clarification markers (`[NEEDS CLARIFICATION: ...]`) are treated as warnings by both `paradigm doctor` and `paradigm_purpose_validate`. They scan all description fields for this exact pattern and report matches as warnings. This means the marker surfaces during health checks to remind the team of open design questions, but it does not fail validation or block builds. The intent is to make ambiguity visible and trackable rather than silent. Resolve markers before shipping by replacing them with the clarified text.'
+  - id: plsat-039
+    scenario: 'You need to build a complete user profile feature: a UI component, API endpoint, database service, validation logic, and tests. This will touch at least 6 files across 3 directories.'
+    question: Before writing ANY code, what should you do FIRST?
+    choices:
+      A: Start coding the UI component — start with the frontend and work backwards
+      B: 'Call `paradigm_orchestrate_inline({ task: ''Build user profile feature'', mode: ''plan'' })` to get the right agents and plan'
+      C: Call `paradigm_search` for existing profile-related symbols
+      D: Create the `.purpose` file first to define all the symbols
+      E: Call `paradigm_ripple` on every component you plan to create
+    correct: B
+    explanation: 'When a task affects 3+ files, involves multiple features, or spans security and implementation, the FIRST step is calling `paradigm_orchestrate_inline` with mode=''plan''. This returns: the right agent team (e.g., architect + security + builder + tester), estimated token cost, and an execution plan with stages. This prevents you from wasting tokens on ad-hoc implementation when a structured approach would be more efficient. After the plan, you''d call with mode=''execute'' to get full agent prompts. You can''t ripple (E) symbols that don''t exist yet.'
+    slot: slot-039
+    section: para-401
+  - id: plsat-040
+    scenario: |-
+      You call `paradigm_orchestrate_inline` with mode='plan' for a task involving JWT authentication. The plan returns four agents: architect, security, builder, tester. The plan shows two stages:
+
+      ```
+      Stage 1: [architect, security] (canRunParallel: true)
+      Stage 2: [builder, tester] (canRunParallel: false)
+      ```
+    question: How should you execute this plan?
+    choices:
+      A: Run all four agents simultaneously for maximum speed
+      B: Run architect and security in parallel, wait for both to complete, then run builder, then tester sequentially
+      C: Run architect first, then security, then builder, then tester — always sequential
+      D: Skip the architect and security agents — just run builder and tester
+      E: Run builder first to get code written, then architect and security for review
+    correct: B
+    explanation: 'The orchestration plan explicitly marks `canRunParallel: true` for Stage 1 (architect + security), meaning they can run simultaneously. Stage 2 has `canRunParallel: false`, meaning builder must complete before tester starts. The correct execution is: launch architect and security in parallel (Stage 1), wait for both to finish, run builder with handoff context from Stage 1, then run tester after builder completes. Skipping agents (D) defeats the purpose of orchestration. Running builder first (E) ignores architecture and security design.'
+    slot: slot-040
+    section: para-401
+  - id: plsat-041
+    scenario: |-
+      Your team is evaluating which agent provider to use for orchestration. The environment has:
+      - `ANTHROPIC_API_KEY` set
+      - Claude Code installed (Max subscription)
+      - Cursor IDE open
+      - No `.paradigm/config.yaml` provider override
+
+      The team runs `paradigm team providers`.
+    question: Which provider will be used by default based on the cascade?
+    choices:
+      A: Cursor agent CLI — because Cursor IDE is detected
+      B: Claude Code Task tool — because Max subscription is available
+      C: Anthropic API (claude) — because it's first in the cascade and the API key is set
+      D: Manual file-based handoffs — because no provider is explicitly configured
+      E: Claude Code Agent Teams — because it supports parallel execution
+    correct: C
+    explanation: 'The provider cascade tries providers in order: (1) claude (Anthropic API), (2) claude-code-teams, (3) claude-code, (4) cursor-cli, (5) claude-cli, (6) manual. Since `ANTHROPIC_API_KEY` is set, the first provider (`claude` — Anthropic API) is available and will be used. The cascade stops at the first available provider unless overridden. Even though Cursor and Claude Code are available, they''re lower priority. To override, use `paradigm team providers --set cursor-cli` or set `agent-provider` in config.'
+    slot: slot-041
+    section: para-401
+  - id: plsat-042
+    scenario: |-
+      You're configuring agent models for your team. The task involves:
+      - An architectural review (complex reasoning needed)
+      - A security audit (critical, needs thoroughness)
+      - Building 3 UI components (straightforward implementation)
+      - Writing unit tests (repetitive, pattern-based)
+
+      Your budget is limited.
+    question: Which model assignment follows Paradigm's recommended configuration?
+    choices:
+      A: All agents use opus for maximum quality
+      B: 'Architect: opus, Security: opus, Builder: haiku, Tester: haiku'
+      C: All agents use haiku for cost efficiency
+      D: 'Architect: sonnet, Security: sonnet, Builder: sonnet, Tester: sonnet'
+      E: 'Architect: opus, Security: sonnet, Builder: opus, Tester: haiku'
+    correct: B
+    explanation: 'Paradigm''s recommended model configuration is: architect and security agents use opus (complex reasoning, critical decisions), builder uses haiku (fast, cost-effective for straightforward implementation), and tester uses haiku (pattern-based, repetitive work). The reviewer role (not in this scenario) uses sonnet (balanced critique). This balances quality where it matters most (architecture, security) with cost efficiency where tasks are more mechanical (building, testing). All-opus (A) blows the budget. All-haiku (C) risks poor architectural decisions.'
+    slot: slot-042
+    section: para-401
+    variants:
+      - id: plsat-042b
+        scenario: The reviewer agent is reviewing a builder's implementation of a new checkout feature. During Stage 1 (Spec Compliance), the reviewer discovers that the builder created a new `#shipping-calculator` component but did not register it in any `.purpose` file. The code itself looks clean and well-tested.
+        question: What should the reviewer do?
+        choices:
+          A: Proceed to Stage 2 (Code Quality) since the code looks good, and mention the missing `.purpose` entry as a note
+          B: Stop at Stage 1, report a blocking finding for the unregistered component, and hand back to the builder without running Stage 2
+          C: Register the component in the `.purpose` file on behalf of the builder, then approve
+          D: Skip both stages and approve since the code is well-tested
+          E: Run Stage 2 first since code quality is more important than metadata
+        correct: B
+        explanation: The reviewer follows a strict two-stage protocol. Stage 1 (Spec Compliance) is a hard gate — if it fails, the reviewer stops immediately and hands back to the builder. A missing `.purpose` registration is a spec compliance violation (blocking finding). There is no point reviewing code quality of spec-noncompliant code. The reviewer never writes code or modifies files (C is wrong). Stage 2 cannot run before Stage 1 passes.
+  - id: plsat-043
+    scenario: |-
+      You're about to call an MCP tool. Your choices are:
+      1. `paradigm_status` (~100 tokens)
+      2. `paradigm_navigate` (~200 tokens)
+      3. Reading a 400-line TypeScript file (~2000 tokens)
+      4. `paradigm_ripple` (~300 tokens)
+
+      You need to understand what components exist in the payments area before modifying `#payment-service`.
+    question: What is the MOST token-efficient approach?
+    choices:
+      A: Read the TypeScript file directly — you need to see the actual code
+      B: Call `paradigm_navigate` to explore the payments area, then `paradigm_ripple` on `#payment-service`, then read only the specific file you need to change
+      C: Call `paradigm_status` first, then read all payment-related files
+      D: Call all four tools to be thorough
+      E: Skip all tools and just start coding — you'll figure it out
+    correct: B
+    explanation: 'The optimal approach is: (1) `paradigm_navigate` (~200 tokens) to discover what exists in the payments area without reading files. (2) `paradigm_ripple` (~300 tokens) on `#payment-service` to understand impact before modifying. (3) THEN read the specific file you need to change. Total: ~500 tokens + one targeted file read. This follows the rule: ''MCP for discovery, files for implementation.'' Reading files first (A) costs ~2000 tokens before you even know what you''re looking at. Calling everything (D) wastes `paradigm_status` tokens on info you don''t need for this task.'
+    slot: slot-043
+    section: para-401
+  - id: plsat-044
+    scenario: Your team decides that all API responses should include a `requestId` header for tracing. This is an architectural decision that affects every API endpoint in the project.
+    question: How should this decision be recorded in Paradigm?
+    choices:
+      A: Add a comment in every API route file
+      B: Call `paradigm_decision_record` with title, rationale, participants, and alternatives_considered — the decision lives in `.paradigm/decisions/` and writes a companion lore `insight` automatically
+      C: Create a `~request-id-required` aspect and add it to every component
+      D: Update `.paradigm/config.yaml` with a new convention
+      E: Both B and C — record the decision AND create an aspect with code anchors
+    correct: E
+    explanation: 'The most complete answer is both. (1) Record the architectural decision with `paradigm_decision_record` including title, decision text, rationale (tracing, debugging, support requirements), participants with stances, and alternatives_considered (response body field rejected_because clients prefer headers). The decision is stored in `.paradigm/decisions/` and a companion lore `insight` is auto-written so the timeline shows the moment the choice was made. (2) Create `~request-id-required` aspect with anchors pointing to the middleware that adds the header. The decision documents the WHY, the aspect enforces the WHAT with verifiable code anchors. Just the decision (B) lacks enforcement. Just the aspect (C) lacks rationale.'
+    slot: slot-044
+    section: para-401
+  - id: plsat-045
+    scenario: |-
+      You're writing a commit message for a change that added rate limiting to the payment API, modified the Stripe webhook handler, and added a new `!rate-limit-exceeded` signal.
+
+      The affected symbols are: `#payment-api`, `#stripe-webhook-handler`, `~rate-limited`, `!rate-limit-exceeded`.
+    question: Which commit message follows Paradigm conventions?
+    choices:
+      A: |-
+        ```
+        feat: add rate limiting to payments
+        ```
+      B: |-
+        ```
+        feat(#payment-api): add rate limiting to payment endpoints
+
+        - Apply ~rate-limited aspect to #payment-api
+        - Update #stripe-webhook-handler with rate limit checks
+        - Add !rate-limit-exceeded signal for monitoring
+
+        Symbols: #payment-api, #stripe-webhook-handler, ~rate-limited, !rate-limit-exceeded
+        ```
+      C: |-
+        ```
+        feat(payments): add rate limiting
+
+        Added rate limiting to payment API and webhook handler.
+        ```
+      D: |-
+        ```
+        FEAT(#payment-api): ADD RATE LIMITING
+
+        Symbols: ALL PAYMENT SYMBOLS
+        ```
+      E: |-
+        ```
+        feat(~rate-limited): apply rate limiting aspect
+
+        - Updated payment-api
+        - Updated stripe-webhook-handler
+
+        Symbols: ~rate-limited
+        ```
+    correct: B
+    explanation: 'Choice B follows all Paradigm commit conventions: (1) Subject line: `type(#primary-symbol): description` with the primary affected component. (2) Body: references all affected symbols with their prefixes (#, ~, !). (3) `Symbols:` trailer: machine-readable list of ALL affected symbols for the post-commit hook to parse. Choice A lacks symbols entirely. Choice C uses a generic scope instead of a symbol. Choice D is SCREAMING_CASE (no). Choice E uses the aspect as the primary symbol, but the primary change is to `#payment-api`, and the Symbols trailer is incomplete.'
+    slot: slot-045
+    section: para-401
+  - id: plsat-046
+    scenario: 'A developer on your team proposes a new tag: `[webhook-handler]`. They''ve noticed 5 components across the project that handle incoming webhooks and think a dedicated tag would be useful for classification.'
+    question: What is the correct process for adding this tag?
+    choices:
+      A: Add it directly to the `core` section of `tags.yaml`
+      B: Add it directly to the `project` section of `tags.yaml`
+      C: Call `paradigm_tags_suggest` with the tag name, description, reason, and example symbols — it goes to `suggested` for human approval
+      D: 'Just start using `tags: [webhook-handler]` on components — tags are freeform'
+      E: Create a new aspect `~webhook-handler` instead — tags aren't for this
+    correct: C
+    explanation: 'The proper process is `paradigm_tags_suggest`, which adds the tag to the `suggested` section of `tags.yaml` for human review. This is Paradigm''s governance model: AI can propose tags, but humans must approve them before they become official. Once approved, a human promotes it to `project` (team-specific) or `core` (if it should ship with Paradigm). Adding directly to `core` (A) is only for Paradigm framework maintainers. Freeform usage (D) leads to tag sprawl. An aspect (E) is wrong because webhook handling isn''t a cross-cutting rule requiring code anchors.'
+    slot: slot-046
+    section: para-401
+  - id: plsat-047
+    scenario: |-
+      Your CI/CD pipeline runs `paradigm doctor` as a check. The latest run shows:
+
+      ```
+      ERROR: Gate ^project-owner referenced in portal.yaml but not defined
+      WARNING: Aspect ~cache-invalidation has stale anchors (file moved)
+      ERROR: Flow $signup-flow references undefined component #sms-verifier
+      INFO: 3 suggested tags awaiting human review
+      ```
+    question: Which issues MUST be fixed before merging, and which can wait?
+    choices:
+      A: All four must be fixed — `paradigm doctor` errors should block the merge
+      B: The two ERRORs must be fixed (undefined gate and undefined component). The WARNING and INFO can wait.
+      C: Only the gate error must be fixed (security). Everything else is documentation.
+      D: None need to block the merge — `paradigm doctor` is advisory only
+      E: The errors and warning must be fixed. Only the INFO about suggested tags can wait.
+    correct: B
+    explanation: 'ERRORs indicate broken references that will cause real problems: a gate referenced in `portal.yaml` that doesn''t exist means route protection is undefined, and a flow referencing an undefined component means the flow documentation is actively misleading. These MUST be fixed. The WARNING about stale anchors is important but not merge-blocking — the aspect still works, the documentation just needs updating. The INFO about suggested tags is purely administrative. In practice, many teams also fix WARNINGs before merge, but the ERRORs are the must-fix items.'
+    slot: slot-047
+    section: para-401
+  - id: plsat-048
+    scenario: You're preparing a handoff because your context window is at 87%. You've been working on a migration from REST to GraphQL for the user module. You've completed the schema and resolvers but haven't written tests yet.
+    question: What information should you include in `paradigm_handoff_prepare`?
+    choices:
+      A: Just the summary — the next session can figure out the rest
+      B: Summary, list of modified files, symbols touched, next steps (write tests), and the open question about whether to keep the REST endpoints during migration
+      C: A complete transcript of everything you did in this session
+      D: Only the list of modified files — the next session can read them
+      E: Summary and next steps only — modified files are in git
+    correct: B
+    explanation: '`paradigm_handoff_prepare` accepts: summary (what was done), modifiedFiles (what changed), symbolsTouched (which symbols were affected), nextSteps (what to do next), and openQuestions (unresolved decisions). The MOST useful handoff includes ALL of these. The next session needs to know: (1) what was accomplished (summary), (2) which files to look at (modifiedFiles), (3) which symbols are in play (symbolsTouched), (4) exactly what to do next (write tests), and (5) any decisions that still need to be made (keep REST endpoints?). A transcript (C) is too much. Just files (D) lacks context.'
+    slot: slot-048
+    section: para-401
+  - id: plsat-049
+    scenario: You want to validate that a specific flow `$checkout-flow` is correctly implemented. The flow has 5 steps, involves 3 gates, and emits 2 signals. You want to verify that all steps have implementations, gates exist in portal.yaml, and signals are actually emitted in the code.
+    question: Which MCP tool call gives you this deep implementation check?
+    choices:
+      A: '`paradigm_flow_check({ flowId: ''$checkout-flow'' })` — validates flow definition only'
+      B: '`paradigm_flow_check({ flowId: ''$checkout-flow'', checkImplementation: true })` — deep check against codebase'
+      C: '`paradigm_purpose_validate()` — validates all purpose files including flows'
+      D: '`paradigm_ripple({ symbol: ''$checkout-flow'' })` — shows flow dependencies'
+      E: '`paradigm_related({ symbol: ''$checkout-flow'' })` — shows what''s connected to the flow'
+    correct: B
+    explanation: '`paradigm_flow_check` with `checkImplementation: true` performs a deep validation: it checks that gates exist in portal.yaml, actions are implemented in the codebase, and signals are emitted. Without `checkImplementation`, it only validates the YAML structure (A). `paradigm_purpose_validate` (C) checks structural validity of purpose files but doesn''t do the deep codebase cross-reference. `paradigm_ripple` (D) shows what depends on the flow, not whether it''s correctly implemented. The `checkImplementation` flag is the key to going from structural validation to implementation verification.'
+    slot: slot-049
+    section: para-401
+  - id: plsat-050
+    scenario: |-
+      It's 2 AM. Your production system is down. The error logs show:
+
+      ```
+      ERROR: Cannot read property 'id' of null
+        at PaymentProcessor.processRefund (payment-processor.ts:142)
+        at RefundHandler.handle (refund-handler.ts:67)
+      ```
+
+      You need to investigate and fix this as fast as possible using Paradigm tools. The on-call engineer has no context about the payment system.
+    question: What is the optimal 2 AM sequence of actions using Paradigm?
+    choices:
+      A: Read the source files, find the bug, fix it, deploy
+      B: '`paradigm_sentinel_record` the incident → `paradigm_sentinel_patterns` for known fixes → `paradigm_wisdom_context` for `#payment-processor` antipatterns → Fix → `paradigm_sentinel_resolve`'
+      C: '`paradigm_orchestrate_inline` to spin up an architect and security agent'
+      D: '`paradigm_status` → `paradigm_navigate` → Read every file in payments/ → Eventually find the bug'
+      E: '`paradigm_ripple` on `#payment-processor` → Fix everything that depends on it'
+    correct: B
+    explanation: 'At 2 AM with production down, you want the fastest path to resolution with full traceability: (1) `paradigm_sentinel_record` the incident with the error and stack trace — this starts the clock and provides symbolic context. (2) `paradigm_sentinel_patterns` to check if this is a KNOWN failure pattern with an existing resolution — this could save you hours. (3) `paradigm_wisdom_context` for `#payment-processor` to check if there are recorded antipatterns (e.g., ''null check required before accessing refund.id''). (4) Fix the issue with full context. (5) `paradigm_sentinel_resolve` to close the incident with the fix commit. Orchestration (C) is overkill for an emergency fix. Reading everything (D) burns time you don''t have.'
+    slot: slot-050
+    section: para-401
+  - id: plsat-051
+    scenario: Your team just held a meeting where the lead architect chose to switch from PostgreSQL to CockroachDB for the user service. No code was written yet — this is purely a strategic decision with rationale, alternatives considered, and dissent recorded in meeting notes.
+    question: How should this be recorded in v6.0?
+    choices:
+      A: '`paradigm_lore_record({ type: ''decision'', ... })` — the lore system handles architectural decisions'
+      B: '`paradigm_lore_record({ type: ''milestone'', ... })` — switching databases is a major event'
+      C: '`paradigm_decision_record({ title, decision, rationale, participants, alternatives_considered })` — decisions live in the dedicated decision store at `.paradigm/decisions/`, with a companion lore `insight` auto-written for timeline coverage'
+      D: '`paradigm_wisdom_record({ type: ''decision'', ... })` — wisdom captures team decisions'
+      E: '`paradigm_lore_record({ type: ''human-note'', ... })` — a human made the decision'
+    correct: C
+    explanation: 'In v6.0 architectural decisions moved out of both the lore system (the `decision` lore type was removed) and the wisdom system (`paradigm_wisdom_record` no longer accepts `type: ''decision''`). They live in `.paradigm/decisions/` as `TD-*` entries recorded via `paradigm_decision_record`, which carries the full ADR shape: title, decision, rationale, participants with stances (proposed, supported, dissented, abstained), alternatives_considered (with rejected_because), symbols_affected, and a status lifecycle (active, superseded, deprecated). A companion lore entry of type `insight` is auto-written so the project timeline still surfaces when the decision was made. A and D both reference removed APIs — the storage layer rejects type:''decision'' lore entries with an error pointing at `paradigm_decision_record`.'
+    slot: slot-051
+    section: para-501
+  - id: plsat-052
+    scenario: 'An agent just finished a quick session where it fixed a typo in a README and updated one comment in a source file. Total files modified: 2 (README.md and src/utils/format.ts).'
+    question: Should the agent record a lore entry before ending the session?
+    choices:
+      A: Yes — every session should be recorded regardless of scope
+      B: No — 2 files is below the 3-file significance threshold, and the stop hook will not require it
+      C: Yes — the source file modification triggers the recording requirement
+      D: No — but only because README.md is not a source file
+      E: It depends on whether the typo fix was in a critical component
+    correct: B
+    explanation: The lore recording trigger is 3+ modified source files. With only 2 files modified (and one being a README which is typically excluded from the source file count), this session is below the threshold. The stop hook will not block for a missing lore entry. Agents can still choose to record, but it is not enforced.
+    slot: slot-052
+    section: para-501
+  - id: plsat-053
+    scenario: Sentinel has recorded 5 incidents over the past week. Three involve `#payment-processor` with TypeError, one involves `#payment-processor` with NetworkError, and one involves `#auth-service` with TypeError. Sentinel groups incidents using a 0.6 similarity threshold.
+    question: How many incident groups will Sentinel likely create?
+    choices:
+      A: 1 group — all 5 incidents involve errors in the same general area
+      B: '2 groups — one for the 3 TypeError incidents in #payment-processor, and the auth TypeError stays separate because different component'
+      C: 3 groups — one per unique (component, error type) combination
+      D: 5 groups — each incident is unique
+      E: '2 groups — one for all #payment-processor incidents (4), one for #auth-service (1)'
+    correct: C
+    explanation: Sentinel groups by symbolic similarity with a 0.6 threshold. The three `#payment-processor` + TypeError incidents share both component and error type — high similarity, one group. The `#payment-processor` + NetworkError shares the component but differs in error type — enough divergence for a separate group. The `#auth-service` + TypeError shares error type with group 1 but differs in component — separate group. Three distinct (component, error type) clusters yield 3 groups.
+    slot: slot-053
+    section: para-501
+  - id: plsat-054
+    scenario: A production error just occurred. You want to record it, check for known fixes, resolve it, and then create a new pattern so future occurrences are handled faster.
+    question: What is the correct Sentinel tool sequence?
+    choices:
+      A: '`sentinel_add_pattern` → `sentinel_record` → `sentinel_resolve`'
+      B: '`sentinel_triage` → `sentinel_record` → `sentinel_resolve` → `sentinel_add_pattern`'
+      C: '`sentinel_record` → `sentinel_triage` → fix → `sentinel_resolve` → `sentinel_add_pattern`'
+      D: '`sentinel_record` → `sentinel_add_pattern` → `sentinel_resolve`'
+      E: '`sentinel_patterns` → `sentinel_record` → `sentinel_add_pattern` → `sentinel_resolve`'
+    correct: C
+    explanation: 'The correct lifecycle is: (1) `sentinel_record` — create the incident with error details and symbolic context. (2) `sentinel_triage` — view the incident with matched patterns and suggested resolutions. (3) Fix the issue using the context from triage. (4) `sentinel_resolve` — close the incident with the fix commit. (5) `sentinel_add_pattern` — capture the fix as a reusable pattern. You must record before you can triage, fix before you can resolve, and resolve before creating a pattern from the resolution.'
+    slot: slot-054
+    section: para-501
+  - id: plsat-055
+    scenario: 'You are configuring habits for your project. You want to ensure that agents always call `paradigm_ripple` before modifying symbols, and you want this enforced at the start of every task. The seed habit `ripple-before-modify` exists with `trigger: preflight` and `severity: advisory`.'
+    question: Which trigger ensures the habit is evaluated before implementation begins?
+    choices:
+      A: '`on-stop` — checks compliance at the end of the session'
+      B: '`on-commit` — checks before changes are committed'
+      C: '`preflight` — evaluated before starting implementation'
+      D: '`postflight` — evaluated after completing implementation'
+      E: '`pre-write` — evaluated before each file edit'
+    correct: C
+    explanation: The `preflight` trigger evaluates habits before implementation begins — this is when discovery checks like `paradigm_ripple` should run. `postflight` is too late (implementation already happened), `on-stop` is the end of the session, and `on-commit` is at commit time. There is no `pre-write` trigger — the four triggers are preflight, postflight, on-commit, and on-stop.
+    slot: slot-055
+    section: para-501
+  - id: plsat-056
+    scenario: 'A project overrides the seed habit `verify-before-done` (originally `severity: warn`) to `severity: block` in `.paradigm/habits.yaml`. An agent finishes implementing a feature but does not call `paradigm_pm_postflight`. The stop hook runs.'
+    question: What happens?
+    choices:
+      A: A warning is logged but the session completes — `warn` is the seed severity
+      B: The session is blocked — the project override to `block` means the stop hook treats this as a blocking violation
+      C: Nothing — habit severity only affects habit check output, not the stop hook
+      D: The override is ignored because seed habits cannot be overridden
+      E: The session completes but the next session receives a mandatory reminder
+    correct: B
+    explanation: 'Project overrides in `.paradigm/habits.yaml` take precedence over seed defaults. The three-layer merge (seed → global → project) means the project''s `severity: block` override replaces the seed''s `severity: warn`. When the stop hook evaluates on-stop habits, it finds a blocking violation because `verify-before-done` was not followed and its severity is now `block`. The session cannot complete until the agent runs `paradigm_pm_postflight`.'
+    slot: slot-056
+    section: para-501
+  - id: plsat-057
+    scenario: An agent has finished reading requirements and has a clear plan for implementing a new feature. It has not written any code yet. It wants to save a checkpoint in case the session crashes.
+    question: Which checkpoint phase should it use?
+    choices:
+      A: '`implementing` — the agent is about to start implementing'
+      B: '`planning` — the agent has a plan but has not started coding'
+      C: '`validating` — the agent needs to validate its plan first'
+      D: '`complete` — the planning phase is complete'
+      E: '`ready` — the agent is ready to implement'
+    correct: B
+    explanation: 'The `planning` phase captures the state after requirements are understood and a plan exists but before any code is written. If the session crashes, recovery knows: the plan is set, coding has not started, here are the key decisions. `implementing` should only be used after code changes begin. `complete` is for when the entire task is finished. There is no `ready` phase — the four phases are planning, implementing, validating, and complete.'
+    slot: slot-057
+    section: para-501
+  - id: plsat-058
+    scenario: |-
+      The stop hook has blocked your session with two violations:
+      1. "Modified source directories missing .purpose coverage: src/services/refund/"
+      2. "Lore entry expected: 4 source files modified, no lore recorded"
+
+      You need to unblock and complete your session.
+    question: What is the correct remediation sequence?
+    choices:
+      A: Run `paradigm_reindex` to fix both violations automatically
+      B: Create a .purpose file in `src/services/refund/`, record a lore entry with `paradigm_lore_record`, then run `paradigm_reindex`
+      C: Delete the `.paradigm/.pending-review` file to clear the tracking
+      D: Add `src/services/refund/` to the `.paradigm/config.yaml` skip list
+      E: Call `paradigm_pm_postflight` which handles all violations
+    correct: B
+    explanation: 'Each violation requires a specific fix: (1) Create or update a .purpose file in or above `src/services/refund/` to provide coverage for the new directory. (2) Call `paradigm_lore_record` with a summary of the session since 4 files exceeds the 3-file threshold. (3) Run `paradigm_reindex` to rebuild the index with the new .purpose file. Deleting `.pending-review` (C) just hides the tracking — the stop hook would still detect uncovered directories. `paradigm_pm_postflight` (E) reports violations but doesn''t fix them.'
+    slot: slot-058
+    section: para-501
+  - id: plsat-059
+    scenario: |-
+      You run `paradigm flow validate` on your project and receive this output:
+
+      ```
+      ⚠ Circular Dependencies (1)
+
+        $order-flow → $inventory-flow → $order-flow
+      ```
+
+      Both flows reference each other via `relatedFlows`.
+    question: What is the best way to resolve this circular dependency?
+    choices:
+      A: Delete one of the flows — circular flows are always a design error
+      B: Extract the shared logic into a new `$stock-check-flow` that both flows reference, breaking the cycle
+      C: Ignore it — circular dependencies are just warnings and do not affect anything
+      D: Rename the flows so the validator does not detect the cycle
+      E: Move both flows into the same .purpose file to merge them
+    correct: B
+    explanation: The recommended resolution for circular flow dependencies is to extract shared logic into a separate flow. If $order-flow and $inventory-flow both need shared behavior, create a third flow (e.g., $stock-check-flow) that both reference unidirectionally. This eliminates the cycle while preserving the relationships. Deletion (A) loses documentation, ignoring (C) hides architectural coupling, and renaming (D) is a workaround that does not fix the underlying issue.
+    slot: slot-059
+    section: para-201
+    variants:
+      - id: plsat-059b
+        scenario: |-
+          Your project has three flows with these `relatedFlows` references:
+          - `$checkout-flow` → `[$payment-flow]`
+          - `$payment-flow` → `[$receipt-flow]`
+          - `$receipt-flow` → `[$checkout-flow]`
+
+          You run `paradigm_flow_check({})` to validate all flows.
+        question: What will the circular dependency detection report?
+        choices:
+          A: No issues — each flow only references one other flow
+          B: Three separate circular dependencies, one for each flow
+          C: 'One circular dependency: $checkout-flow → $payment-flow → $receipt-flow → $checkout-flow'
+          D: A warning that flows should not have relatedFlows at all
+          E: An error that three-flow cycles are not supported
+        correct: C
+        explanation: 'Paradigm''s circular dependency detector uses depth-first search to trace the full dependency graph. Starting from $checkout-flow, it follows: $checkout-flow → $payment-flow → $receipt-flow → $checkout-flow, detecting a single 3-node cycle. The cycle is normalized (starting from the lexicographically smallest node) and reported once, not three times.'
+  - id: plsat-pg3-q1a
+    scenario: ''
+    question: An agent skips calling `paradigm_ripple` before modifying `#checkout-service` and then tries to end the session. What happens?
+    choices:
+      A: Advisory note is logged — ripple-before-modify defaults to advisory severity
+      B: Warning is shown — the override upgrades it to warn
+      C: 'Session is blocked — the override sets ripple-before-modify to severity: block'
+      D: Nothing — ripple-before-modify only checks during preflight, not on-stop
+      E: The habit is disabled because test-new-components is disabled
+    correct: C
+    explanation: 'The overrides section sets `ripple-before-modify` to `severity: block`. The seed habit''s trigger is `preflight`, but when severity is `block`, violations detected during preflight evaluation carry through to the stop hook as blocking violations. The agent cannot complete the session until it calls `paradigm_ripple` for the modified symbols.'
+    slot: pg-habits-q1
+    section: para-501
+    passageId: passage-habits-review
+    passage: |-
+      Your team's `.paradigm/habits.yaml` for an e-commerce project:
+
+      ```yaml
+      overrides:
+        ripple-before-modify:
+          severity: block
+        explore-before-implement:
+          severity: warn
+        test-new-components:
+          enabled: false
+        record-lore-for-significant:
+          severity: block
+
+      custom:
+        - id: check-price-validation
+          name: Validate Price Calculations
+          description: Ensure price calculation tests exist for any payment-related changes
+          category: testing
+          trigger: postflight
+          severity: warn
+          check:
+            type: tests-exist
+            params:
+              patterns: ["**/price*.test.*", "**/payment*.test.*"]
+          enabled: true
+      ```
+
+      The seed habits that are NOT shown in overrides retain their default values. The project has 14 seed habits plus 1 custom habit.
+  - id: plsat-pg3-q2a
+    scenario: ''
+    question: The team disabled `test-new-components` but added a custom `check-price-validation` habit. What testing discipline does this configuration express?
+    choices:
+      A: No testing discipline — disabling the seed habit removes all test requirements
+      B: Targeted testing — the team doesn't require tests for ALL components, but does require them for price/payment code specifically
+      C: The custom habit replaces the seed habit entirely
+      D: This is a configuration error — you cannot disable a seed habit and add a custom one in the same category
+      E: Full testing — the custom habit covers everything the seed habit did
+    correct: B
+    explanation: 'Disabling `test-new-components` (which checks for test files globally with `**/*.test.*`) removes the blanket test requirement. The custom `check-price-validation` habit adds a targeted requirement: test files must exist specifically for price and payment code (`**/price*.test.*`, `**/payment*.test.*`). This is a deliberate choice: the team decided that testing everything is too strict, but payment/price logic is critical enough to enforce test coverage.'
+    slot: pg-habits-q2
+    section: para-501
+    passageId: passage-habits-review
+    passage: |-
+      Your team's `.paradigm/habits.yaml` for an e-commerce project:
+
+      ```yaml
+      overrides:
+        ripple-before-modify:
+          severity: block
+        explore-before-implement:
+          severity: warn
+        test-new-components:
+          enabled: false
+        record-lore-for-significant:
+          severity: block
+
+      custom:
+        - id: check-price-validation
+          name: Validate Price Calculations
+          description: Ensure price calculation tests exist for any payment-related changes
+          category: testing
+          trigger: postflight
+          severity: warn
+          check:
+            type: tests-exist
+            params:
+              patterns: ["**/price*.test.*", "**/payment*.test.*"]
+          enabled: true
+      ```
+
+      The seed habits that are NOT shown in overrides retain their default values. The project has 14 seed habits plus 1 custom habit.
+  - id: plsat-pg3-q3a
+    scenario: ''
+    question: An agent modifies 5 source files including payment logic but does not record a lore entry. What combination of violations will the stop hook report?
+    choices:
+      A: 'One violation: missing lore entry (block severity)'
+      B: 'Two violations: missing lore entry (block) and missing price validation tests (warn)'
+      C: 'One violation: missing price validation tests only — lore is advisory by default'
+      D: 'Three violations: missing lore, missing tests, and .purpose coverage'
+      E: The lore violation alone blocks the session — other checks are not evaluated after a block
+    correct: B
+    explanation: 'The stop hook evaluates ALL checks independently. `record-lore-for-significant` is overridden to `severity: block` and 5 files exceeds the 3-file threshold — this blocks. `check-price-validation` has `trigger: postflight` and `severity: warn`, and if payment files were modified without matching test files, it warns. Both violations are reported. The stop hook blocks because at least one violation has `severity: block`, but it reports all violations so the agent can fix everything in one pass.'
+    slot: pg-habits-q3
+    section: para-501
+    passageId: passage-habits-review
+    passage: |-
+      Your team's `.paradigm/habits.yaml` for an e-commerce project:
+
+      ```yaml
+      overrides:
+        ripple-before-modify:
+          severity: block
+        explore-before-implement:
+          severity: warn
+        test-new-components:
+          enabled: false
+        record-lore-for-significant:
+          severity: block
+
+      custom:
+        - id: check-price-validation
+          name: Validate Price Calculations
+          description: Ensure price calculation tests exist for any payment-related changes
+          category: testing
+          trigger: postflight
+          severity: warn
+          check:
+            type: tests-exist
+            params:
+              patterns: ["**/price*.test.*", "**/payment*.test.*"]
+          enabled: true
+      ```
+
+      The seed habits that are NOT shown in overrides retain their default values. The project has 14 seed habits plus 1 custom habit.
+  - id: plsat-060
+    scenario: |-
+      A project has these habits enabled:
+      - `commit-message-symbols` (on-commit/advisory) — checks commit messages match `type(#symbol):` format and include a `Symbols:` trailer
+      - `flow-coverage-for-multi-component` (postflight/advisory) — checks that changes spanning 3+ components have a documented $flow
+
+      An agent modifies `#auth-handler`, `#session-store`, `#login-page`, and `#password-reset` but does not create a $flow. The agent then commits with message: `fix: update auth logic`.
+    question: Which habits are violated?
+    choices:
+      A: 'Only commit-message-symbols — the message lacks type(#symbol): format'
+      B: Only flow-coverage — 4 components without a $flow
+      C: 'Both: commit message lacks #symbol in parens and Symbols: trailer, plus 4 components touched without a flow'
+      D: Neither — both are advisory and don't actually check anything
+      E: Only flow-coverage — the commit message format is correct
+    correct: C
+    explanation: 'The commit message `fix: update auth logic` matches the conventional prefix `fix:` but lacks a #symbol in parentheses (should be `fix(#auth-handler):`) and has no `Symbols:` trailer. Additionally, 4 components were modified (>= 3 threshold) without a documented $flow. Both habits are violated — the advisory severity means they log notes rather than blocking.'
+    slot: slot-060
+    section: para-501
+    variants:
+      - id: plsat-060b
+        scenario: |-
+          A project enables `context-session-awareness` (preflight/advisory) and `aspect-anchors-valid` (postflight/advisory).
+
+          An agent starts a session, immediately begins modifying `~rate-limited` aspect without calling any context or session recovery tools. After modifying the aspect's anchor locations, the agent calls `paradigm_aspect_check` to verify the anchors are valid.
+        question: What do the habit evaluations show?
+        choices:
+          A: Both followed — the agent did check the aspect
+          B: 'context-session-awareness: skipped (no context tools called); aspect-anchors-valid: followed (paradigm_aspect_check was called)'
+          C: Both skipped — advisory habits are always skipped
+          D: 'context-session-awareness: followed (aspect_check counts as context); aspect-anchors-valid: skipped (anchors were modified)'
+          E: Both partial — the agent did some work for each
+        correct: B
+        explanation: context-session-awareness checks if paradigm_session_health, paradigm_session_recover, or paradigm_session_checkpoint was called — paradigm_aspect_check does not count. aspect-anchors-valid checks if paradigm_aspect_check was called for touched aspects, which it was. So the first is skipped and the second is followed.
+  - id: plsat-061
+    scenario: |-
+      Sentinel groups 8 incidents affecting `#payment-service` with these error messages:
+      - 4 incidents: "Stripe API returned 429: rate limited"
+      - 2 incidents: "Payment webhook timeout after 30s"
+      - 2 incidents: "Connection reset by peer during payment callback"
+
+      The pattern suggester infers a resolution strategy from the grouped incidents.
+    question: What strategy will the suggester infer?
+    choices:
+      A: fix-code — the default for any group of incidents
+      B: retry — timeout and network-related errors dominate the group
+      C: scale-up — rate limiting means the service needs more capacity
+      D: rollback — the errors suggest a recent deployment broke something
+      E: config-change — the 429 means the API key needs updating
+    correct: B
+    explanation: 'The strategy inference checks error messages for keywords. ''timeout'' and ''connection reset'' match the retry strategy (timeout, network keywords). While ''429: rate limited'' could suggest scale-up, the ''timeout'' keyword in 2 messages triggers the retry check first in the keyword priority order. The inference returns the first matching strategy, which is retry for timeout/network errors.'
+    slot: slot-061
+    section: para-301
+  - id: plsat-062a
+    scenario: |-
+      A portal.yaml defines a gate `^subscription-required` with two locks:
+
+      ```yaml
+      locks:
+        - id: has-user
+          keys:
+            - expression: "req.user != null"
+        - id: active-sub
+          keys:
+            - expression: "req.user.subscription.status === 'active'"
+            - expression: "req.user.subscription.plan !== 'free'"
+      ```
+
+      You run `paradigm portal test --gate ^subscription-required`.
+    question: How many test cases does the gate lock introspection auto-generate?
+    choices:
+      A: 2 — one passing case and one failing case
+      B: 3 — one passing case, one per-lock failure case for each of the 2 locks, but no empty entity case
+      C: 4 — one passing case, one per-lock failure case for each of the 2 locks, and one empty entity case
+      D: 5 — one case per key expression plus one empty entity case
+      E: 1 — only the passing case with all properties populated
+    correct: C
+    explanation: 'Gate lock introspection generates: (1) a passing case with all properties populated from all key expressions, (2) one failure case per lock (omitting that lock''s required properties), and (3) an empty entity case that should always fail. With 2 locks, that''s 1 + 2 + 1 = 4 test cases.'
+    slot: slot-062
+    section: para-201
+    variants:
+      - id: plsat-062b
+        scenario: You need a machine-readable export of your portal configuration for a CI audit pipeline. Your portal.yaml has 5 gates and 12 routes.
+        question: Which command produces a structured export suitable for programmatic consumption in CI?
+        choices:
+          A: paradigm portal export --format json
+          B: paradigm portal export --format csv
+          C: paradigm portal export --format markdown
+          D: paradigm doctor --json
+          E: paradigm scan --verbose
+        correct: A
+        explanation: paradigm portal export --format json produces a structured JSON output with gates and routes arrays, ideal for CI pipelines. CSV is for spreadsheet analysis, markdown for documentation. paradigm doctor --json reports health checks, not portal config.
+  - id: plsat-063
+    scenario: You join a team working on a large codebase. Many source directories have code but no `.purpose` files documenting their components. You want to quickly generate draft documentation.
+    question: What is the correct approach using Paradigm's lint tooling?
+    choices:
+      A: paradigm lint --fix — automatically creates .purpose files for all undocumented directories
+      B: paradigm lint --auto-populate — scans source directories and suggests .purpose drafts, then paradigm lint --auto-populate --fix to write them
+      C: paradigm scan --fix — rebuilds the index and creates missing .purpose files
+      D: paradigm doctor --fix — finds missing documentation and generates stubs
+    correct: B
+    explanation: paradigm lint --auto-populate scans source directories (max depth 4) for undocumented components — directories containing source files but no .purpose file. Without --fix it reports suggestions; with --fix it writes draft .purpose files. paradigm lint --fix only fixes lint issues in existing .purpose files, it doesn't create new ones. scan and doctor don't generate .purpose files.
+    slot: slot-063
+    section: para-301
+  - id: plsat-064a
+    scenario: A team has both AGENTS.md and llms.txt in their Paradigm project. A new developer asks what each file is for.
+    question: Which statement correctly distinguishes the two files?
+    choices:
+      A: AGENTS.md is for Claude, llms.txt is for all other LLMs
+      B: AGENTS.md contains instructions (how to behave), llms.txt contains facts (what exists)
+      C: llms.txt replaces AGENTS.md in Paradigm v2
+      D: They contain the same information in different formats
+      E: AGENTS.md is auto-generated but llms.txt must be hand-written
+    correct: B
+    explanation: AGENTS.md is prescriptive — it tells agents what tools to use, what conventions to follow, and what workflow to observe. llms.txt is descriptive — it tells agents what symbols exist, what flows are defined, and how the project is structured. Both are auto-generated by Paradigm (sync agents and sync-llms respectively) and serve distinct purposes.
+    slot: slot-064
+    section: para-401
+    variants:
+      - id: plsat-064b
+        scenario: An AI agent spawned in isolation needs to orient itself before working on a task. It has access to AGENTS.md, MCP tools, and the full codebase.
+        question: What is the most token-efficient orientation sequence?
+        choices:
+          A: Read all .purpose files, then read portal.yaml
+          B: Read AGENTS.md → paradigm_session_recover → paradigm_navigate with context intent (~500 tokens total)
+          C: paradigm_search for every symbol type → read matching files
+          D: Read every file in .paradigm/ for full context
+          E: Call paradigm_status repeatedly until context is sufficient
+        correct: B
+        explanation: 'The Fresh Context Principle: AGENTS.md provides instructions and conventions, paradigm_session_recover provides previous session context, and paradigm_navigate with context intent provides task-relevant files. Total cost: ~500 tokens — compared to thousands of tokens for file-reading approaches.'
+  - id: plsat-065
+    scenario: |-
+      You have a `$checkout-flow` with these steps:
+      1. ^authenticated (gate)
+      2. #validate-cart (action)
+      3. #process-payment (action)
+      4. !order-placed (signal)
+
+      You run `paradigm flow diagram $checkout-flow`.
+    question: In the generated Mermaid diagram, what shapes represent each step type?
+    choices:
+      A: All steps are rectangles with different colors
+      B: Gates are diamonds, actions are rectangles, signals are rounded boxes
+      C: Gates are hexagons, actions are circles, signals are parallelograms
+      D: All steps are circles connected by labeled arrows
+      E: Gates are rounded boxes, actions are diamonds, signals are rectangles
+    correct: B
+    explanation: 'Paradigm''s Mermaid diagram generator uses conventional flowchart shapes: diamond shapes (decision points) for gates, rectangles for actions, and rounded rectangles for signals. Gates also show deny paths when a failResponse or errorSignal is defined. Steps are color-coded: yellow for gates, blue for actions, green for signals.'
+    slot: slot-065
+    section: para-201
+  - id: plsat-066
+    scenario: Your MCP-connected agent calls `paradigm_search` for `#auth` twice within 10 seconds. The project has a ToolCache with a 30-second TTL configured.
+    question: What happens on the second call?
+    choices:
+      A: The search runs again because each MCP call is stateless
+      B: The cached result is returned instantly without re-scanning the index
+      C: The cache is checked but always invalidated because search results may change
+      D: The second call is queued until the first cache entry expires
+      E: An error is returned because duplicate calls are rate-limited
+    correct: B
+    explanation: The ToolCache uses a time-based TTL (default 30 seconds). When the same tool is called with the same arguments within the TTL window, the cached result is returned immediately without re-executing the underlying scan. This saves significant compute for repeated discovery operations like search, status, and navigate.
+    slot: slot-066
+    section: para-401
+    variants:
+      - id: plsat-066b
+        scenario: An agent calls `paradigm_reindex` to rebuild the static index after modifying several .purpose files. The project has ToolCache enabled.
+        question: What happens to the ToolCache when reindex completes?
+        choices:
+          A: Nothing — the cache is independent of the index
+          B: Only search-related cache entries are invalidated
+          C: The entire cache is cleared to ensure fresh results from the rebuilt index
+          D: Cache entries are marked stale but still served until they expire naturally
+          E: The cache TTL is doubled to avoid redundant scans after reindex
+        correct: C
+        explanation: When paradigm_reindex completes successfully, it calls toolCache.clear() to invalidate ALL cached entries. This is critical because the reindex rebuilds the underlying data that search, navigate, and status tools depend on. Serving stale cached results after a reindex would return outdated symbol information.
+  - id: plsat-067
+    scenario: An agent has been working for 45 minutes, modifying 5 source files and touching symbols `#auth-middleware`, `^rate-limited`, and `!login-failed`. The session has 12 breadcrumbs recorded.
+    question: What triggers auto-lore drafting?
+    choices:
+      A: Auto-lore drafts after every file modification regardless of count
+      B: Auto-lore drafts when 3+ files are modified, generating a partial LoreEntry from session breadcrumbs
+      C: Auto-lore drafts only when the agent explicitly calls paradigm_lore_record
+      D: Auto-lore drafts at a fixed time interval (every 30 minutes)
+      E: Auto-lore drafts only during the on-stop habit check
+    correct: B
+    explanation: The draftLoreFromBreadcrumbs() function generates a partial LoreEntry when 3+ files have been modified in a session. It extracts tool usage statistics from breadcrumbs, includes the symbols touched and files modified, and tags the draft with 'auto-draft' for review. The 3-file threshold ensures trivial edits don't generate noise.
+    slot: slot-067
+    section: para-501
+    variants:
+      - id: plsat-067b
+        scenario: After a long coding session, the auto-lore system generates a draft entry. You inspect the draft and notice it has a tag you didn't add.
+        question: What tag does auto-lore always apply to drafted entries?
+        choices:
+          A: '`auto-generated` — marking it as machine-created'
+          B: '`auto-draft` — indicating it needs human review before finalization'
+          C: '`session-log` — categorizing it as a session record'
+          D: '`pending-review` — flagging it for team approval'
+          E: '`unverified` — warning that the content may be incomplete'
+        correct: B
+        explanation: Auto-drafted lore entries are always tagged with 'auto-draft' to distinguish them from manually recorded entries. This tag signals that the entry was machine-generated from session breadcrumbs and should be reviewed for accuracy before being treated as authoritative project history.
+  - id: plsat-068
+    scenario: |-
+      Your project's `.paradigm/config.yaml` contains:
+      ```yaml
+      limits:
+        habitsCacheTtlMs: 60000
+        threadTrailMax: 20
+        breadcrumbsMax: 100
+      ```
+    question: What do these configurable limits control?
+    choices:
+      A: Maximum file sizes for paradigm-managed files
+      B: Rate limits for MCP tool calls per session
+      C: Tunable parameters for habits cache duration, thread trail depth, and breadcrumb history length
+      D: Hard caps on the number of symbols, flows, and gates allowed
+      E: Timeout durations for CLI commands
+    correct: C
+    explanation: 'The LimitsConfig in config.yaml allows projects to tune operational parameters: habitsCacheTtlMs controls how long habit definitions are cached (default 30000ms), threadTrailMax sets the maximum breadcrumbs shown in thread trail output (default 10), and breadcrumbsMax sets the maximum breadcrumbs stored per session. These defaults work for most projects but can be adjusted for larger codebases.'
+    slot: slot-068
+    section: para-501
+    variants:
+      - id: plsat-068b
+        scenario: A large monorepo project finds that paradigm_search is running too frequently, consuming unnecessary compute. They want to increase the cache duration for MCP tool results.
+        question: Which config.yaml field controls MCP tool cache duration?
+        choices:
+          A: '`limits.searchCacheTtlMs` — specific to search operations'
+          B: '`limits.toolCacheTtlMs` — controls the ToolCache TTL for all cached MCP tools'
+          C: '`limits.mcpTimeoutMs` — sets the MCP response timeout'
+          D: '`cache.ttl` — global cache setting for all paradigm operations'
+          E: '`limits.habitsCacheTtlMs` — since habits and tools share the same cache'
+        correct: B
+        explanation: The limits.toolCacheTtlMs field in config.yaml controls the TTL for the ToolCache that wraps paradigm_search, paradigm_status, and paradigm_navigate. The default is 30000ms (30 seconds). Increasing this value reduces redundant computations but may serve slightly stale results. It's separate from habitsCacheTtlMs which controls the habits definition cache.
+  - id: plsat-069
+    scenario: Your team uses Paradigm's Global Brain (`~/.paradigm/`) to share wisdom, lore, and history across projects. After a year, the global directory has grown to contain hundreds of old entries.
+    question: How do you clean up old Global Brain entries?
+    choices:
+      A: Manually delete files from `~/.paradigm/` using `rm -rf`
+      B: '`paradigm global clean --older-than 90d` removes files older than the specified duration'
+      C: '`paradigm scan --prune` removes unused global entries'
+      D: Global Brain entries are automatically pruned on each `paradigm shift`
+      E: '`paradigm doctor --fix` cleans up stale global files'
+    correct: B
+    explanation: The `paradigm global clean` command scans ~/.paradigm/ directories (wisdom, lore, history, cache) for files older than the specified duration. The --older-than flag accepts human-readable durations like 90d, 30d, or 7d. Use --dry-run first to preview what would be deleted. This is safer than manual deletion because it respects directory structure and cleans up empty directories afterward.
+    slot: slot-069
+    section: para-501
+  - id: plsat-070
+    scenario: |-
+      A Claude Code plugin's `hooks.json` includes:
+      ```json
+      {
+        "compatibleVersions": {
+          "min": "3.0.0",
+          "max": "4.0.0"
+        }
+      }
+      ```
+      Your installed Paradigm CLI is version 3.1.6.
+    question: What happens when you run `paradigm hooks install`?
+    choices:
+      A: Installation fails because 3.1.6 is not exactly 3.0.0 or 4.0.0
+      B: Installation proceeds normally — 3.1.6 is within the compatible range
+      C: A warning is shown but installation is blocked until you upgrade
+      D: The plugin is downgraded to match version 3.0.0
+      E: The compatibleVersions field is ignored during installation
+    correct: B
+    explanation: The plugin version compatibility check compares the installed Paradigm version against the min/max range in hooks.json. Since 3.1.6 >= 3.0.0 and 3.1.6 < 4.0.0, installation proceeds normally. If the version were outside the range (e.g., 2.9.0 or 4.1.0), a warning would be displayed advising the user to update their Paradigm version or the plugin.
+    slot: slot-070
+    section: para-401
+    variants:
+      - id: plsat-070b
+        scenario: You're developing a Paradigm plugin and want to ensure it only works with Paradigm versions that support the habits system (introduced in v3.0).
+        question: Where do you declare this version requirement?
+        choices:
+          A: In the plugin's `package.json` under `peerDependencies`
+          B: 'In the plugin''s `hooks.json` under the `compatibleVersions` field with `min: "3.0.0"`'
+          C: In the plugin's `.purpose` file under `dependencies`
+          D: In the project's `.paradigm/config.yaml` under `plugins`
+          E: Version requirements are not enforceable — plugins work with any version
+        correct: B
+        explanation: Plugin version compatibility is declared in the plugin's hooks.json file using the compatibleVersions field. Setting min to '3.0.0' ensures that paradigm hooks install will warn users running older versions that lack habits support. This check runs at the start of hook installation before any hooks are written.
+  - id: plsat-071
+    scenario: You want to record a lore entry that credits both the human developer and the AI agent that collaborated on a feature. The lore system supports co-authorship tracking.
+    question: Which field on a LoreEntry captures AI collaboration?
+    choices:
+      A: '`author` — set to the AI agent''s name'
+      B: '`assistedBy` — with type (''agent'', ''tool'', or ''human''), id, and optional role'
+      C: '`contributors` — an array of all participant names'
+      D: '`metadata.aiModel` — storing the model name used'
+      E: '`tags` — add an ''ai-assisted'' tag'
+    correct: B
+    explanation: The assistedBy field on LoreEntry provides structured co-authorship tracking. It records the type of assistant (agent, tool, or human), their identifier (e.g., 'claude-opus-4', 'copilot'), and an optional role description. The author field remains the human developer, while assistedBy captures the AI collaboration context for project history.
+    slot: slot-071
+    section: para-501
+    variants:
+      - id: plsat-071b
+        scenario: Your team reviews lore entries from the past month and wants to understand how much AI assistance was involved in recent changes.
+        question: How does the `assistedBy` field help with this analysis?
+        choices:
+          A: It tracks token usage per AI interaction
+          B: It records the AI's confidence score for each change
+          C: It provides structured data (type, id, role) showing which AI tools or agents assisted each recorded session
+          D: It measures the percentage of code written by AI vs human
+          E: It links to the AI conversation transcript
+        correct: C
+        explanation: 'The assistedBy field captures three dimensions of AI collaboration: type (was it an agent like Claude, a tool like Copilot, or a human pair-programmer?), id (which specific model or tool?), and role (what was their contribution — implementation, review, planning?). This structured data enables teams to analyze collaboration patterns across their lore timeline.'
+  - id: plsat-072
+    scenario: A project has no `limits` section in `.paradigm/config.yaml`. An agent calls tools that rely on configurable limits — habits cache, thread trail, and ToolCache.
+    question: What values are used when limits are not configured?
+    choices:
+      A: All limits are set to 0 (unlimited)
+      B: An error is thrown requiring explicit configuration
+      C: 'Sensible defaults: habitsCacheTtlMs=30000, threadTrailMax=10, toolCacheTtlMs=30000, breadcrumbsMax=unlimited'
+      D: Limits are inherited from the Global Brain (~/.paradigm/) configuration
+      E: Each tool prompts the user to set a limit on first use
+    correct: C
+    explanation: 'All configurable limits have sensible defaults that match the pre-configuration behavior: habits cache refreshes every 30 seconds, thread trail shows the last 10 breadcrumbs, ToolCache entries expire after 30 seconds. These defaults work well for most projects. The limits section in config.yaml is entirely optional — only override when you have a specific need.'
+    slot: slot-072
+    section: para-501
+  - id: plsat-073
+    scenario: |-
+      An agent working on a complex feature calls these MCP tools in sequence:
+      1. `paradigm_status` (cached)
+      2. `paradigm_search` for `#auth` (cached)
+      3. Edits 3 files, adds a new component
+      4. `paradigm_reindex`
+      5. `paradigm_search` for `#auth` again
+    question: Does step 5 return the updated results including the new component?
+    choices:
+      A: No — the search cache still has the old results from step 2
+      B: Yes — reindex at step 4 clears all caches, so step 5 runs a fresh search against the rebuilt index
+      C: Only if 30 seconds have passed since step 2
+      D: Only if the agent explicitly called toolCache.clear()
+      E: The search always bypasses cache after a write operation
+    correct: B
+    explanation: 'The reindex operation at step 4 has two effects: it rebuilds the static index from .purpose files and clears the entire ToolCache. This means step 5 performs a fresh search against the newly rebuilt index, which includes the new component. This cache-invalidation-on-reindex pattern ensures that discovery tools always reflect the current state after structural changes.'
+    slot: slot-073
+    section: para-401
+  - id: plsat-074
+    scenario: 'An auto-lore draft is generated from session breadcrumbs after modifying 6 files. The breadcrumbs show: 4 Edit tool calls, 2 Write tool calls, 8 Read tool calls, 3 paradigm_navigate calls.'
+    question: What information does the auto-lore draft extract from these breadcrumbs?
+    choices:
+      A: Only the file paths that were modified
+      B: A complete diff of all code changes
+      C: Tool usage statistics (edit count, write count, read count) plus modified files and symbols touched
+      D: The full text of every tool call and response
+      E: Only the symbols referenced in paradigm_navigate calls
+    correct: C
+    explanation: The auto-lore drafting function analyzes breadcrumbs to extract tool usage statistics — counting edits, writes, reads, and paradigm tool calls. It combines this with the list of modified files and symbols touched to generate a summary. The draft doesn't include full diffs or response text, keeping the lore entry concise and focused on what happened rather than how.
+    slot: slot-074
+    section: para-501
+    variants:
+      - id: plsat-074b
+        scenario: An agent completes a task that modified only 2 files. The habits system runs the on-stop check.
+        question: Will auto-lore drafting generate an entry?
+        choices:
+          A: Yes — any file modification triggers auto-lore
+          B: No — auto-lore requires 3+ modified files to trigger
+          C: Yes — but only if the session lasted longer than 15 minutes
+          D: No — auto-lore only runs during postflight, not on-stop
+          E: It depends on the project's limits.breadcrumbsMax setting
+        correct: B
+        explanation: 'Auto-lore drafting has a 3-file minimum threshold. Modifying only 2 files does not trigger a draft because such small changes are typically routine fixes that don''t warrant project history entries. This threshold aligns with the lore recording decision tree: ''Did I modify 3+ source files? YES → Record lore.'' The threshold prevents noise in project history.'
+  - id: plsat-075
+    scenario: |-
+      You run `paradigm global clean --older-than 30d --dry-run` and see:
+      ```
+      Would delete 23 files from wisdom/
+      Would delete 45 files from lore/
+      Would delete 12 files from history/
+      Would delete 0 files from cache/
+      ```
+    question: What is the safest next step?
+    choices:
+      A: Run `paradigm global clean --older-than 30d` to delete all 80 files immediately
+      B: Review the specific files listed, then run without --dry-run if the deletions look correct
+      C: Run `paradigm global clean --older-than 7d` to be more aggressive
+      D: Delete the `~/.paradigm/` directory entirely since most files are old
+      E: Skip cleanup — 80 files is too many to safely remove
+    correct: B
+    explanation: 'The --dry-run flag exists specifically to preview destructive operations. The safest workflow is: (1) dry-run to see what would be deleted, (2) review the file list for anything you want to keep, (3) run without --dry-run once satisfied. Global Brain files contain cross-project wisdom and lore that may be valuable — always review before bulk deletion.'
+    slot: slot-075
+    section: para-501
+  - id: plsat-076
+    scenario: Your project uses both the ToolCache (for MCP tool results) and the habits cache (for habit definitions). Both have configurable TTLs.
+    question: Why are these two separate caches rather than one unified cache?
+    choices:
+      A: Historical accident — they were built by different teams
+      B: 'They cache different data types with different invalidation needs: tool results change on reindex, habit definitions change on file edits'
+      C: Performance — two smaller caches are faster than one large cache
+      D: Security — MCP tool results must be isolated from habit definitions
+      E: They are the same cache with different configuration keys
+    correct: B
+    explanation: The ToolCache caches MCP tool results (search, navigate, status) and is invalidated on reindex when the underlying index changes. The habits cache stores parsed habit definitions from habits.yaml and is invalidated when the file's modification time changes. These fundamentally different invalidation strategies require separate cache implementations — flushing all habit definitions because a .purpose file changed would be wasteful, and vice versa.
+    slot: slot-076
+    section: para-401
+  - id: plsat-077
+    scenario: You're configuring a large monorepo with 500+ symbols. Sessions often span 30+ minutes with many breadcrumbs. You want to optimize the Paradigm configuration.
+    question: Which limits configuration would be most appropriate?
+    choices:
+      A: Set all limits to maximum values for the largest possible buffers
+      B: Increase threadTrailMax to 25 and toolCacheTtlMs to 60000 for the larger codebase, keep other defaults
+      C: Decrease all TTLs to 5000ms to ensure data is always fresh
+      D: Remove the limits section entirely and rely on defaults
+      E: Set breadcrumbsMax to 10 to save memory
+    correct: B
+    explanation: For large monorepos, increasing threadTrailMax (from default 10 to 25) provides more session context for complex tasks, and increasing toolCacheTtlMs (from 30s to 60s) reduces redundant index scans across the larger symbol space. Other defaults work well regardless of project size. Setting TTLs too low causes excessive recomputation, while setting breadcrumbsMax too low loses valuable session context.
+    slot: slot-077
+    section: para-501
+  - id: plsat-078
+    scenario: 'Your project has aspects categorized as rules, decisions, constraints, configurations, and invariants. A new aspect states: ''API response payloads must not exceed 5MB.'' A developer is unsure which category to assign.'
+    question: Which aspect category is correct for this aspect?
+    choices:
+      A: '`rule` — because it uses ''must not'', indicating a mandatory pattern'
+      B: '`constraint` — because it defines a quantitative limit (5MB) on system behavior'
+      C: '`configuration` — because the 5MB value could be changed per environment'
+      D: '`invariant` — because it must always hold true'
+      E: '`decision` — because someone decided 5MB was the right limit'
+    correct: B
+    explanation: 'The key indicator is the quantitative limit: ''5MB''. Constraints define measurable boundaries on system behavior — file sizes, rate limits, timeouts, quotas. While ''must not exceed'' sounds like a rule, the category inference system prioritizes ''limit'', ''maximum'', ''cannot exceed'' keywords for `constraint`. A rule would be a pattern without a specific numeric boundary (e.g., ''all responses must include request IDs''). Configuration would apply if the value explicitly varies by environment.'
+    slot: slot-078
+    section: para-501
+    variants:
+      - id: plsat-078b
+        scenario: 'An aspect definition reads: ''The team decided to use PostgreSQL over MongoDB for the user service due to relational query requirements.'' No category field is explicitly set.'
+        question: What category will Paradigm's category inference assign?
+        choices:
+          A: '`rule` — because it implies PostgreSQL must be used'
+          B: '`constraint` — because it limits the database technology'
+          C: '`decision` — because the description contains ''decided'' and ''chose'''
+          D: '`configuration` — because the database choice is a deployment setting'
+          E: '`invariant` — because the database choice should never change'
+        correct: C
+        explanation: Category inference uses keyword matching on the description. Words like 'decided', 'chosen', 'selected', 'opted' trigger the `decision` category. The description explicitly says 'The team decided to use PostgreSQL over MongoDB' — this is a textbook architectural decision with rationale.
+  - id: plsat-079
+    scenario: |-
+      Your aspect graph has the following edges:
+      - `~token-expiry-24h` --depends-on--> `~jwt-signing-rs256`
+      - `~jwt-signing-rs256` --enforced-by--> `#auth-middleware`
+      - `~cache-aggressively` --contradicts--> `~always-fresh-data`
+      - `~rate-limit-v2` --supersedes--> `~rate-limit-v1`
+
+      You need to modify `~jwt-signing-rs256` to change the signing algorithm.
+    question: Which aspect will paradigm_ripple surface as impacted through the 'depends-on' edge?
+    choices:
+      A: '`~cache-aggressively` — because it has a contradicts edge in the same graph'
+      B: '`~token-expiry-24h` — because it depends-on the aspect being modified'
+      C: '`~rate-limit-v2` — because it supersedes another aspect'
+      D: '`#auth-middleware` — because it enforces the aspect'
+      E: All four aspects — ripple follows all edge types equally
+    correct: B
+    explanation: Ripple follows dependency edges to discover indirect impacts. `~token-expiry-24h` has a `depends-on` edge to `~jwt-signing-rs256`, meaning changes to the signing algorithm may affect token expiry behavior. `#auth-middleware` has an `enforced-by` edge (reverse direction — it enforces the aspect, but the aspect doesn't depend on it for correctness). The contradicts and supersedes edges involve unrelated aspects.
+    slot: slot-079
+    section: para-501
+  - id: plsat-080
+    scenario: |-
+      You run `paradigm_aspect_search({ query: 'jwt expiry' })` and get three results:
+      - Tier 1 (learned): `~token-expiry-24h` (weight: 3.0)
+      - Tier 2 (FTS5): `~session-timeout-30m` (BM25: 0.7)
+      - Tier 3 (fuzzy): `~jwt-refresh-rotation` (distance: 2)
+
+      The Tier 1 result is exactly what you need.
+    question: What should you do to reinforce this search mapping?
+    choices:
+      A: Nothing — Tier 1 results are already reinforced by being in the search_weights table
+      B: 'Call `paradigm_aspect_confirm({ query: ''jwt expiry'', aspectId: ''token-expiry-24h'' })` to add +1.0 weight and decay the others'
+      C: Manually update the search_weights SQLite table to increase the weight
+      D: 'Call `paradigm_aspect_get({ aspectId: ''token-expiry-24h'' })` to register a direct access'
+      E: Call `paradigm_reindex` to rebuild the learned mappings
+    correct: B
+    explanation: paradigm_aspect_confirm is the feedback mechanism for the learning system. Calling it with the query and selected aspect ID adds +1.0 to the confirmed result's weight (3.0 → 4.0) and decays all other results for that query by *0.95. This reinforces the correct mapping. Reindex rebuilds the graph but does not affect search_weights — those persist across reindexes. Direct access via aspect_get records a heatmap entry but does not affect search learning.
+    slot: slot-080
+    section: para-501
+  - id: plsat-081
+    scenario: The aspect graph materialization pipeline runs during `paradigm_reindex`. It processes aspects from .purpose files through a specific sequence of steps.
+    question: What is the correct order of the five-step materialization pipeline?
+    choices:
+      A: materialize aspects → open graph → materialize lore links → infer lore edges → close graph
+      B: open graph → materialize aspects → materialize lore links → infer lore edges → close graph
+      C: open graph → infer lore edges → materialize aspects → materialize lore links → close graph
+      D: materialize aspects → materialize lore links → open graph → infer lore edges → close graph
+      E: open graph → materialize lore links → materialize aspects → close graph → infer lore edges
+    correct: B
+    explanation: 'The materialization pipeline follows a strict order: (1) openAspectGraph opens or creates the SQLite database and clears all tables. (2) materializeAspects reads .purpose files and writes aspects, anchors, and explicit/inferred edges. (3) materializeLoreLinks creates entries connecting aspects to their referenced lore entries. (4) inferLoreEdges scans for shared lore references between aspects and creates learned edges. (5) closeAspectGraph commits changes, runs ANALYZE, and closes the connection.'
+    slot: slot-081
+    section: para-501
+  - id: plsat-082
+    scenario: |-
+      You define an aspect with an `applies-to` reference to a component:
+
+      ```yaml
+      ~audit-required:
+        description: Financial operations must produce audit logs
+        applies-to: ["#payment-service"]
+        edges:
+          - target: "#audit-middleware"
+            relation: enforced-by
+      ```
+    question: What edges will the materialization pipeline create, and what are their origins and weights?
+    choices:
+      A: 'One edge: `enforced-by` to `#audit-middleware` with origin `explicit` and weight 1.0'
+      B: 'Two edges: `enforced-by` to `#audit-middleware` (origin: explicit, weight: 1.0) and an inferred edge to `#payment-service` (origin: inferred, weight: 0.5)'
+      C: 'Two edges: both with origin `explicit` and weight 1.0'
+      D: 'Three edges: one explicit, one inferred, and one learned'
+      E: 'One edge: `applies-to` is documentation only and does not generate edges'
+    correct: B
+    explanation: The materialization pipeline creates edges from two sources. The explicit `edges` field generates an edge to `#audit-middleware` with origin `explicit` and weight 1.0. The `applies-to` reference generates an inferred edge to `#payment-service` with origin `inferred` and weight 0.5. Inferred edges have lower weight because they represent a weaker relationship than explicitly declared edges.
+    slot: slot-082
+    section: para-501
+  - id: plsat-083
+    scenario: |-
+      An aspect `~session-timeout-30m` was created 3 months ago with an anchor at `src/middleware/session.ts:15-25`. Since then, a developer refactored the file and the session timeout logic is now at lines 40-55. The aspect definition was not updated.
+
+      You run `paradigm_aspect_drift({ aspectId: 'session-timeout-30m' })`.
+    question: What will the drift detection report?
+    choices:
+      A: No drift — the file still exists, so the anchor is valid
+      B: 'Drift detected: the SHA-256 content hash of lines 15-25 no longer matches the stored hash, indicating the code at the anchored location has changed'
+      C: An error — the anchor line range exceeds the current file length
+      D: Partial drift — only some lines within the range changed
+      E: No drift — drift detection only checks whether the file exists, not its contents
+    correct: B
+    explanation: Drift detection computes a SHA-256 hash of the current code at the anchored line range (15-25) and compares it to the hash stored during materialization. Since the timeout logic moved to different lines, the code at lines 15-25 is now different — the hashes will not match, and drift is reported. The fix is to update the anchor to `src/middleware/session.ts:40-55` to point to the new location of the timeout logic.
+    slot: slot-083
+    section: para-501
+  - id: plsat-084
+    scenario: |-
+      You run `paradigm_aspect_suggest_scan({ filePath: 'src/auth/jwt.ts' })` on a file containing:
+
+      ```typescript
+      const TOKEN_EXPIRY = 86400; // 24 hours in seconds
+      const MAX_REFRESH_ATTEMPTS = 3;
+      if (process.env.NODE_ENV === 'production') { ... }
+      const EMAIL_REGEX = /^[a-zA-Z0-9+_.-]+@[a-zA-Z0-9.-]+$/;
+      ```
+    question: Which of the 8 built-in detectors will fire for each pattern?
+    choices:
+      A: All four lines trigger the 'magic numbers' detector only
+      B: 'TOKEN_EXPIRY: time values; MAX_REFRESH_ATTEMPTS: magic numbers; process.env: environment checks; EMAIL_REGEX: regex patterns'
+      C: 'TOKEN_EXPIRY: magic numbers; MAX_REFRESH_ATTEMPTS: rate limits; process.env: feature flags; EMAIL_REGEX: hardcoded strings'
+      D: All four lines trigger the 'hardcoded strings' detector
+      E: 'TOKEN_EXPIRY: configuration; MAX_REFRESH_ATTEMPTS: constraint; process.env: environment checks; EMAIL_REGEX: assertion guards'
+    correct: B
+    explanation: 'Each pattern matches a specific detector: (1) 86400 with a comment mentioning ''24 hours'' matches the time values detector (durations, timeouts, TTLs, expiry). (2) MAX_REFRESH_ATTEMPTS = 3 is a numeric literal that is not 0 or 1, matching the magic numbers detector. (3) process.env.NODE_ENV matches the environment checks detector. (4) The regular expression literal matches the regex patterns detector. The detectors are specialized for these exact pattern types.'
+    slot: slot-084
+    section: para-501
+  - id: plsat-085
+    scenario: |-
+      Two aspects in your project both reference lore entry `L-2026-01-15-003`:
+      - `~token-expiry-24h` has `lore: [L-2026-01-15-003]`
+      - `~refresh-token-rotation` has `lore: [L-2026-01-15-003]`
+
+      Neither aspect has an explicit edge to the other.
+    question: What happens during the `inferLoreEdges` step of materialization?
+    choices:
+      A: Nothing — edges are only created from explicit YAML definitions
+      B: A learned edge is created between the two aspects with origin 'learned' and weight proportional to shared lore references
+      C: Both aspects are merged into a single aspect
+      D: A lore_links entry is created but no edge is generated
+      E: An explicit edge with weight 1.0 is created between them
+    correct: B
+    explanation: The inferLoreEdges step scans the lore_links table for aspects that share lore references. When two aspects both reference the same lore entry, a learned edge is created between them with origin 'learned' and a weight proportional to the number of shared references. This discovers implicit relationships — aspects that were discussed in the same lore context are likely related even without explicit edges.
+    slot: slot-085
+    section: para-501
+  - id: plsat-086
+    scenario: |-
+      Your project has three edge origins in the aspect graph:
+      - Explicit edges (weight 1.0) from YAML `edges` fields
+      - Inferred edges (weight 0.5) from `applies-to` references
+      - Learned edges from shared lore references
+
+      During recursive ripple, the BFS traverses: an explicit edge (1.0) then an inferred edge (0.5) then another inferred edge (0.5).
+    question: What is the cumulative path weight after these three hops, and will it be pruned by the default minWeight threshold?
+    choices:
+      A: 'Weight: 2.0 (additive) — well above the 0.1 threshold, not pruned'
+      B: 'Weight: 0.25 (multiplicative: 1.0 * 0.5 * 0.5) — above 0.1, not pruned'
+      C: 'Weight: 0.5 (only the weakest edge counts) — above 0.1, not pruned'
+      D: 'Weight: 0.0625 (multiplicative: 1.0 * 0.25 * 0.25) — below 0.1, pruned'
+      E: 'Weight: 0.167 (average of all three) — above 0.1, not pruned'
+    correct: B
+    explanation: 'Recursive ripple uses multiplicative decay: the weight at each hop is multiplied by the edge weight. Starting at 1.0, after an explicit edge (1.0): 1.0 * 1.0 = 1.0. After an inferred edge (0.5): 1.0 * 0.5 = 0.5. After another inferred edge (0.5): 0.5 * 0.5 = 0.25. The cumulative weight 0.25 is above the default minWeight threshold of 0.1, so this path is NOT pruned. One more inferred edge would drop it to 0.125, still above threshold. Two more would reach 0.0625, below threshold and pruned.'
+    slot: slot-086
+    section: para-501
+  - id: plsat-087
+    scenario: Your project's aspect graph SQLite database at `.paradigm/aspect-graph.db` has six tables. During a governance review, you want to understand which aspects are discovered most frequently and how they are typically found.
+    question: Which table stores this information, and what are its columns?
+    choices:
+      A: The `aspects` table with an `access_count` column
+      B: The `edges` table with a `traversal_count` column
+      C: 'The `heatmap` table with columns: aspect_id, access_type, count, and last_accessed'
+      D: The `search_weights` table with a `hit_count` column
+      E: The `anchors` table with a `reference_count` column
+    correct: C
+    explanation: 'The `heatmap` table tracks aspect access patterns with four columns: `aspect_id` (which aspect), `access_type` (how it was discovered: search, ripple, navigate, or direct), `count` (frequency), and `last_accessed` (timestamp). This table powers `paradigm_aspect_heatmap` and reveals whether aspects are typically found via search, encountered during ripple analysis, discovered through navigation, or accessed by direct ID lookup.'
+    slot: slot-087
+    section: para-501
+  - id: plsat-088
+    scenario: You want to extend `paradigm_aspect_suggest_scan` to detect SOC2 compliance annotations specific to your project. The built-in 8 detectors do not cover this pattern.
+    question: How do you add a custom detector?
+    choices:
+      A: Edit the Paradigm source code to add a 9th built-in detector
+      B: Define a custom detector in `.paradigm/aspect-detectors.yaml` with regex patterns, language filters, and suggested category/severity
+      C: Create a `.paradigm/plugins/soc2-detector.js` plugin file
+      D: Add a `detectors` section to `.paradigm/config.yaml`
+      E: Custom detectors are not supported — use paradigm_aspect_search instead
+    correct: B
+    explanation: Custom detectors are defined in `.paradigm/aspect-detectors.yaml`. Each detector specifies an id, name, description, regex patterns with language filters, and suggestions for category, severity, and tags. Custom detectors are loaded alongside the built-in 8 during `paradigm_aspect_suggest_scan`, extending the detection system without modifying Paradigm's source code.
+    slot: slot-088
+    section: para-501
+  - id: plsat-089
+    scenario: 'During a quarterly governance review of a project with 150 aspects, the heatmap shows 40 aspects with zero access. The drift audit reveals 12 drifted anchors. The category distribution is: 95 rules, 20 constraints, 15 configurations, 12 decisions, 8 invariants.'
+    question: What does the category distribution suggest about this project's aspect governance?
+    choices:
+      A: The distribution is healthy — rules should always be the majority
+      B: The project may be over-documenting constraints as rules, and under-documenting strategic decisions — review whether some 'rules' are actually constraints or decisions
+      C: The project needs more invariants to balance the distribution
+      D: Configuration aspects should equal rules in a well-governed project
+      E: The 40 zero-access aspects indicate the project should reduce to 110 aspects
+    correct: B
+    explanation: A 63% concentration in the `rule` category (95 out of 150) suggests over-classification. Many numeric limits (which should be constraints) and architectural choices (which should be decisions) may be categorized as rules. The low decision count (12) is a red flag — a project with 150 aspects likely made more than 12 strategic decisions. The governance review should reclassify mistyped aspects and document missing decisions. Zero-access aspects (40) are a separate concern requiring individual evaluation.
+    slot: slot-089
+    section: para-501
+  - id: plsat-090
+    scenario: 'Your team uses Paradigm task management to track work across context windows. An agent creates three tasks on 2026-03-10: a high-priority auth bug, a medium-priority docs update, and a low-priority refactor. Later that day, a fourth task is created. The next morning (2026-03-11), a new agent session starts and calls `paradigm_session_recover`.'
+    question: What task ID is assigned to the fourth task on 2026-03-10, and how are tasks surfaced in the new session?
+    choices:
+      A: T-2026-03-10-004. All four tasks are fully displayed in the recovery payload.
+      B: T-2026-03-10-004. The top 5 open tasks sorted by priority are surfaced in the session recovery, so all four appear (high first, then medium, then low).
+      C: T-004. Only tasks explicitly pinned to the session are recovered.
+      D: T-2026-03-11-001. Task IDs reset per calendar day, so recovery re-numbers them.
+      E: T-2026-03-10-004. Tasks are not surfaced automatically — the agent must call `paradigm_task_list` to see them.
+    correct: B
+    explanation: 'Task IDs follow the format T-YYYY-MM-DD-NNN with per-date sequential numbering, so the fourth task on 2026-03-10 is T-2026-03-10-004. Tasks are designed to survive context windows — on session recovery, the top 5 open tasks (sorted by priority: high > medium > low) are automatically surfaced. Since there are only four open tasks, all four appear. This ensures continuity without requiring the agent to manually query task state.'
+    slot: slot-090
+    section: para-501
+  - id: plsat-091
+    scenario: 'An agent finishes a debugging session and wants to record the root cause and resolution as a lasting insight, grouped under the `arc:auth-hardening` arc. The agent calls `paradigm_lore_record` with `type: "insight"`, `tags: ["arc:auth-hardening", "assessment:insight"]`, a summary, and a body with the detailed analysis. The author is `ascend` and the timestamp is `2026-04-02T16:30:00Z`.'
+    question: Where is the entry stored, and how does the arc grouping work?
+    choices:
+      A: Stored in `.paradigm/assessments/arcs/arc-auth-hardening/entries/` — arcs have their own storage directories.
+      B: Stored in `.paradigm/lore/entries/2026-04-02/` as a `.lore` file — arcs are just tag prefixes, not separate storage.
+      C: Stored in `.paradigm/lore/arcs/auth-hardening/` — arc entries get their own subdirectory.
+      D: Stored in `.paradigm/lore/entries/` root directory — no date partitioning for arc entries.
+      E: Stored in both `.paradigm/lore/` and `.paradigm/assessments/` — the system maintains backward compatibility.
+    correct: B
+    explanation: 'All lore entries are stored in `.paradigm/lore/entries/{date}/` as `.lore` files, regardless of their tags. Arcs are simply tag prefixes (e.g., `arc:auth-hardening`) — they require no separate directory structure or management. To find all entries in an arc, use `paradigm_lore_search` with `tag: "arc:auth-hardening"`. This unified storage eliminates the complexity of a separate assessment system while preserving full arc-based organization through tags.'
+    slot: slot-091
+    section: para-501
+  - id: plsat-092
+    scenario: 'A developer wants to record retrospectives about a failed deployment. They have no prior entries tagged with `arc:platform-stability`. The agent calls `paradigm_lore_record` with `type: "retro"`, `tags: ["arc:platform-stability", "assessment:retro"]`, a title, summary, and body describing the failure and lessons learned.'
+    question: What happens when you use a new arc tag that no prior entries have?
+    choices:
+      A: The call fails — arcs must be explicitly created before tagging entries.
+      B: The entry is recorded normally — arcs are just tag prefixes, no creation step needed. The arc exists as soon as an entry has the tag.
+      C: The system auto-creates a `.paradigm/lore/arcs/platform-stability/` directory to track the arc.
+      D: The entry is recorded but flagged as orphaned until an arc is formally registered.
+      E: The tag is rejected because it does not match an existing arc in the arc registry.
+    correct: B
+    explanation: 'Arcs in the unified lore system are simply tag prefixes — no explicit creation needed. The first entry tagged with `arc:platform-stability` effectively creates that arc. To find all entries in this arc later, use `paradigm_lore_search` with `tag: "arc:platform-stability"`. To close the arc, add `arc-closed` and `arc-status:complete` tags to its entries. This tag-based approach eliminates the overhead of managing separate arc directories and YAML files.'
+    slot: slot-092
+    section: para-501
+  - id: plsat-093
+    scenario: 'Your project has been running for six months. The codebase has 200+ commits in git and 57 lore entries: 45 are `agent-session` type (automatic session records), 8 have `arc:*` tags (retrospectives and insights grouped into thematic arcs), and 4 are `decision` type (architectural decisions). A new team member asks how lore''s different entry types and tags work together.'
+    question: Which statement BEST describes Paradigm's unified lore model?
+    choices:
+      A: Lore entries are all the same — tags are purely cosmetic and do not affect searching or organization.
+      B: Lore is the single project memory system. Entry types classify the nature of knowledge (session, retro, insight, decision), while tags like `arc:*` group related entries into themes — both are filterable via `paradigm_lore_search`.
+      C: Session entries and reflection entries are stored in separate directories, with tags used only for cross-referencing between them.
+      D: The `arc:*` tags are managed by a separate arc subsystem that must be initialized before use.
+      E: Entry types are deprecated — tags alone drive all classification in the new model.
+    correct: B
+    explanation: 'Paradigm''s unified lore model uses one system with two classification axes: entry `type` classifies the nature of the knowledge (agent-session for automated records, retro for retrospectives, insight for patterns, decision for choices, etc.), while tags provide flexible grouping (arc:* for thematic arcs, assessment:* for reflection type, plus arbitrary project tags). Both are searchable via `paradigm_lore_search` — you can filter by type, tag prefix, symbol, author, and date range. All entries live in the same `.paradigm/lore/entries/` directory structure regardless of type or tags.'
+    slot: slot-093
+    section: para-501
+  - id: plsat-094
+    scenario: 'You receive a task: "Add a new Settings page to the application." The project has a `.paradigm/protocols/` directory with several `.protocol` files. You know that previous agents added similar pages (Logs, Events, Dashboard) following the same pattern each time.'
+    question: What should you do FIRST before exploring the codebase?
+    choices:
+      A: Read every existing page component to understand the pattern
+      B: Call `paradigm_protocol_search` with your task description to check for a matching protocol
+      C: Call `paradigm_lore_record` to document that you are starting the task
+      D: Call `paradigm_protocol_record` to create a new protocol for the Settings page
+      E: Read the `.paradigm/protocols/index.yaml` file directly to scan for relevant entries
+    correct: B
+    explanation: paradigm_protocol_search is the agent's first stop before exploring the codebase. It takes a natural language task description and returns matching protocols with steps, exemplar files, and freshness info — typically saving thousands of exploration tokens. Reading existing pages (A) is exactly the expensive exploration that protocols prevent. Recording lore (C) is done after work, not before. Recording a protocol (D) is done after completing repeatable work. Reading index.yaml directly (E) bypasses the fuzzy search that matches task descriptions to protocols.
+    slot: slot-094
+    section: para-301
+    variants:
+      - id: plsat-094b
+        scenario: 'An agent needs to add a new API endpoint to the project. The project has 15 recorded protocols covering common tasks. The agent calls `paradigm_protocol_search({ task: "add a new API endpoint" })` and gets back a protocol with 4 steps: create route file, add handler, register route, verify with build.'
+        question: What should the agent do next?
+        choices:
+          A: Ignore the protocol and explore the codebase to find its own approach
+          B: Call `paradigm_protocol_get` with the protocol ID to get full details, then follow the steps using the exemplar as reference
+          C: Call `paradigm_protocol_record` to save the protocol it just found
+          D: Run `paradigm_reindex` to make sure the protocol is up to date
+          E: Call `paradigm_protocol_validate` to check all protocols before proceeding
+        correct: B
+        explanation: After finding a matching protocol via search, the next step is paradigm_protocol_get to retrieve full details (including the exemplar file path and detailed step notes), then follow the steps. The exemplar is the canonical file to study for the pattern. Ignoring the protocol (A) wastes the lookup. Recording (C) is for new protocols. Reindex (D) and full validation (E) are maintenance operations, not implementation steps.
+  - id: plsat-095
+    scenario: 'An agent just finished adding a new Sentinel event schema — the third such schema added to the project this month. Each time, the agent followed the same steps: create a schema file, register it in the schema index, add a migration, and verify. No protocol exists for this task yet.'
+    question: What should the agent do regarding protocols?
+    choices:
+      A: Nothing — protocols are only created by project maintainers, not agents
+      B: Call `paradigm_protocol_record` to capture the repeatable pattern it just followed
+      C: Edit an existing protocol to add the schema steps as a sub-procedure
+      D: Wait for `paradigm_reindex` to auto-generate a protocol from git history
+      E: File an issue asking a human to write the protocol later
+    correct: B
+    explanation: Protocols are captured AFTER completing work, by the agent that did the work. When an agent completes a repeatable task and no protocol existed, it should call paradigm_protocol_record with the steps it followed, trigger phrases, tags, and an exemplar file. This ensures the next agent that receives a similar task can skip exploration entirely. Reindex (D) validates existing protocols but does not auto-generate new ones from git history.
+    slot: slot-095
+    section: para-301
+    variants:
+      - id: plsat-095b
+        scenario: After recording lore for a session where the agent created two new view components following the existing LogsView pattern, the `paradigm_lore_record` response includes a `protocol_suggestion` field with a draft protocol.
+        question: What triggered this protocol suggestion?
+        choices:
+          A: The agent explicitly asked for protocol suggestions in the lore_record call
+          B: The lore system detected that the session created new files following existing patterns in the same directory
+          C: All lore entries automatically include protocol suggestions
+          D: The protocol suggestion was cached from a previous session
+          E: The lore system runs paradigm_protocol_search on every lore entry
+        correct: B
+        explanation: 'When paradigm_lore_record is called, it runs a detection heuristic: if the session created 2+ new files in a directory that already has similar files, or modified the same ''registration'' files that existing protocols touch, it includes a protocol_suggestion in the response. This nudges agents to capture repeatable patterns without manual intervention. Not all lore entries trigger suggestions (C) — only those with detectable repeatable patterns.'
+  - id: plsat-096
+    scenario: During `paradigm_reindex`, the system validates all protocols. Protocol P-add-view references `ui/src/views/LogsView.tsx` as its exemplar. The file still exists but was significantly refactored two weeks after the protocol was last verified.
+    question: What status will the reindex assign to this protocol?
+    choices:
+      A: '`current` — the file still exists, so the protocol is valid'
+      B: '`stale` — the exemplar has been modified since the protocol was last verified'
+      C: '`broken` — any change to a referenced file invalidates the protocol'
+      D: '`deprecated` — protocols older than 30 days are automatically deprecated'
+      E: '`unknown` — reindex cannot determine status without running the protocol'
+    correct: B
+    explanation: 'During reindex validation, a protocol is marked ''stale'' when its exemplar or referenced files have been modified since last_verified. The file still exists (so it is not ''broken''), but the protocol''s steps might no longer match the current code pattern. A ''broken'' status (C) is reserved for when referenced files are missing entirely. Stale protocols still work but should be reviewed and refreshed after successful use via paradigm_protocol_update with refresh: true.'
+    slot: slot-096
+    section: para-301
+    variants:
+      - id: plsat-096b
+        scenario: 'An agent calls `paradigm_protocol_validate({ id: "P-add-api-route" })`. The protocol''s step 2 references the file `src/routes/index.ts`, but that file was deleted during a recent refactoring.'
+        question: What status will the validation assign?
+        choices:
+          A: '`stale` — a referenced file has changed'
+          B: '`current` — the protocol itself is still syntactically valid'
+          C: '`broken` — a referenced file no longer exists'
+          D: '`warning` — the file might be temporarily missing'
+          E: '`archived` — protocols with missing references are auto-archived'
+        correct: C
+        explanation: A 'broken' status means one or more files referenced by the protocol (targets, exemplars, or template_from) no longer exist. This is more severe than 'stale' (where files exist but have been modified). A broken protocol cannot be reliably followed until its references are updated to point to existing files via paradigm_protocol_update.
+  - id: plsat-097
+    scenario: 'You run `paradigm init` on an existing Next.js project. The output shows `discipline: fullstack` and `stack: nextjs`. Your colleague asks what the difference is between a discipline and a stack preset.'
+    question: Which statement BEST describes the relationship between disciplines and stack presets?
+    choices:
+      A: They are the same thing — 'discipline' is the old name and 'stack preset' is the new name
+      B: Disciplines define domain-level symbol mappings (web, backend, mobile), while stack presets layer framework-specific configuration (Next.js, FastAPI, SwiftUI) on top of the discipline
+      C: Stack presets replace disciplines entirely — once a preset is detected, the discipline is ignored
+      D: Disciplines are for code organization and stack presets are for deployment configuration
+      E: Stack presets are only used for auto-scan patterns, while disciplines control everything else
+    correct: B
+    explanation: 'Disciplines and stack presets are a two-layer system. The discipline (e.g., ''fullstack'') defines broad symbol mappings for the development domain. The stack preset (e.g., ''nextjs'') adds framework-specific refinements: scan hints for Next.js patterns like app/ routes and server components, purpose-required paths, and additional symbol mappings. The preset extends the discipline — it does not replace it.'
+    slot: slot-097
+    section: para-201
+    variants:
+      - id: plsat-097b
+        scenario: 'A team is setting up Paradigm on a Flutter mobile app. They run `paradigm init` and see `discipline: mobile` with `stack: flutter`. They want to see what other stack presets are available for mobile projects.'
+        question: Which command shows available stack presets filtered by discipline?
+        choices:
+          A: '`paradigm disciplines --list`'
+          B: '`paradigm presets --discipline mobile`'
+          C: '`paradigm init --show-stacks`'
+          D: '`paradigm config --list-presets`'
+          E: '`paradigm scan --detect-stack`'
+        correct: B
+        explanation: The `paradigm presets` command lists all available stack presets. The `--discipline` flag filters to show only presets for a specific discipline. For mobile, this would show flutter, swift-ios, kotlin-android, and react-native presets.
+  - id: plsat-098
+    scenario: You join a large existing project with 200+ source files and no Paradigm setup. Running `paradigm init` creates the `.paradigm/` directory, but no `.purpose` files exist yet. A colleague suggests running `paradigm scan auto` to bootstrap the project.
+    question: What does `paradigm scan auto` do?
+    choices:
+      A: It reads all source files line-by-line and creates comprehensive documentation for every function
+      B: It uses regex-based heuristics to detect components, routes, auth patterns, and signals in your codebase, then generates draft `.purpose` files with detected symbols
+      C: It copies `.purpose` templates from a global registry and places them in every directory
+      D: It connects to an AI service to analyze your code and generate documentation
+      E: It deletes all existing `.purpose` files and starts fresh
+    correct: B
+    explanation: paradigm scan auto uses pattern-based detection to find components (exported classes/functions), routes (HTTP method patterns like app.get/router.post), auth patterns (JWT, session checks, middleware), and signals (event emitters). It produces draft .purpose files with detected symbols and confidence levels. The detection is local and regex-based — it does not call external services or read every line. Stack presets enhance the scan with framework-specific patterns.
+    slot: slot-098
+    section: para-301
+    variants:
+      - id: plsat-098b
+        scenario: 'After running `paradigm scan auto` on a FastAPI project, the auto-scan detects several route handlers in `src/routes/users.py` and marks them with `confidence: high`. It also finds some utility functions and marks them `confidence: medium`.'
+        question: What do the confidence levels on auto-detected symbols indicate?
+        choices:
+          A: How important the symbol is to the project — high means critical, medium means optional
+          B: How certain the scanner is that the detected pattern actually represents that symbol type — high means strong pattern match, medium means heuristic match
+          C: How many lines of code the detected symbol contains — more lines means higher confidence
+          D: How recently the file was modified — recently modified files get higher confidence
+          E: How many other symbols reference this one — more references means higher confidence
+        correct: B
+        explanation: Confidence levels reflect the scanner's certainty about the detection. A route handler matching `@app.get('/users')` is a strong, unambiguous pattern match (high confidence). A utility function detected from an exported function that doesn't match any specific pattern is a heuristic match (medium confidence). Low confidence detections are more speculative. Users should review auto-generated .purpose files, especially medium and low confidence entries.
+  - id: plsat-099
+    scenario: A developer is tasked with adding Paradigm to a mature React Native project that has been in development for two years. The project has 150+ components, navigation stacks, Redux state management, and several API integration files. The developer is worried about the setup effort.
+    question: What is the recommended approach for adding Paradigm to a large existing project?
+    choices:
+      A: Document every single component on day one — comprehensive coverage is required before Paradigm is useful
+      B: Start with `paradigm init` (which auto-detects discipline and stack), then create one `.purpose` file for the most critical module, and expand incrementally
+      C: Rewrite the project structure to match Paradigm's expected directory layout
+      D: Wait until starting a new project — Paradigm cannot be added to existing codebases
+      E: Run `paradigm scan auto` and commit all generated files without review
+    correct: B
+    explanation: Paradigm is designed for incremental adoption. Start with `paradigm init` which auto-detects your discipline (mobile) and stack preset (react-native), configuring symbol mappings and scan patterns for your framework. Then create one .purpose file for your most important module. You can optionally run `paradigm scan auto` to bootstrap additional .purpose files, but always review auto-generated content. A common pitfall is trying to document everything on day one — start small and expand as the project grows.
+    slot: slot-099
+    section: para-101
+    variants:
+      - id: plsat-099b
+        scenario: 'A team runs `paradigm init` on their Django project. The init command auto-detects `discipline: fullstack` and `stack: django`. The team then runs `paradigm scan auto` which generates draft `.purpose` files for `views/`, `models/`, and `urls/` directories.'
+        question: Why did the auto-scan know to look in `views/`, `models/`, and `urls/` directories?
+        choices:
+          A: These are hardcoded directories that every Paradigm scan checks regardless of discipline
+          B: The django stack preset provides scan hints with Django-specific component patterns, route patterns, and directory structures
+          C: The scan randomly explores all directories and happened to find code there
+          D: The team manually configured these directories in config.yaml before scanning
+          E: Django is a special case with its own dedicated scanner module in Paradigm
+        correct: B
+        explanation: 'Stack presets include scan hints — framework-specific patterns that tell the auto-scanner where to look and what patterns to match. The django preset knows that views.py files contain route handlers, models.py files contain data models, and urls.py files define URL routing. This is why stack presets solve the cold-start problem: they bring framework knowledge that makes auto-scanning productive for existing projects.'
+  - id: plsat-100
+    scenario: 'Your project has a `#PaymentService` that coordinates payment processing and integrates with Stripe. A new developer asks whether they should use `type: integration` or `tags: [integration]` to capture the Stripe relationship.'
+    question: What is the correct approach?
+    choices:
+      A: '`type: integration` — because the Stripe integration is the most important thing about this component'
+      B: '`type: service` with `tags: [integration]` — type describes structural role, tags describe domain/behavior'
+      C: 'Both `type: integration` and `tags: [integration]` — redundancy is good for search'
+      D: Neither — integration is a v1 concept replaced by `&` prefix in v2
+      E: '`type: stripe` — use the specific integration name as the type'
+    correct: B
+    explanation: 'The `type` field describes a component''s structural role — what the code IS architecturally. PaymentService is a service, so `type: service`. The Stripe integration is a behavioral/domain concern, captured with `tags: [integration]`. Type and tags serve different classification axes: type = architecture, tags = domain.'
+    slot: slot-100
+    section: para-101
+    variants:
+      - id: plsat-100b
+        scenario: 'A developer adds a new `#EmailValidator` utility and sets `type: validator` in the .purpose file. Another developer points out that `validator` is not in the project''s `component_types` glossary in config.yaml.'
+        question: 'Is `type: validator` valid?'
+        choices:
+          A: No — types must exactly match the glossary entries or they are rejected
+          B: Yes — types are open strings and the glossary is descriptive only, not enforced
+          C: No — you must add it to the glossary first before using it
+          D: Yes — but only if the developer also adds a `~validator` aspect
+          E: It depends on the `strict-types` setting in config.yaml
+        correct: B
+        explanation: 'Component types are open strings — any project can invent its own vocabulary. The glossary in config.yaml is descriptive only (it helps agents understand types) but does not enforce or block unknown types. The developer can use `type: validator` freely.'
+  - id: plsat-101
+    scenario: You have a `#GazeRouter` component that maps gaze coordinates to dispatch targets. It is managed by `#InputOrchestrator`. You want to express this hierarchy in the .purpose file.
+    question: How should the parent relationship be declared?
+    choices:
+      A: 'On `#InputOrchestrator` with `children: ["#GazeRouter"]`'
+      B: 'On `#GazeRouter` with `parent: "#InputOrchestrator"`'
+      C: In a separate `relationships` section at the top of the .purpose file
+      D: In portal.yaml alongside route gates
+      E: 'Using `tags: [child-of-InputOrchestrator]` on GazeRouter'
+    correct: B
+    explanation: Parent relationships are declared on the child component using the `parent` field with a `#` symbol reference. This keeps .purpose files decentralized — you don't need to maintain a children roster on the parent. The parent field is computed upward, not maintained downward.
+    slot: slot-101
+    section: para-101
+  - id: plsat-102
+    scenario: An AI agent needs to find all router components in a project to understand the dispatch architecture. The project uses component types consistently.
+    question: What is the most efficient MCP tool call?
+    choices:
+      A: '`paradigm_search` with `query: "router"` — search by name'
+      B: '`paradigm_search` with `query: "*"` and `componentType: "router"` — filter by type'
+      C: '`paradigm_navigate` with `intent: "find"` and `target: "router"` — navigate to routers'
+      D: '`paradigm_ripple` with `symbol: "#router"` — check router dependencies'
+      E: 'Read every .purpose file and grep for `type: router`'
+    correct: B
+    explanation: 'The `paradigm_search` tool accepts a `componentType` filter that directly queries the symbol index for components of a specific type. This is the most efficient approach — it uses the index instead of reading files, and returns exactly the components with `type: router`.'
+    slot: slot-102
+    section: para-101
+  - id: plsat-103
+    scenario: 'Your team is evaluating Symphony''s The Score for inter-agent communication. A team member asks: ''Does The Score require a central server or WebSocket connection to route messages between agents on the same machine?'''
+    question: How does The Score route messages between agents on a single machine?
+    choices:
+      A: Through a persistent WebSocket connection managed by Sentinel's event hub
+      B: Through a central message broker that must be started with `paradigm symphony serve`
+      C: Through file-based mailboxes — agents write to JSONL files in `~/.paradigm/score/agents/` and poll for new messages via `/loop`
+      D: Through Conductor's native IPC channel between Swift and Node.js processes
+      E: Through a shared SQLite database at `~/.paradigm/score/messages.db`
+    correct: C
+    explanation: The Score is file-based with zero daemon dependencies. Each agent has a mailbox directory containing inbox.jsonl and outbox.jsonl. Messages are appended as single JSON lines. Agents poll for new messages using `/loop 10s paradigm_symphony_poll`. No WebSocket, no broker, no Conductor required — just filesystem reads and writes.
+    slot: slot-103
+    section: para-501
+    variants:
+      - id: plsat-103b
+        scenario: A developer is comparing Symphony The Score to traditional inter-process communication. They note that The Score uses JSONL files for message passing instead of sockets, pipes, or shared memory.
+        question: Why does The Score use JSONL files instead of a real-time transport like WebSockets?
+        choices:
+          A: JSONL is faster than WebSockets for small messages under 1KB
+          B: File-based messaging requires zero dependencies beyond the Paradigm CLI — no Conductor, no Sentinel, no persistent server process
+          C: Claude Code sessions cannot open network connections, so files are the only option
+          D: JSONL files provide built-in encryption that WebSockets lack
+          E: File-based messaging is required by macOS sandboxing rules for CLI tools
+        correct: B
+        explanation: The Score's design goal is zero-dependency messaging. It works with nothing beyond the Paradigm CLI — no Conductor, no Sentinel, no network configuration. File-based JSONL is append-only (safe for concurrent writes), trivial to parse, and works on every OS without additional runtime dependencies. Later phases (Conductor, Sentinel) add richer transports, but The Score is the foundation that always works.
+  - id: plsat-104
+    scenario: 'You have two Claude Code sessions open: one working on `a-paradigm` in the core library role, and another working on `a-paradigm` in the backend role. After running `paradigm symphony join`, each session gets an identity.'
+    question: How are agent identities determined in The Score?
+    choices:
+      A: Random UUIDs assigned at session start — different every time
+      B: The process ID (PID) of the Claude Code session is used as the identity
+      C: Derived from project directory + role (e.g., `a-paradigm/core`) — deterministic and stable across session restarts for the same project context
+      D: The user's GitHub username combined with a session counter
+      E: 'Assigned sequentially by the mail router: agent-001, agent-002, etc.'
+    correct: C
+    explanation: 'Agent identity in The Score is deterministic: `{project-name}/{role}`. The same project opened in the same context always gets the same identity, even across session restarts. This stability means other agents can reliably address messages to `a-paradigm/backend` knowing it will reach the backend agent regardless of which specific Claude Code session is running. PID maps to identity via identity.json but is not the identity itself.'
+    slot: slot-104
+    section: para-501
+    variants:
+      - id: plsat-104b
+        scenario: 'After running `paradigm symphony whoami`, an agent sees: `agent-abc123 (a-paradigm/backend) — 3 linked peers, 2 active threads`. The agent then crashes and a new Claude Code session is started for the same project directory with the same working context.'
+        question: What happens to the agent's identity after the restart?
+        choices:
+          A: A new random identity is assigned — the old one is permanently lost
+          B: The identity `a-paradigm/backend` is restored because it is derived from the project directory and role, not the PID
+          C: The identity is lost unless the agent calls `paradigm symphony recover` within 5 minutes
+          D: The new session gets a different identity with a `-2` suffix to avoid conflicts
+          E: The old session's mailbox is deleted and a fresh one is created with a new ID
+        correct: B
+        explanation: Agent identity is derived from project directory + role, not from PID or session-specific state. When a new session starts for the same project context, it gets the same deterministic identity. The PID-to-identity mapping in identity.json is updated, but the mailbox (inbox.jsonl, outbox.jsonl) persists. Unread messages from before the crash are still in the inbox waiting for the next poll.
+  - id: plsat-105
+    scenario: An agent investigating a production bug sends a Symphony message to the frontend agent. The agent wants to indicate that it is asking a question and expects information in response, not just acknowledgment.
+    question: Which message intent should the agent use?
+    choices:
+      A: '`context` — because the agent is seeking contextual information'
+      B: '`clarification` — because the agent wants details clarified'
+      C: '`question` — because the agent is asking for information and the intent classifies the message''s purpose for structured processing'
+      D: '`reference` — because the agent wants the frontend agent to reference its recent changes'
+      E: '`alert` — because the production bug is urgent'
+    correct: C
+    explanation: Message intents classify the purpose of a message. `question` signals that the sender is asking for information and expects a substantive response. `context` is for providing background (not requesting it). `clarification` is for asking about something already said. `alert` is specifically for forwarding Sentinel alerts. Intents help the receiving agent understand what kind of response is expected.
+    slot: slot-105
+    section: para-501
+    variants:
+      - id: plsat-105b
+        scenario: 'During a Symphony conversation thread, Agent A proposes a fix: ''Make the currency field optional with a default of USD.'' Agent B agrees and wants to record this as a team decision that will be captured in Lore.'
+        question: What intent should Agent B use when confirming the decision?
+        choices:
+          A: '`approval` — to approve Agent A''s proposal'
+          B: '`decision` — to formally record the choice, triggering automatic Lore entry creation'
+          C: '`action` — to announce it will implement the fix'
+          D: '`verification` — to verify understanding of the proposal'
+          E: '`context` — to provide context that it agrees'
+        correct: B
+        explanation: 'The `decision` intent serves a dual purpose: it communicates agreement within the conversation AND triggers automatic Lore integration. Symphony auto-records messages with `intent: decision` as lore entries of type `decision`, linking them to the thread and referenced symbols. Using `approval` (A) would confirm the proposal but would not trigger the Lore recording side effect.'
+  - id: plsat-106
+    scenario: 'Agent A on your machine needs `src/config/database.ts` from Agent B on a teammate''s machine. Agent A calls `paradigm_symphony_request_file` with the file path and reason. The teammate''s trust.yaml has `neverApprove: [".env*", "**/*.key"]` but no entry for `.ts` files.'
+    question: What happens next in the file transfer pipeline?
+    choices:
+      A: The file is automatically sent because `.ts` files are not in the neverApprove list
+      B: The request is queued and the teammate (human) receives a prompt to approve, deny, or approve with redaction — human approval is required for every file transfer
+      C: Agent B automatically reads and sends the file since both agents are in the same Symphony network
+      D: The request is denied because `database.ts` might contain database credentials
+      E: The file is sent after a 5-minute delay to give the human time to intervene
+    correct: B
+    explanation: 'Every file transfer requires explicit human approval regardless of trust configuration. The neverApprove list adds hard denials (even if the human clicks approve), but not being on the neverApprove list does not mean auto-approval. The teammate sees a prompt with the file path, the requesting agent, and the reason, then chooses: approve, deny, or approve with redaction.'
+    slot: slot-106
+    section: para-501
+    variants:
+      - id: plsat-106b
+        scenario: 'A developer sees a file request in their terminal via `paradigm symphony requests`: Agent C is requesting `.env.production` from their project. The developer''s trust.yaml includes `neverApprove: [".env*"]`. The developer runs `paradigm symphony approve req-xyz` anyway.'
+        question: What happens when the developer tries to approve a file on the neverApprove list?
+        choices:
+          A: The approval succeeds — human override always takes priority over trust configuration
+          B: The approval is rejected by the system — files matching neverApprove patterns are always denied, even if the human explicitly approves
+          C: The file is sent but with all values redacted automatically
+          D: The developer is prompted a second time to confirm the override
+          E: The approval is queued for review by a second team member
+        correct: B
+        explanation: The neverApprove list is enforced absolutely by the system. Files matching patterns like `.env*`, `*.key`, or `*.pem` are always denied regardless of human action. This is a security guardrail — even well-intentioned approvals cannot override it. The developer would need to modify trust.yaml to remove the pattern before the file could be approved.
+  - id: plsat-107
+    scenario: 'A thread about migrating to a new API version has been active for 30 minutes. Four agents and two humans participated. The team agreed on an approach: skip the database migration and hotfix the serializer. Someone runs `paradigm symphony resolve thr-abc`.'
+    question: What does thread resolution produce?
+    choices:
+      A: A git commit with the conversation as the commit message
+      B: A comprehensive lore entry capturing the topic, participants, decisions made, actions taken, and symbols discussed — bridging ephemeral conversation to permanent project memory
+      C: A .purpose file update adding the thread as a new component
+      D: A Sentinel incident record linking the conversation to a production error
+      E: An email summary sent to all team members who were not in the thread
+    correct: B
+    explanation: 'Thread resolution creates a lore entry that captures the entire collaborative context: the conversation topic, all participants (agents and humans), decisions made during the discussion, actions taken, and Paradigm symbols referenced. This bridges the gap between ephemeral real-time conversation and permanent project memory. Future developers can find and learn from the discussion via `paradigm_lore_search`.'
+    slot: slot-107
+    section: para-501
+    variants:
+      - id: plsat-107b
+        scenario: An agent resolves a thread with `paradigm symphony resolve thr-def`. The thread contained 12 messages, 3 decisions, and referenced symbols `#payment-serializer`, `#api-types`, and `$refund-flow`. A week later, a new developer encounters a similar serialization issue.
+        question: How can the new developer find the resolved thread's knowledge?
+        choices:
+          A: Search `~/.paradigm/score/threads/` for the thread JSON file — resolved threads are kept permanently
+          B: 'Call `paradigm_lore_search` with `symbol: ''#payment-serializer''` — the resolved thread became a lore entry linked to the discussed symbols'
+          C: Call `paradigm_symphony_thread` with the old thread ID — resolved threads remain in the Symphony network
+          D: Check git log for the conversation — resolved threads are saved as commit messages
+          E: The knowledge is lost — resolved threads are deleted from the filesystem
+        correct: B
+        explanation: 'When a thread is resolved, it becomes a lore entry tagged with the symbols discussed in the conversation. The new developer searching for `#payment-serializer` via `paradigm_lore_search` will find the entry, which contains the full conversation context, decisions, and actions. This is the core value of thread resolution: converting temporary discussion into searchable, permanent project memory.'
+  - id: plsat-108
+    scenario: 'You have set up The Score with 3 linked agents. Each agent has a mailbox, but none of them are running `/loop`. You send a message via `paradigm symphony send "Check the failing test in #auth-service"`. The message is written to each agent''s inbox.jsonl.'
+    question: When will the agents see and respond to this message?
+    choices:
+      A: Immediately — messages trigger an interrupt in the Claude Code session
+      B: Never — without `/loop`, agents have no mechanism to poll their inbox and will not discover the message
+      C: Within 30 seconds — the MCP tool cache automatically polls inboxes
+      D: On the next `paradigm_status` call — status checks include inbox polling
+      E: When the agent explicitly calls `paradigm symphony read` from its session
+    correct: B
+    explanation: '`/loop` is the agent heartbeat. It runs `paradigm_symphony_poll` on a timer (typically every 10 seconds), which reads inbox.jsonl and presents messages to the agent. Without `/loop`, messages accumulate in the inbox with nobody reading them. The convenience command `paradigm symphony join` sets up both identity registration and the polling loop in one step. This is why the setup instructions always include `/loop 10s paradigm_symphony_poll` in each session.'
+    slot: slot-108
+    section: para-501
+    variants:
+      - id: plsat-108b
+        scenario: 'An agent is running `/loop 10s paradigm_symphony_poll`. During one poll cycle, the tool returns 2 new messages: a question from the frontend agent and a decision message from a human. The agent processes both and sends replies via `paradigm_symphony_send`.'
+        question: Where do the agent's replies go, and how are they delivered to the recipients?
+        choices:
+          A: Directly into each recipient's inbox.jsonl — the send tool writes to all inboxes simultaneously
+          B: To this agent's outbox.jsonl — a mail router (or Conductor) picks up outbox messages and delivers them to the appropriate recipient inboxes
+          C: To a central message queue at `~/.paradigm/score/queue.jsonl` that all agents read from
+          D: Over a WebSocket connection to each recipient's MCP server
+          E: To Sentinel's event hub, which broadcasts to all connected agents
+        correct: B
+        explanation: The agent writes replies to its own outbox.jsonl via `paradigm_symphony_send`. A mail router process (in The Score's Phase 0 implementation) or Conductor (in later phases) reads outbox files and delivers messages to the correct recipient inbox files. This separation of write (outbox) and delivery (router) keeps the protocol simple — agents only ever write to their own outbox and read from their own inbox.
+  - id: plsat-109
+    scenario: A developer is using `paradigm serve` to run the Platform. Their AI agent is helping refactor `#payment-service`. The agent wants to walk the developer through three related components on the Graph canvas, but the developer is currently reading a lore entry.
+    question: What sequence of MCP tool calls should the agent use to present its walkthrough without disrupting the developer?
+    choices:
+      A: Call `paradigm_platform_navigate` three times rapidly for each component — the browser handles queuing
+      B: Call `paradigm_platform_observe` first to check if the user is active, then `paradigm_platform_annotate` with a toast saying 'I'd like to show you something on the Graph', then navigate after the user responds
+      C: Call `paradigm_platform_highlight` on all three symbols simultaneously — highlights work across all sections
+      D: Write to the Symphony mailbox and wait for the developer to read the message
+      E: Call `paradigm_platform_clear` first, then force-navigate to each component
+    correct: B
+    explanation: The agent should first observe the user's state to understand context (are they busy? what section? muted?). Since the user is actively reading lore, the agent should use a toast annotation to signal intent rather than auto-navigating. When the user is active (<5s since last interaction), navigate commands show a prompt rather than auto-executing — but checking observe first lets the agent tailor its approach.
+    slot: slot-109
+    section: para-501
+    variants:
+      - id: plsat-109b
+        scenario: 'An AI agent calls `paradigm_platform_highlight({ symbols: [''#api-gateway'', ''#auth-middleware'', ''#rate-limiter''], label: ''Security surface'', duration: 8000, pulse: true })` on the Platform. The developer sees three nodes glowing on the Graph canvas.'
+        question: What happens to the highlights after 8 seconds?
+        choices:
+          A: They remain until the developer clicks on one of the nodes
+          B: They fade out automatically — the duration parameter sets auto-expiry on both server (UserStateTracker) and browser (agentStore)
+          C: 'They persist until the agent calls `paradigm_platform_clear({ target: ''highlights'' })`'
+          D: They remain but the pulse animation stops
+          E: The Platform server removes them but the browser keeps a static glow
+        correct: B
+        explanation: The duration parameter controls auto-expiry. On the server, UserStateTracker schedules removal after the specified milliseconds. On the browser, agentStore sets a setTimeout that filters out the highlight after duration expires. Both sides independently clean up, so even if a message is lost, the highlight eventually disappears.
+  - id: plsat-110
+    scenario: The Platform server starts with `paradigm serve`. Two browser tabs are open. An MCP tool sends an `agent:annotate` command with type `callout` targeting `#database-pool`.
+    question: How does the annotation reach both browser tabs?
+    choices:
+      A: The MCP tool sends the command directly to each tab via separate HTTP requests
+      B: The Platform server stores the annotation in scan-index.json and both tabs poll for changes
+      C: The MCP tool POSTs to /api/platform/agent-command, the server broadcasts a WebSocket message to all connected clients in the wsClients Set — both tabs receive it
+      D: Only the active tab receives the annotation; the other tab receives it on focus
+      E: The annotation is stored in localStorage, which is shared between tabs
+    correct: C
+    explanation: The Platform server maintains a Set<WebSocket> of all connected browser clients. When the agent command route receives a POST, it broadcasts the typed message (agent:annotate) to every client with readyState === OPEN. Both tabs have independent WebSocket connections to ws://localhost:3850/ws, so both receive the broadcast simultaneously.
+    slot: slot-110
+    section: para-501
+    variants:
+      - id: plsat-110b
+        scenario: A developer opens the Platform at localhost:3850 and navigates to the Graph section. They select `#payment-service`. The Platform server's UserStateTracker records this activity. Ten seconds later, the AI agent calls `paradigm_platform_observe()`.
+        question: What information does the observe tool return?
+        choices:
+          A: 'Only whether the Platform is running — `{ connected: true }`'
+          B: The section, selected symbol, theme, mute state, connected agents, browser client count, and optionally active highlights/annotations
+          C: The full DOM tree of the Platform UI for the agent to parse
+          D: A diff of everything that changed since the agent's last observe call
+          E: Only the section name and selected symbol — no agent or highlight info
+        correct: B
+        explanation: 'paradigm_platform_observe returns the full UI state from the UserStateTracker: connected (boolean), users (client count), agents (array of AgentPresence with agentId, color, timestamps), and state (section, selectedSymbol, theme, muted). With detail: ''full'', it also includes active highlights and annotations. This gives the agent a complete picture of the shared workspace.'
+  - id: plsat-111
+    scenario: An agent connected to the Platform has been idle for 3 minutes. No MCP tool calls have been made. The AgentPresenceManager runs its periodic cleanup.
+    question: What happens to the agent's presence?
+    choices:
+      A: Nothing — agents are only removed when they explicitly disconnect
+      B: The agent is marked as 'idle' but remains in the agents list with a dimmed indicator
+      C: The agent is pruned from the presence list and an `agent:leave` message is broadcast to all browsers, removing the presence dot from the header
+      D: The server sends a ping to the agent and waits for a response before deciding
+      E: The agent's highlights and annotations are cleared but its presence remains
+    correct: C
+    explanation: The AgentPresenceManager runs pruneStale() every 30 seconds. Any agent whose lastActivity timestamp is more than 2 minutes old is removed from the agents Map and an agent:leave message is broadcast to all browser clients. The browser's agentStore filters out the agent, and the header presence dots update. This prevents ghost agents from accumulating.
+    slot: slot-111
+    section: para-501
+  - id: plsat-112
+    scenario: You're building a new Platform section that should respond to agent highlight commands. The existing sections (Graph, Lore, Overview) already work with the agent-driven UI system.
+    question: Which browser-side component is responsible for receiving WebSocket agent messages and updating the Zustand store?
+    choices:
+      A: platformStore.ts — all state flows through the main platform store
+      B: useActivityReporter — it handles all WebSocket communication bidirectionally
+      C: useAgentEffects — it connects WebSocket `agent:*` messages to agentStore.handleAgentMessage, with auto-reconnect on disconnect
+      D: AgentToast — it listens for WebSocket messages and renders toasts
+      E: The Platform server pushes state updates directly into the browser's agentStore via a shared reference
+    correct: C
+    explanation: useAgentEffects is the WebSocket→store bridge. It establishes a WebSocket connection to ws://localhost:{port}/ws, listens for messages whose type starts with 'agent:', and dispatches them to agentStore.handleAgentMessage. It also handles auto-reconnect (3s delay on close). useActivityReporter (B) handles the opposite direction — reporting user actions TO the server. AgentToast (D) only renders; it reads from the store but doesn't handle WebSocket.
+    slot: slot-112
+    section: para-501
+  - id: plsat-113
+    scenario: A builder agent finishes implementing a new REST endpoint. It modified 4 files, resolved 1 blocker, and the tests pass. The agent needs to record this somewhere in the knowledge streams.
+    question: Which knowledge stream is the correct destination for this entry?
+    choices:
+      A: Learning Journal — the agent learned how to build the endpoint
+      B: Team Decision — the team decided to add an endpoint
+      C: Work Log — it records what got done, files modified, outcome, and next steps
+      D: Event Stream — it is an event that happened during work
+      E: Lore — all project history goes into lore entries
+    correct: C
+    explanation: The Work Log stream answers 'what got done.' It captures the agent, summary, files_modified, symbols_touched, outcome (pass/fail/partial/blocked), and next_steps. It is project-scoped and ephemeral — designed for sprint boards and standup summaries. The Learning Journal is for personal insights the agent gains, not task completion. Team Decisions record rationale and alternatives for institutional choices.
+    slot: slot-113
+    section: para-601
+    variants:
+      - id: plsat-113b
+        scenario: An agent spent 45 minutes debugging a flaky test in the CI pipeline. It turned out to be a race condition in the database setup. The agent fixed it, and the test suite passes now. The agent wants to log this work.
+        question: Which knowledge stream should this entry go into?
+        choices:
+          A: Team Decision — the team needs to know about flaky tests
+          B: Work Log — it captures what was done, duration, outcome, and what was fixed
+          C: Learning Journal — the agent discovered a race condition pattern
+          D: Event Stream — file-modified events are emitted automatically
+          E: Both Work Log and Learning Journal equally — there is no distinction
+        correct: B
+        explanation: The Work Log is the correct primary destination — it records what got done (fixed flaky test), the outcome (pass), duration (45 min), and files modified. The agent might also record a Learning Journal entry about the race condition pattern it discovered, but the work itself belongs in the Work Log. These are separate entries in separate streams — the journal entry would link back to the work log via linked_work_log.
+  - id: plsat-114
+    scenario: During a code review, the architect agent points out that the builder's approach to token refresh will cause a race condition under concurrent requests. The builder realizes its mental model of the refresh flow was wrong and adjusts its confidence from 0.8 to 0.5 on `#token-refresh`.
+    question: Which knowledge stream captures this learning moment?
+    choices:
+      A: Work Log — the builder did work (reviewed code)
+      B: Team Decision — the team decided to change the approach
+      C: Learning Journal — the builder received a correction and adjusted its confidence, which is a personal learning event
+      D: Event Stream — the correction is a 'compliance-violation' event
+      E: Work Log with outcome 'fail' — the original approach failed review
+    correct: C
+    explanation: The Learning Journal captures 'what I learned.' The trigger is 'correction_received', the insight is the corrected mental model, confidence_before is 0.8, confidence_after is 0.5, and the entry is agent-private (stored in ~/.paradigm/agents/{id}/journal/). It may or may not be transferable to other projects. The Work Log would separately record the review activity, but the learning itself belongs in the journal.
+    slot: slot-114
+    section: para-601
+    variants:
+      - id: plsat-114b
+        scenario: A security agent reviewed an authentication module and predicted with 0.9 confidence that the session handling was secure. A penetration test later revealed a session fixation vulnerability. The security agent needs to record this calibration miss.
+        question: Which knowledge stream is appropriate for this entry?
+        choices:
+          A: Team Decision — the team needs to decide how to fix the vulnerability
+          B: Work Log — the penetration test results are work output
+          C: Event Stream — emit an 'error-encountered' event
+          D: Learning Journal — the agent had a confidence miss and needs to record the corrected understanding
+          E: Both Work Log and Team Decision — the journal is only for minor insights
+        correct: D
+        explanation: 'The Learning Journal is the right stream for calibration misses. The trigger is ''confidence_miss'', with confidence_before: 0.9 and confidence_after adjusted downward. The journal is agent-private, stored in ~/.paradigm/agents/{id}/journal/, and travels with the agent across projects if marked transferable. A separate Team Decision might record the fix approach, but the personal calibration adjustment belongs in the journal.'
+  - id: plsat-115
+    scenario: The team holds a design discussion about whether to use WebSockets or Server-Sent Events for real-time updates. The architect proposes WebSockets, the builder supports it, and the reviewer dissents (preferring SSE for simplicity). They go with WebSockets. The rationale and alternatives need to be preserved.
+    question: Which knowledge stream captures this?
+    choices:
+      A: Work Log — a design discussion is work
+      B: Learning Journal — everyone learned something from the debate
+      C: Team Decision — it records the choice, rationale, participants with stances, and alternatives considered
+      D: Event Stream — emit a 'decision-made' event and the stream captures it
+      E: Lore entry of type 'human-note' — a human-authored design choice belongs in the timeline
+    correct: C
+    explanation: 'Team Decisions capture institutional memory: the title, decision text, rationale, participants (with stances like ''proposed'', ''supported'', ''dissented''), alternatives_considered (with rejected_because), and affected symbols. They are project-scoped and long-lived (status: active/superseded/deprecated). The event stream might emit a ''decision-made'' event, but that is a notification — the decision record itself lives in the Team Decisions stream at .paradigm/decisions/. Note that "Team Decision" here refers to the *decisions stream* — distinct from the v5-era `decision` lore type, which was removed in v6.0. The decisions stream is fed by `paradigm_decision_record` and emits a companion lore `insight` entry to the journal stream for timeline coverage.'
+    slot: slot-115
+    section: para-601
+    variants:
+      - id: plsat-115b
+        scenario: After a production incident, the team decides to add rate limiting to all public API endpoints. The security agent proposed it, the architect supported it, and the builder abstained. They considered IP-based limiting vs token-bucket and chose token-bucket. This needs to be recorded for future reference.
+        question: Which knowledge stream should hold this record?
+        choices:
+          A: Work Log — an incident response is work that was done
+          B: Team Decision — it preserves the choice, who participated, their stances, and why token-bucket was chosen over IP-based
+          C: Learning Journal — the team learned from the incident
+          D: All three streams equally — incidents generate entries everywhere
+          E: Event Stream — the decision is an event type 'decision-made'
+        correct: B
+        explanation: 'Team Decisions are the institutional record for choices like this. The entry includes participants (security: proposed, architect: supported, builder: abstained), alternatives_considered (IP-based: rejected because it fails behind proxies), symbols_affected (#rate-limiter, #api-gateway), and status: active. The incident itself might generate work log entries and journal entries, but the decision about the approach belongs in the Team Decisions stream.'
+  - id: plsat-116
+    scenario: 'A security agent has attention patterns configured as: symbols: [''^*'', ''#*-auth'', ''#*-middleware''], paths: [''auth/**'', ''middleware/**''], concepts: [''permission'', ''JWT'', ''RBAC''], signals: [{ type: ''gate-added'' }, { type: ''route-created'' }], threshold: 0.4. A new event arrives: type: ''file-modified'', path: ''src/utils/date-formatter.ts'', symbols: [''#date-formatter''], keywords: [''formatting'', ''locale''].'
+    question: Will the security agent self-nominate for this event?
+    choices:
+      A: Yes — the agent's threshold is low (0.4), so it nominates for most events
+      B: No — the symbol '#date-formatter' does not match '^*', '#*-auth', or '#*-middleware'; the path 'src/utils/' does not match 'auth/**' or 'middleware/**'; the keywords have no concept overlap; and no signal matches. All four scores are 0, which is below 0.4
+      C: Yes — '#date-formatter' matches '#*' because * is a wildcard for any suffix
+      D: No — the agent only responds to signals, not file modifications
+      E: Yes — every agent nominates for every event to ensure nothing is missed
+    correct: B
+    explanation: 'Attention scoring evaluates four dimensions: symbolMatch (does ''#date-formatter'' match ''^*'', ''#*-auth'', or ''#*-middleware''? No — it would need to end with ''-auth'' or ''-middleware''), pathMatch (''src/utils/date-formatter.ts'' doesn''t match ''auth/**'' or ''middleware/**''), conceptMatch (no overlap between [''formatting'', ''locale''] and [''permission'', ''JWT'', ''RBAC'']), and signalMatch (event type ''file-modified'' is not ''gate-added'' or ''route-created''). The final score is max(0, 0, 0, 0) = 0, which is below the 0.4 threshold.'
+    slot: slot-116
+    section: para-601
+    variants:
+      - id: plsat-116b
+        scenario: 'A tester agent has attention patterns: paths: [''**/*.test.*'', ''**/*.spec.*''], concepts: [''test'', ''coverage'', ''assertion''], signals: [{ type: ''error-encountered'' }], threshold: 0.5. An event arrives: type: ''file-modified'', path: ''src/services/payment.ts'', symbols: [''#payment-service''], keywords: [''refactor'', ''extract method''].'
+        question: Will the tester agent self-nominate?
+        choices:
+          A: Yes — any file modification could break tests, so the tester is always relevant
+          B: Yes — the threshold of 0.5 is met because 'refactor' is similar to 'test'
+          C: No — the path does not match '**/*.test.*' or '**/*.spec.*', no concept overlap ('refactor' and 'extract method' do not match 'test', 'coverage', or 'assertion'), and the event type 'file-modified' is not 'error-encountered'. Score is 0
+          D: No — tester agents can only observe test files, not source files
+          E: Yes — '#payment-service' triggers the tester because payments need testing
+        correct: C
+        explanation: 'The tester''s attention has no symbol patterns, so symbolMatch is 0. The path ''src/services/payment.ts'' doesn''t match ''**/*.test.*'' or ''**/*.spec.*'', so pathMatch is 0. The keywords [''refactor'', ''extract method''] have no overlap with [''test'', ''coverage'', ''assertion''], so conceptMatch is 0. The event type ''file-modified'' is not ''error-encountered'', so signalMatch is 0. Final score: max(0, 0, 0, 0) = 0, below the 0.5 threshold.'
+  - id: plsat-117
+    scenario: 'An architect agent has attention: symbols: [''$*'', ''#*''], concepts: [''architecture'', ''design'', ''pattern''], threshold: 0.5. An event arrives: type: ''flow-modified'', symbols: [''$checkout-flow'', ''#cart-service''], keywords: [''added step'', ''validation''], context: ''New payment validation step added to checkout flow''.'
+    question: Will the architect self-nominate, and what is the approximate attention score?
+    choices:
+      A: No — the architect only cares about design documents, not flow changes
+      B: Yes — '$checkout-flow' matches '$*' giving symbolMatch=1.0, and the score exceeds the 0.5 threshold
+      C: Yes — but only because the keyword 'validation' triggers a concept match
+      D: No — the threshold of 0.5 requires at least two dimensions to match
+      E: Yes — every event with symbols triggers every agent that has symbol patterns
+    correct: B
+    explanation: The architect's symbol pattern '$*' matches '$checkout-flow' (any symbol starting with $), giving symbolMatch=1.0. Additionally '#*' matches '#cart-service' (already capped at 1.0). The final score is max(symbolMatch, pathMatch, conceptMatch, signalMatch) = max(1.0, 0, partial, 0) = 1.0, well above the 0.5 threshold. The agent will self-nominate. Note that conceptMatch might also contribute ('pattern' could partial-match against context), but symbolMatch alone is sufficient.
+    slot: slot-117
+    section: para-601
+    variants:
+      - id: plsat-117b
+        scenario: 'A reviewer agent has attention: concepts: [''code quality'', ''bug'', ''smell'', ''convention''], threshold: 0.6. An event arrives: type: ''error-encountered'', keywords: [''null pointer'', ''uncaught exception'', ''bug''], context: ''TypeError: Cannot read properties of undefined in auth middleware'', severity: ''error''.'
+        question: Will the reviewer self-nominate?
+        choices:
+          A: No — the reviewer has no symbol or path patterns, so it cannot score above 0
+          B: No — 'error-encountered' events are only for tester agents
+          C: Yes — the keyword 'bug' matches the concept 'bug', giving conceptMatch of at least 0.25 (1 of 4 concepts). Since max score uses the highest dimension, this gives 0.25 which is below 0.6, so actually no
+          D: Yes — 'bug' matches concept 'bug' (1/4 = 0.25 conceptMatch), but the score is max(0, 0, 0.25, 0) = 0.25, which is below the 0.6 threshold, so the agent stays quiet
+          E: Yes — the severity 'error' automatically forces all agents to nominate
+        correct: D
+        explanation: The reviewer has no symbol patterns (symbolMatch=0), no path patterns (pathMatch=0), and no signal patterns (signalMatch=0). For concepts, 'bug' matches 1 of 4 concepts, giving conceptMatch = 1/4 = 0.25. The final score is max(0, 0, 0.25, 0) = 0.25, which is below the 0.6 threshold. The agent's quietReason would be 'below-threshold'. Severity does not override the attention threshold — agents only speak when their specific attention patterns fire strongly enough.
+  - id: plsat-118
+    scenario: 'A learning journal entry contains: insight: ''When JWT tokens use RS256 with the PAYMENTS_SIGNING_KEY, rotation requires coordinating across 3 services.'' The data policy has learning_journal ring: ''user-scoped'' with redaction patterns: [{ pattern: ''\\b[A-Z_]{2,}_KEY\\b'' }, { pattern: ''password|secret|token'' }].'
+    question: Which trust ring does the learning journal belong to, and what happens to the content?
+    choices:
+      A: Ring 1 (project-locked) — journals never leave the project
+      B: Ring 2 (user-scoped) — the journal travels across the user's projects, but 'PAYMENTS_SIGNING_KEY' is redacted by the [A-Z_]{2,}_KEY pattern and 'token' is redacted by the password|secret|token pattern
+      C: Ring 3 (creator-upstream) — journal insights flow to agent creators anonymized
+      D: Ring 2 (user-scoped) — but no redaction occurs because journals are already private
+      E: Ring 4 (network-public) — aggregated learning patterns are shared publicly
+    correct: B
+    explanation: The learning journal's ring is 'user-scoped' (Ring 2), meaning it travels across the user's own projects but never beyond. The data policy's redaction patterns are applied at the 'journal-recording' enforcement boundary. The regex '\b[A-Z_]{2,}_KEY\b' matches 'PAYMENTS_SIGNING_KEY', and 'password|secret|token' matches 'token' in 'JWT tokens'. Both are redacted before storage. Trust rings are concentric — data classified as Ring 2 can be read in Ring 1 (project) and Ring 2 (user) contexts, but never reaches Ring 3 (upstream) or Ring 4 (network).
+    slot: slot-118
+    section: para-601
+    variants:
+      - id: plsat-118b
+        scenario: 'A work log entry records: summary: ''Fixed database connection pooling for the POSTGRES_SECRET_URL endpoint, updated #db-pool configuration.'' The data policy has work_log ring: ''project-locked'' with deny_content: [''code_snippets'', ''file_contents'', ''diff_content''] and no redaction patterns.'
+        question: What trust ring contains this work log, and is the content filtered?
+        choices:
+          A: Ring 1 (project-locked) — the content stays in the project; deny_content blocks code snippets but the summary text is allowed because 'file_paths' and 'symbol_names' are in allow_content
+          B: Ring 2 (user-scoped) — work logs travel with the user across projects
+          C: Ring 1 (project-locked) — but 'POSTGRES_SECRET_URL' should be redacted
+          D: Ring 1 (project-locked) — the entire entry is blocked because it mentions a secret URL
+          E: Ring 3 (creator-upstream) — work logs are feedback for agent creators
+        correct: A
+        explanation: Work logs default to Ring 1 (project-locked) — they never leave the project. The allow_content list includes 'file_paths', 'symbol_names', and 'outcome', so the summary mentioning '#db-pool' and describing the fix is fine. The deny_content blocks 'code_snippets', 'file_contents', and 'diff_content', but a summary paragraph is not a code snippet. Note that 'POSTGRES_SECRET_URL' is not redacted because the work_log stream has no redaction patterns in the default policy — it relies on project-locked ring containment instead.
+  - id: plsat-119
+    scenario: 'A project''s CLAUDE.md has grown to 850 lines. It includes: the symbol table (5 symbols), commit conventions, agent onboarding steps, a 200-line logging guide with directory mapping tables, a 150-line portal protocol specification, and 100 lines of MCP workflow details. The team wants to reduce base context cost.'
+    question: Using Paradigm's guidance resource model, what should stay inline in CLAUDE.md and what should move?
+    choices:
+      A: Everything stays in CLAUDE.md — agents need all context upfront to avoid errors
+      B: Move everything to guidance resources — CLAUDE.md should only have the project name
+      C: The symbol table, commit conventions, and agent onboarding steps stay inline (~150 lines). The logging guide, portal protocol, and MCP workflow move to on-demand guidance resources (paradigm://guidance/logging, paradigm://guidance/portal, paradigm://guidance/mcp-workflow)
+      D: Only the symbol table stays inline. Everything else, including commit conventions, moves to guidance resources
+      E: Keep the logging guide inline (agents need it every session) and move everything else to guidance
+    correct: C
+    explanation: 'Paradigm''s guidance resource model splits CLAUDE.md into two tiers: (1) always-loaded base context (~150 lines) containing the symbol system, conventions, and onboarding steps that every session needs, and (2) on-demand guidance resources loaded via MCP resource URIs only when relevant. The logging guide, portal protocol, and MCP workflow are reference material — an agent building a React component doesn''t need the portal spec. Moving them to paradigm://guidance/* reduces base context from ~850 to ~150 lines while keeping all guidance one tool call away.'
+    slot: slot-119
+    section: para-601
+    variants:
+      - id: plsat-119b
+        scenario: A developer notices that their CLAUDE.md includes a detailed multi-agent orchestration section (120 lines), a flow-first development guide (80 lines), a workspace configuration reference (60 lines), and the core symbol system with conventions (100 lines). They want to follow Paradigm's context efficiency pattern.
+        question: What is the correct split between inline CLAUDE.md and on-demand guidance?
+        choices:
+          A: Keep everything — 360 lines is acceptable for CLAUDE.md
+          B: The core symbol system and conventions stay inline. Orchestration, flow-first, and workspace references become guidance resources loaded via paradigm://guidance/orchestration, paradigm://guidance/flows, and paradigm://guidance/workspaces
+          C: Move everything to guidance resources and leave CLAUDE.md empty
+          D: Keep orchestration inline because multi-agent work is common; move only workspaces
+          E: Split each section in half — keep summaries inline, details in guidance
+        correct: B
+        explanation: 'The core symbol system (# $ ^ ! ~) and project conventions are needed in every session — they stay inline. Orchestration, flow-first development, and workspace configuration are situational: you only need orchestration when running multi-agent tasks, flows when documenting a complex process, and workspaces when working across projects. These become on-demand resources. The CLAUDE.md even includes a resource table mapping topics to URIs so agents know what is available without loading the full content.'
+  - id: plsat-120
+    scenario: 'A builder agent modifies `src/auth/jwt-verify.ts` and adds a new gate `^token-valid`. The event stream emits: type: ''gate-added'', source: ''post-write-hook'', symbols: [''^token-valid'', ''#jwt-verify''], path: ''src/auth/jwt-verify.ts'', keywords: [''JWT'', ''validation'', ''gate'', ''authentication'']. A security agent has attention: symbols: [''^*'', ''#*-auth'', ''#*-middleware''], concepts: [''permission'', ''JWT'', ''RBAC''], signals: [{ type: ''gate-added'' }], threshold: 0.4.'
+    question: What urgency level should the security agent's nomination use?
+    choices:
+      A: Low — gate additions are routine maintenance
+      B: Medium — any security-related change warrants moderate urgency
+      C: High or Critical — a new gate in the auth layer is a security-sensitive change; the agent's nomination.speak_when.urgency likely includes 'gate_missing' and 'security_risk', and the signal match on 'gate-added' directly triggers the security review pattern
+      D: The urgency is always 'medium' unless the event severity is 'critical'
+      E: No nomination — the security agent only reviews when asked directly
+    correct: C
+    explanation: 'The security agent''s attention fires on three dimensions simultaneously: symbolMatch (''^token-valid'' matches ''^*''), conceptMatch (''JWT'' and ''authentication'' match concepts), and signalMatch (''gate-added'' matches a signal). With a threshold of 0.4 and a score of 1.0, the agent clearly self-nominates. For urgency, gate additions in authentication code are security-sensitive changes — the nomination.speak_when.urgency array typically includes ''gate_missing'' and ''security_risk''. A new gate needs review to verify it is correctly implemented and not bypassed.'
+    slot: slot-120
+    section: para-601
+    variants:
+      - id: plsat-120b
+        scenario: 'A builder agent updates a CSS file: type: ''file-modified'', path: ''src/styles/button.css'', symbols: [''#button-styles''], keywords: [''padding'', ''border-radius'', ''color'']. A security agent has attention: symbols: [''^*'', ''#*-auth''], paths: [''auth/**'', ''middleware/**''], concepts: [''permission'', ''JWT''], signals: [{ type: ''gate-added'' }], threshold: 0.4.'
+        question: What happens with the security agent's nomination for this event?
+        choices:
+          A: The security agent nominates with urgency 'low' — all changes get reviewed
+          B: The security agent does not nominate — score is 0 across all dimensions (no symbol match, path is not auth/middleware, no concept overlap, no signal match), and quietReason is 'below-threshold'
+          C: The security agent nominates because the low threshold (0.4) catches most events
+          D: The security agent nominates with urgency 'medium' — CSS could affect security UI
+          E: The security agent defers — it waits to see if other agents nominate first
+        correct: B
+        explanation: 'The security agent''s attention patterns produce zero matches: ''#button-styles'' does not match ''^*'' or ''#*-auth''; ''src/styles/button.css'' does not match ''auth/**'' or ''middleware/**''; [''padding'', ''border-radius'', ''color''] have no overlap with [''permission'', ''JWT'']; and event type ''file-modified'' is not ''gate-added''. The score is max(0, 0, 0, 0) = 0, far below the 0.4 threshold. The agent stays quiet with quietReason: ''below-threshold''. A low threshold does not mean the agent nominates for everything — it means the agent is more sensitive to weak matches in its attention domain.'
+  - id: plsat-121
+    scenario: A security agent nominates with urgency 'critical' after detecting a missing gate on a payment endpoint. At the same time, a reviewer agent nominates with urgency 'low' about a variable naming convention issue in the same file. Both nominations target overlapping symbols.
+    question: How should the urgency levels affect surfacing to the human?
+    choices:
+      A: Both are shown equally — urgency is just metadata with no behavioral effect
+      B: Only the critical nomination is shown — low urgency nominations are always suppressed
+      C: The critical nomination is surfaced immediately; the low urgency nomination may be batched or deferred based on the SurfacingConfig's min_urgency setting for the reviewer agent
+      D: They are merged into a single nomination with urgency 'high' (the average)
+      E: The reviewer's nomination is upgraded to 'critical' because it touches the same symbols
+    correct: C
+    explanation: 'SurfacingConfig controls how nominations reach the human. Each agent can have a min_urgency setting — if the reviewer''s SurfacingPreference has min_urgency: ''medium'', the ''low'' urgency naming convention issue would be batched or suppressed until the human is less busy. The security agent''s ''critical'' nomination exceeds any reasonable min_urgency threshold and is surfaced immediately. Nominations are not merged or averaged — they are independent contributions that may be grouped as a ''complementary'' Debate if they touch overlapping symbols.'
+    slot: slot-121
+    section: para-601
+    variants:
+      - id: plsat-121b
+        scenario: 'An event fires: type: ''route-created'' for a new `/api/admin/users` endpoint. The security agent nominates with urgency ''high'' (missing gate review). The architect agent nominates with urgency ''medium'' (suggesting a different URL structure). The builder agent scores below threshold and stays quiet.'
+        question: What nomination urgency behavior is correct here?
+        choices:
+          A: The architect's nomination is suppressed because the security agent already nominated
+          B: 'Both nominations surface: security at ''high'' urgency (shows first) and architect at ''medium'' urgency. They may be grouped into a Debate because they target the same route symbol. The builder''s quietReason is ''below-threshold'''
+          C: All three agents must nominate — staying quiet is not an option
+          D: The urgency levels are recalculated based on the number of agents that nominate
+          E: Only the highest urgency nomination surfaces; others are queued for later
+        correct: B
+        explanation: 'Each agent independently scores the event and decides whether to nominate. The security and architect agents exceeded their thresholds and nominated with different urgency levels. Both are surfaced (high shows before medium in priority order). Because they target the same route/symbols, the system may group them as a Debate (type: ''complementary'' since they address different concerns). The builder agent scored below its threshold and stays quiet with quietReason: ''below-threshold'' — this is correct behavior, not a failure.'
+  - id: plsat-122
+    scenario: 'A project''s data policy has: upstream ring: ''creator-upstream'', allowed: [''task_type'', ''outcome'', ''helpfulness'', ''duration_bucket'', ''error_category''], denied: [''code_of_any_kind'', ''file_paths'', ''symbol_names'', ''conversation_content'', ''user_identity'']. An agent creator''s analytics dashboard requests feedback data.'
+    question: Which data reaches the agent creator?
+    choices:
+      A: Everything the agent produced — the creator needs full visibility to improve the agent
+      B: 'Only the allowed fields: task_type (''feature implementation''), outcome (''pass''), helpfulness (''high''), duration_bucket (''30-60min''), error_category (null). No code, file paths, symbol names, conversation content, or user identity is transmitted'
+      C: A summary of the agent's work log entries
+      D: Nothing — the 'denied' list overrides the 'allowed' list entirely
+      E: Only 'outcome' and 'helpfulness' — those are the minimum required fields
+    correct: B
+    explanation: 'The upstream rules at Ring 3 (creator-upstream) define exactly what flows to agent creators. The ''allowed'' list enumerates the specific fields that can be transmitted: task_type, outcome, helpfulness, duration_bucket, and error_category. The ''denied'' list explicitly blocks code_of_any_kind, file_paths, symbol_names, conversation_content, and user_identity. These two lists work together — only allowed fields pass, and denied fields are hard-blocked even if they would otherwise be inferred. The creator sees anonymized quality metrics, never the user''s actual code or identity.'
+    slot: slot-122
+    section: para-601
+    variants:
+      - id: plsat-122b
+        scenario: 'A team decision entry contains: decision: ''Use PostgreSQL with pgvector for embeddings'', rationale: ''Lower latency than Pinecone for our dataset size'', symbols_affected: [''#embedding-store'', ''#search-service'']. The data policy has team_decisions ring: ''project-locked'', deny_content: [''implementation_details'']. An agent from another user project requests this data.'
+        question: What happens when the cross-project request arrives?
+        choices:
+          A: The decision is shared — team decisions are public knowledge
+          B: Only the rationale is shared — the decision text contains implementation details
+          C: The request is blocked entirely — team decisions are in Ring 1 (project-locked), which means they never leave the project regardless of what the requesting agent needs
+          D: The decision title is shared but the rationale is redacted
+          E: The data is shared if the other project is in the same workspace
+        correct: C
+        explanation: Team decisions default to Ring 1 (project-locked). The trust ring system is the primary enforcement boundary — data classified in Ring 1 never leaves the project, period. The 'cross-project-transfer' enforcement boundary checks the ring before any content filtering. Even though the deny_content only blocks 'implementation_details', the ring restriction prevents the entire entry from being transmitted. Workspaces do not override ring restrictions — they enable symbol awareness across projects, not data sharing.
+  - id: plsat-123
+    scenario: 'The data policy''s default ring is ''project-locked''. The observation rules are: allow: [''src/**'', ''.paradigm/**'', ''portal.yaml''], deny: [''.env*'', ''**/*.key'', ''**/*.pem'', ''**/secrets/**'']. A builder agent tries to read ''.env.production'' to check a database URL.'
+    question: What happens at the observation enforcement boundary?
+    choices:
+      A: The read succeeds — '.env.production' matches 'src/**' because it starts with a dot
+      B: The read is blocked — '.env.production' matches the deny pattern '.env*', and deny overrides allow. The agent is prevented from observing the file contents
+      C: The read succeeds but the content is redacted — only the file name is returned
+      D: The read is blocked only if the file contains actual secrets; the policy checks content
+      E: The read succeeds because the default ring is 'project-locked', which means all project files are accessible
+    correct: B
+    explanation: The observation rules control what agents can see. The deny list takes precedence over the allow list — '.env.production' matches the deny glob '.env*', so the read is blocked at the 'event-emission' enforcement boundary. This is a hard deny, not a content-aware filter. The default ring being 'project-locked' means data stays within the project, but observation deny patterns prevent agents from accessing sensitive files regardless of ring level. The agent would need the deny pattern removed from the data policy to read this file.
+    slot: slot-123
+    section: para-601
+    variants:
+      - id: plsat-123b
+        scenario: 'The observation rules allow: [''src/**'', ''.paradigm/**''], deny: [''**/*.key'', ''**/*.pem'', ''**/secrets/**'']. A security agent wants to audit the file ''src/config/secrets/api-keys.json'' to check for hardcoded credentials.'
+        question: What does the data policy enforce?
+        choices:
+          A: The read is allowed — 'src/**' matches and the security agent has special override privileges
+          B: The read is allowed — 'src/config/secrets/api-keys.json' matches 'src/**' in allow
+          C: The read is blocked — 'src/config/secrets/api-keys.json' matches '**/secrets/**' in deny, which overrides the 'src/**' allow pattern
+          D: The read is partially allowed — the file name is visible but contents are redacted
+          E: The read depends on the agent's permissions.paths.read setting, not the data policy
+        correct: C
+        explanation: Deny patterns override allow patterns in observation rules. While 'src/config/secrets/api-keys.json' does match 'src/**' in the allow list, it also matches '**/secrets/**' in the deny list. The deny takes precedence. This is a deliberate security design — even well-intentioned audit access to secrets directories is blocked. If the security agent needs to verify no hardcoded secrets exist, it would need a different approach (e.g., a human-run audit) or a per-agent override in agent_overrides that explicitly allows that path.
+  - id: plsat-124
+    scenario: An event is emitted by the post-write hook after a file save. You need to understand the anatomy of the StreamEvent object.
+    question: Which fields are ALWAYS present on every StreamEvent, regardless of the event type or source?
+    choices:
+      A: id, type, source, timestamp, path, symbols, agent
+      B: id, type, source, timestamp — these four are required. Fields like path, symbols, keywords, context, agent, tool, severity, and data are all optional and depend on the event type
+      C: id, timestamp, and agent — the agent is always set because events come from agents
+      D: All fields are always present — optional fields default to empty arrays or null
+      E: type and timestamp only — the id is generated lazily when the event is queried
+    correct: B
+    explanation: 'A StreamEvent has four required fields: id (auto-generated like ''ev-1711000000000-0042''), type (an EventType like ''file-modified'', ''gate-added'', ''error-encountered''), source (an EventSource like ''post-write-hook'', ''mcp-tool-call'', ''conversation''), and timestamp (ISO 8601). All other fields are optional: path is present for file events, symbols for Paradigm-aware events, agent for agent-originated events, tool for MCP tool calls, severity for compliance/error events, and data for arbitrary structured metadata.'
+    slot: slot-124
+    section: para-601
+    variants:
+      - id: plsat-124b
+        scenario: 'You are debugging an event that arrived in the stream: { id: ''ev-1711036800000-0317'', type: ''gate-checked'', source: ''mcp-tool-call'', timestamp: ''2026-03-21T12:00:00Z'', symbols: [''^admin-only''], tool: ''paradigm_gates_for_route'', context: ''Checking gates for /api/admin/config'' }.'
+        question: Which fields on this event are the optional ones (not present on every event)?
+        choices:
+          A: All fields shown are required — this is the minimum event structure
+          B: Only 'context' is optional — everything else is always present
+          C: symbols, tool, and context are the optional fields. id, type, source, and timestamp are the four required fields present on every event
+          D: id is optional — some events are anonymous
+          E: source and tool are both optional — they are redundant
+        correct: C
+        explanation: The four required fields are id, type, source, and timestamp. In this event, symbols (['^admin-only']), tool ('paradigm_gates_for_route'), and context ('Checking gates for /api/admin/config') are all optional fields that happen to be populated. Other events might lack these — for example, a 'file-modified' event from 'post-write-hook' would have path instead of tool, and might not have symbols at all if the file is not covered by a .purpose file.
+  - id: plsat-125
+    scenario: 'A builder agent starts a new session on project ''acme-api''. You call `paradigm_context_compose` with agent: ''builder'', symbols: [''#api-gateway'', ''#rate-limiter''], include_nominations: true, include_decisions: true, include_journal: true.'
+    question: What sections does the composed context include?
+    choices:
+      A: Only the agent's profile — context compose just returns the .agent file
+      B: The full CLAUDE.md, all .purpose files, and the complete event stream
+      C: Profile enrichment (personality, relevant expertise for the given symbols, transferable patterns), recent active team decisions, transferable journal entries for this agent, and pending nominations — four distinct sections composed into a markdown block
+      D: Only nominations and decisions — the profile is loaded separately
+      E: The agent's attention patterns and learning configuration — context compose is about ambient setup
+    correct: C
+    explanation: 'paradigm_context_compose builds a session context from four sources: (1) Profile enrichment — the agent''s personality, expertise entries matching the given symbols, and transferable patterns; (2) Recent team decisions with status ''active'' (up to max_decisions, default 5); (3) Transferable journal entries for this agent (insights that apply across projects, up to max_journal, default 5); (4) Pending nominations that haven''t been surfaced yet. Each section can be toggled via include_* flags. The result is a markdown string for prompt injection, not raw data.'
+    slot: slot-125
+    section: para-601
+    variants:
+      - id: plsat-125b
+        scenario: 'A security agent calls `paradigm_context_compose` with agent: ''security'', include_decisions: true, include_journal: true, include_nominations: false, max_decisions: 3, max_journal: 10.'
+        question: What does the composed context contain?
+        choices:
+          A: All 4 sections are always included — the include_* flags are just suggestions
+          B: Profile enrichment for the security agent, up to 3 recent active team decisions, up to 10 transferable journal entries, and NO nominations section (because include_nominations is false)
+          C: Only the journal entries — security agents do not get profile enrichment
+          D: The full event stream filtered to security-relevant events
+          E: Profile, decisions, and journal — but max_journal caps at 5 regardless of the parameter
+        correct: B
+        explanation: 'The include_* flags control which sections appear in the composed context. With include_nominations: false, that section is skipped entirely. Profile enrichment is always included (it is the base). max_decisions: 3 limits team decisions to the 3 most recent active ones (instead of the default 5). max_journal: 10 allows up to 10 transferable journal entries (overriding the default 5). The result is a markdown context block with three sections: profile enrichment, decisions, and journal — ready for prompt injection.'
+  - id: plsat-126
+    scenario: 'The data policy network rules are: ring: ''network-public'', opt_in: false, if_opted_in: [''aggregated_task_success_rates'', ''anonymized_pattern_frequency'']. A network aggregation service requests data from this project.'
+    question: What data flows to the network?
+    choices:
+      A: aggregated_task_success_rates and anonymized_pattern_frequency — the if_opted_in list defines what is shared
+      B: 'Nothing — opt_in is false, so no data reaches Ring 4 (network-public) regardless of the if_opted_in list. The user must explicitly set opt_in: true before any data flows'
+      C: Only anonymized_pattern_frequency — success rates could identify the project
+      D: Aggregated statistics are always shared — opt_in only controls detailed data
+      E: The data is shared but with a 30-day delay for privacy
+    correct: B
+    explanation: 'The network rules require explicit opt-in. With opt_in: false, the ''network-aggregation'' enforcement boundary blocks ALL data from reaching Ring 4 (network-public). The if_opted_in list only takes effect when opt_in is true — it defines which specific metrics would be shared if the user chooses to participate. This is a deliberate design: no data flows to the network by default. The user must consciously enable it, and even then, only the listed metric types (aggregated task success rates and anonymized pattern frequency) are transmitted.'
+    slot: slot-126
+    section: para-601
+    variants:
+      - id: plsat-126b
+        scenario: 'An upstream rule has: ring: ''creator-upstream'', allowed: [''task_type'', ''outcome''], denied: [''code_of_any_kind'', ''file_paths'', ''symbol_names'', ''conversation_content'', ''user_identity'']. The agent generates a work log entry that mentions file paths and symbol names in the summary. This entry is allowed at Ring 1. Now the upstream boundary is checked.'
+        question: What reaches the agent creator?
+        choices:
+          A: The full work log entry — it was allowed at Ring 1 so it passes all rings
+          B: Only the task_type and outcome fields. Even though the summary mentions file paths and symbols, the upstream boundary enforces the denied list. File paths, symbol names, and any code are stripped. Only the enumerated allowed fields pass through to Ring 3
+          C: The summary with file paths and symbol names redacted inline
+          D: Nothing — the denied list cancels out the allowed list
+          E: The work log ID and timestamp only — those are always transmitted
+        correct: B
+        explanation: 'The upstream enforcement boundary operates on specific fields, not on the text content of entries. The ''allowed'' list names exactly which fields pass: task_type and outcome. The ''denied'' list provides an additional hard block on categories like file_paths, symbol_names, and code_of_any_kind. Data that was allowed at Ring 1 (project-locked) does not automatically flow to Ring 3 (creator-upstream) — each ring''s enforcement boundary re-evaluates what passes. The creator receives structured, enumerated fields only — never free-text summaries that might leak sensitive information.'
+  - id: plsat-127
+    scenario: A new project is set up with Paradigm Ambient. The CLAUDE.md mentions a 'learning loop' where agents improve over time. A junior developer asks about the sequence of steps in the ambient learning loop.
+    question: What is the correct order of the ambient learning loop?
+    choices:
+      A: Observe → Learn → Act → Record
+      B: Act → Record → Learn → Apply
+      C: Event emitted → Attention scoring → Self-nomination → Surfacing → Human engagement → Feedback → Journal recording → Confidence adjustment → Pattern extraction → Context enrichment (next session)
+      D: Record everything → Filter later → Show on demand
+      E: Human assigns → Agent acts → Agent reports → Human reviews
+    correct: C
+    explanation: 'The ambient learning loop is a 10-step cycle: (1) An event is emitted (file save, tool call, error). (2) Each agent scores it against their attention patterns. (3) Agents that exceed their threshold self-nominate with a type and urgency. (4) Nominations are surfaced to the human based on SurfacingConfig. (5) The human engages (accepts, dismisses, defers). (6) The response becomes feedback. (7) The agent records insights in its Learning Journal. (8) Confidence scores are adjusted via exponential moving average. (9) Transferable patterns are extracted for cross-project use. (10) Next session, paradigm_context_compose injects the updated patterns and insights.'
+    slot: slot-127
+    section: para-601
+    variants:
+      - id: plsat-127b
+        scenario: A team is evaluating whether Paradigm Ambient's learning loop actually improves agent performance over time. They want to understand the mechanism.
+        question: Which sequence correctly describes how an agent's future behavior improves from a single learning event?
+        choices:
+          A: The agent's code is retrained on the new data point
+          B: The correction is stored but only used if the exact same scenario recurs
+          C: Feedback → Journal entry (trigger + insight + confidence adjustment) → Pattern extraction (if transferable) → Notebook promotion (if auto-promote enabled) → Context compose injects the pattern in future sessions → Agent's expertise scores are updated
+          D: The human writes a rule in the data policy and the agent follows it
+          E: The agent's threshold is lowered so it speaks up more often
+        correct: C
+        explanation: 'Agent improvement follows a structured path: (1) Feedback from human engagement triggers a journal entry with the specific trigger type (correction_received, confidence_miss, etc.), the insight, and confidence adjustment (before/after). (2) If the learning is transferable, a pattern is extracted with applies_when and correct_approach. (3) If notebook_auto_promote is enabled in the agent''s learning config, the pattern promotes to the agent''s notebook. (4) In future sessions, paradigm_context_compose loads transferable journal entries and patterns into the agent''s context. (5) The agent''s expertise scores (EMA) are updated, shifting future attention scoring. The agent is not retrained — it improves through richer context injection.'
+  - id: plsat-128
+    scenario: 'An architect agent has attention: symbols: [''$*'', ''#*''], concepts: [''architecture'', ''design'', ''pattern'', ''refactor''], threshold: 0.5. An event arrives: type: ''concept-mentioned'', source: ''conversation'', keywords: [''refactor'', ''extract'', ''design pattern'', ''strategy pattern''], context: ''Discussing whether to refactor the notification system using the strategy pattern.'''
+    question: What is the architect's conceptMatch score, and does it self-nominate?
+    choices:
+      A: conceptMatch = 0.25 (1 of 4 concepts), score = 0.25, does not nominate (below 0.5)
+      B: conceptMatch = 1.0 — any concept match gives full score
+      C: conceptMatch = 0.75 — 'architecture' does not appear but 'design', 'pattern', and 'refactor' all match, giving 3 of 4 concepts matched. Score = max(0, 0, 0.75, 0) = 0.75, which exceeds 0.5, so the agent self-nominates
+      D: conceptMatch = 0.5 — only exact keyword matches count, and only 'refactor' and 'pattern' are exact matches (2 of 4)
+      E: The architect does not nominate because 'concept-mentioned' is not in its signals list
+    correct: C
+    explanation: 'Concept matching joins the event''s context, keywords, and type into a single lowercase string, then checks how many of the agent''s concepts appear. The combined text includes ''refactor'', ''extract'', ''design pattern'', ''strategy pattern'', ''concept-mentioned''. Against the agent''s concepts [''architecture'', ''design'', ''pattern'', ''refactor'']: ''design'' matches, ''pattern'' matches, ''refactor'' matches. ''architecture'' does not appear. That is 3 out of 4 = 0.75. The final score is max(symbolMatch, pathMatch, conceptMatch, signalMatch). With no symbols or path on this event, symbolMatch and pathMatch are 0. signalMatch is 0 (no signal patterns configured). Score = 0.75, above the 0.5 threshold. The architect self-nominates.'
+    slot: slot-128
+    section: para-601
+    variants:
+      - id: plsat-128b
+        scenario: 'A security agent has attention: symbols: [''^*'', ''#*-auth'', ''#*-middleware''], paths: [''auth/**'', ''middleware/**''], concepts: [''permission'', ''JWT'', ''RBAC'', ''XSS'', ''injection''], signals: [{ type: ''gate-added'' }, { type: ''route-created'' }], threshold: 0.4. An event arrives: type: ''route-created'', source: ''post-write-hook'', path: ''src/routes/admin.ts'', symbols: [''#admin-routes''], keywords: [''new endpoint'', ''admin panel'', ''user management''].'
+        question: What is the security agent's overall score and should it nominate?
+        choices:
+          A: Score = 0 — '#admin-routes' does not match any symbol pattern
+          B: Score = 0.4 — only the path partially matches, barely meeting threshold
+          C: Score = 1.0 — signalMatch is 1.0 because 'route-created' matches signals. symbolMatch is 0 ('#admin-routes' does not match '^*', '#*-auth', or '#*-middleware'). pathMatch is 0 ('src/routes/admin.ts' does not match 'auth/**' or 'middleware/**'). The final score is max(0, 0, 0, 1.0) = 1.0, well above the 0.4 threshold
+          D: Score = 0.2 — partial matches across dimensions are averaged
+          E: Score = 1.0 — all four dimensions fire because admin is security-related
+        correct: C
+        explanation: 'The scoring uses max() across four dimensions, not an average. symbolMatch: ''#admin-routes'' does not end with ''-auth'' or ''-middleware'' and does not start with ''^'', so 0. pathMatch: ''src/routes/admin.ts'' does not match ''auth/**'' or ''middleware/**'', so 0. conceptMatch: keywords [''new endpoint'', ''admin panel'', ''user management''] do not contain ''permission'', ''JWT'', ''RBAC'', ''XSS'', or ''injection'', so 0. signalMatch: the event type ''route-created'' matches the signal { type: ''route-created'' }, so 1.0. Final score: max(0, 0, 0, 1.0) = 1.0. The security agent self-nominates — new route creation is exactly the kind of event that warrants security review.'