Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration

[lightcloud00]

What

The Park screen now drives two always-on TimelineView(.periodic(from: .now, by: 1)):

• MeterHero — the countdown, its progress bar, and the state evaluation;
• detailsCard — the "Parked for h:mm:ss" line.

Both tick every second for as long as the screen is open, and the hero's tick re-evaluates MeterState and re-renders a ProgressView. The elapsed timer predates the redesign; the hero is new, so the screen now does roughly twice the per-second work it used to.

Why it may matter here specifically

This is a screen people leave open while walking back to a car — outdoors, on cellular, often on a phone that has been out all day. It is close to the worst case for an always-on 1 Hz redraw.

What has not been established

Nothing has been measured. This is a flagged concern, not a demonstrated defect:

• no Instruments trace of the Park screen idling with a meter set;
• no comparison against the pre-redesign single timer;
• no check of what Low Power Mode should do.

AGENTS.md requires Reduce Motion support. A per-second numeric update is arguably not "motion", but a continuously animating progress bar is closer to the line, and the question has not been asked.

Suggested approach

Measure first. If it is negligible, close this with the number and stop worrying about it. If it is not:

• one TimelineView for the whole screen instead of two;
• drop to .periodic(by: 60) once the remaining time is over an hour, where seconds carry no information;
• consider @Environment(\.accessibilityReduceMotion) for the progress bar's animation only, never for the countdown itself — suppressing the number would remove information rather than motion.

Acceptance

• Idle CPU/energy measured with a meter running, and recorded here.
• Compared against the single-timer baseline.
• Either closed with the measurement, or reduced and re-measured.

Resolution plan

• Verified: 2026-08-25T04:51:19Z against main@04a6cd5e808720983471ee9595fd40bc94e1f0fe (commit time 2026-08-25T00:53:29Z).
• Source basis: Original issue body, all 0 comment(s), current default-branch tree, referenced pull-request states, and the protected top-90 dossier revalidated without modifying it.
• Disposition: Code or verification work - not complete on the verified default branch.
• Outcome: Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration

Current evidence and corrected premise

Verdict — NOT_STARTED. Two exact sites confirmed.

ParkNudge/UI/Park/ParkView.swift:

