docs(tmdb): clarify user-provided API key policy - #1581
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ddce371a26
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Distributed builds ship **without a shared TMDB API key**. To use | ||
| metadata enrichment, users enable it and enter their own key under | ||
| `Settings > Metadata (TMDB)`. Key registration is available through the |
There was a problem hiding this comment.
For the no-shared-key builds described here, the application still labels SETTINGS.TMDB_API_KEY as “optional” and says it overrides a built-in key in every locale (for example, apps/web/src/assets/i18n/en.json:281-282). Because TmdbRuntimeService.isEnabled() silently evaluates to false when the toggle is enabled without a key, users following the Settings copy can save a configuration that produces no enrichment and no explanation; update the in-app wording or validation alongside this policy clarification.
AGENTS.md reference: AGENTS.md:L70-L71
Useful? React with 👍 / 👎.
| This is a project distribution policy, not a claim that TMDB's terms | ||
| categorically prohibit embedding an application key. A key shipped in a | ||
| client can be extracted and misused; revoking a shared key could interrupt |
There was a problem hiding this comment.
This clarification says the personal-key requirement is not a categorical interpretation of TMDB's terms, but the adjacent implementation documentation in libs/services/src/lib/tmdb/tmdb-config.ts still says that requiring each user to bring a key “matches TMDB's personal-use terms.” That leaves two authoritative descriptions giving opposite rationales and can cause future maintenance to reintroduce the legal claim this change is meant to remove; update that comment to describe the project distribution policy instead.
AGENTS.md reference: AGENTS.md:L70-L71
Useful? React with 👍 / 👎.
Greptile SummaryThis documentation-only PR clarifies the project's TMDB API-key distribution policy and aligns user and contributor guidance with existing runtime behavior.
Confidence Score: 5/5The documentation changes appear safe to merge and accurately describe the repository’s current key-selection and enrichment-gating behavior. No actionable discrepancy was found: the default key is empty, optional injection safely no-ops without a secret, user keys take precedence, and enrichment is disabled when no key is available. Important Files Changed
Reviews (1): Last reviewed commit: "docs(tmdb): clarify user-provided API ke..." | Re-trigger Greptile |
1 participant
What changed
Clarify in the README, TMDB architecture guide, capability roadmap, and CLAUDE.md that distributed builds require a user-provided TMDB API key. Document optional build-time injection, user-key precedence, and inactive enrichment when no key is available.
Why
The docs incorrectly described a shared key as present in release builds. Requiring a personal key is project policy to limit shared-key misuse and revocation impact, not a categorical claim about TMDB terms. Personal keys still remain subject to service throttling.
Related to #1497, closed separately as not planned. This PR changes documentation only.
Release note
Checks
git diff --checkpassed.pnpm run release:notes:validatepassed (47 notes).pnpm dlx prettier@3.9.6 --check README.md CLAUDE.md docs/architecture/tmdb-metadata-enrichment.md docs/architecture/tmdb-roadmap.mdreports formatting differences. Confirmed the same four files already have formatting differences on the base revision; broad reformatting is outside this change.