{"owner":"doorkeeper-gem","repo":"doorkeeper","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Doorkeeper Codebase Guide for AI Agents\n\nDoorkeeper is a Ruby gem and Rails engine that implements an OAuth 2 provider for Rails and Grape applications.\n\n## Core expectations\n\n- Treat OAuth behavior and security requirements as the primary constraint. Changes should stay aligned with the relevant RFCs, especially RFC 6749, RFC 6819, RFC 7009, RFC 7636, RFC 7662, and RFC 8252 where applicable.\n- Prefer compatibility-safe changes. Doorkeeper is a library used by host apps, so avoid breaking public APIs, configuration, routes, token semantics, and view overrides unless the task explicitly requires it.\n- Keep both Rails and Grape support in mind when changing shared protocol logic.\n\n## Architecture map\n\n- `lib/doorkeeper.rb` is the main entry point and autoload map.\n- `lib/doorkeeper/engine.rb` wires the Rails engine, routes, helpers, asset behavior, and ORM hooks.\n- `lib/doorkeeper/oauth/**` contains most protocol-level request, response, token, and authorization logic.\n- `lib/doorkeeper/request/**` contains grant/request strategy parsing.\n- `lib/doorkeeper/models/**` and `lib/doorkeeper/orm/**` hold model mixins, concerns, and ORM integration.\n- `app/controllers/doorkeeper/**` and `app/views/doorkeeper/**` are the engine controllers and UI views exposed to host apps.\n- `spec/dummy/` is the embedded Rails app used by request, controller, routing, and integration specs.\n\n## Where to add tests\n\n- Request and endpoint behavior: `spec/requests/**`\n- Controller behavior: `spec/controllers/**`\n- Model and mixin behavior: `spec/models/**`\n- Routing behavior: `spec/routing/**`\n- Generator behavior: `spec/generators/**`\n- Grape integration: `spec/grape/**`\n\nReuse the helpers and shared support code under `spec/support/**` instead of introducing duplicate test setup.\n\n## Development workflow\n\nFrom the repository root:\n\n```bash\nbundle install\nbundle exec rake spec\nbundle exec rubocop\n```\n\nUseful targeted commands:\n\n```bash\nbundle exec rspec spec/path/to/file_spec.rb\nbundle exec rake doorkeeper:server\n```\n\nTo test against a specific Rails version, use one of the gemfiles that actually exists in `gemfiles/`, for example:\n\n```bash\nBUNDLE_GEMFILE=gemfiles/rails_7_2.gemfile bundle exec rake spec\n```\n\n## Code conventions\n\n- Follow `.rubocop.yml` and `.rubocop_todo.yml`.\n- The codebase prefers `# frozen_string_literal: true` and double-quoted strings.\n- Keep line length and formatting aligned with RuboCop rather than hand-rolling a different style.\n- Preserve existing naming and directory conventions; protocol logic usually belongs in `lib/doorkeeper/**`, not in ad hoc helpers.\n\n## Change guidance\n\n- Preserve backward compatibility.\n- Make surgical changes with specs close to the behavior you changed.\n- When changing engine behavior, check whether the impact also reaches host-app integration through `spec/dummy`.\n- When changing protocol or token behavior, look for nearby request, controller, and model specs that should move together.\n- Avoid introducing behavior that silently weakens validation, token handling, revocation, scope checks, redirect URI checks, or client authentication.\n\n## Changelog and docs\n\n- For user-visible fixes or features, add an entry under `## main` in `CHANGELOG.md`.\n- Match the existing changelog style when a PR number is known: `- [#1234] Brief description`\n- Update user-facing docs when changing public configuration, supported behavior, generators, or visible views. Start with `README.md`, `UPGRADE.md`, and inline YARD/RDoc comments where relevant.\n\n## Practical reminders\n\n- Prefer existing rake tasks and repository tooling over custom scripts.\n- Do not assume examples in older docs are current; verify against files present in this repository.\n- If you touch views or translations, check for user override implications and mention them when they affect upgrades.\n"},"files":{"AGENTS.md":"# Doorkeeper Codebase Guide for AI Agents\n\nDoorkeeper is a Ruby gem and Rails engine that implements an OAuth 2 provider for Rails and Grape applications.\n\n## Core expectations\n\n- Treat OAuth behavior and security requirements as the primary constraint. Changes should stay aligned with the relevant RFCs, especially RFC 6749, RFC 6819, RFC 7009, RFC 7636, RFC 7662, and RFC 8252 where applicable.\n- Prefer compatibility-safe changes. Doorkeeper is a library used by host apps, so avoid breaking public APIs, configuration, routes, token semantics, and view overrides unless the task explicitly requires it.\n- Keep both Rails and Grape support in mind when changing shared protocol logic.\n\n## Architecture map\n\n- `lib/doorkeeper.rb` is the main entry point and autoload map.\n- `lib/doorkeeper/engine.rb` wires the Rails engine, routes, helpers, asset behavior, and ORM hooks.\n- `lib/doorkeeper/oauth/**` contains most protocol-level request, response, token, and authorization logic.\n- `lib/doorkeeper/request/**` contains grant/request strategy parsing.\n- `lib/doorkeeper/models/**` and `lib/doorkeeper/orm/**` hold model mixins, concerns, and ORM integration.\n- `app/controllers/doorkeeper/**` and `app/views/doorkeeper/**` are the engine controllers and UI views exposed to host apps.\n- `spec/dummy/` is the embedded Rails app used by request, controller, routing, and integration specs.\n\n## Where to add tests\n\n- Request and endpoint behavior: `spec/requests/**`\n- Controller behavior: `spec/controllers/**`\n- Model and mixin behavior: `spec/models/**`\n- Routing behavior: `spec/routing/**`\n- Generator behavior: `spec/generators/**`\n- Grape integration: `spec/grape/**`\n\nReuse the helpers and shared support code under `spec/support/**` instead of introducing duplicate test setup.\n\n## Development workflow\n\nFrom the repository root:\n\n```bash\nbundle install\nbundle exec rake spec\nbundle exec rubocop\n```\n\nUseful targeted commands:\n\n```bash\nbundle exec rspec spec/path/to/file_spec.rb\nbundle exec rake doorkeeper:server\n```\n\nTo test against a specific Rails version, use one of the gemfiles that actually exists in `gemfiles/`, for example:\n\n```bash\nBUNDLE_GEMFILE=gemfiles/rails_7_2.gemfile bundle exec rake spec\n```\n\n## Code conventions\n\n- Follow `.rubocop.yml` and `.rubocop_todo.yml`.\n- The codebase prefers `# frozen_string_literal: true` and double-quoted strings.\n- Keep line length and formatting aligned with RuboCop rather than hand-rolling a different style.\n- Preserve existing naming and directory conventions; protocol logic usually belongs in `lib/doorkeeper/**`, not in ad hoc helpers.\n\n## Change guidance\n\n- Preserve backward compatibility.\n- Make surgical changes with specs close to the behavior you changed.\n- When changing engine behavior, check whether the impact also reaches host-app integration through `spec/dummy`.\n- When changing protocol or token behavior, look for nearby request, controller, and model specs that should move together.\n- Avoid introducing behavior that silently weakens validation, token handling, revocation, scope checks, redirect URI checks, or client authentication.\n\n## Changelog and docs\n\n- For user-visible fixes or features, add an entry under `## main` in `CHANGELOG.md`.\n- Match the existing changelog style when a PR number is known: `- [#1234] Brief description`\n- Update user-facing docs when changing public configuration, supported behavior, generators, or visible views. Start with `README.md`, `UPGRADE.md`, and inline YARD/RDoc comments where relevant.\n\n## Practical reminders\n\n- Prefer existing rake tasks and repository tooling over custom scripts.\n- Do not assume examples in older docs are current; verify against files present in this repository.\n- If you touch views or translations, check for user override implications and mention them when they affect upgrades.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Doorkeeper Codebase Guide for AI Agents\n\nDoorkeeper is a Ruby gem and Rails engine that implements an OAuth 2 provider for Rails and Grape applications.\n\n## Core expectations\n\n- Treat OAuth behavior and security requirements as the primary constraint. Changes should stay aligned with the relevant RFCs, especially RFC 6749, RFC 6819, RFC 7009, RFC 7636, RFC 7662, and RFC 8252 where applicable.\n- Prefer compatibility-safe changes. Doorkeeper is a library used by host apps, so avoid breaking public APIs, configuration, routes, token semantics, and view overrides unless the task explicitly requires it.\n- Keep both Rails and Grape support in mind when changing shared protocol logic.\n\n## Architecture map\n\n- `lib/doorkeeper.rb` is the main entry point and autoload map.\n- `lib/doorkeeper/engine.rb` wires the Rails engine, routes, helpers, asset behavior, and ORM hooks.\n- `lib/doorkeeper/oauth/**` contains most protocol-level request, response, token, and authorization logic.\n- `lib/doorkeeper/request/**` contains grant/request strategy parsing.\n- `lib/doorkeeper/models/**` and `lib/doorkeeper/orm/**` hold model mixins, concerns, and ORM integration.\n- `app/controllers/doorkeeper/**` and `app/views/doorkeeper/**` are the engine controllers and UI views exposed to host apps.\n- `spec/dummy/` is the embedded Rails app used by request, controller, routing, and integration specs.\n\n## Where to add tests\n\n- Request and endpoint behavior: `spec/requests/**`\n- Controller behavior: `spec/controllers/**`\n- Model and mixin behavior: `spec/models/**`\n- Routing behavior: `spec/routing/**`\n- Generator behavior: `spec/generators/**`\n- Grape integration: `spec/grape/**`\n\nReuse the helpers and shared support code under `spec/support/**` instead of introducing duplicate test setup.\n\n## Development workflow\n\nFrom the repository root:\n\n```bash\nbundle install\nbundle exec rake spec\nbundle exec rubocop\n```\n\nUseful targeted commands:\n\n```bash\nbundle exec rspec spec/path/to/file_spec.rb\nbundle exec rake doorkeeper:server\n```\n\nTo test against a specific Rails version, use one of the gemfiles that actually exists in `gemfiles/`, for example:\n\n```bash\nBUNDLE_GEMFILE=gemfiles/rails_7_2.gemfile bundle exec rake spec\n```\n\n## Code conventions\n\n- Follow `.rubocop.yml` and `.rubocop_todo.yml`.\n- The codebase prefers `# frozen_string_literal: true` and double-quoted strings.\n- Keep line length and formatting aligned with RuboCop rather than hand-rolling a different style.\n- Preserve existing naming and directory conventions; protocol logic usually belongs in `lib/doorkeeper/**`, not in ad hoc helpers.\n\n## Change guidance\n\n- Preserve backward compatibility.\n- Make surgical changes with specs close to the behavior you changed.\n- When changing engine behavior, check whether the impact also reaches host-app integration through `spec/dummy`.\n- When changing protocol or token behavior, look for nearby request, controller, and model specs that should move together.\n- Avoid introducing behavior that silently weakens validation, token handling, revocation, scope checks, redirect URI checks, or client authentication.\n\n## Changelog and docs\n\n- For user-visible fixes or features, add an entry under `## main` in `CHANGELOG.md`.\n- Match the existing changelog style when a PR number is known: `- [#1234] Brief description`\n- Update user-facing docs when changing public configuration, supported behavior, generators, or visible views. Start with `README.md`, `UPGRADE.md`, and inline YARD/RDoc comments where relevant.\n\n## Practical reminders\n\n- Prefer existing rake tasks and repository tooling over custom scripts.\n- Do not assume examples in older docs are current; verify against files present in this repository.\n- If you touch views or translations, check for user override implications and mention them when they affect upgrades.\n","category":"root","tokens":960}]}