@a-company/paradigm 5.37.11 → 6.0.2

package/dist/university-content/notes/N-para-701-learning-feedback-loop.md

@@ -0,0 +1,188 @@
+---
+id: N-para-701-learning-feedback-loop
+title: 'Lesson 9: The Learning Feedback Loop'
+type: note
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+  - session-work-log
+  - auto-expertise-adjustment-003
+  - teacher-model-runs
+symbols: []
+difficulty: beginner
+estimatedMinutes: 6
+prerequisites: []
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+---
+
+## The Full Loop: DO-RECORD-ASSESS-LEARN-ADAPT-DO
+
+PARA 601 introduced the six-phase learning loop. In the context of the agent system, this loop operates at the agent level: each agent does work, records its contributions, receives verdicts, learns from the feedback, and adapts its behavior for the next session. The agent system provides the concrete mechanisms that make each phase work.
+
+## Phase 1: DO — Agent Work
+
+Agents perform work during orchestration. The builder writes code. The security agent reviews gates. The designer proposes UI patterns. Each contribution is captured in the session work log as an `agent-contribution` entry:
+
+```typescript
+interface SessionWorkEntry {
+  timestamp: string;
+  type: 'agent-contribution' | 'user-verdict' | 'decision';
+  agent?: string;
+  contribution?: string;
+  attribution?: string;
+  symbols?: string[];
+}
+```
+
+The session work log is stored at `.paradigm/events/session-log.jsonl` as append-only JSONL, bounded to 200 entries per session. Unlike breadcrumbs (which are recovery-focused with a 50-entry limit), the session work log captures rich context specifically for the learning pass.
+
+## Phase 2: RECORD — Verdict Capture
+
+When a human accepts, dismisses, or revises an agent's contribution, the verdict is recorded:
+
+```typescript
+{
+  type: 'user-verdict',
+  agent: 'security',
+  nominationId: 'nom-2026-03-24-001',
+  verdict: 'accepted' | 'dismissed' | 'revised' | 'deferred',
+  reason: 'Gate coverage recommendation was accurate',
+  symbols: ['^authenticated', '#payment-service'],
+  revisionDelta?: '...',  // What the human changed (for revised)
+}
+```
+
+Four verdict types capture the full range of human feedback:
+
+- **accepted** — The contribution was correct and applied as-is.
+- **dismissed** — The contribution was wrong or irrelevant.
+- **revised** — The contribution was partially correct; the human modified it. The `revisionDelta` captures what changed.
+- **deferred** — The contribution may be valid but is not relevant now.
+
+Each verdict is linked to the agent and the symbols involved, enabling per-symbol confidence tracking.
+
+## Phase 3: ASSESS — Auto-Expertise Adjustment
+
+When a verdict is recorded, the session work log automatically adjusts the agent's expertise confidence:
+
+```typescript
+const delta = entry.verdict === 'accepted' ? 0.03
+  : entry.verdict === 'dismissed' ? -0.02
+  : entry.verdict === 'revised' ? -0.01
+  : 0; // deferred = no change
+```
+
+This adjustment is asymmetric by design:
+
+- **+0.03 for accepted** — Positive reinforcement is slightly stronger than negative. This prevents a single bad review from tanking an otherwise reliable agent.
+- **-0.02 for dismissed** — A dismissed contribution means the agent was wrong. Confidence should decrease, but not catastrophically.
+- **-0.01 for revised** — A revised contribution was partially right. The penalty is smaller because the agent was in the right direction.
+- **0 for deferred** — Deferral says nothing about correctness, only timing. No confidence change.
+
+The adjustment is applied per-symbol. If the security agent's gate recommendation for `^authenticated` was accepted, its confidence on `^authenticated` increases by 0.03. Its confidence on unrelated symbols is unchanged.
+
+```typescript
+for (const symbol of entry.symbols!) {
+  const exp = profile.expertise!.find(e => e.symbol === symbol);
+  if (exp) {
+    exp.confidence = Math.max(0, Math.min(1, exp.confidence + delta));
+    exp.sessions = (exp.sessions || 0) + 1;
+    exp.lastTouch = new Date().toISOString();
+  }
+}
+```
+
+Confidence is clamped to `[0.0, 1.0]`. Sessions are incremented. The `lastTouch` timestamp is updated. This all happens as a fire-and-forget side effect of recording the verdict — the human never manually adjusts expertise scores.
+
+## Phase 4: LEARN — Teacher Model and Journal Entries
+
+At the end of an orchestration session, the Teacher Model runs a postflight learning pass. It reads the session work log, identifies patterns in the verdicts, and writes journal entries for each agent that participated:
+
+```yaml
+# Learning journal entry written by Teacher Model
+id: LJ-2026-03-24-001
+agent: security
+timestamp: '2026-03-24T16:00:00.000Z'
+trigger: human_feedback
+insight: >-
+  Security review of webhook endpoints should check for Stripe
+  signature verification, not just gate coverage. The human revised
+  the gate recommendation to include webhook-specific checks.
+project: dealoracle
+transferable: true
+confidence_before: 0.85
+confidence_after: 0.84
+pattern:
+  id: webhook-stripe-signature
+  applies_when: Reviewing webhook endpoints that receive Stripe events
+  correct_approach: Check for webhook signature verification in addition to gate coverage
+```
+
+The Teacher Model synthesizes verdict patterns into actionable journal entries. A single "revised" verdict becomes an insight about what the agent should do differently. The `trigger: human_feedback` records that this learning came from a human correction, not self-reflection.
+
+## Phase 5: ADAPT — Journal Promotion to Notebooks
+
+Journal entries that prove valuable over time are promoted into notebook entries by Sensei (trainer). The promotion pipeline:
+
+```
+Journal entry (agent-private) → Sensei reviews → 
+promoteFromLore() → Notebook entry (reusable snippet) → 
+buildProfileEnrichment() → Injected into future prompts
+```
+
+The key distinction: journal entries are raw learnings ("I was wrong about X because Y"). Notebook entries are distilled knowledge ("When doing X, use this pattern"). Sensei's job is to transform the former into the latter.
+
+Not every journal entry becomes a notebook entry. Sensei evaluates:
+- Is the insight transferable to other projects?
+- Is it actionable (specific enough to apply)?
+- Has the same insight appeared in multiple sessions (pattern confirmation)?
+- Is the confidence high enough to be reliable?
+
+## Phase 6: The Nomination Engine
+
+The nomination engine connects the learning loop to real-time project activity. As events flow through the event stream, each active agent scores them against their attention patterns:
+
+```
+Event (file-modified, gate-added, etc.)
+  ↓
+scoreEventForAgent(event, agentId, attention)
+  ↓
+AttentionScore { score, shouldNominate, breakdown }
+  ↓
+If shouldNominate → Create nomination
+  ↓
+Nomination surfaced in orchestration or paradigm_ambient_nominations
+```
+
+The nomination engine is the adaptive component: as an agent's attention patterns evolve (new concepts, adjusted thresholds), its nominations change. As its expertise confidence adjusts, its contributions become more or less influential. The system adapts based on empirical performance, not fixed rules.
+
+## The Complete Cycle
+
+Putting all six phases together for a single agent:
+
+```
+1. DO:     Security agent reviews webhook endpoint, flags missing gate
+2. RECORD: Human accepts the gate recommendation → verdict: accepted
+3. ASSESS: Security confidence on ^authenticated: 0.85 → 0.88 (+0.03)
+4. LEARN:  Teacher Model writes journal entry about webhook gate patterns
+5. ADAPT:  Sensei promotes journal → notebook entry for webhook security
+6. DO:     Next session, security agent starts with webhook pattern in
+           its prompt via buildProfileEnrichment(). It applies the pattern
+           without needing to rediscover it.
+```
+
+Each iteration through the loop makes the agent incrementally better. After 10 sessions with consistent feedback, the security agent's webhook review pattern is battle-tested, high-confidence, and automatically injected into every relevant orchestration. The human no longer needs to remind the agent about webhook-specific checks — the learning loop closed.
+
+## What Makes This Different
+
+Most AI systems have observation without adaptation. They log what happened but do not feed it back. Paradigm's agent system closes the loop through four mechanisms:
+
+1. **Per-symbol expertise tracking** — Confidence adjusts based on verdicts, not manual scoring
+2. **Asymmetric reinforcement** — +0.03/-0.02/-0.01 prevents a single bad session from destroying confidence
+3. **Teacher Model postflight** — Journal entries are written automatically, not relying on agents to self-reflect
+4. **Notebook promotion** — Insights become reusable patterns via Sensei, surfaced through buildProfileEnrichment()

