@accelerationguy/accel 1.0.0

package/modules/radar/src/transform/workflows/phase-8-execution-planning.md

@@ -0,0 +1,159 @@
+<purpose>
+Orchestrates execution planning by invoking the Execution Validator to define verification steps for every proposed change, build a dependency graph, and generate Drive-compatible project artifacts — producing the complete Layer C execution plan without ever applying changes.
+</purpose>
+
+<phase_context>
+Phase: 8 — Execution Planning
+Prior phase output: Risk-scored change plan (execution/risk-scores.yaml), Phase 6 playbooks (remediation/playbooks/), Phase 7 guardrails (remediation/guardrails/), risk assessment report
+Agents invoked: execution-validator (single agent)
+Output: execution/change-graph.yaml (dependency graph), execution/verification-plan.md (verification steps per change), execution/drive-project/ (Drive-compatible project artifacts)
+CRITICAL: Radar Transform NEVER applies changes. This workflow produces a plan only.
+</phase_context>
+
+<required_input>
+@.radar/STATE.md
+@.radar/MANIFEST.md
+@.radar/findings/*.md (for traceability)
+@execution/risk-scores.yaml (Phase 7 output)
+@remediation/playbooks/*.md (Phase 6 output)
+@remediation/guardrails/*.md (Phase 7 output)
+@~/.claude/radar/transform/agents/execution-validator.md
+@~/.claude/radar/transform/schemas/verification-plan.md
+@~/.claude/radar/transform/schemas/intervention-level.md
+@~/.claude/radar/transform/schemas/change-risk.md
+@~/.claude/radar/transform/rules/safety-governance.md
+@~/.claude/radar/transform/rules/change-risk-rules.md
+@~/.claude/radar/transform/workflows/transform-safety.md
+</required_input>
+
+<process>
+
+<step name="validate_prerequisites" priority="first">
+1. Verify .radar/STATE.md shows Phase 7 (Change Risk Validation) complete:
+   a. Check phase_7_complete: true
+   b. Check execution/risk-scores.yaml exists
+   c. Check remediation/guardrails/ contains at least one file
+2. If Phase 7 is not complete:
+   a. Halt with error: "Phase 7 (Change Risk Validation) not complete. Run phase-7-risk-validation workflow first."
+   b. Do not proceed.
+3. Load Phase 7 output metrics from .radar/STATE.md.
+4. Update .radar/STATE.md:
+   a. current_phase: 8
+   b. phase_status: in_progress
+</step>
+
+<step name="load_execution_context" priority="blocking">
+1. Load risk-scored change plan from execution/risk-scores.yaml:
+   a. All proposed changes with dimensional risk profiles
+   b. Final intervention levels (post-safety-validation)
+   c. Risk-adjusted priority ordering
+2. Load Phase 6 playbooks for remediation detail:
+   a. Transformation layers (abstract → project-specific)
+   b. Educational context from Pedagogy Agent
+3. Load Phase 7 guardrails for constraint integration.
+4. Load test infrastructure inventory and deployment configuration if available.
+5. Build complete change manifest:
+   a. Every change with its risk profile, intervention level, playbook reference, and guardrail references
+   b. Dependencies between changes (from Remediation Architect's ordering)
+6. Record execution context metrics in .radar/STATE.md.
+</step>
+
+<step name="invoke_execution_validator" priority="blocking">
+1. Load agent manifest from src/transform/agents/execution-validator.md.
+2. Resolve all component references:
+   a. Persona: src/transform/personas/execution-validator.md
+   b. Schemas: src/transform/schemas/verification-plan.md, src/transform/schemas/intervention-level.md, src/transform/schemas/change-risk.md
+   c. Rules: src/transform/rules/safety-governance.md, src/transform/rules/change-risk-rules.md
+3. Provide complete change manifest as input.
+4. Instruct agent to:
+   a. Define verification steps for every proposed change:
+      - Pre-change baseline observation
+      - Post-change acceptance criteria (traced to original finding)
+      - Regression verification (what was working, confirm it still is)
+      - Rollback criteria (conditions that trigger reverting the change)
+   b. Build dependency graph for change sequencing:
+      - Explicit dependencies (change A must precede change B)
+      - Implicit dependencies (shared code paths, behavioral contracts)
+      - Parallel-eligible change groups (independent changes that can proceed concurrently)
+   c. Generate Drive-compatible project artifacts:
+      - PROJECT.md (project definition with Radar audit reference)
+      - ROADMAP.md (phased plan with dependency ordering and verification gates)
+      - Per-phase PLAN.md files with tasks, acceptance criteria, and risk metadata per task
+   d. Embed risk metadata in Drive task definitions:
+      - Intervention level per task
+      - Change risk scores per task
+      - Finding confidence reference per task
+      - Verification plan reference per task
+5. Validate verification plan against src/transform/schemas/verification-plan.md.
+6. Record execution-validator session completion in .radar/STATE.md.
+</step>
+
+<step name="final_safety_validation" priority="blocking">
+1. Invoke transform-safety workflow for final validation:
+   a. Pass complete Drive project structure
+   b. Pass all verification plans
+2. Safety workflow validates:
+   a. No-auto-execution boundary: Drive project contains plans only — no execution commands, no direct file modifications, no bypass mechanisms
+   b. All 5 refusal conditions re-checked against final plan
+   c. Every task carries appropriate intervention level and risk metadata
+   d. Verification gates exist at every phase boundary
+3. If safety violations detected:
+   a. This is the last safety gate before handoff — violations must be resolved
+   b. Adjust Drive project to comply
+   c. Re-validate until clean
+4. Record final safety validation results in .radar/STATE.md.
+</step>
+
+<step name="persist_and_finalize" priority="blocking">
+1. Write change dependency graph to execution/change-graph.yaml:
+   a. Nodes: proposed changes with risk profiles
+   b. Edges: dependency relationships (explicit and implicit)
+   c. Groups: parallel-eligible change sets
+2. Write verification plan to execution/verification-plan.md:
+   a. Per-change verification steps (pre-change, post-change, regression, rollback)
+   b. Evidence chain from each verification criterion back to original finding
+3. Write Drive project to execution/drive-project/:
+   a. PROJECT.md
+   b. ROADMAP.md
+   c. Per-phase PLAN.md files
+   d. All files carry risk metadata and verification references
+4. Generate handoff summary:
+   a. Total changes planned, by intervention level
+   b. Estimated phases and dependencies
+   c. Key risks and mitigation strategies
+   d. Guardrails to install before execution begins
+5. Update .radar/STATE.md:
+   a. current_phase: 8
+   b. phase_status: complete
+   c. phase_8_complete: true
+   d. transform_complete: true
+   e. drive_project_generated: true
+   f. total_changes, changes_by_intervention_level, phases_in_drive_project
+   g. timestamp
+6. Mark Transform pipeline complete.
+</step>
+
+</process>
+
+<output>
+Artifacts created:
+- execution/change-graph.yaml — Dependency graph of all proposed changes
+- execution/verification-plan.md — Verification steps per change with evidence chains to original findings
+- execution/drive-project/PROJECT.md — Drive project definition with Radar audit reference
+- execution/drive-project/ROADMAP.md — Phased plan with dependency ordering and verification gates
+- execution/drive-project/phases/{NN}-*/PLAN.md — Per-phase plans with risk metadata per task
+- .radar/STATE.md — Updated with Phase 8 and Transform pipeline completion
+
+CRITICAL: No execution artifacts. No file modifications. No change commands. Radar Transform produces plans only.
+All verification plans conform to src/transform/schemas/verification-plan.md.
+Drive project validated by transform-safety workflow.
+</output>
+
+<error_handling>
+- **Phase 7 not complete:** Halt immediately. Display: "Phase 7 (Change Risk Validation) must complete before execution planning. Run phase-7-risk-validation workflow first." Do not proceed.
+- **Verification plan cannot be constructed for a change:** Record as "unverifiable" with specific gap (missing oracle, environment mismatch, untestable behavior). Include in handoff summary. An unverifiable change should not be included in the Drive project without explicit risk acknowledgment.
+- **Drive project generation fails:** Produce a manual remediation plan as fallback — a structured document describing changes, ordering, and verification in human-readable format without Drive project structure. Record fallback in STATE.md.
+- **Final safety validation finds violations:** Resolve violations before persisting. This is the last gate — no bypass. If violations cannot be resolved, remove the violating changes from the Drive project and record as "excluded by safety validation" with reasons.
+- **Dependency graph has cycles:** Report cycle to user. Cycles in change dependencies indicate that changes cannot be sequenced safely — some manual intervention is needed to break the cycle. Do not force a topological ordering that ignores cycles.
+- **No-auto-execution boundary violation detected:** This is a CRITICAL error. Remove any execution commands, file modification instructions, or bypass mechanisms. Re-validate. Transform NEVER executes changes under any circumstances.
+</error_handling>

