Download the PHP package voku/agent-loop without Composer

On this page you can find all versions of the php package voku/agent-loop. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package agent-loop

Agent Loop

A governed coding-agent workflow for PHP repositories.

voku/agent-loop is the umbrella package for a local, auditable agentic-coding loop. It combines target-aware edit orchestration, task selection, working sessions, recall compilation, gated workflow orchestration, verification, deterministic review, learning capture, memory promotion, and repo setup/diagnostics behind one CLI:

Quick start

Install the package in an existing PHP project:

For an exact method-scoped change, build the semantic map, compile bounded source-backed recall, and prepare one execution bundle directly:

When the project's PHPStan semantic export needs more than its PHP default, pass an explicit bounded value such as --phpstan-memory-limit=512M to edit; the value is forwarded only to the map-building child process and recorded in the execution request.

For a surgical replacement, add repeatable --focus literals. edit records them and asks the local map/recall stack for short source windows around each match, so the external runner receives the evidence it needs without first spending tool calls rediscovering a large target method. Focus mode omits optional caller/dependency/test slices; use it only when the requested change is local to the matched expression. If a literal is not found, the complete target method is retained rather than silently omitting context.

The default stdout runner does not execute another agent. It writes request.json, prompt.md, execution.json, agent-result.json, the recall artifacts, and any runner evidence under .agent-loop/edit/<task-id>/.

agent-result.json is the answer sheet a verifier grades. The orchestrator fills in what it observed itself - the verification_plan_sha256 the edit is bound to, the changed_files diffed from a working-tree snapshot taken before the runner ran, and the commands it actually invoked with their exit codes - and seeds one empty slot per probe and checklist item from verification-plan.json, so an unanswered probe is visibly unanswered rather than missing. The agent fills those slots; it does not write the rest.

Verify it with:

That loads the plan, the verifier-owned key, the answer sheet and execution.json, refuses to grade artifacts whose bindings do not line up (exit 2), grades the probe answers against the key, resolves the checklist evidence, runs the declared objective gates, and writes verification-result.json. Gates that shell out report not_run unless --run-commands is passed, and a required gate that did not run fails the verification rather than passing it. The post-edit map is refreshed into a bundle-local copy, never the shared index. Exit codes: 0 verified, 1 failed, 2 unreadable bundle. This is not agent-loop verify, which checks cross-package consistency and drift.

It deliberately carries no expected answers, scores, verdicts or generated learnings. Those belong to the verifier: a result file that can grade itself is not evidence. changed_files_source distinguishes a genuinely empty diff (git_status_diff) from a repository the snapshot could not read (unavailable). Use --runner=command with an explicit executable and repeated --runner-arg values for a harness that consumes the compiled prompt on stdin. No shell command is constructed.

For an exact one-for-one literal replacement inside a resolved PHP method, prefer --runner=auto with both replacement literals. It selects the scoped mechanical runner, which requires exactly one match inside that method, verifies the map hash immediately before writing, runs php -l, reverts on lint failure, and records 0 model input tokens and tool calls in execution.json. Identical literals in another method are left unchanged, unlike a file-wide sed replacement. auto without replacement proof writes an escalation_required bundle and never launches a model; choose --runner=command explicitly only when PHP judgment is required.

Create the minimal local workflow structure and a clearly marked example task:

Inspect the generated card:

Plan and approve it. This example uses composer.json, which is already in a Composer project; replace it with the real file you intend to change.

Generate the bounded context for your coding agent:

After making the change, record its validation and continue through review and closure. See Your first governed task.

The goal is not to make a coding agent "remember everything".

The goal is to make it work in a controlled loop where useful context is selected, work is verified, findings are reviewed, and only approved knowledge becomes durable guidance.

Why this exists

Coding agents are useful, but they are also very good at three bad habits:

  1. forgetting project-specific rules,
  2. repeating old mistakes,
  3. stuffing too much irrelevant context into the prompt.

agent-loop gives them a process.

Instead of asking an agent to "just fix this", you run a loop:

That last part matters.

Not every observation should become memory. Some findings are temporary, accidental, stale, or just wrong. A useful agent workflow needs both learning and forgetting.

