mb-run 0.0.3-dev-20260705-2f3e02d → 0.0.3

package/CHANGELOG.md

@@ -21,12 +21,12 @@ 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
+## [0.0.3] - 2026-07-06
 
 ### Added
 
-- [copilot]: Update VS Code settings to version 1.0.6 and add terminal auto-approve configurations.
-- [claude]: Update Claude settings to version 1.0.3 and add terminal auto-approve configurations.
+- [copilot]: Update VS Code settings to version 1.0.7 and add terminal auto-approve configurations.
+- [claude]: Update Claude settings to version 1.0.4 and add terminal auto-approve configurations.
 - [package]: Apply style.
 
 ### Changed

package/dist/upgrade.js

@@ -116,7 +116,11 @@ export async function runPackageJsonUpgrade(opts, pkgPath, pkgJson, isMonorepo =
             removeDirSafe(path.join(dstDir, '.claude', 'rules', 'matterbridge'));
     }
     if (!isWorkspace) {
+        copyRecursive('.agents', '.agents');
         copyRecursive('.codex', '.codex');
+        copyRecursive('AGENTS.md', 'AGENTS.md');
+        if (!isPlugin)
+            unlinkSafe(path.join(dstDir, '.agents', 'matterbridge.md'));
         if (!isPlugin)
             removeDirSafe(path.join(dstDir, '.codex', 'rules', 'matterbridge'));
     }
