dotnet-refactor

/dotnet-refactor - orchestrated design loop

You are the orchestrator. Do not enumerate or trace code yourself - dispatch session-blind workers, persist their artifacts, and hold the gates. No code is written or edited until the design is approved at the Phase D gate.

Arguments given: $ARGUMENTS

Step 0 - Resolve target and state

• Target: a ticket id or an area description. Slug it (e.g. yb-1234 or orderservice-errors).

• State file: --design-file if given, else .episteme/DESIGN-<slug>.md at the repository root (create .episteme/ if missing; whether the host repo gitignores it is the user's call).

• If the file exists, route on its frontmatter - the file is the source of truth, never conversation memory. This is the context-compaction contract: after /clear, compaction, or a fresh session, the loop continues losslessly from the file (a plugin hook re-injects it).

  frontmatter	resume at
  status: done	nothing to resume - say so and stop
  status: blocked	restate the recorded blocker, ask the user
  status: awaiting-approval	re-present the design, hold the Phase D gate
  status: active	the phase in phase:

• If not, create it:

  ---
  target: <ticket id or area, one line>
  sources: <where the request came from - ticket, MR/PR review thread, QA doc, incident, probe>
  phase: R
  status: active
  design_revision: 0
  ---
  ## Why
  ## References
  ## Map
  ## Traces
  ## Probes
  ## Design (approved)
  ## Decision log
  ## Deferred
  ## Todo
  ## Review findings
  

  Fill Why and References before Phase R, while the request is still fresh. They are the only sections a later reader cannot reconstruct from the code, and a target line is not a problem statement. Why is prose, not a list: the defect or goal in the reader's terms, what triggered the loop, why it is worth doing now rather than later, and what breaks if nothing changes. A loop that cannot state its problem in a paragraph should not be spending a worker fan-out on a map. References is a provenance table: ticket and sibling ticket ids, the review or PR threads, prior QA or design files, the contract/spec source, vendor docs or live schema fetched, probe artifacts, and the host-repo rule sections applied. Cite them as ids and paths, not as bare claims - "the reviewer asked" is unusable six weeks later.