Skip to content

Export the recent two-hour pace beside the conservative burn - #1090

Merged
1 commit merged into
mainfrom
work/1085-recent-burn
Nov 8, 2026
Merged

1 commit merged into
mainfrom
work/1085-recent-burn

Conversation

@shiny-code-app

@shiny-code-app shiny-code-app Bot commented Nov 8, 2026

Copy link
Copy Markdown
Contributor

Why

The Supervisor steers each account to its reset with a check every 30 minutes. The exported burn is the higher of the last day's and last six hours' pace, so it kept reading 1.25%/h for two hours after an account stopped. That is right for the panel's "am I safe" warnings, and wrong for "what is the pace now".

What changed

  • Each agent snapshot window gains recentBurn, a sibling of burn with the same shape: {unitsPerHour, observedDurationHours, sampleCount}, or null. It measures only the last two hours.
  • burn is unchanged. Use next, warnings and the pace forecast still read it.
  • Window length: 2 hours. At 5-minute readings, two hours gives about 24 intervals and close to 2 hours of observation. That clears the estimator's minimums (30 minutes of observation, two usable intervals) many times over. The same minimums apply, so it is null when the last two hours have too few readings, for example after the Mac slept. Like burn, it is never a whole-window average.
  • It is the existing estimator with a shorter lookback (AccountBurnRateEstimator.observedBurnRates(..., recentOnly:)), not a new estimator. It is filled on both the local and the shared-presentation export paths. It uses the same last-day history the reader already loads.
  • The two burn constructions now share one Burn(_:) initializer that drops unmeasured rates.
  • Documented in the agent snapshot section of docs/provider-usage-access.md.

Verification

  • swift build: clean.
  • swift test --filter ContextPanelCoreTests: 1359 passed.
  • New test, local and shared paths: a batch at 3 points an hour that stopped two hours ago exports burn 2/h (unchanged) and recentBurn 0/h over 2 hours with 25 samples. With no readings in the last two hours, burn stands and recentBurn is null. It fails if the recent pass uses the long lookback, if the shared path drops it, or if burn reads the recent rate (3 mutations, all caught).
  • JetBrains inspection: UNKNOWN. This repository's worker is PyCharm and has no Swift or Markdown coverage.

Removed: the two inline Burn(unitsPerHour:...) constructions, now one initializer.
Net lines: Sources +29, Tests +39, docs +8.

Closes #1085

…1085)

Each agent snapshot window gains recentBurn: the pace over only the last two
hours, with its own units per hour, observed duration and sample count, null
with too few recent readings. burn stays the conservative maximum the panel's
warnings and Use next read.
@shiny-code-app

shiny-code-app Bot commented Nov 8, 2026

Copy link
Copy Markdown
Contributor Author

Ready for the merge train

Head: 303d887

@shiny-code-app

shiny-code-app Bot commented Nov 8, 2026 •

Copy link
Copy Markdown
Contributor Author

Launchplane completed the merge-train step for this pull request.

Launchplane landed this pull request through protected batch PR #1091.

Launchplane manages this comment and will update it as the train moves.

@shiny-code-app

shiny-code-app Bot commented Nov 8, 2026

Copy link
Copy Markdown
Contributor Author

Ready for the merge train

Head: 303d887

@shiny-code-app shiny-code-app Bot closed this pull request by merging all changes into main in 4b1fe69 Nov 8, 2026
@shiny-code-app
shiny-code-app Bot deleted the work/1085-recent-burn branch November 8, 2026 23:02
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.

Export the recent burn estimate beside the conservative one

0 participants