@forwardimpact/outpost 3.12.0 → 3.13.0

package/templates/.claude/skills/req-track/SKILL.md

@@ -1,20 +1,22 @@
 ---
 name: req-track
-description: Scan synced email threads for recruitment candidates, extract structured profiles, and create/update notes in Knowledge/Candidates/. Use when the user asks to track candidates, process recruitment emails, or update the hiring pipeline.
+description: Scan synced email threads for recruitment candidates, extract structured profiles, and create/update notes in 2-Confidential/Candidates/. Use when the user asks to track candidates, process recruitment emails, or update the hiring pipeline.
 ---
 
 # Track Candidates
 
+Write tier: `2-Confidential`
+Frontmatter: candidate
+
 Scan synced email threads from `~/.cache/fit/outpost/apple_mail/` for
 recruitment candidates. Extract structured candidate profiles and create or
-update notes in `Knowledge/Candidates/`. Builds a local, searchable recruitment
-pipeline from scattered email threads.
+update notes in `2-Confidential/Candidates/`.
 
 ## Trigger
 
 - The user asks to track, process, or update candidates.
 - The user asks about recruitment pipeline status.
-- After `sync-apple-mail` has pulled new threads.
+- After `sync-apple-mail` pulls new threads.
 
 ## Prerequisites
 
@@ -29,38 +31,38 @@ pipeline from scattered email threads.
 - `~/.cache/fit/outpost/apple_mail/attachments/` — CV/resume attachments.
 - `~/.cache/fit/outpost/apple_calendar/*.json` — calendar events (for
   cross-source inference).
-- `Knowledge/Roles/*.md` — role/requisition files (check the `**Status:**`
-  field: `open` for active roles, `closed` for historical).
+- `2-Confidential/Roles/*.md` — role/requisition files (check the
+  `**Status:**` field: `open` for active roles, `closed` for historical).
 - `~/.cache/fit/outpost/state/graph_processed` — processed-file index (shared
   with `extract-entities`).
 - `~/.cache/fit/outpost/state/identity.md` — user identity for self-exclusion
-  (written by the `person-identify` skill).
+  (the `person-identify` skill writes it).
 
 ## Outputs
 
-- `Knowledge/Candidates/{Full Name}/brief.md` — candidate profile note.
-- `Knowledge/Candidates/{Full Name}/CV.pdf` (or `CV.docx`) — local CV copy.
-- `Knowledge/Candidates/{Full Name}/headshot.jpeg` — candidate photo.
-- `Knowledge/Roles/*.md` — role files created/updated; the `**Status:**` field
-  determines visibility (open/closed).
+- `2-Confidential/Candidates/{Full Name}/brief.md` — candidate profile note.
+- `2-Confidential/Candidates/{Full Name}/CV.pdf` (or `CV.docx`) — local CV.
+- `2-Confidential/Candidates/{Full Name}/headshot.jpeg` — candidate photo.
+- `2-Confidential/Roles/*.md` — role files created or updated. The
+  `**Status:**` field determines visibility (open/closed).
 - `~/.cache/fit/outpost/state/graph_processed` — updated with processed threads.
 
 <do_confirm_checklist goal="Verify candidate processing batch is complete and
 correct">
 
-- [ ] Required Info fields present on every brief (Title, Source, Status, First
-      seen, Last activity, Channel).
-- [ ] Pipeline status reflects latest thread activity; timeline in chronological
-      order.
-- [ ] Bidirectional links present (Candidate ↔ Org / Recruiter / Role /
-      Project).
-- [ ] Role files synced — Candidates tables rebuilt, stubs created for any
+- [ ] Frontmatter (`type`, `created`, `updated`, `aliases`, registry `status`)
+      and the required Info fields present on every brief.
+- [ ] Pipeline status reflects the latest thread activity. Timeline in
+      chronological order.
+- [ ] Backlinks land on `2-Confidential` overlay notes, never on `3-Team`
+      notes.
+- [ ] Role files synced. Candidates tables rebuilt. Stubs created for any
       unknown reqs.
 - [ ] CV and headshot copied into the candidate directory when available.
 - [ ] Skills tagged with agent-aligned engineering standard IDs from
       `bunx fit-pathway skill --list`.
 - [ ] Gender field populated only from explicit pronouns or titles.
