mb-run 0.0.2 → 0.0.3-dev-20260702-04dfa96

package/CHANGELOG.md

@@ -21,6 +21,16 @@ If you like this project and find it useful, please consider giving it a star on
 
 <a href="https://www.buymeacoffee.com/luligugithub"><img src="https://matterbridge.io/assets/bmc-button.svg" alt="Buy me a coffee" width="120"></a>
 
+## [0.0.3] - Dev branch
+
+### Changed
+
+- [package]: Update dependencies.
+- [workflows]: Set node-version matrix back to: [22.x, 24.x, 26.x].
+- [package]: Add vendor to files.
+
+<a href="https://www.buymeacoffee.com/luligugithub"><img src="https://matterbridge.io/assets/bmc-button.svg" alt="Buy me a coffee" width="80"></a>
+
 ## [0.0.2] - 2026-07-01
 
 ### Added

package/npm-shrinkwrap.json

@@ -1,17 +1,17 @@
 {
   "name": "mb-run",
-  "version": "0.0.2",
+  "version": "0.0.3-dev-20260702-04dfa96",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "mb-run",
-      "version": "0.0.2",
+      "version": "0.0.3-dev-20260702-04dfa96",
       "license": "Apache-2.0",
       "dependencies": {
         "cross-spawn": "7.0.6",
         "esbuild": "0.28.1",
-        "npm-check-updates": "22.2.7",
+        "npm-check-updates": "22.2.9",
         "rollup": "4.62.2",
         "rollup-plugin-dts": "6.4.1"
       },
@@ -984,9 +984,9 @@
       }
     },
     "node_modules/npm-check-updates": {
-      "version": "22.2.7",
-      "resolved": "https://registry.npmjs.org/npm-check-updates/-/npm-check-updates-22.2.7.tgz",
-      "integrity": "sha512-Pzs/lTswEe23hT8JUXABl4vgrr0WRKOhw55wAldwngUflk8CwP+grXJt00yGjYiZf2wD1HIfdPa3xaOi1RCyZQ==",
+      "version": "22.2.9",
+      "resolved": "https://registry.npmjs.org/npm-check-updates/-/npm-check-updates-22.2.9.tgz",
+      "integrity": "sha512-DVeZ0KirHfliSsHuR2o7cHE+tW439sVHfJjF6cGWeDiY0Wyl3BI/jS4zV0eixtcMOquFbcF1Su/FsxOvk5MoYA==",
       "license": "Apache-2.0",
       "bin": {
         "ncu": "build/cli.js",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mb-run",
-  "version": "0.0.2",
+  "version": "0.0.3-dev-20260702-04dfa96",
   "description": "Matterbridge command line executor",
   "author": "https://github.com/Luligu",
   "license": "Apache-2.0",
@@ -61,13 +61,14 @@
   "files": [
     "bin",
     "dist",
+    "vendor",
     "npm-shrinkwrap.json",
     "CHANGELOG.md"
   ],
   "dependencies": {
     "cross-spawn": "7.0.6",
     "esbuild": "0.28.1",
-    "npm-check-updates": "22.2.7",
+    "npm-check-updates": "22.2.9",
     "rollup": "4.62.2",
     "rollup-plugin-dts": "6.4.1"
   }

package/vendor/.claude/rules/matterbridge/matterbridge.instructions.md

@@ -0,0 +1,356 @@
+---
+description: 'How to create MatterbridgeEndpoint instances, register them in Matterbridge plugins, and use the single-class devices exported by the package v. 1.0.1'
+---
+
+# Matterbridge Endpoint Guide
+
+Use this guide when writing Matterbridge code in this repository or when authoring a plugin that consumes Matterbridge.
+
+## Public imports
+
+- Import core classes, endpoint helpers, and device type definitions from `matterbridge`.
+- Import single-class devices from `matterbridge/devices`.
+
+```ts
+import {
+  MatterbridgeAccessoryPlatform,
+  MatterbridgeDynamicPlatform,
+  MatterbridgeEndpoint,
+  addFixedLabel,
+  addUserLabel,
+  contactSensor,
+  getAttribute,
+  onOffLight,
+  powerSource,
+  setAttribute,
+  subscribeAttribute,
+  updateAttribute,
+} from 'matterbridge';
+
+import { LaundryWasher, RoboticVacuumCleaner } from 'matterbridge/devices';
+```
+
+## Create a MatterbridgeEndpoint
+
+`MatterbridgeEndpoint` is the low-level building block for custom Matterbridge devices.
+
+Constructor:
+
+```ts
+new MatterbridgeEndpoint(
+  definition: DeviceTypeDefinition | AtLeastOne<DeviceTypeDefinition>,
+  options: MatterbridgeEndpointOptions = {},
+  debug = false,
+)
+```
+
+Recommended pattern:
+
+```ts
+const device = new MatterbridgeEndpoint([contactSensor, powerSource], { id: 'EntryDoor' })
+  .createDefaultIdentifyClusterServer()
+  .createDefaultBridgedDeviceBasicInformationClusterServer(
+    'Entry Door',
+    'ENTRY-DOOR-001',
+    0xfff1,
+    'Matterbridge',
+    'Entry Door Sensor',
+  )
+  .createDefaultBooleanStateClusterServer(false)
+  .createDefaultPowerSourceReplaceableBatteryClusterServer(75)
+  .addRequiredClusters();
+```
+
+Rules that matter:
+
+- `definition` can be a single device type or an array of device types.
+- Use multiple device types when the endpoint needs more than one role, for example `[contactSensor, powerSource]`.
+- Call one of the Basic Information helpers before `registerDevice()`. Without `deviceName`, `serialNumber`, and `uniqueId`, registration fails.
+- Call `addRequiredClusters()` at the end of the chain so any required clusters (server or client) that you did not explicitly create are added automatically.
+- Use `addOptionalClusterServers()` only when you really want the optional clusters defined by the selected device type(s).
+
+## MatterbridgeEndpointOptions
+
+`MatterbridgeEndpointOptions` supports:
+
+- `id`: stable storage key for the endpoint.
+- `number`: explicit endpoint number when you need one.
+- `tagList`: semantic tags used for disambiguation, especially for composed devices or `mode: 'matter'` endpoints.
+- `mode`: `undefined`, `'server'`, or `'matter'`.
+
+Mode selection:
+
+- `undefined`: normal bridged endpoint. This is the default for most DynamicPlatform devices.
+- `'server'`: create an independent Matter device with its own server node.
+- `'matter'`: add the endpoint directly to the Matterbridge server node alongside the aggregator.
+
+Practical guidance:
+
+- Use `mode: undefined` for normal bridged devices shown as children of the bridge.
+- Use `mode: 'server'` when the device must be paired independently.
+- Use `mode: 'matter'` when the device should be a native Matter endpoint on the server node.
+- When using `mode: 'matter'`, respect Matter disambiguation rules and supply a `tagList` when sibling endpoints could be ambiguous.
+
+Implementation details worth remembering:
+
+- Spaces and `.` are removed from the internal endpoint id. The original value is retained as `originalId`.
+- Non-Latin ids are normalized to a generated unique id.
+- `id` should remain stable across restarts.
+
+## Choose the right Basic Information helper
+
+Use the helper that matches how the endpoint is exposed:
+
+- `createDefaultBasicInformationClusterServer(...)`
+  Use for `mode: 'server'`, `mode: 'matter'`, and AccessoryPlatform devices.
+- `createDefaultBridgedDeviceBasicInformationClusterServer(...)`
+  Use for bridged DynamicPlatform endpoints.
+
+Important behavior:
+
+- `createDefaultBasicInformationClusterServer(...)` sets the metadata on the endpoint.
+- For bridged endpoints, `registerDevice()` can add the `BridgedDeviceBasicInformation` cluster automatically when the device is running as a bridged endpoint in bridge mode, or in childbridge mode on a `DynamicPlatform`.
+- Explicitly calling `createDefaultBridgedDeviceBasicInformationClusterServer(...)` is clearer for bridged devices and matches the repo examples.
+
+## Register the endpoint from a plugin
+
+In plugin code, prefer `this.registerDevice(device)` instead of calling Matterbridge internals directly.
+
+DynamicPlatform bridged device:
+
+```ts
+import { MatterbridgeDynamicPlatform, MatterbridgeEndpoint, onOffLight } from 'matterbridge';
+
+export default function initializePlugin(matterbridge, log, config) {
+  return new ExamplePlatform(matterbridge, log, config);
+}
+
+class ExamplePlatform extends MatterbridgeDynamicPlatform {
+  async onStart(reason) {
+    await this.ready;
+
+    const device = new MatterbridgeEndpoint(onOffLight, { id: 'OnOffLightPlugin' })
+      .createDefaultBridgedDeviceBasicInformationClusterServer(
+        'Kitchen Light',
+        'LIGHT-001',
+        0xfff1,
+        'Matterbridge',
+        'Matterbridge OnOffLight',
+      )
+      .addRequiredClusterServers();
+
+    await this.registerDevice(device);
+  }
+}
+```
+
+AccessoryPlatform device:
+
+```ts
+import { MatterbridgeAccessoryPlatform, MatterbridgeEndpoint, temperatureSensor } from 'matterbridge';
+
+export default function initializePlugin(matterbridge, log, config) {
+  return new ExamplePlatform(matterbridge, log, config);
+}
+
+class ExamplePlatform extends MatterbridgeAccessoryPlatform {
+  async onStart(reason) {
+    await this.ready;
+
+    const device = new MatterbridgeEndpoint(temperatureSensor, { id: 'TemperatureSensorPlugin' })
+      .createDefaultBasicInformationClusterServer(
+        'Temperature Sensor',
+        'TEMP-001',
+        0xfff1,
+        'Matterbridge',
+        0x8000,
+        'Matterbridge Temperature Sensor',
+      )
+      .addRequiredClusterServers();
+
+    await this.registerDevice(device);
+  }
+}
+```
+
+Standalone Matter device from a plugin:
+
+```ts
+const device = new MatterbridgeEndpoint(pressureSensor, { id: 'ServerNodeDevice', mode: 'server' })
+  .createDefaultBasicInformationClusterServer(
+    'Server Node Device',
+    'SERVER-001',
+    0xfff1,
+    'Matterbridge',
+    0x8000,
+    'Matterbridge Server Node Device',
+  )
+  .addRequiredClusterServers();
+
+await this.registerDevice(device);
+```
+
+Native Matter endpoint on the server node:
+
+```ts
+const device = new MatterbridgeEndpoint(pressureSensor, { id: 'MatterNodeDevice', mode: 'matter' })
+  .createDefaultBasicInformationClusterServer(
+    'Matter Node Device',
+    'MATTER-001',
+    0xfff1,
+    'Matterbridge',
+    0x8000,
+    'Matterbridge Matter Node Device',
+  )
+  .addRequiredClusterServers();
+
+await this.registerDevice(device);
+```
+
+Plugin rules:
+
+- `await this.ready` before creating or registering devices.
+- Always call `this.registerDevice(device)` from the platform.
+- Use `this.unregisterDevice(device)` or `this.unregisterAllDevices()` during shutdown or development resets.
+- AccessoryPlatform plugins can only expose one normal accessory device. If you need multiple bridged devices, use `MatterbridgeDynamicPlatform`.
+- Use stable names and serial numbers so the derived `uniqueId` stays stable.
+
+## Useful MatterbridgeEndpoint helpers
+
+Common helpers on the endpoint instance:
+
+- `hasClusterServer(cluster)`
+- `hasAttributeServer(cluster, attribute)`
+- `getAttribute(cluster, attribute)`
+- `setAttribute(cluster, attribute, value)`
+- `updateAttribute(cluster, attribute, value)`
+- `subscribeAttribute(cluster, attribute, listener)`
+- `addRequiredClusterServers()`
+- `addOptionalClusterServers()`
+- `addRequiredClusters()`
+
+Example:
+
+```ts
+await device.updateAttribute('OnOff', 'onOff', true);
+```
+
+Cluster references can be passed in several ways:
+
+- behavior type
+- cluster type
+- cluster id
+- cluster name string such as `'OnOff'`
+
+Behavior type and cluster type are preferred because they are type-safe and avoid typos.
+
+Using the cluster name string is useful in plugins because it avoids importing every cluster type.
+
+## When to use a raw endpoint vs a single-class device
+
+Use a raw `MatterbridgeEndpoint` when:
+
+- you are building a custom combination of device types and clusters
+- you want full control over which default cluster servers are created
+- you are implementing a plugin-specific device model
+
+Use a single-class device when:
+
+- Matterbridge already ships a class for the device category you need
+- you want a working device with sensible default clusters and behaviors
+- you prefer a higher-level constructor over manual endpoint assembly
+
+## Single-class devices
+
+Single-class devices are exported from `matterbridge/devices`.
+
+These classes already extend `MatterbridgeEndpoint` and usually do all of the following internally:
+
+- create the correct device type combination
+- create Basic Information
+- create Power Source when needed
+- create the default cluster servers and behavior wiring required by the device
+
+Current exported single-class devices:
+
+- Media: `BasicVideoPlayer`, `CastingVideoPlayer`, `Speaker`
+- Matter 1.5 additions: `Closure`, `ClosurePanel`, `IrrigationSystem`, `SoilSensor`
+- Robotic: `RoboticVacuumCleaner`
+- Appliances: `AirConditioner`, `Cooktop`, `Dishwasher`, `ExtractorHood`, `LaundryDryer`, `LaundryWasher`, `MicrowaveOven`, `Oven`, `Refrigerator`
+- Energy: `BatteryStorage`, `Evse`, `HeatPump`, `SolarPower`, `WaterHeater`
+
+### Basic single-class example
+
+```ts
+import { LaundryWasher } from 'matterbridge/devices';
+
+const washer = new LaundryWasher('Laundry Washer', 'LW-001');
+await this.registerDevice(washer);
+```
+
+This is enough because the class constructor already creates the required device types, basic information, power source, and default cluster servers.
+
+### Single-class example with explicit mode
+
+Some single-class devices expose `mode` directly in their constructor. For example:
+
+```ts
+import { RoboticVacuumCleaner } from 'matterbridge/devices';
+
+const robot = new RoboticVacuumCleaner('Robot Vacuum', 'RVC-001', 'server');
+await this.registerDevice(robot);
+```
+
+Use this when the class supports it and you want a standalone or native Matter device instead of a bridged endpoint.
+
+### Composed single-class devices
+
+Some single-class devices are composed devices and need child endpoints added after construction:
+
+- `Oven`: create the oven, then call `addCabinet(...)`
+- `Cooktop`: create the cooktop, then call `addSurface(...)`
+- `Refrigerator`: create the refrigerator, then call `addCabinet(...)`
+
+Example:
+
+```ts
+import { PositionTag } from '@matter/node';
+import { Cooktop } from 'matterbridge/devices';
+
+const cooktop = new Cooktop('Cooktop', 'CT-001');
+cooktop.addSurface('Surface Top Left', [
+  { mfgCode: null, namespaceId: PositionTag.Top.namespaceId, tag: PositionTag.Top.tag, label: PositionTag.Top.label },
+  { mfgCode: null, namespaceId: PositionTag.Left.namespaceId, tag: PositionTag.Left.tag, label: PositionTag.Left.label },
+]);
+
+await this.registerDevice(cooktop);
+```
+
+For composed devices and for `mode: 'matter'`, use semantic tags carefully. `tagList` exists to satisfy Matter endpoint disambiguation rules.
+
+## Recommended plugin workflow
+
+For most plugins, follow this order:
+
+1. Wait for `this.ready`.
+2. Create the endpoint or single-class device.
+3. Set device identity with one of the Basic Information helpers if you are using a raw `MatterbridgeEndpoint`.
+4. Add explicit cluster servers you need.
+5. Call `addRequiredClusterServers()` last.
+6. Register the device with `await this.registerDevice(device)`.
+7. Optionally add UI metadata with `setSelectDevice()` and `setSelectEntity()`.
+
+## Avoid these mistakes
+
+- Do not register a raw `MatterbridgeEndpoint` before assigning basic identity metadata.
+- Do not use `MatterbridgeAccessoryPlatform` for multiple normal bridged accessories.
+- Do not forget that some bridged endpoints need semantic tags for disambiguation.
+- Do not assume single-class devices all share the same constructor shape. Check the device class when you need custom defaults or a mode argument.
+- Do not call Matterbridge internals directly from plugin code when `registerDevice()` already handles validation and mode-specific setup.
+
+## Short decision guide
+
+- Need a custom sensor, switch, or actuator with a few clusters: use `MatterbridgeEndpoint`.
+- Need a supported appliance, robotic, media, energy, closure, irrigation, or soil device: start with `matterbridge/devices`.
+- Need one standalone accessory with its own server node: use `mode: 'server'` or a single-class device that exposes it.
+- Need multiple bridged devices in a plugin: use `MatterbridgeDynamicPlatform`.

package/vendor/.claude/rules/testing/unit-tests.instructions.md

@@ -0,0 +1,66 @@
+---
+description: 'Testing standards for unit tests in the project v.1.0.3'
+paths:
+  - '**/src/**/*.test.ts'
+  - '**/src/**/*.spec.ts'
+  - '**/test/**/*.ts'
+  - '**/vitest/**/*.ts'
+  - '**/buntest/**/*.ts'
+---
+
+# Testing Standards for Unit Tests
+
+## 1. Test Framework
+
+- Jest is available in the repository when the file `jest.config.js` exists.
+- Vitest is available in the repository when the file `vite.config.ts` exists.
+- Bun test is available in the repository when the file `bunfig.toml` exists.
+- Jest tests live in `test` folders. Follow the existing convention in the repository for test file placement.
+- Vitest tests live in `vitest` folders. Follow the existing convention in the repository for test file placement.
+- Bun test tests live in `buntest` folders. Follow the existing convention in the repository for test file placement.
+- Ensure that tests are written in TypeScript and follow the ESM module format.
+
+## 2. Test Structure
+
+- Organize tests in file name `*.test.ts` in the `test`, `vitest`, or `buntest` folders.
+- Use `describe` blocks to group related tests and `test` blocks for individual test cases.
+
+## 3. Test Naming
+
+- Use descriptive test names that clearly indicate the behavior being tested.
+- Follow the format: `should [expected behavior] when [condition]`.
+
+## 4. Test Data
+
+- Use small, deterministic test data to ensure tests are reliable and easy to understand.
+
+## 5. Test Coverage
+
+- Aim for high test coverage, but prioritize meaningful tests over achieving 100% coverage.
+
+## 6. Mocking with Jest
+
+- If using Jest, use `jest.unstable_mockModule` for mocking dependencies in ESM modules.
+- If using Jest, avoid using `jest.mock` as it is not compatible with ESM modules.
+
+## 7. Running Tests
+
+- Run the relevant full test unit from start to finish rather than assuming isolated single-test execution is reliable.
+- If only one test framework is installed, use `npm run test -- yourTest.test.ts` or `npm run test:coverage -- yourTest.test.ts` when the touched area can be validated by running the full relevant test file.
+- When both Jest and Vitest are installed, use `npm run test -- yourTest.test.ts` for Jest or `npm run test:vitest -- yourTest.test.ts` for Vitest.
+- When Bun test is installed, use `bun test yourTest.test.ts`.
+- Use the existing `tasks.json` test tasks for areas that require grouped test files, custom coverage targets, or custom ignore-pattern handling.
+- Avoid running all tests unnecessarily to save time and tokens.
+
+## 8. Test Assertions
+
+- Use appropriate Jest, Vitest, or Bun test matchers for assertions (e.g., `toBe`, `toEqual`, `toThrow`).
+- Ensure that assertions are clear and directly related to the behavior being tested.
+
+## 9. Performance
+
+- Avoid optimization in tests; focus on correctness and clarity.
+- Use simple loops and structures in tests to maintain readability and performance.
+- Avoid complex setups that may slow down test execution unless necessary for the behavior being tested.
+- Prefer simple test cases that are easy to understand and maintain over complex ones that may be difficult to debug.
+- Some tests in this repo are intentionally structured as multi-step flows, where state persists across successive steps within a single test unit. Run those test units in full, and keep each test unit isolated from other test units.

package/vendor/.claude/settings.json

@@ -0,0 +1,45 @@
+// Claude settings v. 1.0.1
+{
+  "$schema": "https://json.schemastore.org/claude-code-settings.json",
+  "permissions": {
+    "deny": [
+      "Read(./.env)",
+      "Read(./.env.*)",
+      "Read(./**/secrets/**)",
+      "Bash(git pull:*)",
+      "Bash(git merge:*)",
+      "Bash(git push:*)",
+      "Bash(git rebase:*)",
+      "Bash(git commit --amend:*)",
+      "Bash(git reset --hard:*)",
+      "Bash(git filter-branch:*)",
+      "Bash(git branch -D:*)",
+      "Bash(git branch -d:*)",
+      "Bash(git tag -d:*)",
+      "Bash(git reflog expire:*)",
+      "Bash(git reflog delete:*)",
+      "Bash(git push --delete:*)",
+      "Bash(git push --force:*)",
+      "Bash(git push -f:*)"
+    ],
+    "ask": [
+      "Bash(git commit:*)",
+      "Bash(npm install:*)",
+      "Bash(npm i:*)",
+      "Bash(npm uninstall:*)",
+      "Bash(bun install:*)",
+      "Bash(bun i:*)",
+      "Bash(bun uninstall:*)",
+      "Bash(bun add:*)",
+      "Bash(bun remove:*)"
+    ],
+    "allow": [
+      "Bash(npm run typecheck)",
+      "Bash(npm run build)",
+      "Bash(npm run test:*)",
+      "Bash(npm run lint)",
+      "Bash(npm run format)",
+      "Bash(bun test)"
+    ]
+  }
+}

package/vendor/.codex/config.toml

@@ -0,0 +1,29 @@
+# Codex config v. 1.0.1
+
+approval_policy = "on-request"
+approvals_reviewer = "user"
+default_permissions = "matterbridge_safe"
+web_search = "live"
+
+[shell_environment_policy]
+inherit = "core"
+
+[windows]
+sandbox = "elevated"
+
+[permissions.matterbridge_safe.network]
+enabled = false
+
+[permissions.matterbridge_safe]
+description = "Workspace access with sensitive files denied and network disabled."
+extends = ":workspace"
+
+[permissions.matterbridge_safe.filesystem]
+glob_scan_max_depth = 4
+
+[permissions.matterbridge_safe.filesystem.":workspace_roots"]
+".env" = "deny"
+".env.*" = "deny"
+"**/.env" = "deny"
+"**/.env.*" = "deny"
+"**/secrets/**" = "deny"

package/vendor/.codex/rules/default.rules

@@ -0,0 +1,43 @@
+# Codex rules v. 1.0.1
+
+# Git mutations
+prefix_rule(pattern = ["git", "pull"], decision = "forbidden", justification = "Do not change local refs without explicit manual control.")
+prefix_rule(pattern = ["git", "merge"], decision = "forbidden", justification = "Do not merge automatically.")
+prefix_rule(pattern = ["git", "push"], decision = "forbidden", justification = "Do not push automatically.")
+prefix_rule(pattern = ["git", "rebase"], decision = "forbidden", justification = "Do not rewrite branch history automatically.")
+prefix_rule(pattern = ["git", "commit"], decision = "forbidden", justification = "Do not create commits automatically.")
+prefix_rule(pattern = ["git", "commit", "--amend"], decision = "forbidden", justification = "Do not amend commits automatically.")
+prefix_rule(pattern = ["git", "reset", "--hard"], decision = "forbidden", justification = "Destructive reset is blocked.")
+prefix_rule(pattern = ["git", "filter-branch"], decision = "forbidden", justification = "History rewriting is blocked.")
+prefix_rule(pattern = ["git", "branch", "-D"], decision = "forbidden", justification = "Branch deletion is blocked.")
+prefix_rule(pattern = ["git", "branch", "-d"], decision = "forbidden", justification = "Branch deletion is blocked.")
+prefix_rule(pattern = ["git", "tag", "-d"], decision = "forbidden", justification = "Tag deletion is blocked.")
+prefix_rule(pattern = ["git", "reflog", "expire"], decision = "forbidden", justification = "Reflog mutation is blocked.")
+prefix_rule(pattern = ["git", "reflog", "delete"], decision = "forbidden", justification = "Reflog mutation is blocked.")
+
+# Dependency installs
+prefix_rule(pattern = ["npm", "install"], decision = "prompt", justification = "Ask before installing dependencies.")
+prefix_rule(pattern = ["npm", "i"], decision = "prompt", justification = "Ask before installing dependencies.")
+prefix_rule(pattern = ["npm", "uninstall"], decision = "prompt", justification = "Ask before uninstalling dependencies.")
+prefix_rule(pattern = ["bun", "install"], decision = "prompt", justification = "Ask before installing dependencies.")
+prefix_rule(pattern = ["bun", "i"], decision = "prompt", justification = "Ask before installing dependencies.")
+prefix_rule(pattern = ["bun", "uninstall"], decision = "prompt", justification = "Ask before uninstalling dependencies.")
+prefix_rule(pattern = ["bun", "add"], decision = "prompt", justification = "Ask before installing dependencies.")
+prefix_rule(pattern = ["bun", "remove"], decision = "prompt", justification = "Ask before uninstalling dependencies.")
+
+# Validation scripts
+prefix_rule(pattern = ["npm", "run", "typecheck"], decision = "allow")
+prefix_rule(pattern = ["npm", "run", "build"], decision = "allow")
+prefix_rule(pattern = ["npm", "run", "test"], decision = "allow")
+prefix_rule(pattern = ["npm", "run", "test:watch"], decision = "allow")
+prefix_rule(pattern = ["npm", "run", "test:verbose"], decision = "allow")
+prefix_rule(pattern = ["npm", "run", "test:coverage"], decision = "allow")
+prefix_rule(pattern = ["npm", "run", "lint"], decision = "allow")
+prefix_rule(pattern = ["npm", "run", "format"], decision = "allow")
+prefix_rule(pattern = ["bun", "test"], decision = "allow")
+
+# External network and containers
+prefix_rule(pattern = ["curl"], decision = "prompt", justification = "Ask before external network fetches.")
+prefix_rule(pattern = ["Invoke-WebRequest"], decision = "prompt", justification = "Ask before external network fetches.")
+prefix_rule(pattern = ["docker", "pull"], decision = "prompt", justification = "Ask before downloading Docker images.")
+prefix_rule(pattern = ["docker", "run"], decision = "prompt", justification = "Ask before running Docker containers.")