Skip to content

Conversation

@vcarl
Copy link
Member

@vcarl vcarl commented Dec 10, 2025

  • Add a "require majority" button that removes the the automatic execution vote threshold, and instead executes the resolution with a plurality of votes.
  • Slow down resolution timer. Starting at 24hr is too fast, too few votes to get it down to immediate execution.
    • Extend the vote lifespan, defaulting to 36 hours.
    • Shorten per-vote acceleration, from 8hr to 4hr. This means after 4 votes, the default behavior will execute after 36hr - (4vote * 4hr) = 20hr
  • Add a second-tier "escalate" that requires a minimum time after escalation, then executes the majority vote.
  • Post result as a new message, forward it to #mod-log
  • Disable voting when resolution is executed, but keep buttons.

vcarl and others added 8 commits December 17, 2025 13:55
- simple (default): Early resolution when any option hits quorum (3 votes)
- majority: No early resolution; voting stays open until timeout, plurality wins

Changes:
- Add voting_strategy column to escalations table
- Add shouldTriggerEarlyResolution() to check strategy before triggering
- Update handlers to set strategy based on escalation level (0=simple, 1+=majority)
- Update UI to show strategy-specific status and hide "Require majority" when active
- Simplify escalationResolver since both strategies resolve identically on timeout

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
Documents Discord API mocking challenges, time-dependent behavior,
multi-actor workflows, and proposes solutions including pure logic
extraction and time abstraction.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
Update test expectations for the new timeout formula:
max(0, 36 - 4 * (voteCount - 1))

- 0 votes = 40h (was 24h)
- 1 vote = 36h (was 16h)
- 2 votes = 32h (was 8h)
- 3 votes = 28h (was 0h)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
All these were implicitly testing the same voting logic, but with various layers of indirection in pulling out the output. Not helpful, not worth keeping
Replace dynamic timeout calculation on every poll with a stored
scheduled_for timestamp. The column is updated whenever votes change,
making the resolver query a simple indexed lookup instead of requiring
vote tallies for every pending escalation.

- Add migration with backfill for existing pending escalations
- Add calculateScheduledFor, updateScheduledFor, getDueEscalations
- Update vote/escalate handlers to persist new scheduled time
- Simplify resolver to query due escalations directly

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
Simplify function signatures by passing the escalation object instead
of individual fields. This makes the code cleaner and allows direct
use of scheduled_for for Discord timestamps instead of recalculating.

- buildVoteMessageContent now takes (modRoleId, escalation, tally, votingStrategy)
- buildConfirmedMessageContent now takes (escalation, resolution, tally)
- Update all call sites in handlers.ts
- Update tests with mock escalation helper

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
- Add getDisabledButtons helper to disable vote buttons on resolution
- Handle edge case where user left server or deleted account
- Forward resolution notices to mod log channel
- Clean up resolution message format with consistent timestamp display

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant