Make targets & Redis key conventions

Two small but daily references: the super-repo make targets, and the Redis key naming contract every service must honour.

Make targets

Run from the super-repo root (Makefile). make help prints the full list.

Target	What it does
`make bootstrap`	Check tools, init submodules, create `.env`
`make up`	Build every image + start the backend stack (detached)
`make up-frontend`	Also start the SaaS app + UI2.0 (`frontend` profile)
`make doctor`	Verify tools, token, health, ports
`make ps`	Container status
`make logs`	Tail all logs (one service: `make logs s=core-mcp`)
`make restart` / `make stop` / `make down`	Restart / stop / stop-and-remove (keeps data)
`make update`	Pull latest submodule branches
`make proto`	Refresh generated proto stubs
`make azurite-init`	Create blob containers (once, before uploads)
`make agent-tool-id`	Print the Agent One tool id (for `AGENT_TOOL_ID`)
`make db-reset`	Wipe Postgres + reload schema (destructive)
`make clean` / `make nuke`	Down + drop volumes (destructive)
`make wire`	Adopt existing plain clones as submodules
`make deploy-staging`	Trigger staging deploys
`make build`	Build images without starting

Every Redis key is namespaced so environments never collide and cross-language services agree on the same key:

{env}:{namespace}:{rest}

{env} — the value of ENVIRONMENT (staging, prod, or your local env). Two services with mismatched ENVIRONMENT silently read/write different keys — a common “it registered but nothing shows up” cause.
{namespace} — the functional area. The common: namespace is the cross-language contract: keys any two services (Go + Python) must both compute identically (e.g. the task:wake pub/sub channel). Change one side and you must change the other in lockstep.
{rest} — the specific key (ids, suffixes).