:162    TimelineView(.periodic(from: .now, by: 1)) { context in
:319    TimelineView(.periodic(from: .now, by: 1)) { context in

Two independent 1 Hz timelines in one screen. Each rebuilds its subtree every second for as long as
the view is on screen, regardless of whether anything visible changed, whether the device is in Low
Power Mode, or whether the user has asked for Reduce Motion.
P2 · accessibility, area: ios, priority:p2, revenue:r3 · Canonical source: origin/main
All 0 issue comment(s) were read. There are no comments.
Verified source paths on this head:

• AGENTS.md
• ParkNudge/UI/Park/ParkView.swift
• ParkNudgeTests/MeterStateTests.swift

Resolution steps

Exact fix

1. Drop the cadence when seconds are not visible. If the label reads "2h 14m", a 1 Hz tick is
   ~119 wasted rebuilds per minute. Use .periodic(by: 1) only while the remaining time is under a
   minute (or whatever threshold makes the seconds digit meaningful); otherwise by: 60. This alone
   removes almost all of the cost.
2. Honour Low Power Mode — ProcessInfo.processInfo.isLowPowerModeEnabled, and observe
   .NSProcessInfoPowerStateDidChange so it reacts rather than sampling once at launch.
3. Honour Reduce Motion — @Environment(\.accessibilityReduceMotion). Where the timeline drives
   an animation rather than a text update, this should stop it entirely, not slow it.
4. Collapse the two timelines into one if both drive the same clock. Two independent periodic
   sources in one view means two rebuild storms with no shared phase.

Keep the countdown correct — recompute from a stored expiry Date, never by decrementing a
counter, so a slower tick or a missed one cannot drift.

Tests and acceptance

Test / proof

ParkNudgeTests/MeterStateTests.swift already tests the state transitions; extend the same seam
with a test that the chosen tick interval is 60 when remaining time is large and 1 when small.
Battery behaviour itself is not unit-testable — verify by observing that the view body evaluates at
the expected cadence (a counter incremented in the timeline closure under test).

Gate — the repo's unit scheme

• For every listed xcodebuild argv, submit the equivalent focused job through the shared fleet-build gate after iOS capacity admission; do not run xcodebuild directly.

Dependencies and stop gates

Out of scope — #29's meter hero states; general animation policy elsewhere in the app

• Do not close this issue until every acceptance item is mapped to exact merged-head evidence.

Next AI first action

Drop the cadence when seconds are not visible.** If the label reads "2h 14m", a 1 Hz tick is

[lightcloud00]

Verified issue disposition — diagnostic

This is the current managed disposition for lightcloud00/parknudge#32 at default-branch 5c3d185143a2.

Current evidence

• Current stable snapshot for Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32 at 5c3d185143a2 keeps the issue open with body hash 5e15d5ac022a; the validated grounded planner classified it as diagnostic_ready.

Files or owner actions

• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32, inspect and change only ParkNudge/UI/Park/ParkView.swift after confirming it exists at the recorded SHA.
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32, inspect and change only ParkNudgeTests/MeterStateTests.swift after confirming it exists at the recorded SHA.
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32, inspect and change only {'content_sha256': 'sha256:e279290014daebb1d791caf359111701fda1e8b517c7e2d38e04a8452a77ba55', 'decode_state': 'content_hashed', 'decoded_bytes': 15196, 'default_branch': 'main', 'git_blob_sha': '7a516f49673fc7dea82b9c44408dfceb857ad1c4', 'github_size': 15196, 'matched_issue_hints': ['Date', 'MeterHero', 'MeterState', 'Park', 'ProgressView', 'TimelineView', 'detailsCard', 'screen'], 'path': 'ParkNudge/UI/Park/ParkView.swift', 'state': 'inspected'} after confirming it exists at the recorded SHA.
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32, inspect and change only {'content_sha256': 'sha256:3cce7818c84f5d558d5013b442e76542f4a5d03a4fb88ff87cdce9c1439a5a6f', 'decode_state': 'content_hashed', 'decoded_bytes': 5378, 'default_branch': 'main', 'git_blob_sha': '11aa1ac737f5d377234cade98970100d79a94339', 'github_size': 5378, 'matched_issue_hints': ['Date', 'MeterState', 'Park'], 'path': 'ParkNudgeTests/MeterStateTests.swift', 'state': 'inspected'} after confirming it exists at the recorded SHA.

Bounded plan

• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: Use the recorded read-only Git blob identities as the source starting point; create a detached task-temporary clone only if implementation requires broader inspection.
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: Record the canonical checkout, task branch/base SHA, source tree, issue body hash, and pre-existing owner dirt.
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: Reproduce the reported behavior and constrain the change to the issue-named surfaces: ParkNudge/UI/Park/ParkView.swift, ParkNudgeTests/MeterStateTests.swift, AGENTS.md, Date, MeterHero, MeterState, ProcessInfo.processInfo.isLowPowerModeEnabled, ProgressView.
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: Implement the smallest source change satisfying the issue-authored acceptance context while preserving unrelated behavior and dirt.
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: Run focused verification, then the broader gate: python3 -m pytest -q.
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: Capture exact diff, source identity before/after, test results, rollback boundary, and independent-peer state.

Commands

• Run git grep -n -F AGENTS.md main for Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32 and retain sanitized output.
• Run git grep -n -F Date main for Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32 and retain sanitized output.
• Run git grep -n -F MeterHero main for Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32 and retain sanitized output.
• Run git grep -n -F MeterState main for Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32 and retain sanitized output.
• Run git grep -n -F ProcessInfo.processInfo.isLowPowerModeEnabled main for Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32 and retain sanitized output.
• Run python3 -m pytest -q for Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32 and retain sanitized output.

Acceptance tests

• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: [ ] Idle CPU/energy measured with a meter running, and recorded here.
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: [ ] Compared against the single-timer baseline.
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: [ ] Either closed with the measurement, or reduced and re-measured.
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: For every listed xcodebuild argv, submit the equivalent focused job through the shared fleet-build gate after iOS capacity admission; do not run xcodebuild directly.

Risks

• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32, a false source binding could widen the change or invalidate this plan; Revert only the exact task-branch change after capturing source and runtime identity; never reset or restore an owner worktree.

Stop gates

• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: no issue close, reopen, body edit, pull-request, branch, or merge mutation while implementing this plan
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: the managed plan comment and disposition-specific readiness labels are the only authorized issue mutations in the planning lane
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: no push, protected-branch update, force-push, or merge
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: no deploy, upload, App Store Connect, TestFlight, or public release
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: no credential value disclosure, rotation, billing, or provider change
• For Park screen redraws at 1 Hz whenever it is open, with no low-power or Reduce Motion consideration #32: no owner-worktree restore, reset, checkout, process signal, or queue reorder

---

Ledger schema: aos.github-issue-plan-coverage.v1 · issue body: 5e15d5ac022a

[lightcloud00]

Implementation checkpoint, 2026-08-25:

• Root cause reproduced: the active Park surface used a periodic timeline with a fixed one-second cadence, independent of meter phase, Low Power Mode, or Reduce Motion.
• Clean isolated candidate f08faad995f325ce24b30d28aa4722a4bbeb805e is rebased onto current main@460aa110a8edebafc4a855dda2c81dcf17bf12a5.
• The candidate centralizes cadence policy, slows non-critical/low-power/reduced-motion updates, preserves time-sensitive meter transitions, and adds deterministic policy and meter-state coverage.
• Source gates pass: XcodeGen double-generation idempotence, website checks for 9 pages, privacy/store JSON validation, shell syntax, Swift parsing, and git diff --check.

Issue #32 remains open. Exact blockers: the occupied shared iOS lane prevents the required exact-head native suite, and acceptance still requires device energy measurement against the one-second baseline. Owner: repository delivery lane for native proof; Gus for physical-device energy acceptance. Next safe action: one coordinator-routed verifier after two safe capacity samples, then device-only measurement without inferring release authority.

[lightcloud00]

Self-review correction, 2026-08-25:

The earlier local head f08faad995f325ce24b30d28aa4722a4bbeb805e handled Low Power Mode but only disabled progress animation for Reduce Motion; it did not lower the timeline cadence. That gap is now fixed in amended clean head 8176b9f7f69417d2fae5111dc8d34518abecfb9b.

ParkTimelineCadence now treats Low Power Mode and Reduce Motion as independent reasons to use minute-level updates, and ParkTimelineSchedule carries both settings through every adaptive entry. Two additional tests pin Reduce Motion policy and schedule behavior near expiry. Exact-head source revalidation is green: XcodeGen double-generation fingerprint 4445e11be487e4da40ae81c85faf79108baaa9dac140f7e9414d87adda7ca00e, 9-page website gate, privacy/store JSON, shell syntax, Swift parsing, and git diff --check; the branch is clean.

Issue #32 remains open. Exact blockers are unchanged: one coordinator-routed native suite after shared admission, followed by physical-device energy comparison against the one-second baseline. No push, PR, direct xcodebuild, simulator mutation, device claim, ASC action, or release occurred.

[lightcloud00]

Exact-head implementation checkpoint, 2026-08-26:

• Clean candidate fc8ecc08c8ce844610eaad0124b1d941747d99cc (tree ff72fd57001e946bc72765ece8f9d708b02b9094) replaces the two independent one-second timelines with one adaptive wall-clock schedule shared by the meter hero and parked-for line.
• Cadence is computed from absolute dates, uses whole-minute presentation outside the urgent window, responds to Low Power Mode changes, and treats Reduce Motion independently while disabling progress animation.
• Deterministic policy/schedule tests cover long, urgent, recently expired, Low Power, Reduce Motion, and no-meter cases; an injected UI-test Low Power override is scoped behind -ui-testing.
• Exact-head source gates are green: XcodeGen double-generation fingerprint 37637bc74542784933c6488e8b631ac09d6cfd09b9a60ace7f065c630be4358d, nine-page website audit, privacy/StoreKit validation, Swift parsing, and git diff --check.
• The required repository verifier is submitted once through the shared fleet gate as job 20260826T012800Z-codex-app-f76a2d; it is queued behind earlier owners and has not started.

This issue remains open. Native exact-head proof is pending, and the acceptance item requiring a physical-device idle CPU/energy comparison against the one-second baseline remains Gus-owned. No simulator result is being promoted to a physical-device energy claim. No direct xcodebuild, push, PR, merge, deployment, ASC upload, review submission, or release occurred at this checkpoint.

[lightcloud00]

Queue checkpoint correction — 2026-08-25 ET

The first exact-head job 20260826T012800Z-codex-app-f76a2d was canceled while still queued during a bounded review of the test-only launch path. That review confirmed the path was already correctly scoped: AppEnvironment.make() only reaches the meter seeder from the -ui-testing branch and uses an in-memory container. No source change was needed.

One replacement job is now queued:

• job: 20260826T020525Z-codex-app-4f862f
• command: bash scripts/verify.sh
• exact clean head: fc8ecc08c8ce844610eaad0124b1d941747d99cc
• tree: ff72fd57001e946bc72765ece8f9d708b02b9094

The issue remains open. No duplicate live job, direct xcodebuild, push, PR, merge, Pages deployment, build upload, Sandbox claim, or release occurred.