Repository Guidelines

Keep changes small, independently reviewable, and covered by the smallest relevant check.
Use the approved stack below; within it, prefer existing code, standard libraries, and native platform features before adding dependencies or abstractions.
Treat platform responses, webhooks, account data, proxies, and credentials as untrusted or sensitive external input.
Preserve idempotency and backward compatibility at integration boundaries; document retry and failure behavior.
Never commit secrets, production credentials, or personal account data.
Do not add instructions or features for bypassing detection, evading platform risk controls, or violating platform rules.
When referencing upstream projects, record the source and license, then implement independently unless the license explicitly permits reuse.

Approved Stack

Use Go 1.26, Fiber v3 for HTTP routing and service lifecycle, Viper for configuration, Logrus for application logging, and Cobra for executable entrypoints. Keep the exact dependency versions locked by go.mod and go.sum.
Keep mature standard-library integrations, such as the reverse proxy and Docker HTTP client, instead of rewriting them. When a net/http handler crosses the Fiber boundary, use Fiber's official adapter.
Create a local viper.New() instance, bind only supported inputs, apply defaults explicitly, and validate all configuration before network, filesystem, or Docker side effects. Do not use Viper's global singleton, remote providers, or live reload without an approved requirement.
Emit structured JSON through Logrus with stable fields such as service; never log credentials, proxies, account data, request bodies, or other sensitive values. Return errors from reusable code and log them once at the service boundary.
Give each service one minimal Cobra root command. Add subcommands, persistent flags, generators, or completion only when a real operator workflow requires them.
Do not add an ORM, Redis, a task framework, or another HTTP/config/logging/CLI stack without a reviewed requirement.

Use React 19, Vite 8, react-admin 5.15.x, and MUI 9. Lock exact installed versions in web/package-lock.json.
Use only the open-source react-admin and MUI packages for the initial implementation. Enterprise Edition and MUI X Pro/Premium require separate product and license review.
Own the visual system in CreatorHub: keep brand tokens in the project theme and keep navigation/chrome in project-owned Layout, AppBar, and Menu components. Mantis Free may be consulted as MIT-licensed visual reference, but do not import or fork the full template.
Do not mix Ant Design, Arco, or another component system into the react-admin/MUI application.
Preserve domain actions such as start, stop, and recycle as explicit actions; do not disguise them as generic CRUD updates merely to fit react-admin conventions.

Limit a future UI switch to the project-owned MUI theme, Layout/AppBar/Menu, and react-admin dataProvider boundary. Keep API calls and response mapping in the data provider, not in presentation components.
Do not build a parallel design system, framework-neutral component layer, or speculative adapter hierarchy now. Introduce a new boundary only when a concrete replacement cannot be contained by the existing three seams.
A switch away from MUI or react-admin requires user review before implementation. Replace the current UI stack rather than running two component systems side by side.

Add the smallest regression test that would fail without each non-trivial behavior change. Cover success, validation, failure, and compatibility paths at trust and integration boundaries.
Backend changes must pass go test ./..., go vet ./..., and builds for both ./cmd/control-plane and ./cmd/docker-gateway; run go test -race ./... for concurrency, lifecycle, or shared-state changes. Docker or Compose changes must also pass docker compose config --quiet.
Frontend changes must install from the lockfile, pass the repository's non-interactive test command, and pass npm --prefix web run build. Changes to theme, Layout, navigation, resource actions, or the data provider require focused interaction coverage, including error and disabled states where applicable.
Preserve existing API and Docker lifecycle behavior unless the issue explicitly approves a contract change. Document any status-code, payload, configuration, migration, security, or retry impact in the PR.
Keep each PR scoped to one issue, include the issue key in its title, body, or branch, and report the exact validation commands and results. Do not use close intent unless the issue explicitly requests it.
Every code PR requires independent review. P0/P1 findings must be fixed and re-reviewed; record P2 findings as follow-up work. The implementation agent must not merge, deploy, publish, or change production configuration; hand an approved PR to the designated delivery role.