carlos / platform Public

Migrated from github.com/carlosframework/platform issue #90, opened 2026-08-07. GitHub issues are closed for this repo; see AGENTS.md, "Work is tracked on amadan, not GitHub".

Still outstanding: A ports capability grant has no infra counterpart; nothing surfaces that it needs a security-group rule the platform cannot verify.

---

From cribado/cribado-dmarc#5 (first third-party ports consumer): Bill's release declared ports:[{port:25,name:mx}], the console echoed the block, the port:25 grant was made and adopted, the unit got the socket — and mx.cribado.report:25 still timed out for two days because the security group on carlos-tito-ie only allows 80/443. Every platform-side signal said "done"; the one remaining step lived in tofu (region-host's extra_ingress, pinfra PR #7) and nothing pointed at it.\n\nThe capability machinery stops at the box boundary. Options, roughly in order of ambition:\n\n1. Surface it: when a port:N grant is made (or adopted), the console/CLI notes "inbound N must also be open at the infra layer — this platform cannot verify it" so the operator hears about the other half at grant time.\n2. Probe it: the agent (or carlos doctor-shaped check) attempts an external-path TCP dial to the granted port and reports closed/open in carlos instances / the app page — turning the silent gap into a visible red reading.\n3. Own it (v2, deployment-bucket-coupling territory): grants render into the infra layer the way routes render into DNS.\n\n(1) is cheap and would have saved this round. Related: the operator-order rule already enforced for daemon routes shows the pattern — the platform is willing to know about box-level prerequisites.\n\n🤖 Generated with Claude Code