@accelerationguy/accel 1.0.0

package/modules/radar/src/domains/12-team-risk.md

@@ -0,0 +1,221 @@
+---
+id: domain-12
+number: "12"
+name: Team Ownership & Knowledge Risk
+owner_agents: [staff-engineer]
+---
+
+## Overview
+
+Team Ownership & Knowledge Risk evaluates the human sustainability of a codebase through authorship patterns, knowledge distribution, and collaborative practices. This domain identifies single points of failure in team knowledge, documentation gaps, and cultural risks around code review and ownership transitions. Systems fail socially before they fail technically—concentrated knowledge creates organizational fragility regardless of code quality. This domain does NOT cover code health metrics (domain 09), change impact analysis (domain 11), or risk synthesis across domains (domain 13).
+
+## Audit Questions
+
+- What is the bus factor for each critical module, and which components have single-author dependency?
+- Where is tribal knowledge concentrated, and what documentation exists to mitigate knowledge loss?
+- How many modules have no active maintainer or have been abandoned by their original authors?
+- What percentage of changes receive meaningful code review, and what is the review-to-approval time distribution?
+- Which subsystems have high author concentration (Gini coefficient >0.7), indicating knowledge silos?
+- How many critical components lack comprehensive documentation or have documentation older than the code?
+- What is the onboarding time for new contributors to become productive in each major subsystem?
+- Are there modules where only one person has committed in the last 6 months?
+- How consistent are review standards across teams, and are there bypassed review requirements?
+- What percentage of commits include documentation updates, and what is the documentation debt ratio?
+- How many knowledge transfer events have occurred in the past year (pairing sessions, design reviews, runbooks)?
+- Which components have the longest time-to-first-external-contribution, indicating high entry barriers?
+
+## Failure Patterns
+
+### Single-Author Modules
+- **Description:** Critical components where >80% of commits come from a single author, creating extreme bus factor risk and knowledge bottlenecks that threaten continuity.
+- **Indicators:**
+  - Author concentration Gini coefficient >0.8 for modules with >1000 LOC
+  - No commits from secondary authors in the last 90 days
+  - Module fails to build or deploy when primary author is unavailable
+  - Onboarding documentation explicitly references "ask [person]" for critical knowledge
+- **Severity Tendency:** high
+
+### Knowledge Silos
+- **Description:** Teams or subsystems where knowledge is concentrated within small groups with no cross-pollination, creating organizational fragility and collaboration barriers.
+- **Indicators:**
+  - <3 people have committed to a subsystem in the last 180 days
+  - No cross-team code review activity in shared interfaces
+  - Design decisions documented in private channels or not at all
+  - New team members require >30 days to make first meaningful contribution
+- **Severity Tendency:** high
+
+### Missing Code Review Culture
+- **Description:** Significant percentage of changes merged without peer review, bypassing quality gates and knowledge sharing opportunities that prevent defects and spread understanding.
+- **Indicators:**
+  - >20% of commits pushed directly to main branch without PR
+  - Average review-to-approval time <10 minutes, indicating rubber-stamp reviews
+  - PRs with >500 LOC changes approved with zero comments
+  - Review bypass patterns during "crunch time" or by senior engineers
+- **Severity Tendency:** medium
+
+### Documentation Debt
+- **Description:** Critical components lack current documentation, or documentation age significantly exceeds code age, creating barriers to understanding and maintenance.
+- **Indicators:**
+  - >40% of modules have no README or design documentation
+  - Documentation last-modified date >12 months older than latest code changes
+  - Onboarding requires >10 questions to senior engineers about undocumented subsystems
+  - Zero runbooks or operational guides for production systems
+- **Severity Tendency:** medium
+
+### Tribal Knowledge Dependencies
+- **Description:** Essential operational knowledge exists only in human memory or private notes, not in accessible artifacts, creating catastrophic failure risk when key people depart.
+- **Indicators:**
+  - Deployment procedures exist only as Slack messages or verbal instructions
+  - Critical configuration parameters documented in personal notes or wikis with access restrictions
+  - Incident response requires specific individuals with undocumented mental models
+  - "Oral tradition" references in team communication about how systems actually work
+- **Severity Tendency:** critical
+
+### Abandoned Code Ownership
+- **Description:** Modules with no clear current owner, where the original author has left or moved on, creating accountability gaps and maintenance neglect.
+- **Indicators:**
+  - CODEOWNERS file missing or >50% entries reference departed team members
+  - Zero commits to module in last 180 days despite open bug reports
+  - Pull requests to module sit unreviewed for >30 days
+  - Module excluded from refactoring or upgrade initiatives due to "no one understands it"
+- **Severity Tendency:** high
+
+### Inconsistent Review Standards
+- **Description:** Different teams or individuals apply wildly different review rigor, creating quality variance and cultural friction that undermines trust in the review process.
+- **Indicators:**
+  - Reviewer X approves 95% of PRs within 5 minutes; Reviewer Y averages 45 minutes with detailed feedback
+  - Some teams require 2+ approvals; others allow single-approval merge
+  - Security/performance issues caught in production that were visible in reviewed PRs
+  - Team retrospectives mention "review lottery" or reviewer shopping behavior
+- **Severity Tendency:** medium
+
+## Best Practice Patterns
+
+### Distributed Ownership
+- **Replaces Failure Pattern:** Single-Author Modules
+- **Abstract Pattern:** Critical components maintained by 3+ active contributors with balanced commit distribution, ensuring knowledge redundancy and sustainable maintenance through collaborative stewardship.
+- **Framework Mappings:**
+  - GitHub CODEOWNERS: Require 2+ reviewers from different teams for protected modules
+  - GitLab Code Owners: Use group-based ownership with mandatory secondary reviewers
+  - Azure DevOps: Configure branch policies requiring multi-team approval for critical paths
+- **Language Patterns:**
+  - Microservices (any language): Rotate on-call ownership quarterly to spread operational knowledge
+  - Monorepo (TypeScript/Go): Use package-level CODEOWNERS with explicit fallback reviewers
+  - Infrastructure (Terraform/Kubernetes): Require platform team + product team dual approval
+
+### Cross-Team Knowledge Sharing
+- **Replaces Failure Pattern:** Knowledge Silos
+- **Abstract Pattern:** Scheduled knowledge transfer activities, cross-team pairing rotations, and shared documentation practices that build organizational resilience through deliberate knowledge distribution.
+- **Framework Mappings:**
+  - Team Topologies: Implement "community of practice" groups for shared technical domains
+  - Spotify Model: Host guild meetings for architecture, security, and operations knowledge sharing
+  - DevOps: Embed SRE engineers with product teams for bidirectional knowledge flow
+- **Language Patterns:**
+  - Backend teams: Monthly architecture deep-dives with rotation presenters from different teams
+  - Frontend teams: Shared component library ownership with contribution guidelines requiring cross-team review
+  - Data teams: Weekly data model review sessions with product and engineering representation
+
+### Rigorous Review Process
+- **Replaces Failure Pattern:** Missing Code Review Culture
+- **Abstract Pattern:** Mandatory peer review with clear standards, review checklists, and metrics tracking review quality, ensuring every change receives thoughtful scrutiny before integration.
+- **Framework Mappings:**
+  - GitHub: Use required reviewers, status checks, and review assignment automation (CODEOWNERS)
+  - GitLab: Configure approval rules with eligible approvers and required approval count
+  - Gerrit: Enforce verified+2 from CI and code-review+2 from human before submit
+- **Language Patterns:**
+  - Pull request templates: Include security checklist, test coverage requirements, and breaking change assessment
+  - Review bots: Automate size limits (<400 LOC), test coverage gates (>80%), and documentation checks
+  - Review guidelines: Publish standards for response time (24h), approval criteria, and constructive feedback tone
+
+### Living Documentation
+- **Replaces Failure Pattern:** Documentation Debt
+- **Abstract Pattern:** Documentation colocated with code, updated in the same commits as implementation changes, with CI enforcement and regular audits to maintain accuracy and relevance.
+- **Framework Mappings:**
+  - Docs-as-code: Markdown in repository, versioned with code, published via CI (Docusaurus, MkDocs, Sphinx)
+  - ADR (Architecture Decision Records): Lightweight decisions in docs/adr/ directory, numbered and immutable
+  - README-driven development: Write README before implementation, update in same PR as code changes
+- **Language Patterns:**
+  - Rust: Use `cargo doc` with enforced `#![warn(missing_docs)]` for public APIs
+  - TypeScript: Generate API docs from TSDoc comments via TypeDoc, published automatically
+  - Python: Maintain Sphinx documentation with docstring coverage >90%, checked in CI
+
+### Explicit Knowledge Capture
+- **Replaces Failure Pattern:** Tribal Knowledge Dependencies
+- **Abstract Pattern:** Operational runbooks, architecture decision records, and incident postmortems as first-class artifacts, reviewed and updated with the same rigor as code.
+- **Framework Mappings:**
+  - SRE runbooks: Step-by-step procedures for deployment, rollback, and incident response in shared wiki
+  - PagerDuty runbooks: Linked from alerts with copy-paste commands and decision trees
+  - Incident retrospectives: Blameless postmortems with action items tracked in ticketing system
+- **Language Patterns:**
+  - Kubernetes: Document deployment topologies with diagrams, config explanations, and troubleshooting steps
+  - AWS: Maintain infrastructure-as-code with inline comments explaining non-obvious design decisions
+  - Database: Create migration runbooks documenting rollback procedures and data validation steps
+
+### Active Maintainership
+- **Replaces Failure Pattern:** Abandoned Code Ownership
+- **Abstract Pattern:** Explicit ownership assignments with accountability for responsiveness, regularly audited and reassigned as team composition changes, ensuring every component has an engaged steward.
+- **Framework Mappings:**
+  - CODEOWNERS file: Updated quarterly with current team members, synced to org chart
+  - Service catalog: Document owner, on-call rotation, and escalation path for each service
+  - Ownership dashboard: Visualize modules with inactive owners, flagging reassignment needs
+- **Language Patterns:**
+  - Microservices: Each service has named owner team with SLO commitments and support tier
+  - Libraries: Package.json or setup.py includes maintainers field, synced to GitHub team
+  - Infrastructure: Terraform modules have provider blocks with owner annotations and review requirements
+
+### Standardized Review Criteria
+- **Replaces Failure Pattern:** Inconsistent Review Standards
+- **Abstract Pattern:** Documented review guidelines with checklists, training for reviewers, and periodic calibration sessions to align expectations and maintain quality standards across teams.
+- **Framework Mappings:**
+  - Review guidelines doc: Published standards covering correctness, readability, security, and test coverage
+  - Review training program: Onboard new reviewers with shadowing and calibration exercises
+  - Review metrics dashboard: Track approval rates, comment depth, and review time by reviewer to identify outliers
+- **Language Patterns:**
+  - Code review checklist: Security (input validation, auth), performance (algorithmic complexity), maintainability (naming, modularity)
+  - Review escalation: Require senior engineer review for PRs touching critical paths or changing interfaces
+  - Review retrospectives: Quarterly calibration sessions where team reviews same PR and compares feedback
+
+## Red Flags
+
+- Single commit author for entire module with >5000 LOC
+- CODEOWNERS file not updated in >12 months
+- >30% of PRs merged with zero review comments
+- Documentation directory last touched >2 years ago
+- No ADRs or design docs for system with >50K LOC
+- Critical deployment procedure exists only in Slack history
+- On-call runbook says "call [specific person]" instead of providing steps
+- Module has open PRs from 6+ months ago with no reviewer assignment
+- New hire onboarding checklist includes >10 "ask [person]" items
+- Team retrospectives repeatedly mention knowledge silos as blocker
+- Production incident required 2+ hours to find someone who understood system
+
+## Tool Affinities
+
+| Tool ID | Signal Type | Relevance |
+|---------|-------------|-----------|
+| git-history | Author concentration per module, commit timeline by contributor, review participation | primary |
+| git-history | Bus factor calculation, abandoned file detection (no commits in 180+ days) | primary |
+| git-history | Documentation staleness (last-modified dates relative to code) | primary |
+| SonarQube | Code review coverage metrics, PR decoration with quality gates | contextual |
+
+## Standards & Frameworks
+
+- **Team Topologies** — Stream-aligned teams, enabling teams, and community of practice models for knowledge sharing
+- **DevOps Research (DORA)** — Elite performer characteristics include low bus factor and high review participation
+- **Conway's Law** — System design mirrors communication structure; ownership patterns reveal architectural coupling
+- **Spotify Model** — Guilds and chapters as knowledge-sharing mechanisms across squad boundaries
+- **CODEOWNERS (GitHub/GitLab)** — Explicit ownership declarations with review enforcement
+- **SRE Principles (Google)** — On-call rotations and runbook culture as operational knowledge distribution
+
+## Metrics
+
+| Metric | What It Measures | Healthy Range |
+|--------|-----------------|---------------|
+| Bus Factor (per module) | Minimum number of contributors who must leave before knowledge loss becomes critical | ≥3 for critical modules |
+| Author Concentration (Gini) | Distribution inequality of commits across contributors (0=equal, 1=monopoly) | <0.6 for critical modules |
+| Review Coverage | Percentage of commits that went through peer review before merge | >90% |
+| Review Comment Depth | Average comments per reviewed PR, indicating engagement quality | 2-8 comments |
+| Documentation Freshness | Ratio of documentation age to code age (days since doc update / days since code update) | <0.5 (docs updated at least half as recently) |
+| Time to First Contribution | Days for new contributor to land first merged PR, indicating entry barriers | <30 days |
+| Abandoned Module Count | Modules with zero commits in last 180 days and open issues | 0 |
+| Onboarding Dependency | Number of "ask [person]" items in onboarding checklist, indicating tribal knowledge | <3 |

