TetherPHP

TetherPHP is an open-source PHP framework built around the Action-Domain-Responder pattern. It is designed for developers who want to follow a web request from route to response by reading ordinary application code. Each route has an Action, the Action calls a Domain that stays independent of HTTP, and the result goes to a Responder that decides what the view receives. This gives an application a consistent path through named classes instead of hiding important behavior behind a large amount of framework machinery. The project emphasizes code that a new teammate or an AI coding agent can inspect without first learning unwritten conventions.

The structure is deliberately explicit. Routes show where requests go, middleware configuration shows what wraps them, and dependencies are assembled visibly rather than pulled from a dependency injection container. A Services class lists what the application is made of, the public entry point builds those services, and Actions receive what they need to pass into Domains. Files follow predictable names and locations, with matching Action, Domain, Result, Responder, and view components for a feature. The framework encourages one class per route instead of placing several route methods in one controller, keeping the path through an application narrow and traceable. The skeleton separates Actions, console Commands, Domains, Domain Results, Responders, Views, public files, routes, storage, and tests into visible directories. Unit tests can exercise a Domain alone, while feature tests pass through the Kernel. This mirrors the division between business logic and HTTP concerns that the ADR structure is intended to preserve.

TetherPHP ships the fundamental web pieces rather than a full stack of preferred libraries. Its stated scope includes routing, requests, responses, middleware, and a console. It does not bundle an ORM, query builder, validation layer, or service container. Database access, validation, templating choices, queues, and other concerns can be added as packages. CSRF protection and HTTP method overriding are supplied as middleware but must be enabled in the middleware routes file, so an API can omit them and start without a session. Tailwind CSS is preconfigured in the skeleton, and application logs are written under the storage directory.

The command line tooling is a central part of the framework. Generator commands can create an individual Action, a complete feature, or a CRUD resource with the matching Actions, Domains, Responders, Results, and views. Introspection commands list registered routes, explain how a URL resolves, inspect application details, and produce machine-readable context in JSON for tools and agents. The console also runs the test suite and reports its available commands. An explain command can resolve a particular URL the same way the application will, while the routes command reports registered routes and their middleware. A context command outputs JSON specifically so external tools and agents can read the application structure. This is meant to help both people and coding agents understand the application they are modifying, not merely save typing during initial scaffolding.

TetherPHP is a good fit for developers who prefer clear conventions, a small core, and direct control over which supporting packages enter a project. Its charter prioritizes human-readable code, agent-friendly structure, visible wiring, one obvious way to perform common tasks, composable packages, and first-class developer tools. That opinionated design reduces ambiguity but will feel restrictive to teams that want several accepted architectural styles. The minimal core also means developers must choose and integrate capabilities that larger frameworks include by default. It requires PHP 8.5 or higher and Composer, and projects can run through PHP's built-in server or the supplied Docker setup.

The framework is MIT licensed and distributed through Packagist as a Composer project, so there is no purchase or hosted service required. A new project can be created with Composer, followed by copying the example environment file and starting the development server. The official documentation covers the ADR model, requirements, usage, naming, routing, requests, responders, middleware, services, CRUD building, and the console. The project is still in early development and remains below version 1.0, while its own documentation says features and guidance are actively being developed. It is therefore most appropriate for developers comfortable evaluating a young framework and filling in some infrastructure through packages.