@a-company/paradigm 5.38.0 → 6.0.4

package/dist/university-content/notes/N-para-601-nominations-debates.md

@@ -0,0 +1,115 @@
+---
+id: N-para-601-nominations-debates
+title: Nominations & Debates
+type: note
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-601
+  - nominations-are-structured
+  - four-urgency-levels
+  - five-nomination-types
+symbols: []
+difficulty: beginner
+estimatedMinutes: 5
+prerequisites: []
+category: paradigm-core
+origin: imported
+source: courses/para-601.json
+---
+
+## Agents Self-Nominate Contributions
+
+In the ambient model, agents do not push messages at each other. Instead, when an event exceeds an agent's attention threshold, the agent creates a **nomination** — a structured contribution that may or may not be surfaced to the human. Nominations are the bridge between passive observation and active participation.
+
+The key insight is that not every observation deserves immediate attention. A nomination captures the agent's contribution in a structured format, and surfacing rules determine when and how to present it. This prevents the "every agent shouts at once" problem that plagues naive multi-agent systems.
+
+## Nomination Anatomy
+
+A nomination has 13 fields:
+
+```typescript
+interface Nomination {
+  id: string;                    // Unique ID
+  agent: string;                 // Nominating agent
+  relevance: number;             // Attention score (0.0-1.0)
+  urgency: NominationUrgencyLevel;  // critical, high, medium, low
+  type: NominationType;          // warning, suggestion, question, offer, observation
+  brief: string;                 // 1-line summary
+  detail?: string;               // Full contribution (shown on engage)
+  action_offered?: string;       // Action the agent offers to take
+  evidence?: NominationEvidence[];  // Supporting evidence
+  triggered_by: string[];        // Event ID(s) that triggered this
+  timestamp: string;             // ISO 8601
+  surfaced: boolean;             // Whether shown to human
+  engaged?: boolean;             // Whether human interacted
+  response?: string;             // accepted, dismissed, deferred
+}
+```
+
+The `brief` field is critical — it is the first (and possibly only) thing the human sees. A good brief is actionable and specific: "New POST /api/payments route lacks ^payment-authorized gate" rather than "Security concern detected."
+
+The `detail` field expands on the brief with full reasoning, code references, and recommendations. It is shown only if the human engages with the nomination, saving context window space when the human dismisses or defers.
+
+## Urgency Levels
+
+Four urgency levels determine how aggressively a nomination is surfaced:
+
+| Level | Meaning | Surfacing Rule |
+|---|---|---|
+| `critical` | Immediate action required — security vulnerability, data loss risk | Always surfaced immediately, interrupts if necessary |
+| `high` | Should be addressed before session ends — missing gate, broken flow | Surfaced in the current batch, highlighted |
+| `medium` | Worth knowing but not blocking — code smell, missing test | Surfaced if the human has not dismissed similar nominations recently |
+| `low` | FYI — style suggestion, minor optimization opportunity | Batched and shown only if the human asks or at session end |
+
+The surfacing rules are configurable via `SurfacingConfig`. A user who finds security nominations too frequent can set the security agent's `min_urgency` to `high`, silencing `medium` and `low` nominations from that agent.
+
+## Nomination Types
+
+Five types classify the nature of the contribution:
+
+- **warning** — Something is wrong or risky (e.g., "Route without gate", "Aspect anchor drift detected")
+- **suggestion** — An improvement opportunity (e.g., "Consider extracting this into a shared utility")
+- **question** — The agent needs clarification (e.g., "Should this endpoint be public or require authentication?")
+- **offer** — The agent volunteers to do something (e.g., "I can write the test suite for this component")
+- **observation** — A neutral factual note (e.g., "This is the third time this pattern has been refactored")
+
+The `action_offered` field is used with `offer` type nominations. When the human accepts an offer, the agent can proceed to take the offered action.
+
+## Evidence
+
+Nominations can include evidence to support their claims. Each `NominationEvidence` item can reference a file, a symbol, a pattern from the agent's notebook, specific line numbers, or a textual description.
+
+Evidence transforms a nomination from opinion to argument. "This route needs a gate" is a suggestion. "This route needs a gate — see portal.yaml line 42 where all /api/payments routes require ^payment-authorized, and `#payment-service` has a documented aspect ~pci-compliance-required" is a compelling argument backed by project facts.
+
+## Storage
+
+Nominations and debates are stored as JSONL files alongside the event stream:
+
+- `.paradigm/events/nominations.jsonl` — All nominations, append-only
+- `.paradigm/events/debates.jsonl` — Detected debates (conflicting/complementary nomination groups)
+
+## Debate Detection
+
+When multiple agents nominate on the same event or overlapping symbols, a **debate** may form. Paradigm detects debates by checking for overlapping `triggered_by` event IDs or overlapping symbols across nominations within a time window.
+
+A `Debate` has two types:
+- **conflicting** — The nominations disagree (e.g., architect says "use SQL" while builder says "use NoSQL")
+- **complementary** — The nominations agree but add different perspectives (e.g., security says "add gate" and tester says "add test for gate")
+
+Debates are surfaced as a group rather than individual nominations, so the human sees the full picture. A debate includes:
+- `topic` — What the debate is about (derived from overlapping symbols/events)
+- `nominations` — IDs of the participating nominations
+- `overlap_symbols` — Symbols that triggered grouping
+- `overlap_events` — Events that triggered grouping
+- `resolution` — How it was resolved (chosen nomination, reason, resolved by human or consensus)
+
+## MCP Tools
+
+**`paradigm_ambient_nominations`** — View pending nominations. Supports filtering by agent, urgency, type, and whether nominations have been surfaced. Returns nominations sorted by urgency (critical first) then by relevance score.
+
+**`paradigm_ambient_engage`** — Engage with a nomination. Pass the nomination ID and a response (`accepted`, `dismissed`, `deferred`). If accepted, the nomination's `detail` and `evidence` are returned for the agent to act on. If dismissed, the nomination is marked as seen but not acted upon. If deferred, it is re-queued for later surfacing.
+
+The engage tool creates a feedback signal — over time, the pattern of accepted vs dismissed nominations helps calibrate attention thresholds. An agent whose nominations are consistently dismissed may need a higher threshold.

