scenario: The Developer Setup — verify bluefin-dx-groups.service seed entry covers wheel group and reboot requirements

[castrojo]

Scenario

You switched to the DX image but docker commands still require sudo. The AI needs to confirm you are on the DX variant and then explain the group-membership mechanism that normally makes sudo unnecessary — and why it may not have taken effect yet.

Tools that serve this scenario today

• get_variant_info — confirms the DX variant is active.
• get_unit_docs("bluefin-dx-groups.service") — returns the knowledge-store entry explaining that this service adds every wheel group member to the docker and incus-admin groups on boot.

What to verify / improve

• Does the seed entry for bluefin-dx-groups.service explicitly mention: (a) the wheel group prerequisite, (b) that the effect only applies after the next boot (or re-login), and (c) what to check if the service failed (e.g. systemctl status bluefin-dx-groups.service)?
• If the entry is missing any of those three facts, it should be updated so the AI can give a complete, actionable response without additional lookups.
• Verify that get_variant_info distinguishes bluefin-dx from bluefin clearly enough for the AI to know the DX service set is present.

Acceptance criteria

• get_unit_docs("bluefin-dx-groups.service") returns an entry covering: wheel group requirement, reboot/re-login requirement, and a diagnostic command.
• get_variant_info unambiguously identifies DX variants.
• An AI given only these two tools can resolve the "docker still needs sudo" scenario without asking the user to run any unlisted commands.