Verifying an Install

There is no CI in this repository - Dotboost is configuration, not code with a build step - so this manual smoke test is the closest thing to a test suite. Run it after installing into a project.

Skill routing

Ask "where does a new Doctrine entity go?" — it should reach for dotkernel-module-structure rather than answering from general framework knowledge.

The CLAUDE.md block

With the dependency-policy block in place (see Getting Started), ask "how do I send mail from here?" — a question with no package name in it. It should load dependency-policy and walk the ladder, grepping composer.lock first and then the dotkernel/* manifest (generating it if absent), rather than replying with a package name from memory. See Dependency Policy.

Guardrails

• Ask it to edit vendor/autoload.php — blocked by guard-protected-paths.sh.
• Ask it to add a package to composer.json — blocked by the same hook; it should propose the change in chat instead of writing it.
• Ask it to run cd src && composer require foo — guard-bash.sh should catch the install even though it's inside a compound command, which path-based permission rules alone cannot see. See Guardrails vs. Permissions.

Verify against current docs

Claude Code's own settings.json schema and hook event names move faster than most things in this repo. If a permission rule or hook doesn't take effect, check the current Claude Code docs — in particular the glob syntax accepted by permissions.deny and whether permissions.ask exists in your installed version. Treat the hooks as the reliable layer and the permission rules as the convenient one when the two seem to disagree.