Truth audit & repo setup

Today at a glance

• Recall10 min
• Concept · Truth audit55 min
• Build · SWIFTCLAIM repo70 min
• Drill · Go arrays + hash map25 min
• Job search20 min

Day 1 has two jobs. First, find out exactly which claims about your work you can defend under three “why?”s, and write them down once so the resume, LinkedIn and every story use the same words and numbers. Second, lay the SWIFTCLAIM foundation: a Python project managed by uv, Postgres with pgvector in Docker Compose, a README skeleton that separates Measured from Assumed, and a pre-commit hook that stops secrets reaching git. Both jobs share one idea: nothing is claimed before the evidence exists.

Recall (10 min, no notes)

Day 1 has nothing earlier to recall, so check the “Before Day 1” list instead. Answer aloud, then open each answer. Anything you could not tick goes on the gap list (A2) today.

Concept · The truth audit (55 min)

What it is

A truth audit takes every claim you make about yourself, wherever it appears, and checks it against evidence before anyone else does. The output is a claim ledger: one row per claim, one decision per row. You then rewrite the resume, LinkedIn and story bank from the ledger, never the other way round.

It exists because FDE loops probe claims harder than most interviews. The technical deep-dive takes something you wrote, asks “why?” three times, and then asks how you measured it. A claim that collapses on the third “why?” costs more than a smaller claim that holds.

The ledger

The four claim classes

• Professional: work you personally delivered, at the scope you delivered it.
• Team: team delivery, with your exact role stated.
• Portfolio: SWIFTCLAIM, always labelled “personal project, synthetic data”.
• Learning: studied or tried; never presented as production ownership.

How a row gets its decision

claim ──▶ evidence exists today? ──no──▶ REMOVE  (or rewrite as Learning)
                │ yes
                ▼
       who did the work? ──team──▶ class = Team, state your exact role
                │ me
                ▼
       number in the claim? ──no──▶ KEEP as written
                │ yes
                ▼
   measure + method + window + baseline known? ──no──▶ REWRITE without the number
                │ yes
                ▼
       KEEP: identical wording on resume, LinkedIn, story bank

Worked example: the rows the course already flags

The course's story bank (§9) lists the audits these claims need before first use. Your ledger starts with them. The decision column below shows what the audit must establish, not a verdict; only you can fill in the evidence.

Consistency: one number, three places

Interviewers read the resume and LinkedIn side by side. If the resume says “60–80%” and LinkedIn says “~70%”, the question stops being about your work and becomes about your honesty. For every Keep row, paste the same sentence into all three places. Outcome framing still applies: say what changed for the customer (“cut X from A to B”), not “built a pipeline”, but only with numbers that pass the audit.

Seven questions

How this shows up in SWIFTCLAIM today

The README you scaffold in today's build has Measured and Assumed sections from the first commit, and the first line labels the project “personal project, synthetic data”. That is the ledger discipline applied to the code: from Week 2 every number in the README carries its n, and anything you have not measured stays under Assumed. The secret-scan hook is the same idea for data: synthetic only, nothing real, and a machine check instead of a promise.

Build · SWIFTCLAIM repo setup (70 min)

Today is boilerplate, which rule 2 allows AI to generate. The core modules (LLM client, schemas, rule engine) start tomorrow and are hand-written through Week 3. The files below are given in full so you can spend the time understanding each one rather than typing it.

1. Create the project with uv.

   mkdir swiftclaim && cd swiftclaim
   git init
   uv init --package --python 3.12
   uv add --dev ruff pytest pre-commit
   uv run python -c "import swiftclaim; print('ok')"

   --package gives a src/swiftclaim/ layout, so tests import the installed package rather than a stray file in the working directory. Check that pyproject.toml says requires-python = ">=3.12".

2. Configure ruff and pytest by appending to pyproject.toml:

   [tool.ruff]
   line-length = 100
   target-version = "py312"
   
   [tool.ruff.lint]
   select = ["E", "F", "I", "B", "UP"]
   
   [tool.pytest.ini_options]
   testpaths = ["tests"]