package/modules/radar/src/transform/workflows/transform-safety.md

@@ -0,0 +1,158 @@
+<purpose>
+Validates Transform output against the safety framework — enforcing confidence gating, risk thresholds, intervention level integrity, the no-auto-execution boundary, and refusal conditions. Invoked as a utility workflow by phase workflows at every safety checkpoint.
+</purpose>
+
+<phase_context>
+Phase: N/A — Utility workflow invoked by Phase 6, 7, and 8 workflows
+Prior phase output: Varies by invocation point — playbooks (Phase 6), risk-scored changes (Phase 7), Drive project (Phase 8)
+Agents invoked: None — this is a validation gate, not an agent orchestration workflow
+Output: Safety validation result (pass/fail per item), intervention level adjustments, refusal records
+</phase_context>
+
+<required_input>
+@~/.claude/radar/transform/rules/safety-governance.md
+@~/.claude/radar/transform/rules/change-risk-rules.md
+@~/.claude/radar/transform/schemas/intervention-level.md
+@~/.claude/radar/schemas/confidence.md
+@~/.claude/radar/transform/schemas/change-risk.md
+Items to validate (passed by invoking workflow):
+- Playbooks with intervention level classifications
+- Finding confidence scores
+- Risk dimensional profiles (when available)
+- Drive project artifacts (Phase 8)
+</required_input>
+
+<process>
+
+<step name="confidence_gating" priority="first">
+1. For each item being validated (playbook, change, or Drive task):
+   a. Retrieve the declared intervention level
+   b. Retrieve the confidence score of the underlying finding(s)
+   c. Check against confidence thresholds:
+      - Suggesting: requires Low confidence minimum (1 source)
+      - Planning: requires Medium confidence minimum (2 independent sources)
+      - Authorizing: requires High confidence minimum (3+ independent sources)
+      - Executing: requires High confidence minimum (3+ independent sources with cross-validation)
+   d. If confidence is insufficient for declared level:
+      - Downgrade to the highest level the confidence supports
+      - Record: original level, downgraded level, confidence score, reason
+      - Example: "Downgraded from Authorizing to Planning — confidence has 2 sources, Authorizing requires 3+"
+2. Any confidence dimension rated 1 (lowest) caps overall confidence at Low regardless of other dimensions.
+3. Confidence vectors are immutable — do not modify the original finding's confidence, only the intervention level classification.
+</step>
+
+<step name="risk_threshold_check" priority="blocking">
+1. For each item with risk scores (available after Phase 7):
+   a. Check all 4 risk dimensions:
+      - Blast radius
+      - Coupling coefficient
+      - Regression probability
+      - Architectural tension
+   b. If ANY single dimension exceeds "high" threshold:
+      - Force intervention level downgrade to Suggesting
+      - Record: which dimension triggered, score value, original level
+      - This is the "unsafe context circuit breaker" — non-negotiable
+   c. If multiple dimensions are elevated but none exceed "high":
+      - Flag for heightened scrutiny but do not auto-downgrade
+      - Record: elevated dimensions and combined risk profile
+2. Risk-based downgrades override confidence-based levels:
+   a. Even if confidence supports Authorizing, a high-risk dimension forces Suggesting
+   b. Risk check is the more conservative gate
+3. For items without risk scores (Phase 6 invocation before risk scoring):
+   a. Skip dimensional risk check
+   b. Apply confidence gating only
+   c. Note: full risk validation occurs in Phase 7
+</step>
+
+<step name="intervention_level_enforcement" priority="blocking">
+1. Verify final intervention level integrity:
+   a. No playbook or change claims a higher level than its evidence warrants
+   b. Levels reflect the MORE restrictive of confidence gating and risk threshold checks
+   c. Intervention levels are immutable after approval — once set, they cannot be escalated
+2. Validate intervention level semantics:
+   a. Suggesting: advisory only, no structural commitments, developer decides
+   b. Planning: structured remediation plan, human approval required before any action
+   c. Authorizing: approved plan with verification gates, still requires human execution
+   d. Executing: approved + verified plan with automated verification — but Transform NEVER reaches this level (see no-auto-execution boundary)
+3. Record final intervention level for each item.
+</step>
+
+<step name="no_auto_execution_boundary" priority="blocking">
+1. Scan all Transform output for execution violations:
+   a. Direct file modification commands (write, edit, delete, move, rename)
+   b. Shell commands that modify the codebase (git commit, npm install, etc.)
+   c. Automated deployment triggers
+   d. Bypass mechanisms ("skip safety check", "override intervention level", "auto-apply")
+   e. Any instruction framed as imperative action rather than proposed plan
+2. If ANY execution violation detected:
+   a. Flag as CRITICAL safety violation
+   b. Remove the violating content
+   c. Record: what was found, where, what was removed
+   d. This boundary is absolute — Transform produces plans, never executes them
+3. Verify output framing:
+   a. All changes described as "proposed" or "recommended", never "will be applied"
+   b. All plans include human approval gates
+   c. All Drive tasks defer execution to the user's AI assistant operating under Drive framework
+4. The no-auto-execution boundary exists because:
+   a. Transform output has not been verified against the actual current codebase state
+   b. Transform agents may lack context about in-flight changes
+   c. Automated application of changes at audit scale carries unacceptable risk
+   d. Human oversight at the execution boundary is the final safety layer
+</step>
+
+<step name="refusal_conditions_check" priority="blocking">
+1. Check all 5 refusal conditions. If ANY condition is met, refuse to generate or approve remediation for the affected item:
+
+   a. **Confidence insufficient:** Finding confidence is too low to support any intervention level above Suggesting, AND the proposed action requires Planning or higher. Refuse the action; the finding needs more evidence before remediation can proceed.
+
+   b. **Risk exceeds bounds:** Risk dimensional profile shows one or more dimensions at maximum severity with no viable mitigation strategy. The proposed change is too dangerous to recommend in any form. Refuse; flag for human architectural review.
+
+   c. **Insufficient test coverage:** The blast radius of the proposed change extends into code with no test coverage, making regression verification structurally impossible. Refuse until test coverage is extended to cover the blast radius OR the change is rescoped to stay within tested boundaries.
+
+   d. **Unresolved high-severity disagreements:** The finding being remediated is subject to an unresolved disagreement with severity "high" or "critical" where no principal_response has been recorded. Refuse; the epistemic basis for the remediation is contested and the contest has not been resolved.
+
+   e. **Changes outside audit scope:** The proposed remediation modifies code, modules, or systems that were not included in the original audit scope (.radar/scope.md). Refuse; Transform cannot safely intervene in areas it has not analyzed.
+
+2. For each refusal:
+   a. Record: which condition was met, which item was refused, specific evidence
+   b. Refusals are NOT errors — they are the safety system working correctly
+   c. Refused items are excluded from the final output with their refusal reason preserved
+   d. The invoking workflow must handle refused items appropriately (record, report, do not force)
+</step>
+
+<step name="record_safety_audit" priority="blocking">
+1. Compile safety audit record:
+   a. Total items validated
+   b. Items passed without adjustment
+   c. Items with confidence-based downgrades (list with reasons)
+   d. Items with risk-based downgrades (list with triggering dimensions)
+   e. Items refused (list with refusal conditions)
+   f. Execution boundary violations detected and removed (list with details)
+2. Return safety validation result to invoking workflow:
+   a. Per-item pass/fail/downgrade/refuse status
+   b. Adjusted intervention levels
+   c. Refusal records
+   d. Safety audit summary
+3. This record is preserved in .radar/STATE.md and included in the final Transform output for audit trail purposes.
+</step>
+
+</process>
+
+<output>
+Returned to invoking workflow:
+- Per-item validation result: pass (no changes), downgrade (level adjusted), refuse (item excluded)
+- Adjusted intervention levels with downgrade rationale
+- Refusal records with specific condition and evidence
+- Safety audit summary (counts, details, boundary checks)
+
+No artifacts created directly — the invoking workflow persists results.
+Safety audit trail preserved in .radar/STATE.md for each invocation.
+</output>
+
+<error_handling>
+- **Safety violations are NOT errors:** A downgrade, a refusal, or an execution boundary violation detection is the safety system working correctly. These are expected outcomes, not failures to recover from.
+- **Missing confidence data:** If a finding lacks a confidence score, treat as confidence = unknown. Unknown confidence caps intervention level at Suggesting. Record as: "Confidence data missing — defaulting to Suggesting."
+- **Missing risk data:** If invoked before risk scoring (Phase 6), skip risk threshold check. Note in safety audit that risk validation was not performed at this checkpoint. Full risk validation occurs in Phase 7.
+- **Conflicting safety signals:** If confidence gating and risk thresholds produce different intervention levels, use the MORE restrictive (lower) level. Safety errs conservative.
+- **Invoking workflow ignores safety result:** This workflow cannot enforce compliance — it can only report. If an invoking workflow proceeds despite a refusal, the safety audit trail preserves the record. This is a process failure to be flagged in the Transform output summary, not a runtime error.
+</error_handling>