-- [ ] No duplicate candidate notes; all processed threads marked in the state
+- [ ] No duplicate candidate notes. All processed threads marked in the state
       file.
 
 </do_confirm_checklist>
@@ -72,108 +74,108 @@ Process **10 files per run**.
 ### 1. Load context and pick the batch
 
 Read the user's name, email, and domain from
-`~/.cache/fit/outpost/state/identity.md` (run the `person-identify` skill first
-if it is missing or stale). List new or changed source files:
+`~/.cache/fit/outpost/state/identity.md`. Run the `person-identify` skill first
+if that file is missing or stale. List new or changed source files:
 
 ```bash
 node .claude/skills/extract-entities/scripts/state.mjs check
 ```
 
-Filter the output to `apple_mail/*.md` only — calendar files are not relevant
+Filter the output to `apple_mail/*.md` only. Calendar files are not relevant
 here.
 
 ### 2. Build candidate, people, and org indexes
 
 ```bash
-ls -d Knowledge/Candidates/*/
+ls -d 2-Confidential/Candidates/*/
 ```
 
 Read each existing brief's header (Name, Role, Source, Status) to build a mental
-index. Also scan `Knowledge/People/`, `Knowledge/Organizations/`, and
-`Knowledge/Projects/` to resolve recruiter names, agency orgs, and project
-links.
+index. Also scan `3-Team/People/`, `3-Team/Organizations/`, and
+`3-Team/Projects/` to resolve recruiter names, agency orgs, and project links.
 
-### 3. Sync `Knowledge/Roles/`
+### 3. Sync `2-Confidential/Roles/`
 
-Role files are flat here; the `**Status:**` field is `open` or `closed`.
+Role files are flat here. The `**Status:**` field is `open` or `closed`.
 
 1. Read each Role file's Info block to map Req → Role file path, Hiring manager,
    Domain lead, recruiter, Channel. Look up by filename substring so a req-less
-   role stays findable: `ls Knowledge/Roles/ | grep "{partial_name_or_req}"`.
-2. Find Reqs in candidate briefs missing a Role file:
-   `rg "^\*\*Req:\*\*" Knowledge/Candidates/*/brief.md`. Check all Role files
-   first; for a genuinely missing open role, create a stub with `**Status:**
-   open` using the **Role file stub** in
-   [references/templates.md](references/templates.md), then enrich:
-   `rg "{req_number}" Knowledge/`.
-3. Rebuild each **open** Role file's `## Candidates` table by scanning briefs:
-   `rg -l "Req:.*{req_number}" Knowledge/Candidates/*/brief.md`. Use the **Role
-   Candidates table** format from `references/templates.md`, newest first.
+   role stays findable:
+   `ls 2-Confidential/Roles/ | grep "{partial_name_or_req}"`.
+2. Find Reqs in candidate briefs that have no Role file:
+   `rg "^\*\*Req:\*\*" 2-Confidential/Candidates/*/brief.md`. Check all Role
+   files first. For a genuinely missing open role, create a stub with
+   `**Status:** open` from the **Role file stub** in
+   [references/templates.md](references/templates.md). Then enrich:
+   `rg "{req_number}" [0-9]-*/`.
+3. Scan briefs to rebuild each **open** Role file's `## Candidates` table:
+   `rg -l "Req:.*{req_number}" 2-Confidential/Candidates/*/brief.md`. Use the
+   **Role Candidates table** format from `references/templates.md`.
 4. If a Role file has a hiring manager but no domain lead, walk the
-   `**Reports to:**` chain in `Knowledge/People/` to a VP or senior leader.
+   `**Reports to:**` chain in `3-Team/People/` to a VP or senior leader.
 5. When a role closes (filled, cancelled, or frozen 6+ months), set its
-   `**Status:**` field to `closed` — only on a clear signal.
+   `**Status:**` field to `closed`. Do this only on a clear signal.
 
 ### 4. Identify recruitment threads
 
 For each thread in the batch, decide whether it contains recruitment content
