0.1.7

Added

• Forward Predict, as five new groups of unpublished operations: 50 in all,
  described from Forward's server source and verified against a live instance
  of the current build. Requested by the change-demo integration, which had
  been reaching them through a raw request helper.

  client.change_sets covers the rehearsal loop with a handle per change set:
  create against a base snapshot, stage device commands as plain text, validate,
  commit, predict_and_wait() for the processed predicted snapshot, checks, and
  delete. client.snapshot_diffs compares two snapshots: subnet connectivity
  with wait_for_subnet_connectivity() for the asynchronous computation,
  vulnerability and routing-loop counts, their bidirectional views, a file
  summary, and counts() for every per-area count at once.
  client.firewall_predict holds the structured security-rule edits PAN-OS
  needs, since CLI-driven Predict does not work there. client.webhooks and
  client.configuration round it out, with config_value() to read a
  configuration response whatever its key.

  The traps a consumer met while working around these are encoded rather than
  documented: note is required on predict and commit, the bulk delete key is
  changeSetIds, the create body carries no networkId because Forward
  rejects unknown properties, and the first connectivity read after a
  prediction returns zeros that mean "not finished". See the new "Rehearsing a
  change" page for the ones a signature cannot carry, including the global
  configuration route reporting a default that the org route contradicts.

  Two claims in the consumer's notes were wrong and are corrected here: the
  create body must not carry networkId, and an omitted webhook network list
  is a 400 rather than a server crash.

• HAND_WRITTEN_TAGS is now one list, on the operation definitions module,
  read by the service generator and the coverage test alike, so the two cannot
  disagree about which groups are generated.

Fixed

• The unpublished-endpoints page said the NQE execution request's sort and
  filter fields were absent from the published description. They are in it.

• nqe.repo.publish no longer raises when nothing has changed. Forward
  terminates its rejection with a full stop, User has no changes at the following paths: /a/q1, /a/q2., and the parser kept it, so the last path read
  as /a/q2. and matched nothing. The caller then stripped every path but that
  one and retried a commit Forward refused for the same reason, and the second
  refusal escaped. Re-running an idempotent publisher with nothing to publish is
  the normal case in a pipeline, and it reported failure. A single-path commit
  was affected too, since that path is also the last one.

  A second refusal of the stripped set is now also read as a no-op rather than
  raising, so a message this parser cannot read cannot turn a no-op into an
  error again. Found by reading Forward's own source, which builds that string,
  and confirmed on an instance of the current build: re-publishing a committed
  query's own source returns a report with it skipped, commits nothing and
  leaves no draft behind.

Changed

• latest_processed and latest_processed_id exclude predicted snapshots.
  Forward creates and processes one for every Predict run, so on a network using
  Predict the newest processed snapshot is very often a prediction rather than a
  state the network was ever in, and basing a change set on one predicts a
  change against a change. Pass include_predicted=True for the old behaviour.

  The filter excludes PREDICT rather than requiring COLLECTION. A reprocessed
  snapshot reports REPROCESS and is real collected data, and on one live
  network 20 of 43 processed snapshots were reprocessed; requiring COLLECTION
  would skip those and select the previous collection, which during a rehearsal
  is the snapshot taken while the change was still applied. Reported by the
  change-demo integration, which had hit exactly that.

  Confirmed against a Predict-enabled instance: on a network there, 4 of 5
  processed snapshots were predictions, so the previous default picked one four
  times in five.