Just read description

I got tired of local microservices turning into a pile of Dockerfiles, Compose files, and nginx configs that nobody wants to maintain. Agents are worse at it than people. They rewrite a Dockerfile, break the Tiltfile, and burn a bunch of tokens fixing plumbing instead of the app. So I built TDK CLI. You keep one service.json next to each service. tdk up generates the local runtime and starts it. Docker runs the containers. Tilt live-reloads them. No local Kubernetes. you keep tdk up writes what runs

---

services/orders-api/ .autogenerated/ Docker service.json -- tdk up --> Dockerfile | src/ Tiltfile v Traefik routes Tilt watches | v api.shop.localhost A small shop stack looks like this: tdk up shop | +-------------------+-------------------+ | | | orders-api storefront postgres | | | +-------------------+-------------------+ | Traefik | *.shop.localhost The shortest loop: mkdir shop && cd shop tdk project --yes tdk resource orders-api --type backend --stack shop --yes tdk up shop --dry-run tdk up shop tdk doctor checks Docker, Tilt, and ports. tdk ui is a terminal dashboard for the running services. tdk config verify catches drift if someone hand-edits a generated file. It is local dev only. Production stays on Helm, Argo CD, or Kustomize. Core is MIT and does not need a key. You need Docker and Tilt. macOS and Linux work directly. Windows needs WSL2 Ubuntu. Native Windows can inspect, not start the stack. Repo: https://github.com/tdk-landscape/tdk-cli-core If Compose or Tilt already works for you, would a service.json still be worth it, or is that just another file to keep in sync?