{"owner":"pig-mesh","repo":"pig","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Repository Guidelines\n\n## Project Structure & Module Organization\n\n`pig` aggregates the open-source Spring Cloud services through the root `pom.xml`. Runtime services sit under dedicated\nfolders: `pig-register` (Nacos), `pig-gateway` (edge routing), `pig-auth` (authorization), `pig-upms` (user and\npermission), `pig-boot` (single-service launcher), and `pig-visual` (monitor, codegen, quartz). Shared libraries and\nDTOs live in `pig-common`. Sample SQL and Docker build contexts reside in `db/`, while infra manifests live in\n`docker-compose.yml`. Every module uses the standard `src/main/java` and `src/test/java` layout.\n\nThe open-source edition intentionally excludes workflow, app server, MP, payment, report, BI, multi-tenant, data-scope,\nand dynamic gateway route management code. Gateway routes are maintained through normal configuration files.\n\n## Build, Test, and Development Commands\n\n- Run `mvn clean install -T 4 -Pcloud` from the project root to compile the full cloud edition with the managed BOM.\n\n- `docker compose build && docker compose up` builds images and starts the local service stack.\n\n## Testing Guidelines\n\nUse `spring-boot-starter-test` (JUnit 5, AssertJ, Mockito) for unit and slice tests. Name classes `*Tests.java` and\ncolocate fixtures in `src/test/resources`. Focus coverage on authentication, gateway filters, user/permission logic,\nscheduled jobs, and code generation. Run `mvn verify` before opening a PR to exercise the full plugin stack.\n\n## Commit & Pull Request Guidelines\n\nFollow the repo’s `type(scope): summary` history, e.g. `fix(upms): clear login failure cache` or\n`feat(codegen): add template option`. Each PR must describe the impact area, list affected modules, and reference\nissues when applicable. Attach curl/Postman snippets or screenshots whenever UI or OpenAPI responses change. Avoid\ncommitting generated artifacts, and call out schema/config updates explicitly.\n\n## Security & Configuration Tips\n\nNever commit environment secrets; rely on `docker-compose.yml` plus `.env` overrides ignored by Git. Keep `db/` seed\ndata sanitized, and drive end-to-end checks against `pig-register` (ports 8848/9848) with `pig-gateway` (9999) so\ndiscovery behavior matches production.\n\n## Behavioral Guidelines\n\nThe following four rules apply to all tasks and take precedence over other default behaviors.\n\n### 1. Think Before Coding\n\n- When requirements are ambiguous, ask first — never make silent assumptions\n- If a simpler solution exists, say so explicitly rather than quietly picking a direction\n- When something is unclear, surface the confusion instead of pushing forward with guesswork\n\n### 2. Prefer Simplicity\n\n- Use the minimum code needed to solve the current problem; add nothing unrequested\n- Do not introduce abstractions for one-off code or design for hypothetical future needs\n- Ask yourself: would a senior engineer call this over-engineered?\n\n### 3. Surgical Changes\n\n- Only touch what the task requires; do not refactor adjacent code as a side effect\n- Do not alter style or structure unrelated to the current task\n- Every changed line must trace directly to a stated requirement\n\n### 4. Goal-Driven Execution\n\n- Convert vague instructions into verifiable goals — prefer tests as the success criterion\n- \"Fix a bug\" → write a failing test that reproduces it, then make it pass\n- \"Add validation\" → write tests covering invalid inputs, then make them pass\n"},"files":{"AGENTS.md":"# Repository Guidelines\n\n## Project Structure & Module Organization\n\n`pig` aggregates the open-source Spring Cloud services through the root `pom.xml`. Runtime services sit under dedicated\nfolders: `pig-register` (Nacos), `pig-gateway` (edge routing), `pig-auth` (authorization), `pig-upms` (user and\npermission), `pig-boot` (single-service launcher), and `pig-visual` (monitor, codegen, quartz). Shared libraries and\nDTOs live in `pig-common`. Sample SQL and Docker build contexts reside in `db/`, while infra manifests live in\n`docker-compose.yml`. Every module uses the standard `src/main/java` and `src/test/java` layout.\n\nThe open-source edition intentionally excludes workflow, app server, MP, payment, report, BI, multi-tenant, data-scope,\nand dynamic gateway route management code. Gateway routes are maintained through normal configuration files.\n\n## Build, Test, and Development Commands\n\n- Run `mvn clean install -T 4 -Pcloud` from the project root to compile the full cloud edition with the managed BOM.\n\n- `docker compose build && docker compose up` builds images and starts the local service stack.\n\n## Testing Guidelines\n\nUse `spring-boot-starter-test` (JUnit 5, AssertJ, Mockito) for unit and slice tests. Name classes `*Tests.java` and\ncolocate fixtures in `src/test/resources`. Focus coverage on authentication, gateway filters, user/permission logic,\nscheduled jobs, and code generation. Run `mvn verify` before opening a PR to exercise the full plugin stack.\n\n## Commit & Pull Request Guidelines\n\nFollow the repo’s `type(scope): summary` history, e.g. `fix(upms): clear login failure cache` or\n`feat(codegen): add template option`. Each PR must describe the impact area, list affected modules, and reference\nissues when applicable. Attach curl/Postman snippets or screenshots whenever UI or OpenAPI responses change. Avoid\ncommitting generated artifacts, and call out schema/config updates explicitly.\n\n## Security & Configuration Tips\n\nNever commit environment secrets; rely on `docker-compose.yml` plus `.env` overrides ignored by Git. Keep `db/` seed\ndata sanitized, and drive end-to-end checks against `pig-register` (ports 8848/9848) with `pig-gateway` (9999) so\ndiscovery behavior matches production.\n\n## Behavioral Guidelines\n\nThe following four rules apply to all tasks and take precedence over other default behaviors.\n\n### 1. Think Before Coding\n\n- When requirements are ambiguous, ask first — never make silent assumptions\n- If a simpler solution exists, say so explicitly rather than quietly picking a direction\n- When something is unclear, surface the confusion instead of pushing forward with guesswork\n\n### 2. Prefer Simplicity\n\n- Use the minimum code needed to solve the current problem; add nothing unrequested\n- Do not introduce abstractions for one-off code or design for hypothetical future needs\n- Ask yourself: would a senior engineer call this over-engineered?\n\n### 3. Surgical Changes\n\n- Only touch what the task requires; do not refactor adjacent code as a side effect\n- Do not alter style or structure unrelated to the current task\n- Every changed line must trace directly to a stated requirement\n\n### 4. Goal-Driven Execution\n\n- Convert vague instructions into verifiable goals — prefer tests as the success criterion\n- \"Fix a bug\" → write a failing test that reproduces it, then make it pass\n- \"Add validation\" → write tests covering invalid inputs, then make them pass\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Repository Guidelines\n\n## Project Structure & Module Organization\n\n`pig` aggregates the open-source Spring Cloud services through the root `pom.xml`. Runtime services sit under dedicated\nfolders: `pig-register` (Nacos), `pig-gateway` (edge routing), `pig-auth` (authorization), `pig-upms` (user and\npermission), `pig-boot` (single-service launcher), and `pig-visual` (monitor, codegen, quartz). Shared libraries and\nDTOs live in `pig-common`. Sample SQL and Docker build contexts reside in `db/`, while infra manifests live in\n`docker-compose.yml`. Every module uses the standard `src/main/java` and `src/test/java` layout.\n\nThe open-source edition intentionally excludes workflow, app server, MP, payment, report, BI, multi-tenant, data-scope,\nand dynamic gateway route management code. Gateway routes are maintained through normal configuration files.\n\n## Build, Test, and Development Commands\n\n- Run `mvn clean install -T 4 -Pcloud` from the project root to compile the full cloud edition with the managed BOM.\n\n- `docker compose build && docker compose up` builds images and starts the local service stack.\n\n## Testing Guidelines\n\nUse `spring-boot-starter-test` (JUnit 5, AssertJ, Mockito) for unit and slice tests. Name classes `*Tests.java` and\ncolocate fixtures in `src/test/resources`. Focus coverage on authentication, gateway filters, user/permission logic,\nscheduled jobs, and code generation. Run `mvn verify` before opening a PR to exercise the full plugin stack.\n\n## Commit & Pull Request Guidelines\n\nFollow the repo’s `type(scope): summary` history, e.g. `fix(upms): clear login failure cache` or\n`feat(codegen): add template option`. Each PR must describe the impact area, list affected modules, and reference\nissues when applicable. Attach curl/Postman snippets or screenshots whenever UI or OpenAPI responses change. Avoid\ncommitting generated artifacts, and call out schema/config updates explicitly.\n\n## Security & Configuration Tips\n\nNever commit environment secrets; rely on `docker-compose.yml` plus `.env` overrides ignored by Git. Keep `db/` seed\ndata sanitized, and drive end-to-end checks against `pig-register` (ports 8848/9848) with `pig-gateway` (9999) so\ndiscovery behavior matches production.\n\n## Behavioral Guidelines\n\nThe following four rules apply to all tasks and take precedence over other default behaviors.\n\n### 1. Think Before Coding\n\n- When requirements are ambiguous, ask first — never make silent assumptions\n- If a simpler solution exists, say so explicitly rather than quietly picking a direction\n- When something is unclear, surface the confusion instead of pushing forward with guesswork\n\n### 2. Prefer Simplicity\n\n- Use the minimum code needed to solve the current problem; add nothing unrequested\n- Do not introduce abstractions for one-off code or design for hypothetical future needs\n- Ask yourself: would a senior engineer call this over-engineered?\n\n### 3. Surgical Changes\n\n- Only touch what the task requires; do not refactor adjacent code as a side effect\n- Do not alter style or structure unrelated to the current task\n- Every changed line must trace directly to a stated requirement\n\n### 4. Goal-Driven Execution\n\n- Convert vague instructions into verifiable goals — prefer tests as the success criterion\n- \"Fix a bug\" → write a failing test that reproduces it, then make it pass\n- \"Add validation\" → write tests covering invalid inputs, then make them pass\n","category":"root","tokens":855}]}