v0.6.0

Metaproc v0.6.0

A minor release, because a gcp run job’s console moved off Cloud Logging and a mapped
composite now runs as concurrently as its run was told to.

Most of what changed is about a long cloud run staying observable without becoming
expensive to observe.
A gcp run job appends its console to a file on the job’s run-storage mount and sends
Cloud Logging only a start line, a heartbeat a minute, and the exit line; a bounded live
view in the dispatch bucket lets metaproc gcp logs and metaproc gcp status read the
job without mounting the run-storage share.
Validation reports now carry each layer’s actual execution rather than leaving it
unknown.

The one change that alters how an existing process runs is the mapped-composite scope
ceiling: a run whose ceiling is 80 or 160 used to open at most 32 item scopes anyway,
and now opens as many as the ceiling admits.
Read Compatibility before upgrading.

No CLI command or flag was removed, no adapter default or accepted model identifier
changed, and no plugin entry point moved.

What’s Changed

Features

• A gcp run job keeps its console in a file. With a run-storage mount and the
  shipped wheel, the command runs inside metaproc.cloud.gcp.gcp_run_console, which
  appends its output to <mount>/logs/gcp-run/<job>/console.log. Cloud Logging keeps
  the wrapper’s start line, a heartbeat a minute, and the exit line, plus the bootstrap
  output from before the wrapper starts — so a job that fails during bootstrap is still
  diagnosed there, while the console file is the complete record of the command itself.
  A whole run’s console no longer has to be a Cloud Logging stream to be readable.

  • --console file requests the file explicitly, --console cloud-logging keeps the
    whole stream in Cloud Logging, and the default --console auto chooses the file
    when the job has a run-storage mount and ships the wheel.
    Cloud Logging therefore remains the default for --no-wheel jobs.
    --console file without a mount is refused rather than silently downgraded.
  • A bounded atomic live view in the dispatch bucket pairs the console tail with its
    cursor on each heartbeat, so a reader always sees a consistent tail.
  • --watch-run <container path> names run directories, repeatably, whose
    metaproc status a background worker caches every five minutes.
    It needs the file console.
  • metaproc gcp logs <job> gains --follow, --errors, and --cloud-logging, and
    metaproc gcp status <job> --run-status reports a watched run’s status.
    Both read the job through the live view, without mounting the run-storage share.
  • Live following stops at terminal Batch state when a final upload is missing, instead
    of waiting for a tail that is never coming.
  • The dispatcher sets METAPROC_GCP_RUN_CONSOLE_PATH, METAPROC_GCP_RUN_LIVE_GCS,
    and METAPROC_GCP_RUN_WATCH inside the job; none is set by hand.

• Validation reports state what actually ran. Each layer carries its own execution
  — not_run, completed, or errored — so a report distinguishes a check that passed
  from one that never ran.
  Built-in model-only checks include the document-enforcement-via-model-only advisory.
  A report retained from an earlier release has no such evidence, and its execution
  stays unknown rather than being guessed.

Fixes

• A mapped composite opens as many item scopes as the run’s ceiling admits. It used
  to open at most 32 at once whatever --max-concurrency said, so a run with a ceiling
  of 80 or 160 never had more than 32 items’ leaves competing for the pool.
  Scopes hold no admission capacity of their own, so they now follow the run’s ceiling,
  with 32 as the floor.
  The pool’s memory and provider admission still bound the work in flight.
  See Compatibility: this changes how an existing process runs.

• Frontmatter repair no longer rewrites valid frontmatter. Its self-check used
  ruamel’s raw safe loader, whose C scanner rejects flow collections that are valid YAML
  — URL values among them — so on a machine with ruamel’s C extension installed the
  repair could fire on a document that was never broken.
  The check now uses the same guarded reader as downstream validation, which falls back
  to the pure parser, and such documents are left unchanged.
  The narrow malformed-scalar repair is unaffected.

• Resuming a cached task no longer rewrites its state bytes. A terminal task status
  took its completion time from the clock at the moment it was written, so a resume that
  reused a cached task produced a different completed_at on every tick.
  It now comes from the accepted durable attempt’s end time.

• Pool files are written the same with or without ruamel’s C extension. With
  _ruamel_yaml installed, the safe YAML handle behind pool status, scale-state,
  scale-override, and kill-sentinel files switched to libyaml’s emitter, which wraps
  long values at different points, so the same state serialized to different bytes
  depending on what was installed.
  They now dump through metaproc.io.new_dump_yaml, which keeps the pure-Python
  emitter.

Documentation

• Installation describes the optional YAML C extension and what
  installing it does and does not change.
• The shipped file-I/O architecture topic (metaproc help arch-file-io) describes the
  guarded frontmatter repair check and the reader-compatibility boundary.

Compatibility

• Two dependency floors rise. Metaproc now requires softschema>=0.9.1,<0.10 and
  frontmatter-format>=0.5.1,<0.6. Both are resolved for you on install; a pinned
  environment holding either below its floor cannot install this release, and that
  includes softschema==0.9.0 and frontmatter-format==0.5.0 — the floors are the
  patch releases, not the minor series.
  The frontmatter-format readers use guarded C-parser paths when available and fall back
  to the pure parser, and its writers retain deterministic pure-Python emitters.

• A mapped composite may now run more work at once. This is the one change that can
  alter an existing run’s behavior without any spec or flag change.
  A process whose run ceiling is above 32 — --max-concurrency 80 or 160, say —
  previously had at most 32 item scopes open; it will now open as many as the ceiling
  admits, so more leaves compete for the pool and peak memory and provider pressure rise
  accordingly. The pool’s memory and provider admission still bound what actually
  executes, and 32 remains the floor.
  If a run was tuned against the old implicit cap, set --max-concurrency to what you
  actually want rather than relying on the 32.

• Validation execution is additive. A report written by this release carries each
  layer’s execution; one retained from an earlier release does not, and readers treat
  that as unknown. No existing report token changed.

• Three new environment variables, all set by the dispatcher inside a gcp run job:
  METAPROC_GCP_RUN_CONSOLE_PATH, METAPROC_GCP_RUN_LIVE_GCS, and
  METAPROC_GCP_RUN_WATCH. Nothing else in the environment contract changed.

• Nothing public was removed. No CLI command or flag, no adapter default (opus,
  gpt-5.5, gemini-3.1-pro-preview-customtools, sonnet), no accepted model
  identifier, no process-file field, no runtime artifact shape, and no plugin entry
  point was removed or renamed.

• Still open from v0.5.0: the GCP image interpreter. Metaproc has required Python
  3.14 since v0.5.0, and container bootstrap refuses the shipped wheel on an image whose
  /opt/venv is older.
  That image build lives outside this repository and is still unverified (mp-mo74).
  Until it is confirmed or rebuilt on 3.14 and re-pinned, dispatch with --no-wheel or
  from 0.4.x; metaproc help cloud-dispatch says the same.

• Still open from v0.4.0: Gemini and ignored files. Gemini steps ship with
  context.fileFiltering.respectGitIgnore: False, so a Gemini step’s file tools can
  read ignored files anywhere in the workspace, .env included.
  Whether the default should become opt-in is still open as mp-x1qh; treat a workspace
  a Gemini step runs in as readable by that step.

Full commit history:
v0.5.0 … v0.6.0