docs(engine): verify git mv rename recognition in coverage/diff tooling

[lourincedaging0-commits]

Closes #4878. Single doc file (packages/loopover-engine/docs/coverage-safe-file-moves.md), no code moved — the throwaway test move was reverted per the issue's boundaries.

Verified answer to the question (does a moved file read as a rename, or a coverage-tripping delete-plus-add?), grounded in an empirical test against a real content-lane file in this repo:

• A plain git mv with no content change stages as R100 — 0 insertions / 0 deletions, so Codecov's diff-based patch gate (99%, 0% threshold per codecov.yml) has nothing to measure and coverage history carries forward.
• With rename detection off — i.e. when the move commit also edits the file and similarity drops below git's threshold — the same file re-surfaces as 117 added lines that must clear 99% patch, tripping the gate on unchanged behavior.
• Control: the already-merged extraction refactor(engine): extract the pull-request-target-key parser into loopover-engine #5762 did not depend on rename detection at all — it re-added the extracted code as a new file with a new covering test (the extract-as-new path).

Established workaround for every subsequent phase: move-only commits (byte-identical git mv, adapters/shims in separate files) or extract-as-new with a covering test — never a move blended with edits in one blob. This unblocks the extraction milestone (#4880 / #4879 / #4884) to proceed safely.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-14 13:35:48 UTC}

1 file · 1 AI reviewer · no blockers · readiness 100/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This is a pure documentation addition — a single new markdown file explaining git's rename-detection behavior for the coverage/patch gate, closing #4878. No code, config, schema, or test files are touched, so there's nothing to functionally verify beyond the doc's internal consistency, and the empirical git commands shown (R100 vs --no-renames numstat) are plausible and consistent with standard git rename-detection semantics. The PR correctly reverted the throwaway test move per the issue's boundaries, keeping the diff scoped to docs only.

Nits — 5 non-blocking

• The doc asserts specific numbers (117 added lines, 50% default similarity threshold) that a reader can't independently verify from the PR itself — consider linking the actual commit/branch where the empirical test was run, or noting it was done in a scratch branch not included in this PR.
• No cross-link from this new doc file into any developer-facing README or CONTRIBUTING doc, so future engine-extraction contributors may not discover it unless they already know to look in packages/loopover-engine/docs/.
• Consider adding a one-line pointer from packages/loopover-engine/README.md (or the repo's top-level CONTRIBUTING doc) to this new file so the extraction workaround is discoverable, not just archived.
• If the empirical git commands were run against a throwaway branch, note the branch/commit SHA in the doc for future auditability.
• Diff looks like trivial or whitespace-only churn — Reduce whitespace-only or formatting-only churn and keep the diff focused on substantive changes.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#4878
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 0 registered-repo PR(s), 0 merged, 0 issue(s).
Contributor context	❌ No public Gittensor match	lourincedaging0-commits; not a blocker.
Gate result	✅ Passing	No configured blocker found.
Improvement	⚠️ ℹ️ Insufficient signal	risk: low · value: insufficient-signal — Nothing measurable for the structural-improvement analyzers on this PR (e.g. no code files changed). LLM value judgment: moderate — The doc closes an explicitly cited open issue (#4878) with a concrete, well-reasoned answer and an actionable protocol that unblocks a named upcoming milestone (#4880/#4879/#4884), even though it is pure documentation with no code change to verify.

Review context

• Author: lourincedaging0-commits
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: HTML
• Contributor context: Public profile only; not a blocker.
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

[BETA] Chat with Gittensory

Ask Gittensory a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @gittensory ask <question> answers contribution-quality Q&A with source citations and freshness.
• @gittensory chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @gittensory mention with a real question is routed to the closest matching read-only command automatically -- no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

Gittensory approves — the gate is satisfied and CI is green.