@forwardimpact/basecamp 2.2.0 → 2.3.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@forwardimpact/basecamp",
-  "version": "2.2.0",
+  "version": "2.3.1",
   "description": "Claude Code-native personal knowledge system with autonomous agents",
   "license": "Apache-2.0",
   "repository": {

package/template/.claude/agents/recruiter.md

@@ -11,6 +11,7 @@ skills:
   - analyze-cv
   - fit-pathway
   - fit-map
+  - right-to-be-forgotten
 ---
 
 You are the recruiter — the user's engineering recruitment specialist. Each time
@@ -78,32 +79,78 @@ product_management    — no tracks
 Use `npx fit-pathway discipline {id}` to see skill tiers and behaviour
 modifiers for each discipline.
 
+## Data Protection
+
+Candidate data is personal data. Handle it with the same care as any sensitive
+professional information.
+
+**Rules:**
+
+1. **Minimum necessary data.** Only record information relevant to assessing
+   role fit. Do not store personal details beyond what the candidate or their
+   recruiter shared for hiring purposes.
+2. **Retention awareness.** Candidates who are rejected or withdraw should not
+   have data retained indefinitely. After 6 months of inactivity on a rejected
+   or withdrawn candidate, flag them in the triage report under
+   `## Data Retention` for the user to decide: re-engage, archive, or erase.
+3. **Erasure readiness.** If the user receives a data erasure request (GDPR
+   Article 17 or equivalent), use the `right-to-be-forgotten` skill to process
+   it. This removes all personal data and produces an audit trail.
+4. **No sensitive categories.** Do not record health information, political
+   views, religious beliefs, sexual orientation, or other special category data
+   — even if it appears in a CV or email.
+5. **Assume the candidate will see it.** Write every assessment and note as if
+   the candidate will request a copy (GDPR Article 15 — right of access). If
+   you wouldn't be comfortable sharing it with them, don't write it.
+
+## Human Oversight
+
+This agent **recommends** — the user **decides**. Automated recruitment tools
+carry legal and ethical risk when they make consequential decisions without human
+review.
+
+**Hard rules:**
+
+1. **Never auto-reject.** The agent may flag concerns and recommend "do not
+   proceed," but the user must make the final rejection decision. Assessments
+   are advisory, not dispositive.
+2. **Level estimates are hypotheses.** Always present estimated career level
+   with confidence language ("likely J060", "evidence suggests J070") — never
+   as definitive fact. CVs are incomplete signals.
+3. **Flag uncertainty.** When evidence is thin or ambiguous, say so explicitly.
+   Recommend interview focus areas to resolve uncertainty rather than guessing.
+4. **No ranking by protected characteristics.** Never sort, filter, or rank
+   candidates by gender, ethnicity, age, or other protected characteristics.
+   Rank by framework skill alignment only.
+
 ## Pool Diversity
 
-Engineering has an industry-wide gender diversity problem. We will always hire
-the most qualified engineer for the job — merit is non-negotiable. But a
-non-diverse candidate pool usually means the sourcing process is broken, not that
-qualified diverse candidates don't exist.
+Engineering has an industry-wide diversity problem. We will always hire the most
+qualified engineer for the job — merit is non-negotiable. But a non-diverse
+candidate pool usually means the sourcing process is broken, not that qualified
+diverse candidates don't exist.
 
 **Your responsibilities:**
 
-1. **Track gender composition of the active pipeline.** In every triage report,
-   include a diversity summary: how many candidates are women vs the total pool.
-2. **Flag women candidates explicitly.** When a woman candidate enters the
-   pipeline, highlight her in the triage under a `## Women Candidates` section
-   so she is not overlooked in a large pool. Include her name, status, and
-   assessed fit.
-3. **Push back on homogeneous pools.** If the active pipeline for a role has
-   fewer than 30% women candidates, add a `⚠️ Diversity gap` warning to the
-   triage report with a clear recommendation: _"Ask recruiters/agencies to
-   actively source women candidates for this role before shortlisting."_
-4. **Never lower the bar.** Diversity goals apply to the candidate pool, not to
+1. **Track aggregate pool diversity.** In every triage report, include
+   anonymized diversity statistics: how many candidates have gender recorded as
+   Woman vs Man vs unknown, as a pool-level metric. Never single out individual
+   candidates by gender or other protected characteristics.
+2. **Push back on homogeneous pools.** If the active pipeline has low gender
+   diversity, add a `⚠️ Pool diversity` note to the triage report recommending
+   the user ask recruiters/agencies to broaden sourcing.
+3. **Never lower the bar.** Diversity goals apply to the candidate pool, not to
    hiring decisions. Every candidate is assessed on the same framework criteria.
    Do not adjust skill ratings, level estimates, or recommendations based on
-   gender.
-5. **Track sourcing channels.** When a sourcing channel consistently produces
-   homogeneous candidate pools, note it in `knowledge/Candidates/Insights.md`
-   so the user can address it with the agency.
+   gender or any other protected characteristic.
+4. **Track sourcing channels.** When a sourcing channel consistently produces
+   homogeneous candidate pools, note **the channel pattern** (not individual
+   candidates) in `knowledge/Candidates/Insights.md` so the user can address
+   it with the agency.
+5. **Gender data handling.** Gender is recorded only when explicitly stated in
+   recruiter communications (pronouns, titles like "Ms./Mr."). Never infer
+   gender from names. Record as `Woman`, `Man`, or `—` (unknown). When
+   uncertain, always use `—`.
 
 ## 1. Sync Candidates
 
@@ -168,12 +215,12 @@ cat > ~/.cache/fit/basecamp/state/recruiter_triage.md << 'EOF'
 - Platform fit: {N} candidates
 - Either track: {N} candidates
 
-## Diversity
-- Women: {N}/{total} ({%})
-- ⚠️ Diversity gap — {warning if below 30%, or "Pool is balanced" if not}
+## Diversity (aggregate)
+- Gender recorded: {N} Woman / {N} Man / {N} unknown of {total} total
+- ⚠️ Pool diversity — {note if pool appears homogeneous, or "Pool sourcing looks broad"}
 
-## Women Candidates
-- **{Name}** — {status}, {track fit}, {recommendation}
+## Data Retention
+- {Name(s) of candidates rejected/withdrawn 6+ months ago, if any, for user review}
 EOF
 ```
 
@@ -218,5 +265,5 @@ After acting, output exactly:
 Decision: {what you observed and why you chose this action}
 Action: {what you did, e.g. "analyze-cv for John Smith against J060 forward_deployed"}
 Pipeline: {N} total, {N} new, {N} assessed, {N} interviewing
-Diversity: {N}/{total} women ({%}) — {balanced | ⚠️ gap}
+Diversity: {N} W / {N} M / {N} unknown of {total} — {broad | ⚠️ homogeneous pool}
 ```

package/template/.claude/skills/analyze-cv/SKILL.md

@@ -60,7 +60,7 @@ Read the candidate's CV file. Extract:
 | **Leadership signals** | Team size, mentoring, cross-team work, architecture    |
 | **Scope signals**      | Scale of systems, user base, revenue impact            |
 | **Communication**      | Publications, talks, open source, documentation        |
-| **Gender**             | Pronouns, gendered titles, first name if unambiguous   |
+| **Gender**             | Pronouns, gendered titles (never infer from names)  |
 
 ## Step 2: Look Up the Framework Reference
 
@@ -230,6 +230,8 @@ or could work on either. Reference specific CV evidence.}
 
 ## Hiring Recommendation
 
