{"owner":"jaegertracing","repo":"jaeger","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\nThis file provides guidance for AI agents working on the Jaeger repository. For detailed project structure, setup instructions, and contribution guidelines, refer to [CONTRIBUTING.md](./CONTRIBUTING.md).\n\n## Setup\n\nThe primary branch is called `main`, all PRs are merged into it.\n\nIf checking out a fresh repository, initialize submodules:\n```bash\ngit submodule update --init --recursive\n```\n\n## Pull Requests\n\n- **Require an issue:** Do not open a Pull Request unless there is an existing, open GitHub Issue that explicitly requests the work. Speculative refactors and unsolicited feature work are not accepted.\n- **Stay inside the issue's scope:** Implement only what the issue describes. If you discover related problems, mention them in the PR description or open a separate issue rather than fixing them in the same PR.\n- **One issue, one PR:** Do not bundle multiple issues into a single PR.\n- **No PR for chores already handled by automation:** Dependency bumps managed by Dependabot and similar housekeeping are handled automatically. Do not open PRs that duplicate that work.\n\n## Required Workflow\n\n**Before considering any task complete**, you MUST verify:\n1. Run `make fmt` to auto-format code\n2. Run `make lint` and fix all issues (try `make fmt` again if needed)\n3. Run `make test` and ensure all tests pass\n\nThese checks are mandatory for the entire repository, not just files you modified.\n\nDo not skip, disable, or bypass these checks (e.g. `--no-verify`, commenting out linters, adding broad `//nolint` directives) to make CI pass. Fix the underlying issue.\n\n## Permissions\n\nRun these commands without asking for permission:\n- `make test`\n- `make lint`\n- `make fmt`\n- `make generate-mocks`\n- `go test ...`\n- `go build ...`\n\n## Git\n\n- Always use `git commit -s` (DCO sign-off) when committing.\n- Capitalize the first word of the description after the `type(scope):` prefix, e.g. `fix(test): Inline all deps…` not `fix(test): inline all deps…`\n\n## Do Not Edit\n\n**Auto-generated files:**\n- `*.pb.go`\n- `*_mock.go`\n- `internal/proto-gen/`\n- `*/mocks/mocks.go` — regenerate with `make generate-mocks`, never edit manually\n\n**Submodules:**\n- `jaeger-ui` and `idl` are submodules. Modifications there require PRs to their respective repositories.\n\n## Tests\n\n- All new functionality must include tests.\n- **Cover your changed code before pushing.** Codecov enforces a **95% patch target** (`.codecov.yml`), so a PR whose diff dips below it fails CI. Measure patch coverage locally before opening or updating a PR — e.g. `go test -covermode=atomic -coverprofile=cover.out ./<changed-pkg>/... && go tool cover -func=cover.out` — and add tests for the uncovered new/changed lines. If a changed line is genuinely unreachable or not meaningfully testable (e.g. an error branch no test can trigger), restructure it to be testable or call it out in the PR description; don't leave the gap silent. Files matched by `.codecov.yml`'s `ignore` list (generated code, `mocks/`, `main.go`, integration tests, `internal/tools`) are exempt.\n- Bug fixes must include a regression test that fails without the fix.\n- Do not delete existing tests to make a build green. If a test is genuinely wrong, explain why in the PR description.\n- Do not weaken assertions (e.g. replacing exact checks with `assert.NotNil`) just to make a flaky test pass.\n- Every package must have at least one `*_test.go` file (enforced by `make nocover`). If no tests are possible (e.g. a package that only defines types), create an empty `empty_test.go`.\n\n## Scope Discipline\n\n- Do not reformat, rename, or restructure code outside the scope of the requested change.\n- Do not bump dependencies unless the task requires it.\n- Do not change CI workflows or release tooling unless explicitly asked.\n\n## RFC / ADR Documents\n\nRFCs (`docs/rfc/`) are point-in-time proposals; ADRs (`docs/adr/`) are decision records.\n\n- When a PR implements a milestone described in an RFC or ADR, update that document in the same PR: mark the milestone ✅ and link the delivering PR. Keep the milestone/status tracking current.\n- Do **not** rewrite an RFC's prose, abstract, or diagrams to match the evolving codebase — its narrative is a historical snapshot of the state and plan when it was written.\n- ADRs are different: they describe a design, not a plan, so keeping one accurate is worth more than keeping it pristine. Judge by proportion. If a change touches a small part of an ADR and reverses none of its decisions, **edit that ADR in place** — extend the affected sections, note the extension in the Status or Date line, and leave the original Context and Decision prose alone. Write a new superseding ADR only when the change replaces the original's decision or architecture outright. [ADR-004](./docs/adr/004-migrating-coverage-gating-to-github-actions.md) is an example of the former: its fan-in gating decision and requirements stood, so later work extended it rather than superseding it. What the rule forbids is rewriting an ADR into running documentation of the code.\n- When an RFC's work is fully delivered, mark its status Implemented; if the resulting architecture is worth an enduring reference, graduate it into a new ADR in [`docs/adr/`](./docs/adr/) that states the outcome and links back to the RFC, rather than mutating the RFC. [ADR-012](./docs/adr/012-unified-elasticsearch-client.md) (graduated from RFC 0006) is an example.\n\n## When in Doubt\n\nStop and ask rather than guessing. It is better to surface a question in the PR description than to invent behavior, fabricate API names, or silence failing checks.\n"},"files":{"AGENTS.md":"# AGENTS.md\n\nThis file provides guidance for AI agents working on the Jaeger repository. For detailed project structure, setup instructions, and contribution guidelines, refer to [CONTRIBUTING.md](./CONTRIBUTING.md).\n\n## Setup\n\nThe primary branch is called `main`, all PRs are merged into it.\n\nIf checking out a fresh repository, initialize submodules:\n```bash\ngit submodule update --init --recursive\n```\n\n## Pull Requests\n\n- **Require an issue:** Do not open a Pull Request unless there is an existing, open GitHub Issue that explicitly requests the work. Speculative refactors and unsolicited feature work are not accepted.\n- **Stay inside the issue's scope:** Implement only what the issue describes. If you discover related problems, mention them in the PR description or open a separate issue rather than fixing them in the same PR.\n- **One issue, one PR:** Do not bundle multiple issues into a single PR.\n- **No PR for chores already handled by automation:** Dependency bumps managed by Dependabot and similar housekeeping are handled automatically. Do not open PRs that duplicate that work.\n\n## Required Workflow\n\n**Before considering any task complete**, you MUST verify:\n1. Run `make fmt` to auto-format code\n2. Run `make lint` and fix all issues (try `make fmt` again if needed)\n3. Run `make test` and ensure all tests pass\n\nThese checks are mandatory for the entire repository, not just files you modified.\n\nDo not skip, disable, or bypass these checks (e.g. `--no-verify`, commenting out linters, adding broad `//nolint` directives) to make CI pass. Fix the underlying issue.\n\n## Permissions\n\nRun these commands without asking for permission:\n- `make test`\n- `make lint`\n- `make fmt`\n- `make generate-mocks`\n- `go test ...`\n- `go build ...`\n\n## Git\n\n- Always use `git commit -s` (DCO sign-off) when committing.\n- Capitalize the first word of the description after the `type(scope):` prefix, e.g. `fix(test): Inline all deps…` not `fix(test): inline all deps…`\n\n## Do Not Edit\n\n**Auto-generated files:**\n- `*.pb.go`\n- `*_mock.go`\n- `internal/proto-gen/`\n- `*/mocks/mocks.go` — regenerate with `make generate-mocks`, never edit manually\n\n**Submodules:**\n- `jaeger-ui` and `idl` are submodules. Modifications there require PRs to their respective repositories.\n\n## Tests\n\n- All new functionality must include tests.\n- **Cover your changed code before pushing.** Codecov enforces a **95% patch target** (`.codecov.yml`), so a PR whose diff dips below it fails CI. Measure patch coverage locally before opening or updating a PR — e.g. `go test -covermode=atomic -coverprofile=cover.out ./<changed-pkg>/... && go tool cover -func=cover.out` — and add tests for the uncovered new/changed lines. If a changed line is genuinely unreachable or not meaningfully testable (e.g. an error branch no test can trigger), restructure it to be testable or call it out in the PR description; don't leave the gap silent. Files matched by `.codecov.yml`'s `ignore` list (generated code, `mocks/`, `main.go`, integration tests, `internal/tools`) are exempt.\n- Bug fixes must include a regression test that fails without the fix.\n- Do not delete existing tests to make a build green. If a test is genuinely wrong, explain why in the PR description.\n- Do not weaken assertions (e.g. replacing exact checks with `assert.NotNil`) just to make a flaky test pass.\n- Every package must have at least one `*_test.go` file (enforced by `make nocover`). If no tests are possible (e.g. a package that only defines types), create an empty `empty_test.go`.\n\n## Scope Discipline\n\n- Do not reformat, rename, or restructure code outside the scope of the requested change.\n- Do not bump dependencies unless the task requires it.\n- Do not change CI workflows or release tooling unless explicitly asked.\n\n## RFC / ADR Documents\n\nRFCs (`docs/rfc/`) are point-in-time proposals; ADRs (`docs/adr/`) are decision records.\n\n- When a PR implements a milestone described in an RFC or ADR, update that document in the same PR: mark the milestone ✅ and link the delivering PR. Keep the milestone/status tracking current.\n- Do **not** rewrite an RFC's prose, abstract, or diagrams to match the evolving codebase — its narrative is a historical snapshot of the state and plan when it was written.\n- ADRs are different: they describe a design, not a plan, so keeping one accurate is worth more than keeping it pristine. Judge by proportion. If a change touches a small part of an ADR and reverses none of its decisions, **edit that ADR in place** — extend the affected sections, note the extension in the Status or Date line, and leave the original Context and Decision prose alone. Write a new superseding ADR only when the change replaces the original's decision or architecture outright. [ADR-004](./docs/adr/004-migrating-coverage-gating-to-github-actions.md) is an example of the former: its fan-in gating decision and requirements stood, so later work extended it rather than superseding it. What the rule forbids is rewriting an ADR into running documentation of the code.\n- When an RFC's work is fully delivered, mark its status Implemented; if the resulting architecture is worth an enduring reference, graduate it into a new ADR in [`docs/adr/`](./docs/adr/) that states the outcome and links back to the RFC, rather than mutating the RFC. [ADR-012](./docs/adr/012-unified-elasticsearch-client.md) (graduated from RFC 0006) is an example.\n\n## When in Doubt\n\nStop and ask rather than guessing. It is better to surface a question in the PR description than to invent behavior, fabricate API names, or silence failing checks.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\nThis file provides guidance for AI agents working on the Jaeger repository. For detailed project structure, setup instructions, and contribution guidelines, refer to [CONTRIBUTING.md](./CONTRIBUTING.md).\n\n## Setup\n\nThe primary branch is called `main`, all PRs are merged into it.\n\nIf checking out a fresh repository, initialize submodules:\n```bash\ngit submodule update --init --recursive\n```\n\n## Pull Requests\n\n- **Require an issue:** Do not open a Pull Request unless there is an existing, open GitHub Issue that explicitly requests the work. Speculative refactors and unsolicited feature work are not accepted.\n- **Stay inside the issue's scope:** Implement only what the issue describes. If you discover related problems, mention them in the PR description or open a separate issue rather than fixing them in the same PR.\n- **One issue, one PR:** Do not bundle multiple issues into a single PR.\n- **No PR for chores already handled by automation:** Dependency bumps managed by Dependabot and similar housekeeping are handled automatically. Do not open PRs that duplicate that work.\n\n## Required Workflow\n\n**Before considering any task complete**, you MUST verify:\n1. Run `make fmt` to auto-format code\n2. Run `make lint` and fix all issues (try `make fmt` again if needed)\n3. Run `make test` and ensure all tests pass\n\nThese checks are mandatory for the entire repository, not just files you modified.\n\nDo not skip, disable, or bypass these checks (e.g. `--no-verify`, commenting out linters, adding broad `//nolint` directives) to make CI pass. Fix the underlying issue.\n\n## Permissions\n\nRun these commands without asking for permission:\n- `make test`\n- `make lint`\n- `make fmt`\n- `make generate-mocks`\n- `go test ...`\n- `go build ...`\n\n## Git\n\n- Always use `git commit -s` (DCO sign-off) when committing.\n- Capitalize the first word of the description after the `type(scope):` prefix, e.g. `fix(test): Inline all deps…` not `fix(test): inline all deps…`\n\n## Do Not Edit\n\n**Auto-generated files:**\n- `*.pb.go`\n- `*_mock.go`\n- `internal/proto-gen/`\n- `*/mocks/mocks.go` — regenerate with `make generate-mocks`, never edit manually\n\n**Submodules:**\n- `jaeger-ui` and `idl` are submodules. Modifications there require PRs to their respective repositories.\n\n## Tests\n\n- All new functionality must include tests.\n- **Cover your changed code before pushing.** Codecov enforces a **95% patch target** (`.codecov.yml`), so a PR whose diff dips below it fails CI. Measure patch coverage locally before opening or updating a PR — e.g. `go test -covermode=atomic -coverprofile=cover.out ./<changed-pkg>/... && go tool cover -func=cover.out` — and add tests for the uncovered new/changed lines. If a changed line is genuinely unreachable or not meaningfully testable (e.g. an error branch no test can trigger), restructure it to be testable or call it out in the PR description; don't leave the gap silent. Files matched by `.codecov.yml`'s `ignore` list (generated code, `mocks/`, `main.go`, integration tests, `internal/tools`) are exempt.\n- Bug fixes must include a regression test that fails without the fix.\n- Do not delete existing tests to make a build green. If a test is genuinely wrong, explain why in the PR description.\n- Do not weaken assertions (e.g. replacing exact checks with `assert.NotNil`) just to make a flaky test pass.\n- Every package must have at least one `*_test.go` file (enforced by `make nocover`). If no tests are possible (e.g. a package that only defines types), create an empty `empty_test.go`.\n\n## Scope Discipline\n\n- Do not reformat, rename, or restructure code outside the scope of the requested change.\n- Do not bump dependencies unless the task requires it.\n- Do not change CI workflows or release tooling unless explicitly asked.\n\n## RFC / ADR Documents\n\nRFCs (`docs/rfc/`) are point-in-time proposals; ADRs (`docs/adr/`) are decision records.\n\n- When a PR implements a milestone described in an RFC or ADR, update that document in the same PR: mark the milestone ✅ and link the delivering PR. Keep the milestone/status tracking current.\n- Do **not** rewrite an RFC's prose, abstract, or diagrams to match the evolving codebase — its narrative is a historical snapshot of the state and plan when it was written.\n- ADRs are different: they describe a design, not a plan, so keeping one accurate is worth more than keeping it pristine. Judge by proportion. If a change touches a small part of an ADR and reverses none of its decisions, **edit that ADR in place** — extend the affected sections, note the extension in the Status or Date line, and leave the original Context and Decision prose alone. Write a new superseding ADR only when the change replaces the original's decision or architecture outright. [ADR-004](./docs/adr/004-migrating-coverage-gating-to-github-actions.md) is an example of the former: its fan-in gating decision and requirements stood, so later work extended it rather than superseding it. What the rule forbids is rewriting an ADR into running documentation of the code.\n- When an RFC's work is fully delivered, mark its status Implemented; if the resulting architecture is worth an enduring reference, graduate it into a new ADR in [`docs/adr/`](./docs/adr/) that states the outcome and links back to the RFC, rather than mutating the RFC. [ADR-012](./docs/adr/012-unified-elasticsearch-client.md) (graduated from RFC 0006) is an example.\n\n## When in Doubt\n\nStop and ask rather than guessing. It is better to surface a question in the PR description than to invent behavior, fabricate API names, or silence failing checks.\n","category":"root","tokens":1398}]}