constituency-outcome-slice

name	constituency-outcome-slice
description	Work one bounded constituency possible-outcome slice. Use when: creating or reviewing seat-local outcome packets under the new 1 primary + 3 reviewer workflow.

Constituency Outcome Slice

When to Use

• Working one district or one bounded seat cluster in the constituency possible-outcome lane
• Writing research/constituency-outcomes/* or research/constituency-outcome-reviews/*
• Converting a Kerala seed read into the new normalized packet shape

Canonical Files

• docs/CONSTITUENCY_POSSIBLE_OUTCOME_CONTRACT.md
• docs/CONSTITUENCY_POSSIBLE_OUTCOME_WORKFLOW.md
• research/constituency-outcomes/<stateId>/<districtId>/<constituencyId>.json
• research/constituency-outcome-reviews/<stateId>/<districtId>/<constituencyId>.json
• tools/e2e-lite-check.mjs
• tools/constituency-outcome-coverage-report.mjs
• tools/sync-constituency-outcome-index.mjs

Procedure

1. Read the contract, workflow doc, and guardrails before mutating any seat packet
2. Run node tools/constituency-outcome-coverage-report.mjs --ref origin/main --compact before claiming or closing a slice when the shared checkout is dirty or stale; use the full report only when you need district-level drill-down
3. Keep the slice district-local or cluster-local; do not build a shared statewide working file
4. If another live slice already owns the repo-wide outcome writing lane, stay prepared and keep payload prep scratch-only until that writer releases
5. Treat the first prepared or writing issue comment for the slice as the reusable source comment; edit that same comment when the slice starts writing or releases
6. If the source comment is malformed or incomplete, repair it or release the slice before any tracked repo write starts
7. Write the primary seat packet with normalized labels, rationale, risk factors, source refs, and exact lastReviewedAt
8. Record reviews in the paired review packet only; keep reviewer ids unique and independent from the primary worker
9. Use withheld or escalated when the evidence, alliance context, or field completeness is not strong enough
10. Keep public-safe runtime writes gated by the paired seat packet + review packet, and never use runtime projections as the working surface
11. After rebasing onto the latest main, run node tools/sync-constituency-outcome-index.mjs --write before commit whenever the slice touched district projection files or public/data/constituency-outcomes/index.json

Guardrails

• No deterministic winner language before results
• No append-only seat diaries or run-numbered outcome logs
• prepared is read-only and scratch-only for this lane; do not leave tracked repo diffs behind until the single outcome writing lane is available
• Do not leave duplicate prepared, writing, or released comments live for one slice when the existing bot-written source comment is still editable
• Keep public summary copy materially seat-specific; do not seed generic "stays withheld while ... review gate" filler because the runtime suppresses that boilerplate
• Public public/data/constituency-outcomes/* writes are allowed only after the paired seat packet + review packet exist and the row stays inside the approved public-safe projection contract
• Keep outcome rationales and public summaries seat-specific; do not reuse one district-wide boilerplate sentence across most seats
• Do not stretch research/statewide/constituency-outlooks.json into the multi-state working surface

Handoff

• Re-run validator coverage after outcome packet edits; missing seat packets, review packets, projection rows, district files, or manifest entries inside the slice are real defects, not silent gaps
• Re-run the coverage report when sizing the remaining state/district gap; use --compact for issue comments and do not replace the live report with a growing handwritten progress ledger
• Sync repo-truth docs if the workflow contract changes