Generate tailored CV variants from the canonical PDF design

.github/workflows/generate-tailored-cvs.yml

@@ -0,0 +1,48 @@
+name: Generate Tailored CVs
+
+on:
+  pull_request:
+    branches: [main]
+    paths:
+      - 'lib/cv/**'
+      - 'app/[locale]/(standalone)/cv/**'
+      - 'scripts/generate-tailored-cvs.tsx'
+      - '.github/workflows/generate-tailored-cvs.yml'
+      - 'public/images/cv/**'
+      - 'public/images/yotam-programmer.png'
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  generate:
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Setup pnpm
+        uses: pnpm/action-setup@v4
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: 24
+          cache: pnpm
+
+      - name: Install dependencies
+        run: pnpm install --frozen-lockfile
+
+      - name: Generate tailored CV PDFs
+        run: pnpm tsx scripts/generate-tailored-cvs.tsx
+
+      - name: Upload tailored CVs
+        uses: actions/upload-artifact@v4
+        with:
+          name: tailored-cvs
+          path: artifacts/cv-tailored/*.pdf
+          if-no-files-found: error
+          retention-days: 7

docs/cv/TAILORED_CV_GUIDELINES.md

@@ -0,0 +1,310 @@
+# Tailored CV Guidelines
+
+This document defines how Yotam Faraggi's tailored CV variants should be created.
+
+The goal is to make each CV highly relevant to a specific role **without changing Yotam's professional identity or making the CV look artificially rewritten to mirror a job description**.
+
+## Core principle
+
+> Tailor the emphasis, not the identity.
+
+A tailored CV should help a recruiter quickly see the parts of Yotam's real experience that matter most for the role. It should not make him appear to become a different kind of engineer for every application.
+
+---
+
+## 1. Professional identity is stable
+
+Yotam's canonical engineering identity is:
+
+**Senior Full-Stack Engineer**
+
+This is the primary title and should remain stable across tailored CVs.
+
+Do **not** replace it with job-specific identities such as:
+
+- Senior Backend Engineer
+- Senior Frontend Engineer
+- AI Engineer
+- Platform Engineer
+- Integration Engineer
+
+Those can describe a role being targeted or an area of relevant experience, but they should not replace the canonical title unless Yotam explicitly decides to change his long-term professional identity.
+
+### Why
+
+Yotam's career is genuinely full-stack. His experience spans frontend, backend, APIs, integrations, infrastructure, enterprise systems, product delivery, and technical leadership. Calling him a backend engineer for one application and a frontend engineer for another can make the tailoring feel performative rather than credible.
+
+A backend role does not require pretending that the rest of the full-stack experience does not exist. Instead, the CV should demonstrate enough backend depth that the recruiter can confidently see the fit.
+
+---
+
+## 2. Stable positioning vs. role-specific positioning
+
+Think of the top of the CV as two conceptual layers:
+
+### Stable identity / positioning
+
+Preferred base:
+
+**Senior Full-Stack Engineer | Product & AI**
+
+"Product & AI" is positioning, not a replacement for the engineering identity. It reflects Yotam's product ownership mindset and current AI-assisted product work.
+
+This wording can be refined over time if Yotam changes his long-term positioning, but it should not be changed simply because a job advertisement uses a different title.
+
+### Role-specific subtitle / focus
+
+A short secondary focus can be tailored to the role, for example:
+
+- Banking Systems, APIs & Integrations
+- Distributed Systems & Cloud Platforms
+- React, Product UX & Web Performance
+- Healthcare Platforms & Integrations
+- E-commerce, Automation & Integrations
+
+This is where the CV may speak directly to the target opportunity.
+
+The role-specific subtitle should describe **which part of Yotam's existing experience is most relevant**, not claim a new identity.
+
+### If the current PDF layout only supports one headline
+
+Do not solve the limitation by changing the primary profession.
+
+Prefer a stable headline such as:
+
+**Senior Full-Stack Engineer | Product & AI**
+
+and express the job-specific focus through the summary, experience emphasis, skill ordering, and metadata until the renderer has a dedicated subtitle field.
+
+---
+
+## 3. What may be tailored
+
+The following elements are intentionally flexible.
+
+### Professional summary
+
+Rewrite the summary for the target role while preserving the same underlying career story.
+
+The summary should:
+
+- start from the stable Full-Stack identity
+- surface the most relevant domain and technical experience early
+- use terminology that is natural for the target role when it accurately describes existing experience
+- explain transferable experience when the exact target stack is different
+- remain readable and human, not keyword-stuffed
+
+Example for a backend/platform role:
+
+Do not say that Yotam "is a backend engineer" simply because the role is backend.
+
+Instead, explain that he is a senior full-stack engineer whose backend experience includes APIs, integrations, high-availability banking services, event-driven messaging, production systems, Node.js, PostgreSQL, cloud infrastructure, and reliability work.
+
+### Experience descriptions and bullets
+
+Bullets may be rewritten or reordered to make relevant work easier to see.
+
+Allowed:
+
+- bring relevant responsibilities to the first bullet
+- make an implicit but factual technical connection clearer
+- emphasize scale, reliability, integrations, architecture, product ownership, performance, security, or domain experience when supported
+- reduce detail that is irrelevant to the target role
+- use more specific wording when the underlying fact is known
+
+Not allowed:
+
+- invent technologies
+- invent ownership that did not exist
+- imply experience with a target stack solely because it is similar to something Yotam used
+- inflate scale, team size, business impact, seniority, or responsibility
+- rewrite a role so aggressively that it no longer resembles the actual job
+
+### Skills
+
+Skills can be reordered and regrouped so the most relevant proven skills appear first.
+
+For example, a backend role can begin with APIs, Node.js, system design, PostgreSQL, integrations, messaging, cloud, and reliability before React.
+
+This is **emphasis**, not concealment. Full-stack skills should remain visible.
+
+### Section ordering and density
+
+Sections and individual items can be reordered where the renderer permits it if doing so makes the relevant evidence easier to find.
+
+Older experience can receive slightly more visibility when it is unusually relevant to the target role, such as Leumi or HOT for banking, integrations, high-availability services, or messaging-heavy backend roles.
+
+---
+
+## 4. What should normally remain unchanged
+
+Unless there is a factual correction or Yotam explicitly requests a change, preserve:
+
+- name and contact details
+- location and work authorization
+- company names
+- actual job titles held at each company
+- employment dates
+- education
+- languages
+- factual technologies and systems used
+- the overall chronological career history
+- the canonical **Senior Full-Stack Engineer** identity
+
+The CV may change the lens through which the experience is presented, but not the underlying career history.
+
+---
+
+## 5. Never mirror the job description mechanically
+
+A tailored CV should not look like the job advertisement was copied into the candidate profile.
+
+Avoid:
+
+- changing the title to exactly match the vacancy when that is not Yotam's real professional identity
+- repeating the employer's wording unnaturally
+- inserting every keyword from the requirements
+- forcing marginal experience into the summary because a keyword appears in the listing
+- claiming adjacent technologies as direct experience
+
+Use the job description as a **relevance map**, not as source material for a new persona.
+
+A recruiter should come away thinking:
+
+> "His existing background happens to be very relevant to this role."
+
+not:
+
+> "This CV was rewritten to make him look like exactly whatever we advertised."
+
+---
+
+## 6. Handling missing target-stack experience
+
+When a job asks for technologies Yotam has not used, never manufacture them.
+
+Instead:
+
+1. Identify the underlying engineering capability being tested.
+2. Find the strongest real analogue in Yotam's experience.
+3. Surface that experience clearly.
+4. Let the recruiter infer transferability.
+
+Example:
+
+If a role asks for Kafka but Yotam's proven event-driven production experience is with JMS, emphasize the JMS/event-driven systems experience. Do not add Kafka.
+
+If a role asks for AWS but Yotam's production cloud experience is GCP, emphasize cloud architecture and GCP. Do not silently replace GCP with AWS.
+
+If a role asks for Kotlin/Spring and the demonstrated backend stack is Node.js/TypeScript plus enterprise integration technologies, show the backend/system-design depth without claiming Kotlin/Spring experience.
+
+---
+
+## 7. Role-specific tailoring strategy
+
+Before writing a variant, identify the 3-5 strongest reasons Yotam is a fit.
+
+Use those reasons consistently across the summary, experience bullets, and skills.
+
+### Backend / platform role
+
+Possible evidence:
+
+- Node.js / TypeScript backend work
+- API design and integrations
+- PostgreSQL
+- high-availability banking services
+- high-throughput services
+- JMS and event-driven messaging
+- enterprise integration systems
+- cloud infrastructure
+- Docker / CI/CD
+- architecture, reliability, and technical ownership
+
+Keep React/Next.js visible because they reinforce the full-stack profile rather than weaken it.
+
+### Frontend-heavy role
+
+Possible evidence:
+
+- React / Next.js / TypeScript
+- frontend architecture and modernization
+- customer-facing product ownership
+- performance optimization
+- API integration
+- design implementation and product quality
+
+Do not rename Yotam "Senior Frontend Engineer" merely to match the vacancy.
+
+### Product engineering role
+
+Possible evidence:
+
+- end-to-end ownership
+- technical scoping
+- customer-facing product development
+- product and engineering tradeoffs
+- integrations
+- AI-assisted workflows
+- shipping and iteration
+
+### AI-oriented product role
+
+Possible evidence:
+
+- LLM APIs
+- AI-assisted product workflows
+- automation
+- product architecture around AI capabilities
+- integrations with external systems
+
+Do not imply ML research, model training, or specialized ML engineering unless it is actually supported.
+
+---
+
+## 8. File-generation workflow
+
+Tailored CVs must follow the repository workflow rather than being manually recreated.
+
+1. Use `CartShift/CartShift-Studio` as the source of truth.
+2. Work on the dedicated `cv-tailored-variants` branch.
+3. Add or update the tailored variant in the CV variant system.
+4. Use the existing React-PDF `CVDocument` renderer, assets, typography, spacing, and layout.
+5. Do **not** create a new public website route or change the live CV simply to generate an application-specific version.
+6. Generate the PDF using the repository's tailored-CV workflow/script.
+7. Inspect every generated page visually for clipping, overflow, awkward page breaks, density, or layout regressions.
+8. Keep the result concise, preferably two pages unless there is a strong reason otherwise.
+9. Upload the approved PDF to the existing tailored-CV location in Google Drive.
+
+The code and the generated PDF should remain reproducible from the repository.
+
+---
+
+## 9. Final pre-generation checklist
+
+Before generating any tailored CV, verify:
+
+- [ ] The primary professional identity still says **Senior Full-Stack Engineer**.
+- [ ] The CV does not pretend Yotam has become the exact job title in the vacancy.
+- [ ] The summary makes the target fit obvious within the first few sentences.
+- [ ] The strongest relevant evidence appears early.
+- [ ] Every claimed technology and responsibility is factual.
+- [ ] Missing technologies were handled through honest transferable experience, not invention.
+- [ ] Full-stack breadth is still visible even when emphasizing backend or frontend depth.
+- [ ] Existing job titles, companies, dates, education, and languages remain factual.
+- [ ] Skills are reordered for relevance rather than stuffed with job-description keywords.
+- [ ] The result still sounds like the same person as every other version of the CV.
+- [ ] The PDF is generated through the canonical repository workflow.
+- [ ] The final PDF is visually inspected before it is used or uploaded.
+
+---
+
+## 10. Decision rule
+
+When unsure whether a change is appropriate, ask:
+
+> **Does this make Yotam's real experience easier to understand, or does it make him look more like the job advertisement?**
+
+If it is the first, the change is probably good tailoring.
+
+If it is the second, do not make the change.