@a-company/paradigm 5.38.0 → 6.0.4

package/dist/university-content/quizzes/Q-para-401-provider-cascade.yaml

@@ -0,0 +1,56 @@
+id: Q-para-401-provider-cascade
+title: 'PARA 401: Orchestration — Provider Cascade'
+description: 'Quiz for lesson: Provider Cascade'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-401
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-401.json
+questions:
+  - id: q1
+    question: You are running in a fresh terminal with only the Claude CLI installed. Which provider will the cascade select?
+    choices:
+      A: claude -- the Anthropic API
+      B: claude-code -- the Task tool
+      C: claude-cli -- spawning CLI processes
+      D: manual -- file-based handoffs
+      E: The cascade will fail with an error
+    correct: C
+    explanation: 'The cascade tries providers in order: claude (needs API key -- not available), claude-code-teams (not available), claude-code (needs Max subscription -- not in this scenario), cursor-cli (not in Cursor -- not available), claude-cli (CLI is installed -- available). It selects claude-cli.'
+  - id: q2
+    question: You set PARADIGM_AGENT_PROVIDER=cursor-cli but you are not running inside Cursor. What happens?
+    choices:
+      A: An error is thrown and orchestration fails
+      B: The cascade falls through to the next available provider
+      C: Cursor is automatically launched
+      D: The manual provider is always used as override
+      E: The setting is ignored entirely
+    correct: B
+    explanation: Setting a preferred provider changes the cascade starting point but does not disable it. If cursor-cli is not available (not in Cursor), the cascade continues to claude-cli, then manual. The fallback chain always works.
+  - id: q3
+    question: Which provider is always available regardless of environment?
+    choices:
+      A: claude (Anthropic API)
+      B: claude-code (Task tool)
+      C: cursor-cli
+      D: manual (file-based handoffs)
+      E: claude-code-teams
+    correct: D
+    explanation: The manual provider writes agent prompts to files for human or tool execution. It requires no API keys, subscriptions, or specific IDE -- just a filesystem. This universal fallback ensures orchestration works in every environment.
+  - id: q4
+    question: You just added a new ANTHROPIC_API_KEY to your environment. What command should you run to update Paradigm's awareness of available models?
+    choices:
+      A: paradigm scan
+      B: paradigm team providers --set claude
+      C: paradigm team models --refresh
+      D: paradigm doctor
+      E: paradigm sync
+    correct: C
+    explanation: paradigm team models --refresh re-discovers available models from all providers. After adding a new API key, this command detects the newly available models and updates the model assignments.

package/dist/university-content/quizzes/Q-para-401-quick-check.yaml

@@ -0,0 +1,46 @@
+id: Q-para-401-quick-check
+title: 'PARA 401: Orchestration — Quick-Check: Ask Before You Build'
+description: 'Quiz for lesson: Quick-Check: Ask Before You Build'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-401
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-401.json
+questions:
+  - id: q1
+    question: You need to rename a CSS class from .btn-primary to .btn-main across 2 files. Your project uses balanced enforcement with orchestration-required set to warn. What do you do?
+    choices:
+      A: Run full orchestration — any change should go through the full pipeline
+      B: Run quick-check — it is a scoped, low-risk change that will likely get GREENLIGHT
+      C: Skip orchestration entirely — CSS changes do not count as "complex tasks"
+      D: Ask the architect to plan the rename first
+      E: Disable orchestration-required for this one task
+    correct: B
+    explanation: A CSS class rename across 2 files is exactly the kind of scoped, low-risk change quick-check is designed for. It will likely GREENLIGHT. Skipping orchestration entirely would trigger the enforcement warning. Running full orchestration would waste tokens on a trivial change. Quick-check gives you the compliance checkmark at minimal cost.
+  - id: q2
+    question: Quick-check returns ESCALATE for your task "add user deletion endpoint." You are short on time and want to build it anyway. What are the consequences?
+    choices:
+      A: Nothing — ESCALATE is just a suggestion
+      B: The build will fail at compile time
+      C: The stop hook will flag that you bypassed an ESCALATE recommendation, and the verdict is recorded for traceability
+      D: Your code will be automatically reverted
+      E: The orchestrator will refuse to run any further tasks
+    correct: C
+    explanation: ESCALATE is a recorded recommendation, not a hard block (unless orchestration-required is set to block in strict enforcement). However, the stop hook flags the bypass, and the verdict is traceable in the session history. A user deletion endpoint likely needs security review and architectural planning — skipping that introduces real risk.
+  - id: q3
+    question: 'During quick-check, Jinx asks: "What if the email service is down when sending password reset?" and the reviewer notes "touches auth, new endpoint, email infra — estimated 4+ files." The verdict is ESCALATE. Which agents would full orchestration likely include?'
+    choices:
+      A: Only builder — the task is clearly defined
+      B: architect (4+ files), security (auth + password reset), builder, tester, compliance (symbols)
+      C: Only security — it is a security task
+      D: All 54 agents to be thorough
+      E: Jinx and reviewer again, but with more tokens
+    correct: B
+    explanation: 'Full orchestration composes the team from trigger patterns: 4+ files triggers architect for multi-file design, auth/password triggers security for review, implementation triggers builder, complexity triggers tester for testing, and compliance runs for symbol planning. This is the value of ESCALATE — it routes you to the right team composition.'

