refactor

Runtime Configuration (Step 0 — before any processing)

Read these files to configure domain-specific behavior:

1. ops/derivation-manifest.md — vocabulary mapping, dimension positions, platform hints

   • Use vocabulary.notes for the notes folder name
   • Use vocabulary.note / vocabulary.note_plural for note type references
   • Use vocabulary.topic_map / vocabulary.topic_map_plural for MOC references
   • Use vocabulary.inbox for the inbox folder name

2. ops/config.yaml — current live configuration (the "after" state)

3. ops/derivation.md — original derivation record (the "before" state)

If these files don't exist, report error: "Cannot refactor without both ops/config.yaml and ops/derivation.md. These files establish the baseline and current configuration."

EXECUTE NOW

INVARIANT: /refactor never executes without approval. The plan is always shown first.

Target: $ARGUMENTS

Parse immediately:

• If target is empty: detect ALL config changes and plan restructuring
• If target names a specific dimension (e.g., "granularity", "organization"): focus on that dimension only
• If target is --dry-run: show plan without asking for approval

Execute these phases:

1. Detect changes between config.yaml and derivation.md
2. Plan restructuring for each changed dimension
3. Show the plan with affected artifacts and risk assessment
4. Execute on approval (unless --dry-run)
5. Validate post-restructuring

START NOW. Reference below defines the workflow.

Philosophy

Configuration changes cascade.

Changing a dimension is not just editing a value in config.yaml. Each dimension affects multiple artifacts — skills, templates, context file sections, hooks, MOC structure. Changing organization from "flat" to "hierarchical" means restructuring the notes directory, updating MOC templates, adjusting navigation references in the context file, and regenerating skills that reference folder structure.

/refactor makes these cascades visible and manages them. Without it, dimension changes create drift: config says one thing, artifacts say another. With it, every change is planned, approved, and validated.

The relationship to /architect: /architect RECOMMENDS changes. /refactor IMPLEMENTS them. /architect analyzes health and friction to propose dimension shifts. When those proposals are approved, /refactor ensures every affected artifact is updated consistently.

Phase 1: Detect Changes

Compare each dimension in ops/config.yaml against the same dimension in ops/derivation.md:

Step 1: Read both files

Read ops/config.yaml and ops/derivation.md fully. Extract the position for each of the 8 dimensions from both.

Step 2: Build comparison table

Step 3: Check feature flags

Also compare feature flags between derivation and config:

Step 4: Early exit if no changes

If no changes detected:

--=={ refactor }==--

  No configuration drift detected between config.yaml and derivation.md.
  All dimensions and features match the original derivation.

  If you want to explore changes, run /architect for recommendations
  or edit ops/config.yaml directly, then run /refactor again.

Phase 2: Plan Restructuring

For each changed dimension, determine ALL affected artifacts. This is the cascade analysis.

Dimension-to-Artifact Mapping

Artifact Analysis Format

For each affected artifact, specify:

Artifact: [file path]
  Section: [specific section within the file, if applicable]
  Current: [what it says now — quote relevant content]
  Proposed: [what it should say after refactoring]
  Risk: [low | medium | high]
  Reversible: [yes | no — with explanation]
  Content impact: [does this affect existing notes? how many?]

Content Impact Assessment

Some changes affect only infrastructure (skills, templates, context file). Others affect existing content (notes, MOCs):

For content-impacting changes:

• Count affected notes: grep -rl '[old value]' {vocabulary.notes}/*.md | wc -l
• List specific files that need updating
• Estimate time for content migration

Interaction Constraint Check

Read ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md and check:

1. Hard blocks: Would the new configuration create a combination that WILL fail?

   • Example: atomic granularity + 2-tier navigation at high volume
   • If a hard block is detected: WARN the user and recommend against the change

2. Soft warns: What friction points does the new configuration create?

   • Example: dense schema + convention-level automation (manual schema enforcement is tedious)
   • If soft warns exist: note them in the plan with compensating mechanisms

3. **Cascade ef