The console

The framework should explain your application, not just run it

The CLI is first-class, not an afterthought. A runtime feature is not finished until something can show it — if routing gains a capability, tether routes gains a column.

php tether help
php tether help <command>

Understanding an application

php tether routes                 # every registered route, and what wraps it
php tether explain /posts/12      # resolve one URL the way a request would
php tether inspect Actions\Post\Show
php tether context                # the whole application as JSON

routes flags any route whose Action is missing or not routable — a 500 nobody would otherwise see until someone requested it — and lists the middleware every route passes through.

explain walks one URL through the pipeline: the middleware it passes, the route it matches, the parameters it captures, the query string the Action receives, and the Action, Domain, Result and Responder behind it. Where a link is a naming convention it says so, and where it read the answer out of the code it says that too.

context writes JSON to stdout and nothing else, so it can be piped. It carries the routes, the ADR triples, the commands, the directories and the conventions that are otherwise folklore — which is what an agent needs in order to place a new feature without guessing.

Generating code

php tether make:feature Blog                  # one page, whole triple
php tether make:resource Post --uri=/posts    # seven, a whole CRUD resource
php tether make:action Blog Show              # add one operation to a feature

The three piecemeal generators take a feature and an operation, and default the operation to Index. They warn when the class they just wrote refers to one that does not exist yet, which is a legitimate thing to do — the others may be coming — but should never be silent.

Explicit code costs typing. That is the correct trade only because the generators write the explicit parts, and what runs is still exactly what you can read. See CRUD.

Running things

php tether serve                  # PHP's built-in server
php tether test                   # your application's PHPUnit
php tether boilerplate:clear      # remove the shipped home page

test forwards to your own PHPUnit rather than vendoring a runner into the framework.

Exit codes are part of the interface

Every command returns a real exit code, so a script or a CI job can tell success from failure. A command that cannot be registered — a misnamed class, a missing autoload mapping, a duplicate name — is reported to stderr with the reason rather than silently vanishing from the list.

Every command

Generated from tether context rather than written by hand, because a list of commands maintained in two places is a list that goes stale — this page spent three releases claiming the framework had two.

tether boilerplate:clear [--force]

tether context [--pretty]

tether explain <uri> [--method]

tether help <command>

tether inspect <class>

tether make:action <feature> <operation>

tether make:command <name>

tether make:domain <feature> <operation>

tether make:feature <name>

tether make:resource <name> [--uri]

tether make:responder <feature> <operation>

tether routes [--method]

tether serve [--host] [--port]

tether test

If that list disagrees with your install, yours is right and this is stale. The framework knows its own commands; run php tether help.