MCP Verify — Product architecture, remaining Track 2 items implementation

Target release: 1.0.545 (main.py/tests in commit 256cc62, analytics.py in 7e9b04f).

Source: everything left on the Track 2 checklist after the earlier Phases 5/9/10 round, per the user's "do everything that is left" request following an explicit "what's left?" audit against the full 56-section source doc.

§34 — Remove Weak Priority Claims

Audited main.py for "first"-as-priority-claim language beyond the one instance already known. Found and fixed 6 genuine customer-facing instances:

• Homepage "Research" stat card: "First public index of MCP trust

signals..." → "Public index of MCP trust signals...".

• Trust Index page (render_trust_index_launch_page and neighbors): the

hero paragraph, the promotion-copy paragraph, the SEO description, the structured-data description, and the "Headline read" panel paragraph all dropped "the first" in favor of the doc's own suggested capability-differentiated framing ("Public trust index... based on fresh runtime and security evidence").

One instance was deliberately left unchanged: a line inside an internal /llms.txt-style AI-crawler launch checklist ("Promote the first MCP Trust Index at /trust-index as the public research anchor for launch outreach") — this is operational sequencing guidance for an internal audience (which edition to promote first), not a customer-facing market-priority claim, and doc §34's concern is specifically about claims like "First public MCP Trust Index" read by buyers.

Phase 4 completion — Homepage Registry Reduction (doc §12/R3)

The earlier /search phase shipped the additive destination page but deliberately left /'s own results table untouched (25-row default). Doc Requirement R3 is specific: "After search, display a small sample... Approximately 5–10 results is sufficient. Then provide: Browse all MCP servers."

render_index_page now computes is_homepage_default_sample = page_mode == "index" and bool(filters.get("default_result_constraint")) — reusing the exact flag that already distinguishes the true unfiltered homepage view from every other case (including /search, and any explicitly filtered / URL like /?freshness=fresh). When true, items is sliced to 8 before the results-row loop, "Showing N of M" uses the post-slice count (not the full queried total, which would otherwise overstate what's actually rendered), and a "Browse all MCP servers →" link to /search renders after the table.

This is purely a display-layer change — no backend query, cache-key, or limit default was touched, so /search's own default page size (still 25) and all existing cache behavior are unaffected. Deep-linked filter URLs into / (e.g. the homepage's own "Fresh scores" stat card link, /?freshness=fresh&sort_by=score) still return their full queried result set, unaffected — only the true zero-filter default view is capped.

Phase 8 — investigated, no change needed

Doc §32 ("Publisher Monetization") asks that, if Publisher becomes an important self-service wedge, pricing and included value be explicit, and that score neutrality remain explicit. Read /verified-server-profile (render_verified_server_profile_page) in full before assuming this was a gap: it already has an explicit tier table with included value per tier, a "Claim to verified profile path" checklist, and a dedicated "What paid status can and cannot do" panel stating "Cannot buy: Higher objective score, hidden ranking boosts, or undisclosed placement inside trust comparisons" — a closer, more explicit match to the doc's ask than the earlier conversation assumed. No change made; the earlier "Publisher Monetization was never touched" assessment was corrected after actually reading the page rather than relying on memory.

Phase 9 completion — endpoint-sequence detection (doc §22/A2)

The doc names three A2 patterns; the earlier round shipped one (/manage sweep). This round adds the second: "profile → badge → ledger → trust-summary sequences" / "repetitive endpoint ordering."

_browser_like_automation_window (analytics.py) now builds an ordered endpoint_sequence: list[str] alongside its existing unordered endpoint_types: set[str], and a new _contains_subsequence() helper checks whether ("server_profile", "badge", "evidence", "trust_summary") appears in that relative order (not necessarily contiguous — other events may interleave) within the 60-second window. "evidence" is this codebase's existing endpoint-type name for ledger content (_structured_endpoint_type already maps ledger paths there); no new mapping was needed since all four constituent event names were already in STRUCTURED_INTENT_EVENTS. A match produces reason="trust_surface_sequence_60s", checked after the manage-sweep reason and before the generic unordered fan-out catch-all, so a real sequence match gets a precise label instead of falling into the vaguer bucket.

Deliberately not attempted: the third A2 pattern (cross-session correlation / subnet-level IP grouping) and full endpoint-order detection beyond this one named example sequence. Both are genuine privacy-policy decisions — correlating traffic across session/cookie boundaries or grouping by IP subnet is a different category of change than extending existing per-session window logic, and the doc itself hedges these as "where practical" / "where privacy appropriate" rather than a concrete requirement. Flagged here rather than silently dropped.

§44 — Cross-Surface Consistency Tests

Discovered while investigating: verify/tests/test_api.py's existing snapshot_id-based test (inside assert_surfaces_on_same_snapshot, predates this round) already proves JSON detail/report/policy/badge/ compare/trust-summary and the server HTML page all share one snapshot_id — a strong, pre-existing form of cross-surface consistency coverage the doc's own §44 asks for, just not labeled as such.

The genuine gap was the human-readable listing row surfaces (/, /search, /rankings) — do they show the same score as the detail page and JSON for the same server? New test test_arch_track2_score_and_verdict_consistent_across_search_and_detail_surfaces fetches a seeded server's JSON current_score, formats it the same way the UI does, and asserts that exact formatted value appears in both its /search listing row and its HTML detail page.

/rankings was deliberately excluded from this test: it's a materialized top-N-by-score cache built from the whole corpus (build_rankings_payload), not queryable for one specific server, so a seeded test fixture isn't guaranteed to appear in it deterministically — attempting to force inclusion would make the test fragile rather than meaningful. /trust-index was excluded for a different reason: it's a curated, timestamped "launch edition" article (confirmed while fixing §34's wording on the same page), not a per-server live view — exempt under the doc's own "unless explicitly expected by different snapshot timestamps" carve-out.

Validation

• PYTHONPATH=verify/src pytest verify/tests -q — 498 passed (up from

495 before this round): 1 test's existing "first MCP Trust Index" assertion updated to match the new §34 wording (a real regression caught by the full suite, not anticipated in advance), plus 3 new tests (Phase 4 sample cap, Phase 9 sequence detection, §44 consistency).

• python3 scripts/export_openapi.py --check — fresh; none of these

changes touch a JSON API route's schema.

• Root-repo pytest (pre-commit hook) — 188 passed both commits,

unaffected.

What's left in the source doc after this round

• The doc's own non-goals (§48) and hedged items (subnet/cross-session

correlation, per A2 above) are intentionally not implemented.

• Everything else in the doc's numbered Phase list (1-10) and named

requirements (V1-V3 verdict vocabulary, navigation §33, accessibility §40, responsive §41) is either shipped across this and the prior four Track 2 implementation rounds, or was already satisfied by the existing implementation before this engagement's Track 2 work began.