package/dist/university-content/notes/N-para-701-model-tier-resolution.md

@@ -0,0 +1,204 @@
+---
+id: N-para-701-model-tier-resolution
+title: 'Lesson 6: Model Tier Resolution'
+type: note
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+  - three-capability-tiers
+  - model-resolution-config-block
+  - five-level-resolution-cascade
+symbols: []
+difficulty: beginner
+estimatedMinutes: 5
+prerequisites: []
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+---
+
+## The Platform Portability Problem
+
+Early Paradigm agent profiles specified `defaultModel: opus | sonnet | haiku` — Anthropic-specific model names hardcoded into each agent's configuration. This created four problems:
+
+1. **Platform lock-in** — These model names do not exist in Cursor, Windsurf, Copilot, or other IDEs. An agent profile designed for Claude Code breaks everywhere else.
+2. **Plan limitations** — Not every user has access to Opus. A developer on a Sonnet-only plan cannot use agents that request Opus without manual profile editing.
+3. **Provider assumptions** — The model names assume Anthropic. Users who want to use GPT-4o, Gemini, or local models through Ollama have no path.
+4. **Maintenance burden** — Model names were hardcoded in the orchestrator as `DEFAULT_MODELS`. Every time Anthropic ships a new model, someone has to update agent profiles.
+
+## The Solution: Capability Tiers
+
+Model tier resolution replaces specific model names with abstract **capability tiers** that describe what the agent needs, not which model to use:
+
+| Tier | Capability | Use Cases |
+|---|---|---|
+| `tier-1` (reasoning) | Complex analysis, multi-step planning | Architect, security audit, system design |
+| `tier-2` (balanced) | General coding, review, design | Reviewer, designer, most agent work |
+| `tier-3` (fast) | Simple tasks, documentation, bulk ops | Builder, tester, documentor |
+
+Agent profiles now specify `modelTier` instead of `defaultModel`:
+
+```yaml
+# Before (platform-locked)
+defaultModel: opus
+
+# After (platform-agnostic)
+modelTier: tier-1
+```
+
+The orchestrator maps tier requests to available models through a resolution table in the project configuration.
+
+## The model-resolution Config Block
+
+The `model-resolution` block in `.paradigm/config.yaml` maps tiers to actual model identifiers:
+
+```yaml
+# .paradigm/config.yaml
+model-resolution:
+  tier-1: claude-opus-4-6        # Best reasoning available
+  tier-2: claude-sonnet-4-6      # Balanced
+  tier-3: claude-haiku-4-5       # Fast/cheap
+```
+
+This is the single configuration point where model choices live. Changing all agent models is a 3-line edit. Different environments ship different defaults:
+
+```yaml
+# Claude Code (full Anthropic access)
+model-resolution:
+  tier-1: claude-opus-4-6
+  tier-2: claude-sonnet-4-6
+  tier-3: claude-haiku-4-5
+
+# Cursor (may not have Opus access)
+model-resolution:
+  tier-1: claude-sonnet-4-6
+  tier-2: claude-sonnet-4-6
+  tier-3: claude-haiku-4-5
+
+# OpenAI-only environment
+model-resolution:
+  tier-1: gpt-4o
+  tier-2: gpt-4o-mini
+  tier-3: gpt-4o-mini
+
+# Self-hosted / Ollama
+model-resolution:
+  tier-1: llama-3.1-70b
+  tier-2: llama-3.1-8b
+  tier-3: llama-3.1-8b
+
+# Budget-conscious
+model-resolution:
+  tier-1: claude-sonnet-4-6
+  tier-2: claude-sonnet-4-6
+  tier-3: claude-sonnet-4-6
+```
+
+The budget-conscious configuration demonstrates the power of tiers: you can run the full 54-agent orchestration system with Sonnet for everything by mapping all three tiers to the same model. The agents still have different personalities, expertise, and behaviors — the model tier only affects the underlying LLM capability.
+
+## Resolution Order
+
+When the orchestrator needs a model for an agent, it resolves through a five-level cascade:
+
+1. **Agent profile** — `modelTier` field (what the agent requests)
+2. **Project config** — `.paradigm/config.yaml` `model-resolution` block (project override)
+3. **Global config** — `~/.paradigm/config.yaml` `model-resolution` block (user preference)
+4. **IDE detection** — Auto-detect available models from environment variables (`CLAUDE_CODE`, `CURSOR_SESSION`, `WINDSURF_SESSION`)
+5. **Fallback** — Default to tier-2 (balanced) with the best available model
+
+```typescript
+function resolveModel(tier: ModelTier, config: ParadigmConfig): string {
+  return config.modelResolution?.[tier] ?? DEFAULTS[tier];
+}
+```
+
+The cascade ensures that agent preferences are respected when possible, project-level overrides take precedence over global preferences, and there is always a working fallback even if nothing is configured.
+
+## Environment Detection
+
+The system auto-detects the IDE environment to set sensible defaults:
+
+```typescript
+function detectEnvironment(): ModelResolution {
+  if (process.env.CLAUDE_CODE) {
+    return {
+      'tier-1': 'claude-opus-4-6',
+      'tier-2': 'claude-sonnet-4-6',
+      'tier-3': 'claude-haiku-4-5'
+    };
+  }
+  if (process.env.CURSOR_SESSION) {
+    return {
+      'tier-1': 'claude-sonnet-4-6',
+      'tier-2': 'claude-sonnet-4-6',
+      'tier-3': 'claude-haiku-4-5'
+    };
+  }
+  // Fallback: everything is tier-2
+  return {
+    'tier-1': 'claude-sonnet-4-6',
+    'tier-2': 'claude-sonnet-4-6',
+    'tier-3': 'claude-sonnet-4-6'
+  };
+}
+```
+
+Claude Code users get the full tier spread (Opus/Sonnet/Haiku). Cursor users get Sonnet for tier-1 because Opus may not be available in Cursor's model selection. Unknown environments get Sonnet for everything as a safe fallback.
+
+## Default Tier Assignments
+
+The orchestrator assigns default tiers to standard agent roles:
+
+```typescript
+const DEFAULT_TIERS: Record<string, ModelTier> = {
+  architect: 'tier-1',    // Complex planning and design
+  security: 'tier-1',     // Critical analysis, cannot miss vulnerabilities
+  reviewer: 'tier-2',     // Balanced evaluation
+  builder: 'tier-3',      // Fast implementation
+  tester: 'tier-3',       // Fast test writing
+  documentor: 'tier-3',   // Fast file maintenance
+};
+```
+
+Architect and security get tier-1 because their work requires deep reasoning (system design, vulnerability analysis). Builder, tester, and documentor get tier-3 because their work is more mechanical (implement this spec, write this test, update this .purpose file). Reviewer gets tier-2 as a balanced middle ground.
+
+These defaults can be overridden per-agent in the `.agent` file (`modelTier: tier-2`) or per-project in config.yaml.
+
+## Cost Estimation
+
+The orchestrator uses tier cost multipliers for budget estimation:
+
+```typescript
+const TIER_COST_MULTIPLIER = {
+  'tier-1': 3.0,    // ~$15/MTok for Opus
+  'tier-2': 1.0,    // ~$3/MTok for Sonnet (baseline)
+  'tier-3': 0.25,   // ~$0.80/MTok for Haiku
+};
+```
+
+The orchestration plan output includes cost estimates: "Estimated cost: $0.12 (tier-1: architect, tier-2: reviewer, tier-3: builder+documentor)". This transparency lets the human approve or modify the plan before execution.
+
+## Backward Compatibility
+
+The migration path preserves existing profiles:
+
+```yaml
+# Agent profile with both fields (transitional)
+defaultModel: opus      # Old field (deprecated, still read)
+modelTier: tier-1       # New field (preferred)
+```
+
+The resolution logic checks `modelTier` first. If only `defaultModel` exists, it maps: `opus` to `tier-1`, `sonnet` to `tier-2`, `haiku` to `tier-3`. This ensures existing agent profiles continue working without modification.
+
+## What This Enables
+
+Model tier resolution unlocks five capabilities:
+
+- **Budget control** — Map all tiers to Sonnet and run the full orchestration at Sonnet cost.
+- **Platform portability** — Same agents work in Claude Code, Cursor, Windsurf, and Copilot.
+- **Provider flexibility** — Swap to OpenAI, Gemini, or local models by changing 3 lines in config.
+- **Graceful degradation** — If the tier-1 model is unavailable, fall back to tier-2 automatically.
+- **Team consistency** — The entire team shares one `model-resolution` config block, not per-agent model names.

