@nexus-cortex/cli 4.26.0

package/.cortex/agents/AGENT_PROFILE_GUIDE.md

@@ -0,0 +1,307 @@
+# Agent Profile Guide
+
+This guide covers how to create, configure, and use Task Agent profiles in Nexus Cortex.
+
+## Overview
+
+Task Agents are specialized sub-agents that can be spawned via the `Task` tool to handle complex, multi-step operations. Each agent is defined by a markdown file with YAML frontmatter configuration.
+
+## Directory Structure
+
+Agents are loaded from two locations:
+
+```
+.cortex/
+└── agents/             # Project-specific agents
+    ├── explore.md
+    ├── code-reviewer.md
+    └── test-writer.md
+
+~/.cortex/agents/       # Personal agents (shared across projects)
+    └── my-custom-agent.md
+```
+
+Project agents take precedence over personal agents with the same name.
+
+## Creating an Agent Profile
+
+### Basic Structure
+
+```markdown
+---
+name: agent-name
+description: Brief description of when to use this agent.
+tools:
+  - Read
+  - Write
+  - Grep
+model: sonnet
+---
+
+# Agent Title
+
+Your system prompt goes here. This defines the agent's personality,
+capabilities, and behavior guidelines.
+```
+
+### Frontmatter Schema
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `name` | string | Yes | Unique identifier (alphanumeric + hyphens, max 64 chars) |
+| `description` | string | Yes | When to use this agent (shown in tool description) |
+| `tools` | string[] or "all" | Yes | Allowed tools or "all" for unrestricted access |
+| `model` | string | Yes | Model alias or full ID, or "inherit" for parent's model |
+
+### Name Requirements
+
+- Alphanumeric characters and hyphens only
+- 1-64 characters
+- Must be unique within the same location (project/personal)
+- Case-sensitive
+
+Valid: `code-reviewer`, `test123`, `my-agent`
+Invalid: `Code Reviewer`, `test_writer`, `a-really-long-name-that-exceeds-the-maximum-allowed-length-of-64-characters`
+
+## Tool Configuration
+
+### Restricted Tool Access
+
+Specify which tools the agent can use:
+
+```yaml
+tools:
+  - Read     # Read files
+  - Glob     # Find files by pattern
+  - Grep     # Search file contents
+```
+
+The agent will only have access to these tools. Any attempt to use other tools will be blocked.
+
+### Full Tool Access
+
+For agents that need all capabilities:
+
+```yaml
+tools: all
+```
+
+**Warning**: Use `all` sparingly. Restricted tools improve safety and focus.
+
+### Available Tools
+
+Core file operations:
+- `Read` - Read file contents
+- `Write` - Create/overwrite files
+- `Edit` - Edit existing files
+- `Glob` - Find files by pattern
+- `Grep` - Search file contents
+
+Shell operations:
+- `Bash` - Execute shell commands
+- `BashOutput` - Get output from background shells
+- `KillShell` - Terminate shells
+
+Web operations:
+- `WebSearch` - Search the web
+- `WebFetch` - Fetch web pages
+
+Planning and UI:
+- `TodoWrite` - Manage task lists
+- `AskUserQuestion` - Ask user questions
+- `ExitPlanMode` - Exit plan mode
+
+Special:
+- `Task` - Spawn sub-agents (use carefully to avoid infinite loops)
+- `SlashCommand` - Execute slash commands
+- `Skill` - Use skills
+
+## Model Configuration
+
+### Model Aliases
+
+Use convenient aliases for common models:
+
+```yaml
+model: sonnet      # Claude Sonnet 4.5
+model: opus        # Claude Opus 4.1
+model: haiku       # Claude 3.5 Haiku
+model: gemini      # Gemini 2.5 Pro
+model: grok        # Grok 4.1 Fast
+model: deepseek    # DeepSeek Chat
+```
+
+### Full Model IDs
+
+Specify exact models:
+
+```yaml
+model: claude-sonnet-4-5-20250929
+model: gemini-2.5-flash
+model: gpt-4o
+```
+
+### Inherit Parent Model
+
+Use the same model as the parent session:
+
+```yaml
+model: inherit
+```
+
+### Available Aliases
+
+| Alias | Model |
+|-------|-------|
+| `sonnet`, `claude-sonnet`, `sonnet-4.5` | claude-sonnet-4-5-20250929 |
+| `opus`, `claude-opus`, `opus-4` | claude-opus-4-1-20250805 |
+| `haiku`, `claude-haiku`, `haiku-3.5` | claude-3-5-haiku-20241022 |
+| `gemini`, `gemini-pro`, `gemini-2.5` | gemini-2.5-pro |
+| `gemini-flash`, `flash` | gemini-2.5-flash |
+| `grok`, `grok-4`, `grok-fast` | grok-4.1-fast-reasoning |
+| `deepseek` | deepseek-v4-pro |
+| `reasoner` | deepseek-v4-pro |
+| `gpt4`, `gpt-4` | gpt-4.1 |
+| `o1`, `o3`, `o4-mini` | (OpenAI reasoning models) |
+
+## System Prompt Best Practices
+
+### Structure
+
+1. **Role definition** - What the agent is and does
+2. **Approach/methodology** - How the agent works
+3. **Guidelines** - Rules and constraints
+4. **Output format** - Expected response structure
+
+### Example
+
+```markdown
+---
+name: security-auditor
+description: Performs security audits on code, identifying vulnerabilities and suggesting fixes.
+tools:
+  - Read
+  - Glob
+  - Grep
+model: opus
+---
+
+# Security Auditor Agent
+
+You are a security expert specializing in application security.
+
+## Your Role
+
+Analyze code for security vulnerabilities including:
+- Injection attacks (SQL, Command, XSS)
+- Authentication/authorization flaws
+- Data exposure risks
+- Cryptographic weaknesses
+
+## Approach
+
+1. Read relevant files systematically
+2. Check for known vulnerability patterns
+3. Assess severity (Critical/High/Medium/Low)
+4. Provide remediation guidance
+
+## Output Format
+
+Report each finding as:
+
+### [Severity] [Vulnerability Type]
+**Location**: file:line
+**Description**: What the issue is
+**Impact**: What could happen
+**Remediation**: How to fix it
+```
+
+### Tips
+
+- **Be specific** - Clear instructions produce better results
+- **Include examples** - Show expected output format
+- **Define scope** - What should and shouldn't be done
+- **Set constraints** - Quality standards, safety rules
+
+## Using Agents
+
+### Via Task Tool
+
+The Task tool spawns agents:
+
+```
+Use the Task tool to spawn the code-reviewer agent with:
+- task: "Review the authentication module for security issues"
+- agent: "code-reviewer"
+```
+
+### Agent Selection
+
+The parent LLM selects agents based on the task and agent descriptions. Write clear descriptions to improve selection accuracy.
+
+### Monitoring
+
+Sub-agent events are streamed to the parent:
+- `agent:started` - Agent begins execution
+- `agent:progress` - Progress updates (tokens, turns)
+- `agent:tool_call` - Tool usage
+- `agent:text` - Output text
+- `agent:completed` - Execution complete
+- `agent:error` - Errors encountered
+
+## Advanced Configuration
+
+### Timeout Settings
+
+Configure via Task tool options (not in agent definition):
+
+```
+timeout: 300000  # 5 minutes (default)
+maxTurns: 10     # Maximum conversation turns
+```
+
+### Permission Inheritance
+
+Agents inherit permission policies from the parent session:
+- Parent's whitelist/blacklist policies apply
+- File operation restrictions are enforced
+- Bash command policies carry over
+
+Agents cannot exceed parent permissions, only further restrict them.
+
+## Troubleshooting
+
+### Agent Not Found
+
+Check:
+1. File is in `.cortex/agents/` or `~/.cortex/agents/`
+2. File has `.md` extension
+3. YAML frontmatter is valid
+4. Name matches file name (recommended)
+
+### Invalid Configuration
+
+Common issues:
+- Missing required field (`name`, `description`, `tools`, `model`)
+- Invalid tool name (check spelling, case-sensitive)
+- Invalid model alias (check available aliases)
+- Invalid name format (special characters)
+
+### Agent Errors
+
+Check the agent:error event for details. Common causes:
+- Tool restrictions blocking required operations
+- Model API errors
+- Timeout exceeded
+- Invalid system prompt
+
+## Example Agents
+
+See the other files in this directory for complete examples:
+
+- `explore.md` - Fast codebase exploration
+- `code-reviewer.md` - Code review
+- `test-writer.md` - Test generation
+- `doc-writer.md` - Documentation
+- `refactor.md` - Code refactoring
+- `plan.md` - Implementation planning

