# Senior containers & local-dev playbook

Compressed reference for the senior-only containers/local-dev extension. Pair with [cheat-sheet.md](./cheat-sheet.md), [GLOSSARY.md](./GLOSSARY.md), and [repo-containers-map.md](./repo-containers-map.md).

## The senior shift
Intermediate understanding is: "I know what a container is, how images and Compose work, and how this repo starts locally."

Senior understanding is: "I can explain why this repo chose these local workflows, evaluate readiness and reload trade-offs, and debug the local stack under pressure without reducing everything to folklore."

## The six senior lenses
1. **Image strategy is workflow strategy** — Dockerfile stages, entrypoints, and shipped tooling shape the whole local-dev experience.
2. **Readiness is not just a healthcheck checkbox** — the real question is what failure you are avoiding and where you place the gate.
3. **Fast inner loops are designed, not accidental** — rebuild, hot-swap, restart, and redeploy each optimize a different bottleneck.
4. **Compose vs kind is a fidelity choice** — speed and realism are both valuable; good engineers choose the stack that answers the current question.
5. **Debugging starts with the path of change** — image build, config render, volume mount, health gate, process start, and live reload are separate failure layers.
6. **Local stacks are architecture education** — the container and dev-loop choices teach you how the production deployment system is really organized.

## Senior review checklist
- Why does `Dockerfile.development` have both `no-op` and `developer` paths?
- Which failures are guarded by `wait-for-it-service`, and which are not?
- When is `docker cp` hot-swap a better loop than rebuilding the image?
- When is the kind+Skaffold stack worth its extra cost?
- If a service does not pick up a config change, which layer likely failed: render, mount, process args, or restart?
- What does the local workflow reveal about the repo’s “one binary, many services” model?

## Interview answer shapes
### Why not rebuild the image for every code change?
Because the repo optimizes the inner loop for service iteration. Host-compile plus `docker cp` into a running container is much faster than full image rebuilds when the image and config have not changed.

### Why have both compose and kind+Skaffold?
They answer different questions. Compose is the fast container/process loop; kind+Skaffold is the higher-fidelity loop for Kubernetes, Helm, and service-mesh behavior.

### What problem does `wait-for-it-service` solve?
It centralizes readiness gating for infra dependencies so application services do not race ahead just because containers started before dependencies were actually ready.

### Why use one image for many services?
Because the repo compiles one `build/server` binary and chooses service behavior at runtime through command args and mounted config. That keeps the image strategy simpler and supports fast local loops.

### What is the real debugging order for a broken local service?
Check image/runtime choice, rendered config, mounted files/secrets, dependency readiness, process command/entrypoint, then the live-reload or restart path.