package/dist/university-content/notes/N-para-701-orchestration-enforcement.md

@@ -0,0 +1,169 @@
+---
+id: N-para-701-orchestration-enforcement
+title: 'Lesson 7: Orchestration Enforcement'
+type: note
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+  - three-seed-habits
+  - enforcement-uses-the
+  - nominations-surface-in
+symbols: []
+difficulty: beginner
+estimatedMinutes: 6
+prerequisites: []
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+---
+
+## Why Enforcement Matters
+
+Orchestration is powerful but optional. An agent can skip `paradigm_orchestrate_inline` and implement a 10-file feature solo, bypassing security review, missing test coverage, and producing no documentation updates. The feature ships, but quality degrades silently.
+
+Enforcement solves this by making orchestration the path of least resistance. Instead of hardcoding rules into agent logic ("always call the orchestrator"), enforcement works through Paradigm's habit system — three seed habits that nudge, warn, and track orchestration compliance.
+
+## The Three Orchestration Habits
+
+Paradigm seeds three habits specifically for orchestration enforcement:
+
+### 1. orchestration-required (preflight, warn)
+
+```typescript
+{
+  id: 'orchestration-required',
+  name: 'Orchestrate Complex Tasks',
+  description: 'Tasks affecting 3+ files or touching security symbols
+    should use paradigm_orchestrate_inline to determine which agents
+    are needed.',
+  category: 'collaboration',
+  trigger: 'preflight',
+  severity: 'warn',
+  check: {
+    type: 'tool-called',
+    params: { tools: ['paradigm_orchestrate_inline'] }
+  },
+  enabled: true,
+}
+```
+
+This habit fires at **preflight** (session start). It checks whether `paradigm_orchestrate_inline` was called. If not, and the task description suggests complexity (3+ files, security symbols), it emits a `warn` severity message: "This task may benefit from orchestration. Call paradigm_orchestrate_inline mode='plan' to see which agents are needed."
+
+The severity is `warn`, not `block`. This is deliberate. Blocking on orchestration would prevent quick fixes, hot patches, and simple tasks that genuinely do not need multi-agent coordination. The warning surfaces the recommendation; the human decides whether to follow it.
+
+### 2. agent-coverage-validated (postflight, advisory)
+
+```typescript
+{
+  id: 'agent-coverage-validated',
+  name: 'Validate Agent Involvement',
+  description: 'After completing work, verify that agents with relevant
+    expertise were consulted. Check nominations that were surfaced but
+    not acted on.',
+  category: 'collaboration',
+  trigger: 'postflight',
+  severity: 'advisory',
+  check: {
+    type: 'tool-called',
+    params: {
+      tools: ['paradigm_ambient_nominations', 'paradigm_agent_list']
+    }
+  },
+  enabled: true,
+}
+```
+
+This habit fires at **postflight** (before session end). It checks whether agent nominations were reviewed. If `paradigm_ambient_nominations` was not called, it advises: "There may be agent nominations you haven't reviewed. Run paradigm_ambient_nominations to check if any agents have relevant contributions."
+
+This catches the scenario where the orchestrator was bypassed but agents still self-nominated. The security agent may have noticed a new route without a gate, but if nobody checked nominations, the contribution is lost.
+
+### 3. hot-mode-incident (on-stop, advisory)
+
+```typescript
+{
+  id: 'hot-mode-incident',
+  name: 'Incident Response Acknowledgment',
+  description: 'During incident response, orchestration enforcement is
+    waived. But a post-incident lore entry is required and a postflight
+    review should be scheduled.',
+  category: 'collaboration',
+  trigger: 'on-stop',
+  severity: 'advisory',
+  check: { type: 'lore-recorded' },
+  enabled: true,
+}
+```
+
+This habit acknowledges that incidents are different. When production is down, you do not want a warning about calling the orchestrator. You want to fix the problem. This habit fires at **on-stop** and only checks that a lore entry was recorded. The rationale: during incidents, skip orchestration. After incidents, record what happened so the learning loop can process it.
+
+## The Nomination System
+
+Orchestration enforcement works hand-in-hand with the nomination system. When events flow through the event stream, each agent scores them against their attention patterns. Agents whose scores exceed their threshold self-nominate contributions.
+
+Nominations surface in two places:
+
+1. **During orchestration plan/execute** — The orchestrator includes pending nominations in the plan. If the security agent nominated a gate-coverage review, it appears in the orchestration plan's agent list with the nomination brief.
+
+2. **Via paradigm_ambient_nominations** — This MCP tool returns all pending nominations with their urgency, agent, and brief description. The `agent-coverage-validated` habit points agents here when orchestration was skipped.
+
+The nomination flow:
+
+```
+Event emitted → Each agent scores it → Score >= threshold → 
+Agent self-nominates → Nomination stored → 
+Surfaced in orchestration OR paradigm_ambient_nominations
+```
+
+## The Post-Write Hook Connection
+
+The post-write hook (which runs after every file edit) emits events into the event stream. These events trigger attention scoring across all active agents. If an agent's attention score exceeds its threshold, a nomination is created.
+
+The post-write hook itself does not enforce orchestration. It simply produces the events that feed the nomination engine. The enforcement comes from the habits that check whether nominations were reviewed.
+
+## Enforcement Through Habits, Not Hardcoded Logic
+
+This is a critical architectural decision. Orchestration enforcement is not baked into the orchestrator or the agent runtime. It lives in the habit system, which means:
+
+- **Configurable** — A project can disable `orchestration-required` by setting `enabled: false` in their habits override. A team that always orchestrates manually can turn off the nag.
+- **Tunable** — A project can change the severity from `warn` to `block` if they want strict enforcement. A project can change it to `advisory` if they want a softer touch.
+- **Extensible** — Teams can add custom orchestration habits. A habit that requires security review for any task touching `auth/**` files. A habit that requires documentation review for API changes.
+- **Transparent** — Habits are declared in YAML, visible in the project configuration, and evaluated at predictable trigger points (preflight, postflight, on-stop).
+
+The alternative — hardcoding orchestration requirements into the orchestrator itself — would be rigid, opaque, and impossible to customize per project. The habit system provides the same enforcement with full flexibility.
+
+## Habit Evaluation Context
+
+When habits are evaluated, the system provides an `EvaluationContext` that includes:
+
+```typescript
+interface EvaluationContext {
+  toolsCalled: string[];     // Which MCP tools were invoked
+  filesModified: string[];   // Which files were changed
+  symbolsTouched: string[];  // Which symbols were affected
+  loreRecorded: boolean;     // Whether a lore entry was written
+  hasPortalRoutes: boolean;  // Whether portal.yaml has routes
+  taskAddsRoutes: boolean;   // Whether the task added new routes
+  taskDescription?: string;  // The task description (for complexity analysis)
+  gitClean?: boolean;        // Whether the working tree is clean
+}
+```
+
+The `orchestration-required` habit checks `toolsCalled` for `paradigm_orchestrate_inline`. The `agent-coverage-validated` habit checks for `paradigm_ambient_nominations` or `paradigm_agent_list`. The `hot-mode-incident` habit checks `loreRecorded`.
+
+The evaluation produces a `HabitEvaluation` with three possible results: `followed` (the habit was satisfied), `skipped` (the habit was not satisfied), or `partial` (some conditions met, others not). Skipped habits with `warn` severity produce warnings; skipped habits with `block` severity prevent the session from completing.
+
+## Practical Workflow
+
+Here is how orchestration enforcement plays out in a typical session:
+
+1. Developer starts a task: "Add webhook support for Stripe events"
+2. **Preflight** — `orchestration-required` fires: "This task modifies auth-related symbols. Consider calling paradigm_orchestrate_inline."
+3. Developer calls `paradigm_orchestrate_inline mode='plan'` — the plan includes builder (implement), security (gate review), tester (write tests), documentor (update .purpose)
+4. Developer calls `paradigm_orchestrate_inline mode='execute'` — agents produce their outputs
+5. Work is done. **Postflight** — `agent-coverage-validated` fires: evaluates whether nominations were reviewed. Since orchestration was used, this passes.
+6. Session ends. **On-stop** — standard hooks check .purpose coverage, portal.yaml gates, etc.
+
+If step 3 was skipped (developer implemented solo), the postflight habit would advise reviewing `paradigm_ambient_nominations` to check for security or documentation contributions that were self-nominated by agents watching the event stream.