Weave Code
Core Laravel Package
robot-council/core
Core foundation for Robot Council, providing shared contracts, container bindings, and orchestration primitives for building multi-agent robot workflows in Laravel and PHP. Lightweight, extensible, and designed to integrate with the wider Robot Council ecosystem.
The core of Robot Council, a coordination service for fleets of AI coding agents: a Laravel package giving a host application GitHub sign-in, agent enrollment, presence, tasks, locks, and an ordered change feed
Frequently asked questions about Core
- What is robot-council/core used for?
- robot-council/core is the core of Robot Council, a coordination service for fleets of AI coding agents. It gives a Laravel host application GitHub sign-in, agent enrollment, presence tracking, tasks, locks, and an ordered change feed. It also ships shared contracts, container bindings, and orchestration primitives so you are not inventing the coordination layer yourself when building multi-agent robot workflows.
- How do I install robot-council/core in a Laravel application?
- Install it with Composer by requiring robot-council/core in your Laravel project. It follows standard Laravel package conventions, so the service provider should be auto-discovered without host-application surgery. Check the repository README for any publishable config or setup steps before wiring it into a real environment.
- Which Laravel and PHP versions does robot-council/core support?
- The authoritative answer is the Laravel and PHP constraints declared in the package's composer.json, since it is consumed as a normal Composer dependency. Because the package is pre-1.0, treat those constraints as moving targets and pin a version you have actually tested. Confirm current support in the repository before upgrading a production application.
- Where are parked state and assignment hours configured for the task_claim guard?
- Parked seat state and developer assignment hours are data the claim guard depends on, and the release notes do not state whether they are configuration, per-seat records, or derived values. Confirm the source of truth and who owns the accuracy of that data before scheduling integration work. Data quality is part of the rollout: a parked seat or a missing hours record changes whether task_claim returns 422.
- How do I test agent workflows built on robot-council/core?
- Exercise the claim path with Laravel's HTTP testing helpers, seeding seats, enrollment, presence, and assignment-hours records so you can assert both the success path and the parked or out-of-hours 422. Mock the GitHub sign-in flow rather than calling the real provider. Add regression coverage for every task_claim call site, including any queued or artisan paths.
- Is robot-council/core safe for production while it is pre-1.0?
- It is pre-1.0 software, so expect behavioural changes across minor and even patch releases. Pin an exact version, read release notes before updating, and stage upgrades; v0.8.3 is a good example of a change that alters caller behaviour without any schema migration. If you need stability guarantees, wait for a 1.0 tag or vendor a reviewed commit.
- What are the alternatives to robot-council/core for coordinating multiple AI agents in Laravel?
- If you only need background processing and mutual exclusion, Laravel's queue, cache locks, and scheduler may be enough. Robot Council adds coordination semantics those primitives do not cover: agent enrollment, presence, task claiming with rule-based refusal, and an ordered change feed. Rolling your own is viable, but you will be reimplementing those contracts plus the observability around them.
- Why did the task_claim rule change ship in a v0.8.3 patch release, and how do I upgrade safely?
- The release is framed as parity with existing placement behaviour, so claim and placement no longer diverge, but it is still a functional contract change landing in a patch version. Pin the current version, inventory all task_claim call sites, confirm parking and assignment-hours data quality in each environment, then upgrade behind a staged rollout. Most of the work is client-side: branch on the new 422 and distinguish it from a malformed request.
- What does the 422 response from task_claim mean?
- task_claim now rejects requests from a parked seat or from a seat outside its developer's assignment hours, returning 422 with the violated rule named. That naming is deliberate: it lets API consumers and on-call engineers tell a rule refusal apart from a malformed request. Check whether the rule identifier is a documented machine-readable code or only prose before you build logic on it.
- Does the new claim guard cover queued jobs and internal service calls, or only HTTP requests?
- Only the task_claim enforcement point is confirmed, so audit whether bulk claims, queued jobs, artisan commands, or internal service calls reach the domain without passing through it. Anything bypassing that path stays unguarded and can produce inconsistent state. Also verify your exception handler passes the package's 422 body through rather than flattening it into a generic error.
Weaver
How can I help you explore Laravel packages today?