@accelerationguy/accel 1.0.0

package/modules/radar/docs/standards/workflows.md

@@ -0,0 +1,254 @@
+# Workflow Convention
+
+## Purpose
+
+Workflows define **ORCHESTRATION** — step-by-step execution logic for Radar audit phases and utility processes. A workflow specifies *what happens*, *in what order*, *with which agents*, and *how sessions hand off context*.
+
+Workflows are the operational backbone of Radar. They handle multi-session agent invocation, session boundary management, disagreement resolution sequencing, and artifact creation. Workflows do not analyze code, interpret signals, or render judgments — that is agent work. Workflows ensure agents are invoked correctly, receive the right context, produce output in the right format, and that phase transitions happen cleanly.
+
+Radar uses approximately 12 workflow files: 8 for Core (Phases 0-5 + utilities) and 4 for Transform (Phases 6-8 + Drive handoff).
+
+## Location
+
+```
+src/core/workflows/      (Core phase orchestration)
+src/transform/workflows/ (Transform phase orchestration)
+```
+
+## Naming
+
+**Pattern:**
+- Phase workflows: `phase-{N}-{kebab-name}.md`
+- Utility workflows: `{kebab-name}.md`
+
+**Examples:**
+- `phase-0-context.md`
+- `phase-1-reconnaissance.md`
+- `phase-2-domain-audits.md`
+- `phase-3-cross-domain.md`
+- `phase-4-severity-calibration.md`
+- `phase-5-report.md`
+- `session-handoff.md`
+- `disagreement-resolution.md`
+
+**Transform examples:**
+- `phase-6-remediation.md`
+- `phase-7-risk-validation.md`
+- `phase-8-execution-planning.md`
+- `drive-handoff.md`
+
+## Required Structure
+
+Workflow files use **XML tags** (not YAML frontmatter, not markdown headers). This matches the workflow convention used in the Drive framework and provides clear structural boundaries for each section.
+
+Workflows have no YAML frontmatter. They are loaded by explicit reference from commands and other workflows, not discovered by metadata scan.
+
+### Sections (All Required)
+
+| Section | Tag | Purpose |
+|---------|-----|---------|
+| Purpose | `<purpose>` | One-sentence description of what this workflow does. |
+| Phase Context | `<phase_context>` | Phase number, what this phase receives, which agents run, what it produces. |
+| Required Input | `<required_input>` | `@` references to files and artifacts this workflow needs loaded. |
+| Process | `<process>` | Ordered steps using `<step>` tags with named, prioritized instructions. |
+| Output | `<output>` | What artifacts are created and where they go in `.radar/`. |
+| Error Handling | `<error_handling>` | Failure scenarios and how the workflow responds. |
+
+### Step Structure
+
+Steps within `<process>` use this format:
+
+```xml
+<step name="{snake_case_name}" priority="{first|blocking|optional}">
+[Detailed numbered instructions for this step]
+</step>
+```
+
+| Attribute | Required | Values | Description |
+|-----------|----------|--------|-------------|
+| `name` | yes | snake_case string | Unique step identifier within this workflow |
+| `priority` | yes | `first`, `blocking`, `optional` | `first`: must execute before all others. `blocking`: must complete before next step. `optional`: can be skipped without invalidating the workflow. |
+
+## Cross-References
+
+| Direction | What | How |
+|-----------|------|-----|
+| References | Agent manifests (`src/agents/`) | By agent ID for invocation |
+| References | Schemas (`src/schemas/`) | For output validation |
+| References | `.radar/` state files | For runtime state management |
+| Referenced BY | Commands (`src/commands/`) | Delegation from user-facing entry points |
+| Referenced BY | Other workflows | For sub-workflow invocation (e.g., disagreement-resolution called by phase-3) |
+
+## Example Skeleton
+
+````xml
+<purpose>
+[One sentence describing what this workflow does.
+Example: "Executes parallel domain audits by invoking specialist agents against
+their assigned domains with normalized tool signals as input."]
+</purpose>
+
+<phase_context>
+Phase: [N] — [Phase Name]
+Prior phase output: [What this phase receives from the previous phase.
+  Example: "Repository structure map, technology inventory, normalized
+  tool signals (.radar/signals/), STATE.md"]
+Agents invoked: [Which agents run in this phase.
+  Example: "security-engineer, principal-engineer, sre, data-engineer,
+  api-designer (parallel-eligible agents run concurrently)"]
+Output: [What this phase produces.
+  Example: "Per-agent finding sets (.radar/findings/{agent-id}.md),
+  disagreement records (.radar/disagreements/), updated STATE.md"]
+</phase_context>
+
+<required_input>
+@.radar/STATE.md
+@.radar/MANIFEST.md
+@src/schemas/finding.md
+@src/schemas/signal.md
+@src/rules/epistemic-hygiene.md
+[Additional @ references to required files]
+</required_input>
+
+<process>
+
+<step name="validate_prerequisites" priority="first">
+1. Verify .radar/STATE.md exists and shows prior phase completed successfully.
+2. Verify all required signal files exist in .radar/signals/.
+3. Verify all agents listed in phase_context are defined in .radar/MANIFEST.md.
+4. If any prerequisite is missing, halt with error: "[prerequisite] not found.
+   Run phase [N-1] first."
+</step>
+
+<step name="prepare_agent_context" priority="blocking">
+1. For each agent invoked in this phase:
+   a. Load agent manifest from src/agents/{agent-id}.md.
+   b. Resolve all component references: persona, domains, tools, schemas, rules.
+   c. Collect normalized signals from .radar/signals/ matching the agent's tool list.
+   d. Collect findings from prior phases that reference the agent's domains.
+2. Bundle context into agent session input.
+3. Record agent invocation plan in .radar/STATE.md.
+</step>
+
+<step name="invoke_agents" priority="blocking">
+1. Identify parallel-eligible agents (those with `parallel_eligible: true`).
+2. Invoke parallel-eligible agents concurrently.
+3. Invoke remaining agents sequentially.
+4. For each agent invocation:
+   a. Provide: persona + domains + signals + schemas + rules.
+   b. Instruct agent to produce findings conforming to the finding schema.
+   c. Validate output against schema before accepting.
+   d. If validation fails, return to agent with specific field-level errors.
+5. Collect all agent outputs.
+</step>
+
+<step name="validate_outputs" priority="blocking">
+1. For each agent's finding set:
+   a. Validate every finding against src/schemas/finding.md.
+   b. Validate confidence ratings against src/schemas/confidence.md.
+   c. Check epistemic hygiene rules: evidence present, confidence justified,
+      severity reasoned.
+2. Flag findings that fail validation for agent revision.
+3. Record validated finding counts in .radar/STATE.md.
+</step>
+
+<step name="detect_disagreements" priority="blocking">
+1. Compare findings across agents for the same domains.
+2. Identify conflicts: same code area, different severity; same pattern,
+   different assessment; contradictory recommendations.
+3. For each disagreement:
+   a. Create disagreement record conforming to src/schemas/disagreement.md.
+   b. Write to .radar/disagreements/{disagreement-id}.md.
+4. If disagreements exist, queue disagreement-resolution workflow.
+</step>
+
+<step name="update_state" priority="blocking">
+1. Update .radar/STATE.md with:
+   - Phase [N] completion status.
+   - Finding counts by agent and domain.
+   - Disagreement count and resolution status.
+   - Timestamp.
+2. Write finding files to .radar/findings/{agent-id}.md.
+</step>
+
+</process>
+
+<output>
+Artifacts created:
+- .radar/findings/{agent-id}.md — Per-agent finding sets (one file per agent)
+- .radar/disagreements/{disagreement-id}.md — Disagreement records (if any)
+- .radar/STATE.md — Updated with phase completion and metrics
+
+All output files must conform to their respective schemas.
+</output>
+
+<error_handling>
+- **Missing prerequisites:** Halt immediately. Display which prerequisite is missing
+  and which prior phase must be run.
+- **Agent invocation failure:** Log failure, skip agent, continue with remaining agents.
+  Record skipped agent in STATE.md. Warn user that coverage is incomplete.
+- **Schema validation failure:** Return finding to agent with field-level errors.
+  Allow up to 2 retry attempts. On third failure, log finding as "unvalidated"
+  and flag for manual review.
+- **Session timeout:** Save partial state to .radar/STATE.md with status "interrupted".
+  Allow resume from last completed step via session-handoff workflow.
+- **All agents fail:** Halt phase. Record failure in STATE.md. Do not proceed to
+  next phase.
+</error_handling>
+````
+
+## Transform Workflow Types
+
+Transform workflows orchestrate Phases 6-8 and the Drive handoff. They follow the same structural conventions as Core workflows (XML tags, step structure, error handling) but with Transform-specific concerns.
+
+**Phase 6 — Remediation Synthesis Workflow:**
+- Invokes: Remediation Architect, then Pedagogy Agent (sequential)
+- Input: Complete `.radar/` Layer A record
+- Steps: (1) Load all findings grouped by root cause, (2) Invoke Remediation Architect to produce playbooks at all 4 transformation layers, (3) Invoke Pedagogy Agent to enrich with educational context, (4) Classify each playbook by intervention level, (5) Validate all playbooks against playbook schema
+- Output: `remediation/playbooks/`, `remediation/patterns/`, `remediation/REMEDIATION-SUMMARY.md`
+- Error handling: If a finding cannot be remediated (insufficient confidence, unclear root cause), record as "unremediated" with reason
+
+**Phase 7 — Change Risk Validation Workflow:**
+- Invokes: Change Risk Modeler, then Guardrail Generator (sequential)
+- Input: Phase 6 playbooks + codebase structure + git history + test coverage
+- Steps: (1) Score every proposed change across 4 risk dimensions, (2) Flag changes exceeding risk thresholds for intervention level downgrade, (3) Invoke Guardrail Generator to produce project rules, (4) Establish final risk-adjusted priority ordering
+- Output: `execution/risk-scores.yaml`, `remediation/guardrails/`
+- Error handling: If risk scoring fails for a change, default to maximum risk and flag for human review
+
+**Phase 8 — Execution Planning Workflow:**
+- Invokes: Execution Validator
+- Input: Risk-scored change plan from Phase 7
+- Steps: (1) Define verification steps for every proposed change, (2) Build dependency graph, (3) Generate Drive project artifacts (PROJECT.md, ROADMAP.md, phased plans), (4) Embed risk metadata and intervention levels in Drive tasks, (5) Validate Drive project structure
+- Output: `execution/change-graph.yaml`, `execution/verification-plan.md`, `execution/drive-project/`
+- Error handling: If Drive project generation fails, produce a manual remediation plan as fallback
+
+**Drive Handoff Workflow:**
+- Purpose: Finalize Transform output and prepare for handoff to user's AI assistant
+- Steps: (1) Validate all Layer B and C artifacts exist and are internally consistent, (2) Generate handoff summary, (3) Archive Transform state, (4) Present Drive project to user
+- Output: Handoff summary document, validated Drive project
+- This is the terminal workflow — after this, Radar's role is complete
+
+### Drive Handoff Specification
+
+A Layer C Drive project must contain:
+
+| Artifact | Required | Description |
+|----------|----------|-------------|
+| `PROJECT.md` | yes | Project definition with Radar audit reference, target codebase, remediation scope |
+| `ROADMAP.md` | yes | Phased plan with dependency ordering, phase descriptions, verification gates |
+| Phase plans | yes | Per-phase PLAN.md with tasks, acceptance criteria, risk metadata per task |
+| Risk metadata per task | yes | Intervention level, change risk scores, finding confidence, verification plan ref |
+| Verification gates per phase | yes | Pre-change, post-change, regression, and rollback criteria |
+
+## Anti-Patterns
+
+| Anti-Pattern | Why It's Wrong |
+|--------------|----------------|
+| Embedding domain knowledge | Workflows orchestrate; they do not analyze. "Check for SQL injection in the user input handlers" is domain knowledge that belongs in `src/domains/`. Workflows invoke agents who apply domain knowledge. |
+| Embedding persona behavior | Workflows invoke agents; they do not define how agents think. "Apply an attacker mindset to this step" is persona content that belongs in `src/personas/`. Workflows specify *which* agent to invoke, not *how* it should reason. |
+| Vague steps | "Analyze the codebase" is not a workflow step. Workflow steps must be specific and mechanical: load these files, invoke this agent, validate against this schema, write to this path. If a step requires judgment, it should be delegated to an agent, not described vaguely. |
+| Missing session handoff specs | Multi-session workflows must explicitly define what passes between sessions. What state is persisted? What context is reloaded? What is lost? Without handoff specs, session boundaries become data loss boundaries. |
+| Hardcoded agent lists | Workflows should reference agents via the manifest or phase configuration, not hardcode names. "Invoke security-engineer, then principal-engineer" breaks when agents are added or removed. Reference the set of agents assigned to this phase. |
+| Missing error handling | Every workflow step that can fail must have a defined failure response. "If step fails, stop" is insufficient. What state is saved? Can the user resume? What diagnostic information is provided? |
+| Transform workflow without safety checks | Every Transform workflow must validate intervention levels and check risk thresholds before producing output. A workflow that generates remediation without checking confidence gating is unsafe. |
+| Drive handoff without verification | The Drive project must be validated before handoff. Missing verification gates, incomplete risk metadata, or unclassified intervention levels make the handoff unreliable. |

package/modules/radar/docs/terminal.svg

@@ -0,0 +1,72 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 380">
+  <defs>
+    <linearGradient id="bg" x1="0" y1="0" x2="0" y2="1">
+      <stop offset="0%" stop-color="#1a1b26"/>
+      <stop offset="100%" stop-color="#16161e"/>
+    </linearGradient>
+    <linearGradient id="titlebar" x1="0" y1="0" x2="0" y2="1">
+      <stop offset="0%" stop-color="#2a2b3d"/>
+      <stop offset="100%" stop-color="#24253a"/>
+    </linearGradient>
+  </defs>
+
+  <!-- Window -->
+  <rect width="800" height="380" rx="10" fill="url(#bg)"/>
+
+  <!-- Title bar -->
+  <rect width="800" height="36" rx="10" fill="url(#titlebar)"/>
+  <rect y="26" width="800" height="10" fill="url(#titlebar)"/>
+
+  <!-- Window buttons -->
+  <circle cx="20" cy="18" r="6" fill="#ff5f57"/>
+  <circle cx="40" cy="18" r="6" fill="#febc2e"/>
+  <circle cx="60" cy="18" r="6" fill="#28c840"/>
+
+  <!-- Title text -->
+  <text x="400" y="23" text-anchor="middle" fill="#787c99" font-family="SF Mono, Monaco, Consolas, monospace" font-size="13">Radar — Codebase Audit System</text>
+
+  <!-- Terminal content -->
+  <g font-family="SF Mono, Monaco, Consolas, monospace" font-size="14">
+
+    <!-- Line 1: prompt + command -->
+    <text x="20" y="65" fill="#7aa2f7">$</text>
+    <text x="35" y="65" fill="#c0caf5">/radar:audit</text>
+
+    <!-- Line 2: blank -->
+
+    <!-- Radar title -->
+    <text x="20" y="120" fill="#bb9af7" font-size="48" font-weight="bold" letter-spacing="12">Radar</text>
+
+    <!-- Line: tagline -->
+    <text x="20" y="188" fill="#565f89" font-size="12">Automated Epistemic Governance &amp; Intelligence System</text>
+
+    <!-- Blank line -->
+
+    <!-- Phase output -->
+    <text x="20" y="215" fill="#9ece6a">✓</text>
+    <text x="38" y="215" fill="#c0caf5">Phase 0 — Context &amp; Threat Modeling</text>
+    <text x="380" y="215" fill="#565f89">complete</text>
+
+    <text x="20" y="237" fill="#9ece6a">✓</text>
+    <text x="38" y="237" fill="#c0caf5">Phase 1 — Automated Signal Gathering</text>
+    <text x="380" y="237" fill="#565f89">6 signal dimensions</text>
+
+    <text x="20" y="259" fill="#9ece6a">✓</text>
+    <text x="38" y="259" fill="#c0caf5">Phase 2 — Deep Domain Audits</text>
+    <text x="380" y="259" fill="#565f89">14 domains, 12 agents</text>
+
+    <text x="20" y="281" fill="#e0af68">▸</text>
+    <text x="38" y="281" fill="#7aa2f7">Phase 3 — Change Risk &amp; Reality Gap</text>
+    <text x="380" y="281" fill="#e0af68">in progress...</text>
+
+    <text x="20" y="303" fill="#565f89">○</text>
+    <text x="38" y="303" fill="#565f89">Phase 4 — Adversarial Review</text>
+
+    <text x="20" y="325" fill="#565f89">○</text>
+    <text x="38" y="325" fill="#565f89">Phase 5 — Final Synthesis</text>
+
+    <!-- Status bar -->
+    <text x="20" y="358" fill="#565f89" font-size="12">Findings: 23 | Agents: 12/12 | Confidence: High | Session: 3 of ~5</text>
+
+  </g>
+</svg>

package/modules/radar/docs/validation/convention-compliance-report.md

@@ -0,0 +1,183 @@
+# Convention Compliance Report
+
+**Date:** 2026-02-19
+**Scope:** All 90 Radar spec files validated against 8 component type conventions (docs/standards/)
+**Validator:** Phase 8 End-to-End Validation (08-01)
+
+## Executive Summary
+
+**90/90 files pass convention compliance.** All required frontmatter fields present, all required sections present, all structural patterns followed. One cosmetic inconsistency noted (non-blocking).
+
+## Results by Component Type
+
+### Domains (14 files) — 14/14 PASS
+
+| File | Frontmatter | Sections (8) | 1:1 Mapping | Result |
+|------|-------------|-------------|-------------|--------|
+| 00-context.md | PASS | PASS | 6:6 | PASS |
+| 01-architecture.md | PASS | PASS | 8:8 | PASS |
+| 02-data.md | PASS | PASS | 7:7 | PASS |
+| 03-correctness.md | PASS | PASS | 7:7 | PASS |
+| 04-security.md | PASS | PASS | 8:8 | PASS |
+| 05-compliance.md | PASS | PASS | 7:7 | PASS |
+| 06-testing.md | PASS | PASS | 7:7 | PASS |
+| 07-reliability.md | PASS | PASS | 8:8 | PASS |
+| 08-performance.md | PASS | PASS | 8:8 | PASS |
+| 09-maintainability.md | PASS | PASS | 8:8 | PASS |
+| 10-operability.md | PASS | PASS | 8:8 | PASS |
+| 11-change-risk.md | PASS | PASS | 7:7 | PASS |
+| 12-team-risk.md | PASS | PASS | 7:7 | PASS |
+| 13-risk-synthesis.md | PASS | PASS | 6:6 | PASS |
+
+**Convention checks:** id (domain-{DD}), number (two-digit string), name, owner_agents. 8 sections in order: Overview, Audit Questions, Failure Patterns, Best Practice Patterns, Red Flags, Tool Affinities, Standards & Frameworks, Metrics. Strict 1:1 failure/best-practice mapping verified.
+
+**Total failure/best-practice pairs:** 104 (range: 6-8 per domain)
+
+### Rules (5 files) — 5/5 PASS
+
+| File | Frontmatter | Sections (4) | Result |
+|------|-------------|-------------|--------|
+| epistemic-hygiene.md | PASS | PASS | PASS |
+| disagreement-protocol.md | PASS | PASS | PASS |
+| agent-boundaries.md | PASS | PASS | PASS |
+| safety-governance.md | PASS | PASS | PASS |
+| change-risk-rules.md | PASS | PASS | PASS |
+
+**Convention checks:** id, name, scope, priority (all are `critical`). Sections: Purpose, Rules, DO, DON'T.
+
+### Schemas (9 files) — 9/9 PASS
+
+| File | Frontmatter | Sections (5) | Result |
+|------|-------------|-------------|--------|
+| confidence.md | PASS | PASS | PASS |
+| disagreement.md | PASS | PASS | PASS |
+| finding.md | PASS | PASS | PASS |
+| report-section.md | PASS | PASS | PASS |
+| signal.md | PASS | PASS | PASS |
+| change-risk.md | PASS | PASS | PASS |
+| intervention-level.md | PASS | PASS | PASS |
+| playbook.md | PASS | PASS | PASS |
+| verification-plan.md | PASS | PASS | PASS |
+
+**Convention checks:** id, name, version (all 1.0.0), used_by. Sections: Purpose, Template, Field Reference, Validation Rules, Examples.
+
+### Tools (8 files) — 8/8 PASS
+
+| File | Frontmatter | Sections (6) | Result |
+|------|-------------|-------------|--------|
+| sonarqube.md | PASS | PASS | PASS |
+| semgrep.md | PASS | PASS | PASS |
+| trivy.md | PASS | PASS | PASS |
+| gitleaks.md | PASS | PASS | PASS |
+| checkov.md | PASS | PASS | PASS |
+| syft.md | PASS | PASS | PASS |
+| grype.md | PASS | PASS | PASS |
+| git-history.md | PASS | PASS | PASS |
+
+**Convention checks:** id, name, type (valid enum), domains_fed, install_required, install_command (conditional). Sections: Purpose, Configuration, Execution, Output Format, Normalization, Limitations.
+
+**Cosmetic note:** sonarqube.md has an extra `# SonarQube Tool Adapter` heading before Purpose section — absent from other tool files. Not a convention violation.
+
+### Personas (17 files) — 17/17 PASS
+
+| File | Frontmatter | XML Sections (8) | Result |
+|------|-------------|------------------|--------|
+| architect.md | PASS | PASS | PASS |
+| compliance-officer.md | PASS | PASS | PASS |
+| data-engineer.md | PASS | PASS | PASS |
+| devils-advocate.md | PASS | PASS | PASS |
+| performance-engineer.md | PASS | PASS | PASS |
+| principal-engineer.md | PASS | PASS | PASS |
+| reality-gap-analyst.md | PASS | PASS | PASS |
+| security-engineer.md | PASS | PASS | PASS |
+| senior-app-engineer.md | PASS | PASS | PASS |
+| sre.md | PASS | PASS | PASS |
+| staff-engineer.md | PASS | PASS | PASS |
+| test-engineer.md | PASS | PASS | PASS |
+| change-risk-modeler.md | PASS | PASS | PASS |
+| execution-validator.md | PASS | PASS | PASS |
+| guardrail-generator.md | PASS | PASS | PASS |
+| pedagogy-agent.md | PASS | PASS | PASS |
+| remediation-architect.md | PASS | PASS | PASS |
+
+**Convention checks:** id, name, role, active_phases. XML sections: identity, mental_models, risk_philosophy, thinking_style, triggers, argumentation, confidence_calibration, constraints.
+
+### Agents (17 files) — 17/17 PASS
+
+| File | Frontmatter (9 fields) | Body Sections (2) | Result |
+|------|------------------------|-------------------|--------|
+| architect.md | PASS | PASS | PASS |
+| compliance-officer.md | PASS | PASS | PASS |
+| data-engineer.md | PASS | PASS | PASS |
+| devils-advocate.md | PASS | PASS | PASS |
+| performance-engineer.md | PASS | PASS | PASS |
+| principal-engineer.md | PASS | PASS | PASS |
+| reality-gap-analyst.md | PASS | PASS | PASS |
+| security-engineer.md | PASS | PASS | PASS |
+| senior-app-engineer.md | PASS | PASS | PASS |
+| sre.md | PASS | PASS | PASS |
+| staff-engineer.md | PASS | PASS | PASS |
+| test-engineer.md | PASS | PASS | PASS |
+| change-risk-modeler.md | PASS | PASS | PASS |
+| execution-validator.md | PASS | PASS | PASS |
+| guardrail-generator.md | PASS | PASS | PASS |
+| pedagogy-agent.md | PASS | PASS | PASS |
+| remediation-architect.md | PASS | PASS | PASS |
+
+**Convention checks:** id, name, persona, domains, tools, schemas (output/confidence/signal_input), rules, active_phases, parallel_eligible. Sections: Assembly Notes, Session Context.
+
+**Note:** Transform agents add `layer_a_input` to schemas — consistent extension, not a violation.
+
+### Workflows (12 files) — 12/12 PASS
+
+| File | XML-only | Sections (6) | Named Steps | Result |
+|------|----------|-------------|-------------|--------|
+| phase-0-context.md | PASS | PASS | PASS | PASS |
+| phase-1-reconnaissance.md | PASS | PASS | PASS | PASS |
+| phase-2-domain-audits.md | PASS | PASS | PASS | PASS |
+| phase-3-cross-domain.md | PASS | PASS | PASS | PASS |
+| phase-4-adversarial-review.md | PASS | PASS | PASS | PASS |
+| phase-5-report.md | PASS | PASS | PASS | PASS |
+| session-handoff.md | PASS | PASS | PASS | PASS |
+| disagreement-resolution.md | PASS | PASS | PASS | PASS |
+| phase-6-remediation.md | PASS | PASS | PASS | PASS |
+| phase-7-risk-validation.md | PASS | PASS | PASS | PASS |
+| phase-8-execution-planning.md | PASS | PASS | PASS | PASS |
+| transform-safety.md | PASS | PASS | PASS | PASS |
+
+**Convention checks:** No YAML frontmatter. XML sections: purpose, phase_context, required_input, process, output, error_handling. All `<output>` and `<error_handling>` are properly structured as sibling elements. Process steps have name and priority attributes.
+
+### Commands (8 files) — 8/8 PASS
+
+| File | Frontmatter | XML Sections (5) | Result |
+|------|-------------|------------------|--------|
+| audit.md | PASS | PASS | PASS |
+| resume.md | PASS | PASS | PASS |
+| status.md | PASS | PASS | PASS |
+| report.md | PASS | PASS | PASS |
+| transform.md | PASS | PASS | PASS |
+| remediate.md | PASS | PASS | PASS |
+| playbook.md | PASS | PASS | PASS |
+| guardrails.md | PASS | PASS | PASS |
+
+**Convention checks:** name (radar:{kebab}), description, argument-hint (optional). XML sections: objective, execution_context, context, process, success_criteria.
+
+## Summary
+
+| Component Type | Files | Passed | Failed | Blockers | Warnings | Cosmetic |
+|---------------|-------|--------|--------|----------|----------|----------|
+| Domains | 14 | 14 | 0 | 0 | 0 | 0 |
+| Rules | 5 | 5 | 0 | 0 | 0 | 0 |
+| Schemas | 9 | 9 | 0 | 0 | 0 | 0 |
+| Tools | 8 | 8 | 0 | 0 | 0 | 1 |
+| Personas | 17 | 17 | 0 | 0 | 0 | 0 |
+| Agents | 17 | 17 | 0 | 0 | 0 | 0 |
+| Workflows | 12 | 12 | 0 | 0 | 0 | 0 |
+| Commands | 8 | 8 | 0 | 0 | 0 | 0 |
+| **TOTAL** | **90** | **90** | **0** | **0** | **0** | **1** |
+
+**Cosmetic issues (1):**
+- sonarqube.md: extra `# SonarQube Tool Adapter` heading not present in other tool files
+
+---
+*Generated: 2026-02-19 — Phase 8 End-to-End Validation*