@@ -339,6 +343,8 @@ export async function runPackageJsonUpgrade(opts, pkgPath, pkgJson, isMonorepo =
     fileReplace('CHANGELOG.md', '(https://github.com/prettier/prettier)', '(https://prettier.io/)');
     fileReplace('CHANGELOG.md', '(https://github.com/eslint/eslint)', '(https://eslint.org/)');
     fileReplace('CHANGELOG.md', '(https://nodejs.org/api/esm.html)', '(https://nodejs.org/)');
+    if (isMonorepo)
+        return;
     const scripts = pkgJson.scripts;
     const startScript = scripts?.start ?? `node ${pkgJson.main ?? 'dist/module.js'}`;
     log(magenta(`Start script: ${cyan(startScript)}`));
@@ -482,7 +488,7 @@ export async function runPackageJsonUpgrade(opts, pkgPath, pkgJson, isMonorepo =
     log(green('Installing devDependencies...'));
     const commands = [
         `npm pkg delete overrides`,
-        `npm install --no-fund --no-audit --save-dev --save-exact typescript @types/node @typescript/native-preview oxlint oxlint-tsgolint oxfmt`,
+        `npm install --no-fund --no-audit --save-dev --save-exact typescript ${opts.useNode ? '@types/node' : ''} ${opts.useBun ? '@types/bun' : ''} @typescript/native-preview oxlint oxlint-tsgolint oxfmt`,
         opts.enableJest ? `npm install --no-fund --no-audit --save-dev --save-exact jest ts-jest @types/jest @jest/globals cross-env` : null,
         opts.enableVitest ? `npm install --no-fund --no-audit --save-dev --save-exact vitest @vitest/coverage-v8` : null,
         opts.enableBundle ? 'npm install --no-fund --no-audit --save-dev --save-exact esbuild' : null,

package/npm-shrinkwrap.json

@@ -1,12 +1,12 @@
 {
   "name": "mb-run",
-  "version": "0.0.3-dev-20260705-2f3e02d",
+  "version": "0.0.3",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "mb-run",
-      "version": "0.0.3-dev-20260705-2f3e02d",
+      "version": "0.0.3",
       "license": "Apache-2.0",
       "dependencies": {
         "cross-spawn": "7.0.6",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mb-run",
-  "version": "0.0.3-dev-20260705-2f3e02d",
+  "version": "0.0.3",
   "description": "Matterbridge command line executor",
   "author": "https://github.com/Luligu",
   "license": "Apache-2.0",

package/vendor/.agents/matterbridge.md

@@ -0,0 +1,319 @@
+# 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, call `this.registerDevice(device)`.
+
+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')
+      .addRequiredClusters();
+
+    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')
+      .addRequiredClusters();
+
+    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')
+  .addRequiredClusters();
+
+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')
+  .addRequiredClusters();
+
+await this.registerDevice(device);
+```
+
+Plugin rules:
+
+- Use `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/.agents/testing.md

@@ -0,0 +1,56 @@
+# 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/rules/matterbridge/matterbridge.instructions.md

@@ -114,7 +114,7 @@ Important behavior:
 
 ## Register the endpoint from a plugin
 
-In plugin code, prefer `this.registerDevice(device)` instead of calling Matterbridge internals directly.
+In plugin code, call `this.registerDevice(device)`.
 
 DynamicPlatform bridged device:
 
@@ -137,7 +137,7 @@ class ExamplePlatform extends MatterbridgeDynamicPlatform {
         'Matterbridge',
         'Matterbridge OnOffLight',
       )
-      .addRequiredClusterServers();
+      .addRequiredClusters();
 
     await this.registerDevice(device);
   }
@@ -166,7 +166,7 @@ class ExamplePlatform extends MatterbridgeAccessoryPlatform {
         0x8000,
         'Matterbridge Temperature Sensor',
       )
-      .addRequiredClusterServers();
+      .addRequiredClusters();
 
     await this.registerDevice(device);
   }
@@ -185,7 +185,7 @@ const device = new MatterbridgeEndpoint(pressureSensor, { id: 'ServerNodeDevice'
     0x8000,
     'Matterbridge Server Node Device',
   )
-  .addRequiredClusterServers();
+  .addRequiredClusters();
 
 await this.registerDevice(device);
 ```
@@ -202,14 +202,14 @@ const device = new MatterbridgeEndpoint(pressureSensor, { id: 'MatterNodeDevice'
     0x8000,
     'Matterbridge Matter Node Device',
   )
-  .addRequiredClusterServers();
+  .addRequiredClusters();
 
 await this.registerDevice(device);
 ```
 
 Plugin rules:
 
-- `await this.ready` before creating or registering devices.
+- Use `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`.

package/vendor/.claude/settings.json

@@ -49,6 +49,7 @@
       "Bash(tsc:*)",
       "Bash(npx tsgo:*)",
       "Bash(tsgo:*)",
+      "Bash(cd:*)",
       "Bash(tail:*)"
     ]
   }

package/vendor/.github-plugin/instructions/matterbridge/matterbridge.instructions.md

@@ -115,7 +115,7 @@ Important behavior:
 
 ## Register the endpoint from a plugin
 
-In plugin code, prefer `this.registerDevice(device)` instead of calling Matterbridge internals directly.
+In plugin code, call `this.registerDevice(device)`.
 
 DynamicPlatform bridged device:
 
@@ -138,7 +138,7 @@ class ExamplePlatform extends MatterbridgeDynamicPlatform {
         'Matterbridge',
         'Matterbridge OnOffLight',
       )
-      .addRequiredClusterServers();
+      .addRequiredClusters();
 
     await this.registerDevice(device);
   }
@@ -167,7 +167,7 @@ class ExamplePlatform extends MatterbridgeAccessoryPlatform {
         0x8000,
         'Matterbridge Temperature Sensor',
       )
-      .addRequiredClusterServers();
+      .addRequiredClusters();
 
     await this.registerDevice(device);
   }
