{"owner":"codeigniter4","repo":"CodeIgniter4","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# CodeIgniter 4 — Repository Guidelines\n\nCodeIgniter 4 is a mature open-source PHP framework. Framework production\ncode lives in `system/`; its tests mirror that structure under\n`tests/system/`.\n\n## Before making changes\n\nConsult the relevant sections of:\n\n- `contributing/pull_request.md`\n- `contributing/internals.md`\n- `contributing/styleguide.md`\n- `tests/README.md`\n\nFollow existing code and tests in the affected component. Search for an\nexisting implementation before introducing a new abstraction or convention.\n\n## Target branch and compatibility policy\n\nCompatibility is judged against the pull request's base branch, not the\ncontributor's source or feature branch. When the base branch is unknown,\napply the stricter `develop` policy.\n\n### Base branch `develop`\n\n`develop` is the next patch-release line. Intentional backward-incompatible\nchanges are not allowed.\n\n- Preserve public and protected APIs, documented behavior, configuration\n  defaults, generated project files, exceptions, and observable side effects.\n- Do not remove deprecated items or change public/protected signatures,\n  visibility, or interface/abstract requirements.\n- A bug or security fix may correct faulty behavior but must preserve the\n  documented contract and ordinary valid usage.\n- If a fix necessarily breaks compatibility, target the appropriate minor\n  branch instead.\n\n### Base branch `4.*`\n\nMinor-release lines (for example `4.9`). Small, deliberate compatibility\nbreaks may be accepted when they materially improve the framework or\ncomplete the documented deprecation lifecycle.\n\n- Keep each break narrow, explicit, and justified; never an incidental\n  side effect of refactoring.\n- Deprecated APIs may be removed no earlier than the second subsequent\n  minor release (deprecated in 4.6.x means removable in 4.8.0), with a\n  supported replacement.\n- Every accepted break needs tests for the new behavior, a minor-version\n  changelog entry, and migration instructions in the upgrading guide.\n\n### All base branches\n\n- Production code must run on PHP 8.2. Do not require a newer PHP version,\n  even when a newer version is installed locally.\n- Signatures, properties, constants, default values, exceptions, side\n  effects, configuration, and generated project files are all\n  compatibility-sensitive.\n- Major-scale redesigns and ecosystem-wide migration requirements belong in\n  a major release, not a patch or minor release.\n- Prefer the minimum useful abstraction and keep framework components as\n  independent as practical.\n- Dependencies should be injectable. When a framework service is used as a\n  default, preserve the ability for applications to replace it.\n- Do not add or update a Composer dependency unless the task explicitly\n  requires it and the change is justified.\n- Do not modify code in `system/ThirdParty/`.\n\n## Coding standards\n\n- Do not add `declare(strict_types=1)` mechanically. Follow nearby code and\n  check the `DeclareStrictTypesRector` exclusions in `rector.php`; PHP files\n  use strict types unless excluded there. Treat the existing exclusions as\n  intentional compatibility constraints. Do not remove an exclusion without\n  dedicated justification and tests.\n- Every new class property must have a native type declaration. Use the\n  most precise type supported by PHP 8.2; use `mixed` only when the\n  property intentionally accepts unrelated types.\n- Do not add or change a type on an existing public or protected property\n  mechanically. Property types affect inheritance and must follow the\n  target-branch compatibility policy.\n- Add PHPDoc only when it contributes information that native types cannot\n  express. Do not duplicate a parent or interface docblock.\n- Never suppress a static-analysis error or update a baseline to make a\n  check pass.\n\n## FrankenPHP Worker Mode\n\nIn Worker Mode one process serves many requests. The entry point's source\ntemplate is `system/Commands/Worker/Views/frankenphp-worker.php.tpl`; the\n`worker:install` command publishes it as `public/frankenphp-worker.php`.\n\n- For every change affecting application bootstrap, request handling,\n  response sending, shutdown, superglobals, sessions, database or cache\n  connections, services, factories, events, toolbar state, static state, or\n  other request-lifecycle behavior, inspect the worker entry-point template\n  even when it is not part of the diff.\n- Compare traditional per-process execution with worker execution, where\n  the framework boots once and handles multiple requests in the same\n  process.\n- Classify mutable state as process-lifetime, intentionally persistent, or\n  request-specific. Request-specific state must be refreshed or reset for\n  every request and must not leak into the next request.\n- Preserve the ordering requirements between per-request reconnection,\n  framework reset, superglobal refresh, application execution, and\n  post-request cleanup.\n- Treat the template as the source of truth. Do not edit a generated\n  `public/frankenphp-worker.php` in place.\n- When a release changes the template in a way existing installations must\n  receive, add an upgrading instruction telling Worker Mode users to\n  republish it with `php spark worker:install --force`.\n\n## Tests\n\n- Every bug fix should include a regression test that fails without the\n  fix.\n- Test failure paths, exceptions, boundary conditions, and state cleanup,\n  not only the happy path.\n- Prefer strict and dedicated PHPUnit assertions as described in the\n  project style guide.\n- Do not weaken or remove an existing test unless the documented behavior\n  or specification changed.\n\n## Documentation\n\n- Public API, behavior, message, or default-value changes may require an\n  update to the user guide and changelog.\n- Changes requiring user action, including configuration changes, may also\n  require an upgrading-guide entry.\n- For a `4.*` target, every intentional compatibility break must be\n  documented in both the minor-version changelog and its upgrading guide.\n\n## Focused validation\n\nGitHub Actions is the authoritative source for full validation. Do not\nreproduce the complete CI matrix locally.\n\n- Run only the narrowest PHPUnit test file or component that covers a code\n  change, for example\n  `vendor/bin/phpunit tests/system/<Component>/<Class>Test.php`.\n- Run a file-scoped analysis or formatting check only when it is quick and\n  directly relevant.\n- Do not run the complete PHPUnit suite, `composer phpstan:check`,\n  `composer cs`, Psalm, Structarmed, or a repository-wide Rector analysis\n  by default.\n- Report which focused checks were executed and which validation was left\n  to CI.\n"},"files":{"AGENTS.md":"# CodeIgniter 4 — Repository Guidelines\n\nCodeIgniter 4 is a mature open-source PHP framework. Framework production\ncode lives in `system/`; its tests mirror that structure under\n`tests/system/`.\n\n## Before making changes\n\nConsult the relevant sections of:\n\n- `contributing/pull_request.md`\n- `contributing/internals.md`\n- `contributing/styleguide.md`\n- `tests/README.md`\n\nFollow existing code and tests in the affected component. Search for an\nexisting implementation before introducing a new abstraction or convention.\n\n## Target branch and compatibility policy\n\nCompatibility is judged against the pull request's base branch, not the\ncontributor's source or feature branch. When the base branch is unknown,\napply the stricter `develop` policy.\n\n### Base branch `develop`\n\n`develop` is the next patch-release line. Intentional backward-incompatible\nchanges are not allowed.\n\n- Preserve public and protected APIs, documented behavior, configuration\n  defaults, generated project files, exceptions, and observable side effects.\n- Do not remove deprecated items or change public/protected signatures,\n  visibility, or interface/abstract requirements.\n- A bug or security fix may correct faulty behavior but must preserve the\n  documented contract and ordinary valid usage.\n- If a fix necessarily breaks compatibility, target the appropriate minor\n  branch instead.\n\n### Base branch `4.*`\n\nMinor-release lines (for example `4.9`). Small, deliberate compatibility\nbreaks may be accepted when they materially improve the framework or\ncomplete the documented deprecation lifecycle.\n\n- Keep each break narrow, explicit, and justified; never an incidental\n  side effect of refactoring.\n- Deprecated APIs may be removed no earlier than the second subsequent\n  minor release (deprecated in 4.6.x means removable in 4.8.0), with a\n  supported replacement.\n- Every accepted break needs tests for the new behavior, a minor-version\n  changelog entry, and migration instructions in the upgrading guide.\n\n### All base branches\n\n- Production code must run on PHP 8.2. Do not require a newer PHP version,\n  even when a newer version is installed locally.\n- Signatures, properties, constants, default values, exceptions, side\n  effects, configuration, and generated project files are all\n  compatibility-sensitive.\n- Major-scale redesigns and ecosystem-wide migration requirements belong in\n  a major release, not a patch or minor release.\n- Prefer the minimum useful abstraction and keep framework components as\n  independent as practical.\n- Dependencies should be injectable. When a framework service is used as a\n  default, preserve the ability for applications to replace it.\n- Do not add or update a Composer dependency unless the task explicitly\n  requires it and the change is justified.\n- Do not modify code in `system/ThirdParty/`.\n\n## Coding standards\n\n- Do not add `declare(strict_types=1)` mechanically. Follow nearby code and\n  check the `DeclareStrictTypesRector` exclusions in `rector.php`; PHP files\n  use strict types unless excluded there. Treat the existing exclusions as\n  intentional compatibility constraints. Do not remove an exclusion without\n  dedicated justification and tests.\n- Every new class property must have a native type declaration. Use the\n  most precise type supported by PHP 8.2; use `mixed` only when the\n  property intentionally accepts unrelated types.\n- Do not add or change a type on an existing public or protected property\n  mechanically. Property types affect inheritance and must follow the\n  target-branch compatibility policy.\n- Add PHPDoc only when it contributes information that native types cannot\n  express. Do not duplicate a parent or interface docblock.\n- Never suppress a static-analysis error or update a baseline to make a\n  check pass.\n\n## FrankenPHP Worker Mode\n\nIn Worker Mode one process serves many requests. The entry point's source\ntemplate is `system/Commands/Worker/Views/frankenphp-worker.php.tpl`; the\n`worker:install` command publishes it as `public/frankenphp-worker.php`.\n\n- For every change affecting application bootstrap, request handling,\n  response sending, shutdown, superglobals, sessions, database or cache\n  connections, services, factories, events, toolbar state, static state, or\n  other request-lifecycle behavior, inspect the worker entry-point template\n  even when it is not part of the diff.\n- Compare traditional per-process execution with worker execution, where\n  the framework boots once and handles multiple requests in the same\n  process.\n- Classify mutable state as process-lifetime, intentionally persistent, or\n  request-specific. Request-specific state must be refreshed or reset for\n  every request and must not leak into the next request.\n- Preserve the ordering requirements between per-request reconnection,\n  framework reset, superglobal refresh, application execution, and\n  post-request cleanup.\n- Treat the template as the source of truth. Do not edit a generated\n  `public/frankenphp-worker.php` in place.\n- When a release changes the template in a way existing installations must\n  receive, add an upgrading instruction telling Worker Mode users to\n  republish it with `php spark worker:install --force`.\n\n## Tests\n\n- Every bug fix should include a regression test that fails without the\n  fix.\n- Test failure paths, exceptions, boundary conditions, and state cleanup,\n  not only the happy path.\n- Prefer strict and dedicated PHPUnit assertions as described in the\n  project style guide.\n- Do not weaken or remove an existing test unless the documented behavior\n  or specification changed.\n\n## Documentation\n\n- Public API, behavior, message, or default-value changes may require an\n  update to the user guide and changelog.\n- Changes requiring user action, including configuration changes, may also\n  require an upgrading-guide entry.\n- For a `4.*` target, every intentional compatibility break must be\n  documented in both the minor-version changelog and its upgrading guide.\n\n## Focused validation\n\nGitHub Actions is the authoritative source for full validation. Do not\nreproduce the complete CI matrix locally.\n\n- Run only the narrowest PHPUnit test file or component that covers a code\n  change, for example\n  `vendor/bin/phpunit tests/system/<Component>/<Class>Test.php`.\n- Run a file-scoped analysis or formatting check only when it is quick and\n  directly relevant.\n- Do not run the complete PHPUnit suite, `composer phpstan:check`,\n  `composer cs`, Psalm, Structarmed, or a repository-wide Rector analysis\n  by default.\n- Report which focused checks were executed and which validation was left\n  to CI.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# CodeIgniter 4 — Repository Guidelines\n\nCodeIgniter 4 is a mature open-source PHP framework. Framework production\ncode lives in `system/`; its tests mirror that structure under\n`tests/system/`.\n\n## Before making changes\n\nConsult the relevant sections of:\n\n- `contributing/pull_request.md`\n- `contributing/internals.md`\n- `contributing/styleguide.md`\n- `tests/README.md`\n\nFollow existing code and tests in the affected component. Search for an\nexisting implementation before introducing a new abstraction or convention.\n\n## Target branch and compatibility policy\n\nCompatibility is judged against the pull request's base branch, not the\ncontributor's source or feature branch. When the base branch is unknown,\napply the stricter `develop` policy.\n\n### Base branch `develop`\n\n`develop` is the next patch-release line. Intentional backward-incompatible\nchanges are not allowed.\n\n- Preserve public and protected APIs, documented behavior, configuration\n  defaults, generated project files, exceptions, and observable side effects.\n- Do not remove deprecated items or change public/protected signatures,\n  visibility, or interface/abstract requirements.\n- A bug or security fix may correct faulty behavior but must preserve the\n  documented contract and ordinary valid usage.\n- If a fix necessarily breaks compatibility, target the appropriate minor\n  branch instead.\n\n### Base branch `4.*`\n\nMinor-release lines (for example `4.9`). Small, deliberate compatibility\nbreaks may be accepted when they materially improve the framework or\ncomplete the documented deprecation lifecycle.\n\n- Keep each break narrow, explicit, and justified; never an incidental\n  side effect of refactoring.\n- Deprecated APIs may be removed no earlier than the second subsequent\n  minor release (deprecated in 4.6.x means removable in 4.8.0), with a\n  supported replacement.\n- Every accepted break needs tests for the new behavior, a minor-version\n  changelog entry, and migration instructions in the upgrading guide.\n\n### All base branches\n\n- Production code must run on PHP 8.2. Do not require a newer PHP version,\n  even when a newer version is installed locally.\n- Signatures, properties, constants, default values, exceptions, side\n  effects, configuration, and generated project files are all\n  compatibility-sensitive.\n- Major-scale redesigns and ecosystem-wide migration requirements belong in\n  a major release, not a patch or minor release.\n- Prefer the minimum useful abstraction and keep framework components as\n  independent as practical.\n- Dependencies should be injectable. When a framework service is used as a\n  default, preserve the ability for applications to replace it.\n- Do not add or update a Composer dependency unless the task explicitly\n  requires it and the change is justified.\n- Do not modify code in `system/ThirdParty/`.\n\n## Coding standards\n\n- Do not add `declare(strict_types=1)` mechanically. Follow nearby code and\n  check the `DeclareStrictTypesRector` exclusions in `rector.php`; PHP files\n  use strict types unless excluded there. Treat the existing exclusions as\n  intentional compatibility constraints. Do not remove an exclusion without\n  dedicated justification and tests.\n- Every new class property must have a native type declaration. Use the\n  most precise type supported by PHP 8.2; use `mixed` only when the\n  property intentionally accepts unrelated types.\n- Do not add or change a type on an existing public or protected property\n  mechanically. Property types affect inheritance and must follow the\n  target-branch compatibility policy.\n- Add PHPDoc only when it contributes information that native types cannot\n  express. Do not duplicate a parent or interface docblock.\n- Never suppress a static-analysis error or update a baseline to make a\n  check pass.\n\n## FrankenPHP Worker Mode\n\nIn Worker Mode one process serves many requests. The entry point's source\ntemplate is `system/Commands/Worker/Views/frankenphp-worker.php.tpl`; the\n`worker:install` command publishes it as `public/frankenphp-worker.php`.\n\n- For every change affecting application bootstrap, request handling,\n  response sending, shutdown, superglobals, sessions, database or cache\n  connections, services, factories, events, toolbar state, static state, or\n  other request-lifecycle behavior, inspect the worker entry-point template\n  even when it is not part of the diff.\n- Compare traditional per-process execution with worker execution, where\n  the framework boots once and handles multiple requests in the same\n  process.\n- Classify mutable state as process-lifetime, intentionally persistent, or\n  request-specific. Request-specific state must be refreshed or reset for\n  every request and must not leak into the next request.\n- Preserve the ordering requirements between per-request reconnection,\n  framework reset, superglobal refresh, application execution, and\n  post-request cleanup.\n- Treat the template as the source of truth. Do not edit a generated\n  `public/frankenphp-worker.php` in place.\n- When a release changes the template in a way existing installations must\n  receive, add an upgrading instruction telling Worker Mode users to\n  republish it with `php spark worker:install --force`.\n\n## Tests\n\n- Every bug fix should include a regression test that fails without the\n  fix.\n- Test failure paths, exceptions, boundary conditions, and state cleanup,\n  not only the happy path.\n- Prefer strict and dedicated PHPUnit assertions as described in the\n  project style guide.\n- Do not weaken or remove an existing test unless the documented behavior\n  or specification changed.\n\n## Documentation\n\n- Public API, behavior, message, or default-value changes may require an\n  update to the user guide and changelog.\n- Changes requiring user action, including configuration changes, may also\n  require an upgrading-guide entry.\n- For a `4.*` target, every intentional compatibility break must be\n  documented in both the minor-version changelog and its upgrading guide.\n\n## Focused validation\n\nGitHub Actions is the authoritative source for full validation. Do not\nreproduce the complete CI matrix locally.\n\n- Run only the narrowest PHPUnit test file or component that covers a code\n  change, for example\n  `vendor/bin/phpunit tests/system/<Component>/<Class>Test.php`.\n- Run a file-scoped analysis or formatting check only when it is quick and\n  directly relevant.\n- Do not run the complete PHPUnit suite, `composer phpstan:check`,\n  `composer cs`, Psalm, Structarmed, or a repository-wide Rector analysis\n  by default.\n- Report which focused checks were executed and which validation was left\n  to CI.\n","category":"root","tokens":1651}]}