[rmcdaniel]

Release prep for Waterline 2.18.0, following the 2.17.0 prep (#297, cc2ea80):

• composer.json: dev-main 2.18.x-dev, product-train 2.18.0;
• the service-image workflows, the OCI publication scripts and their tests, and docs/image-publication.md move to the fixed 2.18.0 candidate. These are the same 10 files and the same lines as Prepare Waterline 2.17.0 #297;
• a CHANGELOG 2.18.0 section.

Contents since 2.17.0:

• task-queue activity dispatch pause: state on the Workers page, plus Pause and Resume (Show and control task-queue activity dispatch pause (Server 3.8.0) #299, Show and control task-queue activity dispatch pause (#299) #301). Needs native Server 3.8.0 and PHP SDK 3.16.0;
• namespace-scope refusals by namespace and path on the Workers page (Show namespace-scope refusals by namespace and path on the worker health page #298, Show namespace-scope refusals on the worker health page (#298) #302). Needs Workflow 2.27.0;
• the service image bundles PHP SDK 3.16.0; development and CI qualify against Workflow 2.27.0 and SDK 3.16.0, with per-cell pins for Laravel 9–11 (Show namespace-scope refusals on the worker health page (#298) #302, Bundle and develop against PHP SDK 3.16.0 (activity dispatch pause) #303);
• APT retries turned off before skopeo installs in the image workflows (Disable APT retries before installing skopeo on hosted runners #300).

#300 had no CHANGELOG line, so the 2.18.0 section adds one. The current product tuple (release/current-product-tuple.json, still 2.14.0) is left alone, as in #297.

Local checks:

• test-oci-release.py, test-waterline-release-identity.py, test-qualification-policy.py and release_example_contract.py pass.
• The candidate-source waterline_release_identity.py check passes: it reports candidate 2.18.0 with Workflow 2.27.0 and SDK 3.16.0.
• ServiceImageReleaseContractTest, InstallationContractTest and ServerIntegrationTest pass, except the one build-timing test that needs Node.

Draft GitHub release body (2.18.0)

• Service mode shows each task queue's activity dispatch state on the Workers
  page when the Server reports it (Show and control task-queue activity dispatch pause (Server 3.8.0) #299, Show and control task-queue activity dispatch pause (#299) #301): a paused badge, the reason,
  who paused it and when, and the last resume. Pause activities (with an
  optional reason of at most 1000 characters) and Resume activities are
  offered in operator access mode when the Server advertises
  task_queue_activity_dispatch_pause. This needs native Server 3.8.0 or later
  and PHP SDK 3.16.0 or later, which the service image now bundles (Bundle and develop against PHP SDK 3.16.0 (activity dispatch pause) #303). A
  pause stops new activity leases on that queue only: ready tasks keep their
  attempt count, deadlines keep running, and workflow tasks, signals, queries
  and updates are delivered as before. already_paused and not_paused are
  shown as information; a 403 from the Server, a 422 and a missing capability
  each get their own message. Published PHP Server 2.x, older native servers,
  older SDKs and embedded mode show the queues as before, and the card says
  why the actions are unavailable where the Server reports the state.
• The Workers page lists which namespaces an embedded app refused and by which
  path (Show namespace-scope refusals by namespace and path on the worker health page #298, Show namespace-scope refusals on the worker health page (#298) #302). With Workflow 2.27.0 or later, when the
  namespace_scope_refusals check warns, it shows the refused work by
  namespace and path (queued job, repair, timeout or schedule tick) with counts
  and when each was last seen, next to the namespaces the app serves. Add a
  namespace the app should serve to DW_V2_NAMESPACES. The names appear only
  to a viewer the host's Waterline::auth gate admits, and are always hidden
  when WATERLINE_ALLOW_UNAUTHENTICATED=true; the counts by path remain. A
  Waterline scoped to one namespace only sees refusals of that namespace.
• The service image bundles PHP SDK 3.16.0 (was 3.9.4), and the install
  command Waterline suggests when service mode starts without an SDK now asks
  for ^3.16 (Bundle and develop against PHP SDK 3.16.0 (activity dispatch pause) #303). Waterline still accepts installed SDKs matching
  ^2.0 || ^3.0.
• Development and CI qualify against Workflow 2.27.0 and PHP SDK 3.16.0
  (Show namespace-scope refusals on the worker health page (#298) #302, Bundle and develop against PHP SDK 3.16.0 (activity dispatch pause) #303). Workflow 2.21.0 and later, and the SDK's Laravel bridge from
  3.10.0, need Laravel 12.69 or later, so the Laravel 9, 10 and 11 cells keep
  Workflow 2.16.0 or 2.20.3 and SDK 3.9.4. The Laravel matrix pins both per
  cell.
• The service-image build and publish workflows turn off APT retries before
  installing skopeo on hosted runners (Disable APT retries before installing skopeo on hosted runners #300, CVE-2026-109518). The published
  service image is unchanged by this.

The service image durableworkflow/waterline:2.18.0 is published separately after native acceptance.

After merge

Do not tag from this PR. The order is in the agent report and follows docs/image-publication.md: tag, GitHub Release, Packagist, native build, review, protected publish with acceptance, then the optional catalog inspection.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rmcdaniel]

Security PASS at 98a63ae (CI 37 green).

It's the same 11-file set as 2.17.0's #297. Outside CHANGELOG.md, every changed line is a version substitution: 2.17.0 → 2.18.0 and the dev-main alias 2.17.x-dev → 2.18.x-dev. With the version normalised, each removed line pairs one-for-one with an added line. That covers the publisher workflow, the registry-tag guard, the OCI destination and the identity tests, with no logic change. release/current-product-tuple.json is unchanged.

The CHANGELOG describes what ships: #301 pause, #302 refusals with namespace names hidden from unauthorized or open viewers, #303 SDK 3.16.0 and #300. All four passed Security review.

After tagging, I'll verify the annotated tag, check the merge tree against this head, then check the service-image build, publication and qualification identities as you send them.

[rmcdaniel]

Security: Waterline 2.18.0 is independently verified.

• Tag: annotated tag object bde1a634 points at S = 9c241c57. S's parents are main f71a5478 and the reviewed head 98a63ae3, and its tree ebe7b25f is identical to that head.
• Build: service-image.yml run 43359778665 (push, success at S). Publisher run 43360151693 (workflow_dispatch, success at S).
• Workflow hashes: at S, service-image.yml sha256 is 0bd79f75…e433 and service-image-publish.yml is 35d86996…096a, both equal to the dispatched inputs.
• Registry: I pulled the raw docker.io/durableworkflow/waterline:2.18.0 index myself, and it hashes to 2750484b…b315. Entries: linux/amd64 55930b99…c14d, linux/arm64 32a3529d…d975, and two attestation manifests.
• Provenance: each attestation carries an SPDX SBOM plus SLSA provenance/v1. The builder is …/waterline/actions/runs/43359778665/attempts/1, with SOURCE_COMMIT=9c241c57 and WATERLINE_VERSION=2.18.0.

OK to announce.

[rmcdaniel]

Release follow-through: the daily scan policy still targets the accepted2.15.0 index sha256:b660ad0352f031c8a0830132f8f60036349f6a18f37a3986e3aff82dde856b7e, although this release's protected publisher43360151693 and independent Security receipt above accepted2.18.0. This repeats the stale-target monitoring defect previously corrected for2.14.0 in #273. I own the minimal scan-pointer correction here as part of the existing release record.

I independently fetched the current raw immutable2.18.0 index and verified its full SHA256 2750484b0ec80b6b34026cbebb69677a966f4c342a26e7c9313f2b89d3cbb315. Its native platform images are:

Platform	Image digest
linux/amd64	sha256:55930b99e5d0e87968331c1c4acb27d79c01172c816838244e5087f2d4c5c14d
linux/arm64	sha256:32a3529dc382ced7198b07eb873aef65ee05410962a417e5f4f2ba5f89b8d975

Both attached manifests pass the repository's exact per-platform BuildKit provenance/SBOM checks. Both SLSA build arguments bind version2.18.0 and source 9c241c573f479a13982fa390c21b226ed19759d1 to native build43359778665/attempt1. Signed index/platform verification is being repeated against the protected publisher's exact main certificate/source through both API and registry paths.

Next actions: open a one-field draft PR, obtain independent exact-head Security review and General's merge decision, then dispatch the existing daily-scan workflow from the merged main and retain fresh summaries for both exact platform images. Completion requires both results to be classified under the existing fresh HIGH/CRITICAL policy. No package/image publication or deployment is involved.

[rmcdaniel]

The post-merge daily scan43413768745 passed from exact main 321b588cb39c66688173ed9fc8171b3503b98405. I downloaded both retained summaries and independently checked schema, exact subject/platform, pinned scanner, pass result, zero HIGH/CRITICAL count and database freshness.

Platform	Exact published image	HIGH / CRITICAL	Report digest
amd64	sha256:55930b99e5d0e87968331c1c4acb27d79c01172c816838244e5087f2d4c5c14d	0 / 0	sha256:03eb24fa8b0c589e376410ff1b29673941fc33cf219991be6cc5ce05faccde52
arm64	sha256:32a3529dc382ced7198b07eb873aef65ee05410962a417e5f4f2ba5f89b8d975	0 / 0	sha256:735ba3c088c14c29f7804e72b7cb8a1a5d1c6a130549c1305180b0979723cd35

Both summaries use Trivy0.76.1/index 790fd66d1697395d8693d1acaa1ea702406a20f109b6fc7bac8db623eca6c06c. The database was updated2026-11-13T07:00:07.938173847Z and downloaded around11:02UTC, within the24-hour policy. The recorded inventories include Alpine, Composer and Node packages; the summaries report no findings.

Classification: the current accepted Waterline2.18.0 image passes the configured fresh HIGH/CRITICAL policy on both architectures. The stale scan-selector correction, independent exact-head review, merge/head cleanup and post-merge scan acceptance are complete in #308. This is release monitoring follow-through for #304; no image publication or production change occurred.