-using the signals in [references/signals.md](references/signals.md). Skip
+with the signals in [references/signals.md](references/signals.md). Skip
 threads that match no signal.
 
 ### 5. Extract candidate data
 
-For each candidate found, populate the field map from
-[references/fields.md](references/fields.md). That reference covers field
-sources, the `Channel` rule, the hiring-manager / domain-lead resolution chain,
-gender rules, source/recruiter resolution, CV copying, and headshot discovery.
+For each candidate you find, populate the field map from
+[references/fields.md](references/fields.md). It covers field sources, the
+`Channel` rule, the hiring-manager / domain-lead resolution chain, gender rules,
+source/recruiter resolution, how to copy a CV, and headshot discovery.
 
 ### 6. Determine pipeline status
 
-Assign a status using the table and advancement signals in
-[references/statuses.md](references/statuses.md). Default to `new`. Read the
-full thread chronologically; the most recent signal wins.
+Assign a status with the table and advancement signals in
+[references/statuses.md](references/statuses.md). Default to `new`.
 
 ### 7. Build the pipeline timeline
 
-Extract a chronological timeline — one `**{date}**: {event}` line per meaningful
-event, capturing who did what. Skip noise (signature blocks, disclaimers,
-forwarded headers).
+Extract a chronological timeline. Write one `**{date}**: {event}` line per
+meaningful event. Each line captures who did what. Skip noise (signature
+blocks, disclaimers, forwarded headers).
 
 ### 8. Write or update the candidate note
 
-For **new** candidates, create `Knowledge/Candidates/{Full Name}/brief.md` from
-the **Candidate brief** template in
+For **new** candidates, create `2-Confidential/Candidates/{Full Name}/brief.md`
+from the **Candidate brief** template in
 [references/templates.md](references/templates.md). Place the **Extra Info
 fields** after `Last activity` in the order shown there. Add the **Optional
 sections** when data warrants. Omit `## CV` if no attachment.
 
-For **existing** candidates, apply targeted edits — do not rewrite the file:
-update `Status` and `Last activity`, append Pipeline entries, fill in newly
-known Info fields, and add new Skills.
+For **existing** candidates, apply targeted edits. Do not rewrite the file.
+Update `Status`, `Last activity`, and the frontmatter `status` and `updated`
+keys. Append Pipeline entries, fill in newly known Info fields, and add new
+Skills.
 
 ### 9. Capture cross-candidate insights
 
-Update `Knowledge/Candidates/Insights.md` only when an observation is
-high-signal: candidate may suit a **different role**, is a **strong match** for
-a specific team or leader, a meaningful **comparison between candidates**, or a
-hiring trade-off needs to be **remembered across sessions**.
+Update `2-Confidential/Candidates/Insights.md` only when an observation is
+high-signal: the candidate may suit a **different role**, is a **strong match**
+for a specific team or leader, a meaningful **comparison between candidates**,
+or you must **remember a hiring trade-off across sessions**.
 
-Skip per-candidate status and generic strengths/weaknesses — those belong on
+Skip per-candidate status and generic strengths/weaknesses. Those belong on
 `brief.md`. Format: one bullet under `## Placement Notes` with
-`[[Candidates/Name/brief|Name]]` and relevant people/org backlinks.
+`[[2-Confidential/Candidates/Name/brief|Name]]` and relevant backlinks.
 
-### 10. Ensure bidirectional links
+### 10. Make sure links are bidirectional
 
 | If you add...            | Then also add...                                           |
 | ------------------------ | ---------------------------------------------------------- |
-| Candidate → Organization | Organization → Candidate                                   |
-| Candidate → Recruiter    | Recruiter → Candidate (in Activity)                        |
-| Candidate → Project      | Project → Candidate (in People section)                    |
+| Candidate → Organization | Organization overlay → Candidate                           |
+| Candidate → Recruiter    | Recruiter overlay → Candidate (in Activity)                |
+| Candidate → Project      | Project overlay → Candidate                                |
 | Candidate → Role         | Role → Candidate (in Candidates table — rebuilt by Step 3) |
 
