[TASK] Fix Organization of Rover Documentation

[itsxallwater]

Articles in the site/rover/ directory are not reliably organized by module. The proper structure should follow:

1. Main Module i.e. AP Overview
2. Sub-category for the module, commonly Entry, Report and Procedure
3. Form specific document i.e. AP-E, AP-CONTROL
4. Any child articles for the form i.e. AP-E-1, AP-E-2

There are many instances of articles organized in ways that do not align to the above, i.e. CHECKS-E is nested beneath site/rover/AP-OVERVIEW/AP-ENTRY/AP-E/CHECKS-E/ when really it should exist at site/rover/AP-OVERVIEW/AP-ENTRY/CHECKS-E adjacent to the other CHECKS-E2, CHECKS-E3, CHECKS-E4 articles.

Work on this issue should include proper re-organization of articles like the CHECKS-E example as well as correction of any relevant links either within that article or in other articles referring to articles that receive re-organization. In some circumstances there may be a duplicated article, i.e. PARTS-E existing inside both /AP-OVERVIEW/ and /INV-OVERVIEW/ in which case the duplicates should be compared, merged and updated to exist only in one location.

---

Copilot Agent Prompt

Use this prompt in a Copilot Agent session to plan (not yet execute) the reorganization described above.

Copilot Agent Prompt

Repository: zumasys/docs
Issue Reference: #198
Scope Directory: site/rover/

Goal:
Audit and reorganize the Rover documentation under site/rover/ so that all articles follow the intended hierarchical structure:

1. Main Module directory (e.g., AP-OVERVIEW, INV-OVERVIEW, etc.)
2. Sub-category directory (commonly ENTRY, REPORT, PROCEDURE; others only if justified)
3. Form-level document (e.g., AP-E, AP-CONTROL, CHECKS-E, PARTS-E)
4. Child articles of a form (e.g., AP-E-1, AP-E-2)

Current Problem Example:
CHECKS-E is nested at:
site/rover/AP-OVERVIEW/AP-ENTRY/AP-E/CHECKS-E/
It should be at:
site/rover/AP-OVERVIEW/AP-ENTRY/CHECKS-E/
There may also be duplicate forms (e.g., PARTS-E under both AP-OVERVIEW and INV-OVERVIEW) requiring merge & canonical placement.

---

High-Level Tasks

1. Inventory

   • Output a directory tree of site/rover/ (depth ≤ 6), focusing on *-OVERVIEW modules.
   • List files whose logical depth after site/rover/ exceeds expected (more than: <MODULE-OVERVIEW>/<SUBCATEGORY>/<FORM>(/<child?>)).
   • Detect potential duplicates: same basename (e.g., PARTS-E.md) in multiple module trees.

2. Classification & Validation

   • Infer canonical module ownership for duplicates (e.g., AP vs INV).
   • Flag ambiguous placements (produce an “Ambiguities” section).

3. Reorganization Plan (NO MOVES YET)

   • Produce a mapping: original_path → proposed_new_path.
   • Reason for each: mis-nested | duplicate-merge | normalization.
   • Identify non-standard subcategory names; justify keeping or propose rename.

4. Duplicate Resolution

   • For each duplicate group: diff summaries.
   • Recommend merged canonical location & rationale.
   • Provide a merged content outline (sections to keep/remove).
   • Mark whether “safe to auto-merge” or needs manual review.

5. Link Impact Analysis

   • Search for references to any file slated to move.
   • Output: referencing_file → link_text → old_target.
   • Propose updated relative links.
   • Flag absolute URLs or anchor fragments that will break.

6. Execution Script (Staged – PLAN ONLY)

   • Prepare (but do not run) grouped git mv commands.
   • Include placeholders for merged file creation.
   • Provide a rollback strategy (e.g., git restore --staged / git checkout . instructions before committing).

7. Integrity & QA

   • Recommend link-check approach (simple script / tool).
   • Ensure no orphan child docs (e.g., AP-E-1 without AP-E).
   • List directories that would become empty—mark for deletion.
   • Verify no depth deeper than:
     site/rover/<MODULE-OVERVIEW>/<SUBCATEGORY>/<FORM>/<child?>

8. Acceptance Criteria

   • All form docs at: site/rover/<MODULE-OVERVIEW>/<SUBCATEGORY>/<FORM>(.md)
   • No unmerged duplicate form docs.
   • All internal links updated; no broken references.
   • A mapping file (suggest: site/rover/_reorg-map.md) documenting every move.
   • Child doc naming consistent (FORM-1, FORM-2, etc.).
   • No superfluous nesting directories.

---

Constraints & Conventions

• Preserve file extensions (.md, .mdx, etc.).
• Do not change substantive content except when merging duplicates (then note what changed).
• Use relative links (./FORM.md, ../OTHER-FORM.md).
• No trailing slashes in Markdown links.
• If a directory ends up with a single file and no structural value, list it for potential flattening (do not flatten automatically in the first pass).
• Flag inconsistent patterns: case differences, hyphen vs underscore, abbreviated subcategories (AP-ENT vs AP-ENTRY), stray index.md meaning an overview.

---

Phased Output Format (What to Produce Now)

Phase 1: Inventory & Findings
Phase 2: Duplicate Analysis
Phase 3: Proposed Mapping (YAML list)
Phase 4: Link Impact
Phase 5: Execution Commands (planned, not run)
Phase 6: QA Checklist
Phase 7: Open Questions / Ambiguities

Only produce Phases 1 & 2 first, then pause for confirmation.

---

Edge Cases to Watch

• Files differing only by case.
• Mixed naming conventions (hyphen vs underscore).
• Overly nested chains with unnecessary intermediate directories.
• index.md files representing module overviews vs redundant placeholders.
• Child documents that do not follow numeric suffix patterns.

---

Initial Instruction to Copilot Agent

Begin with Phase 1 (Inventory & Findings) and Phase 2 (Duplicate Analysis) only. Stop and await approval before generating mapping or move commands.

If any assumptions are unclear (e.g., which names qualify as module roots), list clarification questions instead of guessing.

---