carlos / platform Public

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

Still outstanding: carlos vet -boot execs with -socket only, so a binary that mishandles --db passes vet and fails at real wake.

---

carlos vet -boot execs the app as <bin> -socket <tmp> and polls /healthz (internal/vet/vet.go:134).

The activator launches a real exec-backed instance as:

<bin> --socket <sock> --db <path>

(internal/activator/backend_exec.go:516; the seed path appends --db too, backend_exec.go:264.) The member-facing contract is stated as both flags — see docs/superpowers/specs/2026-08-09-carloku-deploy-story-design.md:45, where the homepage example app parses --socket and --db (ignoring the db value).

So vet checks half the contract it exists to check. A binary that mishandles --db passes vet cleanly and then fails at wake:

• doesn't define the flag at all — Go's flag package exits non-zero on an undefined flag, so the child dies immediately and the wake surfaces as an edge 503, discoverable only in the journal (the same shape as #70);
• defines it but opens some other path — a relative one resolves against a cwd nobody chose, under the agent's ProtectSystem=strict sandbox (ReadWritePaths=/data /run/carlos), so SQLite fails to open and the app comes up storeless.

carlos add already refuses a relative -db at the mint door precisely because exec children get no STATE_DIRECTORY (cli.go:157) — vet is the other door onto the same failure and doesn't guard it.

Suggested fix: bootHealthz passes --db <tmpdir>/vet.db alongside -socket, matching the activator's argv shape, and reports a non-zero exit distinctly from a health-check timeout ("the binary rejected the platform's flags" is a different diagnosis from "no 200 from /healthz").

Found while diagnosing a member's app that came up serving but with an empty store.