Curious about 'commit generated output separately'. Is that for reviewability or does something break otherwise?
Index
Feed
Maintained by tessellate · updated Aug 3, 2026
The root file that keeps five agents from treating 40 packages as one big sandbox: affected-only commands, module boundaries with an owner column, and a hard rule about generated code.
- `apps/` — deployables: `web` (Next.js), `api` (Nest), `worker`, `admin`
- `libs/shared/` — cross-cutting: `ui`, `util`, `types`, `config`. CHANGES HERE FAN OUT — see boundary rules.
- `libs/domain/` — business logic per domain: `billing`, `catalog`, `identity`, `shipping`
- `tools/` — generators and scripts. Generated outputs are marked with `@generated` headers.
- Project graph when confused: `npx nx graph --focus=<project> --print` (do NOT open the web UI).The workspace is too big for full runs. Always scope:
- Test what you changed: `npx nx affected -t test --base=main`
- Build + lint + test gate: `npx nx affected -t build,lint,test --base=main`
- One project: `npx nx test domain-billing` / `npx nx build web`
- NEVER `nx run-many -t test --all`. It takes 40 minutes and tells us nothing affected didn't.AGENTS.md
Restructured around 'affected only' after measuring agents spending 30+ minutes per session on full test runs.
Jul 9, 2026Added the generated-code section — an agent hand-edited 12 @generated API clients and the next codegen run erased its work.
Jun 6, 2026'Lint failures are design feedback, not obstacles' — tightened after an agent suppressed a boundary rule to finish a task.
May 14, 2026Running this config?
Sign in to add your report — every count here is backed by a named account.
Enforced by `@nx/enforce-module-boundaries` — lint failures here are design feedback, not obstacles.
- `apps/*` may import `libs/*`; libs NEVER import from apps.
- `libs/domain/*` may import `libs/shared/*` but not other domains. Cross-domain needs go through events (`libs/shared/events`) — ask before adding one.
- `libs/shared/*` imports nothing outside `libs/shared`. It is the bottom of the graph.
- Owners: `shared/*` platform team; `domain/billing` payments team; everything else, the team in `CODEOWNERS`. Changing another team's lib: make the change minimal and flag it in the PR description.- Files with an `@generated` header are NEVER edited directly. Find the generator under `tools/generators` and change the source. If unclear, `git log --follow <file>` shows the generator commit pattern.
- After running a generator, commit generated output separately from hand-written changes.- Unit tests colocated; `nx affected -t test` must be green before you call anything done.
- Integration tests (`apps/api-e2e`) run only when your change touches `apps/api` or `libs/domain/*` public APIs.
- Do not increase any project's `testTimeout` to make a flaky test pass. Report the flake.- Root config files (`nx.json`, `tsconfig.base.json`, `pnpm-workspace.yaml`, root `package.json`): human-only.
- No new projects without the generator: `npx nx g @nx/js:lib` — and ask first.
- Do not "clean up" imports across projects you weren't asked to touch; wide mechanical PRs break every open branch.1. `npx nx affected -t build,lint,test --base=main` green, output included in your summary.
2. Diff contained to the projects the task named (plus generated output, committed separately).
3. Any boundary-lint suppression = automatic failure. There are currently zero; keep it that way.# AGENTS.md — platform monorepo
Nx workspace, ~400k LOC, 40+ projects. pnpm + Nx 20. Read this before touching anything.
## Orientation
- `apps/` — deployables: `web` (Next.js), `api` (Nest), `worker`, `admin`
- `libs/shared/` — cross-cutting: `ui`, `util`, `types`, `config`. CHANGES HERE FAN OUT — see boundary rules.
- `libs/domain/` — business logic per domain: `billing`, `catalog`, `identity`, `shipping`
- `tools/` — generators and scripts. Generated outputs are marked with `@generated` headers.
- Project graph when confused: `npx nx graph --focus=<project> --print` (do NOT open the web UI).
## Commands — affected only
The workspace is too big for full runs. Always scope:
- Test what you changed: `npx nx affected -t test --base=main`
- Build + lint + test gate: `npx nx affected -t build,lint,test --base=main`
- One project: `npx nx test domain-billing` / `npx nx build web`
- NEVER `nx run-many -t test --all`. It takes 40 minutes and tells us nothing affected didn't.
## Module boundaries
Enforced by `@nx/enforce-module-boundaries` — lint failures here are design feedback, not obstacles.
- `apps/*` may import `libs/*`; libs NEVER import from apps.
- `libs/domain/*` may import `libs/shared/*` but not other domains. Cross-domain needs go through events (`libs/shared/events`) — ask before adding one.
- `libs/shared/*` imports nothing outside `libs/shared`. It is the bottom of the graph.
- Owners: `shared/*` platform team; `domain/billing` payments team; everything else, the team in `CODEOWNERS`. Changing another team's lib: make the change minimal and flag it in the PR description.
## Generated code
- Files with an `@generated` header are NEVER edited directly. Find the generator under `tools/generators` and change the source. If unclear, `git log --follow <file>` shows the generator commit pattern.
- After running a generator, commit generated output separately from hand-written changes.
## Testing
- Unit tests colocated; `nx affected -t test` must be green before you call anything done.
- Integration tests (`apps/api-e2e`) run only when your change touches `apps/api` or `libs/domain/*` public APIs.
- Do not increase any project's `testTimeout` to make a flaky test pass. Report the flake.
## Prohibited
- Root config files (`nx.json`, `tsconfig.base.json`, `pnpm-workspace.yaml`, root `package.json`): human-only.
- No new projects without the generator: `npx nx g @nx/js:lib` — and ask first.
- Do not "clean up" imports across projects you weren't asked to touch; wide mechanical PRs break every open branch.
## Done means
1. `npx nx affected -t build,lint,test --base=main` green, output included in your summary.
2. Diff contained to the projects the task named (plus generated output, committed separately).
3. Any boundary-lint suppression = automatic failure. There are currently zero; keep it that way.
Strong evidence gets promoted into the record above.
Curious about 'commit generated output separately'. Is that for reviewability or does something break otherwise?
Reviewability, and revertability. A mixed commit means reverting the hand-written mistake also reverts codegen someone else may have rerun since. Separate commits let CODEOWNERS filters route the generated part to a rubber-stamp lane too.
Sign in to join the discussion, vote, and verify fixes.
Related records
The owner column in the boundaries section is the underrated part. Agents write better PR descriptions when they know a HUMAN team owns the thing they're touching — 'flag it in the PR description' actually happens.