-Use absolute paths: `[[Candidates/Name/brief|Name]]`,
-`[[Organizations/Agency]]`, `[[People/Recruiter]]`. Only add a backlink when the
-target note doesn't already reference the candidate.
+Write each backlink on the entity's `2-Confidential` overlay note, never on
+the `3-Team` note (rules and stub in `references/overlays.md`). Only add a
+backlink when the overlay does not already reference the candidate.
 
 ### 11. Mark each thread processed
 
@@ -181,8 +183,8 @@ target note doesn't already reference the candidate.
 node .claude/skills/extract-entities/scripts/state.mjs update "{file_path}"
 ```
 
-Shares state with `extract-entities`, so the thread won't be re-scanned by
-either skill until it changes.
+`req-track` and `extract-entities` share this state. Neither skill re-scans the
+thread until it changes.
 
 ### 12. Tag skills against the standard
 
@@ -190,7 +192,5 @@ either skill until it changes.
 bunx fit-pathway skill --list
 ```
 
-Use agent-aligned engineering standard IDs (e.g. `data-integration`,
-`full_stack_development`, `architecture_and_design`) in the `## Skills` section
-instead of free-form tags. Flag any candidate with a CV attachment for
-`req-screen`.
+Use agent-aligned engineering standard IDs in the `## Skills` section instead
+of free-form tags. Flag any candidate with a CV attachment for `req-screen`.

package/templates/.claude/skills/req-track/references/fields.md

@@ -1,6 +1,6 @@
 # Candidate Field Extraction
 
-Field map and resolution rules for Step 2 of `req-track`.
+Field map and resolution rules for Step 5 of `req-track`.
 
 ## Fields
 
@@ -18,12 +18,12 @@ Field map and resolution rules for Step 2 of `req-track`.
 | Skills            | Email body, CV                                               | If available        |
 | Gender            | Pronouns or gendered titles only                             | If identifiable     |
 | Summary           | Email body, CV                                               | Yes — 2-3 sentences |
-| Role              | Internal requisition profile being hired against             | If available        |
+| Role              | Internal requisition profile you hire against                | If available        |
 | Req               | Requisition ID from hiring system                            | If available        |
 | Channel           | `hr` or `vendor` — see below                                 | Yes                 |
 | Hiring manager    | Cross-source inference — see below                           | If determinable     |
 | Domain lead       | Resolved from hiring manager's reporting chain               | If determinable     |
-| Internal/External | Whether candidate is internal or external                    | If available        |
+| Internal/External | Whether the 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        |
@@ -33,58 +33,62 @@ Field map and resolution rules for Step 2 of `req-track`.
 
 ## Channel
 
-- `vendor` — Source links to an `[[Organizations/...]]` flagged as
+- `vendor` — Source links to a `[[3-Team/Organizations/...]]` note flagged as
   vendor/partner (keywords: supplier, recruitment partner, contractor,
-  staffing), or Req contains "via {vendor name}" rather than a system ID.
-- `hr` — candidate came through a hiring system (numeric Req), applied
-  internally, or was submitted by an internal recruiter.
+  staffing). A Req that contains "via {vendor name}" instead of a system ID
+  also means `vendor`.
+- `hr` — the candidate came through a hiring system (numeric Req), or applied
+  internally, or an internal recruiter submitted the candidate.
 
 ## Hiring manager and domain lead — resolution chain
 
 Stop at the first match:
 
-1. **Req-first inheritance** — search `Knowledge/Roles/` for a file matching the
-   Req number or role description (use filename substring lookup for req-less
-   roles); check the `**Status:**` field (open/closed), then inherit Hiring
-   manager and Domain lead from the Role file.
+1. **Req-first inheritance** — search `2-Confidential/Roles/` for a file that
+   matches the Req number or the role description. Use a filename substring
+   lookup for req-less roles. Check the `**Status:**` field (open/closed). Then
+   inherit Hiring manager and Domain lead from the Role file.
 2. **Calendar inference** —
    `rg -l "{Candidate Name}" ~/.cache/fit/outpost/apple_calendar/`. The non-user
    organizer of an interview event is likely the hiring manager.
