Retire obsolete portfolio Pages publication without service loss #638

🤖 Generated by the Agentic Engineer

User Story

As the portfolio operator, I want obsolete Pages publication safely retired through its configuration owner, so that an old business-site copy and abandoned hosting settings do not remain live after their source publisher was replaced.

Evidence and scope

Read-only checks on 18 October 2026 found the monorepo's default Pages URL still returns HTTP 200 with the older Devantler Tech business-site title. Its Pages API has no custom domain, and its current workflow list has no site/Pages publisher. The live business domain belongs to business-site's source-owned publisher. Removing a workflow did not retire the already deployed artifact.

Platform's default Pages URL returns HTTP 404, but a Pages setting remains without a custom domain. This is a candidate obsolete setting, not proof of a second functioning business site. Do not assume it can be deleted without checking its intended documentation ownership.

Native parent .github#56. Related: the portfolio Pages-policy spike, monorepo#4247 and monorepo#3939. No raw source/history/customer data, secrets, private topology or account billing details are needed in this public record.

Acceptance Criteria

• Freshly bind each candidate's current source/publisher, authoritative Pages settings, custom-domain/DNS ownership, public response and any active dependent links or workflows. Distinguish stale content from an intentionally retained project-documentation site. An incomplete read is HOLD, not permission to delete.
• For the confirmed obsolete monorepo site, decide between removal and an appropriately hosted minimal retirement/redirect, with the current canonical business domain preserved. Do not keep an old commercial website simply because its publisher is off. Record the exact intended result and migration/restore steps before changing it.
• Resolve the platform setting separately: preserve it if current project documentation needs it and satisfies the policy; otherwise retire the unused configuration. No blanket deletion across every repository.
• Express supported changes in .github's declarative source of truth and test its provider behavior. If the provider cannot safely express artifact retirement, prepare a narrowly scoped reviewed main-branch operation with exact identity/ownership guards and readback; do not mutate managed Pages settings out of band or widen the App's permissions to force it.
• Test actual good/mismatched-owner/unreadable-setting/remaining-publisher refusal paths without deleting a live site in tests. Preserve existing branch protections, domain ownership and the source-owned business-site publication. Retain only permitted restoration evidence; do not expose or republish an old confidential artifact to create a backup.
• After reviewed merge and authorized execution, verify the obsolete public URL no longer serves the old business content, the intended redirect/404 behavior is correct, current business-site EN/DA routes still work and the settings reconciler does not recreate retired Pages publication. Report separately which artifact and settings were removed and what can be restored.

Priority

High priority, Medium effort, Risk reduction. This is stale-publication remediation with a concrete observed URL, not a speculative security incident or authority to take any currently needed site offline. Do not change GitHub billing, repository visibility, code licences, DNS or production portal access as a side effect.