ehoandClaude Opus 5
12f17d9d73
Two backlog trees are complete: `docs/project/backlog/` (75 files, every WP done) and `docs/project/refactor-backlog-setup/` (the arc before it). Move both under `docs/project/archive/` with `git mv`, so history stays intact through `git log --follow`. `SHOWCASE-ROADMAP.md` moves with them, because it points at the now-archived backlog README. Add `docs/project/archive/README.md`. It states that these trees are historical and names the two directories that are still live. Repoint every inbound reference named in RD-30's Files table: CLAUDE.md, the root README, both backend READMEs, `LetterHtml.cs`, `a11y.mdx`, the `document-feature` and `new-ssp` skills, and the readable-codebase PLAN, README, and RD-19 ticket. Fix two upward-relative links inside the moved WP files (WP-68, WP-69) that gained a directory level and would otherwise break. Repoint `.prettierignore`'s two agent-prompt exclusions to their new path, so prettier keeps leaving those files' exact wording alone. Mark RD-30 done and check off its acceptance criteria; flip its README row to done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.9 KiB
MODEL: Opus OUTPUT FILE: /refactor-backlog/00-baseline.md DEPENDS ON: none
PERSISTENCE & RESUME PROTOCOL
Before starting work:
- Read /refactor-backlog/_status.md. If your row says "complete", stop — do not re-run.
- If "in_progress", read your own output file. Treat modules already listed as done. Resume from "Last module processed" + 1.
- If "not_started", confirm your dependencies show "complete" in _status.md. If not, stop and report a blocking dependency instead of guessing.
While working: 4. Append findings incrementally, one module at a time. After each module, update _status.md: "Last module processed" and "Last updated". 5. Each finding gets a stable ID (e.g. RD-014) that never changes across runs. 6. If interrupted, the file + status row is the full recovery state.
On completion: 7. Mark your _status.md row "complete" only once every module in scope has a corresponding section in your output file.
Every output file starts with:
Scope: [modules covered]
Status: [not_started | in_progress | complete]
Last updated: [timestamp]
Depends on: [file(s)]
---
ROLE: Metrics Baseline Agent
Before any refactoring suggestions, establish a baseline for the scoped codebase:
- Test coverage (line/branch) per module, .NET and Angular separately.
- Cyclomatic complexity per method/function (flag >10).
- Duplication percentage (tool-based, e.g. jscpd/SonarQube if configured).
- Dependency graph / layering violations (existing static analysis if present).
- Count and location of existing CQRS-light and hexagonal architecture patterns already in use (so later agents compare against actual current state, not assumed absence).
Output: a metrics table per module, plus a short list of modules ranked worst-to-best on each metric. This file is fixed input to every Phase 1 agent — no agent may propose a change without citing which baseline metric it improves.