|
| 1 | +# ZITADEL Monorepo Guide for AI Agents |
| 2 | + |
| 3 | +## Mission & Context |
| 4 | +ZITADEL is an open-source Identity Management System (IAM) written in Go and Angular/React. It provides secure login, multi-tenancy, and audit trails. |
| 5 | + |
| 6 | +## Read Order |
| 7 | +1. Read this file first. |
| 8 | +2. Read the nearest scoped `AGENTS.md` for the area you edit. |
| 9 | +3. If multiple scopes apply, use the most specific path. |
| 10 | + |
| 11 | +## Repository Structure Map |
| 12 | +- **`apps/`**: Consumer-facing web applications. |
| 13 | + - **`login`**: Next.js authentication UI. See `apps/login/AGENTS.md`. |
| 14 | + - **`docs`**: Fumadocs documentation app. See `apps/docs/AGENTS.md`. |
| 15 | + - **`api`**: Backend Nx app target. See `apps/api/AGENTS.md`. |
| 16 | +- **`console/`**: Angular Management Console. See `console/AGENTS.md`. |
| 17 | +- **`internal/`**: Backend domain and service logic. See `internal/AGENTS.md`. |
| 18 | +- **`proto/`**: API definitions. See `proto/AGENTS.md`. |
| 19 | +- **`packages/`**: Shared TypeScript packages. See `packages/AGENTS.md`. |
| 20 | +- **`tests/functional-ui/`**: Cypress functional UI tests. See `tests/functional-ui/AGENTS.md`. |
| 21 | + |
| 22 | +## Technology Stack & Conventions |
| 23 | +- **Orchestration**: Nx is used for build and task orchestration. |
| 24 | +- **Package Manager**: pnpm. |
| 25 | +- **Backend**: |
| 26 | + - **Go Version Source of Truth**: Inspect `go.mod` before Go work (`go` and optional `toolchain` directives). |
| 27 | + - **Communication**: For V2 APIs, connectRPC is the primary transport. gRPC and HTTP/JSON endpoints are also supported. |
| 28 | + - **Pattern**: The backend is transitioning to a relational design. Events are still persisted in a separate table for history/audit, but events are not the system of record. |
| 29 | +- **Frontend**: |
| 30 | + - **Console**: Angular + RxJS. |
| 31 | + - **Login/Docs**: Next.js + React. |
| 32 | + |
1 | 33 | ## ZITADEL Domain & Multi-Tenancy Logic |
2 | 34 |
|
3 | 35 | ### 1. Hierarchy & Ownership |
4 | 36 |
|
5 | 37 | ZITADEL follows a strict hierarchical containment model. When generating code, logic, or translations, adhere to this structure: |
6 | 38 |
|
7 | 39 | - **System (Installation):** The entire ZITADEL deployment. Global settings are applied through runtime configuration files or environment variables. See `cmd/defaults.yaml`. |
8 | | -- **Instance (The "Identity System"):** |
| 40 | +- **Instance (The "Identity System"):** |
9 | 41 | - **Definition:** A logical partition/virtual tenant. It is a "System inside a System." |
10 | | - - **Isolation:** Data and configurations are strictly isolated between instances. |
| 42 | + - **Isolation:** Data and settings are strictly isolated between instances. |
11 | 43 | - **Translation Rule:** NEVER translate as "Example" or "Case." Use technical terms like "Tenant," "Environment," or the local equivalent of "Logical System Entity." |
12 | 44 | - **Organization:** A group within an Instance. It owns Users, Projects, and Roles. |
13 | 45 | - **Project:** A collection of Applications and Auth Policies within an Org. |
@@ -43,3 +75,34 @@ If a translation is requested for a language not listed above, follow these prio |
43 | 75 | 2. **Priority 2 (System Entity):** Use a term that implies a "running process" or "logical environment." |
44 | 76 | 3. **Priority 3 (Tenant):** If 'Instance' is ambiguous, use the local word for 'Tenant' (e.g., 租户 in Chinese). |
45 | 77 | 4. **Strict Ban:** NEVER use words that mean "an illustration", "a case", "a sample", or "an example." |
| 78 | + |
| 79 | +## Command Rules |
| 80 | +Run commands from the repository root. |
| 81 | + |
| 82 | +- Use verified Nx targets only. |
| 83 | +- If target availability is unclear, run `pnpm nx show project <project>`. |
| 84 | +- Do not assume all projects have `test`, `lint`, `build`, or `generate` targets. |
| 85 | +- Known exception: `@zitadel/console` has no configured `test` target. |
| 86 | + |
| 87 | +## Verified Common Targets |
| 88 | +- `@zitadel/api`: `prod`, `build`, `generate`, `generate-install`, `lint`, `test`, `test-unit`, `test-integration` |
| 89 | +- `@zitadel/login`: `dev`, `build`, `lint`, `test`, `test-unit`, `test-integration` |
| 90 | +- `@zitadel/docs`: `dev`, `build`, `generate`, `install-proto-plugins`, `check-links`, `check-types`, `test`, `lint` |
| 91 | +- `@zitadel/console`: `dev`, `build`, `generate`, `install-proto-plugins`, `lint` |
| 92 | + |
| 93 | +## Proto Plugin Binaries |
| 94 | +All proto plugins are installed to `.artifacts/bin/<GOOS>/<GOARCH>/` and Nx-cached. `generate` targets wire up the correct install dependency and prepend `.artifacts/bin/` to `$PATH` — no manual install step is needed. |
| 95 | + |
| 96 | +## PR Title Convention |
| 97 | + |
| 98 | +PR titles are validated by the Semantic PR app. Format: |
| 99 | + |
| 100 | +`<type>(<scope>): <short summary>` |
| 101 | + |
| 102 | +**Types**: must come from the list in [`.github/semantic.yml`](.github/semantic.yml) under `types:` — e.g. `feat`, `fix`, `docs`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`. |
| 103 | + |
| 104 | +**Scopes**: optional, but if used must come from the list in [`.github/semantic.yml`](.github/semantic.yml) under `scopes:`. When in doubt, omit the scope — do not invent values not on that list. |
| 105 | + |
| 106 | +## Documentation |
| 107 | +- **Human Guide**: See `CONTRIBUTING.md` for setup and contribution details. |
| 108 | +- **API Design**: See `API_DESIGN.md` for API specific guidelines. |
0 commit comments