package/dist/university-content/notes/N-para-701-agent-notebooks.md

@@ -0,0 +1,131 @@
+---
+id: N-para-701-agent-notebooks
+title: 'Lesson 3: Agent Notebooks'
+type: note
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+  - notebook-entries-contain
+  - notebookentry-schema-id
+  - global-notebooks-paradigmnotebooks
+symbols: []
+difficulty: beginner
+estimatedMinutes: 6
+prerequisites: []
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+---
+
+## What Notebooks Are
+
+Agent notebooks are curated snippet libraries distilled from experience. Where expertise scores track *how well* an agent knows a symbol, and transferable patterns track *general principles* the agent has learned, notebooks contain *specific, reusable knowledge* — code patterns, configuration snippets, troubleshooting procedures, and domain-specific techniques.
+
+A notebook entry for the security agent might contain a specific JWT validation middleware pattern for Express v5. A notebook entry for Mika (designer) might contain a font pairing recommendation with rationale. A notebook entry for Atlas (devops) might contain a zero-downtime migration pattern for Supabase.
+
+Notebooks bridge the gap between abstract principles ("always validate JWTs") and concrete implementation ("here is the exact middleware code that handles edge cases in Express v5").
+
+## The NotebookEntry Schema
+
+Every notebook entry follows the `NotebookEntry` interface:
+
+```typescript
+interface NotebookEntry {
+  id: string;              // e.g., "nb-auth-pattern-001"
+  context: string;         // When to apply this snippet
+  snippet: string;         // The reusable code/knowledge
+  provenance: {            // Where this came from
+    source: 'lore' | 'manual' | 'transfer';
+    loreEntryId?: string;  // If promoted from lore
+    originProject?: string;
+    createdBy?: string;
+  };
+  appliedCount: number;    // Times applied in orchestration
+  confidence: number;      // 0.0-1.0
+  concepts: string[];      // Concept tags for retrieval
+  tags: string[];          // Classification tags
+  created: string;         // ISO date
+  updated: string;         // ISO date
+}
+```
+
+The `context` field describes *when* to apply the snippet — not what the snippet is, but the situation that calls for it. For example: "When setting up JWT validation middleware in an Express v5 application with async route handlers." This context is what the retrieval system matches against.
+
+The `snippet` field contains the actual knowledge — code, configuration, a procedure, or a detailed explanation. It should be directly usable, not abstract guidance.
+
+The `provenance` field tracks where the entry came from: `lore` (promoted from a lore entry), `manual` (written directly by a human or agent), or `transfer` (copied from another agent's notebook). This matters for trust: a lore-promoted entry with a link to the original session has higher credibility than a manually created one.
+
+The `appliedCount` tracks how often this entry has been used in orchestration. Entries are sorted by `appliedCount` descending — frequently-applied entries surface first.
+
+## Storage: Global vs Project
+
+Notebooks live in two locations:
+
+**Global notebooks** at `~/.paradigm/notebooks/{agent-id}/` travel with the agent across all projects. An entry about JWT validation patterns is useful regardless of which project the security agent joins. Global notebooks are stored in the user's home directory (ring 2), so they persist even if a project is deleted.
+
+**Project notebooks** at `.paradigm/notebooks/{agent-id}/` contain knowledge specific to one project. An entry about the specific authentication architecture of project X should not bleed into project Y. Project notebooks are committed to the repository so they are shared with the team.
+
+When loading entries, the system reads global first, then project. If the same entry ID exists in both locations, the **project version wins** (override pattern). This allows a project to customize an agent's global knowledge for its specific needs.
+
+Each entry is stored as an individual YAML file named `nb-{concept}.yaml` (or more precisely, `{entry-id}.yaml`). The `nb-` prefix and `.yaml` extension are enforced by the `NOTEBOOK_PREFIX` and `NOTEBOOK_EXT` constants in the notebook loader.
+
+## Bootstrapping: Canonical Sources vs Learning Loop
+
+Notebook entries come from two pipelines:
+
+**Canonical bootstrapping** — When an agent is first created, Loid (forge) or a human seeds its notebook with foundational entries. The security agent might be bootstrapped with entries for OWASP Top 10 patterns, JWT best practices, and RLS policy templates. This gives the agent useful knowledge on day one without needing to learn from experience.
+
+**Learning loop promotion** — Over time, journal entries and lore entries that prove valuable are promoted into notebook entries. The `promoteFromLore()` function takes a lore entry ID, extracts the symbols and content, and creates a notebook entry with `provenance.source: 'lore'` and a link to the original entry. Sensei (trainer) drives this promotion — reviewing agent performance, identifying high-value learnings, and curating them into notebook entries.
+
+The learning loop pipeline is more valuable over time because it captures *project-specific* and *team-specific* patterns that canonical sources cannot predict. A canonical JWT entry is generic. A learning-loop entry that captures "In this project, JWT refresh tokens use the sliding window pattern with 15-minute windows because the mobile app has intermittent connectivity" is specific and actionable.
+
+## How buildProfileEnrichment() Uses Notebooks
+
+During orchestration, `buildProfileEnrichment()` accepts an optional array of notebook entries. The orchestrator matches entries by concept against the task's relevant symbols and injects the **top 5 entries by concept match** into the agent's prompt:
+
+```typescript
+function buildProfileEnrichment(
+  profile: AgentProfile,
+  relevantSymbols: string[],
+  notebookEntries?: Array<{ context: string; snippet: string; concepts: string[] }>,
+  // ...
+): string {
+  // ...
+  if (notebookEntries && notebookEntries.length > 0) {
+    parts.push('## Relevant Notebook Entries');
+    for (const nb of notebookEntries.slice(0, 5)) {
+      parts.push(`### ${nb.context}`);
+      parts.push(`Concepts: ${nb.concepts.join(', ')}`);
+      parts.push('```');
+      const snippet = nb.snippet.length > 300
+        ? nb.snippet.slice(0, 300) + '...' : nb.snippet;
+      parts.push(snippet);
+      parts.push('```');
+    }
+  }
+}
+```
+
+Notice the `slice(0, 5)` — only the top 5 entries are injected. This is a deliberate budget constraint. Notebook entries consume prompt tokens. Injecting 50 entries would blow the context budget. The top 5 are selected by relevance (concept match) and sorted by `appliedCount` (most-used first).
+
+Snippets longer than 300 characters are truncated with `...`. This prevents a single large entry from consuming the entire notebook budget. If an entry's full snippet is needed, the agent can use `paradigm_notebook_search` to retrieve it.
+
+## 10 High-Signal Entries > 100 Low-Signal Ones
+
+The quality bar for notebook entries matters enormously. Consider the token economics: each entry consumes ~100-300 tokens in the prompt. Five entries consume ~500-1,500 tokens. If those entries are high-signal (directly relevant, battle-tested, frequently applied), they provide immense value — the agent starts the task with proven patterns instead of reinventing them.
+
+If those entries are low-signal (vague, generic, rarely applied), they waste 500-1,500 tokens on noise that might actually mislead the agent. Worse, low-quality entries can actively degrade performance by injecting irrelevant patterns that the LLM tries to apply inappropriately.
+
+The `appliedCount` sorting is the primary quality signal. An entry that has been applied 15 times across 8 sessions is empirically useful. An entry that was created once and never applied is speculative. The `confidence` score provides a secondary signal, especially for new entries that have not yet accumulated an applied count.
+
+Sensei's role as curator is critical: reviewing entries, pruning low-value ones, merging duplicates, and updating stale patterns. A well-maintained notebook with 10 entries is vastly more valuable than an unmaintained one with 100.
+
+## MCP Tools for Notebooks
+
+- `paradigm_notebook_add` — Add a new entry. Requires `agentId`, `context`, `snippet`, `concepts`, and `scope` (global or project).
+- `paradigm_notebook_search` — Search entries by query string across context, snippet, and concepts.
+- `paradigm_notebook_list` — List all entries for an agent, optionally filtered by concepts or tags.
+- `paradigm_notebook_promote` — Promote a lore entry into a notebook entry via `promoteFromLore()`.

package/dist/university-content/notes/N-para-701-agent-pods-nevrland.md

@@ -0,0 +1,182 @@
+---
+id: N-para-701-agent-pods-nevrland
+title: 'Lesson 10: Agent Pods & nevr.land'
+type: note
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+  - pods-are-named
+  - pods-are-registry
+  - nevrland-marketplace-enables
+symbols: []
+difficulty: beginner
+estimatedMinutes: 7
+prerequisites: []
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+---
+
+## The Pod Concept
+
+A pod is a named team preset — a curated group of agents optimized for a specific workflow. Instead of manually activating 8-15 agents for a common scenario, you activate a pod and get a pre-configured team.
+
+Pods are metadata about team composition, not modifications to agent behavior. Activating a pod adds agents to the roster; it does not change their personalities, expertise, or attention patterns. The agents in a "Ship Pod" are the same agents as when activated individually — the pod just saves the activation step.
+
+## Named Pods
+
+Several standard pods cover common workflows:
+
+**Ship Pod** — The core shipping team. Architect, builder, reviewer, tester, security, documentor. This is the minimum viable team for implementing and shipping a feature with quality gates.
+
+**Launch Pod** — Everything needed for a product launch. Ship Pod + designer (Mika), copywriter (Wren), seo (Beacon), performance (Bolt), e2e (Ghost). Covers UI, content, search visibility, performance testing, and end-to-end verification.
+
+**Growth Pod** — Business intelligence and growth team. Researcher (Scout), analyst (Sage), seo (Beacon), content-intel (Lens), product (North), pm (Yuki). Focused on market research, analytics, content strategy, and product direction.
+
+**Design Pod** — The visual and UX team. Designer (Mika), copywriter (Wren), a11y (Aria), creative (Prism), presenter (Stage). Covers UI design, copy, accessibility, creative direction, and presentation.
+
+**Infra Pod** — The platform team. Devops (Atlas), dba (Vault), sysadmin (Root), network (Wire), release (Ship), performance (Bolt). Focused on deployment, database, infrastructure, and reliability.
+
+**Quality Pod** — The quality assurance team. Reviewer, tester, e2e (Ghost), qa (Shield), advocate (Jinx), debugger (Trace), performance (Bolt). Covers code review, unit tests, end-to-end tests, test strategy, adversarial testing, debugging, and performance.
+
+Activating a pod via CLI:
+
+```bash
+# Activate all agents in the Ship Pod
+paradigm agents activate --pod ship-pod
+
+# Activate Design Pod on top of existing roster
+paradigm agents activate --pod design-pod
+
+# Multiple pods
+paradigm agents activate --pod ship-pod --pod infra-pod
+```
+
+Pods are additive — activating a pod adds its agents to the roster without removing existing ones. Activating Ship Pod and then Design Pod results in a roster containing both teams.
+
+## Pods Are Registry Metadata, Not Agent Behavior
+
+This distinction is critical. A pod definition is:
+
+```yaml
+id: ship-pod
+name: Ship Pod
+description: Core shipping team for implementing and delivering features
+agents:
+  - architect
+  - builder
+  - reviewer
+  - tester
+  - security
+  - documentor
+```
+
+It is a list of agent IDs. There is no behavioral modification, no special collaboration mode, no pod-specific prompts. The agents in the Ship Pod behave exactly as they do when activated individually. The pod is a convenience for roster management.
+
+This keeps the agent system simple. Agent behavior is defined in `.agent` files. Team composition is defined in `roster.yaml`. Pods are shortcuts for populating the roster. There is one system for behavior (profiles), one for composition (rosters), and one for convenience (pods). They do not overlap.
+
+## The nevr.land Marketplace
+
+While Paradigm ships 54 agents locally, the agent ecosystem is open. nevr.land (nevr.land) is the marketplace where agents can be published, discovered, and installed — like npm for AI agents.
+
+### Installing Agents
+
+```bash
+# Install a community agent
+paradigm agents install @paradigm/designer
+
+# Install from a specific publisher
+paradigm agents install @acme/compliance-auditor
+
+# Install and activate in one step
+paradigm agents install @paradigm/designer --activate
+```
+
+Installed agents are placed in `~/.paradigm/agents/` alongside the built-in agents. They follow the same `.agent` schema and participate in orchestration, attention scoring, and the learning loop identically to built-in agents.
+
+### Trust Levels
+
+Not all agents are equal. The marketplace uses three trust levels:
+
+| Trust Level | Meaning | Verification |
+|---|---|---|
+| **verified** | Published by the Paradigm team or a verified organization | Publisher identity confirmed, agent reviewed for quality and safety |
+| **community** | Published by a community member | Publisher identity confirmed, agent not reviewed |
+| **private** | Published to a private registry | Only accessible to the publisher's organization |
+
+Trust levels affect installation warnings and default permissions. A `verified` agent installs silently. A `community` agent shows a warning with the publisher's identity and a link to the source. A `private` agent requires authentication to the publisher's registry.
+
+Trust does NOT affect agent capabilities. A community agent can do everything a verified agent can do. Trust is about provenance ("who made this?"), not permissions.
+
+### Agent Package Format
+
+A published agent package contains three files:
+
+```
+@paradigm/designer/
+  agent.yaml      # The .agent profile (same schema as local agents)
+  notebooks/      # Bootstrapping notebook entries
+    nb-design-system-001.yaml
+    nb-typography-002.yaml
+    nb-color-theory-003.yaml
+  metadata.yaml   # Registry metadata
+```
+
+**agent.yaml** is the standard `.agent` file: id, nickname, role, personality, collaboration, expertise, attention, behaviors, transferable patterns. It follows the exact same schema used for local agents.
+
+**notebooks/** contains bootstrapping entries that give the agent useful knowledge on day one. A designer agent might ship with entries for typography scales, color theory, layout patterns, and accessibility guidelines. These are installed into `~/.paradigm/notebooks/{agent-id}/` as global entries.
+
+**metadata.yaml** contains registry-specific fields:
+
+```yaml
+name: "@paradigm/designer"
+version: "1.2.0"
+description: "Design engineer with deep knowledge of UI/UX theory"
+author: "Paradigm Team"
+license: "MIT"
+trust: verified
+tags: [design, ui, ux, accessibility, typography]
+compatibility:
+  paradigm: ">=5.0.0"
+  tiers: [tier-1, tier-2]  # Works with reasoning and balanced models
+downloads: 12847
+rating: 4.8
+```
+
+The `compatibility` field specifies which Paradigm version and model tiers the agent works with. An agent designed for tier-1 reasoning models may produce poor results on tier-3 fast models. The marketplace surfaces this information during installation.
+
+### Publishing
+
+Publishing an agent reverses the installation flow:
+
+```bash
+# Package and publish
+paradigm agents publish ~/.paradigm/agents/custom-agent.agent \
+  --notebooks ~/.paradigm/notebooks/custom-agent/ \
+  --trust community
+```
+
+The publish command validates the agent schema, packages the agent file and notebooks, and uploads to the nevr.land registry. Private publishing requires an organization token.
+
+## The Ecosystem Vision
+
+The progression from local to global follows a natural path:
+
+1. **Built-in agents** — Paradigm ships 54 agents covering standard development workflows.
+2. **Custom local agents** — Loid (forge) designs project-specific agents stored in `~/.paradigm/agents/`.
+3. **Team-shared agents** — Agent files in `.paradigm/agents/` (project-level) are committed to the repo and shared with the team.
+4. **Community agents** — Published to nevr.land for anyone to install.
+5. **Verified agents** — Reviewed and endorsed by the Paradigm team for quality and safety.
+
+Each level inherits the same agent system: `.agent` schema, notebooks, expertise tracking, attention patterns, learning loop. A community agent from nevr.land participates in orchestration, builds expertise through verdicts, and accumulates notebook entries exactly like a built-in agent. The only difference is provenance.
+
+## Future: Agent Registries as Infrastructure
+
+The nevr.land marketplace is the first implementation of a broader concept: agent registries. Organizations may run private registries for internal agents that should not be published publicly. Multiple registries can be configured in `~/.paradigm/config.yaml`, similar to how npm supports multiple registries.
+
+The agent package format (agent.yaml + notebooks/ + metadata.yaml) is intentionally simple to enable this. There is no compilation step, no binary format, no platform dependency. An agent package is human-readable YAML and can be inspected, forked, and modified before installation.
+
+This openness is a design principle: agents are knowledge, not code. They should be as shareable, forkable, and composable as npm packages. The trust system provides safety rails without restricting capability.

package/dist/university-content/notes/N-para-701-agent-profiles.md

@@ -0,0 +1,197 @@
+---
+id: N-para-701-agent-profiles
+title: 'Lesson 2: Agent Profiles Deep Dive'
+type: note
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+  - the-agent-file
+  - personality-style-risk
+  - collaboration-graph-defines
+symbols: []
+difficulty: beginner
+estimatedMinutes: 7
+prerequisites: []
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+---
+
+## The .agent File
+
+Every agent's identity lives in a `.agent` file stored at `~/.paradigm/agents/{id}.agent`. This is a YAML file that defines who the agent is: not just what it does, but how it thinks, who it works with, what it watches, and what it has learned. The `.agent` file is the complete specification of an agent's identity.
+
+## Core Identity Fields
+
+The top-level fields establish the agent's identity:
+
+```yaml
+id: security
+nickname: null              # Optional display name (e.g., "Jinx", "Mika")
+role: Security agent
+description: >-
+  Security specialist who audits auth flows, reviews gate implementations,
+  and hunts for vulnerabilities. He is the Portal/Gates champion.
+version: 1.0.0
+```
+
+`id` is the machine-readable identifier used in rosters, orchestration plans, and file paths. `nickname` is the optional human-friendly name displayed in attributed responses and Symphony threads (e.g., Mika for designer, Atlas for devops). `role` is a short description of the agent's function. `description` is a detailed paragraph that explains the agent's responsibilities, expertise boundaries, and what it does NOT do.
+
+The description is critically important because it is injected into the agent's prompt during orchestration. A vague description produces vague behavior. A precise description like "He flags issues but does NOT implement fixes — that's the Builder's job" creates a clear boundary.
+
+## Personality Configuration
+
+The `personality` block defines the agent's behavioral parameters:
+
+```yaml
+personality:
+  style: methodical        # How the agent approaches work
+  risk: conservative       # Risk tolerance for decisions
+  verbosity: detailed      # How much output the agent produces
+```
+
+**Style** options include `rapid` (moves fast, starts immediately), `deliberate` (thinks before acting, maps impact first), `methodical` (follows systematic processes), `analytical` (data-driven, evidence-based), `opinionated` (has strong views, will lead), `confrontational` (challenges everything), `patient` (takes time to understand context), `proactive` (anticipates needs, speaks up unprompted), `strategic` (thinks about long-term implications), and `meticulous` (leaves nothing unchecked).
+
+**Risk** values are `conservative` (prefers proven approaches, avoids experimentation), `balanced` (will take calculated risks with evidence), `moderate` (open to new approaches when justified), and `aggressive` (pushes boundaries, challenges the status quo).
+
+**Verbosity** values are `concise` (minimal output, just the essentials), `precise` (exact and specific, no filler), `detailed` (thorough explanations with context), and `thorough` (comprehensive coverage with examples and rationale).
+
+These values are not decorative. During orchestration, `buildProfileEnrichment()` injects them into the agent's prompt as `**Style:** methodical | **Risk:** conservative | **Verbosity:** detailed`. The LLM uses these parameters to calibrate its response style.
+
+## Collaboration Graph
+
+The `collaboration` block defines how the agent works with others:
+
+```yaml
+collaboration:
+  stance: advisory                   # Default relationship to other agents
+  pairs_well_with:
+    - architect: Security validates the architect's auth model and gate design
+    - devops: Atlas handles infra hardening, security handles app-layer auth
+    - builder: Security reviews builder's auth code before it ships
+  with:
+    architect:
+      stance: peer                   # Treat as equal, not subordinate
+      can_contradict: true           # Allowed to disagree with architect
+    builder:
+      stance: advisory               # Give guidance, not orders
+      review_output: true            # Review what builder produces
+  debate:
+    will_challenge: true             # Will push back on decisions
+    evidence_required: true          # Requires evidence to challenge
+    escalate_to_human: true          # Will ask the human to break ties
+  onboarding: >-
+    When joining a project, security:
+    1. Reads portal.yaml
+    2. Calls paradigm_gates_for_route on key routes
+    3. Checks Sentinel for auth-related events
+    4. Reviews auth middleware implementations
+    5. Identifies unprotected routes
+```
+
+The `stance` field defines the default relationship: `lead` (drives decisions), `advisory` (gives guidance), `support` (executes direction from leads), `peer` (equal footing), `challenger` (pushes back on everything). The `pairs_well_with` array lists productive agent pairings with explanations — these are surfaced during orchestration planning.
+
+The `debate` section controls disagreement behavior. Jinx (advocate) has `will_challenge: true` and `evidence_required: false` — she challenges instinctively. The security agent has `evidence_required: true` — it backs challenges with OWASP references and CVE data. The `onboarding` field is a step-by-step procedure the agent follows when it first encounters a project.
+
+## Expertise Tracking
+
+The `expertise` array tracks the agent's confidence on specific symbols:
+
+```yaml
+expertise:
+  - symbol: '#portal-gates'
+    confidence: 0.95            # 0.0-1.0
+    sessions: 12                # Times this agent worked on this symbol
+    lastTouch: '2026-03-24T11:30:00.000Z'
+  - symbol: '#auth-security'
+    confidence: 0.95
+    sessions: 8
+    lastTouch: '2026-03-24T11:30:00.000Z'
+```
+
+Confidence scores are not static. They adjust automatically based on user verdicts in the session work log: `+0.03` for accepted contributions, `-0.02` for dismissed ones, `-0.01` for revised ones. An agent that consistently gets security reviews accepted will see its `#auth-security` confidence rise over time. An agent whose suggestions are frequently dismissed will see confidence drop.
+
+The `sessions` count and `lastTouch` timestamp provide recency context. An agent with 50 sessions on `#payment-service` that last touched it yesterday has stronger expertise than one with 2 sessions from three months ago.
+
+## Attention Patterns
+
+The `attention` block defines what the agent notices in the event stream:
+
+```yaml
+attention:
+  symbols:
+    - ^*                      # All gate symbols
+    - '#*-auth'
+    - '#*-middleware'
+  paths:
+    - auth/**
+    - middleware/**
+  concepts:
+    - JWT
+    - RBAC
+    - injection
+    - CSRF
+  signals:
+    - type: gate-added
+    - type: route-created
+  threshold: 0.45
+```
+
+Attention patterns were covered in depth in PARA 601. The key point here is that they are part of the agent profile, not a separate system. The agent's identity (who it is) and its attention (what it notices) are defined in the same file.
+
+## Behaviors
+
+The `behaviors` block defines named behavior protocols the agent follows:
+
+```yaml
+behaviors:
+  portal-gates-mastery: >-
+    Security owns the portal.yaml gate model:
+    1. Every route that checks auth MUST have a corresponding ^gate
+    2. Use paradigm_gates_for_route to check gate coverage
+    3. Gates need prizes: [] (v2 requirement)
+  sentinel-security-monitoring: >-
+    Security uses Sentinel for threat detection:
+    - paradigm_sentinel_events to find auth failures
+    - paradigm_sentinel_patterns for security patterns
+  security-review-checklist: >-
+    Before approving auth-related code:
+    1. Check portal.yaml coverage
+    2. Verify JWT validation
+    3. Check for OWASP Top 10 vulnerabilities
+```
+
+Behaviors are injected into the agent's orchestration prompt. They are named so that other agents and humans can reference them ("use the security-review-checklist behavior"). They define step-by-step procedures that make the agent's actions predictable and auditable.
+
+## Transferable Patterns
+
+The `transferable` array contains patterns the agent has learned that apply across projects:
+
+```yaml
+transferable:
+  - pattern: gate-coverage-check
+    description: >-
+      Every new route gets paradigm_gates_for_route called on it.
+      No exceptions. If it returns no gates and the route modifies data,
+      that's a security violation.
+    successRate: 1.0
+    sessions: 0
+```
+
+Transferable patterns travel with the agent across projects. When the security agent joins a new project, it brings its `gate-coverage-check` pattern regardless of whether the previous project was a SaaS app or a CLI tool. Patterns with `successRate >= 0.7` are included in prompt enrichment; lower success rate patterns are excluded.
+
+## How Profiles Define WHO the Agent Is
+
+The `.agent` file is not a configuration file — it is an identity specification. It answers:
+
+- **Who am I?** — id, nickname, role, description, personality
+- **What do I know?** — expertise with confidence scores
+- **What do I notice?** — attention patterns and threshold
+- **How do I work with others?** — collaboration stance, pairings, debate rules
+- **How do I behave?** — named behavior protocols
+- **What have I learned?** — transferable patterns
+
+When the orchestrator invokes an agent, `buildProfileEnrichment()` assembles all of these fields into a prompt section that makes the LLM behave as that specific agent. The same base model (e.g., Claude Sonnet) becomes the security agent or the designer based entirely on the profile enrichment injected from the `.agent` file.