@regardio/dev 2.4.1 → 2.6.0

package/docs/en/tools/releases.md

@@ -1,8 +1,8 @@
 ---
 
 title: "Release Workflow"
-description: "Branch-based release workflow for Regardio packages — main → staging → production, driven by commit-and-tag-version."
-publishedAt: 2026-04-17
+description: "GitLab-flow release workflow for Regardio repos — branches mirror environments, ship tooling drives versioning, CI carries it out."
+publishedAt: 2026-05-07
 language: "en"
 status: "published"
 kind: "guide"
@@ -11,115 +11,92 @@ area: "dev"
 
 # Release Workflow
 
-Branch-based release workflow for Regardio packages. `main` → `staging` → `production`. `commit-and-tag-version` reads conventional commits to determine the version bump; quality gates run locally before any branch promotion. Nothing broken reaches a shared branch.
+Branches mirror environments. `main` is where development happens. `staging` reflects what is deployed to the staging server. `production` reflects what is live. Version bumps happen locally at ship time — CI on `production` carries the result out (publishes to npm or deploys to a server).
 
-## Overview
+## The Three-Branch Model
 
-Branches mirror deployment environments:
+```text
+main  ──── ship:staging ────►  staging  (optional staging server)
+  │
+  └──── ship:production ──►  production  (live / npm)
+                                  │
+                             sync back to staging
+```
+
+| Branch | Contains | CI role |
+|--------|----------|---------|
+| `main` | All committed, tested work | None (Husky runs local gates on commit) |
+| `staging` | Deployed to staging server or preview | Verify + deploy to staging |
+| `production` | Only shipped, versioned releases | Verify + deploy or publish |
+
+**Why version bumps happen locally, not in CI.** Hotfixes start from `production` and must write their version bump back up through `staging` and `main` in one pass. Keeping the bump local means both the normal ship path and the hotfix path behave identically — there is no special case in CI.
+
+## Hotfix Flow
+
+A hotfix is an urgent fix that must go to production immediately, without pulling in unreleased changes from `main`.
 
 ```text
-main → staging (optional) → production
+production ──► hotfix/<name>  (fix here with conventional commits)
+                    │
+                    └──► production ──► staging ──► main
 ```
 
-- **`main`** — active development, always deployable. Version bumps happen at ship time, not per-commit.
-- **`staging`** — optional validation environment. No versioning happens here.
-- **`production`** — versioned, published code only.
+`ship:hotfix start <name>` creates the branch from `production`, not from `main`. This is deliberate: it avoids accidentally shipping work-in-progress that has not yet been reviewed for production.
 
-When `ship-production` runs, it discovers all publishable workspace packages and asks you to assign a bump type — `0` (skip), `1` (patch), `2` (minor), or `3` (major) — to each one individually. Packages you skip are left untouched. It determines the highest bump type across all selected packages and runs `pnpm release:<type>` at the root, which bumps versions, rewrites `CHANGELOG.md`, and commits on `main`. If no release script exists (non-publishing repos like channels), versioning is skipped entirely and only the git merges happen. The branches merge once after all bumps are applied. CI on `production` publishes only the packages whose version changed.
+`ship:hotfix finish` versions the fix, merges it into `production`, then propagates through `staging` and back to `main` so nothing is lost.
 
-## How It Works
+## Commands
 
-### Design principles
+| Command | Purpose |
+|---------|---------|
+| `pnpm ship:staging` | Fast-forward `main` → `staging`, push. Triggers staging CI. |
+| `pnpm ship:production` | Version selected packages (if any), fast-forward `main` → `production`, sync `staging`. Triggers production CI. |
+| `pnpm ship:hotfix start <name>` | Create `hotfix/<name>` from `production`. |
+| `pnpm ship:hotfix finish` | Version selected packages (if any), merge hotfix → `production` → `staging` → `main`. |
 
-1. **Branches mirror environments.** `staging` reflects what is deployed to the staging server (when used); `production` always reflects what is published to npm. There is never ambiguity about what is running where.
-2. **You choose the bump per package at ship time.** When running `ship-production` or `ship-hotfix finish`, every publishable package is listed and you assign it `0` (skip), `1` (patch), `2` (minor), or `3` (major). Packages you skip are untouched. The conventional commits in the log inform each choice; the decisions are always explicit.
-3. **Version numbers are a production guarantee.** Bumps are applied only at `ship-production` time. Every version tag in git and every release on npm corresponds to code that has been validated and shipped.
-4. **Staging is optional.** You can ship directly from `main` to `production`. Use `ship-staging` when you want to test changes in a staging environment first.
-5. **Tests are a local gate, not a CI gate.** Quality checks (`lint`, `typecheck`, `test`) run on your machine before any commit is made. Broken code cannot enter the repository.
-6. **You always land back on `main`.** Every command returns you to `main` when it finishes.
+## Versioning — Per-Package, at Ship Time
 