package/modules/radar/src/domains/13-risk-synthesis.md

@@ -0,0 +1,202 @@
+---
+id: domain-13
+number: "13"
+name: Risk Synthesis & Forecasting
+owner_agents: [principal-engineer]
+---
+
+## Overview
+
+Risk Synthesis & Forecasting aggregates findings across all prior domains to identify compound risks, forecast time-to-failure scenarios, and prioritize remediation efforts based on likelihood-times-impact analysis. This is a SYNTHESIS domain—it consumes findings from domains 00-12 rather than generating primary findings. Its failure patterns describe breakdowns in the synthesis process itself (treating risks in isolation, missing cross-domain interactions, short-term bias), not defects in the codebase. Effective risk synthesis answers "what breaks first" and "what requires immediate action" by understanding how risks interact and evolve. This domain does NOT cover individual domain analysis (architecture, security, performance, team risk, etc.).
+
+## Audit Questions
+
+- How are risks from different domains weighted and combined into a unified risk score?
+- Which cross-domain risk combinations create compound scenarios (e.g., security vulnerability + high coupling + single author)?
+- What is the predicted time-to-failure for critical systems based on trend analysis across quality, security, and ownership metrics?
+- Are risks assessed in isolation, or is there analysis of cascading failure modes and interaction effects?
+- What criteria determine whether a risk is accepted vs remediated, and are these criteria documented and consistently applied?
+- How is remediation sequenced—by severity, by time-to-failure, by dependency order, or by business priority?
+- Does risk assessment consider multiple time horizons (immediate, 3-month, 12-month), or focus only on current state?
+- Are there documented risk acceptance decisions with expiration dates and reassessment triggers?
+- How often are risk profiles updated, and what triggers reevaluation (new findings, production incidents, architecture changes)?
+- Are historical risk trends tracked to identify worsening patterns or validate remediation effectiveness?
+- What percentage of identified risks have defined remediation plans vs sit unaddressed?
+- How is risk communicated to stakeholders—raw scores, narrative summaries, or visual dashboards?
+
+## Failure Patterns
+
+### Risk Compartmentalization
+- **Description:** Treating risks from different domains as independent factors, missing critical interactions where vulnerabilities in one domain amplify or trigger failures in another, leading to blind spots in compound risk scenarios.
+- **Indicators:**
+  - Risk reports organized by domain with no cross-domain correlation analysis
+  - Security findings addressed independently of code ownership patterns (ignoring abandoned code with known CVEs)
+  - Performance degradation trends not correlated with coupling metrics (missing cascading slowdown risks)
+  - Remediation priorities set per-domain without considering interaction effects
+- **Severity Tendency:** high
+
+### Missing Compound Risk Analysis
+- **Description:** Failure to identify scenarios where multiple moderate risks combine into critical failure modes, such as a security vulnerability in single-author legacy code with high coupling and no test coverage.
+- **Indicators:**
+  - No documented compound risk scenarios or cascading failure mode analysis
+  - Risk scoring treats each finding as independent, ignoring multiplicative effects
+  - Production incidents reveal risk combinations that were individually triaged as low-priority
+  - Remediation planning focuses on highest individual scores without dependency or interaction consideration
+- **Severity Tendency:** critical
+
+### Short-Term Bias
+- **Description:** Risk assessment focuses exclusively on current state without trend analysis or forecasting, missing accelerating decay patterns that will cause future failures even if current metrics appear acceptable.
+- **Indicators:**
+  - Risk dashboards show only current snapshots with no historical trend lines
+  - No time-to-failure predictions or degradation rate calculations
+  - Technical debt treated as static rather than accruing with interest
+  - No differentiation between stable risks and rapidly worsening risks in remediation priority
+- **Severity Tendency:** high
+
+### Risk Normalization
+- **Description:** Persistent exposure to risks leads to acceptance-as-default rather than deliberate risk acceptance decisions, causing critical risks to become invisible through familiarity rather than judgment.
+- **Indicators:**
+  - Increasing count of "accepted" risks without documented acceptance criteria or reassessment dates
+  - Same risks appear in reports quarter after quarter with no remediation progress
+  - Team communication treats high-severity findings as "known issues" without urgency
+  - Production incidents greeted with "we knew that was fragile" rather than triggering remediation
+- **Severity Tendency:** high
+
+### Missing Risk Acceptance Criteria
+- **Description:** No documented framework for deciding when to accept vs remediate risks, leading to inconsistent decisions driven by urgency or loudest voice rather than principled assessment of likelihood, impact, and cost.
+- **Indicators:**
+  - Risk triage meetings result in ad-hoc decisions without reference to criteria
+  - Similar risks handled inconsistently (one accepted, another escalated)
+  - No risk acceptance artifacts documenting rationale, owner, expiration date, or monitoring plan
+  - Stakeholders surprised by production issues from risks assumed to be "handled"
+- **Severity Tendency:** medium
+
+### Remediation Without Prioritization
+- **Description:** Attempting to fix all identified risks simultaneously or in arbitrary order, leading to resource waste, incomplete fixes, and missing the highest-impact or most time-sensitive issues.
+- **Indicators:**
+  - Remediation backlog with >50 items and no rank ordering or deadline assignments
+  - Engineering time split across many small fixes without addressing critical compound risks
+  - No dependency analysis (some fixes unblock others; some are prerequisites)
+  - Remediation effort allocated proportionally to finding count per domain rather than impact or urgency
+- **Severity Tendency:** medium
+
+## Best Practice Patterns
+
+### Cross-Domain Risk Correlation
+- **Replaces Failure Pattern:** Risk Compartmentalization
+- **Abstract Pattern:** Analyze relationships between findings across domains, identifying interaction effects and cascading failure modes through correlation matrices and dependency graphs to surface compound risks.
+- **Framework Mappings:**
+  - Risk Matrix (ISO 31000): Extend 2D likelihood-impact matrix with correlation layers for cross-domain dependencies
+  - FAIR (Factor Analysis of Information Risk): Model compound risks using dependency trees and conditional probabilities
+  - Bow-Tie Analysis: Map risk interactions with threat scenarios on left, barriers in center, consequences on right
+- **Language Patterns:**
+  - Python/Pandas: Build correlation matrices between domain metrics (e.g., security score vs ownership concentration)
+  - SQL: Join findings tables across domains with shared code location keys to identify multi-domain hotspots
+  - Graph databases (Neo4j): Model risks as nodes with interaction edges, query for critical path scenarios
+
+### Compound Risk Identification
+- **Replaces Failure Pattern:** Missing Compound Risk Analysis
+- **Abstract Pattern:** Define and detect high-priority compound risk scenarios where multiple domain findings intersect in the same code location, multiplying severity through interaction effects.
+- **Framework Mappings:**
+  - FAIR framework: Calculate compound risk as P(A ∩ B) with amplification factors when risks overlap
+  - Risk scenario modeling: Define templates like "security vuln + abandoned owner + production-critical" as tier-1 scenarios
+  - Failure Mode and Effects Analysis (FMEA): Score compound risks using detection difficulty × occurrence probability × impact severity
+- **Language Patterns:**
+  - Rule engines (Drools, Python rules): Define compound risk patterns as logical rules triggering on multi-domain findings
+  - Risk scoring algorithms: Multiply base severity by amplification factors (e.g., 2x for single-author, 1.5x for high coupling)
+  - Alert thresholds: Escalate when ≥3 high-severity findings from different domains affect same module
+
+### Time-Series Forecasting
+- **Replaces Failure Pattern:** Short-Term Bias
+- **Abstract Pattern:** Track risk metrics over time, fit trend models to detect acceleration or decay, and predict time-to-failure thresholds to prioritize risks by urgency rather than current severity alone.
+- **Framework Mappings:**
+  - Predictive analytics: Use linear regression, exponential smoothing, or ARIMA models on metric time series
+  - Technical debt interest: Model accumulating debt as compound interest, forecasting when cost-to-fix exceeds cost-to-rewrite
+  - Reliability growth models: Apply Weibull or exponential failure models to predict next incident based on historical MTBF trends
+- **Language Patterns:**
+  - Python statsmodels/Prophet: Fit forecasting models to security debt, test coverage decay, or performance degradation trends
+  - Time-series databases (Prometheus, InfluxDB): Store historical risk metrics, query for moving averages and rate-of-change
+  - Alerting on derivatives: Trigger when second derivative is positive (acceleration in negative direction)
+
+### Deliberate Risk Acceptance
+- **Replaces Failure Pattern:** Risk Normalization
+- **Abstract Pattern:** Treat risk acceptance as an explicit decision requiring documented rationale, owner assignment, expiration date, and monitoring plan, preventing invisible accumulation of unaddressed risks.
+- **Framework Mappings:**
+  - Risk register (ISO 31000): Formal log of accepted risks with fields for justification, owner, review date, and compensating controls
+  - Risk acceptance matrix: Document criteria for accept vs mitigate vs transfer vs avoid based on likelihood-impact quadrant
+  - Exception management: Use ticketing system with SLA for accepted risk reviews (e.g., quarterly reassessment)
+- **Language Patterns:**
+  - Issue tracking: Create "accepted risk" ticket type with required fields (rationale, owner, expiry, monitoring)
+  - Automated expiration: Alert when accepted risk passes review date without reassessment
+  - Compensating controls checklist: Require documentation of mitigations even for accepted risks (e.g., monitoring, incident runbooks)
+
+### Risk Acceptance Framework
+- **Replaces Failure Pattern:** Missing Risk Acceptance Criteria
+- **Abstract Pattern:** Publish transparent criteria for risk triage decisions, including thresholds for automatic acceptance, escalation triggers, and stakeholder approval requirements, ensuring consistent and defensible risk management.
+- **Framework Mappings:**
+  - Risk appetite statement: Document organizational tolerance for risk categories (e.g., "no critical security vulns in production code")
+  - Decision tree: Flowchart mapping severity × exploitability × impact to accept/mitigate/escalate outcomes
+  - RACI matrix: Define who is Responsible, Accountable, Consulted, Informed for risk decisions by severity level
+- **Language Patterns:**
+  - Risk scoring rubrics: Published formulas for likelihood (1-5) × impact (1-5) with threshold rules (≥15 = escalate, 8-14 = mitigate, <8 = accept)
+  - Approval workflows: Automate routing (e.g., critical = CTO approval, high = VP eng, medium = tech lead)
+  - Audit trail: Log all risk decisions with timestamp, approver, and criteria reference for compliance review
+
+### Impact-Driven Remediation Sequencing
+- **Replaces Failure Pattern:** Remediation Without Prioritization
+- **Abstract Pattern:** Order remediation by a composite score combining severity, time-to-failure, dependency blocking, and business criticality, ensuring highest-impact and most time-sensitive issues are addressed first.
+- **Framework Mappings:**
+  - Weighted shortest job first (WSJF): Prioritize by (business value + time criticality + risk reduction) / effort estimate
+  - Dependency-aware scheduling: Use topological sort on remediation dependencies (fix A unblocks B and C)
+  - Cost-benefit analysis: Rank by expected value of remediation (incident probability reduction × incident cost - fix cost)
+- **Language Patterns:**
+  - Priority scoring: Calculate composite = (severity × 0.4) + (urgency × 0.3) + (business criticality × 0.2) + (dependency unblock count × 0.1)
+  - Gantt chart generation: Automate remediation roadmap with critical path highlighting and resource allocation
+  - Kanban with WIP limits: Cap in-progress remediations to prevent fragmentation, focus on completing high-priority items
+
+## Red Flags
+
+- Risk reports list findings by domain with no cross-references or interaction analysis
+- Same high-severity risks appear in quarterly reports without status changes or remediation progress
+- Production incident reveals risk combination that was visible across multiple domain reports
+- No documented risk acceptance decisions, or "accepted" tag applied without approval artifacts
+- Remediation backlog sorted alphabetically or by date found rather than by impact or urgency
+- Team treats persistent risks as background noise ("yeah, we know about that")
+- Stakeholders express surprise at production issues from risks assumed to be managed
+- Risk metrics show only current state with no trend lines or historical context
+- No time-to-failure estimates or projections for degrading metrics
+- Remediation planning allocates effort equally across domains without dependency or interaction consideration
+- No risk acceptance expiration dates or reassessment triggers
+
+## Tool Affinities
+
+| Tool ID | Signal Type | Relevance |
+|---------|-------------|-----------|
+| git-history | Trend analysis for ownership concentration, change frequency, and documentation staleness over time | primary |
+| SonarQube | Historical quality metrics, technical debt trends, code smell accumulation rates | supporting |
+| Trivy | CVE discovery date trends, vulnerability backlog age, exploit availability timeline | supporting |
+| Semgrep | Security finding trends by rule category, regression detection in security patterns | supporting |
+| Gitleaks | Secret exposure timeline, remediation velocity for leaked credentials | contextual |
+
+## Standards & Frameworks
+
+- **ISO 31000 Risk Management** — Risk identification, assessment, treatment, monitoring, and communication framework
+- **FAIR (Factor Analysis of Information Risk)** — Quantitative risk modeling with probability distributions and Monte Carlo simulation
+- **Bow-Tie Analysis** — Visual method for analyzing risk scenarios with threats, barriers, and consequences
+- **FMEA (Failure Mode and Effects Analysis)** — Systematic approach for identifying potential failure modes and prioritizing by severity × occurrence × detection
+- **NIST Risk Management Framework (RMF)** — Risk categorization, control selection, monitoring, and authorization
+- **DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability)** — Microsoft threat modeling risk scoring
+- **Technical Debt Quadrant (Fowler)** — Reckless/Prudent × Deliberate/Inadvertent classification for debt prioritization
+
+## Metrics
+
+| Metric | What It Measures | Healthy Range |
+|--------|-----------------|---------------|
+| Cross-Domain Risk Score | Composite severity index combining weighted findings across all domains | 0-100; <40 is healthy, >70 requires immediate action |
+| Compound Risk Count | Number of code locations with ≥3 high-severity findings from different domains | 0 is ideal; >5 indicates critical compound risks |
+| Predicted Time-to-Failure | Estimated days until critical metric crosses failure threshold based on trend analysis | >180 days for all critical systems |
+| Risk Acceptance Ratio | Count of deliberately accepted risks / total identified risks | 10-30% (some acceptance is pragmatic; >50% indicates normalization) |
+| Risk-Accepted with Expiry | Percentage of accepted risks with documented reassessment dates | 100% (all accepted risks require review cycles) |
+| Remediation Velocity | High-severity findings closed per sprint, indicating throughput and prioritization effectiveness | ≥3 per sprint for teams with active risk backlog |
+| Time-to-Remediation (P50) | Median days from finding identification to resolution for high-severity risks | <30 days for high, <7 days for critical |
+| Worsening Risk Trend % | Percentage of tracked metrics with negative trajectory (increasing debt, decreasing coverage) | <20% (some churn is normal; >40% indicates systemic decay) |

