go() scripts are a more application-friendly style of cron task.

Instead of launching a standalone script process and reading argv, we place a PHP file in cron/ that defines a go() function:

<?php
use GT\Input\Input;

function go(Input $input):void {
	file_put_contents(
		"var/cron.log",
		"Mode: " . $input->getString("mode") . PHP_EOL,
		FILE_APPEND
	);
}

The runner loads that function and invokes it directly.

¶Why use go() scripts?

This style is useful when we want:

• a tidy task entry point in cron/
• request-like named input instead of shell arguments
• dependency injection for services
• query-string input without shell quoting

¶Referencing a go() script

If cron/cache.php contains function go(...), all of these command forms are accepted:

* * * * * cache?type=db&mode=daily
* * * * * /cache?type=db&mode=daily
* * * * * cache.php?type=db&mode=daily
* * * * * cron/cache?type=db&mode=daily
* * * * * /cron/cache?type=db&mode=daily

The part after ? is parsed as a query string.

¶Reading input

Query-string values are made available through an Input object:

<?php
use GT\Input\Input;

function go(Input $input):void {
	$type = $input->getString("type");
	$mode = $input->getString("mode");
}

This keeps the task code readable when there are several named options.

¶Dependency injection

go() functions may also receive services as parameters when they can be resolved from the service container.

Example:

<?php
use GT\Input\Input;
use App\Service\Recorder;

function go(Input $input, Recorder $recorder):void {
	$recorder->write($input->getString("type"));
}

The runner creates a container, puts the Input object into it, and then uses the service loaders that are available for the project.

¶How project services are found

When configuration is available, the runner reads:

• app.namespace
• app.class_dir
• app.service_loader

From there it can:

• autoload project classes from the configured class directory
• register WebEngine’s default service loader when it is installed
• register the project’s own service loader class

[!NOTE] In WebEngine projects this usually means go() scripts can use the same service-loading conventions as page logic, which makes cron tasks feel like part of the application rather than a separate subsystem.

¶Nested files

Unlike ordinary script aliases, go() scripts may live in subdirectories under cron/.

For example, this may point at cron/report/daily.php:

0 6 * * * report/daily?audience=internal

¶One important limitation

go() script commands do not accept shell-style trailing arguments after the script name. The special handling is only used when the command is just the script reference, optionally followed by a query string.

Use query-string parameters when the task needs named input.

¶Choosing between go() and ordinary scripts

Choose an ordinary cron/*.php script when:

• argv is enough
• we want a separate process
• the task is already written as a standalone script

Choose a go() script when:

• we are in a WebEngine context
• we want named input through Input
• we want service injection
• we want to organise tasks into nested directories

---

If the built-in cron syntax is not enough, the next page shows how to extend it with Custom expression factories.