@bensandee/tooling 0.86.1 → 0.87.1

package/README.md

@@ -93,11 +93,11 @@ The generated `ci:check` script defaults to `pnpm check --skip 'docker:*'` since
 
 For `stack: "typescript"` repos, `repo:sync` generates a `lint:types` script (`bst lint:types`, backed by a managed `oxlint-tsgolint` devDependency) and inserts a `lint:types` step into `checks:run` right after `lint`. It runs `oxlint --type-aware` and selects its findings by subtracting a plain `oxlint` run from it -- there is no maintained list of type-aware rule names, so a rule oxlint adds lands the day it ships.
 
-**Two phases, and the tooling's own version carries them.** The **report** phase prints every finding, states plainly that they will block once a later tooling release flips to **enforce**, and exits 0. The flip is one constant in the tooling's source, so it reaches every consumer as an ordinary `@bensandee/tooling` version bump -- no coordinated migration, nothing to remember. `.tooling.json#lint.strictTypeAware` (default `false`) lets a repo opt into blocking during the report phase, ahead of the fleet-wide flip.
+**Findings block.** The step prints every finding and exits 1 when there are any, in every repo. Whether findings block is one constant in the tooling's source, so a change to it reaches every consumer as an ordinary `@bensandee/tooling` version bump.
 
 **The whole default rule set ships, and the tooling excludes nothing.** A repo's own `oxlint.config.ts` is the per-rule control -- turning a rule off there (`"typescript/<rule>": "off"`) is honored by the type-aware run, and since plain `oxlint` ignores type-aware rules entirely, such an entry never weakens `pnpm lint`. In increasing order of bluntness: turn off one rule in `oxlint.config.ts`, or skip the whole step with `.tooling.json#checks.skip: ["lint:types"]`.
 
-A missing `oxlint-tsgolint` binary degrades to a notice at exit 0 in the report phase, and fails only when `lint.strictTypeAware` is set -- a repo that has not armed enforcement should not have CI broken by a platform gap, and a repo that has asked for the gate should not silently lose it.
+A missing `oxlint-tsgolint` binary degrades to a notice at exit 0, and fails only when `.tooling.json#lint.strictTypeAware` (default `false`) is set -- a repo that has not armed it should not have CI broken by a platform gap, and a repo that has asked for the gate should not silently lose it.
 
 ### Custom blocks in workflows
 
@@ -403,7 +403,7 @@ The trimmed record's `packages` map is computed by aggregating files whose path
 
 Docker packages are discovered automatically. Any package with a `Dockerfile` or `docker/Dockerfile` is a Docker package. Image names are derived as `{root-package-name}-{package-name}`, build context defaults to `.` (project root). For single-package repos, `Dockerfile` or `docker/Dockerfile` at the project root is checked.
 
-When Docker packages are present, `repo:sync` generates a publish workflow (`.forgejo/workflows/publish.yml` or `.github/workflows/publish.yml`) triggered via `workflow_dispatch` for manual runs. For the `simple` release strategy, docker publishing is also added as a step in the release workflow so it runs automatically after each release.
+With `publishDocker` set, the release workflow publishes Docker images after each release. To publish by hand, run `bst docker:publish` with the registry credentials. `repo:sync` archives a managed `publish.yml` left by older versions.
 
 #### Overrides