v4.8.0

• sandbox.writes can name a task. A {task: <name>} entry, with
  optional vars, makes the directories that task's generates write in
  writable, so a sandboxed task can call it, with task: or as a nested
  task process, on a fresh checkout. Unlike the task's own generates, such
  a directory that also holds sources is not warned about, as only the named
  task can move its outputs. The entry changes neither the task's fingerprint
  nor its cache key; an unknown name fails with exit code 200.
• A sandboxed task's generates outside the root directory no longer fail
  its setup. One under an existing directory such as /opt is left to the
  commands instead of being created beforehand.
• Tasks can check that their sources are complete (Linux only). With
  sandbox: true, a task's commands and the tasks they call can read only the
  task's sources inside the root directory (the Taskfile's). A file missing
  from sources then fails the build instead of leaving a stale up-to-date
  result or cache entry. sandbox.reads and sandbox.writes widen it. The
  restriction uses Landlock, or a slower seccomp supervisor on kernels without
  it (which also works without process_vm_readv, as in some microVM guests);
  with neither available, the default TASK_SANDBOX=auto runs commands
  unrestricted with a warning (TASK_SANDBOX=landlock or seccomp makes it an
  error). Any denial the supervisor sees fails the task, even one the command
  recovered from or ignored, and an enforced sandbox runs a command's if under
  the supervisor (without the supervisor, unsandboxed with a warning).
  TASK_SANDBOX=audit lists every undeclared access without failing.
• sources and generates can copy another task's entries. A
  - task: <name> entry, with optional vars, folds in that task's sources
  (or generates) without it being a dependency or running, so a test or lint
  task stays in step with the build task whose inputs it reads, including
  under sandbox. An unknown task name in a task: or from: entry now fails
  the run or --status with exit code 200, naming the referring task and
  field.
• A Taskfile error with a position now shows the offending lines, with a
  caret under the error, after the message. Unlike Go Task, YAML syntax errors
  get one too; a type mismatch found while decoding still has no position, so
  no snippet.
• Taskfiles are parsed with a memory-safe YAML parser. Checksums and the
  positions of decode errors are unchanged; YAML syntax errors are worded and
  sometimes positioned differently (an unclosed [, { or quote is reported
  where it opens), and a Taskfile starting with a byte order mark now loads.
  Unlike Go Task, a comment glued to the token before it ('x'#c, |#c,
  {b: 1}#c, [1,#c) and [-] are refused, [?x] reads as the string ?x,
  &a#c names the anchor a#c, U+0085, U+2028 and U+2029 are not line
  breaks, and a few inputs Go Task refuses (a tab-indented top-level key, an
  empty key, a stream of only ..., %YAML 1.3) are accepted.