You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement Reject bets at exact deadline boundaries deterministically as a production-ready change in Predictify-org/predictify-contracts.
Why this matters
The implementation must be deterministic and reviewable so normal operation and adverse conditions do not cause silent data loss, inconsistent state, security regressions, or an unrecoverable user experience. This issue specifically requires state-transition and authorization invariants, including replay and boundary behavior.
Scope
Trace the relevant entry points, state model, and failure paths; implement the smallest complete design; preserve public interfaces unless a compatibility plan is included; and document important invariants in code.
Priority
High
Acceptance criteria
The intended behavior is deterministic for valid, invalid, duplicate, and boundary-case inputs.
Authorization, validation, and state-transition invariants remain enforced.
Retries, partial failure, and concurrent execution cannot produce an unsafe or inconsistent result.
Focused tests cover success, rejection, boundary, and regression scenarios.
Existing callers remain compatible, or the PR includes a tested migration path.
Relevant logs, metrics, or user-visible errors make failures diagnosable without exposing sensitive data.
Validation
Run focused tests and repository CI checks with evidence for normal operation, invalid input, retries, concurrency or timing boundaries, and failure recovery where applicable.
Non-goals
Typo-only, formatting-only, documentation-only, or cosmetic changes.
Unrelated refactors, dependency upgrades, or broad rewrites.
Removing safeguards or weakening validation to make tests pass.
Contributor application
Before coding, describe affected modules, proposed state/invariant changes, test strategy, compatibility considerations, and an estimate. Wait for assignment before starting implementation.
PR requirements
Use a feature branch and include Closes #<issue-number>. Address every criterion, map criteria to code and tests, explain security and failure-mode handling, and ensure CI passes.
Quality review
A maintainer will assess correctness, completeness, test depth, compatibility, observability, and adverse-case handling. A substantive implementation is required; merge or CI status alone does not guarantee reward eligibility.
Summary
Implement Reject bets at exact deadline boundaries deterministically as a production-ready change in
Predictify-org/predictify-contracts.Why this matters
The implementation must be deterministic and reviewable so normal operation and adverse conditions do not cause silent data loss, inconsistent state, security regressions, or an unrecoverable user experience. This issue specifically requires state-transition and authorization invariants, including replay and boundary behavior.
Scope
Trace the relevant entry points, state model, and failure paths; implement the smallest complete design; preserve public interfaces unless a compatibility plan is included; and document important invariants in code.
Priority
High
Acceptance criteria
Validation
Run focused tests and repository CI checks with evidence for normal operation, invalid input, retries, concurrency or timing boundaries, and failure recovery where applicable.
Non-goals
Contributor application
Before coding, describe affected modules, proposed state/invariant changes, test strategy, compatibility considerations, and an estimate. Wait for assignment before starting implementation.
PR requirements
Use a feature branch and include
Closes #<issue-number>. Address every criterion, map criteria to code and tests, explain security and failure-mode handling, and ensure CI passes.Quality review
A maintainer will assess correctness, completeness, test depth, compatibility, observability, and adverse-case handling. A substantive implementation is required; merge or CI status alone does not guarantee reward eligibility.