Review accumulated guidance

Run the deterministic maintenance cycle through the unified CLI; it delegates knowledge evaluation to voku/agent-learning and keeps operator output under the ignored .agent-loop/ work area instead of project documentation:

The command validates immutable learning evidence, reports coverage gaps and a small review queue, and exits successfully when candidates need human review. Use --write-candidates only to create reviewable proposal records; it never approves, applies, retires, or rewrites durable guidance.

What agent-loop is

agent-loop is:

What agent-loop is not

agent-loop is not:

If everything becomes memory, memory becomes landfill.

Package architecture

agent-loop delegates to specialized packages instead of rebuilding everything in one large tool.

Each dependency package has one job:

Package Responsibility
voku/agent-kanban Markdown task board, verification, and optional external-issue-tracker sync
voku/agent-session Per-task working memory and session plans
voku/agent-map Compact PHP symbol maps for bounded source navigation
voku/agent-recall-compiler Task-specific recall/L2 meta-prompt compilation, plus blind-spot and code-review prompts
voku/agent-learning Findings, proposals, decision history, guidance evaluation, and deterministic dream maintenance reports
voku/agent-loop Unified CLI, gated workflow orchestration, cross-package verification, memory promotion review, and setup diagnostics
Namespace Status Purpose Owning package
edit Stable Resolve an exact method target, compile bounded recall, and prepare or run an auditable execution bundle voku/agent-loop
board Stable Pick work from local Markdown cards; external sync is optional and host-provided voku/agent-kanban
session Stable Working memory for an in-progress task voku/agent-session
map Stable Build and query a compact PHP symbol map before reading broad files voku/agent-map
recall Stable Compile task-scoped context as review artifacts voku/agent-recall-compiler
learn Stable Findings, proposals, and reviewed decision history voku/agent-learning
verify Stable Cross-package consistency check voku/agent-loop
workflow Stable Plan, approve, start, inspect, report, and close governed work voku/agent-loop
board:verify Stable Narrow check of the kanban board source only voku/agent-kanban
memory Stable MEMORY.md promotion review voku/agent-loop
review Stable Deterministic blind-spot reports and L2 review prompts voku/agent-recall-compiler
init Stable Setup diagnostics, repo-managed assets, and minimal workflow scaffolding voku/agent-loop

The table is the current executable surface. init scaffold creates only the local workflow directories, a small .agent-loop/init.json, and a DEMO-1 board card/task; it never writes over an existing file.

The loop

A typical workflow looks like this. The gated workflow commands are the preferred entry and exit points; the lower-level package commands they wrap stay available directly when you need finer control.

Pick the work:

Plan and approve the governed task context. Planning starts session working memory and records a candidate work brief. Approval seals that exact revision and compiles recall from it:

For exact method-scoped work, agent-loop edit now connects the semantic map and target-aware recall compiler directly. Its safe default prepares the execution bundle without launching an external agent; the generic command runner can pass prompt.md through stdin to an explicitly configured harness.

The broader governed workflow remains the preferred lifecycle for approved board work, session state, review, verification, and closure. Direct recall compile still writes artifacts for manual or harness ingestion.

For behavioral work, the optional repeatable --behavior-anchor records the real request, runtime, consumer, data, or integration seam that needs evidence. It is intentionally optional for documentation-only or static-only tasks. The compiled L2 briefing also distinguishes VERIFIED, INFERRED, ASSUMED, BLOCKED, and CONTRADICTED claims; agent confidence and peer feedback do not become evidence without a current repository, history, or safe-runtime check.

Run the deterministic blind-spot review before closing:

Verify cross-package consistency, then close the task — workflow close requires an approved current work brief, recall metadata, a blind-spot review report, and a passing agent-loop verify before it will let a task go to done:

Capture what the session discovered:

Finally, review durable memory candidates:

Human-in-the-loop by design

agent-loop deliberately keeps humans in the loop.

A coding agent may collect findings, suggest rules, and propose new guidance. But it should not silently rewrite the project's long-term memory, and it should not close its own task as done without evidence.

