Matter Hub Guide

Standalone Agent Handbook · Stable 2.0.55

Operating specification for researching, writing and delivering the 22-chapter guide

You can give this handbook directly to a research or writing agent. Its scope is fixed to upstream tag v2.0.55, commit 6c8e8403d488fb06d2ac02d9199b92a0b8e8dccf. The add-on is governed by pinned mirror commit a68dc435da8eb206e9efd51388d5d1ce798aefe0.

Role, audience and hard boundaries

Your task

  • Write only content supported by the exact tag, same-version documentation, the pinned add-on or read-only observation on real hardware.
  • Use natural international English and address the reader as “you.” Explain terminology first, then give a home or small-office scenario, and only then provide steps.
  • Describe Matter Hub as a bridging tool that exposes Home Assistant entities to an external controller, not as a Matter controller.
  • Record release channel, product maturity and controller support separately for every feature.

Prohibited actions

  • Do not describe Alpha, Testing or callback architecture as Stable functionality.
  • Do not fill gaps in v2.0.55 facts with documentation from another version.
  • Do not promise compatibility with every controller, device or network environment.
  • Do not select Save, Create, Delete, Pair, Reset, Install, Uninstall or Restore to take a screenshot.
  • Do not disclose pairing secrets, tokens, cookies, credentials, private IP addresses or hostnames.

Source precedence and conflict handling

  1. v2.0.55 exact-tag code and schema: Highest priority. Use a fixed-commit URL and record the file path and symbol.
  2. Same-tag README and changelog: Use these for installation, public features and change descriptions. If they differ from the code, follow reachable code paths and note the difference.
  3. Same-tag documentation site: Use it for scenarios and operating instructions; do not substitute the latest documentation.
  4. Pinned add-on mirror: Use it only for mirrored facts about add-on installation, Ingress and container configuration.
  5. Read-only observation on real hardware: It proves only what that environment displays; by itself, it does not prove general support.
Conflict rule: Do not reconcile conflicts yourself. Record the claim, source A, source B, adopted conclusion and remaining verification. If you cannot resolve the conflict, downgrade the text to a limitation or an item requiring verification.

Release channel, maturity and controller support

FieldAllowed valuesWriting rule
Release channelStable/Testing/AlphaOnly functionality reachable in Stable 2.0.55 belongs in the main flow. List everything else only as an excluded boundary.
MaturityProduction/experimental/unknownMulti-entity Server Mode, Camera/Security plugins and some Matter 1.4 types remain labeled “experimental” in Stable.
ControllerVerified/documented/requires verification/not applicableRecord Apple, Google, Alexa, Aqara and SmartThings separately; do not infer across controllers.
Evidencecode/schema/same-tag documentation/real hardwareGive every high-risk or compatibility claim at least one fixed-version source.

Feature manifest workflow

Build the feature manifest before researching and writing chapters. Every row must include at least: feature_id, name, chapter, release channel, maturity, controller, code path, schema path, documentation URL, verification status, limitations and security notes.

feature_id: [stable identifier]
version: 2.0.55
channel: [stable | testing | alpha]
maturity: [production | experimental | unknown]
controllers:
  apple: [verified | documented | requires verification | not applicable]
  google: [verified | documented | requires verification | not applicable]
  alexa: [verified | documented | requires verification | not applicable]
  aqara: [verified | documented | requires verification | not applicable]
  smartthings: [verified | documented | requires verification | not applicable]
evidence:
  - [exact-commit URL]
limitations: [limitations]
security: [security notes]

Responsibilities across 22 chapters

PartChaptersCore deliverable
Foundations01–04Roles, installation, Dashboard, the first bridge and network preflight.
Filtering and mapping05–12Filters, settings, mappings, composed entities, device types and Standalone Devices/Server Mode.
Controller13–17Commissioning, multi-fabric, Apple, Google, Alexa, Aqara and SmartThings.
Operations18–22Bridge operations, Health/topology, network security, plugins/API, backup and troubleshooting.

Required chapter structure

Safe read-only screenshots and redaction

  1. Plan: First record the screenshot’s purpose, page, UI state to prove and potentially sensitive fields.
  2. Navigate read-only: Only open pages, switch tabs that do not write, search and expand information. Do not select any control that changes state.
  3. Isolate originals: Save the first screenshot only in the gitignored artifacts/raw-screenshots/; do not place it directly in public assets.
  4. Redact manually: Redact QR codes, pairing codes, setup PINs, discriminators, fabric/node IDs, tokens, cookies, credentials, IP addresses, hostnames and identifiable household data.
  5. Two-person review: A second person checks the image, filename, EXIF and surrounding text at 100% zoom. Only after approval may it move to assets/screenshots/.
Hard stop: Do not select Save, Create, Delete, Pair, Reset, Install, Uninstall or Restore to “get a better screenshot.” If an image is unavailable, use text and a verifiable schematic structure; do not imitate the product UI or logo.

Factual, security and editorial reviews

Factual review

  • Mark verifiable claims and sources paragraph by paragraph.
  • Check versions, defaults, limits, support matrices and UI paths individually.
  • Search for “always,” “full support,” “all” and “guaranteed”; require evidence or rewrite.
  • Check terminology for Matter Hub/controller and bridge/fabric/endpoint for consistency.

Security review

  • Run a sensitive-data scan and manually inspect QR codes, PINs, tokens, IP addresses and hostnames.
  • Require a backup, impact assessment, approval and recovery plan before high-risk actions.
  • Do not misrepresent Basic Auth as RBAC/SSO.
  • Default to minimal exposure, least privilege and Preview before changes.

Editorial review

  • Use natural international English, address the reader as “you,” and avoid emoji and translationese.
  • Define a technical term on first use, then use it consistently.
  • Name locations and buttons in steps; put limitations immediately after the relevant action.
  • Tables and code must scroll horizontally on mobile.

Accessibility review

  • Use correct semantics for heading hierarchy, landmarks, link text and table headers.
  • Keep keyboard focus visible and interactive targets at least 44px.
  • Prevent page-level horizontal scrolling at 320/360px.
  • Use only the pinned MDI version and hide decorative icons from assistive technology.

Validation commands and failure handling

node scripts/build_nav.js --check
node scripts/check_links.js
node scripts/check_content.js
node scripts/check_sensitive.js
node scripts/check_feature_manifest.js

Deployment and delivery

  1. Freeze the factual baseline: Confirm that the exact commit, add-on mirror and manifest agree.
  2. Run complete build checks: Run navigation, link, content, sensitive-data and manifest checks.
  3. Preview environment: Test the root and project subpath with the same base path as GitHub Pages; check the 404 return link.
  4. Manual acceptance: Recheck desktop, 320px, 360px, keyboard use, screen-reader semantics and sensitive content.
  5. Atomic commit: Commit only the approved scope; record the SHA, change summary, validation output, residual risks and rollback method.
  6. Post-release smoke test: Check the four home-page cards, 22-chapter catalog, three handbooks, OG image, 404 page and external sources.

Pinned sources