timeline-release-check

name	timeline-release-check
description	Verify the current timeline-enabled app data is ready to ship. Use when: preparing a release of the current candidate-detail surface, confirming no live rows still show as pending, or checking current public row/detail parity before deployment.

Timeline Release Check

When to Use

• Before shipping the current timeline-enabled state
• After rerunning sync/public-candidate generation for release readiness
• When users report details pending and the team needs to confirm repo-truth quickly
• For incremental direct-to-main pushes, run this as a single e2e-lite gate per push

Canonical Agents

• publication-agent
• ingestion-validator-agent

What It Checks

• Current district-row count matches current candidate-detail file count
• No live district rows have hasDetail: false
• No live district rows have empty timeline arrays
• Representative merged-chronology routes such as Nemom, Vattiyoorkavu, and one thin seat open from current app data
• Candidate-card previews do not promote scaffold-only filler as the latest meaningful update
• Public candidate-detail files carry valid timelineMeta
• Visible chronology events keep source links and stay inside public copy limits
• The declaration backlog tracker stays aligned with current public detail coverage and the curated route does not flood one affidavit page across many same-date cards
• All shipped candidate routes should still resolve to at least 20 visible events through getCandidateTimelineFeed(...), or any exceptions should be called out explicitly before release
• Current baseline may change after verified row removals; the release check should follow parity, not a stale fixed count
• Remember: the candidate route suppresses statewide-admin schedule items when enough candidate-focused material exists, but it may still show them as last-resort fallback on thin dossiers to preserve the 20-event floor
• If using the lightweight push model, npm run check:e2e-lite is the default pre-push check and should write a compact snapshot to research/swarm/control/validation-state.json
• The internal seat outlook ledger should validate cleanly, but it must stay out of public/data/ and public app routes
• Candidate pages on narrow screens should still keep larger tap targets and no horizontal overflow, but the default route should now be the full latest-to-oldest chronology rather than a short-route-first view

Guardrails

• Do not treat this as a substitute for deployment confirmation
• If validator reports a clean or advisory state but users still report stale UI, investigate rollout state rather than changing data model again
• If a candidate page looks empty after a good sync, inspect route filtering and timelineMeta first instead of assuming the public detail file is missing
• Product route coverage and rolling swarm publication counts may drift; confirm which truth surface the release question is asking about before editing task or review state
• Keep disabled-state copy soft; use true-missing-detail fallback only

Handoff

• After repo checks pass, remember that pushing main triggers Vercel deployment for this repo
• After deploy, confirm the live app is serving refreshed public/data/ outputs