webkernel/lifecycle
Development Workflow
On this page
This section is for changes to Lifecycle itself. For application or module tasks, start with the Guides.
Work from the package boundary
| Change | Relevant source |
|---|---|
| Declaration grammar | src/Declaration/ and support/schemas/extra-webkernel.v1.json. |
| Callback forms or order | src/Event/. |
| Check evaluation | src/Check/ and built-in worker declarations. |
| Action contract or execution | src/Action/, src/Contracts/, StandardLCAction. |
| Helper initialization or paths | src/Path/, load.lifecycle.functions.php. |
| Package destinations | src/Install/. |
| Output behavior | StandardComposerIO. |
| Activation and Composer event adapters | src/Plugin/. |
Read the current neighboring files before editing. Keep changes focused, use the repository's PHP naming/header conventions and keep runtime code independent of a source checkout's absolute location.
Consume through Composer
The repository application is webkernel/; its path repositories point at framework sources with symlinks. Run Composer from that consuming project when refreshing installed metadata and autoload maps:
cd webkernel
composer dump-autoload
For changed dependency/autoload package metadata, update the relevant path package as needed before dumping:
composer update webkernel/lifecycle
Do not hand-edit the generated autoloader or installed-package files. A live lifecycle declaration in a symlinked manifest can be reread on the next command; dependency and PSR-4 metadata still follow Composer's package-update workflow.
Verify the changed behavior
| Change | Useful check |
|---|---|
| Documentation | Resolve relative links and check JSON/PHP sample syntax. |
| Manifest | composer validate in the consuming project. |
| Listener/action | Run the event that reaches it; verify failure as well as successful output. |
| Installer | Exercise the affected package type through Composer and inspect the actual install path. |
| Helper | Load the consuming project's autoloader; inspect root, custom vendor and package path behavior. |
| Performance | Record PHP, OPcache, cache state and measurement scope. |
Manifest validation alone does not prove a callback autoloads. Avoid running generation actions against persistent application data merely to inspect output. Use a disposable fixture project for installation or destructive-failure scenarios.
Keep contracts and documentation together
When a declaration contract changes, update both the PHP validator and editor schema, then the guide and reference. When an install destination changes, update its table from the actual templates. Keep the built-in worker inventory aligned with the manifest's callback order.
The package's benchmark script accepts the Composer autoloader path as its first argument; read Performance before using it in a custom layout. Document measured conditions and avoid turning a local sample into a general speed guarantee.
Documentation conventions
Section directories use 01-name/; pages use 01-name.en.md for English, with the language code in the same position for other languages. Keep the package README as the reading-path index. Add relative links and a useful next step when a page belongs to a sequence.
Return to Troubleshooting for symptoms in a consuming application.