3. Add Postgres + pgvector in compose.yaml:

   services:
     db:
       image: pgvector/pgvector:pg17
       environment:
         POSTGRES_USER: ${POSTGRES_USER:-swiftclaim}
         POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD in .env}
         POSTGRES_DB: ${POSTGRES_DB:-swiftclaim}
       ports:
         - "127.0.0.1:5432:5432"
       volumes:
         - pgdata:/var/lib/postgresql/data
         - ./docker/initdb:/docker-entrypoint-initdb.d:ro
       healthcheck:
         test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
         interval: 5s
         timeout: 3s
         retries: 10
   
   volumes:
     pgdata:

   And docker/initdb/001-extensions.sql:

   CREATE EXTENSION IF NOT EXISTS vector;

   The port binds to 127.0.0.1 so the database is not reachable from your network. $$ escapes $ so the variable is read inside the container, not by Compose. If you pick a different major Postgres version, check the image's docs for its data directory.

4. Write .env.example with placeholders only, then copy it:

   ANTHROPIC_API_KEY=
   POSTGRES_USER=swiftclaim
   POSTGRES_PASSWORD=change-me-local-only
   POSTGRES_DB=swiftclaim
   DATABASE_URL=postgresql://swiftclaim:change-me-local-only@localhost:5432/swiftclaim

   cp .env.example .env
   printf '.env\n.venv/\n__pycache__/\n.pytest_cache/\n.ruff_cache/\n' >> .gitignore
   docker compose up -d --wait
   docker compose exec db psql -U swiftclaim -c "SELECT extversion FROM pg_extension WHERE extname = 'vector';"

   Init scripts run once

   Postgres runs /docker-entrypoint-initdb.d only when the data volume is empty. If the extension is missing because the volume already existed, run docker compose down -v (this deletes local data) and bring it up again.

5. Add secret scanning in .pre-commit-config.yaml:

   repos:
     - repo: https://github.com/gitleaks/gitleaks
       rev: vX.Y.Z  # paste the latest release tag from the gitleaks releases page
       hooks:
         - id: gitleaks
     - repo: local
       hooks:
         - id: ruff
           name: ruff
           entry: uv run ruff check
           language: system
           types: [python]

   uv run pre-commit install
   uv run pre-commit run --all-files

   Prove the hook works before you trust it. Plant a fake token in the shape of a GitHub personal access token, try to commit it, and confirm the commit is blocked:

   python3 -c "import secrets, string; print('token = \"ghp_' + ''.join(secrets.choice(string.ascii_letters + string.digits) for _ in range(36)) + '\"')" > leak_test.py
   git add leak_test.py && git commit -m "should be blocked"
   git restore --staged leak_test.py && rm leak_test.py

   If the commit goes through, the hook is not installed or the pattern did not match. Find out which before moving on; do not weaken the test.

6. Write the hygiene tests in tests/test_repo_hygiene.py and make them pass:

   """Repo hygiene checks: the rules that keep secrets and real data out of SWIFTCLAIM."""
   
   from pathlib import Path
   
   ROOT = Path(__file__).resolve().parents[1]
   REQUIRED_KEYS = {"ANTHROPIC_API_KEY", "POSTGRES_USER", "POSTGRES_PASSWORD", "POSTGRES_DB", "DATABASE_URL"}
   
   
   def read_env_example() -> dict[str, str]:
       pairs = {}
       for line in (ROOT / ".env.example").read_text().splitlines():
           if line.strip() and not line.startswith("#"):
               key, _, value = line.partition("=")
               pairs[key.strip()] = value.strip()
       return pairs
   
   
   def test_env_example_lists_every_required_key():
       assert REQUIRED_KEYS <= read_env_example().keys()
   
   
   def test_env_example_holds_no_api_key():
       assert read_env_example()["ANTHROPIC_API_KEY"] == ""
   
   
   def test_dotenv_is_gitignored():
       ignored = (ROOT / ".gitignore").read_text().splitlines()
       assert ".env" in ignored
   
   
   def test_package_imports():
       import swiftclaim  # noqa: F401

   uv run pytest -q
   uv run ruff check .