@@ -186,7 +186,7 @@ const device = new MatterbridgeEndpoint(pressureSensor, { id: 'ServerNodeDevice'
     0x8000,
     'Matterbridge Server Node Device',
   )
-  .addRequiredClusterServers();
+  .addRequiredClusters();
 
 await this.registerDevice(device);
 ```
@@ -203,14 +203,14 @@ const device = new MatterbridgeEndpoint(pressureSensor, { id: 'MatterNodeDevice'
     0x8000,
     'Matterbridge Matter Node Device',
   )
-  .addRequiredClusterServers();
+  .addRequiredClusters();
 
 await this.registerDevice(device);
 ```
 
 Plugin rules:
 
-- `await this.ready` before creating or registering devices.
+- Use `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`.

package/vendor/.vscode/settings.native.json

@@ -1,4 +1,4 @@
-// VS Code settings native v. 1.0.6
+// VS Code settings native v. 1.0.7
 {
   "npm.packageManager": "npm",
   "eslint.enable": false,
@@ -44,20 +44,29 @@
   "git.autofetch": true,
   "git.autoRepositoryDetection": false,
   // VS Code's Copilot Chat extension settings
-  "chat.useCustomizationsInParentRepositories": true,
-  "chat.useAgentsMdFile": true,
-  "chat.useClaudeMdFile": true,
-  "chat.instructionsFilesLocations": {
-    ".github/instructions": true,
-    ".claude/rules": true,
-    "~/.copilot/instructions": true,
-    "~/.claude/rules": true
-  },
+  "chat.useCustomizationsInParentRepositories": true, // Default false.
   "chat.tools.terminal.autoApprove": {
     "npx tsc": true,
     "npx tsgo": true,
     "npx oxlint": true,
     "npx oxfmt": true,
-    "npx vitest": true
+    "npx vitest": true,
+    "npm run build": true,
+    "npm run typecheck": true,
+    "npm run lint": true,
+    "npm run format:check": true,
+    "npm run test": true,
+    "npm run test:coverage": true,
+    "npm run update-htmls": true,
+    "git status": true,
+    "git diff": true,
+    "git diff --check": true,
+    "git diff --stat": true,
+    "git log": true,
+    "git show": true,
+    "git branch -vv": true,
+    "git ls-files": true,
+    "git --no-pager diff --stat": true,
+    "git --no-pager diff --check": true
   }
 }

package/vendor/AGENTS.md

@@ -3,24 +3,24 @@
 ## Style And Formatting
 
 - Follow [STYLEGUIDE.md](./STYLEGUIDE.md) for code style, naming, JSDoc, validation, logging, and formatting expectations.
-- JSDoc requirements are enforced by oxlint. Treat missing or incomplete JSDoc on required APIs as a real lint issue, not optional documentation.
-- Import and export ordering are enforced by oxlint/oxfmt. Preserve the existing grouped and sorted order unless a change requires updating it.
-- Formatting is enforced by oxfmt. Follow the existing formatting and do not fight the formatter.
+- JSDoc requirements are enforced by the linter. Treat missing or incomplete JSDoc on required APIs as a real lint issue, not optional documentation.
+- Import and export ordering are enforced by the linter or by theformater. Preserve the existing grouped and sorted order unless a change requires updating it.
+- Follow the existing formatting and do not fight the formatter.
 
 ## Scope And Safety
 
 - Keep changes minimal and scoped to the request. Avoid unrelated refactors or broad cleanup.
 - Do not modify production code only to make a test pass. If a failing test points to a likely source issue, explain the issue and change behavior only when required by the task.
 - Preserve cross-platform behavior. Changes must work on Windows, macOS, and Linux, especially for paths, shell commands, environment variables, and networking behavior.
-- Maintain compatibility with the supported Node.js versions in this repository: 20, 22, 24 and 26.
+- Maintain compatibility with the supported Node.js versions in this repository: 20.19, 22.13, 24.0 and 26.0.
 
 ## Project Architecture
 
-- This repository is a TypeScript ESM monorepo. Follow existing project patterns for imports, exports, build configuration, and test setup.
+- This repository is a TypeScript ESM repo. Follow existing project patterns for imports, exports, build configuration, and test setup.
 
 ## Testing And Validation
 
-- Prefer the existing npm scripts in [package.json](./package.json) and the repository test/build tasks when validating changes.
+- Prefer the existing npm scripts in [package.json](./package.json) and the VS Code tasks in [tasks.json](./.vscode/tasks.json) when validating changes.
 - Keep tests deterministic and simple. Prefer small data sets and straightforward setup.
 - Some tests are intentionally multi-step flows. State may persist across successive steps within a single test flow, but each test unit must remain isolated from other tests.
 - For validation, run the relevant full test file or the matching suite/task for the touched area rather than assuming arbitrary isolated single-test execution is reliable.
@@ -28,3 +28,10 @@
 ## Documentation
 
 - When behavior changes, update the relevant tests and documentation.
+
+## Additional Agent Guidance
+
+For task-specific guidance, read relevant files in `.agents/`:
+
+- `.agents/testing.md` for testing and validation expectations
+- `.agents/matterbridge.md` for instruction about using matterbridge in a plugin

package/vendor/Branch protection.json

@@ -51,13 +51,6 @@
     {
       "type": "update"
     },
-    {
-      "type": "copilot_code_review",
-      "parameters": {
-        "review_on_push": true,
-        "review_draft_pull_requests": true
-      }
-    },
     {
       "type": "code_scanning",
       "parameters": {