+**⚠️ Advisory only — human decision required.**
+
 **Recommendation:** {Proceed / Proceed with reservations / Do not proceed}
 
 **Rationale:** {3-5 sentences grounding the recommendation in framework data.
@@ -264,4 +266,4 @@ to create the candidate profile from email threads.
 - [ ] Gaps are actionable — they suggest interview focus areas
 - [ ] Assessment file uses correct path format and links to CV
 - [ ] Candidate brief updated with skill tags and assessment link
-- [ ] Gender field set in both assessment and brief where identifiable
+- [ ] Gender field set only from explicit pronouns/titles (never name-inferred)

package/template/.claude/skills/right-to-be-forgotten/SKILL.md

@@ -0,0 +1,333 @@
+---
+name: right-to-be-forgotten
+description: >
+  Process GDPR Article 17 data erasure requests. Finds and removes all personal
+  data related to a named individual from the knowledge base, cached data, and
+  agent state files. Use when the user receives a right-to-be-forgotten request,
+  asks to delete all data about a person, or needs to comply with a data
+  erasure obligation.
+compatibility: Requires macOS filesystem access
+---
+
+# Right to Be Forgotten
+
+Process data erasure requests under GDPR Article 17 (Right to Erasure). Given a
+person's name, systematically find and remove all personal data from the
+knowledge base, cached synced data, and agent state files.
+
+This skill produces an **erasure report** documenting what was found, what was
+deleted, and what requires manual action — providing an audit trail for
+compliance.
+
+## Trigger
+
+Run this skill:
+
+- When the user receives a formal GDPR erasure request
+- When the user asks to delete all data about a specific person
+- When a candidate withdraws from a recruitment process and requests data
+  deletion
+- When the user asks to "forget" someone
+
+## Prerequisites
+
+- The person's full name (and any known aliases or email addresses)
+- User confirmation before deletion proceeds
+
+## Inputs
+
+- **Name**: Full name of the data subject (required)
+- **Aliases**: Alternative names, maiden names, nicknames (optional)
+- **Email addresses**: Known email addresses (optional, improves search coverage)
+- **Scope**: `all` (default) or `recruitment-only` (limits to candidate data)
+
+## Outputs
+
+- `knowledge/Erasure/{Name}--{YYYY-MM-DD}.md` — erasure report (audit trail)
+- Deleted files and redacted references across the knowledge base
+
+---
+
+## Step 0: Confirm Intent
+
+Before proceeding, clearly state to the user:
+
+> **Data erasure request for: {Name}**
+>
+> This will permanently delete all personal data related to {Name} from:
+> - Knowledge base notes (People, Candidates, Organizations mentions)
+> - Cached email threads and attachments
+> - Agent state and triage files
+>
+> This action cannot be undone. Proceed?
+
+**Wait for explicit confirmation before continuing.**
+
+## Step 1: Discovery — Find All References
+
+Search systematically across every data location. Record every match.
+
+### 1a. Knowledge Base — Direct Notes
+
+```bash
+# Candidate directory (recruitment data)
+ls -d "knowledge/Candidates/{Name}/" 2>/dev/null
+
+# People note
+ls "knowledge/People/{Name}.md" 2>/dev/null
+
+# Try common name variations
+ls "knowledge/People/{First} {Last}.md" 2>/dev/null
+ls "knowledge/People/{Last}, {First}.md" 2>/dev/null
+```
+
+### 1b. Knowledge Base — Backlinks and Mentions
+
+```bash
+# Search for all mentions across the entire knowledge graph
+rg -l "{Name}" knowledge/
+rg -l "{First name} {Last name}" knowledge/
+
+# Search for Obsidian-style links
+rg -l "\[\[.*{Name}.*\]\]" knowledge/
+
+# Search by email address if known
+rg -l "{email}" knowledge/
+```
+
+### 1c. Cached Data — Email Threads
+
+```bash
+# Search synced email threads for mentions
+rg -l "{Name}" ~/.cache/fit/basecamp/apple_mail/ 2>/dev/null
+rg -l "{email}" ~/.cache/fit/basecamp/apple_mail/ 2>/dev/null
+
+# Check for attachment directories containing their files
+find ~/.cache/fit/basecamp/apple_mail/attachments/ -iname "*{Name}*" 2>/dev/null
+```
+
+### 1d. Cached Data — Calendar Events
+
+```bash
+# Search calendar events
+rg -l "{Name}" ~/.cache/fit/basecamp/apple_calendar/ 2>/dev/null
+rg -l "{email}" ~/.cache/fit/basecamp/apple_calendar/ 2>/dev/null
+```
+
+### 1e. Agent State Files
+
+```bash
+# Search triage files for mentions
+rg -l "{Name}" ~/.cache/fit/basecamp/state/ 2>/dev/null
+```
+
+### 1f. Drafts
+
+```bash
+# Search email drafts
+rg -l "{Name}" drafts/ 2>/dev/null
+```
+
+Compile a complete inventory of every file and reference found.
+
+## Step 2: Classify References
+
+For each discovered reference, classify the required action:
+
+| Reference Type | Action | Example |
+| --- | --- | --- |
+| **Dedicated note** (sole subject) | Delete entire file | `knowledge/People/{Name}.md` |
+| **Dedicated directory** | Delete entire directory | `knowledge/Candidates/{Name}/` |
+| **Mention in another note** | Redact: remove lines referencing the person | Backlink in `knowledge/Organizations/Agency.md` |
+| **Email thread** (sole subject) | Delete file | `~/.cache/fit/basecamp/apple_mail/thread.md` |
+| **Email thread** (multiple people) | Redact: remove paragraphs about the person | Thread discussing multiple candidates |
+| **Attachment** (their CV, etc.) | Delete file | `attachments/{thread}/CV.pdf` |
+| **Triage/state file** | Redact: remove lines mentioning them | `recruiter_triage.md` |
+| **Insights file** | Redact: remove bullets mentioning them | `knowledge/Candidates/Insights.md` |
+
+## Step 3: Execute Deletions
+
+Process in order from most specific to most general:
+
+### 3a. Delete Dedicated Files and Directories
+
+```bash
+# Remove candidate directory (CV, brief, assessment — everything)
+rm -rf "knowledge/Candidates/{Name}/"
+
+# Remove people note
+rm -f "knowledge/People/{Name}.md"
+
+# Remove any attachments
+find ~/.cache/fit/basecamp/apple_mail/attachments/ -iname "*{Name}*" -delete
+```
+
+### 3b. Redact Mentions in Other Notes
+
+For each file that **mentions** the person but isn't dedicated to them:
+
+1. Read the file
+2. Remove lines, bullets, or sections that reference the person
+3. Remove broken `[[backlinks]]` to deleted notes
+4. Write the updated file
+
+**Redaction rules:**
+
+- Remove entire bullet points that mention the person by name
+- Remove table rows containing the person's name
+- Remove `## Connected to` entries linking to their deleted note
+- If a section becomes empty after redaction, remove the section header too
+- Do NOT remove surrounding context that doesn't identify the person
+
+### 3c. Handle Email Threads
+
+For threads where the person is the **sole subject** (e.g., a recruitment email
+about only them):
+
+```bash
+rm -f "~/.cache/fit/basecamp/apple_mail/{thread}.md"
+```
+
+For threads with **multiple people**, redact only the paragraphs about this
+person — leave the rest intact.
+
+### 3d. Clean Agent State
+
+Remove mentions from triage files:
+
+```bash
+# Regenerate triage files on next agent wake — just remove current mentions
+for f in ~/.cache/fit/basecamp/state/*_triage.md; do
+  if rg -q "{Name}" "$f" 2>/dev/null; then
+    # Read, remove lines mentioning the person, write back
+    rg -v "{Name}" "$f" > "$f.tmp" && mv "$f.tmp" "$f"
+  fi
+done
+```
+
+### 3e. Clean Processing State
+
+Remove entries from the graph_processed state so deleted files aren't
+incorrectly tracked:
+
+```bash
+# Remove processed-file entries for deleted paths
+rg -v "{deleted_path}" ~/.cache/fit/basecamp/state/graph_processed \
+  > ~/.cache/fit/basecamp/state/graph_processed.tmp \
+  && mv ~/.cache/fit/basecamp/state/graph_processed.tmp \
+       ~/.cache/fit/basecamp/state/graph_processed
+```
+
+## Step 4: Write Erasure Report
+
+Create the audit trail at `knowledge/Erasure/{Name}--{YYYY-MM-DD}.md`:
+
+```markdown
+# Data Erasure Report — {Full Name}
+
+**Date:** {YYYY-MM-DD HH:MM}
+**Requested by:** {user or "GDPR Article 17 request"}
+**Scope:** {all / recruitment-only}
+
+## Data Subject
+- **Name:** {Full Name}
+- **Known aliases:** {aliases or "none"}
+- **Known emails:** {emails or "none"}
+
+## Actions Taken
+
+### Deleted Files
+- `knowledge/Candidates/{Name}/brief.md`
+- `knowledge/Candidates/{Name}/CV.pdf`
+- `knowledge/Candidates/{Name}/assessment.md`
+- `knowledge/People/{Name}.md`
+- {list all deleted files}
+
+### Redacted References
+- `knowledge/Organizations/{Agency}.md` — removed backlink
+- `knowledge/Candidates/Insights.md` — removed {N} bullet(s)
+- {list all redacted files and what was removed}
+
+### Cached Data Removed
+- `~/.cache/fit/basecamp/apple_mail/{thread}.md` — deleted (sole subject)
+- `~/.cache/fit/basecamp/apple_mail/{thread2}.md` — redacted (multi-person)
+- {list all cache actions}
+
+### State Files Cleaned
+- `~/.cache/fit/basecamp/state/recruiter_triage.md` — redacted
+- {list all state file actions}
+
+## Requires Manual Action
+
+The following data sources are outside this tool's reach:
+
+- **Apple Mail** — original emails remain in the user's mailbox. Search for
+  "{Name}" in Mail.app and delete threads manually.
+- **Apple Calendar** — original events remain. Check Calendar.app for events
+  mentioning "{Name}".
+- **Recruitment agencies** — notify {Agency} that the candidate's data has been
+  deleted and request they do the same.
+- **Interview notes** — check physical notebooks or other apps for handwritten
+  or external notes.
+- **Shared documents** — check Google Drive, SharePoint, or other shared
+  platforms for documents mentioning the person.
+
+## Verification
+
+After erasure, verify no traces remain:
+
+```bash
+rg "{Name}" knowledge/ ~/.cache/fit/basecamp/
+```
+
+Expected result: no matches (except this erasure report).
+```
+
+**IMPORTANT:** The erasure report itself must NOT contain personal data beyond
+the name and the fact that data was deleted. Do not copy CV content, skill
+assessments, or candidate details into the report. Record only what was deleted,
+not what it contained.
+
+## Step 5: Verify
+
+Run a final search to confirm no references were missed:
+
+```bash
+rg "{Name}" knowledge/ ~/.cache/fit/basecamp/ drafts/
+```
+
+The only match should be the erasure report itself. If other matches remain,
+process them and update the report.
+
+## Scope Variants
+
+### recruitment-only
+
+When scope is `recruitment-only`, limit erasure to:
+
+- `knowledge/Candidates/{Name}/` directory
+- `knowledge/Candidates/Insights.md` mentions
+- Recruitment-related email threads (from known agency domains)
+- `recruiter_triage.md` state file
+
+Leave `knowledge/People/{Name}.md` and general knowledge graph references
+intact — the person may be a colleague or contact outside of recruitment.
+
+### all (default)
+
+Full erasure across all knowledge base locations, cached data, and state files.
+
+## Quality Checklist
+
+- [ ] User confirmed intent before any deletion
+- [ ] Searched all data locations (knowledge, cache, state, drafts)
+- [ ] All dedicated files/directories deleted
+- [ ] All backlinks and mentions redacted from other notes
+- [ ] Cached email threads and attachments handled
+- [ ] Agent state files cleaned
+- [ ] Processing state updated for deleted files
+- [ ] Erasure report created with full audit trail
+- [ ] Report does NOT contain personal data (only file paths and actions)
+- [ ] Manual action items listed (Mail.app, Calendar.app, agencies)
+- [ ] Final verification search shows no remaining references
+- [ ] Broken backlinks cleaned up in referencing notes

package/template/.claude/skills/sync-apple-mail/SKILL.md

@@ -26,6 +26,8 @@ their email.
 
 - `~/.cache/fit/basecamp/state/apple_mail_last_sync` — last sync timestamp
   (single-line text file)
+- `~/.cache/fit/basecamp/state/apple_mail_last_rowid` — highest message ROWID
+  seen at last sync (single-line text file)
 - `~/Library/Mail/V*/MailData/Envelope Index` — Apple Mail SQLite database
 
 ## Outputs
@@ -36,6 +38,8 @@ their email.
   attachment files for each thread (PDFs, images, documents, etc.)
 - `~/.cache/fit/basecamp/state/apple_mail_last_sync` — updated with new sync
   timestamp
+- `~/.cache/fit/basecamp/state/apple_mail_last_rowid` — updated with highest
+  ROWID seen
 
 ---
 
@@ -53,13 +57,17 @@ The script:
 1. Finds the Mail database (`~/Library/Mail/V*/MailData/Envelope Index`)
 2. Loads last sync timestamp (or defaults to `--days` days ago for first sync)
 3. Discovers the thread grouping column (`conversation_id` or `thread_id`)
-4. Finds threads with new messages since last sync (up to 500)
-5. For each thread: fetches messages, batch-fetches recipients and attachment
+4. Loads last-seen ROWID (or defaults to 0 for first sync)
+5. Finds threads with new messages since last sync (up to 500), using both
+   timestamp and ROWID to catch late-arriving emails (emails downloaded after
+   a delay may have `date_received` before the last sync timestamp, but their
+   ROWID will be higher than the last-seen ROWID)
+6. For each thread: fetches messages, batch-fetches recipients and attachment
    metadata, parses `.emlx` files for full email bodies (falling back to
    database summaries), copies attachment files to the output directory
-6. Writes one markdown file per thread to `~/.cache/fit/basecamp/apple_mail/`
-7. Updates sync state timestamp
-8. Reports summary (threads processed, files written)
+7. Writes one markdown file per thread to `~/.cache/fit/basecamp/apple_mail/`
+8. Updates sync state (timestamp and max ROWID)
+9. Reports summary (threads processed, files written)
 
 The script imports `scripts/parse-emlx.mjs` to extract plain text bodies from
 `.emlx` / `.partial.emlx` files (handles HTML-only emails by stripping tags).

package/template/.claude/skills/track-candidates/SKILL.md

@@ -130,30 +130,40 @@ For each candidate found in a recruitment email, extract:
 
 | Field             | Source                                            | Required            |
 | ----------------- | ------------------------------------------------- | ------------------- |
-| **Name**          | Filename, email body, CV                          | Yes                 |
-| **Role**          | Email body, CV                                    | Yes                 |
-| **Rate**          | Email body (e.g. "$120/hr", "€80/h")              | If available        |
-| **Availability**  | Email body (e.g. "1 month notice", "immediately") | If available        |
-| **English**       | Email body (e.g. "B2", "Upper-intermediate")      | If available        |
-| **Location**      | Email body, CV                                    | If available        |
-| **Source agency** | Sender domain → Organization                      | Yes                 |
-| **Recruiter**     | Email sender or CC'd recruiter                    | Yes                 |
-| **CV path**       | Attachment directory                              | If available        |
-| **Skills**        | Email body, CV                                    | If available        |
-| **Gender**        | Name, pronouns, recruiter context                 | If identifiable     |
-| **Summary**       | Email body, CV                                    | Yes — 2-3 sentences |
+| **Name**             | Filename, email body, CV                                        | Yes                 |
+| **Title**            | Email body, CV — the candidate's professional title/function    | Yes                 |
+| **Rate**             | Email body (e.g. "$120/hr", "€80/h")                            | If available        |
+| **Availability**     | Email body (e.g. "1 month notice", "immediately")               | If available        |
+| **English**          | Email body (e.g. "B2", "Upper-intermediate")                    | If available        |
+| **Location**         | Email body, CV                                                  | If available        |
+| **Source agency**    | Sender domain → Organization                                    | Yes                 |
+| **Recruiter**        | Email sender or CC'd recruiter                                  | Yes                 |
+| **CV path**          | Attachment directory                                            | If available        |
+| **Skills**           | Email body, CV                                                  | If available        |
+| **Gender**           | Name, pronouns, recruiter context                               | If identifiable     |
+| **Summary**          | Email body, CV                                                  | Yes — 2-3 sentences |
+| **Role**             | Internal requisition profile being hired against                | If available        |
+| **Req**              | Requisition ID from hiring system                               | If available        |
+| **Internal/External**| Whether candidate is internal or external                       | If available        |
+| **Model**            | Engagement model (B2B, Direct Hire, etc.)                       | If available        |
+| **Current title**    | CV or email body                                                | If available        |
+| **Email**            | Email body, CV, signature                                       | If available        |
+| **Phone**            | Email body, CV, signature                                       | If available        |
+| **LinkedIn**         | Email body, CV                                                  | If available        |
+| **Also known as**    | Alternate name spellings or transliterations                    | If available        |
 
 ### Determining Gender
 
-Record the candidate's gender when identifiable from the email or CV:
+Record the candidate's gender when **explicitly stated** in the email or CV:
 
 - Pronouns used by the recruiter ("she is available", "her CV attached")
 - Gendered titles ("Ms.", "Mrs.", "Mr.")
-- First name when culturally unambiguous
 
-Record as `Woman`, `Man`, or `—` (unknown). When uncertain, use `—` — never
-guess. This field supports pool diversity tracking; it has **no bearing** on
-hiring decisions or assessment criteria.
+Record as `Woman`, `Man`, or `—` (unknown). When uncertain, use `—` — **never
+infer gender from names**, regardless of cultural context. Name-based inference
+is unreliable and culturally biased. This field supports aggregate pool
+diversity tracking; it has **no bearing** on hiring decisions, assessment
+criteria, or candidate visibility.
 
 ### Determining Source and Recruiter
 
@@ -192,9 +202,11 @@ Assign a status based on the email context:
 | `screening`        | Under review, questions asked about the candidate     |
 | `first-interview`  | First interview scheduled or completed                |
 | `second-interview` | Second interview scheduled or completed               |
+| `work-trial`       | Paid work trial or assessment project in progress     |
 | `offer`            | Offer extended                                        |
 | `hired`            | Accepted and onboarding                               |
 | `rejected`         | Explicitly passed on ("not a fit", "pass", "decline") |
+| `withdrawn`        | Candidate withdrew from the process                   |
 | `on-hold`          | Paused, waiting on notice period, or deferred         |
 
 **Default to `new`** if no response signals are found. Read the full thread
@@ -206,7 +218,10 @@ Look for these patterns in the hiring manager's replies:
 
 - "let's schedule" / "set up an interview" → `first-interview`
 - "second round" / "follow-up interview" → `second-interview`
+- "work trial" / "assessment project" / "paid trial" → `work-trial`
 - "not what we're looking for" / "pass" → `rejected`
+- "candidate withdrew" / "no longer interested" / "accepted another offer" →
+  `withdrawn`
 - "extend an offer" / "make an offer" → `offer`
 - "they've accepted" / "start date" → `hired`
 - "put on hold" / "come back to later" → `on-hold`
@@ -243,7 +258,7 @@ Then create `knowledge/Candidates/{Full Name}/brief.md`:
 # {Full Name}
 
 ## Info
-**Role:** {role title}
+**Title:** {professional title/function}
 **Rate:** {rate or "—"}
 **Availability:** {availability or "—"}
 **English:** {level or "—"}
@@ -253,6 +268,7 @@ Then create `knowledge/Candidates/{Full Name}/brief.md`:
 **Status:** {pipeline status}
 **First seen:** {date profile was shared, YYYY-MM-DD}
 **Last activity:** {date of most recent thread activity, YYYY-MM-DD}
+{extra fields here — see below}
 
 ## Summary
 {2-3 sentences: role, experience level, key strengths}
@@ -270,7 +286,11 @@ Then create `knowledge/Candidates/{Full Name}/brief.md`:
 ## Skills
 {comma-separated skill tags}
 
+## Interview Notes
+{interview feedback, structured by date — omit section if no interviews yet}
+
 ## Notes
+{free-form observations — always present, even if empty}
 ```
 
 If a CV attachment exists, **copy it into the candidate directory** before
@@ -278,6 +298,37 @@ writing the note.
 
 If no CV attachment exists, omit the `## CV` section entirely.
 
+### Extra Info Fields
+
+Place any of these **after Last activity** in the order shown, only when
+available:
+
+```markdown
+**Role:** {internal requisition profile, e.g. "Staff Engineer"}
+**Req:** {requisition ID, e.g. "4950237 — Principal Software Engineer"}
+**Internal/External:** {Internal / External / External (Prior Worker)}
+**Model:** {engagement model, e.g. "B2B (via Agency) — conversion to FTE not possible"}
+**Current title:** {current job title and employer}
+**Email:** {personal or work email}
+**Phone:** {phone number}
+**LinkedIn:** {LinkedIn profile URL}
+**Also known as:** {alternate name spellings}
+```
+
+### Additional Sections
+
+Some candidates accumulate richer profiles over time. These optional sections go
+**after Skills and before Notes**, in this order:
+
+1. `## Education` — degrees, institutions, years
+2. `## Certifications` — professional certifications
+3. `## Work History` — chronological career history (when extracted from CV)
+4. `## Key Facts` — notable bullet points from CV review
+5. `## Interview Notes` — structured by date as `### YYYY-MM-DD — {description}`
+
+`## Notes` is always the **last section**. If an `## Open Items` section exists
+(pending questions or follow-ups), place it after Notes.
+
 ### For EXISTING candidates
 
 Read `knowledge/Candidates/{Full Name}/brief.md`, then apply targeted edits:
@@ -363,6 +414,11 @@ produces a full framework-aligned assessment.
 - [ ] Scanned all new/changed email threads for recruitment signals
 - [ ] Extracted all candidates found (check attachment directories too)
 - [ ] Each candidate has a complete note with all available fields
+- [ ] Info fields are in standard order (Title, Rate, Availability, English,
+      Location, Gender, Source, Status, First seen, Last activity, then extras)
+- [ ] Sections are in standard order (Info → Summary → CV → Connected to →
+      Pipeline → Skills → Education/Certifications/Work History/Key Facts →
+      Interview Notes → Notes → Open Items)
 - [ ] CV paths are correct and point to actual files
 - [ ] Pipeline status reflects the latest thread activity
 - [ ] Timeline entries are in chronological order
@@ -372,4 +428,4 @@ produces a full framework-aligned assessment.
 - [ ] No duplicate candidate notes created
 - [ ] Key strategic insights added to `Insights.md` where warranted
 - [ ] Skills tagged using framework skill IDs where possible
-- [ ] Gender field populated where identifiable (Woman / Man / —)
+- [ ] Gender field populated only from explicit pronouns/titles (never name-inferred)

package/template/.claude/skills/upstream-skill/SKILL.md

@@ -0,0 +1,233 @@
+---
+name: upstream-skill
+description: Track changes made to skills in this installation and produce a changelog that can be included upstream. Use when skills have been modified, added, or removed locally and those changes should be contributed back to the monorepo.
+---
+
+# Upstream
+
+Track changes made to skills in this installation and produce a structured
+changelog so improvements can be contributed back to the upstream monorepo.
+
+## Trigger
+
+Run this skill when:
+
+- The user asks to prepare local skill changes for upstream contribution
+- Skills in `.claude/skills/` have been modified, added, or removed
+- The user wants to document what changed in the local installation
+- Before syncing with the upstream monorepo
+
+## Prerequisites
+
+- A working Basecamp installation with `.claude/skills/` directory
+- Git available for detecting changes
+
+## Inputs
+
+- `.claude/skills/*/SKILL.md` — current skill files in this installation
+- Git history — to detect what changed and when
+
+## Outputs
+
+- `.claude/skills/<skill-name>/CHANGELOG.md` — per-skill changelog of local
+  changes, one per modified skill directory
+
+---
+
+## Process
+
+### Step 1: Identify Changed Skills
+
+Use git to find all skill files that have been added, modified, or deleted since
+the last changelog entry (or since initial commit if no changelog exists).
+
+```bash
+# Find the date of the last changelog entry for a skill (if any)
+head -20 .claude/skills/<skill-name>/CHANGELOG.md 2>/dev/null
+
+# List changed skill files since last documented change
+git log --oneline --name-status -- '.claude/skills/'
+```
+
+If a skill already has a `.claude/skills/<skill-name>/CHANGELOG.md`, read the
+most recent entry date and only look at changes after that date:
+
+```bash
+git log --after="<last-entry-date>" --name-status -- '.claude/skills/<skill-name>/'
+```
+
+If no changelog exists for a skill, consider all commits that touched that
+skill's directory.
+
+### Step 2: Classify Each Change
+
+For every changed skill file, determine the type of change:
+
+| Type        | Description                                           |
+| ----------- | ----------------------------------------------------- |
+| `added`     | New skill created that doesn't exist upstream          |
+| `modified`  | Existing skill updated (workflow, checklists, tools)   |
+| `removed`   | Skill deleted from the installation                    |
+| `renamed`   | Skill directory or file renamed                        |
+
+For **modified** skills, read the current file and the previous version to
+identify what specifically changed:
+
+```bash
+# Show diff for a specific skill
+git diff HEAD~N -- '.claude/skills/<skill-name>/SKILL.md'
+
+# Or compare against a specific commit/date
+git log --oneline -- '.claude/skills/<skill-name>/'
+git diff <commit> -- '.claude/skills/<skill-name>/SKILL.md'
+```
+
+### Step 3: Describe Each Change
+
+For every changed skill, write a clear description that an upstream maintainer
+can act on. Each entry must answer:
+
+1. **What changed?** — The specific section or behaviour that was modified
+2. **Why?** — The problem encountered or improvement discovered during use
+3. **How?** — A summary of the actual change (not a full diff)
+
+Good descriptions:
+
+- "Added a safety check to Step 3 — agents were skipping validation when the
+  source directory was empty, causing silent failures"
+- "Rewrote the Entity Extraction section to process files in batches of 10
+  instead of all at once — large inboxes caused context window overflow"
+- "New skill: `process-hyprnote` — transcribes and extracts entities from
+  Hyprnote meeting recordings"
+
+Bad descriptions:
+
+- "Updated SKILL.md" (too vague)
+- "Fixed stuff" (no context)
+- "Changed line 42" (not meaningful to upstream)
+
+### Step 4: Write the Changelog
+
+For each changed skill, create or update its
+`.claude/skills/<skill-name>/CHANGELOG.md` with the following format:
+
+```markdown
+# <skill-name> Changelog
+
+Changes to this skill that should be considered for upstream inclusion in the
+Forward Impact monorepo.
+
+## <YYYY-MM-DD>
+
+**What:** <one-line summary of the change>
+
+**Why:** <the problem or improvement that motivated it>
+
+**Details:**
+<2-5 lines describing the specific changes made>
+
+---
+```
+
+Entries are in **reverse chronological order** (newest first). Each skill has
+its own changelog file inside its directory.
+
+For **new skills**, create the `CHANGELOG.md` alongside the `SKILL.md` with a
+single `added` entry describing the skill's purpose.
+
+For **removed skills**, the changelog should be the last file remaining in the
+skill directory, documenting why the skill was removed.
+
+### Step 5: Review the Changelogs
+
+After writing, read each changelog back and verify:
+
+- [ ] Every changed skill has a `CHANGELOG.md` in its directory
+- [ ] Each entry has What, Why, and Details sections
+- [ ] Descriptions are specific enough for an upstream maintainer to act on
+- [ ] New skills include a brief description of their purpose
+- [ ] Removed skills explain why they were removed
+- [ ] No duplicate entries for the same change
+- [ ] Dates are accurate (from git history, not guessed)
+
+## Example Output
+
+`.claude/skills/track-candidates/CHANGELOG.md`:
+
+```markdown
+# track-candidates Changelog
+
+Changes to this skill that should be considered for upstream inclusion in the
+Forward Impact monorepo.
+
+## 2026-03-01
+
+**What:** Added gender field extraction for diversity tracking
+
+**Why:** Recruitment pipeline lacked diversity metrics — pool composition was
+invisible without structured gender data.
+
+**Details:**
+- Added Gender field to candidate brief template (Woman / Man / —)
+- Added extraction rules: pronouns, gendered titles, culturally unambiguous names
+- Added explicit note that field has no bearing on hiring decisions
+- Updated quality checklist to include gender field verification
+
+---
+```
+
+`.claude/skills/process-hyprnote/CHANGELOG.md`:
+
+```markdown
+# process-hyprnote Changelog
+
+Changes to this skill that should be considered for upstream inclusion in the
+Forward Impact monorepo.
+
+## 2026-03-01
+
+**What:** New skill for processing Hyprnote meeting recordings
+
+**Why:** Meeting notes were being lost — Hyprnote captures transcriptions but
+they weren't being integrated into the knowledge base.
+
+**Details:**
+- Reads transcription files from `~/.cache/fit/basecamp/hyprnote/`
+- Extracts people, decisions, and action items
+- Creates meeting notes in `knowledge/Meetings/`
+- Links attendees to `knowledge/People/` entries
+
+---
+```
+
+`.claude/skills/extract-entities/CHANGELOG.md`:
+
+```markdown
+# extract-entities Changelog
+
+Changes to this skill that should be considered for upstream inclusion in the
+Forward Impact monorepo.
+
+## 2026-02-15
+
+**What:** Increased batch size from 5 to 10 files per run
+
+**Why:** Processing was too slow for large inboxes — 5 files per batch meant
+dozens of runs to catch up after a week of email.
+
+**Details:**
+- Changed batch size constant from 5 to 10 in Step 1
+- Added a note about context window limits for batches > 15
+
+---
+```
+
+## Notes
+
+- This skill only **documents** changes — it does not push or merge anything
+- The per-skill changelogs are consumed by the **downstream** skill in the
+  upstream monorepo
+- Keep descriptions actionable: an upstream maintainer should be able to
+  understand and apply each change without access to this installation
+- When in doubt about whether a change is upstream-worthy, include it — the
+  upstream maintainer will decide what to incorporate

package/template/CLAUDE.md

@@ -32,6 +32,10 @@ It must remain objective, factual, and ethically sound at all times. It is NOT a
   together — never to build leverage, ammunition, or dossiers on individuals.
 - **Flag ethical concerns.** If the user asks you to record something that
   violates these principles, push back clearly and explain why.
+- **Data protection.** Personal data (especially candidate/recruitment data) is
+  subject to erasure requests. Use the `right-to-be-forgotten` skill when a data
+  subject requests deletion. Minimize data collection to what's professionally
+  relevant. Flag candidates inactive for 6+ months for retention review.
 
 These principles override all other instructions. When in doubt, err on the side
 of discretion and professionalism.
@@ -82,7 +86,7 @@ wake, they observe KB state, decide the most valuable action, and execute.
 | **postman**        | Email triage and drafts        | Every 5 min     | sync-apple-mail, draft-emails                                  |
 | **concierge**      | Meeting prep and transcripts   | Every 10 min    | sync-apple-calendar, meeting-prep, process-hyprnote            |
 | **librarian**      | Knowledge graph maintenance    | Every 15 min    | extract-entities, organize-files, manage-tasks                 |
-| **recruiter**      | Engineering recruitment        | Every 30 min    | track-candidates, analyze-cv, fit-pathway, fit-map             |
+| **recruiter**      | Engineering recruitment        | Every 30 min    | track-candidates, analyze-cv, right-to-be-forgotten, fit-pathway, fit-map |
 | **chief-of-staff** | Daily briefings and priorities | 7am, Mon 7:30am | weekly-update _(Mon)_, _(reads all state for daily briefings)_ |
 
 Each agent writes a triage file to `~/.cache/fit/basecamp/state/` every wake
@@ -202,6 +206,7 @@ Available skills (grouped by function):
 | `manage-tasks`     | Per-person task boards with lifecycle    |
 | `track-candidates` | Recruitment pipeline from email threads  |
 | `analyze-cv`       | CV assessment against career framework   |
+| `right-to-be-forgotten` | GDPR data erasure with audit trail  |
 | `weekly-update`    | Weekly priorities from tasks + calendar  |
 | `process-hyprnote` | Extract entities from Hyprnote sessions  |
 | `organize-files`   | Tidy Desktop/Downloads, chain to extract |