-### Full flow diagram
+`ship:production` and `ship:hotfix finish` discover all workspace packages that have a `.versionrc.json` and ask you to assign a bump type to each:
 
-```text
-                ship-staging (OPTIONAL)
-                ┌──────────────────────────┐
-main ───────────┤ quality checks pass      ├──► staging (pushed)
-                │ ff-merge main → staging  │
-                └──────────────────────────┘
-                            │
-                   (validated in staging)
-                            │
-                            ▼
-                ship-production
-                ┌──────────────────────────┐
-                │ quality checks on main   │
-                │ select packages/bumps    │
-                │ pnpm release:<type>*      │
-main ───────────┤ bumps version +          ├──► production
-                │ rewrites CHANGELOG.md    │
-                │ ff-merge main → prod     │
-                │ ff-merge prod → staging  │
-                │ push --follow-tags main  │
-                └──────────────────────────┘
-                            │
-                   (CI: pnpm -r publish → npm)
-                            ▼
-                       production
-
-
-                ship-hotfix start fix-name
-                ┌──────────────────────────┐
-production ─────┤ create hotfix/fix-name   ├──► hotfix/fix-name
-                └──────────────────────────┘
-                            │
-                   (author fixes with conventional commits)
-                            │
-                ship-hotfix finish
-                ┌──────────────────────────┐
-                │ quality checks           │
-                │ pnpm release:<type>*      │
-hotfix/fix-name ┤ bumps version +          ├──► production → staging → main
-                │ rewrites CHANGELOG.md    │
-                │ merge to production      │
-                │ propagate to staging     │
-                │ propagate to main        │
-                └──────────────────────────┘
-```
+- `0` — skip (no version change)
+- `1` — patch
+- `2` — minor
+- `3` — major
 
-### What each branch represents at any point in time
+For each selected package, `commit-and-tag-version` runs from within that package's directory, reading the package's own `.versionrc.json`. It bumps the `version` field in `package.json`, rewrites `CHANGELOG.md` to include only commits that touched files under that package's directory (`gitRawCommitsOpts.path: "."`), commits the bump, and creates a scoped tag (e.g. `@regardio/dev@v1.2.0`).
 
-| Branch | Contains | Version bumped? |
-|--------|----------|-----------------|
-| `main` | All committed, tested work | Only after `ship-production` / `ship-hotfix finish` |
-| `staging` | Synced from `production` after each ship, or from `main` via `ship-staging` | After a ship propagates |
-| `production` | Only shipped, versioned releases | Yes — always |
+If no packages have a `.versionrc.json`, the versioning UI is skipped and `ship:production` proceeds directly to the git merge.
 
-### CI role
+## CI — What Happens on Each Branch
 
-CI is intentionally minimal. On push to `production` it:
+CI behaviour differs by what the repo produces.
 
-1. Installs dependencies and builds
-2. Runs `pnpm -r publish --access public --no-git-checks` — publishes every workspace package whose current version is not yet on npm, skipping `private: true` packages
-3. Tags are already present (pushed by `ship-production` via `--follow-tags`)
+### Publishing monorepos
 
-## Commands
+- **staging**: Run typecheck and tests. Nothing is published.
+- **production**: Run typecheck, tests, then `pnpm -r publish --access public --no-git-checks`. Only packages whose current version is not yet on npm are published — packages with `"private": true` are skipped automatically.
 
-| Command | Usage | Purpose |
-|---------|-------|---------|
-| `pnpm release` | auto | Bump version from conventional commits, update CHANGELOG.md, commit |
-| `pnpm release:patch` | explicit | Force a patch bump |
-| `pnpm release:minor` | explicit | Force a minor bump |
-| `pnpm release:major` | explicit | Force a major bump |
-| `ship-staging` | `ship-staging` | (Optional) Deploy changes to staging for testing |
-| `ship-production` | `ship-production` | Bump version, merge main → production, trigger publish |
-| `ship-hotfix start <name>` | `ship-hotfix start <name>` | Create a hotfix branch from production |
-| `ship-hotfix finish` | `ship-hotfix finish` | Bump version, propagate hotfix through production → staging → main |
+### Server-deployed apps with Docker
 
