@a-company/paradigm 5.37.11 → 6.0.2

package/dist/university-content/notes/N-para-701-per-project-rosters.md

@@ -0,0 +1,198 @@
+---
+id: N-para-701-per-project-rosters
+title: 'Lesson 5: Per-Project Rosters'
+type: note
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+  - rosteryaml-at-paradigmrosteryaml
+  - no-rosteryaml-
+  - project-type-detection
+symbols: []
+difficulty: beginner
+estimatedMinutes: 6
+prerequisites: []
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+---
+
+## The Problem: 54 Agents Everywhere
+
+Without project-level rosters, all 54 global agents are available to every project. This creates three problems:
+
+1. **Noise** — The orchestrator considers 54 agents when planning, even though a backend API project does not need a designer, copywriter, or SEO agent. More candidates means more evaluation time and potentially irrelevant agents being included in plans.
+
+2. **Irrelevance** — Agents that have no domain expertise for the project (gamedev on a SaaS app, legal on an open-source tool) waste attention by scoring events and producing nominations that will never be acted on.
+
+3. **Global benching is broken** — Before rosters, benching an agent (setting `benched: true` on the `.agent` file) was a global operation. Benching the gamedev agent for your SaaS project also benched it for your game project. There was no per-project control.
+
+## The Solution: roster.yaml
+
+The `roster.yaml` file at `.paradigm/roster.yaml` lists exactly which agents are active on this project:
+
+```yaml
+# .paradigm/roster.yaml
+version: "1.0"
+project: dealoracle
+type: saas-web-app
+
+active:
+  - architect
+  - builder
+  - reviewer
+  - tester
+  - security
+  - documentor
+  - designer          # Mika
+  - copywriter         # Wren
+  - performance        # Bolt
+  - devops             # Atlas
+  - dba                # Vault
+  - e2e                # Ghost
+  - dx                 # Helix
+  - seo                # Beacon
+  - pm                 # Yuki
+  - product            # North
+  - advocate           # Jinx
+  - debugger           # Trace
+  - release            # Ship
+```
+
+Agents not listed are not active on this project. They still exist globally at `~/.paradigm/agents/` but the orchestrator will not consider them when planning work for this project.
+
+## Backward Compatibility
+
+The key design decision: **no roster.yaml = all agents available**. Existing projects that never created a roster continue working exactly as before. The `isAgentActive()` function implements this:
+
+```typescript
+function isAgentActive(agentId: string, rootDir: string): boolean {
+  const roster = loadProjectRoster(rootDir);
+  if (!roster) return true;  // No roster = all active
+  return roster.includes(agentId);
+}
+```
+
+This ensures zero breaking changes. You opt into roster filtering by creating the file. Until then, the system behaves as it always has.
+
+## Project Type Detection
+
+When running `paradigm shift` (the project initialization command), the system auto-detects the project type from filesystem signals:
+
+```typescript
+function detectProjectType(cwd: string): ProjectType {
+  const signals = {
+    hasPackageJson: exists('package.json'),
+    hasSupabase: exists('supabase/'),
+    hasNextConfig: exists('next.config.*'),
+    hasSwiftPackage: exists('Package.swift'),
+    hasGodotProject: exists('project.godot'),
+    hasCargoToml: exists('Cargo.toml'),
+    hasPubspecYaml: exists('pubspec.yaml'),
+    hasPrisma: exists('prisma/'),
+    hasDockerfile: exists('Dockerfile'),
+  };
+
+  if (signals.hasGodotProject) return 'game';
+  if (signals.hasSwiftPackage) return 'ios-app';
+  if (signals.hasPubspecYaml) return 'flutter-app';
+  if (signals.hasSupabase && signals.hasNextConfig) return 'saas-web-app';
+  if (signals.hasNextConfig) return 'web-app';
+  if (signals.hasCargoToml) return 'rust-project';
+  if (signals.hasPrisma || signals.hasDockerfile) return 'backend-api';
+  return 'generic';
+}
+```
+
+Detected types include `saas-web-app`, `web-app`, `backend-api`, `ios-app`, `flutter-app`, `game`, `rust-project`, and `generic`. Each type maps to a suggested roster.
+
+## Suggested Rosters by Type
+
+Each project type has a pre-defined suggested roster. These are starting points, not mandatory configurations:
+
+| Project Type | Typical Size | Notable Inclusions | Notable Exclusions |
+|---|---|---|---|
+| saas-web-app | ~24 agents | Full stack: designer, dba, seo, sales, legal | gamedev, 3d, audio, streaming |
+| web-app | ~15 agents | Frontend-focused: designer, seo, a11y | dba, sales, legal |
+| backend-api | ~13 agents | Backend-focused: dba, dx, performance | designer, copywriter, seo |
+| ios-app | ~12 agents | Mobile: mobile (Swift), a11y, performance | dba, seo, devops |
+| game | ~11 agents | Game-specific: gamedev, 3d, audio | seo, legal, sales, dba |
+| flutter-app | ~11 agents | Cross-platform: mobile, a11y | dba, seo, devops |
+| generic | ~8 agents | Core only: architect through documentor + debugger + qa | All specialists |
+
+The `generic` roster is intentionally minimal: architect, builder, reviewer, tester, security, documentor, debugger, and qa. These 8 agents provide the baseline quality coverage (design, build, review, test, secure, document, debug, validate) that every project needs.
+
+## CLI Commands for Roster Management
+
+Roster management is done through the CLI:
+
+```bash
+# Interactive roster setup (suggests based on project type)
+paradigm agents roster
+
+# Activate specific agents
+paradigm agents activate designer copywriter security devops dba
+
+# Deactivate agents
+paradigm agents deactivate gamedev 3d audio streaming
+
+# List active agents for this project
+paradigm agents list              # Shows only active roster
+paradigm agents list --all        # Shows all global + active status
+
+# Activate a pod (all agents in the pod)
+paradigm agents activate --pod ship-pod
+```
+
+Activate and deactivate modify the `roster.yaml` file — they never modify global `.agent` files. This is the key architectural decision: the roster is a project-level filter over global agents. Agents are not "installed" or "removed" per project; they are "active" or "inactive" based on whether they appear in the roster.
+
+## Orchestrator Integration
+
+The orchestrator's planning phase reads the roster before selecting agents:
+
+```typescript
+function getActiveAgents(rootDir: string): string[] {
+  const rosterPath = path.join(rootDir, '.paradigm', 'roster.yaml');
+  if (fs.existsSync(rosterPath)) {
+    const roster = yaml.load(fs.readFileSync(rosterPath, 'utf8'));
+    return roster.active || [];
+  }
+  // Fallback: all global agents (backward compat)
+  return getAllGlobalAgents().map(a => a.id);
+}
+```
+
+The returned list gates which agents are considered during orchestration planning. If the security agent is not in the roster, it will not be included in orchestration plans, will not receive event notifications, and will not self-nominate contributions. It is effectively invisible on this project.
+
+## paradigm shift Integration
+
+During `paradigm shift` (first-time project setup), the roster step runs after team initialization:
+
+```
+Step 2b/6: Agent roster setup...
+
+  Detected project type: SaaS web app (React + Supabase + Vercel)
+
+  Suggested roster (20 agents):
+    Core:       architect, builder, reviewer, tester, security, documentor
+    Design:     designer (Mika), copywriter (Wren), a11y (Aria)
+    Data:       dba (Vault), performance (Bolt), analyst (Sage)
+    Infra:      devops (Atlas), seo (Beacon), release (Ship)
+    Product:    pm (Yuki), product (North)
+    Quality:    e2e (Ghost), qa (Shield), advocate (Jinx)
+
+  Accept suggested roster? [Y/n]
+
+  Roster saved to .paradigm/roster.yaml (20 agents active)
+```
+
+The human can accept the suggestion, modify it, or skip (which creates no roster file, keeping all agents active). On existing projects, running `paradigm shift` again offers to create a roster based on the detected type.
+
+## Why Rosters Are Not Agent Behavior
+
+Rosters are a filtering mechanism, not a behavior modifier. An agent's `.agent` file defines who it is (personality, expertise, behaviors, attention). The roster defines whether it is active on this project. If the designer is not in the roster, it does not mean the designer "knows" it is inactive — it simply is not invoked.
+
+This separation is important: when you activate the designer on a project, it arrives with its full personality, expertise, notebooks, and transferable patterns intact. Nothing about the agent changed. The roster just opened the door.