-3. **Email inference** — internal To/CC recipients (besides the user)
-   cross-checked against `Knowledge/People/`.
-4. **Reporting chain** — read the hiring manager's `**Reports to:**` field; walk
+3. **Email inference** — cross-check internal To/CC recipients (besides the
+   user) against `3-Team/People/`.
+4. **Reporting chain** — read the hiring manager's `**Reports to:**` field. Walk
    up to a VP / senior leader for the domain lead.
 5. **Staffing project timeline** — search staffing notes for the candidate or
-   vendor; surrounding context often names the manager.
+   vendor. The nearby context often names the manager.
 
 If none resolve, set `—` and revisit on the next cycle.
 
 ## Gender
 
-Record only when **explicitly stated**:
+Record only when the source states it **explicitly**:
 
 - Pronouns from the recruiter ("she is available", "her CV attached")
 - Gendered titles ("Ms.", "Mrs.", "Mr.")
 
 Record as `Woman`, `Man`, or `—` (unknown). When uncertain, use `—`. **Never
-infer gender from names** — name-based inference is unreliable and culturally
-biased. The field supports aggregate diversity tracking; it has no bearing on
+infer gender from names.** Name-based inference is unreliable and culturally
+biased. The field lets you track diversity in aggregate. It has no bearing on
 hiring decisions, assessment criteria, or candidate visibility.
 
 ## Source and recruiter
 
-- Map sender email domain to an organization in `Knowledge/Organizations/`.
-- The person who sent or forwarded the profile is the recruiter — link with
-  `[[People/Name]]`.
-- Create the organization or recruiter notes if missing.
+- Map the sender email domain to an organization in `3-Team/Organizations/`.
+- The person who sent or forwarded the profile is the recruiter. Link with
+  `[[3-Team/People/Name]]`.
+- Write recruiter-side and agency-side backlinks on the entity's
+  `2-Confidential` overlay note ([overlays.md](overlays.md)), never on the
+  `3-Team` note. When the `3-Team` note is missing, keep the name as plain
+  text. `extract-entities` creates team notes.
 
 ## CV attachment
 
 ```bash
 ls ~/.cache/fit/outpost/apple_mail/attachments/{thread_id}/
-mkdir -p "Knowledge/Candidates/{Full Name}"
+mkdir -p "2-Confidential/Candidates/{Full Name}"
 cp "~/.cache/fit/outpost/apple_mail/attachments/{thread_id}/{file}" \
-   "Knowledge/Candidates/{Full Name}/CV.pdf"
+   "2-Confidential/Candidates/{Full Name}/CV.pdf"
 ```
 
 Use `CV.pdf` (PDF) or `CV.docx` (Word). The `## CV` link is `./CV.pdf`.
@@ -108,9 +112,9 @@ Match by name fragment (case-insensitive). Prefer the Downloads match. Always
 write `headshot.jpeg`:
 
 ```bash
-cp "{src}" "Knowledge/Candidates/{Full Name}/headshot.jpeg"
+cp "{src}" "2-Confidential/Candidates/{Full Name}/headshot.jpeg"
 # PNG → JPEG
-magick "{src}.png" "Knowledge/Candidates/{Full Name}/headshot.jpeg"
+magick "{src}.png" "2-Confidential/Candidates/{Full Name}/headshot.jpeg"
 # HEIC → JPEG
-magick "{src}.heic" "Knowledge/Candidates/{Full Name}/headshot.jpeg"
+magick "{src}.heic" "2-Confidential/Candidates/{Full Name}/headshot.jpeg"
 ```

package/templates/.claude/skills/req-track/references/overlays.md

