From d4b406efff8268c13544834175fd309a1aec192f Mon Sep 17 00:00:00 2001 From: Mads Lorentzen Date: Sat, 1 Aug 2026 22:03:22 +0200 Subject: [PATCH] docs(privacy): stop calling a fork 'private working space'; warn at /setup time Forks of public GitHub repositories are always public, so SETUP.md section 8's 'your fork is private working space, so commit them' invited exactly the personal-data exposure it seemed to rule out - the observed failure mode behind several real forks that pushed filled-in profiles to public master. Section 8 now states the fork-is-public fact plainly and documents the safe alternative (private repo + template as upstream remote), and /setup's completion summary carries a matching privacy note at the exact moment profile data first lands in tracked files. Also backfills the CHANGELOG entry for #265. Prompted by rasstamann's discussion #266. Co-Authored-By: Claude Fable 5 --- .claude/commands/setup.md | 5 +++++ CHANGELOG.md | 13 +++++++++++++ SETUP.md | 2 +- 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/.claude/commands/setup.md b/.claude/commands/setup.md index 1a11029..518b324 100644 --- a/.claude/commands/setup.md +++ b/.claude/commands/setup.md @@ -384,6 +384,11 @@ Present a summary: > - `cv/main_example.tex` - Your LaTeX CV template > - `.claude/skills/job-scraper/search-queries.md` - Job search queries for `/scrape` > +> **Privacy note:** the files above now contain your personal data and are *tracked by git*. +> A GitHub fork of the template is always public (forks of public repos cannot be made +> private), so do not push these commits to a fork. Keep them local, or push to a private +> repository instead - see SETUP.md section 8 for the private-remote setup. +> > **Try it out:** > - Run `/scrape` to search for matching jobs right now > - Run `/apply` with a job posting URL to see the full application workflow diff --git a/CHANGELOG.md b/CHANGELOG.md index f24c8a8..2a94102 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -25,6 +25,13 @@ per-file diff commands. ### Security & privacy +- **SETUP.md no longer calls a fork "private working space"** - forks of public GitHub + repositories are always public, so that wording invited exactly the personal-data + exposure it seemed to rule out. Section 8 now states the fork-is-public fact plainly and + documents the safe alternative (a private repository with this repo as `upstream`), and + `/setup` ends with a matching privacy note the moment profile data first lands in + tracked files. Prompted by + [discussion #266](https://github.com/MadsLorentzen/ai-job-search/discussions/266). - **The gitignore guard now covers two more personal-data rules** - `security_guards.py` requires `cover_letters/Cover_*.*` (the uppercase cover-letter naming variant `/apply` recognizes) and `cv/*.txt` (ATS text extractions of tailored CVs) in `.gitignore`, so a @@ -33,6 +40,12 @@ per-file diff commands. ### Fixed +- `tools/check_upstream_updates.py` no longer reports a false "up to date with upstream" + when it silently falls back to a fork's own `origin` remote - the default state of a + plain fork clone, where the script compared the fork against itself and could never + detect upstream updates. It now warns that the fallback remote is not the template repo, + shows the `git remote add upstream` command to fix it, and names the ref it actually + compared against. (#265) - Removed the vestigial `cover_letters/OpenFonts/cover.cls` - an unreferenced remnant of the original font bundle that, since #252's class rename, ambiguously declared the same `cover` class as the real `cover_letters/cover.cls`. diff --git a/SETUP.md b/SETUP.md index 48a8880..2e34b7b 100644 --- a/SETUP.md +++ b/SETUP.md @@ -290,7 +290,7 @@ Upstream keeps improving the methodology files your fork has personalized, so pl **Prefer releases over raw `master`.** Tagged [releases](../../releases) are vetted checkpoints, each described in [CHANGELOG.md](CHANGELOG.md). Updating to a tag pulls a stable, documented state instead of whatever `master` happens to be mid-review. Fetch tags with `git fetch upstream --tags` and merge a release (for example `git merge v1.0.0`) when you want stability; pull `master` directly only when you specifically want the latest unreleased changes. The steps below apply either way - substitute the release tag for `upstream/master` where you see it. -1. **Commit your personalization to your fork.** `/setup` edits CLAUDE.md and the profile skill files in place — those edits are *yours*, and your fork is private working space, so commit them. The genuinely sensitive files (tracker, salary data, `documents/`, application archives) are gitignored and never enter git either way. An uncommitted working tree is the most common reason `git pull` refuses to merge at all (`Your local changes ... would be overwritten`). +1. **Commit your personalization - but know where those commits land.** `/setup` edits CLAUDE.md and the profile skill files in place; those edits are *yours*, and committing them is what lets updates merge cleanly. But a GitHub **fork of this repo is public** - forks of public repositories cannot be made private - so anything you commit *and push to a fork* is visible to anyone. If you want your profile in a remote at all, don't push it to a fork: create a **private** repository, push there, and add this repo as the `upstream` remote (`git remote add upstream https://github.com/MadsLorentzen/ai-job-search.git`) to keep receiving updates. Committing locally without pushing is also fine. The genuinely sensitive files (tracker, salary data, `documents/`, application archives) are gitignored and never enter git either way. An uncommitted working tree is the most common reason `git pull` refuses to merge at all (`Your local changes ... would be overwritten`). 2. **Preview what changed before pulling:** ```bash git fetch upstream # or origin, if you cloned the template directly