package/dist/university-content/notes/N-para-701-symphony-visibility.md

@@ -0,0 +1,142 @@
+---
+id: N-para-701-symphony-visibility
+title: 'Lesson 8: Live Visibility via Symphony'
+type: note
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+  - orchestrator-auto-emits-thr-orch-id
+  - noterelay-polls-paradigmscorethreads
+  - symphonythreadwatcher-filters-orchestration
+symbols: []
+difficulty: beginner
+estimatedMinutes: 6
+prerequisites: []
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+---
+
+## The Visibility Gap
+
+Orchestration runs inside an MCP tool call. The human sees: "Calling paradigm_orchestrate_inline..." followed by a wall of text when it completes. There is no live visibility into what is happening during orchestration — which agents are active, what they are producing, whether they agree or disagree, how far along the plan is.
+
+Symphony closes this gap by providing a real-time communication channel between the orchestrator, agents, and the Conductor UI. The orchestrator emits progress into Symphony threads. The Conductor watches these threads and renders live updates.
+
+## How Orchestration Emits to Symphony
+
+When `paradigm_orchestrate_inline` runs in execute mode, it auto-emits a Symphony thread with a `thr-orch-` prefix:
+
+```typescript
+const orchestrationThread = `thr-orch-${orchestrationId}`;
+```
+
+The orchestrator creates this thread via the Symphony loader and posts an initial note from the "maestro" identity:
+
+```typescript
+const maestroId = `${projectName}/maestro`;
+symphony.createNote(orchestrationThread, {
+  from: maestroId,
+  content: `Orchestration started: ${taskDescription}`,
+  type: 'agent',
+  project: projectName,
+  role: 'orchestrator',
+});
+```
+
+As each agent completes its work, the orchestrator posts their contributions to the thread. If security finds a gate coverage issue, that appears as a note from the security agent. If the builder completes implementation, that appears as a note from the builder. The thread becomes a chronological record of the orchestration.
+
+The `thr-orch-` prefix is critical — it is the identifier that allows the Conductor to distinguish orchestration threads from regular Symphony threads (like team chat or general discussion).
+
+## NoteRelay: The Polling Bridge
+
+Symphony threads are stored as JSON files in `~/.paradigm/score/threads/`. The Conductor is a native macOS application that cannot directly watch the filesystem for MCP-created files (different process, different sandbox). NoteRelay bridges this gap.
+
+NoteRelay is a Conductor service that polls the Symphony thread directory on a 5-second interval:
+
+```
+~/.paradigm/score/threads/*.json → NoteRelay (5s poll) → Conductor state
+```
+
+Every 5 seconds, NoteRelay scans for new or modified thread files. When it finds changes, it parses the JSON, extracts the notes, and updates the Conductor's in-memory state. This creates a near-real-time bridge between the MCP server (which writes threads) and the Conductor UI (which displays them).
+
+The 5-second poll interval is a deliberate balance. A 1-second poll would provide faster updates but consume more CPU on the macOS overlay app. A 30-second poll would be too slow for live orchestration visibility. Five seconds means the Conductor is at most 5 seconds behind the actual orchestration state.
+
+## SymphonyThreadWatcher: Filtering Orchestration Threads
+
+NoteRelay delivers all Symphony threads to the Conductor. But the Team view in Conductor only wants orchestration threads — not general discussion or personal notes. SymphonyThreadWatcher handles this filtering.
+
+SymphonyThreadWatcher polls at a 3-second interval (faster than NoteRelay's 5-second scan) and filters threads by the `thr-orch-` prefix:
+
+```
+All Symphony threads → SymphonyThreadWatcher (3s poll) → 
+Filter: thr-orch-* → TeamThreadView
+```
+
+The watcher also tracks thread state: is the orchestration in progress, completed, or failed? It determines this by checking the latest note in the thread — a "completed" or "failed" status note indicates the orchestration has finished.
+
+## TeamThreadView: Rendering in Conductor
+
+TeamThreadView is the SwiftUI view that renders orchestration threads in the Conductor overlay. Each note in the thread is displayed with:
+
+1. **Colored role badge** — Each agent role has a distinct color. The architect gets one color, the security agent another, the builder another. This makes it immediately visible who said what without reading names.
+
+2. **Intent indicator** — The orchestration plan specifies an intent for each agent (e.g., "review gate coverage", "implement webhook handler"). The intent appears next to the agent's badge, providing context for why the agent was included.
+
+3. **Agent nickname** — If the agent has a nickname (Mika, Atlas, Jinx), it is displayed alongside the role. This makes attributed responses feel like team communication rather than tool output.
+
+4. **Note content** — The actual contribution from the agent. This could be a review finding, a code suggestion, a security flag, or a completion confirmation.
+
+The visual layout mimics a team chat interface: chronological notes from identified agents, each with their role badge and intent. The human can watch the orchestration unfold in real time rather than waiting for a monolithic output.
+
+## Agent-Side Emission
+
+Agents are instructed (via their orchestration prompts) to emit progress and completion notes to Symphony during execution. The orchestrator includes this instruction:
+
+```markdown
+## Symphony Communication
+During your work, emit progress notes to the active Symphony thread.
+Use these note types:
+- progress: "Reviewing file X of Y..."
+- finding: "Found gate coverage gap on POST /api/payments"
+- completion: "Review complete. 2 findings, 0 blockers."
+```
+
+Not all agents emit notes equally. The architect tends to emit planning updates. The security agent emits findings. The builder emits completion summaries. The documentor emits what it updated. This diversity creates a natural team-communication feel in the thread.
+
+## The Full Pipeline
+
+Putting it all together, the live visibility pipeline is:
+
+```
+pardigm_orchestrate_inline execute
+  ↓
+Orchestrator creates thr-orch-{id} thread
+  ↓
+Each agent contributes → notes posted to thread
+  ↓
+Thread file written to ~/.paradigm/score/threads/
+  ↓
+NoteRelay polls (5s) → detects new/changed thread
+  ↓
+SymphonyThreadWatcher filters (3s) → thr-orch-* threads
+  ↓
+TeamThreadView renders with colored badges and intents
+  ↓
+Human sees live orchestration progress in Conductor overlay
+```
+
+The latency from agent contribution to visual display is at most ~8 seconds (5s NoteRelay + 3s ThreadWatcher in the worst case). In practice, it is usually 3-5 seconds because the polls are offset.
+
+## Why This Architecture
+
+The polling-based architecture was chosen over alternatives for pragmatic reasons:
+
+- **Filesystem watching** (FSEvents on macOS) is brittle across sandboxed processes and does not work reliably when the MCP server writes files from a different process tree.
+- **WebSocket/TCP connection** between MCP server and Conductor would require connection management, reconnection logic, and port conflicts. Polling a directory is simpler.
+- **Shared memory** would require both processes to link against the same framework, creating tight coupling.
+
+Polling JSON files from a well-known directory is the simplest architecture that provides near-real-time visibility without process-coupling complexity. The tradeoff is a 3-8 second display latency, which is acceptable for human observation of orchestration progress.

package/dist/university-content/paths/LP-para-001.yaml

@@ -0,0 +1,29 @@
+id: LP-para-001
+title: 'PARA 001: Quick Start'
+description: Get productive with Paradigm in 15 minutes. Initialize a project, meet your agent team, and build your first feature with orchestration. Hands-on from the first minute — theory comes later.
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-001
+ordered: true
+category: paradigm-core
+origin: imported
+source: courses/para-001.json
+steps:
+  - content: N-para-001-shift-setup
+    required: true
+  - content: Q-para-001-shift-setup
+    required: true
+    passRequired: true
+  - content: N-para-001-meet-the-team
+    required: true
+  - content: Q-para-001-meet-the-team
+    required: true
+    passRequired: true
+  - content: N-para-001-build-something
+    required: true
+  - content: Q-para-001-build-something
+    required: true
+    passRequired: true

package/dist/university-content/paths/LP-para-101.yaml

@@ -0,0 +1,59 @@
+id: LP-para-101
+title: 'PARA 101: Foundations'
+description: Master the fundamentals of Paradigm — the meta-framework that gives AI agents structured context to navigate and understand your codebase. Learn the five symbols, purpose files, tags, logging, project structure, and gates.
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-101
+ordered: true
+category: paradigm-core
+origin: imported
+source: courses/para-101.json
+steps:
+  - content: N-para-101-welcome
+    required: true
+  - content: Q-para-101-welcome
+    required: true
+    passRequired: true
+  - content: N-para-101-first-steps
+    required: true
+  - content: Q-para-101-first-steps
+    required: true
+    passRequired: true
+  - content: N-para-101-five-symbols
+    required: true
+  - content: Q-para-101-five-symbols
+    required: true
+    passRequired: true
+  - content: N-para-101-purpose-files
+    required: true
+  - content: Q-para-101-purpose-files
+    required: true
+    passRequired: true
+  - content: N-para-101-tags-and-classification
+    required: true
+  - content: Q-para-101-tags-and-classification
+    required: true
+    passRequired: true
+  - content: N-para-101-paradigm-logger
+    required: true
+  - content: Q-para-101-paradigm-logger
+    required: true
+    passRequired: true
+  - content: N-para-101-project-structure
+    required: true
+  - content: Q-para-101-project-structure
+    required: true
+    passRequired: true
+  - content: N-para-101-portal-yaml
+    required: true
+  - content: Q-para-101-portal-yaml
+    required: true
+    passRequired: true
+  - content: N-para-101-component-types
+    required: true
+  - content: Q-para-101-component-types
+    required: true
+    passRequired: true

package/dist/university-content/paths/LP-para-201.yaml

@@ -0,0 +1,69 @@
+id: LP-para-201
+title: 'PARA 201: Architecture'
+description: Deepen your Paradigm expertise with advanced patterns for flows, gates, aspects, disciplines, naming conventions, and architectural design. Learn to build complete features end-to-end using the full symbol system.
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-201
+ordered: true
+category: paradigm-core
+origin: imported
+source: courses/para-201.json
+steps:
+  - content: N-para-201-flows-deep-dive
+    required: true
+  - content: Q-para-201-flows-deep-dive
+    required: true
+    passRequired: true
+  - content: N-para-201-gates-deep-dive
+    required: true
+  - content: Q-para-201-gates-deep-dive
+    required: true
+    passRequired: true
+  - content: N-para-201-aspects-and-anchors
+    required: true
+  - content: Q-para-201-aspects-and-anchors
+    required: true
+    passRequired: true
+  - content: N-para-201-aspect-graph
+    required: true
+  - content: Q-para-201-aspect-graph
+    required: true
+    passRequired: true
+  - content: N-para-201-portal-protocol
+    required: true
+  - content: Q-para-201-portal-protocol
+    required: true
+    passRequired: true
+  - content: N-para-201-disciplines
+    required: true
+  - content: Q-para-201-disciplines
+    required: true
+    passRequired: true
+  - content: N-para-201-symbol-naming
+    required: true
+  - content: Q-para-201-symbol-naming
+    required: true
+    passRequired: true
+  - content: N-para-201-component-patterns
+    required: true
+  - content: Q-para-201-component-patterns
+    required: true
+    passRequired: true
+  - content: N-para-201-signal-patterns
+    required: true
+  - content: Q-para-201-signal-patterns
+    required: true
+    passRequired: true
+  - content: N-para-201-cross-cutting-concerns
+    required: true
+  - content: Q-para-201-cross-cutting-concerns
+    required: true
+    passRequired: true
+  - content: N-para-201-architecture-review
+    required: true
+  - content: Q-para-201-architecture-review
+    required: true
+    passRequired: true

package/dist/university-content/paths/LP-para-301.yaml

@@ -0,0 +1,84 @@
+id: LP-para-301
+title: 'PARA 301: Operations'
+description: Master the operational tools and workflows that keep a Paradigm project healthy. From history tracking and fragility analysis to sentinel observability and context management, this course covers the day-to-day operations that separate well-maintained projects from chaotic ones.
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+ordered: true
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+steps:
+  - content: N-para-301-history-system
+    required: true
+  - content: Q-para-301-history-system
+    required: true
+    passRequired: true
+  - content: N-para-301-fragility-tracking
+    required: true
+  - content: Q-para-301-fragility-tracking
+    required: true
+    passRequired: true
+  - content: N-para-301-wisdom-system
+    required: true
+  - content: Q-para-301-wisdom-system
+    required: true
+    passRequired: true
+  - content: N-para-301-decisions
+    required: true
+  - content: Q-para-301-decisions
+    required: true
+    passRequired: true
+  - content: N-para-301-ripple-analysis
+    required: true
+  - content: Q-para-301-ripple-analysis
+    required: true
+    passRequired: true
+  - content: N-para-301-doctor-and-validation
+    required: true
+  - content: Q-para-301-doctor-and-validation
+    required: true
+    passRequired: true
+  - content: N-para-301-enforcement-levels
+    required: true
+  - content: Q-para-301-enforcement-levels
+    required: true
+    passRequired: true
+  - content: N-para-301-paradigm-shift
+    required: true
+  - content: Q-para-301-paradigm-shift
+    required: true
+    passRequired: true
+  - content: N-para-301-navigation-system
+    required: true
+  - content: Q-para-301-navigation-system
+    required: true
+    passRequired: true
+  - content: N-para-301-sentinel-observability
+    required: true
+  - content: Q-para-301-sentinel-observability
+    required: true
+    passRequired: true
+  - content: N-para-301-sync-and-maintenance
+    required: true
+  - content: Q-para-301-sync-and-maintenance
+    required: true
+    passRequired: true
+  - content: N-para-301-context-management
+    required: true
+  - content: Q-para-301-context-management
+    required: true
+    passRequired: true
+  - content: N-para-301-protocols
+    required: true
+  - content: Q-para-301-protocols
+    required: true
+    passRequired: true
+  - content: N-para-301-operations-review
+    required: true
+  - content: Q-para-301-operations-review
+    required: true
+    passRequired: true

package/dist/university-content/paths/LP-para-401.yaml

@@ -0,0 +1,74 @@
+id: LP-para-401
+title: 'PARA 401: Orchestration'
+description: Advanced course on multi-agent orchestration, MCP tool mastery, and framework-level coordination. Learn to decompose complex tasks across specialized agents, configure provider cascades, enforce governance with the PM layer, and achieve full Paradigm framework mastery.
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-401
+ordered: true
+category: paradigm-core
+origin: imported
+source: courses/para-401.json
+steps:
+  - content: N-para-401-mcp-tools-overview
+    required: true
+  - content: Q-para-401-mcp-tools-overview
+    required: true
+    passRequired: true
+  - content: N-para-401-multi-agent-coordination
+    required: true
+  - content: Q-para-401-multi-agent-coordination
+    required: true
+    passRequired: true
+  - content: N-para-401-agent-roles
+    required: true
+  - content: Q-para-401-agent-roles
+    required: true
+    passRequired: true
+  - content: N-para-401-provider-cascade
+    required: true
+  - content: Q-para-401-provider-cascade
+    required: true
+    passRequired: true
+  - content: N-para-401-orchestration-workflow
+    required: true
+  - content: Q-para-401-orchestration-workflow
+    required: true
+    passRequired: true
+  - content: N-para-401-quick-check
+    required: true
+  - content: Q-para-401-quick-check
+    required: true
+    passRequired: true
+  - content: N-para-401-pm-governance
+    required: true
+  - content: Q-para-401-pm-governance
+    required: true
+    passRequired: true
+  - content: N-para-401-commit-conventions
+    required: true
+  - content: Q-para-401-commit-conventions
+    required: true
+    passRequired: true
+  - content: N-para-401-mastery-review
+    required: true
+  - content: Q-para-401-mastery-review
+    required: true
+    passRequired: true
+  - content: N-para-401-agent-interop
+    required: true
+  - content: Q-para-401-agent-interop
+    required: true
+    passRequired: true
+  - content: N-para-401-agent-identity
+    required: true
+  - content: Q-para-401-agent-identity
+    required: true
+    passRequired: true
+  - content: N-para-401-notebooks-permissions
+    required: true
+  - content: Q-para-401-notebooks-permissions
+    required: true
+    passRequired: true