scenario: The Container Builder — verify list_distrobox and incus-workaround.service seed serve Distrobox failure diagnosis

[castrojo]

Scenario

Distrobox is failing to create or start containers. The AI needs to know the current container inventory and whether the DX-specific container stack (Incus, libvirt, SELinux workaround services) is relevant to the failure.

Tools that serve this scenario today

• list_distrobox — shows the container inventory including image and status.
• get_variant_info — confirms whether you are on a DX image, which ships the full container stack (Incus, libvirt) alongside Distrobox.
• get_unit_docs — can be used to look up incus-workaround.service and libvirt-workaround.service, which apply SELinux policy workarounds relevant on atomic systems.

What to verify / improve

• Does list_distrobox output include enough structured information — image reference, container status, creation timestamp — for the AI to say "this container is stopped/errored/missing"?
• Does the incus-workaround.service knowledge-store entry note that its SELinux policy changes can also affect Distrobox container startup, not just Incus VMs? If not, the entry should be updated to include that cross-cutting note.
• Verify that the libvirt-workaround.service entry similarly notes any Distrobox-relevant side effects.

Acceptance criteria

• list_distrobox returns image reference and status per container in a structured form.
• The incus-workaround.service seed entry mentions any Distrobox-relevant effects.
• An AI given these three tools can distinguish "container is stopped" from "container creation failed due to SELinux policy" from "DX stack not present."