package/dist/university-content/quizzes/Q-para-451-foundations.yaml

@@ -0,0 +1,154 @@
+id: Q-para-451-foundations
+title: 'PARA 451: Agents Foundations — Foundations Quiz'
+description: >-
+  First quiz of PARA 451. Covers what an agent is, the three identity layers
+  (id / nickname / archetype), model tiers, the faceted vs sequential
+  orchestration modes, when to invoke the always-on backbone agents, and the
+  `paradigm shift` auto-rosterer. Six questions.
+author: paradigm
+created: '2026-04-26'
+updated: '2026-04-26'
+tags:
+  - course
+  - para-451
+  - agents
+  - foundations
+  - quiz
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+prerequisites:
+  - N-para-451-roster-management
+category: paradigm-core
+origin: authored
+source: agents-course-phase-a-design.md
+questions:
+  - id: q1
+    question: >-
+      You rename `forge` to "Lola" on your project, while leaving the agent's
+      machine-stable handle and role pattern untouched. Which of the three
+      identity layers did you change?
+    choices:
+      A: id
+      B: nickname
+      C: archetype
+      D: tier
+      E: All three — they always change together
+    correct: B
+    explanation: >-
+      The nickname is the user-customisable display layer. Renaming `forge` to
+      "Lola" changes only the nickname; the id (`forge`) stays stable so CLI,
+      MCP, and registry references keep resolving, and the archetype
+      (`intelligence-officer`) stays fixed because that is what the agent *is*,
+      not what it is *called*. Tier is an orthogonal axis (which model the
+      agent runs on) and is not part of the identity model.
+  - id: q2
+    question: >-
+      A teammate says "let's bump documentor up to opus on this project for
+      the next week." Which Paradigm concept are they actually changing?
+    choices:
+      A: The documentor's archetype
+      B: The documentor's notebook tier
+      C: The documentor's model tier (its default Claude model)
+      D: The documentor's roster status
+      E: The documentor's partners declaration
+    correct: C
+    explanation: >-
+      Model tier maps an agent to a default Claude model — tier-1 (opus),
+      tier-2 (sonnet), tier-3 (haiku). Bumping `documentor` from its tier-2
+      default up to opus is a model-tier override, configured per-project in
+      `.paradigm/config.yaml` under `model-resolution`. This is **not** the
+      v6.1 notebook-tier concept (scope/ownership of learned patterns), which
+      is a separate axis with the same unfortunate name — PARA 451 keeps the
+      two strictly separate.
+  - id: q3
+    question: >-
+      You are working in Cursor on a small task. You notice that when the
+      orchestrator switches from `architect` to `builder`, builder seems to
+      "remember" things architect just discussed. In Claude Code with the
+      default settings, this would not happen. What is the difference?
+    choices:
+      A: Cursor uses faceted mode and Claude Code uses sequential mode
+      B: >-
+        Cursor uses sequential mode (single shared context, agents take turns
+        in the same conversation), while Claude Code defaults to faceted mode
+        (each agent runs in an isolated Task subagent with its own memory)
+      C: Cursor disables agent profiles entirely
+      D: Claude Code shares notebooks across agents while Cursor does not
+      E: The two IDEs use entirely different agent rosters
+    correct: B
+    explanation: >-
+      Faceted mode (the Claude Code default) launches each agent as an
+      isolated Task subagent — separate context, separate memory, separate
+      tool access. Sequential mode (Cursor and other IDEs without Task tool
+      support) runs each agent as a persona switch in the same conversation,
+      so they share memory. Both modes use the same agent profiles and the
+      same identity layers; the difference is the runtime plumbing. The mode
+      is configured by `orchestration.default_mode` in `agents.yaml`.
+  - id: q4
+    question: >-
+      You are about to start a feature that will touch eight files across
+      three packages and you do not yet have a written plan. Which agent
+      should pick this up first?
+    choices:
+      A: builder — start implementing and figure it out as you go
+      B: reviewer — review what you already have before planning
+      C: architect — design the multi-file change and produce a spec
+      D: tester — write tests first and let the design fall out
+      E: documentor — update `.purpose` files first
+    correct: C
+    explanation: >-
+      `architect` is the design agent — system design, specs, multi-file
+      planning. Anything that spans three or more files in a non-trivial way
+      is architect's territory. `builder` follows the spec architect produces;
+      invoking builder first on an unscoped change is exactly the trap
+      architect exists to prevent. `reviewer` runs after implementation, not
+      before. `documentor` runs as the final orchestration stage on
+      `.purpose` files and `portal.yaml`, not as the entry point for
+      multi-file design work.
+  - id: q5
+    question: >-
+      `builder` has just finished implementing a feature and the diff is in
+      front of you. The change touches the README. Which agents should run
+      next, and in what order?
+    choices:
+      A: documentor first, then reviewer
+      B: reviewer first, then documentor (the final orchestration stage)
+      C: ftux first, then reviewer, then documentor
+      D: reviewer first, then ftux (because the README is a user-visible
+        surface), then documentor as the final stage
+      E: Only documentor — reviewer is unnecessary on small features
+    correct: D
+    explanation: >-
+      The canonical post-implementation sequence: `reviewer` does the
+      two-stage review (spec compliance, then code quality) and hands back
+      without fixing. `ftux` (Nora) runs after Builder when the task touches
+      a user-visible surface — README qualifies, and ftux reads ONLY
+      user-facing surfaces to simulate first-time-user friction. `documentor`
+      is **always the final orchestration stage** — it updates `.purpose`
+      files, `portal.yaml`, and lore, never source. Reviewer-only or
+      documentor-only sequences skip the friction signal that Nora exists to
+      capture.
+  - id: q6
+    question: >-
+      You have just cloned a fresh Swift project and the repo has no
+      `.paradigm/roster.yaml` yet. Which command bootstraps an initial roster
+      that includes both the always-on backbone *and* the matching ecosystem
+      agent?
+    choices:
+      A: paradigm agent list
+      B: paradigm agent activate swift
+      C: paradigm shift
+      D: paradigm agent get architect
+      E: paradigm agent bench --all
+    correct: C
+    explanation: >-
+      `paradigm shift` is the auto-rosterer. It detects the project's
+      language and platform (Swift in this case), selects the always-on
+      backbone (architect, builder, reviewer, security, tester, documentor,
+      cid), and adds matching ecosystem agents (`swift` for a Swift project).
+      `paradigm agent list` only displays the current roster; `paradigm agent
+      activate swift` would only add the ecosystem agent and would not seed
+      the backbone; the other options do unrelated things. `paradigm shift`
+      is the single command that gets a fresh project from "no roster" to "a
+      sensible default roster".

