Document the advanced duration default as 2 days - #6
Conversation
The advanced auction window changed from 7 days to 2 days when its timelock executed. SPEC.md and AGENTS.md still described 7d as the default, and `02_DeployFactory` fell back to `7 days` when ADVANCED_DURATION was unset — the same drift the graduation fallback had. The 2-14 day admin range is unchanged, as is the immutable 24-hour ADVANCED_START_DELAY. Test fixtures that pass `advancedDuration: 7 days` explicitly are left alone: they construct their own params and round-trip them, so they assert behaviour rather than the shipped default, and 7 days is still a legal value.
PR SummaryLow Risk Overview Updates: No Solidity or test changes; explicit Reviewed by Cursor Bugbot for commit 7e2c5aa. Configure here. |
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 58 minutes Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
Comment |
1 participant
The advanced auction window changed from 7 days to 2 days when its timelock executed (
advancedDuration()= 172800s on all four chains). The 2-14 day admin range is unchanged, as is the immutable 24-hourADVANCED_START_DELAY.Changes
SPEC.md:55— presale-duration rowSPEC.md:186— the launch-lifecycle mermaid diagram, which readcontribution window (24h / 7d)AGENTS.md:56— the ADVANCED summary linescript/02_DeployFactory.s.sol:53—vm.envOr("ADVANCED_DURATION", 7 days)→2 daysThat last one is the same class of drift caught on the graduation fallback in #5: with the docs saying 2d and the script defaulting to 7d, a deployment relying on documented defaults would have got a window 3.5× too long.
Deliberately unchanged
Five test/script fixtures pass
advancedDuration: 7 daysexplicitly:script/test/DryRunAll.s.sol:100·test/unit/DeployConfigs.t.sol:102·test/unit/LaunchFactory.t.sol:186·test/integration/IntegrationBase.t.sol:399·test/unit/PresaleManager.t.sol:395Each constructs its own
FactoryParamsand round-trips the value —LaunchFactory.t.sol:368assertsfactory.advancedDuration() == ADVANCED_DURATIONagainst the test's own constant, not the shipped default. They assert behaviour, and 7 days is still legal inside the 2-14 day range. Same reasoning applied to the5 etherfixtures in #5.forge buildandtest/unit/DeployConfigs.t.sol(9 tests) pass.Note
CLAUDE.mdand.cursor/rules/boardwalk.mdccarry the same stale ADVANCED line but are gitignored here, so they cannot ride this PR. I updated them locally; anyone else's checkout will still teach agents 7d until they refresh.