@fleetless/contracts 1.0.5 → 1.0.6

package/CHANGELOG.md

@@ -5,6 +5,15 @@ follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and the
 project uses [semantic versioning](https://semver.org/spec/v2.0.0.html) over
 the wire shapes.
 
+## [Unreleased]
+
+## [1.0.6] — 2026-09-16
+
+- Published from GitHub Actions by npm trusted publishing: no publish token exists anywhere, and every version from this one on carries a provenance attestation linking it to the commit and the run that built it. `npm audit signatures` checks it.
+
+- **The README is a lobby now.** Who the package is for, what is in the box, the two schema directories and which one to validate against, versioning, and links into docs.fleetless.dev. No wire shape changes.
+- The prose guard treats a path into the company-site repository the way it treats every other sibling repository's path. No wire shape changes.
+
 ## [1.0.5] — 2026-09-07
 
 The guard was rebuilt around the set of bytes that become public rather than
@@ -91,8 +100,8 @@ files under `artifacts/schema/` — the one that moves carries a reworded
 
 - **Descriptions and comments that spoke inward.** 1.0.2 removed the markers — a
   ticket id, a robot's hostname, a German paragraph — and left the stance. Text
-  that named an internal decision label (`D2`, `D7`), pointed at a file in
-  another repository (`cloud/src/routes/config.ts`), said "this project" or
+  that named an internal decision label (`D2`, `D7`), pointed at a source file in
+  another repository, said "this project" or
   "this repository", cited a document a reader does not have, or explained how
   somebody discovered the behaviour rather than what the behaviour is. All of it
   is rewritten for a reader who has only this package: 13 descriptions and every

package/CONTRIBUTING.md

@@ -1,12 +1,12 @@
 # Contributing to `@fleetless/contracts`
 
-This package is the single source of wire truth for Fleetless: every shape the
-API accepts or returns, and every message the robot-side bridge exchanges with
-the cloud, is written here once as a zod schema and exported as JSON Schema and
-OpenAPI for consumers that are not TypeScript.
+This package is Fleetless's single source of wire truth. Every shape the API
+accepts or returns, every message the robot-side bridge exchanges with the
+cloud — written once as a zod schema, exported as JSON Schema and OpenAPI for
+consumers that don't speak TypeScript.
 
-That makes a change here a cross-repository change. A schema is not a detail of
-one program; it is the agreement between several.
+A change here is a cross-repository change: a schema isn't one program's
+detail, it's the agreement between several.
 
 ## Setup
 
@@ -18,8 +18,8 @@ corepack enable
 pnpm install
 ```
 
-There are no private dependencies. `pnpm install` works from a clean checkout
-with nothing but a network connection to the npm registry.
+No private dependencies — a clean checkout and a network connection to npm
+are all `pnpm install` needs.
 
 ## The checks
 
@@ -32,67 +32,81 @@ with nothing but a network connection to the npm registry.
 | `pnpm run test:pack` | Packs the tarball, asserts what is and is not inside it, then installs it into a scratch project and imports it for real. |
 
 To run one test file, use `pnpm vitest run test/<name>.test.ts`. Do **not**
-use `pnpm test -- <pattern>`: it does not filter, it runs the whole suite, and
-the exit code you read is the suite's.
+use `pnpm test -- <pattern>`: it does not filter, it runs the whole suite,
+and the exit code you read is the suite's.
 
 ## Changing a schema
 
 1. Edit the zod schema in `src/`.
-2. Run `pnpm artifacts`. This regenerates `artifacts/`, which is **committed**.
-   A test fails if the committed artifacts are stale, and so does CI.
+2. Run `pnpm artifacts`. It regenerates `artifacts/`, which is
+   **committed** — a stale artifact fails a test, and so does CI.
 3. Run `pnpm typecheck && pnpm test`.
-4. Commit the schema change and the regenerated artifacts together. A commit
-   that changes one without the other is a commit that publishes a lie to every
-   consumer validating against the artifact.
+4. Commit the schema and the regenerated artifacts together — split them
+   and you've published a lie to every consumer validating against the
+   artifact.
 
-Every source file carries the SPDX header `// SPDX-License-Identifier:
-Apache-2.0` as its first line. A test asserts this over the whole set — and the
-directory list is derived from the repository rather than written down, so a new
-top-level directory is swept the day it exists.
+Every source file's first line is the SPDX header
+`// SPDX-License-Identifier: Apache-2.0`. A test asserts the whole set, and
+the directory list comes from the repository rather than a written-down
+list — a new top-level directory is swept in the day it's created.
 
-The published files carry it too, which `tsc` does not do on its own:
-declaration emit drops a leading comment, so `scripts/stamp-dist.mjs` puts the
-header back on every file in `dist/` and `pnpm run test:pack` asserts it over
-the tarball's own bytes.
+The published files carry it too — `tsc` won't do that alone; declaration
+emit drops a leading comment, so `scripts/stamp-dist.mjs` puts the header
+back on every file in `dist/`, and `pnpm run test:pack` asserts the tarball's
+own bytes.
 
 **Nothing internal reaches the published bytes.** Doc comments in `src/` are
 carried into `dist/*.js` and `dist/*.d.ts` by `tsc`, and every
-`.meta({ description })` is copied into the JSON Schema and OpenAPI artifacts —
-so a comment written for the people who build this is a comment an editor shows
-to somebody who installed it. Write a description as what a field means to a
-caller, never as how the behaviour was found, on which machine, or under which
-internal ticket. `test/published-prose.test.ts` greps the built output and fails
-on German prose, an internal ticket id, a developer machine path or a
-first-name attribution.
+`.meta({ description })` is copied into the JSON Schema and OpenAPI
+artifacts — so a comment written for the people who build this is a comment
+an editor shows to somebody who installed it. Write a description as what a
+field means to a caller, never as how the behaviour was found, on which
+machine, or under which internal ticket. `test/published-prose.test.ts`
+greps the built output and fails on German prose, an internal ticket id, a
+developer machine path or a first-name attribution.
 
 ## Pull requests
 
 **Pull requests are welcome on GitHub**, at
-<https://github.com/fleetless/contracts>. Open an issue first for anything that
-changes an existing shape, so we can say what else has to move with it.
-
-**CI runs on GitLab.** This repository is mirrored from an internal GitLab
-instance, which is where the pipeline that verifies and publishes it lives. You
-will not see a check run on your GitHub pull request; a maintainer runs the
-same checks, and the result comes back as a review comment. Run `pnpm
-typecheck && pnpm test && pnpm artifacts` yourself before you open the pull
-request and you will have seen everything CI would tell you.
+<https://github.com/fleetless/contracts>. Changing an existing shape? Open
+an issue first — so we can say what else has to move with it.
+
+**CI runs on GitHub Actions**, in this repository
+(`.github/workflows/verify.yml`) — the suite, on every push and every pull
+request. `release.yml` publishes on a release tag and calls that same file
+first, so a release is never checked by a different pipeline than a push.
+
+**Your pull request is verified, a fork's included** — the same file, the
+same suite. The first run by a first-time contributor waits for a maintainer
+to press approve on it; that is a button on your run, not a setting anybody
+has to change, so checks sitting idle for a while are the queue and not a
+failure. The run reads code and reaches nothing else: it is granted
+`contents: read`, no secret is exposed to it, and publishing lives in a
+workflow only a tag can trigger.
+
+Run `pnpm typecheck && pnpm build && pnpm test && pnpm artifacts && pnpm run
+test:pack` yourself first and you've seen everything `verify` will tell you.
+Mind `pnpm artifacts`: `artifacts/` is generated *and* committed, and CI
+fails if regenerating it changes a file — so commit whatever it writes
+together with the schema you changed. That is the single most common reason
+a first pull
+request here goes red.
 
 ## The CLA
 
-The first pull request you open will ask you to sign a Contributor Licence
-Agreement. It grants Dehne Robotik GmbH the right to license your contribution
-under terms other than Apache-2.0 in future — that is the whole of what it is
-for, and it is why the project can relicense its own code later without having
-to find every past contributor. It does not take your copyright away and it
-does not stop you from using your own contribution however you like.
+The first pull request you open asks you to sign a Contributor Licence
+Agreement. It grants Dehne Robotik GmbH the right to license your
+contribution under terms other than Apache-2.0 later — that's the whole of
+it, and how the project can relicense without hunting down every past
+contributor. It does not take your copyright away and it does not stop you
+from using your own contribution however you like.
 
 ## Commit messages
 
 [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/):
-`feat:`, `fix:`, `docs:`, `chore:`, `ci:`, `refactor:`, `test:`. A change that
-alters an existing wire shape is a breaking change; say so with a `!` and a
-`BREAKING CHANGE:` footer, because it decides the next version number.
+`feat:`, `fix:`, `docs:`, `chore:`, `ci:`, `refactor:`, `test:`. Altering an
+existing wire shape is a breaking change — say so with a `!` and a
+`BREAKING CHANGE:` footer; it decides the next version number.
 
 Everything in this repository is written in **English** — code, comments,
 commit messages, documentation.
@@ -104,33 +118,44 @@ By participating you agree to the [Code of Conduct](CODE_OF_CONDUCT.md).
 
 ## Releasing (maintainers)
 
-The pipeline publishes, and `npm publish` from a working tree is refused by a
-`prepublishOnly` script — the rule has a mechanism rather than only a sentence.
-(The pipeline is unaffected: it publishes the tarball `verify` packed, and npm
-runs no prepare lifecycle for a tarball argument.)
+The `publish` workflow job publishes, and `npm publish` from a working tree
+is refused by a `prepublishOnly` script — the rule has a mechanism rather
+than only a sentence. (`publish` is unaffected: it publishes the tarball
+`verify` packed, and npm runs no prepare lifecycle for a tarball argument.)
 
-1. Update `CHANGELOG.md` and set the new version in `package.json`. **CI checks
-   both**, in `scripts/verify-version-tag.mjs`: `package.json` must equal the
-   tag without its `v`, and `CHANGELOG.md` must carry a dated heading reading
-   exactly `## [X.Y.Z] — YYYY-MM-DD`. `CHANGELOG.md` ships inside the tarball,
-   so a forgotten entry documents the wrong version to every consumer and npm
-   will not take a version back.
+1. Update `CHANGELOG.md` and set the new version in `package.json`. **CI
+   checks both** (`scripts/verify-version-tag.mjs`): `package.json` must
+   equal the tag without its `v`, and `CHANGELOG.md` needs a dated heading
+   reading exactly `## [X.Y.Z] — YYYY-MM-DD`. `CHANGELOG.md` ships inside
+   the tarball — skip an entry and you've documented the wrong version to
+   every consumer, and npm won't take a version back.
 
    The same script refuses a release tag that would move npm's `latest`
-   backwards — a backported `v1.0.1` published while `latest` is `2.0.0` would
-   make `npm i @fleetless/contracts`, the command the README gives outsiders,
-   install a package a major version behind.
-2. Commit, push, and let the `verify` job go green on the branch.
-3. Tag `vX.Y.Z` (or `vX.Y.Z-beta.N` for a pre-release, which publishes to the
-   `next` dist-tag) and push the tag. The tag pipeline runs `verify` again and
-   then `publish`.
-
-`publish` needs an `NPM_TOKEN` variable, protected and masked. Protected means
-an unprotected ref receives an empty value rather than a missing one, so the
-tag pattern must be protected too; the job names that case before it can fail
-on it obliquely.
-
-**If the publish job goes red after `npm publish` has run, do not press
-retry.** npm refuses to republish a version, so a retry fails with a 403 that
-reads like a broken pipeline rather than like a release that already happened.
-Check `npm view @fleetless/contracts@<version>` first.
+   backwards — a backported `v1.0.1` published while `latest` is `2.0.0`
+   would make `npm i @fleetless/contracts`, the command the README gives
+   outsiders, install a package a major version behind.
+2. Commit, push, and let the `verify` job go green on the branch (the
+   Actions tab).
+3. Tag `vX.Y.Z` (or `vX.Y.Z-beta.N` for a pre-release, which publishes to
+   the `next` dist-tag) and push the tag. The tag run's `verify` job runs
+   again and then `publish`.
+
+`publish` carries no npm token. It authenticates by **trusted publishing**:
+GitHub mints a short-lived credential for the job, npm checks it against the
+trusted publisher configured on npmjs.com for this repository and this
+workflow filename, and npm generates the provenance attestation itself —
+`npm audit signatures` verifies it against this commit and this run. Renaming
+`release.yml` breaks publishing until the publisher is updated on npmjs.com.
+The job refuses a missing credential by name, rather than failing on an opaque
+error from deep inside `npm publish`. There is no repository secret to add and
+no `.npmrc` anywhere.
+
+**If the publish job goes red after `npm publish` already ran, do not press
+retry.** npm refuses to republish a version — the resulting 403 reads like
+a broken run, not like a release that already happened. Check `npm view
+@fleetless/contracts@<version>` first.
+
+Removing a bad tag is an ordinary git operation here — nothing configures
+tag protection, so `git tag -d vX.Y.Z` locally and `git push origin
+:refs/tags/vX.Y.Z` remotely both just work. What that does *not* undo is a
+publish: the tag is retractable, the npm version is not.

package/README.md

@@ -1,24 +1,43 @@
-# `@fleetless/contracts`
+# @fleetless/contracts
 
-The wire contracts for [Fleetless](https://fleetless.dev): every shape the
-Fleetless API accepts or returns, and every message a robot's bridge exchanges
-with the cloud, written once as [zod](https://zod.dev) schemas and exported as
-JSON Schema and OpenAPI.
+[![npm version](https://img.shields.io/npm/v/@fleetless/contracts)](https://www.npmjs.com/package/@fleetless/contracts)
+[![license Apache-2.0](https://img.shields.io/npm/l/@fleetless/contracts)](LICENSE)
 
-Fleetless turns a ROS 2 robot into a REST and realtime API. A developer
-configures which topics, services, actions and cameras a robot exposes; client
-apps consume those over HTTP and WebSocket. This package is the definition of
-what goes over that wire — it is the same file the server validates with, so a
-client built against it cannot disagree with the server about a field name, a
-bound or an error code.
+**Every shape the Fleetless API accepts or returns, and every frame a robot's
+bridge exchanges with the cloud.** Written once as [zod](https://zod.dev)
+schemas, shipped as JSON Schema and OpenAPI.
+
+[Fleetless](https://fleetless.dev) turns a ROS 2 robot into a hosted REST and
+realtime API. This package is the definition of what crosses that wire, and
+it is the same file the server validates with. A client built against it
+cannot disagree with the server about a field name, a bound or an error code.
+
+## 🎯 Who this is for
+
+Most app developers do not need this package.
+[`@fleetless/sdk`](https://www.npmjs.com/package/@fleetless/sdk) is the client
+library and already speaks these shapes. Reach for `@fleetless/contracts` when
+you are building what the SDK does not cover: a server-side integration, a
+client in another language, or a bridge of your own.
+
+## 📦 What is in the box
+
+| Path | What it is |
+|---|---|
+| `dist/` | The zod schemas, their inferred types and the error codes, exported from the package root. |
+| `artifacts/openapi.json` | The OpenAPI 3.1 description of the REST API. |
+| `artifacts/routes.json` | Every route with its request and response schema names, and the notes that explain each one. |
+| `artifacts/schema/*.json` | One JSON Schema per wire shape, as **a receiver validates an incoming document**. |
+| `artifacts/schema-outgoing/*.json` | The twelve frames a bridge **sends**, as the sender must produce them. |
+
+## 🚀 Getting started
 
 ```sh
 npm i @fleetless/contracts
 ```
 
-## TypeScript
-
-Import the schemas and the types inferred from them:
+TypeScript imports the schemas and the types inferred from them, all from the
+package root:
 
 ```ts
 import { robotListResponse, ERROR_CODES } from '@fleetless/contracts'
@@ -27,98 +46,65 @@ import type { RobotListResponse, ErrorCode } from '@fleetless/contracts'
 const robots: RobotListResponse = robotListResponse.parse(await res.json())
 ```
 
-Everything is exported from the package root. There is no deep import for the
-TypeScript surface.
-
-Most application developers do not need this package directly:
-[`@fleetless/sdk`](https://www.npmjs.com/package/@fleetless/sdk) is the client
-library, and it already speaks these shapes. Reach for `@fleetless/contracts`
-when you are writing something the SDK does not cover — a server-side
-integration, your own client, or a validator in another language.
-
-## JSON Schema and OpenAPI
-
-Consumers that are not TypeScript read the generated documents under
-`artifacts/`, which ship inside the published package and are importable by
-path:
+Everything else imports the generated documents by path, no TypeScript
+required:
 
 ```ts
 import routes from '@fleetless/contracts/artifacts/routes.json' with { type: 'json' }
 import openapi from '@fleetless/contracts/artifacts/openapi.json' with { type: 'json' }
 ```
 
-| Path | What it is |
-|---|---|
-| `artifacts/openapi.json` | The OpenAPI 3.1 description of the REST API, generated from the route manifest and the schemas. |
-| `artifacts/routes.json` | Every route with its request and response schema names, and the notes that explain each one. |
-| `artifacts/schema/*.json` | One JSON Schema per wire shape, named after the shape, rendered as **a receiver validates an incoming document**. |
-| `artifacts/schema-outgoing/*.json` | Twelve of those same shapes rendered again as **a sender must produce them** — the frames a robot's bridge sends to the cloud. |
+Two compatibility axes: the package version follows semver over the wire
+shapes, and `zod` is a range rather than a pin because a schema from here must
+be an instance of the one copy of zod in your tree.
 
-The two schema directories are the same shapes in zod's two rendering modes,
-and the difference matters if you are writing a bridge.
+## ↔️ Two schema directories, and which one you want
 
-`artifacts/schema/` is *input* mode: what a receiver accepts. Fleetless
-receivers strip unknown keys rather than refusing them, so these documents omit
-`additionalProperties: false`, and a field with a default is not marked
-required.
+`artifacts/schema/` is what a receiver accepts. Fleetless receivers strip
+unknown keys rather than refuse them, so these documents omit
+`additionalProperties: false`, and a field with a default is not required.
 
-`artifacts/schema-outgoing/` is *output* mode, for the twelve frames a bridge
-**sends**. There a relaxed schema points the wrong way: a misspelled key in an
-outgoing frame would pass an input-mode check and then be silently dropped by
-the server. Validate what you send against `schema-outgoing/`, and what you
-receive against `schema/`.
+`artifacts/schema-outgoing/` is what a sender must produce, for the twelve
+frames a bridge sends to the cloud. Checked against the relaxed schema, a
+misspelled key in an outgoing frame passes and is then silently dropped by the
+server, which is a bug nobody reports because nothing fails.
 
-The artifacts are generated and committed rather than produced at install time
-because a consumer in another language needs them without running a TypeScript
-build.
+So: validate what you **receive** against `schema/`, and what you **send**
+against `schema-outgoing/`. If you are writing a bridge, this paragraph is the
+one to remember.
 
-## Versioning
+## 🔢 Versioning
 
 Semantic versioning over the wire shapes. A change that makes a previously
-valid message invalid — a new required field, a narrowed bound, a removed
-enum member — is a **major**. Adding an optional field, a new enum member a
-client may ignore, or a description is a minor or a patch.
+valid message invalid — a new required field, a narrowed bound, a removed enum
+member — is a major. A new optional field, a new enum member a client may
+ignore, or a better description is a minor or a patch.
 
 Pin an exact version. These shapes describe a running server, and "compatible
 with the server you are talking to" is not something a range can express.
 
-**The one dependency, `zod`, is deliberately a range and not a pin.** zod is a
-peer in everything but name: a consumer that imports both this package and zod
-must get one copy, or a schema from here fails an `instanceof` check against
-their own. An exact pin here forces a second copy on anyone whose lockfile
-resolves a different patch. The range floor is the version these schemas are
-built, tested and exported against, and a zod major is a major here too.
-
-## Documentation
+## 📚 Documentation
 
 The API reference at
-[docs.fleetless.dev/reference/api](https://docs.fleetless.dev/reference/api) is
-generated from these artifacts and is the place to read what a field means.
-This package is the place to read what it *is*.
-
-## Reporting a security issue
-
-Email **security@fleetless.dev**. Please do not open a public issue for a
-security report.
+[docs.fleetless.dev/reference/api](https://docs.fleetless.dev/reference/api)
+is generated from these artifacts. Read it for what a field *means*; this
+package is for what it *is*. [CHANGELOG.md](CHANGELOG.md) lists what moved in
+each version.
 
-**A wrong schema is a security report.** If a schema here accepts a value that
-should never reach a server — an identifier that escapes its own grammar, a
-missing bound, a union that admits a shape the API does not expect — that is a
-vulnerability in this package, even though nothing in it executes anything. So
-is a generated artifact that disagrees with the zod schema it came from, because
-consumers that are not TypeScript validate against the artifact and never see
-the zod.
+## 🔒 Reporting a security issue
 
-`SECURITY.md` ships inside the published package and has the full policy: what
-is in scope, what is not, and the response times we hold ourselves to.
+Email **security@fleetless.dev** rather than opening a public issue. A wrong
+schema is a security report: a bound that is missing, an identifier that
+escapes its own grammar, or a generated artifact that disagrees with the zod
+it came from. [SECURITY.md](SECURITY.md) has the full policy.
 
-## Contributing
+## 🤝 Contributing
 
-`CONTRIBUTING.md` ships inside the published package and has the setup, the
-checks and the pull request process. In short: `pnpm install`, then `pnpm
-typecheck && pnpm test`; every schema change regenerates `artifacts/` with
-`pnpm artifacts` and commits it in the same commit.
+[CONTRIBUTING.md](CONTRIBUTING.md) has the setup, the checks and the pull
+request process. In short: `pnpm install`, then `pnpm typecheck && pnpm test`,
+and every schema change regenerates `artifacts/` with `pnpm artifacts` in the
+same commit.
 
-## Licence
+## 📜 Licence
 
 [Apache-2.0](LICENSE). Copyright 2026 Dehne Robotik GmbH.

package/SECURITY.md

@@ -2,31 +2,31 @@
 
 ## Reporting a vulnerability
 
-Email **security@fleetless.dev**. Please do not open a public GitHub issue for
-a security report.
+Email **security@fleetless.dev**. Do not open a public GitHub issue for a
+security report.
 
-Include what you found, the schema or artifact it concerns, and — if you have
-one — a value that the schema accepts and should not, or rejects and should
-not. A minimal reproduction against a published version of this package is the
-most useful thing you can send.
+Tell us what you found and which schema or artifact it concerns. If you have
+one, include a value the schema wrongly accepts or wrongly rejects. A minimal
+reproduction against a published version of this package is the most useful
+thing you can send.
 
-We acknowledge every report within **3 working days** and follow up with
-either a fix or a written plan within **30 days**. If a report leads to a
-released fix, we credit you by name unless you ask us not to.
+We acknowledge every report within **3 working days** and follow up with a fix
+or a written plan within **30 days**. A released fix credits you by name
+unless you ask us not to.
 
 ## What is in scope
 
-This repository is a schema library. It defines the wire shapes of the
+This repository is a schema library: it defines the wire shapes of the
 Fleetless API and the bridge–cloud protocol as zod schemas, and exports them
 as JSON Schema and OpenAPI documents under `artifacts/`.
 
-**A wrong schema is a security report.** If a schema accepts a value that
-should never reach a server — an identifier that escapes its own grammar, a
-bound that is missing, a union that admits a shape the API does not expect, a
-field that a validator lets through unchecked — that is a vulnerability in
-this package, even though nothing here executes it. The same is true of a
-generated artifact that disagrees with the zod schema it came from, because
-non-TypeScript consumers validate against the artifact and never see the zod.
+**A wrong schema is a security report.** A schema that accepts a value that
+should never reach a server — an identifier escaping its own grammar, a
+missing bound, a union admitting a shape the API does not expect, a field a
+validator lets through unchecked — is a vulnerability in this package, even
+though nothing here executes it. So is a generated artifact that disagrees
+with the zod schema it came from: non-TypeScript consumers validate against
+the artifact and never see the zod.
 
 So, in scope:
 
@@ -40,16 +40,16 @@ So, in scope:
 
 **The Fleetless cloud is not in this repository.** A server that fails to
 enforce a schema, an authentication or authorisation flaw, a rate limit, a
-data leak from an API endpoint — none of those live here, and none of them can
-be fixed by a change to this package. Report them to the same address; say
-which service you were looking at, and we will route it. What we cannot do is
-treat this repository's issue tracker as the place where they are tracked.
+data leak from an API endpoint — none of that lives here, and none of it can
+be fixed by a change to this package. Report it to the same address, say
+which service you were looking at, and we will route it. This repository's
+issue tracker is not where they get tracked.
 
 Also out of scope here: the Fleetless console, the bridge, the SDK, the
 documentation site, and any deployment of Fleetless operated by someone else.
 
 ## Supported versions
 
-The latest published minor of `@fleetless/contracts` receives fixes. Older
-minors do not; a security fix is released as a new patch on the current minor,
-and consumers pin exact versions, so upgrading is the remedy.
+The latest published minor of `@fleetless/contracts` gets fixes. Older minors
+don't — a security fix is released as a new patch on the current minor, and
+since consumers pin exact versions, upgrading is the remedy.