Remove the RSS/Atom feed — dead feature, never implemented, no evidence of demand

Remove the RSS/Atom Feed — Dead Feature, Never Implemented, No Evidence of Demand

Background

The release detail page links to an RSS feed in two places — an actions-bar button and a dedicated sidebar "Subscribe" card, both pointing at /musehub/repos/{repo_id}/releases.rss (musehub/templates/musehub/pages/release_detail.html, lines ~111-113 and ~328-335). No backend route implementing that URL exists anywhere in the codebase — a full-repo grep for RSS/Atom/feed patterns across musehub/api/routes/, musehub/templates/, and musehub/src/ turns up exactly these two template references and nothing else. This feature has never worked, for any release, on any repo, in any deployment. Every click on either link has always produced a 404.

The decision this ticket makes: remove it, don't build it. GitHub does support Atom feeds for commits/releases/tags, and real usage exists — dependency bots, security scanners, a slice of feed-reader holdouts — but it's genuinely long-tail, and GitHub keeps it because a stateless read-only endpoint over data that already exists costs them almost nothing to maintain. That calculus doesn't hold here: MuseHub has no evidence of any external consumer wanting this (the link has been silently broken with zero reported complaints), and there is a large backlog of higher-leverage, already-half-built work competing for the same engineering time (release CRUD completeness, org/quorum wiring, cross-repo proposals, the domain-plan tickets). Spending effort making a feed "fully functional and supercharged" for an audience of zero known consumers is the wrong bet right now.

If real demand for this ever surfaces, the right rebuild is not a blind GitHub clone: a Muse-native feed item could carry the structural changelog Muse already computes per release (commits, symbols touched, semver bump — the exact data muse release suggest already cites) directly in the feed entry, which would be a genuinely stronger release-watching tool than GitHub's plain "release published" Atom entry. That's named here as a deferred future option, not designed or scheduled — this ticket's job is the removal, not the eventual rebuild.

Goal

• Zero RSS/Atom/feed references remain anywhere on the site — no dead links, no orphaned UI affordances, no template referencing a route that doesn't exist.
• The release detail page renders cleanly with no empty or awkward layout gaps where the removed elements used to be.
• A lightweight regression guard exists so this specific failure mode — a template links to a URL with no backing route, and nobody notices because the link still renders fine — is systematically harder to reintroduce silently for the next half-built feature.

"Done" means: the audit in Phase 1 is real and complete (not just the two spots already found), every reference is removed and verified, and the regression guard is demonstrated to actually catch a reintroduced dead link, not just asserted to.

Non-Goals / Out of Scope

• Building a working RSS/Atom feed. Explicitly not done here — deferred to a future ticket if and when real demand actually appears.
• A general, site-wide dead-link audit. This ticket is scoped to RSS specifically, found by accident while fixing an unrelated release bug. Whether a broader link-integrity sweep is worth doing separately is flagged as an open question, not silently absorbed into this ticket's scope.
• Removing or changing anything else on the release detail page beyond the two RSS-related elements and whatever layout adjustment their removal requires.

Phases

Each phase is fully green before the next begins. Test IDs use the RSSRM_NN prefix.

Phase 1 — Confirm the full removal scope (no code changes)

• RSSRM_01 — Grep the entire codebase (templates, static JS/CSS, sitemap generation, developer docs, API route registration, and the muse CLI side) for every RSS/Atom/feed reference — confirm the two spots already found in release_detail.html are the complete set, not merely the first ones a narrower search happened to find.
• RSSRM_02 — Confirm whether any existing test asserts the RSS button renders or the feed route exists. If any do, catalog them here so Phase 2 removes them deliberately rather than leaving them to silently start failing.
• RSSRM_03 — Check whether any API response (e.g. a repo or release read endpoint) exposes a feed_url/rss_url field pointing at the same dead route — a template isn't the only place a dead reference could hide.

Phase 2 — Remove

• RSSRM_10 — Remove the actions-bar RSS button and the sidebar "Subscribe" card from release_detail.html. If removing the sidebar card leaves an empty or visually awkward section, adjust the surrounding layout — don't leave a hollow card shell where content used to be.
• RSSRM_11 — Remove any test collateral cataloged in RSSRM_02.
• RSSRM_12 — Remove now-unused CSS (rd-rss-btn and any RSS-specific sidebar-card styling) after confirming via search that nothing else references those classes.
• RSSRM_13 — Remove any API field found in RSSRM_03, with a check that no existing client (CLI, UI, or otherwise) reads it.

Phase 3 — Regression guard

• RSSRM_20 — Add a targeted test that renders (or statically checks) release_detail.html and asserts every href pointing at an internal MuseHub path resolves to a registered route. Scope this to the page(s) actually touched here, not a full site-wide crawler — that's a larger project than this ticket's trigger justifies (see Open Questions).
• RSSRM_21 — Self-test the guard: temporarily reintroduce a dead link in a throwaway fixture and confirm the new test actually fails on it, then confirm it passes once removed — a regression guard that hasn't been proven to catch the exact bug it exists for isn't proven at all.

Phase 4 — Docs

• RSSRM_30 — If RSS is mentioned anywhere in user-facing or developer documentation, remove or correct those references so the docs don't promise a feature that no longer exists (and, per Phase 1, never actually did).

Acceptance Criteria

• A full-codebase search for RSS/Atom/feed turns up nothing — not in templates, not in routes, not in docs, not in API response fields.
• release_detail.html renders with no empty or misaligned layout where the removed elements used to be — verified visually, not just by diffing the template source.
• The Phase 3 regression guard is demonstrated to catch a deliberately reintroduced dead link before being trusted as a real safeguard.
• No existing, unrelated test regresses.

Risks

• Layout risk: removing the sidebar "Subscribe" card outright, rather than replacing its content, could leave the sidebar looking sparse or unbalanced — check the rendered page, not just the template diff, before calling this done.
• Guard scope-creep risk: it's tempting to turn Phase 3 into a full site-wide link checker while already in the code. Resist that — a targeted guard on the specific page/pattern this ticket found is the right size; a broader sweep is a separate, explicitly-scoped project (see Open Questions) if it's wanted at all.
• Incomplete-audit risk: Phase 1's grep needs to genuinely cover static JS/CSS and sitemap generation, not just Python route files and HTML templates — a dead reference hiding in a .js file or a generated sitemap entry would defeat the point of calling this ticket complete.

Open Questions

• Is a broader, explicitly-scoped "audit the whole site for other dead links" project worth filing separately, now that one was found this way by accident? Not folded into this ticket either way — flagged for a decision, not assumed.
• If real demand for a release feed ever surfaces later, should the Muse-native redesign (structural changelog per feed item) get its own forward-looking ticket now, purely as a placeholder idea, or is that premature until actual demand exists? Leaning toward: don't file it yet — the point of removing this now is to stop carrying a feature nobody's asked for; pre-filing its hypothetical replacement would partially undercut that.

Implementation Order

Phase 1 → Phase 2 → Phase 3 → Phase 4. Phase 1 is strictly load-bearing — Phase 2 can't be confirmed complete until Phase 1's audit is actually done, not assumed from the two spots already found by one narrow search.

Plan-only issue. Deliverables should be checked off in place as they land — this is a small, contained removal, not a project requiring further decomposition into separate staging issues.