@regardio/dev 2.4.1 → 2.6.0

package/README.md

@@ -47,7 +47,7 @@ Extend the shared configs:
 
 ## Documentation
 
-Documentation sits alongside the code, organised by topic. Cross-project standards — principles, writing voice, documentation shape — live outside this package at [`commons/docs/en/`](../../docs/en/README.md), since they apply well beyond TypeScript.
+Documentation sits alongside the code in `docs/en/`, organised by topic. It covers cross-project principles and writing standards as well as code-level standards and toolchain configuration.
 
 ### Code standards
 

package/dist/bin/ship/hotfix.bin.mjs

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-import { a as git, c as runScript, i as getWorkspacePackages, n as chooseForEach, o as gitRead, s as runQualityChecks, t as branchExists } from "./utils-rnvdLrkF.mjs";
+import { a as git, c as runQualityChecks, i as getWorkspacePackages, n as chooseForEach, o as gitRead, s as runPackageRelease, t as branchExists } from "./utils-sL-BT4MX.mjs";
 //#region src/bin/ship/hotfix.ts
 /**
 * ship-hotfix: Manage hotfix branches based on production code.
@@ -52,6 +52,8 @@ function runShipHotfix(subcommand, subArgs, cwd = process.cwd()) {
 			console.error("Working directory has uncommitted changes. Commit or stash them first.");
 			process.exit(1);
 		}
+		console.log("\nFetching latest state from origin...");
+		git("fetch", "origin");
 		console.log("\nRunning quality checks...");
 		try {
 			runQualityChecks();
@@ -61,27 +63,21 @@ function runShipHotfix(subcommand, subArgs, cwd = process.cwd()) {
 		}
 		console.log("✅ Quality checks passed");
 		const packages = getWorkspacePackages(cwd);
-		if (packages.length === 0) {
-			console.error("No publishable workspace packages found.");
-			process.exit(1);
-		}
-		console.log("\nSelect a version bump for each package (or skip):");
-		const bumps = chooseForEach(packages);
-		if (bumps.length === 0) {
-			console.log("\nNo packages selected for release. Aborted.");
-			process.exit(0);
-		}
-		console.log("\nBumping versions and updating CHANGELOGs...");
-		const hasMajor = bumps.some((b) => b.bump === "major");
-		const hasMinor = bumps.some((b) => b.bump === "minor");
-		const highestBump = hasMajor ? "major" : hasMinor ? "minor" : "patch";
-		try {
-			runScript(`release:${highestBump}`);
-		} catch {
-			console.log("No release script found - skipping versioning (non-publishing repo)");
-		}
-		console.log("\nFetching latest state from origin...");
-		git("fetch", "origin");
+		const bumps = [];
+		if (packages.length > 0) {
+			console.log("\nSelect a version bump for each package (or skip):");
+			bumps.push(...chooseForEach(packages));
+			if (bumps.length === 0) {
+				console.log("\nNo packages selected for release. Aborted.");
+				process.exit(0);
+			}
+			console.log("\nBumping versions and updating CHANGELOGs...");
+			for (const { package: pkg, bump } of bumps) try {
+				runPackageRelease(pkg.path, bump);
+			} catch {
+				console.log(`No versioning configured for ${pkg.name} — skipping.`);
+			}
+		} else console.log("No packages configured for versioning — skipping.");
 		console.log("\nMerging hotfix into production...");
 		git("checkout", "production");
 		git("pull", "--ff-only", "origin", "production");
@@ -101,9 +97,11 @@ function runShipHotfix(subcommand, subArgs, cwd = process.cwd()) {
 		try {
 			git("push", "origin", "--delete", currentBranch);
 		} catch {}
-		const shipped = bumps.map((b) => b.package.name).join(", ");
-		console.log(`\n✅ Hotfix ${shipped} shipped to production → staging → main`);
-		console.log("CI will publish changed packages to npm.");
+		if (bumps.length > 0) {
+			const shipped = bumps.map((b) => b.package.name).join(", ");
+			console.log(`\n✅ Hotfix ${shipped} shipped to production → staging → main.`);
+			console.log("CI will handle the rest.");
+		} else console.log("\n✅ Hotfix shipped to production → staging → main.");
 		console.log("You are on main and ready to keep working.");
 		process.exit(0);
 	}

package/dist/bin/ship/production.bin.mjs

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-import { a as git, c as runScript, i as getWorkspacePackages, n as chooseForEach, o as gitRead, r as confirm, s as runQualityChecks, t as branchExists } from "./utils-rnvdLrkF.mjs";
+import { a as git, c as runQualityChecks, i as getWorkspacePackages, n as chooseForEach, o as gitRead, r as confirm, s as runPackageRelease, t as branchExists } from "./utils-sL-BT4MX.mjs";
 //#region src/bin/ship/production.ts
 /**
 * ship-production: Promote main to production following the GitLab workflow.
@@ -51,29 +51,25 @@ function runShipProduction(cwd = process.cwd()) {
 	}
 	console.log("✅ Quality checks passed");
 	const packages = getWorkspacePackages(cwd);
-	if (packages.length === 0) {
-		console.error("No publishable workspace packages found.");
-		process.exit(1);
-	}
-	console.log("\nSelect a version bump for each package (or skip):");
-	const bumps = chooseForEach(packages);
-	if (bumps.length === 0) {
-		console.log("\nNo packages selected for release. Aborted.");
-		process.exit(0);
-	}
-	if (!confirm(`\nShip to production?\n${bumps.map((b) => `  ${b.package.name}  →  ${b.bump}`).join("\n")}\n`)) {
-		console.log("Aborted.");
-		process.exit(0);
-	}
-	console.log("\nBumping versions and updating CHANGELOGs...");
-	const hasMajor = bumps.some((b) => b.bump === "major");
-	const hasMinor = bumps.some((b) => b.bump === "minor");
-	const highestBump = hasMajor ? "major" : hasMinor ? "minor" : "patch";
-	try {
-		runScript(`release:${highestBump}`);
-	} catch {
-		console.log("No release script found - skipping versioning (non-publishing repo)");
-	}
+	const bumps = [];
+	if (packages.length > 0) {
+		console.log("\nSelect a version bump for each package (or skip):");
+		bumps.push(...chooseForEach(packages));
+		if (bumps.length === 0) {
+			console.log("\nNo packages selected for release. Aborted.");
+			process.exit(0);
+		}
+		if (!confirm(`\nShip to production?\n${bumps.map((b) => `  ${b.package.name}  →  ${b.bump}`).join("\n")}\n`)) {
+			console.log("Aborted.");
+			process.exit(0);
+		}
+		console.log("\nBumping versions and updating CHANGELOGs...");
+		for (const { package: pkg, bump } of bumps) try {
+			runPackageRelease(pkg.path, bump);
+		} catch {
+			console.log(`No versioning configured for ${pkg.name} — skipping.`);
+		}
+	} else if (!confirm("\nNo packages configured for versioning — ship commits to production?\n")) process.exit(0);
 	console.log("\nMerging main into production...");
 	git("checkout", "production");
 	git("pull", "--ff-only", "origin", "production");
@@ -86,8 +82,10 @@ function runShipProduction(cwd = process.cwd()) {
 	git("push", "origin", "staging");
 	git("checkout", "main");
 	git("push", "--follow-tags", "origin", "main");
-	const shipped = bumps.map((b) => b.package.name).join(", ");
-	console.log(`\n✅ Shipped ${shipped} to production. CI will publish changed packages to npm.`);
+	if (bumps.length > 0) {
+		const shipped = bumps.map((b) => b.package.name).join(", ");
+		console.log(`\n✅ Shipped ${shipped} to production. CI will handle the rest.`);
+	} else console.log("\n✅ Commits shipped to production.");
 	console.log("You are on main and ready to keep working.");
 }
 //#endregion

package/dist/bin/ship/staging.bin.mjs

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-import { a as git, o as gitRead, s as runQualityChecks, t as branchExists } from "./utils-rnvdLrkF.mjs";
+import { a as git, c as runQualityChecks, o as gitRead, t as branchExists } from "./utils-sL-BT4MX.mjs";
 import { existsSync, readFileSync } from "node:fs";
 import { join } from "node:path";
 //#region src/bin/ship/staging.ts

package/dist/bin/ship/{utils-rnvdLrkF.mjs → utils-sL-BT4MX.mjs}

@@ -1,6 +1,7 @@
 #!/usr/bin/env node
 import { execFileSync, execSync } from "node:child_process";
-import { closeSync, openSync, readSync } from "node:fs";
+import { closeSync, existsSync, openSync, readSync } from "node:fs";
+import { join } from "node:path";
 //#region src/bin/ship/utils.ts
 /**
 * Shared utilities for ship-staging, ship-production, and ship-hotfix.
@@ -19,6 +20,13 @@ const runScript = (script) => {
 	console.log(`$ pnpm ${script}`);
 	execSync(`pnpm ${script}`, { stdio: "inherit" });
 };
+const runPackageRelease = (pkgPath, bump) => {
+	console.log(`$ commit-and-tag-version --release-as ${bump}`);
+	execSync(`pnpm exec commit-and-tag-version --release-as ${bump}`, {
+		cwd: pkgPath,
+		stdio: "inherit"
+	});
+};
 const runQualityChecks = () => {
 	runScript("lint");
 	runScript("typecheck");
@@ -35,7 +43,7 @@ const getWorkspacePackages = (cwd = process.cwd()) => {
 		cwd,
 		encoding: "utf-8"
 	});
-	return JSON.parse(raw).filter((p) => p.private !== true && p.name !== void 0).map(({ name, path }) => ({
+	return JSON.parse(raw).filter((p) => p.name !== void 0 && existsSync(join(p.path, ".versionrc.json"))).map(({ name, path }) => ({
 		name,
 		path
 	}));
@@ -120,4 +128,4 @@ const choose = (prompt, options, ttyPath = "/dev/tty") => {
 	return chosen.value;
 };
 //#endregion
-export { git as a, runScript as c, getWorkspacePackages as i, chooseForEach as n, gitRead as o, confirm as r, runQualityChecks as s, branchExists as t };
+export { git as a, runQualityChecks as c, getWorkspacePackages as i, chooseForEach as n, gitRead as o, confirm as r, runPackageRelease as s, branchExists as t };

package/docs/en/README.md

@@ -1,7 +1,7 @@
 ---
 
 title: "@regardio/dev Documentation"
-description: "Index for the @regardio/dev toolchain — code-level standards and the tools that enforce them."
+description: "Index for the @regardio/dev toolchain — principles, code-level standards, and the tools that enforce them."
 publishedAt: 2026-04-17
 language: "en"
 status: "published"
@@ -9,9 +9,17 @@ status: "published"
 
 # Documentation
 
-Index for the `@regardio/dev` toolchain.
+Index for the `@regardio/dev` toolchain. All Regardio standards ship with this package and are available at `node_modules/@regardio/dev/docs/en/` after install.
 
-Cross-project standards — voice, documentation shape, principles — live at the commons root in [`docs/en/`](../../../../docs/en/README.md). The documents below are the code-level standards and the tools that enforce them.
+## Principles & writing
+
+Cross-project standards that carry across every Regardio codebase, regardless of language or framework:
+
+| Document | Description |
+|----------|-------------|
+| [Principles](./principles.md) | Code quality, architecture, security, maintainability, collaboration, implementation workflow |
+| [Writing](./writing.md) | Voice, tone, and language — English and German |
+| [Documentation](./documentation.md) | Shape of documents, frontmatter, cross-references, tense and stance |
 
 ## Code standards
 

package/docs/en/documentation.md

@@ -0,0 +1,170 @@
+---
+
+title: "Documentation"
+description: "How Regardio shapes its documents — a thin shared surface with room for each document to take the form its content asks for."
+publishedAt: 2026-04-17
+order: 1
+language: "en"
+status: "published"
+---
+
+## Context
+
+A Regardio document is read for answers about the system, for judgement about what the project does and why, and as the specification its tests are measured against. These readings do not all need the same shape on every page. An architectural decision reads best as a short chain of reasoning — context, alternatives, what was chosen and why. A naming reference reads best as a catalogue. A quick introduction to a tool reads best as a few paragraphs and a short example. Forcing every document into one template serves the template rather than the content, and what the reader comes away with is ceremony instead of understanding.
+
+What the documentation needs is enough predictability for tooling to rely on — a consistent frontmatter, a recognisable title, a place to find related reading — and enough freedom for each document to take the shape its content asks for.
+
+## Decision
+
+Every Regardio document carries a small shared surface. Underneath, it takes whichever of a few shapes fits the content it carries.
+
+### Shared surface
+
+Every document has the same top:
+
+- **Frontmatter** that identifies the document and lets tooling index it
+- **A title** as a heading or implicit from frontmatter
+- **An opening that names what the document is for** — one or two sentences, before any sub-headings, so that a reader landing cold knows where they are
+
+Every document has the same bottom:
+
+- **Cross-references** to documents the reader is likely to want next, either inline in the prose or collected under `## Related` at the end
+
+Between the top and the bottom, the document takes the shape its content asks for.
+
+### Shapes the body takes
+
+A few shapes recur. Pick the one the content fits; do not pad the content into a shape it resists.
+
+**Decision record.** When the document captures a choice with real trade-offs, the ADR shape carries the reasoning well: *Status → Context → Decision → Alternatives Considered → Operational Rules → Consequences*. Operational Rules are the part tests bind to. The shape is an option for decision-heavy documents, not a requirement for every document.
+
+**Reference catalogue.** When the content is a set of rules, names, or mappings that readers look up rather than read end-to-end, a catalogue of short sections with examples is the honest form. Naming conventions, file-layout rules, linter settings, and configuration tables read this way.
+
+**Concept or entity note.** When the document describes a thing in the domain — a Channel, a Piece, a Plan — a short run of paragraphs that names the thing, its role, and its relations is usually enough. Two or three headings if the thing has parts worth naming separately.
+
+**Quick introduction.** When the document introduces a tool or a workflow, a few paragraphs and a small example are enough. The reader needs to know what the thing is, when to reach for it, and where to go next. No ADR skeleton is required for a tool page.
+
+**Warm reasoning.** When the document is working something out — a use case, a walkthrough, an explanation of why a piece of the domain behaves the way it does — prose that follows the thought is the right form. Headings appear where they help the reader keep their place, not because structure is owed.
+
+A document can borrow from more than one shape. An architectural document might open with warm reasoning and close with Operational Rules. An entity note might include a short alternatives paragraph when the entity's shape had genuine contenders. The shapes are orientation, not slots.
+
+### Frontmatter
+
+Frontmatter is the part tooling reads. Keep it stable.
+
+| Field | Required | Notes |
+|---|---|---|
+| `title` | yes | Noun phrase naming the document. Decision records may prefix `"ADR: "`. |
+| `description` | yes | One sentence. What this document is for, without hedging. |
+| `publishedAt` | yes | ISO date (`YYYY-MM-DD`) the document was first accepted. |
+| `status` | yes | `"draft"`, `"published"`, `"superseded"`. |
+| `language` | yes | `"en"`, `"de"`. |
+| `order` | no | Integer, when a sibling set has a meaningful reading order. |
+| `kind` | no | `"adr"`, `"entity"`, `"concept"`, `"architecture"`, `"guide"`, `"use-case"`, `"reference"`. Lets renderers pick the right treatment. |
+| `area` | no | Names the implementation the document belongs to. |
+| `supersedes` | no | Filename (without extension) of the document this one replaces. |
+| `supersededBy` | no | Filename of the document that replaced this one. |
+
+### Tense and stance
+
+Documents describe what the system does, in the present tense, observed rather than advertised. "The publication function returns pieces ordered by `sort_order`." Not "The publication function will return…" and not "We should implement…". The tense holds whether the behaviour is currently built or still being specified; the `status` frontmatter carries the difference.
+
+The stance is observational. A Regardio document is not a pitch. It notices how the system fits together and what follows from that. Reliability, safety, transparency, usefulness, and care for the people the software serves show up through how the reasoning is laid out, not by being claimed. A reader who finishes a document should be able to make their own judgement about whether the system is sound — that is what the prose is for.
+
+### What shows up where
+
+- **Code snippets** appear where they clarify a contract, a data shape, or a naming pattern. Reference catalogues quite properly carry several; decision records rarely need any. A snippet never stands in for the reasoning around it.
+- **Names** (files, functions, columns, handles) appear where they are contracts readers rely on. They do not appear as a substitute for describing what something does.
+- **Procedural steps** belong in runbooks and READMEs. A domain spec does not read like a cookbook.
+
+### Cross-references
+
+Links carry a short descriptor of what the link leads to, not just a filename:
+
+```markdown
+The [Channel](../entities/channel.md) is the publication destination;
+the [Publishing Architecture](../architecture/publishing-architecture.md)
+describes how callers reach it.
+```
+
+`## Related` at the end of a document lists the next pages a reader is likely to want.
+
+### Voice
+
+The [Writing](./writing.md) standard covers voice, tone, and language. This document relies on it rather than repeating it.
+
+## Alternatives Considered
+
+### A single ADR skeleton for every document
+
+**Dismissed because** it presses reference catalogues and tool introductions into a shape that does not suit them. The skeleton adds ceremony where the content is already clear, and readers learn to skim past sections that carry no weight. The skeleton remains available for documents whose content earns it.
+
+### No shared shape at all
+
+**Dismissed because** indexing and cross-referencing need something predictable to bind to, and readers benefit from landing on any document and knowing roughly where to look. A thin shared surface — frontmatter, opening line, closing references — is enough.
+
+### Separate templates per document kind
+
+**Dismissed because** the kinds blur at the edges. An entity note sometimes carries a decision; a use case sometimes carries a catalogue. A small set of recognisable shapes that documents can borrow from works better than a closed list of templates.
+
+## Operational Rules
+
+### Frontmatter is complete
+
+Every document carries `title`, `description`, `publishedAt`, `status`, and `language`. Tooling that indexes or lists documents relies on these five.
+
+### Opening names the subject
+
+Before the first sub-heading, a reader can tell what the document is for. If the opening does not make this clear, the document is not ready.
+
+### Shape follows content
+
+The body takes the shape the content asks for. A decision record uses the ADR skeleton if that skeleton helps the reasoning; a reference uses a catalogue; an introduction stays short. Where a document borrows from more than one shape, it does so in service of the reader, not in service of the template.
+
+### Tense is present, stance is observational
+
+Documents describe the system as it is, in the present tense. Not-yet-built behaviour is flagged through `status`, not through hedged tense. The prose observes rather than promotes.
+
+### Reasoning is preserved, not rewritten
+
+When a decision is revisited, the existing document is superseded. The old reasoning stays readable so that future readers can see what was known at the time. An in-place rewrite that changes direction without supersession loses the history.
+
+### Code and names earn their place
+
+A snippet appears because it clarifies a contract the prose cannot carry alone. A specific name appears because callers rely on it. Both are tools for the reader, not decoration.
+
+### Tests can point at a document
+
+A behaviour worth testing has a place in a document that names it. The document does not need a section labelled "Operational Rules" for this — it needs prose clear enough that a test can quote it and both the test author and the reviewer know what is being verified.
+
+### One subject per document
+
+A document names one entity, one concept, one decision, one scenario. When a draft sprawls across several, the move is to split it.
+
+## Consequences
+
+### Positive
+
+- Documents read naturally for their content. ADRs feel like ADRs; reference catalogues feel like reference catalogues; introductions stay short.
+- Readers find a predictable frontmatter and opening, and the body of each document carries its reasoning in the form that fits.
+- The docs stay honest. Observational prose about what the system does leaves room for the reader to form a judgement, rather than prescribing one.
+- Tests bind to the prose that describes behaviour, wherever in the document that prose lives.
+
+### Negative
+
+- "Shape follows content" asks for judgement. Contributors unsure of the right shape need a reference document to look at; the existing documents serve that role.
+- Without a single template, reviewers sometimes have to say "this would read better as a catalogue" or "this would read better as an ADR". That conversation is part of the standard, not a cost around it.
+
+### Mitigations
+
+- New documents are often patterned on a nearby existing one. A contributor writing a new entity note copies the shape of an adjacent entity note; a contributor writing an ADR copies an adjacent ADR.
+- Reviewers point at this document when a draft has picked a shape that resists its content, and help the author find the form the content already has.
+
+## Related
+
+- [Writing](./writing.md) — Voice, tone, language
+- [Principles](./principles.md) — Shared principles
+
+---
+
+**License**: [CC-BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) © Regardio

package/docs/en/principles.md

@@ -0,0 +1,83 @@
+---
+
+title: "Principles"
+description: "The shared ground Regardio projects stand on — clusters of principles that carry across languages and repos."
+publishedAt: 2026-04-17
+order: 3
+language: "en"
+status: "published"
+kind: "reference"
+---
+
+Regardio spans several codebases and several languages. What keeps them legible to each other is a short list of principles held in common — enough shared ground that a contributor moving between projects finds the same habits in force, and enough room left for each codebase to speak its own idiom.
+
+Seven clusters, a handful of items each.
+
+## Code quality
+
+- Readable code over clever code
+- Consistent naming within each language — `camelCase` in TypeScript, `snake_case` in SQL
+- Small functions with a single responsibility
+- Explicit choices over implicit defaults
+
+## Architecture
+
+- Modules decouple from each other; dependencies are deliberate
+- Duplication resolves into an abstraction only when the pattern is clear
+- Interfaces describe what a module does, not how it does it
+- Concerns separate along the seams the domain suggests
+
+## Error handling
+
+- Input is validated early; failures surface with a clear message
+- Validation covers correctness and security in the same pass
+- Logic stays separated from side effects so it remains testable
+- Dependencies can fail; the code degrades gracefully when they do
+
+## Performance
+
+- Data structures match the shape of the work
+- Measurement comes before optimisation
+- Memory, connections, and file handles are released on the path that acquired them
+- Scale is considered at design time, not retrofitted
+
+## Security
+
+- Client data is untrusted by default; server-side validation is the line
+- Privileges stay narrow; access is opened deliberately
+- Defence is layered; a single check never stands alone
+- Openness is an opt-in, not the default posture
+
+## Maintainability
+
+- Patterns repeat across the codebase so that reading one teaches reading the rest
+- Commits are atomic and speak to one change at a time
+- Refactoring is continuous; debt is paid down rather than accumulated
+
+## Collaboration
+
+- Every change passes through review
+- Code quality is shared, not owned
+- Decisions that involve a real trade-off leave a trace in the project's `docs/en` tree
+
+## Implementation workflow
+
+Non-trivial work tends to follow this sequence — not as a ritual, but because skipping a step usually costs more later than it saves now:
+
+1. **Understand the business logic first.** The deepest defects come from misunderstood requirements. Read the relevant domain document; know what is needed now rather than what might be needed later.
+2. **Look for existing solutions.** Well-maintained libraries are evaluated before custom code is written. Dependencies are vetted for design quality, test coverage, and recent activity.
+3. **Write the tests as specification.** The behaviour a change produces is described as tests before the change is written. Tests are the contract; the code is measured against them.
+4. **Implement with reusability in mind, not reusability as the goal.** Duplicate until the pattern is clear, then extract. Wrong abstractions cost more than duplication.
+5. **Stop and reconsider when complexity grows.** Difficulty that keeps growing despite good preparation is a signal. Back out, simplify, or question the approach.
+6. **Document intent, not mechanics.** Comments explain *why*; the code explains *what*. Existing context is checked before new prose is added.
+
+## Related
+
+- [Writing](./writing.md) — Voice, tone, language
+- [Documentation](./documentation.md) — How documents are shaped
+- [Coding](./standards/coding.md) — TypeScript and general patterns
+- [Testing](./standards/testing.md) — Testing philosophy
+
+---
+
+**License**: [CC-BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) © Regardio

package/docs/en/tools/biome.md

@@ -11,7 +11,7 @@ area: "dev"
 
 # Biome
 
-[Biome](https://biomejs.dev/) is the linter and formatter every Regardio package reaches for. Configuration is centralised through `@regardio/dev`, and wrapper commands keep every package behaving the same way.
+[Biome](https://biomejs.dev/) is the linter and formatter every Regardio package reaches for. Configuration is centralised through `@regardio/dev`.
 
 ## Configuration
 
@@ -29,34 +29,22 @@ A `biome.jsonc` at the package root is all it takes:
 ```json
 {
   "scripts": {
-    "fix": "exec-s fix:pkg fix:md fix:biome",
-    "fix:biome": "lint-biome check --write --unsafe .",
-    "lint": "exec-s lint:md lint:biome",
-    "lint:biome": "lint-biome check ."
+    "fix:biome": "biome check --write --unsafe .",
+    "lint:biome": "biome check ."
   }
 }
 ```
 
-## CLI wrapper
-
-Use `lint-biome` rather than `biome` directly — the wrapper keeps behaviour consistent across the monorepo.
-
-```bash
-lint-biome check .           # Check for issues
-lint-biome check --write .   # Fix the auto-fixable
-lint-biome format .          # Format only
-```
-
 ## `package.json` handling
 
-The Biome preset leaves `package.json` alone. For those files, `lint-package` does the work:
+The Biome preset leaves `package.json` alone. For those files, use `sort-package-json`:
 
 1. Sorts `package.json` using the well-known field order
 2. Fixes export-condition order (`types` before `default` for TypeScript)
 
 ```bash
-lint-package              # Sort package.json in current directory
-lint-package path/to/pkg  # Sort a specific package.json
+pnpm sort-package-json              # Sort package.json in current directory
+pnpm sort-package-json path/to/pkg  # Sort a specific package.json
 ```
 
 It runs automatically as part of `pnpm fix`.

package/docs/en/tools/husky.md

@@ -20,7 +20,7 @@ Husky configures itself through the `prepare` script:
 ```json
 {
   "scripts": {
-    "prepare": "exec-husky"
+    "prepare": "husky"
   }
 }
 ```
@@ -35,7 +35,8 @@ Validates commit messages against the conventional-commit format:
 
 ```bash
 #!/bin/sh
-pnpm lint-commit --edit $1
+. "$(dirname "$0")/_/husky.sh"
+commitlint --edit $1
 ```
 
 ### `pre-commit` (optional)
@@ -47,10 +48,6 @@ Runs linting before a commit lands:
 pnpm lint
 ```
 
-## CLI wrapper
-
-`exec-husky` takes the place of `husky` directly — the wrapper handles monorepo scenarios that bare Husky doesn't.
-
 ## Bypassing hooks
 
 In the rare case where a hook truly has to be skipped:

package/docs/en/tools/markdownlint.md

@@ -11,7 +11,7 @@ area: "dev"
 
 # Markdownlint
 
-Markdownlint checks Markdown structure and formatting. The rules live in `@regardio/dev`; projects reach for the `lint-md` wrapper rather than calling the tool directly.
+Markdownlint checks Markdown structure and formatting. The rules live in `@regardio/dev`.
 
 ## Configuration
 
@@ -28,21 +28,12 @@ A `.markdownlint.json` at the package root:
 ```json
 {
   "scripts": {
-    "fix:md": "lint-md --fix \"**/*.md\" \"**/*.mdx\" \"!**/node_modules/**\" \"!**/dist/**\"",
-    "lint:md": "lint-md \"**/*.md\" \"**/*.mdx\" \"!**/node_modules/**\" \"!**/dist/**\""
+    "fix:md": "markdownlint-cli2 --fix \"**/*.md\" \"**/*.mdx\" \"!**/node_modules/**\" \"!**/dist/**\"",
+    "lint:md": "markdownlint-cli2 \"**/*.md\" \"**/*.mdx\" \"!**/node_modules/**\" \"!**/dist/**\""
   }
 }
 ```
 
-## CLI wrapper
-
-Use `lint-md` rather than `markdownlint-cli2` directly:
-
-```bash
-lint-md "**/*.md"              # Check all Markdown files
-lint-md --fix "**/*.md"        # Auto-fix what can be auto-fixed
-```
-
 ## Key rules
 
 | Rule | Description |