You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Publishes the three legal documents as site pages, linked from the footer. English-only for now — the docs state a Portuguese version must follow (PT prevails for Brazilian users); tracked as a follow-up.
Pages
/terms — Terms of Service, 21 sections. CDC Art. 54 §4 clauses (7.3, 14, 15) rendered as bold highlighted panels; body text 16px (≥12pt, Art. 54 §3). The internal "Deployment Checklist" appendix was dropped per its own instruction ("remove before publishing").
/privacy — Privacy Policy, 14 sections, LGPD Art. 9 processing table as a real table.
/dpa — Data Processing Agreement, 20 sections + signature page + Annexes I–IV, all annex tables rendered.
Shared shell — LegalDoc.svelte: kicker, title, version/effective-date line, anchored contents nav, styled prose (tokens only, no new deps).
DPA Annex III sub-processors filled from the real stack: Google/YouTube, Netlify (hosting), Turso (database), OpenAI (transient classification). Privacy §5 updated to match.
Operator legal name / CNPJ / address brackets left as-is per owner decision — must be filled before these pages are treated as executed legal documents.
Drafting notes ("template for commercial use", "complete annex before execution", Word TOC fields) removed; docs cross-link to each other and keep all external links (YouTube ToS, Google privacy/revocation, ANPD).
Footer — Terms, Privacy, DPA added to the link row (built from LEGAL_DOCS).
Gates: svelte-check 0 errors/warnings, 208/208 tests (3 new for legal.ts), adapter-netlify build ✓. QA screenshots verified at desktop and 390px for all three pages (TOC anchors, tables, highlight blocks, footer links).
Note: branched from feat-pricing HEAD before PR #34 merged; diff against main is only 8ecbd79.
Added dedicated Terms of Service, Privacy Policy, and Data Processing Agreement pages.
Added footer links to all legal documents.
Included document versions, effective dates, tables of contents, responsive formatting, and SEO metadata.
Documentation
Published comprehensive policies covering service use, privacy, data processing, security, retention, rights, and compliance, including Brazilian-law requirements.
Tests
Added coverage to verify legal document content, navigation, links, and page availability.
Walkthrough
Adds shared metadata, reusable rendering, and prerendered routes for Terms, Privacy, and DPA documents. Adds legal content, tables of contents, SEO metadata, footer links, licensing notices, and registry tests.
Changes
Legal document publishing
Layer / File(s)
Summary
Document metadata and registry src/lib/landing/legal.ts, src/lib/landing/legal.test.ts
Defines legal-document types, shared version and effective-date constants, the ordered LEGAL_DOCS registry, and content validation tests.
Publishes the three legal documents as site pages, linked from the footer. English-only for now — the docs state a Portuguese version must follow (PT prevails for Brazilian users); tracked as a follow-up.
Pages
/terms — Terms of Service, 21 sections. CDC Art. 54 §4 clauses (7.3, 14, 15) rendered as bold highlighted panels; body text 16px (≥12pt, Art. 54 §3). The internal "Deployment Checklist" appendix was dropped per its own instruction ("remove before publishing").
/privacy — Privacy Policy, 14 sections, LGPD Art. 9 processing table as a real table.
/dpa — Data Processing Agreement, 20 sections + signature page + Annexes I–IV, all annex tables rendered.
Shared shell — LegalDoc.svelte: kicker, title, version/effective-date line, anchored contents nav, styled prose (tokens only, no new deps).
DPA Annex III sub-processors filled from the real stack: Google/YouTube, Netlify (hosting), Turso (database), OpenAI (transient classification). Privacy §5 updated to match.
Operator legal name / CNPJ / address brackets left as-is per owner decision — must be filled before these pages are treated as executed legal documents.
Drafting notes ("template for commercial use", "complete annex before execution", Word TOC fields) removed; docs cross-link to each other and keep all external links (YouTube ToS, Google privacy/revocation, ANPD).
Footer — Terms, Privacy, DPA added to the link row (built from LEGAL_DOCS).
Gates: svelte-check 0 errors/warnings, 208/208 tests (3 new for legal.ts), adapter-netlify build ✓. QA screenshots verified at desktop and 390px for all three pages (TOC anchors, tables, highlight blocks, footer links).
Note: branched from feat-pricing HEAD before PR #34 merged; diff against main is only 8ecbd79.
CodeAnt-AI Description
Publish Terms, Privacy Policy, and Data Processing Agreement pages
What Changed
Added /terms, /privacy, and /dpa pages with Brazilian legal disclosures, effective dates, version details, and section-by-section contents navigation
Added readable legal document formatting, responsive layouts, highlighted consumer-protection clauses, and scrollable data tables
Documented YouTube data use, LGPD rights, retention periods, process-and-discard handling, security measures, sub-processors, international transfers, refunds, and moderation responsibilities
Added footer links so visitors can access all three legal documents from the site
Impact
✅ Clearer terms for service use and billing ✅ Easier access to privacy rights and data-processing details ✅ Direct access to legal documents from every page
💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
@codeant-ai ask: Your question here
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
@codeant-ai ask: Can you suggest a safer alternative to storing this secret?
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
@codeant-ai: Your feedback here
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
@codeant-ai: Do not flag unused imports.
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
@codeant-ai: review
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
The reason will be displayed to describe this comment to others. Learn more.
This PR successfully implements the three legal document pages (Terms, Privacy, DPA) with proper structure and Brazilian legal compliance requirements. The implementation includes comprehensive tests, correct imports, and proper footer integration. One critical security issue was identified: the Google Privacy Policy URL uses HTTP instead of HTTPS, which must be fixed before merge to prevent potential man-in-the-middle attacks.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
Publish Terms/Privacy/DPA pages (EN) and link from footer
✨ Enhancement📝 Documentation🧪 Tests🕐 40+ Minutes
AI Description
• Add static /terms, /privacy, and /dpa pages with shared legal layout and anchored TOC.
• Centralize legal doc metadata (slug/label/title/version/effective date) for SEO and linking.
• Link legal docs from the footer and add tests guarding the canonical doc list.
The following are alternative approaches to this PR:
1. Render documents from Markdown (mdsvex/remark)
➕ Cleaner diffs and editing experience for long-form text
➕ Easier future EN/PT localization via separate content files
➕ Potential for auto-generated TOC
➖ Adds content pipeline/dependency and potential sanitization concerns
➖ More work to ensure table + highlight styling matches legal formatting constraints
2. Drive docs from a structured schema (JSON/YAML) + renderer
➕ Enforces consistency and can auto-validate placeholders/sections
➕ Simplifies generating TOC and repeated annex/table structures
➖ Higher upfront complexity
➖ Harder for legal text iteration compared to editing prose directly
Recommendation: Static Svelte routes + shared LegalDoc shell + centralized LEGAL_DOCS metadata is a pragmatic, dependency-free approach for prerendered marketing pages and consistent styling. If localization (PT) and frequent revisions become routine, consider moving document bodies to Markdown while keeping the LegalDoc shell and metadata module.
Files changed (10) +1582 / -0
Enhancement (6) +532 / -0
Footer.svelteRender legal links in footer from LEGAL_DOCS+4/-0
Render legal links in footer from LEGAL_DOCS
• Imports LEGAL_DOCS and iterates it to add Terms/Privacy/DPA links to the footer navigation alongside existing links.
+page.svelteAdd /dpa route with TOC and SEO meta tags+81/-0
Add /dpa route with TOC and SEO meta tags
• Creates a static SvelteKit page that sets title/description/OG meta from DPA_DOC, defines a detailed TOC (sections + annexes), and renders Dpa within LegalDoc plus Nav/Footer.
+page.svelteAdd /privacy route with TOC and SEO meta tags+70/-0
Add /privacy route with TOC and SEO meta tags
• Creates a static SvelteKit page that sets title/description/OG meta from PRIVACY_DOC, defines a section TOC, and renders Privacy within LegalDoc plus Nav/Footer.
+page.svelteAdd /terms route with TOC and SEO meta tags+77/-0
Add /terms route with TOC and SEO meta tags
• Creates a static SvelteKit page that sets title/description/OG meta from TERMS_DOC, defines a section TOC, and renders Terms within LegalDoc plus Nav/Footer.
Dpa.svelteAdd DPA document body (EN) with signature page and annexes+665/-0
Add DPA document body (EN) with signature page and annexes
• Introduces the full Data Processing Agreement content with anchored sections, cross-links to /terms and /privacy, and multiple annex tables (including sub-processors and transfer mechanism).
Privacy.svelteAdd Privacy Policy document body (EN) with LGPD processing table+142/-0
Add Privacy Policy document body (EN) with LGPD processing table
• Introduces the Privacy Policy content with section anchors, a rendered processing-activities table, YouTube API disclosures, and cross-links to /terms and /dpa.
Terms.svelteAdd Terms of Service document body (EN) with highlighted clauses+198/-0
Add Terms of Service document body (EN) with highlighted clauses
• Introduces Terms of Service content with anchored sections and prominent highlighted blocks for key clauses (e.g., disclaimers/limitations) and cross-links to Privacy and DPA pages.
Published retention promises contradict persistent storage of comment text and author identifiers
The DPA promises that raw comment content and author identifiers are not persistently stored and that only moderation outcomes are retained, but the runtime pipeline inserts the full comment text, author name, and author channel ID into the persistent comments table for every decision. Either change the implementation to discard these fields or correct the DPA before publishing it.
❌ Normal cron moderation persistently stores comment bodies and author identifiers.
❌ DPA retention and minimization disclosures contradict the production database behavior.
⚠️ Review queues and moderation history depend on these stored comment records.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/lib/components/landing/legal/Dpa.svelte
**Line:** 169:180
**Comment:***Api Mismatch: The DPA promises that raw comment content and author identifiers are not persistently stored and that only moderation outcomes are retained, but the runtime pipeline inserts the full comment text, author name, and author channel ID into the persistent `comments` table for every decision. Either change the implementation to discard these fields or correct the DPA before publishing it.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Critical
2026-08-01 20:00
The terms promise an available Portuguese version that is not published by the new routes
The Terms claim that English and Portuguese versions are both published and equally available before acceptance, but this PR adds only the English document and the routes render only the English component. Brazilian users therefore cannot access the promised prevailing Portuguese version; either publish and link the Portuguese version or remove the availability claim until it exists.
❌ Brazilian users cannot access the promised prevailing version.
⚠️ Pre-acceptance language availability disclosure is inaccurate.
⚠️ Portuguese legal review and contract interpretation are unavailable.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/lib/components/landing/legal/Terms.svelte
**Line:** 182:182
**Comment:***Api Mismatch: The Terms claim that English and Portuguese versions are both published and equally available before acceptance, but this PR adds only the English document and the routes render only the English component. Brazilian users therefore cannot access the promised prevailing Portuguese version; either publish and link the Portuguese version or remove the availability claim until it exists.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Major
2026-08-01 20:00
Security
The recipient disclosure omits service providers that receive or store user and comment data
The policy says personal data is shared only with the listed recipients, but it omits OpenAI even though comment text is sent to both the moderation and tone-classification endpoints, and omits Turso even though moderation records are stored in the Turso-backed database. This makes the recipient and international-transfer disclosures incomplete; list all actual processors consistently with Annex III.
❌ Turso-backed moderation storage is absent from disclosures.
⚠️ International-transfer information is incomplete for listed processors.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/lib/components/landing/legal/Privacy.svelte
**Line:** 100:106
**Comment:***Security: The policy says personal data is shared only with the listed recipients, but it omits OpenAI even though comment text is sent to both the moderation and tone-classification endpoints, and omits Turso even though moderation records are stored in the Turso-backed database. This makes the recipient and international-transfer disclosures incomplete; list all actual processors consistently with Annex III.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Critical
2026-08-01 20:00
Logic error
Legal tables are rendered below the document's stated minimum readable body size
The shared legal-document styles reduce all table content to 14px, and table headers to 10px, despite the document requirements and surrounding comment stating that body text must be at least 16px (12pt). This makes the LGPD processing table and DPA annex tables non-compliant with the stated minimum; keep table cells at the required body size and adjust layout responsively instead.
⚠️ DPA Annex tables inherit the same undersized typography.
⚠️ Legal-document readability is reduced on every published page.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/lib/components/landing/legal/LegalDoc.svelte
**Line:** 185:189
**Comment:***Logic Error: The shared legal-document styles reduce all table content to 14px, and table headers to 10px, despite the document requirements and surrounding comment stating that body text must be at least 16px (12pt). This makes the LGPD processing table and DPA annex tables non-compliant with the stated minimum; keep table cells at the required body size and adjust layout responsively instead.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Major
2026-08-01 20:00
Incomplete implementation
The binding terms expose unresolved operator-identity placeholders instead of the legal counterparty details
Section 21 still publishes literal placeholders for the operator's legal name, CNPJ, and registered address, while Section 1.1 makes that identification part of the binding contract. Publishing the page in this state leaves users with an incomplete operator identity and prevents the stated contract from identifying the counterparty; replace the placeholders before exposing the Terms as effective.
❌ Public Terms do not identify the service operator.
⚠️ Users cannot verify the stated contractual counterparty.
⚠️ CNPJ and registered-address disclosures remain incomplete.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/lib/components/landing/legal/Terms.svelte
**Line:** 194:194
**Comment:***Incomplete Implementation: Section 21 still publishes literal placeholders for the operator's legal name, CNPJ, and registered address, while Section 1.1 makes that identification part of the binding contract. Publishing the page in this state leaves users with an incomplete operator identity and prevents the stated contract from identifying the counterparty; replace the placeholders before exposing the Terms as effective.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
Major
2026-08-01 20:00
Inconsistent naming
The English legal document displays a Portuguese heading label
The published pages are described as English-only, but this new DPA page displays a Portuguese kicker above its English title. This creates a visible language mismatch on the document and should be translated to English or the English-only publication claim should be corrected.
⚠️ User-facing legal-page language consistency is reduced.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/routes/dpa/+page.svelte
**Line:** 72:72
**Comment:***Inconsistent Naming: The published pages are described as English-only, but this new DPA page displays a Portuguese kicker above its English title. This creates a visible language mismatch on the document and should be translated to English or the English-only publication claim should be corrected.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 9
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/lib/components/landing/legal/LegalDoc.svelte`:
- Around line 26-40: Update the legal route metadata passed to LegalDoc so each
route uses an English kicker value: set the terms route to “Terms of Service,”
the privacy route to “Privacy Policy,” and the DPA route to “Data Processing
Agreement.”
In `@src/lib/components/landing/legal/Privacy.svelte`:
- Line 26: In Privacy.svelte, update both occurrences of the statutory name
“Protecao” in the legal text to the correctly accented “Proteção,” including the
DPO title near section 1.3 and the occurrence around line 128. Do not change
surrounding wording.
- Line 108: Update the sub-processor disclosure in Privacy.svelte, including the
provider list near the referenced paragraph, to include OpenAI, LLC and Turso
(ChiselStrike, Inc.) or clearly state their processing functions. Keep the
existing Netlify, Inc. and Stripe, Inc. disclosures and ensure the Privacy
Policy list aligns with Dpa.svelte Annex III.
In `@src/lib/components/landing/legal/Terms.svelte`:
- Line 87: Wrap each highlighted clause in Terms.svelte—including the
occurrences around lines 87 and 142–150—in a block-level paragraph element,
matching the structure used by Privacy.svelte, while preserving the existing
strong class="highlight" markup and text.
- Line 194: Replace the operator identity placeholders in Section 21 of
src/lib/components/landing/legal/Terms.svelte at lines 194-194 with the legal
name, CNPJ, and registered address. Apply the identical values to Section 1.1 in
src/lib/components/landing/legal/Privacy.svelte at lines 24-24; if those values
are unavailable, gate the footer links instead of publishing either document
with placeholders.
- Line 65: Update the Google Privacy Policy link in Terms.svelte section 5.2 to
use https://policies.google.com/privacy instead of the insecure legacy URL, and
apply the same URL update to the corresponding link in Privacy.svelte.
In `@src/routes/terms/`+page.svelte:
- Line 68: Use the same English kicker value, such as “Legal”, for the LegalDoc
components in src/routes/terms/+page.svelte:68-68,
src/routes/privacy/+page.svelte:61-61, and src/routes/dpa/+page.svelte:72-72.
Keep the existing Portuguese strings for the Portuguese document versions.
- Around line 32-63: Move the repeated legal-page metadata and table-of-contents
wiring into shared code: add a toc field to the LegalDoc type and its document
definitions in legal.ts, create a reusable component for the shared svelte:head
tags, and update the legal routes to consume it. Keep each route’s toc alongside
its corresponding document metadata, while preserving the route-specific kicker
and content component behavior.
- Around line 22-30: Because the terms page relies on static prerendering, add a
route-level `prerender` export set to true in the terms page route module
(`+page.ts`). Keep the existing `+page.svelte` content unchanged and place the
configuration before the route depends on the static-route exception.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
Push a commit to this branch (recommended)
Create a new PR with the fixes
ℹ️ Review info⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 49f8a48d-e2a9-4b2b-b594-72bdf9ea85f6
📥 Commits
Reviewing files that changed from the base of the PR and between 9dd7f32 and 8ecbd79.
src/routes/dpa/+page.svelte:72 → Data Processing Agreement
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/lib/components/landing/legal/LegalDoc.svelte` around lines 26 - 40,
Update the legal route metadata passed to LegalDoc so each route uses an English
kicker value: set the terms route to “Terms of Service,” the privacy route to
“Privacy Policy,” and the DPA route to “Data Processing Agreement.”
The newly added Terms and Privacy Policy state they are published in both English and Portuguese
(and Terms says both versions are equally available before acceptance), but the documents introduced
here are English-only, making the published legal text internally inconsistent.
+<p><strong>20.1</strong> These Terms are published in English and Portuguese. For users domiciled in Brazil, the Portuguese version prevails. Both versions are equally available before acceptance.</p>
Relevance
●●● Strong
Internal inconsistency in published legal text; likely to adjust wording to match EN-only reality.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
Both legal documents are written in English but explicitly claim Portuguese versions are already
published/available, which is contradictory for users reading these pages.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
### Issue description
The Terms and Privacy Policy pages claim Portuguese versions are already published/available (and that PT prevails for Brazilian users), but this PR only ships English document content. This creates an internal inconsistency in the legal pages.
### Issue Context
- Terms currently states both EN and PT are published and “equally available before acceptance”.
- Privacy currently states it is published in English and Portuguese.
- DPA wording is less absolute (“shall be made available”), but still suggests PT is expected.
### Fix Focus Areas
- src/lib/components/landing/legal/Terms.svelte[180-183]
- src/lib/components/landing/legal/Privacy.svelte[141-142]
### Suggested fix
Either:
1) Add and publish Portuguese versions (routes + content) and ensure the UI exposes them, OR
2) Update the language clauses to reflect the current English-only state (e.g., “published in English; Portuguese version will be made available; for Brazilian users the Portuguese version will prevail once published”), removing “equally available before acceptance” until true.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
2. Relative import in legal.test.ts📘 Rule violation⚙ Maintainability
Description
src/lib/landing/legal.test.ts imports src/lib code via a relative path (./legal) instead of
using the $lib alias. This violates the import convention and can lead to inconsistent import
styles.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
PR Compliance ID 2401155 requires imports that resolve into src/lib to use the $lib alias, not
relative paths. The new test file imports ./legal, which resolves to src/lib/landing/legal.ts.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
A relative import is used to reference a module under `src/lib`, but the project requires using the `$lib` alias for `src/lib` imports.
## Issue Context
This keeps imports consistent and resilient to refactors.
## Fix Focus Areas
- src/lib/landing/legal.test.ts[19-21]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The new legal routes state in comments that they are prerendered static pages, but this PR doesn’t
show any explicit prerender configuration for these routes or a global prerender default, making the
comment potentially misleading and the behavior unclear.
+ // I12 exception (approved for static marketing routes, same as the+ // homepage): this page is fully static and prerendered — there is no data+ // loading, so loading/empty/error states cannot occur and SSR always+ // renders the populated page.
Relevance
●● Moderate
They’ve accepted documenting static-route exceptions in comments, but prerender behavior/config
proof is unclear.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
The routes explicitly claim prerendering in comments, while the provided kit configuration only sets
the Netlify adapter and does not show any prerender defaults; the route files themselves also don’t
show prerender exports.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
### Issue description
The new /terms, /privacy, and /dpa pages include comments asserting they are “fully static and prerendered”, but the PR does not explicitly configure prerendering in the route files, and the shown SvelteKit config does not set a prerender default.
### Issue Context
This is primarily a maintainability/configuration clarity problem: comments imply a specific build/deploy behavior that is not established by the code shown.
### Fix Focus Areas
- src/routes/terms/+page.svelte[21-25]
- src/routes/privacy/+page.svelte[21-25]
- src/routes/dpa/+page.svelte[21-25]
- svelte.config.js[19-31]
### Suggested fix
Choose one:
- If these pages should be prerendered: add explicit `prerender = true` for these routes (e.g., create `+page.ts` next to each with `export const prerender = true;`, or configure an appropriate parent layout/global default).
- If they are intentionally SSR-rendered: update/remove the “prerendered” wording in the comments so they accurately describe the route behavior.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Several newly added Svelte components lack a <script lang="ts"> block, violating the requirement
that new components use TypeScript/Svelte 5 runes patterns. This can lead to inconsistent component
conventions and tooling behavior across the codebase.
+<p>This Policy provides the information required by Article 9 of the Brazilian General Data Protection Law (Lei no 13.709/2018 — LGPD) in a clear, adequate and ostensible manner, and includes the disclosures required by the YouTube API Services Terms of Service.</p>++<h2 id="s1">1. Who We Are and What This Policy Covers</h2>+<p><strong>1.1</strong> Moderaty is a YouTube comment moderation service operated by [legal name], a sole proprietorship registered in Brazil, CNPJ [number], registered address [address] (Moderaty, we, us). For the personal data described in this Policy, Moderaty is the data controller under the LGPD.</p>+<p><strong>1.2</strong> This Policy covers personal data of our users (YouTube channel owners and their authorized team members) and of people who contact us. It also explains, for transparency, how comment data flows through the Service — but note that for comment data we act as processor on behalf of the channel owner, who is the controller (Section 3).</p>+<p><strong>1.3</strong> Our Data Protection Officer (Encarregado de Protecao de Dados) is Andrew Philip Weilbacher, reachable at <a href="mailto:contact@marketingprowess.simplelogin.com">contact@marketingprowess.simplelogin.com</a>. The DPO acts with independence and technical autonomy, in accordance with ANPD Resolution CD/ANPD no 18/2024.</p>+<p><strong>1.4</strong> <strong class="highlight">PROVIDING CERTAIN PERSONAL DATA (ACCOUNT AND BILLING INFORMATION) IS A CONDITION FOR USING THE SERVICE, BECAUSE WITHOUT IT WE CANNOT CREATE YOUR ACCOUNT, CONNECT YOUR CHANNEL, OR PROCESS PAYMENTS. WHERE THAT IS THE CASE, THIS FACT IS DISCLOSED HERE WITH PROMINENCE, AS REQUIRED BY ARTICLE 9, §3, OF THE LGPD. YOUR RIGHTS AND HOW TO EXERCISE THEM ARE IN SECTION 10.</strong></p>
Relevance
● Weak
Team previously rejected adding even empty <script lang="ts"> just to satisfy a rule.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
PR Compliance ID 2401125 requires new .svelte components to include a <script lang="ts"> block,
but the newly added Privacy.svelte, Terms.svelte, and Dpa.svelte files begin with and contain
only markup in their opening sections with no TypeScript script block present, demonstrating they do
not meet the requirement.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
Newly added `.svelte` components in `src/lib/components/landing/legal/` are missing the required `<script lang="ts">` block, violating the TypeScript/Svelte 5 runes compliance requirement.
## Issue Context
PR Compliance (ID 2401125) requires new Svelte components to use TypeScript via `<script lang="ts">` and follow Svelte 5 runes APIs; the added legal components currently contain only markup and no script block.
## Fix Focus Areas
- src/lib/components/landing/legal/Privacy.svelte[1-30]
- src/lib/components/landing/legal/Terms.svelte[1-35]
- src/lib/components/landing/legal/Dpa.svelte[1-45]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The reason will be displayed to describe this comment to others. Learn more.
2. Relative import in legal.test.ts📘 Rule violation⚙ Maintainability
src/lib/landing/legal.test.ts imports src/lib code via a relative path (./legal) instead of
using the $lib alias. This violates the import convention and can lead to inconsistent import
styles.
Agent Prompt
## Issue description
A relative import is used to reference a module under `src/lib`, but the project requires using the `$lib` alias for `src/lib` imports.
## Issue Context
This keeps imports consistent and resilient to refactors.
## Fix Focus Areas
- src/lib/landing/legal.test.ts[19-21]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The new legal routes state in comments that they are prerendered static pages, but this PR doesn’t
show any explicit prerender configuration for these routes or a global prerender default, making the
comment potentially misleading and the behavior unclear.
Agent Prompt
### Issue description
The new /terms, /privacy, and /dpa pages include comments asserting they are “fully static and prerendered”, but the PR does not explicitly configure prerendering in the route files, and the shown SvelteKit config does not set a prerender default.
### Issue Context
This is primarily a maintainability/configuration clarity problem: comments imply a specific build/deploy behavior that is not established by the code shown.
### Fix Focus Areas
- src/routes/terms/+page.svelte[21-25]
- src/routes/privacy/+page.svelte[21-25]
- src/routes/dpa/+page.svelte[21-25]
- svelte.config.js[19-31]
### Suggested fix
Choose one:
- If these pages should be prerendered: add explicit `prerender = true` for these routes (e.g., create `+page.ts` next to each with `export const prerender = true;`, or configure an appropriate parent layout/global default).
- If they are intentionally SSR-rendered: update/remove the “prerendered” wording in the comments so they accurately describe the route behavior.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Google Privacy Policy URL over HTTP (amazon-q, CodeRabbit — Terms §5.2, Privacy §4.2) — valid; upgraded to https://policies.google.com/privacy in both docs (link and text).
"Protecao" misspelling (CodeRabbit — Privacy §1.3, §10.3) — valid; the docx source had lost the diacritics. Now "Proteção" in both places, matching Terms §21.
Privacy §5 sub-processor list missing OpenAI and Turso (CodeRabbit, Major) — valid; §5(a) now names Netlify, Turso (ChiselStrike), OpenAI (transient classification only), and Stripe, aligned with DPA Annex III.
Portuguese availability misrepresented (Qodo, Action required — Terms §20.1, Privacy §14.1) — valid; both clauses now state the documents are published in English and that a Portuguese version will be made available and will prevail for Brazilian users once published. (PT versions are a planned follow-up.)
Highlight clauses not wrapped in block elements (CodeRabbit — Terms 7.3, 14.1, 14.2, 15.1, 15.2) — valid; all five are now <p><strong class="highlight">, matching Privacy §1.4.
"Prerendered" comment unbacked by config (Qodo, CodeRabbit) — valid for these routes; each legal route now has +page.ts with export const prerender = true, so the I12 comment is accurate.
TOC + head metadata duplicated across three routes (CodeRabbit, Major — repo rule "DO NOT copy and paste code") — valid; toc and kicker moved into LEGAL_DOCS in legal.ts, and a shared LegalPage.svelte now renders head/Nav/LegalDoc/Footer. Routes are ~10 lines each.
Portuguese kicker over English title (CodeRabbit, Minor) — accepted; kicker is now the docs' English subtitle "YouTube Comment Moderation Service" for all three pages.
Every fix above is covered by a new guard test in legal.test.ts (red before the fix, green after — 10 tests total).
Declined (with reasons):
Fill [legal name] / CNPJ / address placeholders (CodeRabbit, Major) — deliberate owner decision: the operator entity is not yet registered, so the brackets stay until the real values exist rather than publishing a guessed identity. Flagged in the PR body from the start as a pre-execution must-fill.
legal.test.ts should import via $lib (Qodo) — not the repo convention: sibling tests (faq.test.ts, queue-script.test.ts, pricing-faq.test.ts) all import the sibling module relatively (./faq, etc.). Kept consistent with them.
110-112: 🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
Publish the Portuguese transfer disclosure before using ANPD SCCs.
Resolution 19/2024, Art. 17 §2, requires a Portuguese website disclosure covering transfer details, destinations, responsibilities, security, and data-subject rights. Clause 14.4 requires SCC information provided to data subjects in Portuguese. The current Policy and DPA are English, and Annex IV only incorporates the SCCs by reference. Add the Portuguese disclosure and complete, unmodified ANPD SCCs to each transfer contract.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/lib/components/landing/legal/Privacy.svelte` around lines 110 - 112, Add
a Portuguese-language international transfer disclosure covering transfer
details, destinations, party responsibilities, security measures, and
data-subject rights before the section describing ANPD standard contractual
clauses. Include the complete, unmodified ANPD SCC text in each applicable
transfer contract rather than relying on Annex IV incorporation by reference,
and preserve the existing Article 33 mechanism disclosures.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/lib/components/landing/legal/Privacy.svelte`:
- Line 103: Update the OpenAI disclosure in Privacy.svelte and the corresponding
language in Dpa.svelte to accurately reflect the configured retention period, or
configure an eligible OpenAI retention control and document that control. Ensure
the disclosure covers both OpenAI endpoints and removes the inaccurate “no
retention” statement.
In `@src/lib/landing/legal.test.ts`:
- Around line 99-104: Update the test around “discloses the same sub-processors”
to read both the Privacy and DPA documents using readComponent, then assert each
required provider is contained in both document contents. Preserve the existing
provider list and ensure the test cannot pass when a provider is missing from
Dpa.svelte.
---
Outside diff comments:
In `@src/lib/components/landing/legal/Privacy.svelte`:
- Around line 110-112: Add a Portuguese-language international transfer
disclosure covering transfer details, destinations, party responsibilities,
security measures, and data-subject rights before the section describing ANPD
standard contractual clauses. Include the complete, unmodified ANPD SCC text in
each applicable transfer contract rather than relying on Annex IV incorporation
by reference, and preserve the existing Article 33 mechanism disclosures.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
Push a commit to this branch (recommended)
Create a new PR with the fixes
ℹ️ Review info⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 56a71fe3-9ebd-4ed3-9ac2-412acffe1751
📥 Commits
Reviewing files that changed from the base of the PR and between dc5cacd and 8147f2c.
<li>(a) Infrastructure and service providers acting as our sub-processors or processors under contract — hosting provider Netlify, Inc. (United States), database provider Turso (ChiselStrike, Inc.), classification provider OpenAI, LLC (transient comment classification only, no retention, no model training), payment processor Stripe, Inc. — limited to what each needs to perform its function;</li>
OpenAI API data retention default abuse monitoring logs 30 days Zero Data Retention Modified Abuse Monitoring endpoint eligibility official documentation
💡 Result:
By default, the OpenAI API retains data, including prompts and responses, for up to 30 days for abuse monitoring purposes [1][2][3]. After this period, data is removed unless legal requirements necessitate longer retention [2][3]. For organizations with specific security or compliance needs, OpenAI offers Zero Data Retention (ZDR) and other advanced retention controls [4][5][6]. Key details regarding these configurations include: 1. Zero Data Retention (ZDR): Under a ZDR agreement, API inputs and outputs are not logged and are not retained by OpenAI [3]. This option is not a default feature but is available for eligible, qualifying use cases [7][8][6]. Interested organizations must typically coordinate with OpenAI sales to establish eligibility and the necessary agreements [9][8]. 2. Advanced Retention Controls: OpenAI provides administrative APIs that allow organizations to configure specific retention policies at the project level [4][5]. Available types include [4][5]: - organization_default: Follows the standard retention policy [5]. - zero_data_retention: Configures the project for ZDR [5]. - modified_abuse_monitoring: A specialized retention configuration [4]. - enhanced_zero_data_retention: An advanced tier of ZDR [4]. - enhanced_modified_abuse_monitoring: An advanced tier of modified abuse monitoring [4]. Organizations can retrieve or update these project-level settings using the OpenAI API (e.g., via the /v1/organization/projects/{project_id}/data_retention endpoint) [4][5]. Because eligibility is determined on a per-customer basis, users seeking ZDR or modified monitoring often report that initiating the process requires contacting OpenAI Sales or relevant account management teams [9][8]. Documentation indicates that these controls are part of a broader suite of enterprise-grade privacy and compliance tools designed for businesses with sensitive data requirements [6].
Correct the OpenAI retention disclosure. The service sends comments to both OpenAI endpoints, but its configuration defines no ZDR or Modified Abuse Monitoring control. OpenAI retains API data for up to 30 days by default for abuse monitoring. Configure an eligible retention control, or state the actual retention period in Privacy.svelte and Dpa.svelte.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/lib/components/landing/legal/Privacy.svelte` at line 103, Update the
OpenAI disclosure in Privacy.svelte and the corresponding language in Dpa.svelte
to accurately reflect the configured retention period, or configure an eligible
OpenAI retention control and document that control. Ensure the disclosure covers
both OpenAI endpoints and removes the inaccurate “no retention” statement.
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Test both documents before claiming alignment.
This test reads only Privacy.svelte. It passes if a listed provider is removed from DPA Annex III. Read Dpa.svelte and assert that each required provider occurs in both documents.
Proposed fix
it('discloses the same sub-processors in the Privacy Policy as in DPA Annex III', () => {
const privacy = readComponent('privacy');
+ const dpa = readComponent('dpa');
for (const provider of ['Netlify', 'Turso', 'OpenAI', 'Stripe']) {
expect(privacy).toContain(provider);
+ expect(dpa).toContain(provider);
}
});
📝 Committable suggestion
‼️IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
it('discloses the same sub-processors in the Privacy Policy as in DPA Annex III',()=>{
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/lib/landing/legal.test.ts` around lines 99 - 104, Update the test around
“discloses the same sub-processors” to read both the Privacy and DPA documents
using readComponent, then assert each required provider is contained in both
document contents. Preserve the existing provider list and ensure the test
cannot pass when a provider is missing from Dpa.svelte.
…ation, dedupe legal docs, wider copy guardrail
- Terms §1.2/§7.3: acceptance and post-window finality were framed
around 'purchasing credits' only; generalized to every charge type
introduced in §6.1 (subscription, lifetime, top-ups)
- Terms §6.2/§6.3: promised cancellation and top-up configuration 'in
your account settings', a surface that does not exist; the mechanism
is now the Section 21 contact channels, matching reality
- PlanCard: body snippet wrapper is a div, not a p, so snippet content
is not restricted to phrasing content
- legal.ts: three doc literals shared kicker/version/effectiveDate
boilerplate (SonarQube duplication block); one defineDoc builder now
holds the shared fields
- pricing-faq guardrail now also reads the visible billing copy in the
plan panels, hero, math terminal, homepage section, and page meta —
the finding that it only policed the data sources was correct
- new failing tests landed before each fix (legal.test.ts: charge-type
scope, no phantom settings UI)
Declined, with rationale: the $lib-alias import rule (sibling
components in this repo import relatively, matching the existing files;
same finding rejected on PR #35), routing the hosted CTA to checkout
(no billing exists yet; this PR is copy-only; same finding rejected on
PR #33), and recoloring the mint cards' CTA (pink is the site's single
primary-action color, intentional).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
codeant-ai
Bot
added
the
size:XXL
![amazon-q-developer[bot]](https://avatars.githubusercontent.com/in/1220912?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
Publishes the three legal documents as site pages, linked from the footer. English-only for now — the docs state a Portuguese version must follow (PT prevails for Brazilian users); tracked as a follow-up.
Pages
/terms— Terms of Service, 21 sections. CDC Art. 54 §4 clauses (7.3, 14, 15) rendered as bold highlighted panels; body text 16px (≥12pt, Art. 54 §3). The internal "Deployment Checklist" appendix was dropped per its own instruction ("remove before publishing")./privacy— Privacy Policy, 14 sections, LGPD Art. 9 processing table as a real table./dpa— Data Processing Agreement, 20 sections + signature page + Annexes I–IV, all annex tables rendered.Shared shell —
LegalDoc.svelte: kicker, title, version/effective-date line, anchored contents nav, styled prose (tokens only, no new deps).Placeholders filled
Drafting notes ("template for commercial use", "complete annex before execution", Word TOC fields) removed; docs cross-link to each other and keep all external links (YouTube ToS, Google privacy/revocation, ANPD).
Footer — Terms, Privacy, DPA added to the link row (built from
LEGAL_DOCS).Gates: svelte-check 0 errors/warnings, 208/208 tests (3 new for
legal.ts), adapter-netlify build ✓. QA screenshots verified at desktop and 390px for all three pages (TOC anchors, tables, highlight blocks, footer links).Note: branched from
feat-pricingHEAD before PR #34 merged; diff against main is only8ecbd79.