package/modules/radar/src/rules/agent-boundaries.md

@@ -0,0 +1,78 @@
+---
+id: agent-boundaries
+name: Agent Boundaries
+scope: all_agents
+priority: critical
+---
+
+## Purpose
+
+Radar agents are composed from personas + domains + schemas + rules. The power of this decomposed architecture depends entirely on agents staying within their compositional contracts. When an Architect agent starts opining on security, its security analysis is uninformed by the Security Engineer's threat model and mental models. When a Security Engineer produces performance recommendations, those recommendations lack the Performance Engineer's calibration for what constitutes an actual bottleneck.
+
+Boundary enforcement prevents two failure modes: **dilution** (agent output becomes generic when agents try to cover everything) and **contradiction** (agents produce conflicting findings in domains they don't own, creating noise instead of signal). Strong boundaries produce strong, distinct analysis. Weak boundaries produce mediocre, overlapping analysis.
+
+## Rules
+
+### 1. Persona identity constraint
+
+**Statement:** An agent must operate within its persona's defined thinking style, risk philosophy, and mental models. An SRE agent must not adopt a Security Engineer's threat model. A Compliance Officer must not reason like an Architect.
+
+**Rationale:** Personas encode how agents think, not just what they know. The Security Engineer's paranoid, threat-first perspective produces different findings than the Architect's structural, pattern-first perspective — even when examining the same code. If agents adopt each other's thinking styles, the multi-agent approach adds no value over a single generalist.
+
+**Enforcement:** Finding review checks that reasoning patterns in Layer 3 (interpretation) and Layer 7 (judgment) are consistent with the declared persona's characteristics. An SRE agent whose findings focus on SQL injection exploitability rather than service availability is operating outside its persona. Persona drift is flagged for Principal review.
+
+### 2. Domain scope constraint
+
+**Statement:** An agent must produce findings only in domains listed in its agent assembly manifest's `domains` field. A Security Engineer (Domain 04) must not produce findings in Domain 08 (Performance). The finding's `domain_number` must be in the agent's declared domain list.
+
+**Rationale:** Domain boundaries ensure comprehensive coverage without overlap. If multiple agents produce findings in the same domain, the audit has redundant analysis in some areas and gaps in others. Each domain has one primary owner — the agent whose persona and expertise are calibrated for that domain's failure patterns.
+
+**Enforcement:** @schema:finding validation checks that `domain_number` is in the producing agent's declared `domains` list. A finding from `security-engineer` with `domain_number: 08` (Performance) is a validation error.
+
+### 3. Cross-domain observation, not cross-domain judgment
+
+**Statement:** An agent may observe signals outside its domains (a Security Engineer may note that a performance issue creates a DoS vector), but the finding must be filed under the agent's own domain with a cross-reference to the relevant domain. The agent provides the observation; the domain owner provides the judgment.
+
+**Rationale:** Cross-domain observations are valuable — a Security Engineer noticing a DoS vector through a performance issue is exactly the kind of cross-cutting insight Radar is designed to surface. But the Security Engineer should file this as a security finding (Domain 04: "Performance issue X creates DoS vector Y") with a reference to Domain 08, not as a performance finding. The Performance Engineer then evaluates whether the performance issue is real; the Security Engineer evaluates whether the DoS vector is exploitable.
+
+**Enforcement:** Findings that reference domains outside the agent's scope must use the agent's own domain number in `domain_number` and include the referenced domain in `references` (e.g., "See Domain 08 for performance characterization"). Findings with `domain_number` outside the agent's domains but containing cross-domain observations are reclassified to the agent's domain with a cross-reference.
+
+### 4. Schema conformance constraint
+
+**Statement:** All agent output must conform to the schemas declared in the agent's assembly manifest. No ad-hoc output formats, no free-form text blocks, no "summary notes" outside the schema structure.
+
+**Rationale:** Schema conformance makes agent output composable. The disagreement resolution workflow expects @schema:finding instances. The report generation workflow expects @schema:disagreement instances. Ad-hoc output cannot be consumed by downstream workflows, creating dead zones in the analysis pipeline.
+
+**Enforcement:** Output validation checks every finding against @schema:finding, every disagreement raised against @schema:disagreement, and every confidence assessment against @schema:confidence. Non-conformant output is rejected and the agent must reformat. Agents cannot produce output types not declared in their assembly manifest.
+
+### 5. Tool signal consumption constraint
+
+**Statement:** Agents must consume signals tagged with their domains (the `domain_relevance` field in @schema:signal) and must not give undue weight to signals irrelevant to their domains. Ignoring relevant signals is a coverage gap; overweighting irrelevant signals is scope creep.
+
+**Rationale:** Phase 1 (Automated Signal Gathering) tags every signal with domain relevance. An agent that ignores signals relevant to its domains may miss evidence that would change its assessment. An agent that gives disproportionate weight to signals outside its domains is effectively auditing another agent's territory without that agent's calibration.
+
+**Enforcement:** Audit trail checks that each agent consumed all signals where `domain_relevance` includes the agent's domains. Missing signal consumption (signal relevant to Domain 04 not referenced by security-engineer) is flagged as a potential coverage gap. Agents referencing signals with no relevance to their domains must justify the cross-domain reference.
+
+## DO
+
+- Security Engineer files finding F-04-015: "Unbounded retry mechanism at `src/http/client.ts:34` creates a potential denial-of-service amplification vector. See Domain 07 for reliability characterization of the retry behavior." (Cross-domain observation filed in the agent's own domain with reference to the relevant domain.)
+
+- Data Engineer produces findings only in Domain 02 (Data & State Integrity), referencing signals S-SQ-003 and S-TRV-007 which both have `domain_relevance: [02]`. (Domain scope respected, relevant signals consumed.)
+
+- Principal Engineer reviews all domain findings and produces synthesis in Domain 13 (Risk Synthesis), which is explicitly in the Principal's domain list. (Synthesis happens within the designated domain, not ad-hoc.)
+
+- Agent output is a well-formed @schema:finding instance with all 7 layers, valid @schema:confidence vector, and proper ID format. (Schema conformance — no ad-hoc formats.)
+
+## DON'T
+
+- Architect agent produces finding F-04-022 in Domain 04 (Security): "Authentication tokens are not rotated."
+  **Why this is wrong:** Domain 04 is the Security Engineer's domain. The Architect may observe that the authentication architecture lacks token rotation (filed under Domain 01: Architecture), but the security implications are the Security Engineer's judgment to make.
+
+- Performance Engineer ignores signal S-SQ-015 (SonarQube complexity hotspot in `src/core/engine.ts`) which has `domain_relevance: [08]`, producing findings based only on manual code review.
+  **Why this is wrong:** Ignoring relevant signals creates coverage gaps. The SonarQube complexity signal may reveal performance-impacting patterns the manual review missed.
+
+- SRE agent produces a free-form text block: "General observations: The deployment pipeline seems fragile and the monitoring has gaps."
+  **Why this is wrong:** "General observations" is not a schema-conformant output. This must be expressed as @schema:finding instances with all 7 layers. "Seems fragile" violates epistemic hygiene (Layer 1 must be factual observation, not impression).
+
+- Security Engineer writes 3 findings in Domain 08 (Performance) because they noticed slow API responses during their security review.
+  **Why this is wrong:** The Security Engineer may note that slow responses create timing-based attack vectors (a Domain 04 finding), but characterizing performance issues is the Performance Engineer's domain. Filing findings in another agent's domain creates overlap and undermines the multi-agent structure.

package/modules/radar/src/rules/disagreement-protocol.md

@@ -0,0 +1,76 @@
+---
+id: disagreement-protocol
+name: Disagreement Protocol
+scope: all_agents
+priority: critical
+---
+
+## Purpose
+
+Multi-agent systems are prone to false consensus. Without explicit protocol rules, disagreements get auto-resolved (silently discarded), averaged (split the difference), or hidden (buried in footnotes). These failure modes are catastrophic because disagreements are where risk hides — the high-severity, high-disagreement quadrant is precisely where leadership attention is most needed.
+
+These rules ensure that every disagreement is a first-class object that must be explicitly raised, structurally recorded, categorized by root cause, and resolved by the Principal Engineer through a named reasoning model. The goal is not consensus — it is epistemic transparency.
+
+## Rules
+
+### 1. No auto-resolving disagreements
+
+**Statement:** A disagreement cannot transition from `open` to any resolved status without the Principal Engineer's explicit response. No agent, workflow, or automated process may resolve a disagreement.
+
+**Rationale:** Auto-resolution is the most dangerous anti-pattern because it is invisible. If an automated process decides two positions are "close enough" and marks the disagreement resolved, the audit record shows consensus where none existed. Risk is hidden, not reduced.
+
+**Enforcement:** @schema:disagreement validation rejects any disagreement where `status` is not `open` and `principal_response` is empty or null. The workflow that transitions disagreement status must verify `principal_response` is substantive (not a placeholder like "acknowledged" or "noted").
+
+### 2. No averaging opinions
+
+**Statement:** The Principal Engineer's resolution must not split the difference between positions. "Severity is between high and medium" is not a resolution — it is an abdication of judgment.
+
+**Rationale:** Averaging creates a false middle ground that no agent actually holds. If one agent says "critical" and another says "low", the answer is not "medium". The answer is a reasoned judgment about which evidence and which threat model is more compelling, using a named resolution model.
+
+**Enforcement:** Principal response text is checked for averaging patterns: "somewhere between", "compromise at", "split the difference", "partially agree with both". These phrases trigger a review flag. The resolution must name a resolution model (evidence_dominance, risk_asymmetry, reversibility, time_to_failure, blast_radius) and explain how it was applied.
+
+### 3. No forcing consensus language
+
+**Statement:** A resolution must not claim that agents now agree when their positions have not changed. Agents do not need to agree — the Principal decides, and dissenting positions are preserved.
+
+**Rationale:** Forced consensus language ("after discussion, all agents agree...") falsifies the epistemic record. If the Security Engineer assessed critical severity and the resolution is medium, the Security Engineer's original position must remain in the record. The Principal's resolution overrides for decision-making purposes, but does not retroactively change what agents assessed.
+
+**Enforcement:** Resolution records that claim consensus must show updated position entries from the agents involved. If no positions were updated, consensus language is a validation error. Dissenting positions are preserved permanently in @schema:disagreement regardless of final status.
+
+### 4. No hiding disagreements in footnotes
+
+**Statement:** Every disagreement referenced in a finding must have a corresponding @schema:disagreement record. Disagreements must appear in Report Section 4 (Cross-Validation Notes), not buried in finding footnotes or appendices.
+
+**Rationale:** A finding that mentions "some agents disagree on severity" without a formal disagreement record is unresolvable. There is no record of who disagreed, why, or how it was resolved. The disagreement becomes gossip instead of structured analysis.
+
+**Enforcement:** Cross-reference validation checks that every finding mentioning disagreement or conflicting assessment has a corresponding D-{NNN} disagreement record. Report validation checks that Section 4 contains all @schema:disagreement instances from the audit. Orphaned references (finding mentions disagreement but no record exists) are validation errors.
+
+### 5. No treating Devil's Advocate as optional
+
+**Statement:** The Devil's Advocate review (Phase 4) must produce at least one disagreement record for every audit. If the Devil's Advocate finds nothing to challenge, the audit's epistemic diversity is suspect. Dismissing Devil's Advocate disagreements as `out_of_scope` without substantive rationale is a violation.
+
+**Rationale:** The Devil's Advocate exists to stress-test the analysis. An audit where everyone agrees is an audit where something was missed or the Devil's Advocate was not sufficiently adversarial. The cost of false positives from the Devil's Advocate (challenges that turn out to be unfounded) is far lower than the cost of false negatives (risks that were never challenged).
+
+**Enforcement:** Report generation checks for disagreement records where `agents_involved` includes `devils-advocate`. If zero such records exist, the audit is flagged as incomplete. Disagreements from `devils-advocate` resolved as `out_of_scope` must have `principal_rationale` explaining why the challenge is outside the audit's scope — a brief dismissal is insufficient.
+
+## DO
+
+- Principal responds to a disagreement: "Evidence dominance favors the security engineer's position. Three independent tools flagged this pattern, and the application engineer's mitigation (input validation) does not address the underlying architectural vulnerability. Downgrading severity from critical to high based on the existing mitigation, but recommending parameterized queries as the durable fix." (Named model, specific reasoning, preserved positions.)
+
+- Devil's Advocate raises challenge: "Finding F-01-003 assumes circular dependencies will cause deployment failures, but the current deployment pipeline deploys as a monolith. The circular dependency is an architectural smell, not an operational risk until the team attempts to decompose into services." (Substantive challenge with specific reasoning.)
+
+- Disagreement record preserves both positions even after resolution, with the Security Engineer's original `confidence: high` and the Application Engineer's original `confidence: medium` both visible in the final record.
+
+## DON'T
+
+- Disagreement resolved by workflow: "Both agents' findings were similar enough. Auto-resolved as mitigated."
+  **Why this is wrong:** No agent or workflow may resolve disagreements. Only the Principal Engineer can transition status. "Similar enough" is averaging, not resolution.
+
+- Principal response: "I've reviewed both positions and they're both valid, so the severity is medium-high."
+  **Why this is wrong:** "Medium-high" is not a Radar severity value. This is averaging. The Principal must choose a severity from the enum and explain why using a named resolution model.
+
+- Resolution states: "After careful consideration, all agents now agree this is a medium-severity issue."
+  **Why this is wrong:** Unless the agents actually revised their positions (with updated position records), this is forced consensus. The original positions must be preserved even if the resolution disagrees with them.
+
+- Devil's Advocate disagreement D-007 resolved as: "Out of scope — not relevant."
+  **Why this is wrong:** "Not relevant" is not a substantive rationale. The Principal must explain specifically why the Devil's Advocate's challenge falls outside the audit scope. If it is relevant but the Principal disagrees, the correct status is `mitigated` or `accepted_risk`, not `out_of_scope`.