Sync .cursor from suite (autodev orchestrator + monorepo skills)

.cursor/skills/refactor/SKILL.md

@@ -69,6 +69,7 @@ Both modes produce `RUN_DIR/list-of-changes.md` (template: `templates/list-of-ch
 | | | *Quick Assessment stops here* | |
 | 3 | `phases/03-safety-net.md` | Check existing tests or implement pre-refactoring tests (skip for testability runs) | GATE: all tests pass |
 | 4 | `phases/04-execution.md` | Delegate task execution to implement skill | GATE: implement completes |
+| 4.5 | (inline, testability runs only) | Produce `testability_changes_summary.md` listing every applied change in plain language, surface to user | GATE: user acknowledges summary |
 | 5 | `phases/05-test-sync.md` | Remove obsolete, update broken, add new tests | GATE: all tests pass |
 | 6 | `phases/06-verification.md` | Run full suite, compare metrics vs baseline | GATE: all pass, no regressions |
 | 7 | `phases/07-documentation.md` | Update `_docs/` to reflect refactored state | Skip if `_docs/02_document/` absent |
@@ -78,6 +79,20 @@ Both modes produce `RUN_DIR/list-of-changes.md` (template: `templates/list-of-ch
 - "refactor [specific target]" → skip phase 1 if docs exist
 - Default → all phases
 
+**Testability-run specifics** (guided mode invoked by autodev existing-code flow Step 4):
+- Run name is `01-testability-refactoring`.
+- Phase 3 (Safety Net) is skipped by design — no tests exist yet. Compensating control: the `list-of-changes.md` gate in Phase 1 must be reviewed and approved by the user before Phase 4 runs.
+- Scope is MINIMAL and surgical; reject change entries that drift into full refactor territory (see existing-code flow Step 4 for allowed/disallowed lists). Flagged entries go to `RUN_DIR/deferred_to_refactor.md` for Step 8 (optional full refactor) consideration.
+- After Phase 4 (Execution) completes, write `RUN_DIR/testability_changes_summary.md` as Phase 4.5. Format: one bullet per applied change.
+  ```markdown
+  # Testability Changes Summary ({{run_name}})
+
+  Applied {{N}} change(s):
+
+  - **{{change_id}}** — changed {{symbol}} in `{{file}}`: {{plain-language reason}}. Risk: {{low|medium|high}}.
+  ```
+  Group bullets by category (config extraction, DI insertion, singleton wrapping, interface extraction, function split). Present the summary to the user via the Choose format before proceeding to Phase 5.
+
 At the start of execution, create a TodoWrite with all applicable phases.
 
 ## Artifact Structure
@@ -94,6 +109,7 @@ analysis/research_findings.md            Phase 2
 analysis/refactoring_roadmap.md          Phase 2
 test_specs/[##]_[test_name].md           Phase 3
 execution_log.md                         Phase 4
+testability_changes_summary.md           Phase 4.5 (testability runs only)
 test_sync/{obsolete_tests,updated_tests,new_tests}.md  Phase 5
 verification_report.md                   Phase 6
 doc_update_log.md                        Phase 7

.cursor/skills/refactor/phases/01-discovery.md

@@ -19,7 +19,7 @@ Determine the input mode set during Context Resolution (see SKILL.md):
 
 ### 1g. Read and Validate Input File
 
-1. Read the provided input file (e.g., `list-of-changes.md` from the autopilot testability revision step or user-provided file)
+1. Read the provided input file (e.g., `list-of-changes.md` from the autodev testability revision step or user-provided file)
 2. Extract file paths, problem descriptions, and proposed changes from each entry
 3. For each entry, verify against actual codebase:
    - Referenced files exist
@@ -95,7 +95,7 @@ Also copy to project standard locations:
 
 **Critical step — do not skip.** Before producing the change list, cross-reference documented business flows against actual implementation. This catches issues that static code inspection alone misses.
 
-1. **Read documented flows**: Load `DOCUMENT_DIR/system-flows.md`, `DOCUMENT_DIR/architecture.md`, and `SOLUTION_DIR/solution.md` (if they exist). Extract every documented business flow, data path, and architectural decision.
+1. **Read documented flows**: Load `DOCUMENT_DIR/system-flows.md`, `DOCUMENT_DIR/architecture.md`, `DOCUMENT_DIR/module-layout.md`, every file under `DOCUMENT_DIR/contracts/`, and `SOLUTION_DIR/solution.md` (whichever exist). Extract every documented business flow, data path, architectural decision, module ownership boundary, and contract shape.
 
 2. **Trace each flow through code**: For every documented flow (e.g., "video batch processing", "image tiling", "engine initialization"), walk the actual code path line by line. At each decision point ask:
    - Does the code match the documented/intended behavior?
@@ -133,6 +133,8 @@ From the component analysis, solution synthesis, and **logical flow analysis**,
 9. Performance bottlenecks
 10. **Logical flow contradictions** (from step 1c)
 11. **Silent data loss or wasted computation** (from step 1c)
+12. **Module ownership violations** — code that lives under one component's directory but implements another component's concern, or imports another component's internal (non-Public API) file. Cross-check against `DOCUMENT_DIR/module-layout.md` if present.
+13. **Contract drift** — shared-models / shared-API implementations whose public shape has drifted from the contract file in `DOCUMENT_DIR/contracts/`. Include both producer drift and consumer drift.
 
 Write `RUN_DIR/list-of-changes.md` using `templates/list-of-changes.md` format:
 - Set **Mode**: `automatic`