Phase D · Phase E
Route Recovery Centre
Every HTML file is classified before any decision is made. Release evidence, generated placeholders, duplicate-name candidates and substantive devotional pages are kept separate—without deleting repository history.
No bulk deletion
A duplicate hash, missing homepage link or release-numbered filename is not sufficient evidence for deletion.
Canonical before public
Devotee navigation is driven by governed route records, source boundaries, search indexes and sitemaps—not by every repository file.
Safe repairs only
A link is considered safely repairable only when one unique existing target is resolved through an exact rule or controlled alias.
Full HTML classification
Understand what each file is before connecting it.
Loading Phase D–E evidence…
Controlled repair sequence
How unresolved connectivity is fixed.
Confirm canonical target
Verify the destination file, route status, title, source scope and current publication boundary.
Repair small batches
Apply only unique target fixes to governed pages, then rerun link validation before continuing.
Register meaningful content
Substantive orphan pages are added through the governed route-additions registry rather than direct homepage clutter.
Retain evidence
Release notes, checksums, manifests and tests remain in GitHub but are excluded from devotee navigation and deployment where appropriate.
Rebuild discovery
Update the route registry, local search, sitemap, related links and PWA cache for the canonical route.
Regression test
Validate desktop, mobile, keyboard, offline, metadata and source-status behaviour before marking the batch complete.