feat: support repo-local config for context selection

[Karnak19]

Changes

Adds a repo-local config file so a repository can pin which context every coolify command inside it targets, without anyone having to remember --context or flip the global default back and forth.

.coolify.json (or .coolifyrc) at the repo root:

{
  "context": "production"
}

The CLI walks up from the working directory and uses the nearest one.

Resolution order:

1. --context flag
2. repo-local .coolify.json / .coolifyrc
3. global default context

• No credentials in the repo. The file only names a context that already exists in ~/.config/coolify/config.json; tokens stay global.
• Both file names are plain JSON, so no new dependency (.coolify.toml would need a TOML parser for a single key — happy to add it if you'd prefer that shape).
• A repo-local file naming a context that doesn't exist is a hard error that prints both paths, rather than a silent fallback to the default instance — silently deploying to the wrong place is the thing the issue is about. Malformed JSON errors too, for the same reason.
• --debug prints which file the context came from.
• Wired into cli.GetAPIClient, the single point where every command resolves its context, so all commands pick it up. No command surface changes.
• internal/config/local.go + local_test.go, docs in README.md, CLAUDE.md and ARCHITECTURE.md.

Testing: internal/config/local_test.go covers discovery from a nested directory, nearest-file-wins, absence, and parse failure. go test -race ./internal/... (config package at 83.3%), gofmt -s, and go vet ./... are green; also verified against a built binary for the flag-override, repo-local hit, and repo-local miss paths.

Issues & Discussions

• fix Support repo-local config for context selection #58 — Support repo-local config for context selection

🤖 Generated with Claude Code