# GitHub Recruiter Handoff

Use this when you want a GitHub-native wrapper for the review path that works directly
from this profile repo. It is the fastest handoff for recruiter screens, application review,
or hiring-manager forwarding when a browser route is not needed.

## 30-Second Screen

- Target: remote-capable Junior Python Backend / API Automation.
- Adjacent lanes: QA/API Python, CRM/API Integration, Internal Tools, and Support Engineer with Python when the work is backend/API-heavy.
- Experience base: Autoschool54 / DriveDesk backend and application-support work since March 2024.
- First code proof: OpsDesk Reviewer Replay shows a public FastAPI/SQLAlchemy backend slice with ticket intake, operator queue, idempotent outbox, SLA worker, SQL metrics, reviewer replay, pytest, Docker Compose, CI, and privacy audit.
- Real-work context: DriveDesk Business Intake API Handoff shows bot-style intake -> FastAPI/backend validation -> admin queue -> status transition -> outbox/integration handoff on the DriveDesk PostgreSQL-backed operations path, using synthetic public evidence only.
- Safe first assignment: one endpoint, data model, admin queue step, API/CRM mapping, pytest/API smoke check, SQL/data check, or runbook gap with handoff notes.

## Open In This Order

1. [Profile README](./README.md) - 10-second shortlist, target role, search fit, and work samples.
2. [OpsDesk Reviewer Replay](https://github.com/AlexGerlitz/opsdesk-lite/blob/main/docs/REVIEWER_REPLAY.md) - no-Docker proof path: synthetic webhook intake, idempotency, queue, status handoff, outbox dispatch, metrics, support diagnostics, and OpenAPI checks.
3. [DriveDesk Business Intake API Handoff](https://github.com/AlexGerlitz/drivedesk-core/blob/main/docs/public/BUSINESS_INTAKE_API_HANDOFF.md) - real-work API/admin/outbox handoff proof with FastAPI/PostgreSQL context and synthetic public evidence.
4. [LinkedIn Recruiter Packet](./LINKEDIN_RECRUITER_PACKET.md) - role lane, first proof, safe first task, and contact path.
5. [First Backend Role Fit](./FIRST_BACKEND_ROLE.md) - the bounded first-role question: what can a team safely give me first?
6. [Autoschool Intake/Admin work sample](./AUTOSCHOOL_INTAKE_ADMIN.md) - public-safe business workflow evidence without live production data.
7. [PDF resume](./output/pdf/alex-gerlitz-python-backend-automation-resume.pdf) - two-page application upload or internal-forwarding artifact.
8. [ATS plain-text resume](./output/txt/alex-gerlitz-ats-resume.txt) - parser-friendly text for application forms.
9. [Role Fit Message Examples](./APPLICATION_OUTREACH_PACK.md) - role-fit matrix, ATS keywords, and first message examples for a concrete vacancy.
10. [Recruiter proof pack](./output/pdf/alex-gerlitz-recruiter-proof-pack.pdf) - forwarding pack after role fit is clear.
11. [Verification pack](./VERIFICATION_PACK.md) - CI, public evidence freshness, review paths, and privacy boundary.

## Best First Message

```text
Role: ...
Success condition: ...
Can you send the smallest responsible first slice you would give me, the fit risks, and the best review path?
```

Remote setup, stack/systems, team surface, timeline, and compensation band can follow after fit is clear.

## What I Will Send Back

- Fit read: whether the role matches Python/backend automation, API verification, integrations, internal tools, or support-with-Python work.
- Risk check: missing context, weak assumptions, integration/data/access risks, and what should be verified first.
- First slice: the smallest useful task with input, state, output, verification, and handoff.
- Review path: the strongest repo, PDF, markdown proof, CI run, or public-safe work sample to inspect first.
- Boundary: I do not lead with infrastructure/cloud claims; first proof stays a backend/API slice under review.

## Evidence Boundary

Public evidence uses synthetic or redacted data only: no real names, phone numbers, Telegram IDs,
chat IDs, admin URLs, logs, dumps, credentials, tokens, private repository code, or live admin
screenshots.

AI tooling speeds up discovery, implementation, debugging, docs, tests, and review. Data
boundaries, privacy, verification, logs, docs, runbooks, and shipped quality stay reviewable.