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 <noreply@anthropic.com>

.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

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`.

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