Fakes and the development call log

This is the detail behind Tests and fakes and Provider calls in development: what a fake answers, how a script is used, and what the call log keeps.

• One fake per test, in every provider connection's place. The test host gives a package's fake for each connection to a provider package, so a subscriber's call between the test's steps answers from the same script. An unscripted call answers with the operation's generated default.
• The generated default is the value of the operation's output type a provider would send, keeping its rules where a simple value can: text of its least length (example where that fits), a number at its least, the first plain variant, empty lists and maps, null for what is optional, the invocation's clock for an instant and its date, a fresh UUID. It is written as the provider sends it, its wire_name: spellings and output_at: envelope included, and read back through the operation's decoding, so a type whose rules no such value keeps (a pattern, say) faults where it is read, naming the field and the rule, and the test scripts it instead.
• A scripted answer is a value of the operation's output type, written and read back the same way; one of its failures, by its code; or a condition: unavailable, lost (the request went and no answer came: outcome_unknown for an unkeyed change, unavailable otherwise), in_use (the provider's key still in use) or misconfigured. A bare name is only a code or a condition, never a constant; an operation is scripted once, with at least one answer (semantic.fake_invalid). fakes: sits among the test's settings, and its answers are given to the fake before the test's first statement.
• A script's use. Each call of a scripted operation takes its next answer; a call past the last gets the generated default and fails the test as test.fake_exhausted, which reports in place of whatever the test went on to fail with, being the first thing that went wrong. Answers left fail a test that otherwise passed as test.fake_unused. Both name the operation, at its first scripted answer.
• jadpo dev gives every provider connection of the program it runs one driver: the sandbox, through the package driver, for what is let through; otherwise the fake, answering what jadpo calls script scripted, then the generated default. A provider connection's credential, environment or address setting that no variable or default gives gets a stand-in, so the app starts; such a connection stays faked whatever sandbox: says, and jadpo dev names the variables to set. Its environment set to live refuses to start, or to reload a save, with cli.dev_start_failed naming the variable and --fake. The session's --sandbox takes connection.resource.operation or connection.resource, and --fake a connection, each checked (cli.dev_arguments).
• development: { sandbox: } takes only sandbox:, a list of resource.operation and resource names, each once, each one of the package's public operations or resources (connection.key_invalid, connection.value_invalid).
• Scripting by hand. jadpo calls script <operation> <answer> takes an operation as the code calls it and one of its failures' codes or a condition, checked against the project's plan; a value can't be given on the command line. Each answer waits as a file of its own under build/dev/script/, oldest first, and the call that takes it removes it, so each answers one call, whichever worker makes it.
• The call log is build/dev/calls.jsonl, one call a line: its id (call_31, counted on from the last the log holds), when it went out, its connection and operation, its source (generated, scripted, sandbox and recording), its request's id, how long it took, the request as made (method, address and body, never its headers, which hold the credential) and the answer as sent or generated, and how it ended with a failure's code. It keeps the last 500 calls. A call retry: sends again is one entry, its last attempt's, where the invocation's own log keeps each attempt. Only provider calls are logged, a host's other capabilities' calls (files) are not, and a delivery's or a schedule's call has no request. Each request's line in jadpo dev lists its calls, and its --json event gives them.

A script's .requests isn't built yet, nor are the timelines the call log would keep beside its calls.