package/.cortex/agents/README.md

@@ -0,0 +1,268 @@
+# Agent Dispatch Modes — Nexus Cortex
+
+This directory contains Task Agent profiles. The orchestrator spawns agents via `child_process.fork()` when the LLM calls the `Task` tool. Agents run as independent processes with their own orchestrator instance, tools, and session.
+
+## Quick Reference
+
+| Mode | Agents | Communication | Workspace | Trigger |
+|------|--------|--------------|-----------|---------|
+| **Solo** | 1 | None | Shared | 1 Task tool call |
+| **Parallel** | N | None | Shared | N Task tool calls in same turn |
+| **Team** | N | Briefing + Broadcasting | Shared | N Task calls (auto-detected) |
+| **Git Worktree** | N | Briefing + Broadcasting | Isolated per agent | WorkspaceManager + N Task calls |
+
+---
+
+## Mode 1: Solo Agent
+
+A single Task tool call spawns one agent. The agent runs independently, completes its work, and returns results to the orchestrator.
+
+### When to Use
+- Focused single-domain tasks (code review, exploration, test writing)
+- Tasks that don't benefit from parallelization
+
+### Usage
+
+```bash
+# Via cortex CLI — model dispatches a solo agent internally
+cortex --quiet "Review packages/core/src/orchestrator/APIClient.ts for security issues"
+
+# Via API
+curl -s http://localhost:4000/v1/messages \
+  -H "Content-Type: application/json" \
+  -d '{"messages":[{"role":"user","content":"Use the code-reviewer agent to review APIClient.ts"}]}'
+```
+
+### How It Works
+1. LLM calls Task tool with agent name and prompt
+2. Orchestrator spawns child process via `SubAgentProcessManager.spawnAgent()`
+3. Agent runs with its own tools, model, and system prompt (from `.cortex/agents/{name}.md`)
+4. IPC events stream back: tool calls, text, progress, completion
+5. Agent result returned as tool_result to parent LLM
+
+---
+
+## Mode 2: Parallel Agents
+
+Multiple Task tool calls in the same LLM response are dispatched simultaneously via `Promise.all`. Agents run independently with no communication between them.
+
+### When to Use
+- Independent tasks that can run concurrently
+- Multiple searches or analyses that don't need to share findings
+- Speed-critical workflows where wall-clock time matters
+
+### Usage
+
+```bash
+# The model decides to parallelize based on the prompt
+cortex --quiet "Search for all usages of deprecated API patterns AND check test coverage for the auth module"
+
+# Explicit multi-agent dispatch
+cortex --quiet "Use 3 parallel explore agents to search for: (1) all WebSocket code, (2) all authentication middleware, (3) all rate limiting logic"
+```
+
+### How It Works
+1. LLM emits N Task tool calls in a single response
+2. `handleToolCalls()` in orchestrator separates Task tools from regular tools
+3. All N agents spawned simultaneously via `Promise.all`
+4. Each agent runs independently — no shared state or communication
+5. All results collected and returned to parent LLM
+
+---
+
+## Mode 3: Team Agents
+
+When the orchestrator detects >1 Task tools in the same response, it automatically activates team mode. Each agent receives a **team briefing** prepended to its prompt, and when any agent completes, its findings are **broadcast** to still-running siblings.
+
+### When to Use
+- Tasks where agents benefit from knowing about each other's work
+- PR review (security + quality + architecture agents share findings)
+- Any parallel dispatch where cross-pollination of results adds value
+
+### Usage
+
+```bash
+# PR review — dispatches 3 audit agents as a team
+cortex --pr review owner/repo 42
+
+# Custom team dispatch
+cortex --quiet "Dispatch a team of 3 agents: one to review security, one to review performance, one to check test coverage for the auth refactor"
+
+# Via API
+curl -s http://localhost:4000/v1/messages \
+  -H "Content-Type: application/json" \
+  -d '{"messages":[{"role":"user","content":"Use parallel agents to review the auth module. Dispatch pr-security-auditor, pr-code-quality, and pr-architecture-reviewer as a team."}]}'
+```
+
+### How It Works
+1. LLM emits N Task tool calls in a single response
+2. `handleToolCalls()` detects N > 1, calls `injectTeamBriefing()`
+3. Each agent's prompt gets prepended with:
+   ```
+   📋 **Team Briefing**
+   You are part of a {N}-agent team working in parallel.
+
+   Teammates:
+   - {agent-1}: {assignment}
+   - {agent-2}: {assignment}
+
+   The orchestrator will forward relevant findings from teammates.
+   Focus on YOUR assignment. Do not duplicate others' work.
+   ```
+4. Agents run in parallel
+5. When Agent A completes, `broadcastGuidance()` sends summary to Agents B, C
+6. Running agents receive guidance via IPC → `injectGuidance()` → ephemeral `<system-reminder>` or thinking block
+7. All results collected and returned to parent LLM
+
+### Cross-Agent Communication Path
+```
+Agent A completes
+  → SubAgentProcessManager.broadcastGuidance(summary, excludeAgentA)
+    → IPC message type 'guidance' sent to Agent B, C
+      → agent-mode.ts handler pushes to pendingGuidance[]
+        → orchestrator.injectGuidance(message, 'team_update')
+          → injectThinkingBlock() dual-path:
+              Google: thinking block
+              Others: <system-reminder> tag
+```
+
+---
+
+## Mode 4: Git Worktree (Isolated Workspace)
+
+Combines team mode with per-agent git worktree isolation. Each agent works in its own branch and directory, preventing file conflicts. The `WorkspaceManager` tool manages the worktree lifecycle.
+
+### When to Use
+- Multiple agents editing the same codebase simultaneously
+- PR implementation with parallel feature branches
+- Multi-repo operations (clone external repos for each agent)
+- Any scenario where agents might create conflicting file changes
+
+### Usage
+
+```bash
+# Internal development — multiple agents on different features
+cortex --quiet "Use WorkspaceManager to create 2 worktrees (branch auth-refactor and branch api-cleanup), then dispatch pr-implementer agents to each worktree with specific tasks"
+
+# External PR — clone and review
+cortex --pr review external-org/repo 42
+
+# Multi-repo workflow
+cortex --quiet "Clone owner/upstream-lib into a worktree AND create a local worktree for this repo's changes. Dispatch agents to update shared types in both."
+```
+
+### How It Works
+1. LLM calls `WorkspaceManager` tool to create worktrees:
+   - `create` mode: `git worktree add /tmp/workspace-{id} -b {branch}`
+   - `clone` mode: `git clone {repo} /tmp/repo-{id}` then worktree
+2. WorkspaceManager returns structured JSON with worktree paths
+3. LLM includes worktree paths in Task prompts for each agent
+4. Team briefing includes workspace paths for each teammate
+5. Each agent operates in its isolated worktree
+6. After agents complete, LLM can:
+   - `diff` mode: See what each agent changed
+   - `cleanup` mode: Remove worktrees
+
+### WorkspaceManager Modes
+
+| Mode | Command | Returns |
+|------|---------|---------|
+| `create` | `git worktree add /tmp/workspace-{id} -b {branch}` | worktree path |
+| `clone` | `git clone {repo}` + `git worktree add` | worktree path |
+| `status` | `git worktree list` | all active worktrees |
+| `diff` | `git -C {path} diff {base}` | diff content |
+| `cleanup` | `git worktree remove {path}` | confirmation |
+
+---
+
+## Visual Monitoring (Optional)
+
+Set `AGENT_TMUX_MONITOR=true` to enable tmux pane monitoring for parallel agents.
+
+```bash
+# Enable monitoring
+AGENT_TMUX_MONITOR=true cortex --quiet "Dispatch 3 parallel agents..."
+
+# View in browser
+open http://localhost:4001/tmux/team-{dispatchId}
+
+# Attach in terminal
+tmux attach -t team-{dispatchId}
+```
+
+Each agent gets its own tmux pane showing live IPC events:
+- `🔧 Read /path/to/file` — tool calls
+- Agent text output
+- `Turn 3 | 5.2K tokens | 12.3s` — progress
+- `✅ Done: {summary}` — completion
+- `❌ Error: {message}` — errors
+
+---
+
+## Agent Profiles in This Directory
+
+### General Purpose
+| Agent | Model | Tools | Use Case |
+|-------|-------|-------|----------|
+| `explore` | inherit | Read, Glob, Grep | Fast codebase exploration |
+| `code-reviewer` | inherit | Read, Grep, Glob | Code review with findings |
+| `test-writer` | inherit | Read, Write, Edit, Bash, Grep, Glob | Test generation |
+| `doc-writer` | inherit | Read, Write, Edit, Glob, Grep | Documentation |
+| `refactor` | inherit | Read, Write, Edit, Bash, Grep, Glob | Code refactoring |
+| `plan` | inherit | Read, Glob, Grep | Implementation planning |
+| `context-research` | inherit | Read, Grep, Glob, WebSearch, WebFetch | Research with web access |
+
+### PR Review Team
+| Agent | Model | Tools | Role in Team |
+|-------|-------|-------|-------------|
+| `pr-security-auditor` | inherit | Grep, Read, Bash | Scan for vulnerabilities, malicious code, supply chain risks |
+| `pr-code-quality` | inherit | Read, Grep, Glob | Review style, complexity, anti-patterns, test gaps |
+| `pr-architecture-reviewer` | inherit | Read, Grep, Glob, Bash | Breaking changes, API surface, dependency impact |
+| `pr-implementer` | inherit | Read, Edit, Write, Bash, Grep, Glob | Implement code changes in git worktree |
+| `pr-test-writer` | inherit | Read, Write, Edit, Bash, Grep, Glob | Write tests for PR changes |
+
+### Specialized
+| Agent | Model | Tools | Use Case |
+|-------|-------|-------|----------|
+| `new-model-api-integrator-analyst` | inherit | all | Analyze new AI provider APIs for integration |
+| `a-frontend-landing-page-designer` | inherit | all | Design frontend interfaces |
+
+---
+
+## Creating a New Agent
+
+See `AGENT_PROFILE_GUIDE.md` for the full guide. Quick version:
+
+```markdown
+---
+name: my-agent
+description: Brief description of when to use this agent.
+tools:
+  - Read
+  - Write
+  - Grep
+model: inherit
+---
+
+# My Agent
+
+System prompt defining the agent's role, approach, and output format.
+```
+
+**Required fields**: `name`, `description`, `tools`, `model`
+**Model options**: `inherit` (parent's model), aliases (`sonnet`, `opus`, `haiku`, `grok`), or full IDs
+**Tools**: Array of tool names or `all` for unrestricted access
+
+---
+
+## Troubleshooting
+
+| Issue | Fix |
+|-------|-----|
+| Agent not found | Check `.cortex/agents/{name}.md` exists with valid YAML frontmatter |
+| Team briefing not appearing | Ensure >1 Task tools in same LLM response |
+| WorkspaceManager branch conflict | `git branch -D {branch}` to clean stale branches |
+| Guidance not received | Check agent-mode.ts guidance handler, verify IPC is connected |
+| Tmux monitoring not working | Verify `tmux` binary available, `AGENT_TMUX_MONITOR=true` |
+| PR commands failing | Verify `gh auth status` — gh CLI must be authenticated |
+| Model not found errors | Use registered model IDs (check `cortex --list-models`) |

package/.cortex/agents/a-frontend-landing-page-designer.md

@@ -0,0 +1,41 @@
+---
+name: landing-page-designer
+description: A frontend landing page designer for rich beautiful landing pages
+tools:
+  - read
+  - write
+  - edit
+  - glob
+  - grep
+  - bash
+  - web_fetch
+model: gpt-5-mini
+---
+
+# a-frontend-landing-page-designer
+
+## Your Role
+
+You are a specialized A frontend landing page designer for rich beautiful landing pages agent.
+
+## Context from User
+
+A frontend landing page designer for rich beautiful landing pages HTML/CSS,. js, and tailwind it should focus on easily extendable frameworks
+
+## Responsibilities
+
+- Understand and fulfill requests related to A frontend landing page designer for rich beautiful landing pages
+- Use available tools effectively to accomplish tasks
+- Provide clear explanations of your actions
+- Ask for clarification when requirements are ambiguous
+
+## Guidelines
+
+- Be thorough and methodical in your approach
+- Focus on quality and correctness
+- Explain your reasoning when making decisions
+- Follow best practices for the domain
+
+## Output Format
+
+Provide clear, well-structured output appropriate to the task.

package/.cortex/agents/autoresearch-agent.md

@@ -0,0 +1,49 @@
+---
+name: autoresearch-agent
+description: Runs one auto-research experiment cycle on a single backlog deficiency — fix in an isolated worktree, measure base-vs-candidate through the statistical gate, and report a verified candidate. One of N the PM spawns per deficiency.
+tools:
+  - read
+  - write
+  - edit
+  - glob
+  - grep
+  - bash
+  - research_backlog
+  - workspace_manager
+model: deepseek-v4-flash
+---
+
+# Auto-Research Agent
+
+You are ONE of several auto-research agents the PM spawned on the **same** backlog deficiency. Your job: produce one candidate improvement and measure whether it is a REAL, verified improvement — then report. You do **not** merge anything yourself; the PM arbitrates across all agents and merges the verified winner.
+
+## Read your task first
+Your prompt contains:
+- The **deficiency** (what to improve) and how it's measured (task-set / metric).
+- An **EXECUTION MODE**: `native` or `mcp`.
+- Your **strategy flavor** (e.g. conservative vs aggressive fix, a specific hypothesis). You are one of N varied arms — stay in your lane so the arms stay diverse.
+
+## Operating rules — read before you start
+- **If it is NOT measurable, FAIL FAST.** If the deficiency has no eval / repro / task-set you can run a base-vs-candidate measurement against, do NOT explore the codebase indefinitely. Within a few turns, set the deficiency `wont_fix` with the note "not measurable — needs a benchmark task-set/eval" and STOP. A long fruitless search is worse than an honest early bail.
+- **Turn budget.** Reach a runnable experiment within ~15 turns. If you cannot, stop and report what is blocking (no metric, no repro, can't locate the code) — do not burn the whole budget searching.
+- **Follow YOUR assigned strategy.** Pursue the persona/strategy in your prompt; do NOT converge on the same path as the other arms. If every arm does the same thing, the parallelism is wasted.
+- **Always update the backlog before finishing** — `fixed`, `verified`, or `wont_fix` with a note. Never leave the deficiency `in_progress` and walk away.
+
+## EXECUTION MODE: native  (use the internal tools)
+1. **`ResearchBacklog`** → `next` / confirm the deficiency; `in_progress` to claim it (use the experiment tag from your prompt).
+2. **`WorkspaceManager`** → create an isolated **candidate worktree** off the base ref. NEVER edit the user's working tree.
+3. **Apply your fix** in the worktree. Either run the headless Fixer — `cortex autoresearch fix --cwd <worktree> --prompt "<deficiency + your strategy>"` via Bash — or edit directly with Read/Edit/Write. Then commit it (`git -C <worktree> add -A && git -C <worktree> commit -m "..."`).
+4. **Measure**: `cortex autoresearch experiment --experiment-tag <tag> --base-dir <base> --candidate-dir <worktree> --task-set <tasks> [--holdout-set <holdout>] --json` via Bash. (Add `--run-cmd '<eval>'` for a non-cortex target.)
+5. **Read the JSON verdict**: `decision` (keep/discard), `effect`, `mergeEligible` (keep + FWER + holdout-verified).
+6. **`ResearchBacklog`** → `fixed` (passed the discovery task) or — only after a holdout confirms — `verified`. Never `verified` on train alone.
+
+## EXECUTION MODE: mcp  (offload to the hosted harness)
+Use the configured **auto-research MCP** tools instead of the internal CLI: submit the experiment, poll its status, read the verdict. Do **not** run the local `cortex autoresearch` CLI in this mode — the MCP server runs it for you in its container.
+
+## Discipline (do not break these)
+- **fixed ≠ verified.** A candidate that only passes the task that surfaced the deficiency is `fixed`, NOT verified. Only a HELD-OUT confirmation makes it `verified`.
+- **Do not self-merge.** Report your candidate ref + its verdict; the PM applies the cross-arm gate and merges the single winner. With N parallel arms, some clear the bar by chance — central arbitration is what keeps that honest.
+- **Stay isolated.** All work in your own worktree off the base ref; never touch the user's branch or working tree.
+
+## Report back
+Return: your candidate ref, the verdict JSON (`decision` / `effect` / `mergeEligible`), what you changed, and whether it is holdout-verified. Keep it tight — the PM is comparing N of these.