Current state
A developer who renames a post slug to improve its title will push the change without an entry in public/_redirects, permanently breaking all external links, search engine index entries, and newsletter or social shares pointing to the old URL. The _redirects.test.ts validates only format, not completeness, so the gap is invisible in CI. There is no comment or README section explaining that _redirects is permanent link-preservation infrastructure or that slug renames require a new entry. The feedId field in posts provides RSS feed stability, but the web URL has no equivalent protection explained anywhere.
Ideal state
- A comment block at the top of
public/_redirects states that it is permanent SEO and link-preservation infrastructure, that every slug rename requires a new 301 entry, and that removing any existing entry permanently breaks all links to that URL.
- README.md or CLAUDE.md includes a "Renaming a post" note that identifies adding a
_redirects entry as a required step.
- A developer who renames a slug discovers the required action without asking anyone.
Out of scope
- Automating redirect generation from git history.
- Adding completeness validation to
_redirects.test.ts (a separate improvement).
Starting points
public/_redirects — where the warning comment should be added at the top of the fileio/notion/getPosts.ts — the feedId field, the analogous RSS-stability mechanism to reference as prior art
QA plan
- Read the top of
public/_redirects — expect a comment block explaining the SEO purpose and the slug-rename requirement.
- Read README.md or CLAUDE.md — expect a note that renaming a post slug requires adding a
_redirects entry.
- Confirm
_redirects.test.ts still passes after the comment is added.
Done when
public/_redirects has a comment block at the top that makes the rename-requires-redirect invariant discoverable, and README.md or CLAUDE.md references it for developers performing slug renames.
Current state
A developer who renames a post slug to improve its title will push the change without an entry in
public/_redirects, permanently breaking all external links, search engine index entries, and newsletter or social shares pointing to the old URL. The_redirects.test.tsvalidates only format, not completeness, so the gap is invisible in CI. There is no comment or README section explaining that_redirectsis permanent link-preservation infrastructure or that slug renames require a new entry. ThefeedIdfield in posts provides RSS feed stability, but the web URL has no equivalent protection explained anywhere.Ideal state
public/_redirectsstates that it is permanent SEO and link-preservation infrastructure, that every slug rename requires a new301entry, and that removing any existing entry permanently breaks all links to that URL._redirectsentry as a required step.Out of scope
_redirects.test.ts(a separate improvement).Starting points
public/_redirects— where the warning comment should be added at the top of the fileio/notion/getPosts.ts— thefeedIdfield, the analogous RSS-stability mechanism to reference as prior artQA plan
public/_redirects— expect a comment block explaining the SEO purpose and the slug-rename requirement._redirectsentry._redirects.test.tsstill passes after the comment is added.Done when
public/_redirectshas a comment block at the top that makes the rename-requires-redirect invariant discoverable, and README.md or CLAUDE.md references it for developers performing slug renames.