Skip to content

Support Bundle Subsystem

The Support Bundle Subsystem defines the platform-level contracts for creating sanitized diagnostic bundles across SmrtHub.

This document is contract-focused. End-to-end “who triggers what and what gets collected” narratives belong in the Support Bundle Capability (Flow) doc.

Overview & responsibilities

  • Standardize safe-by-default diagnostic handoff across all SmrtHub components.
  • Define required bundle structure (manifest, hashes, review reports) and redaction expectations.
  • Ensure bundles discover inputs via canonical Operational Data Policy locations.

Contract(s) and invariants

All components that generate or contribute artifacts to Support Bundles must follow these contracts:

  1. Sanitized by default
  2. Bundles must not include secrets.

  3. Redaction/scrubbing is required by default.

  4. Canonical discovery

  5. Inputs must be discovered from canonical paths and naming conventions (Operational Data Policy).

  6. Do not scrape arbitrary locations outside policy-defined roots.

  7. Deterministic structure

  8. Bundles must include a machine-readable manifest with SHA-256 hashes.

  9. Bundles must include human-readable review output.

  10. Bounded scope

  11. Collection must support bounded time windows and component filtering.

  12. Exporters must cap size and handle partial failure gracefully.

  13. Observability

  14. Bundle generation must emit structured logs describing what was included/skipped and why.

Integration points

  • Primary implementation component: SmrtApps/src/Smrt.SupportBundle/README.md
  • Logging: uses the unified logging stack; see README.Files/Reference-Guides/SmrtHub.Logging.README.md
  • Policies: Operational Data Policy + Privacy/Security Policy govern locations and redaction expectations.
  • Trigger surfaces: HubWindow tray/taskbar, Supervisor/CLI tools, and approved automation hooks.

Configuration, paths, and operational data

  • Canonical path rules live in README.Files/System/Policies/SmrtHub-Operational-Data-Policy-v1.0.README.md.
  • The Support Bundle exporter should not introduce new directory layouts beyond policy.

Observability & diagnostics

  • Bundle generation must emit structured logs describing what was included/skipped and why.
  • Not documented yet: standardized event names for bundle planning, sanitization, and packaging phases.

Security/privacy notes

  • Treat bundles as sensitive diagnostic artifacts.
  • Keep redaction enabled by default.
  • Do not log raw captured content; log summaries and redaction counts.

Testing & validation expectations

  • Validate redaction behavior.
  • Validate manifest hashing.
  • Validate bundle completeness for a representative set of components.