@@ -0,0 +1,42 @@
+# Overlay Notes
+
+Backlink rules for Step 10 of `req-track`. `req-workday` and `req-assess`
+follow the same rules.
+
+## The rule
+
+A `3-Team` note must not link into `2-Confidential`. Write every People-side,
+Organization-side, and Project-side backlink on the entity's `2-Confidential`
+overlay note, never on the `3-Team` note. The overlay declares its wide note
+with a one-way `canonical` link: double-quoted, tier-prefixed, and
+vault-absolute. Create the overlay when it is missing. When the `3-Team` note
+itself is missing, keep the name as plain text. `extract-entities` creates
+team notes.
+
+## Overlay stub
+
+File: `2-Confidential/People/{Name}.md` (or
+`2-Confidential/Organizations/{Name}.md`, `2-Confidential/Projects/{Name}.md`
+with the matching `type`).
+
+```markdown
+---
+type: person
+created: {YYYY-MM-DD}
+updated: {YYYY-MM-DD}
+aliases:
+  - "{Name} (recruitment)"
+canonical: "[[3-Team/People/{Name}]]"
+---
+
+# {Name}
+
+## Activity
+- **{date}**: Presented [[2-Confidential/Candidates/{Candidate}/brief|{Candidate}]]
+```
+
+## Assessment prose
+
+Interview-outcome and assessment prose about a candidate lives only in the
+candidate's own folder. A wider note, and an overlay, record only that an
+event happened.

package/templates/.claude/skills/req-track/references/signals.md

@@ -1,7 +1,7 @@
 # Recruitment Signals
 
 Decide whether an email thread is recruitment-related. Skip threads that match
-no signal — most email is not.
+no signal. Most email is not recruitment-related.
 
 ## CV/resume attachments
 
@@ -10,25 +10,25 @@ no signal — most email is not.
 
 ## Recruiter sender domains
 
-Sender domain maps to an organization in `Knowledge/Organizations/` tagged as a
-recruitment agency. When no agencies are catalogued yet, treat these patterns as
-hints:
+The sender domain maps to an organization in `3-Team/Organizations/` tagged
+as a recruitment agency. When no agencies are catalogued yet, treat these
+patterns as hints:
 
-- Multiple candidates presented by the same sender
-- Structured profile formatting (rate, availability, skills)
-- Forwarding candidate CVs on behalf of others
+- The same sender presents multiple candidates
+- The profile uses a structured format (rate, availability, skills)
+- The sender forwards candidate CVs on behalf of others
 
 ## Profile presentation patterns
 
-Structured candidate descriptions containing:
+Structured candidate descriptions that contain:
 
 - "Rate:" or rate/cost information
 - "Availability:" or notice period
 - "English:" or language level
 - "Location:" or country/city
-- Candidate name + role formatting (e.g. "Staff Software Engineer")
+- Candidate name + role format (e.g. "Staff Software Engineer")
 - "years of experience" / "YoE"
-- Skills/tech stack listings
+- Lists of skills or the tech stack
 
 ## Interview scheduling
 
@@ -38,5 +38,5 @@ Structured candidate descriptions containing:
 
 ## Follow-up on existing candidates
 
-A thread mentions a candidate already in `Knowledge/Candidates/` by name —
-process it to update pipeline status.
+A thread mentions a candidate already in `2-Confidential/Candidates/` by name.
+Process it to update the pipeline status.

package/templates/.claude/skills/req-track/references/statuses.md

@@ -1,7 +1,8 @@
 # Pipeline Statuses
 
-Used by Step 3 of `req-track`. Default to `new` if no advancement signals are
-found. Read the full thread chronologically; the most recent signal wins.
+Step 3 of `req-track` uses these statuses. Default to `new` if you find no
+advancement signals. Read the full thread chronologically. The most recent
+signal wins.
 
 ## Statuses
 

package/templates/.claude/skills/req-track/references/templates.md

@@ -1,10 +1,10 @@
 # Templates
 
-Markdown templates used by `req-track` for Role files and Candidate briefs.
+Backlink rules and the overlay stub live in [overlays.md](overlays.md).
 
 ## Role file stub
 
-Used by Step 0b when a Req appears on a candidate brief but no Role file exists.
+Step 3 stub for a Req with no Role file, in `2-Confidential/Roles/`.
 
 ```markdown
 # {Title from candidate Req field}
@@ -36,23 +36,31 @@ Used by Step 0b when a Req appears on a candidate brief but no Role file exists.
 
 ## Role Candidates table
 
-Step 0b rebuilds this table on each Role file by scanning briefs:
+Step 3 scans briefs and rebuilds this table on each Role file. Sort by First
+seen, newest first:
 
 ```markdown
 ## Candidates
 | Candidate | Status | Channel | First seen |
 |---|---|---|---|