package/modules/vector/.vector-template/vector.json

@@ -0,0 +1,72 @@
+{
+  "version": 1,
+  "last_modified": null,
+  "config": {
+    "devmode": false,
+    "post_compact_gate": true,
+    "global_exclude": [],
+    "context_brackets": {
+      "FRESH": {
+        "enabled": true,
+        "rules": []
+      },
+      "MODERATE": {
+        "enabled": true,
+        "rules": [
+          "Keep responses focused — avoid unnecessary exploration",
+          "Prefer targeted edits over full file rewrites"
+        ]
+      },
+      "DEPLETED": {
+        "enabled": true,
+        "rules": [
+          "Minimize tool calls — batch aggressively",
+          "Skip verbose explanations — action over narration",
+          "Consider suggesting /compact or spawning a subagent for remaining work"
+        ]
+      }
+    },
+    "commands": {}
+  },
+  "domains": {
+    "GLOBAL": {
+      "state": "active",
+      "always_on": true,
+      "recall": ["universal"],
+      "exclude": [],
+      "rules": [
+        {
+          "id": 0,
+          "text": "NEVER use relative paths in code — use absolute. NEVER use absolute paths when referencing files to user — use relative.",
+          "added": null,
+          "last_reviewed": null,
+          "source": "template"
+        },
+        {
+          "id": 1,
+          "text": "NEVER run independent tool calls sequentially — batch them in parallel.",
+          "added": null,
+          "last_reviewed": null,
+          "source": "template"
+        },
+        {
+          "id": 2,
+          "text": "NEVER mark tasks complete without validation — test everything, require proof.",
+          "added": null,
+          "last_reviewed": null,
+          "source": "template"
+        }
+      ],
+      "decisions": []
+    },
+    "DEVELOPMENT": {
+      "state": "active",
+      "always_on": false,
+      "recall": ["write code for", "fix this bug", "implement this feature", "build this component", "refactor this", "add this endpoint", "programming task", "code review"],
+      "exclude": [],
+      "rules": [],
+      "decisions": []
+    }
+  },
+  "staging": []
+}

