feat(article): add the article read path

[aquie00t]

What does this PR do?

Stage 3 of the article feature — the read path.

Method	Path	Auth	Rate limit	Behaviour
GET	/api/v1/articles	optional	PUBLIC	published only, cached 60s
GET	/api/v1/articles/me	required	STANDARD	drafts included, never cached
GET	/api/v1/articles/:slug	optional	PUBLIC	404 when not visible

Draft containment now has both layers

Stage 1 shipped the first: every list query in the repository pins status to PUBLISHED. This stage adds the second — findBySlug deliberately returns an article of any status so an author can read their own draft back, and the use case decides who may see it.

A viewer who may not see it gets 404, not 403. A distinct status code for a draft that exists would confirm the slug, which is exactly the leak these two layers exist to prevent. An unknown author username returns an empty page for the same reason, rather than a 404 that would distinguish "no such user" from "user with nothing published".

The e2e suite asserts this directly: an unknown slug and a real draft slug must return the same status and the same error title.

GetMyArticlesUseCase has no cache dependency at all. Sharing a cache with the public list is precisely how a draft leaks into it, so the ability is absent rather than merely unused.

Cache

Key: articles:list:page:P:limit:L:tag:T:author:A:categories:C:followedOnly:F:user:U, TTL 60s, cleared by the articles:list:* pattern the write path already invalidates on publish, archive, and edits or deletes of a published article.

Two deliberate choices:

• The cached page is an explicit DTO, rebuilt field by field. get-posts.usecase.ts rehydrates with ...(data as any), which keeps stale shapes alive across deploys and lets the reader silently accept them. This one names every field and parses the dates back.
• Categories are sorted into the key, so ?categories=BACKEND,FRONTEND and ?categories=FRONTEND,BACKEND share one entry instead of splitting the cache.

Every filter appears in the key with absent values as literals (ALL, guest), so the key space stays flat and one pattern delete clears it.

Two things this run caught that type checking could not

1. A DI break that compiled cleanly. GetArticlesUseCase took a constructor parameter named followRepository, while the container registers followUserRepository:

AwilixResolutionError: Could not resolve 'followRepository'.
Resolution path: articleController -> getArticlesUseCase -> followRepository

Under awilix CLASSIC, arguments resolve by parameter name. tsc was perfectly happy; the failure appeared only when the container built the controller at boot. Fixed, and the constructor now carries a comment saying the names are load-bearing. Worth noting this is also why several older registrations use asFunction — the wrapper maps cradle keys to positional arguments, which hides the mismatch.

2. Route precedence. /articles/me must win over /articles/:slug, since me matches the slug pattern. find-my-way scores the static segment higher, confirmed by the route answering 401 rather than the slug route's 404 — and there is an e2e test pinning that behaviour so a future refactor cannot silently swallow the endpoint.

Verification

708 unit tests pass (687 existing + 21 new), lint, format:check and build clean.

I also booted the real app to check DI resolution and routing, since neither shows up in a type check. Only read queries were issued — development and production still share a connection string.

That boot surfaced something worth flagging separately, unrelated to this PR's correctness: the articles table does not exist in that database. Both merged migrations (add_articles and restore_missing_foreign_keys) are in main but have never been applied there, so the article endpoints answer 500 against it. Details in the PR comment.

The e2e suite here — including the dedicated draft-visibility and cache-isolation blocks — gets its first real run in CI.

---

Type of Change

• Bug fix
• New feature
• Refactor
• Documentation
• Chore

---

Checklist

• My branch follows the naming convention (feature/, fix/, chore/, docs/)
• My commits follow Conventional Commits
• I have tested my changes locally
• I have not introduced any breaking changes
• I have updated relevant documentation if needed

🤖 Generated with Claude Code

[aquie00t]

Flagging an operational issue found while booting the app for this PR — it is not caused by this branch, but it affects what is on main right now.

The articles table does not exist in the database that .env.development and .env.production both point at.

PrismaClientKnownRequestError:
Invalid `this.prisma.article.findUnique()` invocation
The table `public.articles` does not exist in the current database.

Two migrations are merged into main and have never been applied there:

• 20260824203007_add_articles — creates the article tables
• 20260824215030_restore_missing_foreign_keys — restores the 21 missing foreign keys

Neither runs automatically. The Dockerfile has no migration step, and render.yaml deploys on commit, so the deployed image contains the article routes while the database has no article tables. Any call to /api/v1/articles* in production answers 500 until migrations are applied.

The part that needs a decision: prisma migrate deploy applies both pending migrations. Since development and production still share one database, running it there would also apply the foreign-key repair — the exact change we wanted to rehearse on a dev branch first. It would delete the 2 orphaned post_likes rows and add 21 constraints to the live database in the same command.

So the ordering matters:

1. Create the Neon dev branch and point .env.development at it.
2. Run pnpm db:deploy against the dev branch. Both migrations apply, and the foreign-key repair is rehearsed against a copy of real data.
3. Only then decide on production, deliberately rather than as a side effect of wanting the article tables.

Happy to walk through step 2 once the branch exists.

[github-actions]

🎉 This PR is included in version 1.3.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