chore: back-merge main into development to clear the release conflict - #481
Merged
Conversation
Release v1.1.0
Release v1.2.0
Release v1.2.1
…t does not exist The policy directed users to "Settings > Privacy > Delete Analytics Data". That control was removed as a non-functional stub (MAINT-173) and is absent from app/src, so the copy was an affirmative representation about a named control the app does not provide — the FTC Act §5 deception shape. Remedy (b): correct the copy, do not build the control. Compliance ruled that CCPA/GDPR/TDPSA require a designated request method rather than a self-service in-app control. Building it was independently rejected because usePostHog() returns undefined whenever the provider is unmounted — the analytics-OFF state, i.e. exactly when a user would reach for the control — so handleAnalyticsDeletion no-ops and still returns success, reproducing the misrepresentation in code. The replacement copy states only what is verifiable in source and already published elsewhere in the same document: analytics is opt-in default OFF, toggling it off stops collection immediately, server-side events are deleted after 90 days (§7.2), and earlier deletion is available via privacy@being.fyi, honored within 30 days (§7.3). Also corrected, because the same defect had two other shapes: - The identical claim was mirrored at docs/architecture/analytics-architecture.md, which no legal tooling watches. Left alone it would re-seed the claim from an internal doc presenting itself as the policy's mirror. - Five further stale in-app paths across privacy-policy, california-privacy and support. There is no "Settings" navigation root at all — the tab is Profile and the screen is "Privacy & Data". Export and Delete Account do exist, so those were path-naming defects, not missing controls. The iOS system path "Settings > Apple ID > Subscriptions" is not app navigation and is unchanged. Adds app/__tests__/privacy/analyticsControlClaims.privacy.test.ts, run by CI's Safety + privacy gates. It asserts the relation none of the three existing guards covered: legal-registry.js compares filenames and never reads prose; legal-site-freshness.js derives both sides of its comparison from the same markdown, so it fingerprinted the deception as fresh; and consumer-privacy-posture.test.ts never opens docs/legal. The new check asserts that a control path named in the legal copy resolves to a real label in PrivacyDataScreen.tsx. Per DEBUG-390, markdown is matched on the DIRECTIVE shape rather than bare presence, so the DPIA change log can record what it corrected without tripping its own guard; source is comment-stripped so the MAINT-173 prose warning does not match. A matcher-integrity block proves every regex still fires. legalContent.generated.ts is gitignored (app/.gitignore, DEBUG-178) and regenerates on postinstall/prestart/preios, so it is deliberately absent from this diff and must never be hand-edited. Verified: test:privacy 542 passed; legal-registry consistent; check:ci-test-coverage consistent; typecheck clean; no new lint errors. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CMQzeUa97ZCj4mnE1ZMLzS
fix: DEBUG-534 privacy policy names a control the app does not provide (hotfix to main)
Records `main`'s history on `development` with ZERO content change. The resolved tree is byte-identical to `origin/development` — verified with `git diff origin/development` (empty). Why it was needed. The v1.3.0 release PR opened CONFLICTING against `main` even though Phase 2.4 of /b-release found no divergence, and both checks were correct: - `main` carries hotfix PR #435 (`d1e6e840`, DEBUG-534 legal copy), which was backported to `development` by cherry-pick as `4b2119d7`, per the Hotfix Process. Cherry-pick rewrites the SHA, so Phase 2.4's `--cherry-pick --right-only` patch-id check correctly cleared it: `main` has no unique CONTENT. - But `development` then moved PAST that content. DEBUG-545 took privacy-policy.md 1.10 -> 1.11 and added three DPIA changelog rows. Git sees two independent edits to the same regions with no common ancestor for them, so a textual conflict remains even though one side is a strict superset of the other. Both conflicts resolved to `development`, which is the superset in each: docs/legal/privacy-policy.md main 1.10 vs dev 1.11 -> dev docs/legal/dpia-sensitive-wellness-data.md main empty vs dev rows 2.10/2.11/2.12 -> dev `docs/architecture/analytics-architecture.md` auto-merged and is likewise unchanged from `development`. Note for the Hotfix Process: CLAUDE.md states that after a cherry-pick backport "git handles identical content gracefully on the next release PR." That holds only while `development` does not subsequently edit the same lines. It did here, and the conflict surfaced at release time rather than at backport time. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkZagJp7dzojvrjY7uYwkh
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Zero content change. The merge result is byte-identical to
development—git diff origin/developmentis empty. This commit exists only to recordmain's history so git stops seeing divergence.Why the release PR conflicted
The v1.3.0 release PR (#480) opened
CONFLICTINGeven though/b-releasePhase 2.4 found no divergence. Both were correct:maincarries hotfix PR fix: DEBUG-534 privacy policy names a control the app does not provide (hotfix to main) #435 (d1e6e840, DEBUG-534 legal copy), backported todevelopmentby cherry-pick as4b2119d7per the documented Hotfix Process. Cherry-pick rewrites the SHA, so Phase 2.4's--cherry-pick --right-onlypatch-id check correctly reported thatmainhas no unique content.developmentthen moved past that content — DEBUG-545 tookprivacy-policy.md1.10 → 1.11 and added three DPIA changelog rows. Git sees two independent edits to the same regions, so a textual conflict remains even though one side is a strict superset.Resolution — development's side in both, being the superset
maindevelopmentdocs/legal/privacy-policy.mdVersion: 1.10Version: 1.11docs/legal/dpia-sensitive-wellness-data.mddocs/architecture/analytics-architecture.mdauto-merged and is also unchanged fromdevelopment.Worth recording
CLAUDE.md's Hotfix Process says that after a cherry-pick backport "git handles identical content gracefully on the next release PR." That holds only while
developmentdoes not subsequently edit the same lines. It did, and the conflict surfaced at release time rather than at backport time.🤖 Generated with Claude Code
https://claude.ai/code/session_01CkZagJp7dzojvrjY7uYwkh