package/modules/vector/AUDIT-CLAUDEMD.md

@@ -0,0 +1,154 @@
+# CLAUDE.md Audit Guide
+
+Help users identify content in their CLAUDE.md that could be migrated to Vector domains for leaner context.
+
+## Purpose
+
+This guide helps Claude audit a user's CLAUDE.md and **suggest** (not automatically change) content that could become Vector domains. The goal is to reduce static context bloat while preserving the user's preferences.
+
+## Audit Process
+
+When a user asks to audit their CLAUDE.md for Vector migration:
+
+### Step 1: Read Their CLAUDE.md
+
+```
+Read the user's CLAUDE.md (project or global)
+```
+
+### Step 2: Categorize Content
+
+Identify content types:
+
+| Type | Should Stay in CLAUDE.md | Could Become Vector Domain |
+|------|--------------------------|--------------------------|
+| Project identity | Yes | No |
+| Directory structure | Yes | No |
+| Team/business context | Yes | No |
+| Git conventions | Yes | No |
+| **Coding preferences** | Maybe | **Yes** |
+| **Response formatting rules** | Maybe | **Yes** |
+| **Workflow-specific instructions** | Maybe | **Yes** |
+| **Tool usage preferences** | Maybe | **Yes** |
+| **Domain-specific rules** (testing, content, etc.) | No | **Yes** |
+
+### Step 3: Identify Candidates
+
+Look for patterns that indicate domain candidates:
+
+**Development preferences:**
+```
+"Always use TypeScript strict mode"
+"Prefer functional components"
+"Run tests after changes"
+```
+→ Suggest: DEVELOPMENT domain
+
+**Content/writing rules:**
+```
+"Use active voice"
+"Keep paragraphs short"
+"Include code examples"
+```
+→ Suggest: CONTENT domain
+
+**Review/quality rules:**
+```
+"Check for security issues"
+"Note performance implications"
+"Suggest improvements"
+```
+→ Suggest: REVIEW domain (or star-command)
+
+**Response format rules:**
+```
+"Be concise"
+"Use bullet points"
+"Skip explanations unless asked"
+```
+→ Suggest: Star-command (*brief, *concise, etc.)
+
+### Step 4: Present Findings
+
+Format your audit report:
+
+```markdown
+## CLAUDE.md Audit Report
+
+### Summary
+- Total lines: X
+- Identity/context content: X lines (keep)
+- Migration candidates: X lines
+
+### Keep in CLAUDE.md
+These sections provide essential project context:
+- [Section name] - [reason]
+
+### Migration Candidates
+
+#### Candidate 1: Development Preferences
+**Current location:** Lines X-Y
+**Content:**
+> [quote the relevant content]
+
+**Suggested domain:** DEVELOPMENT
+**Suggested recall keywords:** write code, fix bug, implement
+**Why migrate:** These rules only apply when coding, not for all interactions.
+
+#### Candidate 2: ...
+
+### Recommended Actions
+1. [First recommended action]
+2. [Second recommended action]
+
+### Questions for User
+- [Any clarifications needed]
+```
+
+### Step 5: Wait for Approval
+
+**CRITICAL:** Do NOT modify the user's CLAUDE.md without explicit approval.
+
+After presenting the audit:
+1. Ask which candidates they want to migrate
+2. Confirm the domain names and recall keywords
+3. Only then create the domains (using /vector:manager or manually)
+4. Only then remove content from CLAUDE.md (with user approval)
+
+## Example Audit Conversation
+
+**User:** Can you audit my CLAUDE.md for Vector migration?
+
+**Claude:** I'll read your CLAUDE.md and identify content that could become Vector domains.
+
+[Reads file, analyzes content]
+
+**Claude:** Here's my audit:
+
+### Migration Candidates
+
+**1. Coding Preferences (Lines 45-52)**
+> "Always use TypeScript strict mode. Prefer editing existing files. Run tests after changes. Keep changes minimal."
+
+This could become a DEVELOPMENT domain with recall keywords: "write code, fix bug, implement"
+
+**2. Response Formatting (Lines 60-63)**
+> "Be concise. Use bullet points. Skip explanations unless asked."
+
+This could become a `*brief` star-command.
+
+**Questions:**
+- Should I create these domains?
+- Any adjustments to the recall keywords?
+
+**User:** Yes, create the DEVELOPMENT domain but I want *concise instead of *brief.
+
+**Claude:** [Creates DEVELOPMENT domain and *concise command, then asks permission to remove the migrated lines from CLAUDE.md]
+
+## Key Principles
+
+1. **Diagnostic first** — Analyze and report before suggesting changes
+2. **User approval required** — Never modify CLAUDE.md without explicit consent
+3. **Preserve identity content** — Project context stays in CLAUDE.md
+4. **Migrate behavioral content** — Rules and preferences can become domains
+5. **Explain the benefit** — Show how migration reduces context usage