package/dist/university-content/quizzes/Q-para-451-when-to-invoke.yaml

@@ -0,0 +1,182 @@
+id: Q-para-451-when-to-invoke
+title: 'PARA 451: Agents Foundations — When to Invoke Quiz'
+description: >-
+  Highest-leverage routing quiz of PARA 451. Five scenario questions covering
+  builder-vs-documentor differentiation, reviewer activation timing, scholar
+  deep-dive triggering, ftux first-time UX simulation, and designer for visual
+  work. Tests the decision-tree material from N-para-451-agent-routing.
+  Architect-routing scenario is intentionally omitted (already covered in
+  Q-para-451-foundations q4).
+type: quiz
+author: paradigm
+created: '2026-04-26'
+updated: '2026-04-26'
+tags:
+  - course
+  - para-451
+  - agents
+  - routing
+  - when-to-invoke
+  - quiz
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+prerequisites:
+  - N-para-451-agent-routing
+category: paradigm-core
+origin: authored
+source: agents-course-phase-a-design.md
+questions:
+  - id: q1
+    question: >-
+      Builder has just shipped a feature. The diff modifies source files and
+      adds three new exported functions, but does not touch any `.purpose`
+      files, `portal.yaml`, or lore. Two agents are clearly relevant: one to
+      verify the implementation, and one to keep framework metadata in sync.
+      Which agent owns which job, and in what order do they run?
+    choices:
+      A: documentor reviews the code, then builder updates .purpose files
+      B: >-
+        reviewer reviews the code (spec compliance, then code quality), then
+        documentor updates `.purpose` files, `portal.yaml`, and lore as the
+        final orchestration stage. documentor never touches source.
+      C: >-
+        documentor reviews the code AND updates .purpose files in one pass —
+        reviewer is unnecessary for small changes
+      D: >-
+        reviewer reviews the code AND updates .purpose files in one pass —
+        documentor is for user-facing docs only
+      E: >-
+        builder updates `.purpose` files itself; neither reviewer nor
+        documentor needs to run
+    correct: B
+    explanation: >-
+      reviewer and documentor own non-overlapping jobs. reviewer runs the
+      two-stage review (spec compliance, then code quality) and hands back
+      without fixing — its job is verifying the code. documentor is **always
+      the final orchestration stage** and updates `.purpose` files,
+      `portal.yaml`, and lore — never source. The two agents differentiate
+      cleanly: reviewer touches code (read-only), documentor touches
+      framework metadata (write). Conflating them is the most common routing
+      mistake; that is why this quiz tests the difference explicitly.
+  - id: q2
+    question: >-
+      You are halfway through implementing a feature in builder when you
+      realise the spec is ambiguous about an edge case. What is the right
+      escalation move?
+    choices:
+      A: >-
+        Push through with a best-guess interpretation; reviewer will catch it
+        later
+      B: Bench builder and switch to architect to redesign the whole feature
+      C: >-
+        Have builder push back on the ambiguity (this is one of builder's
+        documented behaviours) and route the clarifying question to architect
+        — the agent that produced the spec — before continuing
+      D: >-
+        Ask documentor to clarify the spec, since documentor owns
+        framework-text consistency
+      E: Invoke jinx (advocate) to pick the safer interpretation
+    correct: C
+    explanation: >-
+      builder's profile explicitly says "follows specs exactly. Pushes back
+      when unclear." Pushing back on ambiguity is the documented behaviour,
+      not a failure mode. The clarifying question routes to architect because
+      architect owns the spec — that is exactly what architect was invoked
+      for. reviewer runs after implementation, not as a clarification surface
+      mid-implementation. documentor never touches spec content. jinx is for
+      stress-testing assumptions before high-risk decisions, not for
+      arbitrating ambiguous spec text.
+  - id: q3
+    question: >-
+      You are about to add a new technical research entry to the project's
+      learning materials — citations, file references, careful sourcing — and
+      then shape it into a sequenced quiz. Which agent (or pair) picks this
+      up?
+    choices:
+      A: educator alone — pedagogical sequencing covers all of it
+      B: scholar alone — research includes the shaping step
+      C: researcher alone — all research is researcher's job
+      D: >-
+        scholar and educator as a reciprocal pair — scholar produces the
+        source material with citation discipline; educator shapes it
+        pedagogically into the quiz. This is the canonical use of the
+        partners primitive.
+      E: documentor — University content is framework-text, so documentor owns it
+    correct: D
+    explanation: >-
+      scholar and educator (Sheila) are the canonical partners pair in
+      Paradigm. scholar produces source material with citation discipline;
+      educator shapes it into pedagogical form (sequenced quizzes, paths,
+      PLSAT modules). Routing to one alone leaves half the work undone.
+      researcher is the **business / market** research agent, not technical
+      research — different archetype entirely. documentor handles framework
+      metadata (`.purpose`, `portal.yaml`, lore), not University content.
+      This routing is the same partnership that authored PARA 451 itself.
+  - id: q4
+    question: >-
+      Builder has just shipped a CLI command improvement. The change updates
+      the `--help` output, the printed error messages, and the README's
+      install section. After reviewer signs off but before documentor runs,
+      which additional agent should be in the pipeline, and what is the rule
+      for when to include it?
+    choices:
+      A: >-
+        scholar — to research how other CLIs handle the same command shape
+      B: >-
+        ftux — Nora simulates a first-time user and reads ONLY user-facing
+        surfaces (README, --help, docs, error messages). Include ftux after
+        builder when the task touches a user-visible surface; skip when the
+        change is purely internal.
+      C: >-
+        designer — Mika reviews any text change for visual hierarchy
+      D: >-
+        ftux always runs after every builder pass, regardless of whether the
+        change is user-facing
+      E: >-
+        jinx — to stress-test the new error messages for failure modes
+    correct: B
+    explanation: >-
+      ftux (Nora) is the framework's first-time-user-experience guard. Its
+      simulation integrity rule is strict — it reads ONLY user-facing surfaces
+      (README, --help, docs, changelogs, error strings). It never reads
+      source code; confusion observed in user-facing surfaces **is** data.
+      The trigger condition is "the task touches a user-visible surface" —
+      a CLI `--help` change, a README update, or new error messages all
+      qualify. Internal-only refactors do not. ftux running after every
+      builder pass would be wasted invocation; ftux skipping a CLI surface
+      change would miss the friction it exists to catch.
+  - id: q5
+    question: >-
+      You are about to redesign the visual layout of a settings panel — UI
+      hierarchy, spacing, motion, accessibility. Which agent owns this work,
+      and what is the relationship to builder?
+    choices:
+      A: >-
+        builder owns it — visual work is just code, and builder writes the
+        code
+      B: >-
+        designer (Mika) owns the visual surface; builder owns the wiring.
+        Invoke designer for the visual decisions, builder for the
+        implementation, often in parallel for visual / UI / design-system
+        work.
+      C: >-
+        forge owns it — visual changes are agent work
+      D: >-
+        documentor owns it, since visual changes are user-facing
+      E: >-
+        Only mika can ever touch UI code; builder must be benched on UI
+        projects entirely
+    correct: B
+    explanation: >-
+      designer (Mika) is the design engineer — UI/UX, design systems, motion,
+      accessibility. designer owns the **surface** (the visual decisions, the
+      hierarchy, the spacing, the motion); builder owns the **wiring** (the
+      implementation that makes the surface real). On UI work the two run
+      together — often in parallel — with designer producing the surface
+      decisions and builder shipping the implementation. forge is the
+      intelligence-officer archetype (Loid) and has nothing to do with
+      visual work. documentor only touches framework metadata. Benching
+      builder on UI projects entirely would be incorrect — builder is
+      always part of the implementation pipeline; designer is the
+      *additional* agent that owns the visual decisions builder implements.

