DOCA Management Service (DMS)

DOCA Management Service (DMS)

⚠️ Destructive operations. The gNOI reboot, OS install, factory-reset, and managed-file deletion operations are irreversible and service-impacting — they can take a production BlueField or ConnectX offline or wipe its configuration. Before issuing any of them the agent MUST: (1) verify the target device identity, and (2) obtain explicit confirmation bound to that target and action. In an interactive session this is an explicit user reply naming/accepting both; in unattended execution it must be an approved-system authorization artifact bound to both. Otherwise stop with confirmation_required. Never invoke them speculatively or as a side effect of another task. See the public DMS guide's safety guidance for these operations.

Where to start: This skill is for operating DMS, not for linking against a library. If the user wants to deploy or run the daemon, open TASKS.md and start at ## configure. If the question is what shape of service is DMS and what protocols does it speak, start at CAPABILITIES.md. If DOCA is not installed on the management endpoint yet, route to doca-setup first.

Example questions this skill answers well

The CLASSES of DMS questions this skill is built to answer, each with one worked example. The class is the load-bearing piece; the worked example is one instance.

• "Where should DMS run for my target topology?" — worked example: "I have a host without a DPU; can I still manage a remote ConnectX?". Answered by the deployment-shape decision in CAPABILITIES.md ## Capabilities and modes
  • TASKS.md ## configure.
• "Which authentication mode should I pick for my security posture?" — worked example: "a multi-tenant production env vs a single-tenant lab". Answered by the auth-mode trade-off table in CAPABILITIES.md ## Safety policy
  • the auth-wiring step in