-## Typical Release Flow
+- **staging**: Run tests, build the Docker image, push to the container registry, trigger a staging deploy (e.g. Coolify webhook).
+- **production**: Run typecheck + tests, build and push the Docker image, trigger a production deploy.
+
+### Cloudflare Workers apps
+
+- **staging**: Run tests, then `wrangler versions upload --preview-alias preview`.
+- **production**: Run typecheck + tests, then `wrangler deploy`.
+
+### Documentation / vocabulary repos
 
-### 1. Develop with conventional commits
+- **staging** and **production**: Verify the repo is well-formed (build, typecheck, test). No publishing or deployment — the repo is distributed via git clone, not npm.
 
-On `main`, use conventional commits so the bump type is inferred automatically:
+### Static sites without a configured deployment
+
+- **staging** and **production**: Run tests, typecheck (production only), and build. A deployment step is left as a TODO until the hosting platform is chosen.
+
+## Typical Release Flow
+
+### 1. Develop on `main` with conventional commits
 
 ```bash
 feat: add user authentication       # → minor bump
@@ -127,111 +104,111 @@ fix: resolve login redirect loop    # → patch bump
 feat!: redesign authentication API  # → major bump
 ```
 
-### 2. Ship to production
+### 2. (Optional) Test in staging first
 
 ```bash
-pnpm ship:production
+pnpm ship:staging
 ```
 
-This will:
-
-1. Guard: must be on `main`, working tree clean
-2. Fetch and verify `staging` + `production` branches exist
-3. Show commits to be shipped
-4. Run full quality suite on `main` — aborts on failure
-5. For each publishable package: choose `0 (skip) / 1 (patch) / 2 (minor) / 3 (major)`
-6. Confirm the planned bumps — abort if declined or all skipped
-7. Run `pnpm release:<type>` at the root (highest bump type) — bumps versions, rewrites `CHANGELOG.md`, commits. If no release script exists, skip versioning.
-8. Fast-forward merge `main` into `production` and push
-9. Sync `staging` with `production`
-10. Push `main` with `--follow-tags` to push all new version tags
-11. Return to `main`
-
-CI on `production` runs `pnpm -r publish` to push changed packages to npm.
+Deploys `main` to `staging` without touching versions.
 
-### Option: Test in staging first
+### 3. Ship to production
 
 ```bash
-pnpm ship:staging
+pnpm ship:production
 ```
 
-Deploys `main` to `staging` without touching versions. Useful for validating in a staging environment before shipping to production.
+1. Guard: must be on `main`, working tree clean.
+2. Fetch and verify `staging` and `production` branches exist.
+3. Show commits to be shipped.
+4. Run full quality suite — aborts on failure.
+5. If packages have `.versionrc.json`: assign a bump type to each; confirm the planned bumps.
+6. If no packages have `.versionrc.json`: confirm whether to ship (versioning is skipped).
+7. For each selected package: run `commit-and-tag-version --release-as <type>` from within the package directory.
+8. Fast-forward merge `main` → `production`, push.
+9. Sync `staging` with `production`, push.
+10. Push `main` with `--follow-tags` to carry the new version tags.
+11. Return to `main`.
 
-## Hotfix Flow
-
-For urgent fixes that must go directly to production:
+### 4. Hotfix flow
 
 ```bash
 pnpm ship:hotfix start fix-auth-bug
-# apply your fix with conventional commits
+# apply fix with conventional commits
 git add . && git commit -m "fix: ..."
 pnpm ship:hotfix finish
 ```
 
-`finish` asks you to assign a bump type (`0` (skip), `1` (patch), `2` (minor), or `3` (major)) to each publishable package, runs `pnpm release:<type>` at the root (highest bump type) to bump versions and update `CHANGELOG.md`. If no release script exists, versioning is skipped. Then it merges `hotfix → production → staging → main` and deletes the hotfix branch. CI publishes from `production`.
+`finish` fetches origin, runs quality checks, assigns bump types (for packages with `.versionrc.json`), versions the fix, then merges `hotfix → production → staging → main` and deletes the hotfix branch.
 
 ## Adoption
 