package/dist/university-content/quizzes/Q-para-501-advanced-workflows.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-advanced-workflows
+title: 'PARA 501: Advanced Systems — The Complete Workflow'
+description: 'Quiz for lesson: The Complete Workflow'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: In the complete workflow, why does `paradigm_habits_check(preflight)` run BEFORE `paradigm_ripple` and `paradigm_wisdom_context`?
+    choices:
+      A: To block the session if discovery habits were violated in the previous session
+      B: To verify that the agent intends to call discovery tools — the habit check reminds and tracks, while the actual tools provide the context
+      C: Because habits must always run first regardless of workflow position
+      D: To generate the list of symbols that ripple and wisdom should check
+      E: The order does not matter — they can run in any sequence
+    correct: B
+    explanation: The preflight habits check evaluates whether discovery habits (ripple, navigate, wisdom) are being followed. It runs early to remind and track compliance. The actual MCP tools (ripple, wisdom_context) run after to provide the substantive context. The habit check is about behavioral discipline; the tools are about information gathering.
+  - id: q2
+    question: An agent implements a feature, updates .purpose files, but forgets to record lore before committing. The session modified 5 source files. What sequence of events occurs?
+    choices:
+      A: Pre-commit hook blocks the commit until lore is recorded
+      B: Stop hook blocks, citing missing lore entry → agent records lore → re-attempts commit → stop hook passes
+      C: Commit succeeds but the next session receives a warning about missing lore
+      D: The post-write hook retroactively creates a lore entry from tracked files
+      E: The commit succeeds — lore is enforced by habits, not hooks
+    correct: B
+    explanation: The stop hook checks for lore entries when 3+ source files were modified. With 5 files and no lore entry, it blocks. The agent must then call `paradigm_lore_record` with the session summary, and re-attempt the commit. The pre-commit hook only rebuilds the index — it doesn't check compliance. Lore enforcement lives in the stop hook.
+  - id: q3
+    question: How does Sentinel benefit from the Habits system?
+    choices:
+      A: Sentinel directly calls habit checks during incident recording
+      B: Practice profiles show correlations between skipped habits and incident rates, providing evidence for severity upgrades
+      C: Habits automatically resolve Sentinel incidents when compliance is high
+      D: Sentinel and Habits are independent systems with no interaction
+      E: Habits disable Sentinel checks when compliance is above 90%
+    correct: B
+    explanation: The feedback loop between Habits and Sentinel works through practice profiles. When an agent frequently skips `ripple-before-modify` and the symbols it touches have higher incident rates, the practice profile surfaces this correlation. This provides data-driven evidence to upgrade the habit's severity from advisory to warn or block — closing the loop between behavior and outcomes.
+  - id: q4
+    question: What is the relationship between Lore entries and Session checkpoints?
+    choices:
+      A: They are the same thing — checkpoints are stored as lore entries
+      B: Checkpoints are ephemeral (7-day expiry) for crash recovery; lore entries are permanent for institutional memory
+      C: Lore entries are auto-generated from checkpoints at session end
+      D: Checkpoints replace lore entries in Paradigm v2
+      E: Lore entries expire after 30 days; checkpoints are permanent
+    correct: B
+    explanation: 'Checkpoints and lore serve different purposes with different lifespans. Checkpoints are ephemeral snapshots for crash recovery — they expire after 7 days because their value is immediate continuity. Lore entries are permanent project history — they capture decisions, learnings, and context that remain valuable months or years later. You need both: checkpoints for resilience, lore for memory.'
+  - id: q5
+    question: A team's practice profile shows high compliance across all categories, yet incidents keep occurring in `#payment-service`. What system should they investigate?
+    choices:
+      A: Habits — add more habits targeting the payment service
+      B: Hooks — the stop hook might not be running for payment-related changes
+      C: Sentinel — check `paradigm_sentinel_patterns` and `paradigm_sentinel_stats` for the symbol to identify recurring failure patterns and resolution gaps
+      D: Lore — the payment service lore entries might be inaccurate
+      E: Session Intelligence — breadcrumbs might be losing payment context
+    correct: C
+    explanation: High habit compliance means the behavioral discipline is fine — agents are doing the right things. If incidents persist despite good practices, the issue is likely in the code or architecture, not the process. Sentinel's pattern analysis (`paradigm_sentinel_patterns`) can reveal if the same failure keeps recurring despite resolutions, and `paradigm_sentinel_stats` can show the symbol's incident rate and resolution effectiveness. The answer lives in the incident data, not the compliance data.