7. Write the README skeleton. Every heading exists now; most stay empty until the week that fills them.

   # SWIFTCLAIM
   
   AI-assisted claims-triage copilot for a fictional insurer.
   **Personal project, synthetic data.** Not client work; results do not predict real-world performance.
   
   ## Problem
   ## How to run
   ## Measured
   _Nothing measured yet. Every number here will carry its n, model ID and prompt version._
   ## Assumed
   ## Architecture
   ## Decisions and cuts
   ## Limits
   ## Demo

8. Licence, history scan, first commit. Add an MIT or Apache-2.0 LICENSE. Install the gitleaks binary and scan the whole history, not just staged files:

   gitleaks git -v .        # older releases: gitleaks detect --source . -v
   git add -A && git commit -m "Scaffold SWIFTCLAIM: uv, ruff, pytest, pgvector, secret scan"

   Create the GitHub repo once the scan is clean. The week's exit test wants it public; check the commit history before you flip it.

Acceptance criteria

• uv run pytest -q passes and uv run ruff check . is clean.
• docker compose up -d --wait starts a healthy database, and the vector extension is installed.
• The pre-commit hook blocked your planted fake token.
• .env is ignored; .env.example holds placeholders only.
• A full-history gitleaks scan reports no leaks.
• The README's first lines say “personal project, synthetic data”, with empty Measured and Assumed sections.

Drill · Go arrays + hash map (25 min)

NO AI 25 min Narrate while you type, and state time and space complexity before you run anything.

Problem 1 · Two Sum

Given nums []int and target int, return the indices of the two numbers that add up to target. Exactly one solution exists, and you may not use the same element twice.

• nums = [2, 7, 11, 15], target = 9 → [0, 1]
• nums = [3, 2, 4], target = 6 → [1, 2]
• nums = [3, 3], target = 6 → [0, 1]

Constraints: 2 ≤ len(nums) ≤ 10⁴; values and target fit in an int. Aim for better than O(n²).

Problem 2 · Contains Duplicate

Return true if any value appears at least twice in nums, otherwise false.

• [1, 2, 3, 1] → true
• [1, 2, 3, 4] → false

func twoSum(nums []int, target int) []int {
	seen := make(map[int]int, len(nums)) // value -> index
	for i, n := range nums {
		if j, ok := seen[target-n]; ok {
			return []int{j, i}
		}
		seen[n] = i
	}
	return nil
}

func containsDuplicate(nums []int) bool {
	seen := make(map[int]struct{}, len(nums))
	for _, n := range nums {
		if _, ok := seen[n]; ok {
			return true
		}
		seen[n] = struct{}{}
	}
	return false
}

Log both problems in the drill log (A5): date, problem, language, mode, minutes, solved, complexity stated, pattern (“hash map: complement lookup”, “hash set: seen-before”).

Job search (20 min)

This week ends with 30 companies tiered A/B/C. Today, set up the application tracker and seed the first 10.

1. Create the A4 tracker as a spreadsheet with these columns: Company · Tier · Role · Location · Source · Applied · Stage · Loop + AI policy · Next step.
2. Add 10 companies, spread across Pune, Hyderabad and remote-India with equal weight. Start from the 2026 listings in §3 (Google Cloud, Databricks, LiveKit, Accenture India, Wipro) and verify each one is still live.
3. Tag each with a tier. A is top choice and waits for v2 (Week 7). B is realistic and waits for v1 (Week 5). C is practice and waits for resume v2 plus a public repo (Week 3).
4. Leave “Applied” empty. Nothing goes out until the resume is rebuilt from today's ledger, unless runway is under three months and you are on the safety-net track.

Done means

• Claim ledger complete: every resume and LinkedIn claim has evidence, contribution, metric method, class and a decision.
• The SDLC metric row names one measure, or is marked “rewrite without number” until it can.
• The ledger lives in a private document, not in the repo.
• SWIFTCLAIM repo scaffolded: uv, ruff, pytest, Compose with pgvector, README skeleton, .env.example, licence.
• Secret scan proven to block a planted token, and the full history scans clean.
• Two Go drills solved without AI, complexity stated aloud, logged in A5.
• Application tracker created with 10 tiered companies.

Resources

• uv documentation: projects, uv add, uv run.
• pgvector: installation, Docker image and the vector extension.
• gitleaks: pre-commit hook and history scanning.
• pre-commit: hook configuration and local hooks.