fix(public): replace internal submission-prep copy on app privacy pages - #61
fix(public): replace internal submission-prep copy on app privacy pages#61nish3451 wants to merge 2 commits into
Conversation
The Promptly and Drishti privacy pages still carried internal editorial
and submission-prep notes as visible copy on main: H1s spoke to the
launch calendar ("already public ahead of release", "already in place
before launch"), the hero lead referenced the "current planned launch
scope" and "final App Store privacy disclosures before release", the
aside was labeled "Current release scope" with "not publicly released
yet" and "currently planned launch configuration", the first card
eyebrow said "At launch", and the important note told visitors the
page and App Store privacy answers "should be updated before that
version is submitted".
Rewrite those passages as visitor-facing copy that describes what each
privacy policy covers, how data is used, and the choices available,
without referencing the internal submission process. Heading levels,
links, meta tags, chips, and JSON-LD are unchanged.
Public-site checks: heading hierarchy 44/44, link targets 77/77,
structured data 127/127, social preview 137/137, brand disambiguation
11/11, conversion signal 126/126, soft-404 19/19 — 541 checks, 0
failures.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
|
Warning Review limit reached
Next review available in: 35 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Comment |
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
The fleet keeps dispatching the same finding to multiple lanes, producing duplicate same-fix PR pairs: #36/#44 and #55/#56 are byte-identical or near-identical patches of the operator export --help fix, #39/#49 the offername article fix, #40/#52 the recording exporter --help fix, plus #38/#48/#51, #30/#61/#72, #45/#64, #42/#60, #43/#54 and #46/#74. Add a PR Duplicate Guard: - scripts/check-pr-duplicates.mjs compares a PR's diff against every other open PR (shared changed-file coverage >= 0.8 and patch similarity >= 0.5). Calibrated on all 79 open PRs on 2026-08-11: every pair above the thresholds was a genuine duplicate-cluster member, zero false positives. - .github/workflows/pr-duplicate-guard.yml runs it on every PR event and posts one marker comment naming the duplicate(s) and the canonical PR; the check fails loudly when a duplicate is found. Informational, not required. - scripts/test-pr-duplicates.mjs covers parsing, similarity, detection, and comment upsert with an injected API; wired into npm ci and npm test.
1 participant
What
Closes the lane-1 item: internal editorial and submission-prep notes are live as visible copy on public app pages.
On origin/main (2e3c00e), the four app product/support pages are already clean (merged PR #28), but the two app privacy pages still carried the internal submission-prep voice as visible copy:
Changes
Rewrote those passages as visitor-facing copy that describes what each privacy policy covers, how data is used, and the choices available — no references to the internal submission process:
public/promptly/privacy/index.htmlpublic/drishti/privacy/index.htmlHeading levels, links, meta tags, chips, and JSON-LD are unchanged.
Validation
node scripts/test-public-heading-hierarchy.mjs— 44 checks, 0 failuresnode scripts/test-public-link-targets.mjs— 77 checks, 0 failuresnode scripts/test-public-structured-data.mjs— 127 checks, 0 failuresnode scripts/test-public-social-preview.mjs— 137 checks, 0 failuresnode scripts/test-public-brand-disambiguation.mjs— 11 checks, 0 failuresnode scripts/test-public-conversion-signal.mjs— 126 checks, 0 failuresnode scripts/test-public-soft-404.mjs— 19 checks, 0 failuresFragment sweep of both pages for the old submission-prep vocabulary (app store / submission / submitted / before launch / before release / current release scope / planned launch / not publicly released / at launch / should be updated): zero hits.
Note: open PR #30 contains the same content fix for these two pages and can be closed in favor of this branch if desired; this branch is cut fresh from current origin/main with the identical reviewed copy.