package/dist/university-content/quizzes/Q-para-501-aspect-graph-advanced.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-aspect-graph-advanced
+title: 'PARA 501: Advanced Systems — The Aspect Graph at Scale'
+description: 'Quiz for lesson: The Aspect Graph at Scale'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: How many built-in detectors does paradigm_aspect_suggest_scan use, and which of these is NOT one of them?
+    choices:
+      A: 8 built-in detectors; 'database schema' is not one of them
+      B: 6 built-in detectors; 'magic numbers' is not one of them
+      C: 8 built-in detectors; 'rate limits' IS one of them (trick question)
+      D: 10 built-in detectors; 'feature flags' is not one of them
+      E: 5 built-in detectors; 'environment checks' is not one of them
+    correct: A
+    explanation: 'paradigm_aspect_suggest_scan uses 8 built-in detectors: magic numbers, hardcoded strings, rate limits, time values, environment checks, feature flags, regex patterns, and assertion guards. ''Database schema'' is not among them. Custom detectors can be added via .paradigm/aspect-detectors.yaml to extend the detection system.'
+  - id: q2
+    question: 'You want to find all rules that enforce constraints on #payment-service through the aspect graph. Which query approach is most effective?'
+    choices:
+      A: 'paradigm_aspect_search({ query: ''payment rules'' }) to find them by text'
+      B: 'paradigm_aspect_graph({ symbol: ''#payment-service'', hops: 1 }) filtered by ''enforced-by'' edge relation'
+      C: 'paradigm_aspect_heatmap({ limit: 100 }) and manually scan for payment-related aspects'
+      D: 'paradigm_aspect_drift({ aspectId: ''#payment-service'' }) to find stale rules'
+      E: 'paradigm_ripple({ symbol: ''#payment-service'' }) without any graph filtering'
+    correct: B
+    explanation: An edge-filtered graph query at 1 hop with the 'enforced-by' relation is the most direct approach. It returns exactly the aspects that enforce rules on the target component. Search (A) finds by text, not by graph relationship. Heatmap (C) ranks by usage, not by target. Drift (D) checks anchor freshness, not relationships.
+  - id: q3
+    question: Your CI pipeline should fail when aspect anchors have drifted. Which command configuration achieves this?
+    choices:
+      A: paradigm doctor with no flags — drift is always a blocking error
+      B: paradigm doctor --strict — treats drifted anchors as errors that cause a non-zero exit code
+      C: paradigm scan --fix — automatically fixes drifted anchors
+      D: paradigm_aspect_drift with no arguments — checks all aspects and exits non-zero on drift
+      E: paradigm lint --strict — lint checks include drift detection
+    correct: B
+    explanation: paradigm doctor --strict treats warnings (including drifted anchors) as errors, producing a non-zero exit code that fails the CI step. Without --strict, drifted anchors are warnings that do not block. paradigm scan rebuilds the index but does not check drift. paradigm lint checks .purpose file structure, not anchor content hashes.
+  - id: q4
+    question: A new project's aspect search always falls to Tier 3 (fuzzy matching). How do you warm the learning system so common queries use Tier 1?
+    choices:
+      A: Manually edit the search_weights SQLite table to insert mappings
+      B: Run paradigm_reindex with a --warm-search flag
+      C: Run common queries with paradigm_aspect_search, then confirm the best results with paradigm_aspect_confirm for each query
+      D: Wait for 100+ searches to accumulate — Tier 1 learns automatically without confirmation
+      E: Set limits.searchLearningRate to a higher value in config.yaml
+    correct: C
+    explanation: The learning system requires explicit confirmation via paradigm_aspect_confirm. When you search for a term and confirm the best result, the confirmed aspect gets +1.0 weight for that query. After 3-5 confirmations, the weight exceeds the Tier 1 threshold and future queries return instantly. There is no automatic learning without confirmation — the system relies on user feedback to improve.
+  - id: q5
+    question: During a quarterly governance review, the heatmap shows that 30 aspects out of 120 have zero access across all types (search, ripple, navigate, direct). What does this indicate and what should you do?
+    choices:
+      A: These aspects are well-documented and need no changes — zero access means no issues
+      B: Delete all 30 immediately — unused aspects are always stale
+      C: These aspects may be stale, poorly named, or irrelevant — evaluate each for removal, renaming, or consolidation as part of the governance review
+      D: Increase their severity to 'critical' to force agents to access them
+      E: Move them to a separate 'archive' section in the .purpose files
+    correct: C
+    explanation: Zero-access aspects are candidates for review, not automatic deletion. Some may be legitimate but poorly named (rename to improve discoverability). Some may be truly stale with drifted anchors (remove or update). Some may have been superseded by newer aspects (consolidate with supersedes edges). The governance review evaluates each case individually.