-Install `@regardio/dev` and:
+### 1. Add ship scripts to `package.json`
+
+```json
+{
+  "scripts": {
+    "ship:hotfix": "ship-hotfix",
+    "ship:production": "ship-production",
+    "ship:staging": "ship-staging"
+  }
+}
+```
+
+### 2. Add `.versionrc.json` to each package you want versioned
 
-1. **Add the scripts to `package.json`** (optional, for publishing repos):
+```bash
+cp node_modules/@regardio/dev/templates/versionrc/.versionrc.json packages/my-pkg/.versionrc.json
+```
 
-   For repos that publish to npm, add release scripts to the root `package.json`:
+Then replace both `@my-scope/my-pkg` placeholders in that file with your actual package name:
 
-   ```json
-   {
-     "scripts": {
-       "release": "commit-and-tag-version",
-       "release:major": "commit-and-tag-version --release-as major",
-       "release:minor": "commit-and-tag-version --release-as minor",
-       "release:patch": "commit-and-tag-version --release-as patch",
-       "ship:hotfix": "ship-hotfix",
-       "ship:production": "ship-production",
-       "ship:staging": "ship-staging"
-     }
-   }
-   ```
+```json
+{
+  "tagPrefix": "@my-scope/my-pkg@v",
+  "releaseCommitMessageFormat": "chore(release): @my-scope/my-pkg@v{{currentTag}}"
+}
+```
 
-   For non-publishing repos (e.g., channels that deploy to servers), omit the release scripts — the ship commands will skip versioning and only perform the git merges. This makes the tools reusable across both publishing and non-publishing repositories.
+`tagPrefix` scopes the git tag to the package. `releaseCommitMessageFormat` puts the full package identifier in the release commit subject, so the monorepo history reads `chore(release): @my-scope/my-pkg@v1.2.0` rather than a bare version number.
 
-2. **Add a `.versionrc.json` to each publishable package** with a scoped `tagPrefix` so tags and changelogs stay isolated per package:
+Every `.versionrc.json` must include `"gitRawCommitsOpts": { "path": "." }` to filter the git log to commits that actually touched files under that package's directory. Without this, the changelog accumulates noise from unrelated packages.
 
-   ```bash
-   cp node_modules/@regardio/dev/templates/versionrc/.versionrc.json packages/my-pkg/.versionrc.json
-   # then set "tagPrefix": "@my-scope/my-pkg@v" inside that file
-   ```
+For a single-package repo, place `.versionrc.json` at the root instead.
 
-   For a single-package repo, put `.versionrc.json` at the root instead.
+### 3. Create the branches
+
+```bash
+git checkout -b staging && git push -u origin staging
+git checkout -b production && git push -u origin production
+git checkout main
+```
 
-3. **Create the branches**:
+### 4. Copy and adapt the CI workflow
 
-   ```bash
-   git checkout -b staging && git push -u origin staging
-   git checkout -b production && git push -u origin production
-   git checkout main
-   ```
+```bash
+# Forgejo / Codeberg
+mkdir -p .forgejo/workflows
+cp node_modules/@regardio/dev/templates/actions/forgejo-release.yml .forgejo/workflows/release.yml
 
-4. **Copy the release workflow** for your forge:
+# GitHub
+mkdir -p .github/workflows
+cp node_modules/@regardio/dev/templates/actions/github-release.yml .github/workflows/release.yml
+```
 
-   ```bash
-   # GitHub
-   mkdir -p .github/workflows
-   cp node_modules/@regardio/dev/templates/github/release.yml .github/workflows/release.yml
+Both templates cover the npm-publishing case. Adapt the publish job for Docker / Cloudflare deployments as described in the CI section above.
 
-   # Forgejo / Codeberg
-   mkdir -p .forgejo/workflows
-   cp node_modules/@regardio/dev/templates/github/release.yml .forgejo/workflows/release.yml
-   ```
+### 5. First publish of any new package must be done locally
 
-5. **First publish of any new package must be done locally**:
+```bash
+pnpm build && npm publish --access public
+```
 
-   ```bash
-   pnpm build && npm publish --access public
-   ```
+CI publishes subsequent versions; the very first one requires a local publish because the package does not yet exist on npm.
 
 ## Quality Gates
 
-Every ship command enforces the same gates — no broken code reaches any environment:
+Every ship command enforces the same gates before any commit or merge:
 
 ```bash
 pnpm build      # Must succeed
@@ -239,11 +216,11 @@ pnpm typecheck  # Must succeed
 pnpm test       # Must succeed
 ```
 
