Three roles set unsafe-inline without the rationale the repository lint
requires; 70 roles already carry it.
Only one of the three rationales is a justification. homeassistant's
frontend boots its panel from an inline module script, so the dashboard
stays blank without the flag. hermes and litellm state instead that the flag
was set when the role first deployed with no console error recorded against
it, and carry a TODO to re-verify against the running application and drop it
if nothing breaks.
unsafe-inline weakens the policy against inline script injection. For two of
these roles this documents the exemption rather than justifying it; whether
they work without it has not been tested.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The first MCP server role: where the agent roles consume tools, this one
offers them. Its services.mcp block declares an internal streamable-HTTP
endpoint gated on an agent being deployed, so the surface only exists
when something can use it, and it stays read-only because a privileged
auth subject must not carry mutating tools.
Home Assistant rejects any request carrying X-Forwarded-For from an
undeclared proxy, answering 400 for every call behind the platform's
reverse proxy. The role therefore renders a configuration.yaml that
trusts the stack subnet, keeping default_config so mounting the file does
not drop the integrations Home Assistant generates on first start.
As a shared_net provider its compose file references its own network as
external, which nothing creates in compose mode, so the role pre-creates
it the way prometheus, minio and seaweedfs already do. The vhost declares
status_codes [200, 302, 405] because the health probe sends HEAD and the
hub answers 405.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
kevinveenbirkenbachandClaude Opus 5