package/dist/university-content/quizzes/Q-para-501-aspect-graph-internals.yaml

@@ -0,0 +1,66 @@
+id: Q-para-501-aspect-graph-internals
+title: 'PARA 501: Advanced Systems — Aspect Graph Internals'
+description: 'Quiz for lesson: Aspect Graph Internals'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+questions:
+  - id: q1
+    question: What is the default maxDepth for recursive ripple in the aspect graph?
+    choices:
+      A: 3 — to keep traversals fast and focused
+      B: 5 — balancing depth of discovery with performance
+      C: 10 — the maximum allowed value
+      D: Unlimited — ripple traverses until minWeight is reached
+      E: 1 — only direct connections are followed by default
+    correct: B
+    explanation: The default maxDepth for recursive ripple is 5, with a maximum configurable value of 10. This default balances discovery depth with performance — at 5 hops, you see a meaningful neighborhood without traversing the entire graph. The minWeight threshold (default 0.1) provides additional pruning by cutting off low-confidence paths before they reach maxDepth.
+  - id: q2
+    question: What happens to search weights when a result is confirmed via paradigm_aspect_confirm?
+    choices:
+      A: The confirmed result gets +0.5 weight and all others are deleted
+      B: The confirmed result gets +1.0 weight and all other results for the same query decay by *0.95
+      C: All results for the query get +1.0 weight to reinforce the entire set
+      D: The confirmed result is permanently pinned and decay is disabled
+      E: The confirmed result replaces all other entries for that query
+    correct: B
+    explanation: The search learning system adds +1.0 to the confirmed result's weight for that query and multiplies all other existing results for the same query by 0.95 (a 5% decay). This self-correcting mechanism lets the best result rise to the top over time while alternatives gradually fade. The decay only applies to aspects that have existing search_weights entries for the query — it does not penalize unrelated aspects.
+  - id: q3
+    question: Which SQLite table stores aspect access frequency for the heatmap tool?
+    choices:
+      A: aspects — in an access_count column
+      B: edges — access frequency is tracked per edge
+      C: search_weights — all access types feed into search weights
+      D: heatmap — with columns for aspect_id, access_type, count, and last_accessed
+      E: anchors — access is tracked per anchor location
+    correct: D
+    explanation: The `heatmap` table stores aspect access frequency with columns for `aspect_id`, `access_type` (search, ripple, navigate, direct), `count`, and `last_accessed`. This dedicated table allows the `paradigm_aspect_heatmap` tool to rank aspects by usage frequency and break down how each aspect is typically discovered — whether through search, ripple analysis, navigation, or direct access.
+  - id: q4
+    question: What is the queue limit for recursive ripple BFS traversal?
+    choices:
+      A: 100 nodes — to keep memory usage minimal
+      B: 500 nodes — a balance between coverage and performance
+      C: 1000 nodes — preventing runaway traversals in dense graphs
+      D: Unlimited — the queue grows until maxDepth is reached
+      E: 10000 nodes — large enough for enterprise-scale graphs
+    correct: C
+    explanation: The BFS queue limit is 1000 nodes. This prevents runaway traversals in densely connected aspect graphs where the number of reachable nodes could grow exponentially with depth. When the queue exceeds 1000 entries, the oldest entries are dropped, ensuring the algorithm completes in bounded time and memory regardless of graph density.
+  - id: q5
+    question: How are aspect edges inferred from existing data during materialization?
+    choices:
+      A: By analyzing import statements in source code files
+      B: From applies-to references with weight 0.5 and origin 'inferred', and from shared lore references with origin 'learned'
+      C: By running static analysis on anchor code blocks
+      D: From git commit history showing which aspects changed together
+      E: Only explicit edges are created — no inference occurs
+    correct: B
+    explanation: The materialization pipeline creates inferred edges in two ways. First, `materializeAspects` generates edges from `applies-to` references with weight 0.5 and origin 'inferred' — when an aspect applies to a component, a relationship edge is created. Second, `inferLoreEdges` scans for aspects sharing lore references and creates edges with origin 'learned' and weight proportional to the overlap. These supplement explicit YAML edges to build a richer graph.