-| [[Candidates/{Name}/brief\|{Name}]] | {status} | {channel} | {date} |
+| [[2-Confidential/Candidates/{Name}/brief\|{Name}]] | {status} | {channel} | {date} |
 ```
 
-Sort by First seen, newest first.
-
 ## Candidate brief
 
-Used by Step 5 for new candidates. File:
-`Knowledge/Candidates/{Full Name}/brief.md`.
+Step 8 uses this template for new candidates. File:
+`2-Confidential/Candidates/{Full Name}/brief.md`. Frontmatter `status` uses
+the registry vocabulary; the body `**Status:**` keeps the pipeline stage.
 
 ```markdown
+---
+type: candidate
+created: {YYYY-MM-DD}
+updated: {YYYY-MM-DD}
+aliases: [{alternate spellings, or an empty list}]
+status: {registry status: new / screening / interviewing / offer / hired / rejected / withdrawn}
+---
+
 # {Full Name}
 
 ## Info
@@ -62,7 +70,7 @@ Used by Step 5 for new candidates. File:
 **English:** {level or "—"}
 **Location:** {location or "—"}
 **Gender:** {Woman / Man / —}
-**Source:** [[Organizations/{Agency}]] via [[People/{Recruiter Name}]]
+**Source:** [[3-Team/Organizations/{Agency}]] via [[3-Team/People/{Recruiter Name}]]
 **Status:** {pipeline status}
 **First seen:** {YYYY-MM-DD}
 **Last activity:** {YYYY-MM-DD}
@@ -75,11 +83,11 @@ Used by Step 5 for new candidates. File:
 - [CV.pdf](./CV.pdf)
 
 ## Connected to
-- [[Organizations/{Agency}]] — sourced by
-- [[People/{Recruiter}]] — recruiter
-- [[Roles/{Role filename without .md}]] — applied to
-- [[People/{Hiring manager}]] — hiring manager
-- [[People/{Domain lead}]] — domain lead
+- [[3-Team/Organizations/{Agency}]] — sourced by
+- [[3-Team/People/{Recruiter}]] — recruiter
+- [[2-Confidential/Roles/{Role filename without .md}]] — applied to
+- [[3-Team/People/{Hiring manager}]] — hiring manager
+- [[3-Team/People/{Domain lead}]] — domain lead
 
 ## Pipeline
 - **{date}**: {event}
@@ -87,40 +95,33 @@ Used by Step 5 for new candidates. File:
 ## Skills
 {comma-separated agent-aligned engineering standard skill IDs}
 
-## Interview Notes
-{omit section if no interviews yet}
-
 ## Notes
 {free-form observations — always present, even if empty}
 ```
 
-Omit `## CV` when no CV attachment exists.
-
 ## Extra Info fields
 
 Place after `Last activity`, in this order, only when known:
 
 ```markdown
 **Role:** {internal requisition profile, e.g. "Staff Engineer"}
-**Req:** [[Roles/{filename}|{req number}]] — {title}
+**Req:** [[2-Confidential/Roles/{filename}|{req number}]] — {title}
 **Channel:** {hr / vendor}
-**Hiring manager:** {[[People/{name}]] or "—"}
-**Domain lead:** {[[People/{name}]] or "—"}
+**Hiring manager:** {[[3-Team/People/{name}]] or "—"}
+**Domain lead:** {[[3-Team/People/{name}]] or "—"}
 **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:** {profile URL}
-**Also known as:** {alternate spellings}
+**Also known as:** {alternate spellings — mirror them into `aliases`}
 ```
 
 For vendor-pipeline candidates the Req backlink uses
-`[[Roles/{filename}|Vendor]] — {description}`.
-
-## Optional sections
+`[[2-Confidential/Roles/{filename}|Vendor]] — {description}`.
 
-Add between `## Skills` and `## Notes` when data is rich enough, in this order:
+Add optional sections between `## Skills` and `## Notes`, in this order:
 `## Education`, `## Certifications`, `## Work History`, `## Key Facts`,
 `## Interview Notes` (`### YYYY-MM-DD — {description}` per interview).