Claude Todo Bundle Laravel Package

Getting Started

The 0.0.1 tag is the package's initial release and its changelog is a GitHub auto-generated stub containing nothing but a compare link — there is no README excerpt, feature list, migration guide, or documented API surface in the release notes. Treat this as an unvetted spike dependency, not a foundation.

1. Confirm what you're actually installing. composer show -a tourze/claude-todo-bundle and read the package's composer.json before writing code. The -bundle suffix is the Symfony naming convention, so check type (library vs symfony-bundle), whether extra.laravel.providers or extra.symfony.bundle-class is present, and whether symfony/* appears in require. If it is a Symfony bundle, it will not auto-register in Laravel and there is no php artisan surface to expect.
2. Pin the exact version. Use "tourze/claude-todo-bundle": "0.0.1", not ^0.0.1. Caret constraints on a 0.0.x line resolve to >=0.0.1 <0.0.2, so you get the pin by accident — but being explicit documents intent and prevents a teammate from "helpfully" loosening it to ^0.1.
3. Where to look first, in order: composer.json (PHP constraint, autoload map, requires), src/ for a *ServiceProvider or *Bundle class, any config/ or Resources/config/ directory, and tests/ — at 0.0.1 the tests are the only reliable spec for behavior.
4. First use case. Install into a throwaway Laravel app, run php artisan list (if console commands ship, they will appear here) and php artisan about, then exercise the package's single obvious entry point. Only after that decide whether it belongs in a real application.

Implementation Patterns

Because the public API is undocumented at 0.0.1, the working pattern is containment: let the package touch exactly one place in your codebase.

• Adapter/wrapper class. Expose your own thin interface (TodoGateway, ClaudeTaskRunner) and implement it with the package's classes inside. When 0.1.0 renames or removes things — likely — you edit one file instead of grepping the app.
• Service provider discipline. If Laravel auto-discovery works, use it; otherwise register explicitly in config/app.php or bootstrap/providers.php. Either way, add a conditional binding so a fresh clone without the package installed still boots:

  $this->app->bind(TodoGateway::class, fn () =>
      class_exists(\Tourze\ClaudeTodo\TodoClient::class)
          ? new PackageTodoGateway()
          : new NullTodoGateway()
  );
  

• Console/scheduling integration. If the package ships artisan commands (a TODO-tracking bundle plausibly does), prefer invoking your own command that wraps the package's service over calling vendor commands directly from cron or routes/console.php — vendor command signatures are the least stable surface in any 0.0.x package.
• Configuration. Publish whatever config the provider offers (php artisan vendor:publish --provider=...) and commit the published file so environment drift is reviewable. If no config is publishable, keep settings in your own config/claude-todo.php and inject them.
• Test strategy. Wrap the calls you depend on with a fake in your test suite early. Do not mock vendor internals; mock your adapter. This also gives you a regression harness you can point at 0.0.2 to see what broke.

Gotchas and Tips

• No changelog means no compatibility contract. The 0.0.1 release notes contain only a Full Changelog link to a single commit range. There is no UPGRADING.md, no deprecation notices, and no stated semver policy. Diff tags yourself (https://github.com/tourze/claude-todo-bundle/compare/0.0.1...0.0.2) before every bump; do not trust the release page.
• Symfony bleed-through. tourze/* packages are frequently Symfony-first. If composer.json requires symfony/console, symfony/config, or symfony/dependency-injection, you are adding a framework subtree to a Laravel app for one feature. Weigh that against writing the 40 lines yourself.
• Autodiscovery silently failing. If nothing registers, check extra.laravel.providers exists and that composer dump-autoload has run. php artisan about and php artisan tinker → app()->getLoadedProviders() confirm whether the provider is live. On Laravel 11+, providers listed in bootstrap/providers.php are the expected path.
• Version constraint trap. ^0.0.1 behaves like 0.0.1. If you later write ^0.0, Composer allows >=0.0.0 <0.1.0 and can pull a feature release with breaking changes into production. Stay exact until there is a documented 1.0 API.
• Extension points are unknown — don't guess. At 0.0.1 there is no evidence of events, contracts, or a driver system. Prefer composition (your wrapper) over subclassing vendor classes; inheritance locks you to internals that will move.
• Debugging recipe. composer why tourze/claude-todo-bundle (is it already a transitive dep?), composer show -a for available versions and dependents, php artisan vendor:publish --provider="..." to surface hidden config, and dd(app()->make(...)) on the container binding to inspect the resolved object graph.
• Maintenance signal. A single 0.0.1 tag with an empty changelog and no README summary in the release is a low-maturity signal. Budget for the possibility of abandonment: keep the wrapper interface, and be prepared to reimplement behind it.
• Vendor directory is your documentation. With no published docs, read src/ directly and note method signatures in your adapter's docblocks — that note is what you'll diff against when the next release lands.