Uh oh!
There was an error while loading. Please reload this page.
feat(voting): auditoría de votos cerrados + podio refleja el resultado final - #49
Conversation
…o final Tres mejoras al cierre de la votación comunitaria: - Admin puede ver por quién votó cada uno también CON LA VOTACIÓN CERRADA. Nueva acción `reveal-ballots` (descifra los ballots igual que `close-preview` pero permite período cerrado, sin publicar nada); `useAdminLiveTally(closed)` firma la acción correcta; VotingProvider suscribe a ballots cuando está cerrada y sos admin (para saber quién votó); el modal de padrón habilita el revelado y ajusta el copy. - El podio del hero cerrado refleja el RESULTADO FINAL combinado (70% popular / 30% jueces) en vez del voto popular: las entradas se arman desde `results.final` (orden = ranking final, métrica = score final "pts"); sin jueces cae al voto popular (métrica = votos). La tabla detallada sigue debajo. - Se oculta la sección genérica "Premios" de la página del hackatón cuando la votación cerró con resultado publicado (el premio ya se ve por proyecto). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughAdds an admin-only "reveal-ballots" voting action that decrypts per-voter ballots after results are frozen, without publishing. Updates the API route, admin live-tally hook, voting UI subscriptions/messaging, hackathon page results visibility, and closed-results podium rendering to use a combined final-results metric. ChangesAdmin reveal-after-close feature
Sequence Diagram(s)sequenceDiagram
participant Admin
participant VotingDetailModal
participant useAdminLiveTally
participant VotingAPI
Admin->>VotingDetailModal: open modal (voting closed)
VotingDetailModal->>VotingDetailModal: canReveal = isAdmin
VotingDetailModal->>useAdminLiveTally: call(hackathonId, closed=true)
useAdminLiveTally->>VotingAPI: POST action=reveal-ballots
VotingAPI-->>useAdminLiveTally: decrypted ballot preview
useAdminLiveTally-->>VotingDetailModal: tally data
VotingDetailModal-->>Admin: render decrypted ballots
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~30 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
app/api/hackathons/[id]/voting/route.ts (1)
811-832: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winUse the frozen close time for
reveal-ballots.buildClosePreview(..., Math.floor(Date.now() / 1000))letsreveal-ballotsadmit ballots that were cast after the voting period was actually closed, so the audit view can diverge fromperiod.results. Passexisting.period.closedAtfor the reveal path instead.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/api/hackathons/`[id]/voting/route.ts around lines 811 - 832, The close-preview/reveal branch in the voting route currently always uses the current timestamp when calling buildClosePreview, which can make reveal-ballots include votes cast after the period actually closed. Update the logic in the action handling block for CLOSE_PREVIEW_ACTION and REVEAL_ACTION so that the reveal path uses existing.period.closedAt as the reference time, while keeping the preview path on the current time. Use the existing.period, buildClosePreview, and REVEAL_ACTION symbols to locate and split the timestamp passed into the preview builder.
🧹 Nitpick comments (2)
app/hackathons/[id]/page.tsx (1)
466-500: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winAvoid computing awards/badge data when Premios is suppressed.
awards,prizeProfiles,prizeBadgeIssuerPubkey,prizeBadgeCatalog, andprizeSoldierRecipients(lines 466-500) are still computed unconditionally wheneverstatus === "closed", even though the only place they're consumed — the Premios card — is now skipped entirely whenresultsPublishedis true (lines 582-695). This meansgetCachedHackathonBadgePublisherPubkey(), per-pubkeygetCachedNostrProfilecalls, andgetSoldiers()run for no visible benefit once results are published.Consider gating these computations on
!resultsPublishedas well.♻️ Proposed refactor
const prizeByProjectId = new Map( - awards.map((a) => [a.project.id, a] as const),+ awards.map((a) => [a.project.id, a] as const), ); const nostrSubmissions = (await getNostrHackathonSubmissions(id)).map( fromCachedNostrSubmission, ); const prizeBadgeIssuerPubkey = - status === "closed"+ status === "closed" && !resultsPublished ? await getCachedHackathonBadgePublisherPubkey().catch(() => "") : ""; const prizeBadgeCatalog = - status === "closed" && prizeBadgeIssuerPubkey+ status === "closed" && !resultsPublished && prizeBadgeIssuerPubkey ? buildHackathonBadgeCatalogContent( prizeBadgeIssuerPubkey, id, hackathon.name, ) : null; const needsSoldierRecipientLookup = - status === "closed" &&+ status === "closed" &&+ !resultsPublished && awards.some((award) => !primaryProjectPubkey(award.project));Also applies to: 582-695
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/hackathons/`[id]/page.tsx around lines 466 - 500, Gate the Premios-related data loading in the hackathon page so it only runs when the card can actually render. In the page component that computes `awards`, `prizeProfiles`, `prizeBadgeIssuerPubkey`, `prizeBadgeCatalog`, and `prizeSoldierRecipients`, add the same `!resultsPublished` check used by the Premios card before calling `getCachedHackathonBadgePublisherPubkey`, `getCachedNostrProfile`, and `getSoldiers`. Keep the existing `status === "closed"` logic, but skip all of these lookups when results are already published.lib/useAdminLiveTally.ts (1)
37-44: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider sharing the action-name constants with the API route instead of re-deriving the literal strings.
"close-preview"/"reveal-ballots"are independently hardcoded here while the server definesCLOSE_PREVIEW_ACTION/REVEAL_ACTIONas local constants inapp/api/hackathons/[id]/voting/route.ts. Exporting these from a shared module (e.g.@/lib/voting) and importing on both sides would let TypeScript catch a future rename instead of silently breaking the client/server contract.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@lib/useAdminLiveTally.ts` around lines 37 - 44, The action names in useAdminLiveTally are duplicated as raw strings, so update the client and API route to use shared exported constants instead of re-deriving "close-preview" and "reveal-ballots". Move CLOSE_PREVIEW_ACTION and REVEAL_ACTION into a common module such as `@/lib/voting`, then import those values in useAdminLiveTally and in the voting route so TypeScript can enforce the client/server contract and catch future renames.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@app/hackathons/`[id]/VotingSection.tsx:
- Around line 802-806: The admin tally in VotingSection/VotingDetailModal is not
refreshed when the period status changes from open to closed, so stale perVoter
data can persist across the transition. Update the logic around
useAdminLiveTally and the modal’s open/closed handling so that a closed-state
flip triggers a refresh or clears the existing tally when data is already
loaded; use the canReveal, tally, and VotingDetailModal flow to locate the state
transition hook.
In `@components/voting/VotingHero.tsx`:
- Around line 600-612: The hero copy in VotingHero.tsx is still hardcoded to say
the winners “se llevaron los votos … de la comunidad” even when hasFinal is true
and the podium is based on the combined finalScore result. Update the
user-facing sentence in the VotingHero rendering logic to be conditional on
hasFinal, so the final-score mode mentions the combined popular/judge result in
Spanish while the fallback continues to reference votes; use the existing
hasFinal and period.results.final symbols to locate the copy.
---
Outside diff comments:
In `@app/api/hackathons/`[id]/voting/route.ts:
- Around line 811-832: The close-preview/reveal branch in the voting route
currently always uses the current timestamp when calling buildClosePreview,
which can make reveal-ballots include votes cast after the period actually
closed. Update the logic in the action handling block for CLOSE_PREVIEW_ACTION
and REVEAL_ACTION so that the reveal path uses existing.period.closedAt as the
reference time, while keeping the preview path on the current time. Use the
existing.period, buildClosePreview, and REVEAL_ACTION symbols to locate and
split the timestamp passed into the preview builder.
---
Nitpick comments:
In `@app/hackathons/`[id]/page.tsx:
- Around line 466-500: Gate the Premios-related data loading in the hackathon
page so it only runs when the card can actually render. In the page component
that computes `awards`, `prizeProfiles`, `prizeBadgeIssuerPubkey`,
`prizeBadgeCatalog`, and `prizeSoldierRecipients`, add the same
`!resultsPublished` check used by the Premios card before calling
`getCachedHackathonBadgePublisherPubkey`, `getCachedNostrProfile`, and
`getSoldiers`. Keep the existing `status === "closed"` logic, but skip all of
these lookups when results are already published.
In `@lib/useAdminLiveTally.ts`:
- Around line 37-44: The action names in useAdminLiveTally are duplicated as raw
strings, so update the client and API route to use shared exported constants
instead of re-deriving "close-preview" and "reveal-ballots". Move
CLOSE_PREVIEW_ACTION and REVEAL_ACTION into a common module such as
`@/lib/voting`, then import those values in useAdminLiveTally and in the voting
route so TypeScript can enforce the client/server contract and catch future
renames.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 82b2639e-dc9d-4916-8b0a-3204ca6a256e
📒 Files selected for processing (5)
app/api/hackathons/[id]/voting/route.tsapp/hackathons/[id]/VotingSection.tsxapp/hackathons/[id]/page.tsxcomponents/voting/VotingHero.tsxlib/useAdminLiveTally.ts
| // encrypted, so one decrypt round-trip (admin-gated, no publish) loads every | ||
| // voter's breakdown; we only fetch it the first time a voter is opened. Works | ||
| // both while open (`close-preview`) and after close (`reveal-ballots`). | ||
| const canReveal = isAdmin; | ||
| const tally = useAdminLiveTally(period.hackathonId, closed); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash# Check whether VotingDetailModal stays mounted across open/closed transitions# (i.e. is it conditionally rendered/unmounted on close, which would naturally reset hook state?)
rg -n "VotingDetailModal" app/hackathons -B5 -A10Repository: lacrypta/lacrypta-dev
Length of output: 3096
🏁 Script executed:
#!/bin/bashset -euo pipefail
# Inspect the relevant hook and modal implementation to determine whether the data can go stale on closed-state changes.
FILE="app/hackathons/[id]/VotingSection.tsx"# Show the hook and its callers around the relevant lines.
grep -n "function useAdminLiveTally\|toggleReveal\|refresh()\|perVoter\|results\|action\|closed""$FILE"| sed -n '1,120p'echoecho"---- VotingDetailModal section ----"
sed -n '774,930p'"$FILE"Repository: lacrypta/lacrypta-dev
Length of output: 9129
🏁 Script executed:
#!/bin/bashset -euo pipefail
# Confirm whether the modal is conditionally mounted and whether closed changes unmount/remount it.
FILE="app/hackathons/[id]/VotingSection.tsx"
sed -n '680,770p'"$FILE"Repository: lacrypta/lacrypta-dev
Length of output: 3374
🏁 Script executed:
#!/bin/bashset -euo pipefail
FILE="app/hackathons/[id]/VotingSection.tsx"# Inspect the hook, toggle logic, and modal implementation.
awk ' /function useAdminLiveTally|const canReveal|function VotingDetailModal|toggleReveal|refresh\(\)|perVoter|results|action|closed/ {print NR ":" $0}'"$FILE"| sed -n '1,220p'echoecho"---- around VotingDetailModal ----"
sed -n '774,930p'"$FILE"echoecho"---- around modal mount in parent ----"
sed -n '700,725p'"$FILE"Repository: lacrypta/lacrypta-dev
Length of output: 9912
🏁 Script executed:
#!/bin/bashset -euo pipefail
FILE="app/hackathons/[id]/VotingSection.tsx"# Inspect the hook, toggle logic, and modal mounting behavior.
rg -n "function useAdminLiveTally|toggleReveal|refresh\(\)|perVoter|results|action|closed|VotingDetailModal""$FILE" -A6 -B6
echoecho"---- modal parent mount ----"
sed -n '700,725p'"$FILE"echoecho"---- modal implementation ----"
sed -n '774,930p'"$FILE"Repository: lacrypta/lacrypta-dev
Length of output: 23087
🏁 Script executed:
#!/bin/bashset -euo pipefail
FILE="app/hackathons/[id]/VotingSection.tsx"# Inspect the live tally hook implementation and its dependencies.
sed -n '1,170p'"$FILE"echo
sed -n '170,430p'"$FILE"Repository: lacrypta/lacrypta-dev
Length of output: 13348
🏁 Script executed:
#!/bin/bashset -euo pipefail
FILE="app/hackathons/[id]/VotingSection.tsx"# Show the hook definition and the refresh logic with enough surrounding context.
sed -n '430,620p'"$FILE"Repository: lacrypta/lacrypta-dev
Length of output: 5684
🏁 Script executed:
#!/bin/bashset -euo pipefail
FILE="app/hackathons/[id]/VotingSection.tsx"# Check whether the hook's request key includes `closed` or only the action name.
rg -n "useAdminLiveTally|close-preview|reveal-ballots|refresh:|refresh\(|action:""$FILE" -A4 -B4Repository: lacrypta/lacrypta-dev
Length of output: 2909
🏁 Script executed:
#!/bin/bashset -euo pipefail
FILE="app/hackathons/[id]/VotingSection.tsx"# Inspect the hook implementation and surrounding helpers to determine whether# a closed/open transition changes the fetched action or can leave cached data in place.
sed -n '430,620p'"$FILE"Repository: lacrypta/lacrypta-dev
Length of output: 5684
🏁 Script executed:
#!/bin/bashset -euo pipefail
FILE="lib/useAdminLiveTally.ts"# Show the hook implementation and any refresh/request-key logic.
sed -n '1,260p'"$FILE"Repository: lacrypta/lacrypta-dev
Length of output: 4177
Refresh the admin tally when the period status flips
VotingDetailModal stays mounted across the open→closed transition, but useAdminLiveTally() only refreshes on the first row expansion. If an admin already loaded perVoter during close-preview, the modal can keep showing that pre-close snapshot after the UI switches to reveal-ballots. Trigger a refresh on closed changes when tally data already exists, or clear the loaded tally on status change.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@app/hackathons/`[id]/VotingSection.tsx around lines 802 - 806, The admin
tally in VotingSection/VotingDetailModal is not refreshed when the period status
changes from open to closed, so stale perVoter data can persist across the
transition. Update the logic around useAdminLiveTally and the modal’s
open/closed handling so that a closed-state flip triggers a refresh or clears
the existing tally when data is already loaded; use the canReveal, tally, and
VotingDetailModal flow to locate the state transition hook.
| // The podium reflects the DEFINITIVE result: the combined 70/30 ranking when | ||
| // judges' scores were merged (headline metric = final score), else the raw | ||
| // popular vote (metric = votes). The detailed breakdown table renders below. | ||
| const hasFinal = | ||
| !!period.results?.final && period.results.final.length > 0; | ||
| // Up to 6 prize positions; the top 3 go on the podium, 4–6 in the list below. | ||
| const winners = (period.results?.winners ?? []).slice(0, 6); | ||
| const podium = winners.slice(0, 3); | ||
| const runnersUp = winners.slice(3, 6); | ||
| const entries: PodiumEntry[] = hasFinal | ||
| ? period.results!.final!.slice(0, 6).map((r) => ({ | ||
| position: r.position, | ||
| projectId: r.projectId, | ||
| projectName: r.name, | ||
| metric: `${r.finalScore.toFixed(1)} pts`, | ||
| })) |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Align the hero copy with the combined-score mode.
When hasFinal is true, the podium now shows the 70/30 final score, but the visible hero text still says these projects “se llevaron los votos … de la comunidad.” Consider making that sentence conditional so final-score results mention the combined popular/judge result instead of only votes. Keep the replacement user-facing copy in Spanish. As per coding guidelines, “User-facing copy must be in Spanish (lang="es", locale es_AR); identifiers and code comments are English.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@components/voting/VotingHero.tsx` around lines 600 - 612, The hero copy in
VotingHero.tsx is still hardcoded to say the winners “se llevaron los votos … de
la comunidad” even when hasFinal is true and the podium is based on the combined
finalScore result. Update the user-facing sentence in the VotingHero rendering
logic to be conditional on hasFinal, so the final-score mode mentions the
combined popular/judge result in Spanish while the fallback continues to
reference votes; use the existing hasFinal and period.results.final symbols to
locate the copy.
Source: Coding guidelines
Continúa el trabajo de votación comunitaria ya mergeado (#47, #48). Tres mejoras al cierre de la votación, verificadas end-to-end en dev (relay local).
1. El admin puede ver por quién votó cada uno — también con la votación CERRADA
Antes el revelado por votante solo funcionaba con la votación abierta.
route.ts: nueva acción adminreveal-ballots— descifra y devuelve los votos por persona igual queclose-preview, pero permite el período cerrado (no publica nada).useAdminLiveTally(hackathonId, closed): firmareveal-ballotscuando está cerrada,close-previewcuando está abierta.VotingProvider: suscribe a ballots también cuando la votación está cerrada y sos admin, para que el padrón sepa quién votó (los usuarios normales no suscriben en cerrado).VotingDetailModal:canReveal = isAdmin(antes excluía cerrado) + copy del footer.Los votos siguen cifrados en el relay; el descifrado es server-side con
LACRYPTA_NSEC, solo visible para el admin.2. El podio del hero cerrado refleja el RESULTADO FINAL (70/30), no el voto popular
ClosedHeroarma las entradas del podio (PodiumEntry) desderesults.finalcuando hay jueces → orden = ranking combinado, métrica = score final ("21.1 pts"). Sin jueces cae al voto popular (métrica = "X votos").PodiumCard/RunnerRowpasaron deVotingWinneraPodiumEntrycon métrica pre-formateada.Ej.: ZapChess tenía más votos populares (1° popular) pero queda #4 en el final; SatArcade es el ganador real (21.1).
3. Se oculta la sección genérica "Premios" cuando hay resultado publicado
app/hackathons/[id]/page.tsx— cuando la votación cerró con resultado (resultsPublished), se oculta la card "Premios" (estructura genérica 250k/400k/…) porque el resultado final ya muestra el premio de cada proyecto.Verificación
tsc --noEmitsin errores.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes