A point counts as present only if the answer states it clearly enough that a reader would act on it.

Q1

1. git reset --soft HEAD~1 (changes stay staged) or git reset HEAD~1 / --mixed (changes stay unstaged) given as the command.
2. Warns not to use --hard (it discards the changes).

Q2

1. A command that finds the PID listening on the port (lsof -i :3000, ss -ltnp, fuser 3000/tcp).
2. A command that kills it (kill <pid> or fuser -k 3000/tcp).

Q3

1. Put the variable in .env.local (or equivalent env file).
2. Browser-visible variables must be prefixed NEXT_PUBLIC_.
3. Read via process.env.NEXT_PUBLIC_NAME.
4. Restart the dev server for changes to apply (or note it is inlined at build time).

Q4

1. python3 -m venv <dir> creates the environment.
2. Activate it (source <dir>/bin/activate, or Windows equivalent).
3. pip install requests.

E1

1. Cache-Control directives control freshness/storage (e.g. max-age, no-store, no-cache, public/private).
2. ETag is a validator for the resource version.
3. Revalidation: client sends If-None-Match; server answers 304 Not Modified without body.
4. Distinguishes fresh (served from cache without a request) vs stale (needs revalidation).

E2

1. A process has its own isolated memory/address space; threads of a process share the same memory.
2. Threads are lighter weight to create/switch than processes.
3. Process isolation: a crash in one process does not directly corrupt another; a thread bug can affect the whole process.
4. Communication differs: threads share memory directly (needing synchronization); processes need IPC.

E3

1. An index is a separate data structure (usually B-tree) that lets the database find rows without scanning the whole table.
2. Speeds up reads/lookups on the indexed columns (WHERE, JOIN, ORDER BY).
3. Hurts writes: inserts/updates/deletes must also maintain the index.
4. Costs storage, and too many or unused/low-selectivity indexes hurt or do not help.

D1 (architecture)

1. Recommends a clear default for this situation (monolith / modular monolith first) with the reason.
2. Team-size and operational-overhead argument (6 people cannot afford the distributed-systems overhead).
3. Microservices costs named: network failures, distributed data consistency/transactions, deployment/observability complexity.
4. Names when/what would trigger a later split (scaling hotspots, team growth, independent deploy needs) or the modular-boundaries advice that keeps the split option open.
5. Acknowledges 10x growth in two years is plausibly handled by a well-built monolith (scaling is not by itself a reason for microservices).

D2 (security)

1. Validate file type by content (magic bytes) / do not trust client MIME type or extension; allow-list types.
2. Limit file size.
3. Do not use the user-supplied filename (path traversal): generate a random name.
4. Prevent executable/script content being served or executed (serve with correct Content-Type, X-Content-Type-Options: nosniff, no execution; SVG/HTML risk named).
5. Store outside the code/app dir or on object storage, and/or caution that disk storage does not scale or survive redeploys.

D3 (migration)

1. Do NOT do a single ALTER TABLE ... RENAME COLUMN while old app code runs (it breaks the running app).
2. Expand step: add the new column contact_email.
3. Keep both in sync (dual-write in app or trigger) during the transition.
4. Backfill existing rows in batches (not one giant lock-holding UPDATE).
5. Deploy app code that reads from the new column, then stop writing the old one.
6. Only after the app no longer uses the old column, drop it (contract step); also carry over constraints/indexes (NOT NULL, unique) to the new column.