[freeqaz]

Problem

Several tests find one structured event in a process's output by hand: split the output, JSON.parse the lines, find the event, assert.ok it with the output as the message. They differ in strictness. Some parse every non-empty line, so a plain-text line fails them; the production image checks skip lines that do not parse. The shared jsonLines helper skips every line that does not start with {, so moving the strict copies onto it would loosen them.

Change

• tests/helpers/json-lines.mjs:
  • jsonLines(text, { strict: true }) parses every non-empty line of the trimmed text, exactly as the strict copies did (trim().split("\n").filter(Boolean).map(JSON.parse)). Passing both strict and lenient throws.
  • jsonEvent(text, event, options) returns the first line whose event matches and fails with the whole text when none does.
• Callers, each keeping its strictness:
  • workspace-files-configuration and startup-ipv6-loopback: strict.
  • production-image-startup (both finders): lenient. They parsed every line and skipped failures; only { lines can hold an event, so lenient mode finds the same record.
  • postgres-bootstrap-failures: the three sites that already used jsonLines(...).find(...) followed by assert.ok(found, output). Default mode, as before.
• Left alone: configuration-startup, sandbox-driver-startup, common-logging, repository-credentials-package and postgres-migration-compatibility, which an open PR rewrites; sign-in-chart-parity, whose startsWith("{") && endsWith("}") filter matches none of the modes exactly; and the postgres-bootstrap-failures sites whose assertion differs (failure?.code checks, or a custom message), since converting them would change the failure message.

Verification

• Node 24, CPUs pinned: workspace-files-configuration 8/8, startup-ipv6-loopback 4/4.
• Against real PostgreSQL (the lane's own prepare/run/cleanup): postgres-bootstrap-failures 22/22.
• production-image-startup needs the built images; the Images and Packaging lane is the authority.
• Mutants:
  • Strict mode returning no lines fails workspace-files-configuration 2/8 and startup-ipv6-loopback 4/4.
  • jsonEvent never finding the event fails workspace-files-configuration 2/8 and startup-ipv6-loopback 4/4.
  • Survivor: jsonEvent that ignores the event name and returns the first record. On passing runs each process prints only one JSON event (postgres-bootstrap-failures 22/22 under this mutant too), so no caller can tell the two apart.
• tsc --build tsconfig.json tests/tsconfig.json, ESLint and Prettier are clean on the touched files.
• git merge-tree against every open PR touching these files (feat: add Agent workload tags #115, Draft implementation: managed outbound HTTPS for dedicated Gateways #2518, feat: add Gateway managed mode to Agent deployments #2982) shows the same conflicts as against main.

Risks

Test-only. No product code or timeout changes. The production image callers would skip an event on a first line that starts with a byte-order mark or no-break space (the old code trimmed those away first); the structured logger never writes one. A strict-mode mutant that falls back to the default mode survives on passing runs (the processes print only JSON there), so strictness is kept by construction rather than proven by a failing caller.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.