Durable guidance should be reviewed because project rules have consequences:

That final step needs a human decision.

The agent can notice the pattern. workflow close can require the evidence exists. The project owner decides whether it becomes a rule.

Learning vs constraints

There are different kinds of knowledge:

Type Meaning
Finding Something observed during a session
Proposal A suggested rule, skill, or memory update
Learning note Useful context, but not necessarily a hard rule
Skill Repeatable procedural guidance
Constraint A hard project rule the agent must follow
Rejected guidance Something considered and intentionally not adopted

The most important output is often not "more memory".

It is a sharper constraint:

Hard constraints prevent repeated mistakes.

Soft notes merely hope the agent behaves. Hope is not a strategy, despite its popularity.

Forgetting is part of the system

A good agent workflow needs explicit rejection.

Some observations should not survive:

agent-loop treats this as part of governance.

Forgetting bad or irrelevant context is often more valuable than learning another vague rule.

CLI overview

Available namespaces:

Run agent-loop <namespace> help (or --help) for a namespace's own command list.

Board

Reads work items from local Markdown card files under todo/cards/*.md (one file per card), with todo/board.md holding board metadata (project prefix, done count). This works fully standalone — no tracker host, credentials, or network access required. todo/jira/ and a root TODO.md remains an optional rendered board projection when present.

Only board external-sync talks to an external issue tracker, and only when the invocation passes --provider-class=<FQCN> pointing at your own voku\AgentKanban\ExternalIssue\ExternalIssueProvider implementation (see "Programmatic usage" below) — nothing is wired in by default. Every other board command works from the local Markdown cards alone.

Edit

edit rejects missing, ambiguous, conflicted, or stale targets before it publishes an execution bundle. Missing or stale maps are rebuilt once unless --no-rebuild-map is supplied. The default runner is deliberately non-executing; --print-prompt prints the compiled prompt, while --runner=command --runner-command=... --runner-arg=... invokes one executable without a shell and stores stdout, stderr, and the exit code as evidence. Use --phpstan-memory-limit=512M (or a project-appropriate positive value) when rebuilding the semantic map needs more memory than the PHP default. Use repeatable --focus=TEXT for narrow, literal replacements; it keeps a small local source window around each match for the runner and falls back to the complete target method if no match is found. For a one-for-one literal replacement with no judgment call, prefer --runner=auto --replace-old=... --replace-new=...; it selects mechanical execution, performs no model invocation, and leaves auditable lint evidence. Without both literals, auto writes escalation_required rather than silently invoking a model; select --runner=command explicitly for that escalation.

RTK is an optional outer-shell output filter, not an edit runner. It can reduce the output an agent has to read without changing the deterministic edit route:

agent-loop init tools --refresh records whether rtk is reachable in PATH. When an agent runs PHP inside a container, invoke RTK outside the container (rtk docker compose exec …); do not assume a nested rtk test docker compose exec … preserves the container working directory. The package-owned historical replay test copies a public agent-loop parent blob to a temporary root, replays a one-line fix through auto, and compares the result with both the committed blob and a guarded Linux replacement baseline.

Map

Builds a compact generated symbol index under .agent-map/ by default. Use it to choose the smallest useful source read; it is optional and never becomes another durable memory store. Build once, then keep it current with map refresh, which re-analyses only changed or new files.

Session

Tracks per-task working memory and session plans. Use this for active work state, not durable project memory.

Recall

Compiles a scoped briefing for the current task. The recall compiler should select relevant approved guidance, not dump every note the project ever had.

Workflow

workflow plan starts or reuses a session and writes a candidate work brief; it deliberately does not compile recall from unapproved scope. workflow approve records the actor and revision, then compiles recall from that sealed brief. When a typed board card and/or map index exist, it passes their stable fact projections too. When <learning-root>/recall-documents.json exists, it also passes that explicit, Git-tracked Skill/ADR manifest; it never scans all project Markdown files. It automatically uses infra/doc/agent-learning (or the legacy learning-root) when one exists; pass --learning-root only for a different location. Its --file values become the initial approved scope unless one or more explicit --scope values are supplied. workflow approve records the actor and revision that approved that candidate. A later plan revision must be approved again.

--tag LABEL on workflow plan (repeatable) records optional relevance labels on the work brief, independent of --scope paths. Recall then selects a fact when its path scope overlaps the task's files or it shares a tag with the task, so cross-cutting learnings/documents (e.g. identity, ldap) can be found for a task whose files live under an unrelated directory, regardless of how a given project lays out its codebase.

workflow start remains available when a host deliberately needs the lower level session-plus-recall step without work-brief orchestration.

workflow status prints read-only session, recall, and review state.

workflow context is the bounded working view for an agent: it reads the approved brief, session decision/checkpoint titles, selected recall guidance, required validation, and navigation facts from the recall bundle (falling back to .agent-map/ only for legacy outputs). It never recompiles recall or a map, embeds no source body, and prints [SKIP] plus explicit omission counts when an input or budget is absent.

workflow report is the bounded handoff view: it reports the current work brief and approval, supplied changed files that fall outside approved scope, revision-bound validation evidence, recall outcome state, review state, task-associated learning counts, and any accepted risk. It is read-only and never runs git; pass each observed path with --changed-file (or use --format json for CI).

workflow close is a gated wrapper around session close. It requires an approved current work brief, passing validation evidence for its exact revision, recall metadata and explicit outcomes for selected guidance, a blind-spot review report, an explicit session learning decision, and a passing agent-loop verify before closing a task as done.

Record completion evidence through the session owner; it remains auditable but does not become durable guidance by itself:

Existing agent-loop session close remains unchanged.

Workflow commands do not approve code, do not approve durable learning, and do not call an LLM.

Accepted risk is explicit and written to disk:

Both are required: an override without a named owner is an anonymous decision, which is the thing the record exists to prevent. The record names who overrode it, why, and every gate that was failing at that moment - including which validation evidence was missing - in .agent-loop/risks/<task-id>.accepted-risk.md and a machine-readable .json beside it.

Verify

The one command that looks across board, session, recall, and learning state at once. Checks each print [OK], [SKIP], or [FAIL] and skip themselves when their inputs are absent, so the command stays meaningful for a repo that only wires up part of the stack. Pass --strict to fail instead of skip when the tasks/ or session_plan/ baseline is missing entirely. Pass --task-id=ID to scope the tasks/sessions/recall checks to one task, so an unrelated task's stale recall draft or broken task file doesn't fail the run — workflow close passes its own task id this way automatically. Package delegates, board, and the learning root stay repo-wide checks either way.

Review

Writes deterministic Markdown/JSON blind-spot reports plus an L2 review prompt under <recall-root>/<task-id>/reviews/, using task, session, and recall artifacts as prompt context. review code generates a focused L2 code-review prompt (purpose mismatch, contracts, invariants, edge cases, security, test gaps). Neither command approves code or calls an LLM itself — the generated prompt is for a human or harness to pass to a receiving LLM.

Learn

Captures and evaluates findings, proposals, and learning history.

Memory

Reports which MEMORY.md rows look ready for promotion; it never edits MEMORY.md itself. Promotion stays a manual edit by whoever owns that file.

Init

Diagnoses local setup, prints reviewed install plans (ripgrep, RTK, Caveman), validates repo-managed asset definitions, and syncs repo-managed skills/subagents/hooks into client target directories. It does not affect workflow close, does not call an LLM, and does not install remote tools.

init doctor/init status are read-only and never write files. init tools is the one exception: it probes whether rg, git, php, composer, and docker are reachable in PATH and whether an agent-map index exists, then caches the result to .agent-loop/tool-inventory.json (gitignore this path) so an agent does not have to re-probe availability at the start of every session. Re-probes automatically once the cache passes --max-age (default 3600s), or immediately with --refresh.

Installation

Requirement Version
PHP 8.3 or newer
Composer required

This installs voku/agent-kanban, voku/agent-session, voku/agent-map, voku/agent-recall-compiler, and voku/agent-learning as dependencies and exposes vendor/bin/agent-loop.

Programmatic usage

Start with the smallest useful loop — one task, one session, one compiled briefing. The high-level workflow command is preferred for creating and closing the governed task context:

The lower-level equivalent of workflow start is still available when you need direct package commands:

session start prints its own generated session id (date-prefixed, e.g. 2025-01-15-abc-123) on its first line. You don't need to capture it: session record/checkpoint/close/claim/show/brief also accept the task id you started the session with — agent-loop resolves it to the matching session id before delegating. The session id still works directly if you have it (e.g. from a list of multiple sessions for the same task). Likewise, recall compile --task ABC-123 without --output-dir writes to <recall-root>/ABC-123/ automatically (RecallOutputRoot::resolve(): paths.recall_root from .agent-loop/init.json if configured, else infra/doc/agent-learning/recall-output when that directory exists, else recall/), where agent-loop verify's recall-coverage check expects to find it; pass --output-dir explicitly only to override that default. See examples/basic-loop for this full sequence run against a tiny fake task with real captured output.

recall compile only writes files (system.md, validation-plan.md, recall-log.draft.json, meta.json) under <recall-root>/<task-id>/ (see RecallOutputRoot::resolve() above); it does not inject them into a running coding agent itself. After a successful compile, agent-loop prints a reminder of this:

Whatever drives the agent (a human, an editor integration, or voku/housekeeping) is responsible for reading system.md and validation-plan.md and feeding them into the actual prompt/context — that wiring is host-specific and out of scope for this package. agent-loop verify's recall check only confirms a briefing was compiled and is not stale; it cannot confirm anything actually read it.

Add the board once you have more than one task in flight, and the learning loop once you want findings to survive past a single session:

Exact available commands

Every command below is real and was verified against this repository's installed dependencies (composer require'd versions); none of it is aspirational. Run agent-loop <namespace> help (or --help) for a namespace's own usage.

agent-loop map: PHP symbol maps for smaller reads

map delegates to voku/agent-map. It builds and queries a compact PHP symbol index so agents can find the right files/classes/methods before reading large file ranges. It does not store source code, call an LLM, own durable learning, or replace PHPStan.

When called through agent-loop, map build and map refresh default --root and --out to the dispatcher root (<root>/.agent-map/php-symbols.json) unless the caller passes explicit values. Every command except build defaults --index to that same root-local index. All normal agent-map options still work:

Prefer directory scopes for --paths: PHPStan disables its result cache when it is handed individual files, which turns every rebuild into a cold rebuild. With directories, map refresh after an ordinary branch switch costs seconds.

Use map output to choose the smallest useful next read. Do not dump .agent-map/php-symbols.json into prompts.

agent-loop board external-sync is the only board command that needs a caller-provided ExternalIssueProvider implementation. The bare binary does not ship one because tracker clients are host-specific; every other board command works against local Markdown cards without it.

agent-loop review blindspots: deterministic review boundary

Run this after implementation validation and before closing the task. It writes deterministic Markdown/JSON reports plus an L2 blind-spot analysis prompt under <recall-root>/<task-id>/reviews/, using task, session, and recall artifacts from voku/agent-recall-compiler as prompt context. It warns when session notes do not show that review blindspots itself was checked. Review reports and generated prompts do not approve code. Review reports do not approve durable learning. The CLI does not call an LLM directly; the generated L2 prompt is for a human or harness to pass to a receiving LLM. Human review remains required.

L2 code-review prompt

Generates <recall-root>/<task-id>/reviews/<task-id>.code.prompt.md, an L2 code-review prompt focused on purpose mismatch, contracts, invariants, edge cases, security, and test gaps. This command is delegated to voku/agent-recall-compiler; agent-loop only defaults --output-dir to RecallOutputRoot::resolve()'s recall root so it fits the standard workflow. The prompt is intended for a receiving LLM or harness; the CLI itself does not call an LLM.

Learning boundary: findings are not durable memory

The workflow/review spine can generate evidence for learning, but it does not promote durable memory. Findings and learning candidates remain review inputs; only reviewed decisions become durable guidance. Use agent-loop memory review --file MEMORY.md as the human promotion boundary for repositories that maintain a MEMORY.md queue. See docs/workflow/learning-boundary.md for the detailed boundary.

agent-loop verify: the safety net

Every other namespace delegates outward and stops there. verify is the one command that looks across board, session, recall, and learning state at once and answers: is this repo's agent workflow state internally consistent?

Checks, each of which prints [OK], [SKIP], or [FAIL] and skips itself when its inputs are absent (so the command stays meaningful for a repo that only wires up part of the stack):

Run agent-loop verify --help for the override flags (--tasks-root, --sessions-root, --recall-root, --learning-root). agent-loop board:verify remains available as the narrower, board-only check this command used to be.

--strict: turn baseline skips into failures

By default, a missing input is reported as [SKIP] and does not fail the command — useful for a repo that only wires up part of the stack. Pass --strict to fail instead when tasks/ or session_plan/ is missing entirely:

tasks/ and session_plan/ are the baseline this command exists to confirm — a task to work on, and a session tracking it. The board and learning root stay skippable even under --strict: both are documented, opt-in additions on top of that baseline, not something every repo using agent-loop is expected to have set up. examples/basic-loop fails --strict before step 2 (session_plan/ doesn't exist yet), then passes it from step 5 onward — the same point where its own verify (without --strict) already passes, since by then a session and its recall briefing both exist.

What agent-loop deliberately does not do

agent-loop is not the learning engine. agent-loop is not the session store. agent-loop is not the recall compiler. agent-loop is the command surface.

Concretely, agent-loop:

If a feature needs new durable state, it belongs in one of the focused packages, not in agent-loop. The moment this wrapper starts hiding state of its own, it has become the second source of truth this whole stack was built to avoid.

Review boundaries and safety contracts

agent-loop coordinates the loop. It does not approve code, approve learning, or replace human review.

Concretely:

If a workflow needs an automated approval or auto-promotion path, that is a deliberate, separately-reviewed change to the owning package (voku/agent-learning for proposals, the host application for MEMORY.md), not something to add to this wrapper.

Programmatic use (host wiring)

Hosts that need custom integrations, for example Jira, implement their own ExternalIssueProvider and pass its class to board external-sync:

voku\AgentKanban\Cli\CliApplication instantiates --provider-class with a no-argument constructor, so your adapter should read its own configuration (base URL, token, project key) from environment variables or your own config file inside its own constructor.

The default binary does not ship a Jira client because Jira clients are host-specific.

That is intentional. The package should not pretend your company's Jira setup is universal. Software has enough lies already.

Scheduled execution

agent-loop is the workflow CLI.

If you want scheduled maintenance, use a runner such as voku/housekeeping to call selected agent-loop commands from cron or another scheduler.

Example scheduled jobs could include:

Keep scheduled jobs conservative.

Agents may suggest. Humans approve.

Suggested repository layout

A repository using agent-loop may keep agent workflow files under infra/doc/agent-learning:

Example workflow files:

The exact structure depends on the consuming packages and project conventions.

Token hygiene

agent-loop is part of a broader token-hygiene strategy.

It reduces prompt waste by making context selective:

The point is not to compress everything.

The point is to avoid loading irrelevant things in the first place.

Example: from finding to constraint

A session discovers this:

A proposal is created:

A human reviews it.

If accepted, it may become durable guidance:

If rejected, it is recorded as rejected guidance instead of being silently forgotten or accidentally rediscovered next week like a cursed treasure.

Development

Install dependencies:

Run the test suite:

Run PHPStan:

Run all CI checks:

composer ci runs:

Design principles

agent-loop follows a few boring but useful rules:

Boring is good here.

Boring tools fail less dramatically.

License

MIT. See LICENSE.


All versions of agent-loop with dependencies

PHP Build Version
Package Version
Requires php Version ^8.3
helgesverre/toon Version ^3.1
voku/agent-kanban Version ^0.3.1
voku/agent-learning Version ^0.13.0
voku/agent-map Version ^0.8.1
voku/agent-recall-compiler Version ^0.13.1
voku/agent-session Version ^0.6.1
voku/itp-context Version ^0.3.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package voku/agent-loop contains the following files

Loading the files please wait ...