weichen
a6d434e432
ci / test (pull_request) Successful in 2m18s
Why: the plan section 3.4 observed the local dev service carrying the credential-bearing DSN as a serve --dsn argument, visible to any process on the host (ps / /proc/<pid>/cmdline) — including scripts generated by agents. The base config layer already supports AGENT_SYSTEM_DSN, so the launcher can move the secret out of the argument vector without touching the binary. Evidence: bash -n clean; make test-governance 104/104 green; an end-to-end probe with a stub binary and a legacy exec= carrying --dsn ...secret... shows the migration stripping the flag (MIGRATED:yes), the process args free of the secret (NO-LEAK-IN-CMDLINE), and AGENT_SYSTEM_DSN present in the process environment (DSN_IN_ENV:yes). New/rebuilt launches never put the DSN in argv; legacy persisted configs are migrated on first reuse. Impact: scripts/svc.sh only — rebuild path sets DSN_ENV instead of --dsn, reuse path strips --dsn from stored exec= once and logs the migration, launch injects AGENT_SYSTEM_DSN alongside the existing guard vars. CLI --dsn still wins inside the binary (config precedence), so manual invocations are unchanged. Refs: plan G1-7 (line 356) and section 3.4 (2026-10-09 ps observation); backend config AGENT_SYSTEM_DSN.