-## Private Packages and Non-Publishing Repos
+## Publishing vs Non-Publishing Repos
 
-Packages that should never be published to npm must set `"private": true` in `package.json`. `pnpm -r publish` skips them automatically.
+Packages with `"private": true` are skipped by `pnpm -r publish` automatically — CI only publishes public packages to npm.
 
-For non-publishing repos (e.g., channels that deploy directly to servers instead of npm), omit the `release:*` scripts from `package.json`. The ship tools will skip versioning entirely and only perform the git merges. CI can then handle deployment to servers based on the `production` branch.
+Whether a package is published to npm is independent of whether it gets versioned. The ship tooling uses `.versionrc.json` presence as the signal for versioning, not the `private` flag. A private channel app or a vocabulary repo can run `ship:production`, get a version bump, a CHANGELOG entry, and a scoped git tag, without ever touching npm.
 
 ## Related
 

package/docs/en/tools/vitest.md

@@ -65,7 +65,7 @@ export default defineConfig({ test: vitestReactConfig });
 ```json
 {
   "scripts": {
-    "test": "exec-s test:*",
+    "test": "vitest run",
     "test:unit": "vitest run",
     "report": "vitest run --coverage"
   }

package/docs/en/writing.md

@@ -0,0 +1,118 @@
+---
+
+title: "Writing"
+description: "Voice, tone, and language Regardio content carries, in English and German."
+publishedAt: 2026-04-17
+order: 2
+language: "en"
+status: "published"
+kind: "concept"
+---
+
+The voice in which Regardio writes about itself and its tools.
+
+## What you are doing
+
+You write *from within* the System, not *about* it. Your aim is to trigger recognition. The reader you are writing for should be able to think *Yes, that's how it is.*
+
+Two trains of thought carry everything the System does — and everything you write about it.
+
+**Any one object can be observed from two sides.** Front and back, inside and outside, past and future, still and moving, question and answer, start and finish. A thing that looks complete from one angle shows something new from the other. Writing that only shows one side flattens what it describes. Writing that acknowledges both gives the reader room to stand where they already stand.
+
+**A whole becomes graspable when it is cut into a few distinct parts.** Six is the number to return to: enough variety to cover what matters, few enough to hold in the head at once, clear enough to name and locate each piece. A pie cut into six slices is something anyone can picture. When a subject resists clarity, the move is not more words — it is better cuts.
+
+These two habits are the grammar underneath the System. Carry them quietly. You rarely name them. They are just the shape of the thinking.
+
+## How to meet the reader
+
+Every reader comes with their own life and their own pursuit. Assume they notice things for themselves. Trust them to do their own connecting. Address them directly, without talking up or down.
+
+The ground under the writing is careful observation of how people actually feel, think, and act — not advice about how they should. When an idea becomes personally recognizable while staying broadly true, it has landed. When it only flatters or only instructs, it hasn't.
+
+## Stance
+
+Six movements carry every piece.
+
+1. **Derive, don't declare.** One thought leads to the next. "The System recognizes…" speaks from above. Better: the observation that leads to the structure. Readers follow a line of thought, not an instruction.
+2. **Observe, don't instruct.** Write like someone who has listened carefully and is sharing an observation, not like someone explaining a method.
+3. **Structure offers freedom, not rules.** The cuts exist to widen a view that has become too narrow, not to discipline one that is already broad.
+4. **Suggest possibilities to choose from.** Offer angles, not answers. Let the reader decide what fits. Suggest questions that people have, not riddles to solve.
+5. **Turned toward what could be, without promises.** Warm, attentive, spacious. Curious about people rather than diagnostic. No salvation talk, no coaching register.
+6. **Good humor makes the deepest thought approachable.** Lightness when it fits. Not forced, not absent. When the moment is right, a small wink can carry weight without claiming it.
+
+## Before and after
+
+**Instead of:** *"Apply this framework to align your team."*
+**Try:** *"What does the decision we made last week have to do with what's slowing us down now?"*
+
+**Instead of:** *"The System helps you gain clarity."*
+**Try:** *"A few angles worth looking at, whatever the pursuit."*
+
+**Instead of:** *"Pursuits flourish with a clear core."*
+**Try:** *"How will we know when we've arrived?"*
+
+The System's questions are not headers. They are real questions, worth sitting with.
+
+## Language
+
+Language that leaves room lets readers think. Language that pushes does the thinking for them. Given the choice, choose room.
+
+**Favor:** notice, explore, find, might, could, pattern, rhythm, carry, hold — words that leave room.
+
+**Avoid:** must, potential, resources, values, purpose, sustainability, growth, leverage, empower, ownership, good, bad. These either push or have been worn down to noise.
+
+**No method jargon.** Not from business, not from coaching, not from therapy, not from spirituality. If a term has a clear everyday word behind it, use the everyday word.
+
+**People are not categories.** Describe what people do and bring about, not what they are. This is also how gendered forms are handled — name actions, not groups.
+
+**The System is humane.** Equal, free cooperation is built in. Avoid connotations of hierarchy, ownership, dominance, control, or force. Reflect that without announcing it.
+
+**Complexity earns its place or goes.** Make hard ideas reachable without flattening them. If a sentence has to be read twice, shorten it. If an idea has been reduced past recognition, let it breathe again.
+
+## System terms
+
+System terms carry precisely defined concepts. Use them as they are; don't swap in synonyms for variety. When tempted to reach for a buzzword, reach for a System term instead — if it fits. If no System term fits, the buzzword probably isn't earning its place either.
+
+In every language the System is written in, the terms are chosen to capture the spirit of each concept in that language — not to translate literally from another. Don't import words from other languages into the prose. Let each language stand on its own.
+
+## Roots, kept in the background
+
+The System draws from many traditions of thought. Reference intents and ideas, not names or schools. The sources show themselves in the structure, not in citation. This is working craft carried by collective intelligence, not an elaborate treatise.
+
+## Format and craft
+
+**Headers** for orientation. **Prose** for connected thought. **Bold** for System terms at first introduction. *Italics* for genuine emphasis. No emojis. Lists only when the content is genuinely a list — bullets never replace a thought.
+
+## Language-specific caveats
+
+### German
+
+- Address the reader with *du* unless the context clearly calls for *Sie* (formal contracts, legal notices). Keep it direct, without affectation.
+- No gendering artifacts: no *:innen*, no asterisks, no *(m/w/d)*. Prefer action-based descriptions over group labels: *wer etwas vorhat*, *ein Mensch, der …*, *die Person, die …*, *Mitwirkende*, *Beteiligte*.
+- Quotation marks: German low-high („…") in body text.
+
+### English
+
+- American English: *organize*, *color*, *toward*, *behavior*, *center*. Periods and commas inside quotation marks.
+- No gendered forms. Name actions: *the person pursuing this*, *contributors*, *those involved*. Singular *they* is fine where a pronoun is unavoidable.
+- Quotation marks: straight double quotes (") in Markdown source; typographic quotes ("…") in rendered prose.
+
+## Check before publishing
+
+- Does it sound like a conversation the reader would want to be in?
+- Does the text derive rather than declare?
+- Are abstract thoughts grounded in concrete examples?
+- Are System terms used consistently, in their precise meaning?
+- Is it free of coaching register, pigeonholing, and tired buzzwords?
+- Could the honest response be *"Yes, that's how it is"*?
+
+*This guide is itself a living text. When in doubt: would you enjoy reading this?*
+
+## Related
+
+- [Documentation](./documentation.md) — How Regardio shapes its documents
+- [Principles](./principles.md) — Shared principles
+
+---
+
+**License**: [CC-BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) © Regardio

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://www.schemastore.org/package.json",
   "name": "@regardio/dev",
-  "version": "2.4.1",
+  "version": "2.6.0",
   "private": false,
   "description": "Regardio development presets: biome, typescript, commitlint, markdownlint, vitest, playwright, sqlfluff, husky, and GitLab-flow ship tooling",
   "keywords": [
@@ -74,7 +74,7 @@
   ],
   "devDependencies": {
     "@total-typescript/ts-reset": "0.6.1",
-    "@types/node": "25.6.0",
+    "@types/node": "25.6.2",
     "@vitest/coverage-v8": "4.1.5",
     "tsdown": "0.22.0",
     "vitest": "4.1.5"
@@ -101,7 +101,7 @@
     "fix:biome": "biome check --write --unsafe .",
     "fix:md": "markdownlint-cli2 --config ../../.markdownlint-cli2.jsonc --fix",
     "fix:pkg": "sort-package-json",
-    "lint": "run-s lint:md lint:biome",
+    "lint": "run-p lint:*",
     "lint:biome": "biome check .",
     "lint:md": "markdownlint-cli2 --config ../../.markdownlint-cli2.jsonc",
     "lint:pkg": "sort-package-json --check",