First-page profiling and remaining rollout gates

The previous goal turn made concrete progress: source history and bounded backfill were installed, the frozen retrieval comparison rejected promotion, operator cost accounting was implemented/reviewed, and a main-inclusive Railway route probe passed. Completion remains unproven. Current controller code is 4c724abcd, with report-only head 2a96acb61; the main-inclusive tested code is b4c32d1f1, with report-only head 5336d2f23.

Immediate diagnostic

Observed first pages were slower than continuations at 1/4/8 concurrent actors. The eight-connection pool reached 51 pending acquisitions, but acquisition time was not measured. Redis safety audits were serialized, included in request latency, and accumulated previously cleared keys. The observed 1.33-second mixed-page p95 cannot identify the application bottleneck.

Before changing application queries, pool sizes, ranking or storage:

1. Preserve the original bundle/report. Build separate profiling artifacts.
2. Test request attribution across delayed pool checkout. Capture SQL context at submission; separately measure acquisition and client-query durations. Record fixed query categories, never SQL text, arguments or credentials.
3. Measure Redis I/O and safety-audit queue/execution separately. Audit only currently tracked live candidates after verified cleanup, retaining a separate all-keys ledger for final cleanup. Pipeline string lengths rather than adding one round trip per string. Preserve memory/TTL/ownership checks.
4. Summarize span unions and overlap explicitly; do not subtract sums of concurrent operations from request duration. Separate first-page and continuation samples. Capture phase CPU/event-loop observations as process-level measurements.
5. Reuse the bounded 713-family synthetic workload in a new disposable testing database/role/service and Redis namespace. No production load or provider calls. Retain the original request, connection, memory, deadline and cleanup limits.
6. Identify a measured component before writing an application optimization. Require correctness regressions and a matched before/after probe for any change. A faster instrumented probe alone is not an application speedup.

Other independent gates

• Resolve the two historical GitGuardian fixture findings through legitimate inspection/triage or a normally scanned integration candidate. Do not disable the scanner, add blanket exemptions, rewrite shared history or hide real secrets.
• Diagnose content dilution and multilingual budgets on the twelve-family development corpus. Keep the consumed sixty-family evaluation separate from fresh promotion evidence; do not tune to its reported scores.
• The existing ClickPipe still has seventeen mappings and lacks the two Discover tables. Source publication/grants and warehouse schema are ready. Its installed management connector is read-only; a real mapping change remains an external prerequisite, not a reason to abandon available performance/quality work.
• Verify source → raw → archive receipts, retention and erasure before readiness. Heartbeats alone are insufficient. Preserve event ownership and known-history limitations; PostHog mirrors must not become additional outcomes.
• Complete full deployment/topology capacity, controlled rollout/rollback and appropriately matured reader-outcome evidence. Synthetic correctness, AI labels, code checks or a default-off deployment cannot prove all of these requirements.

No goal completion or production semantic enablement is warranted by the current evidence. This plan preserves the original recommendation-quality and scale scope.