Skip to content

fix(WhereUI): guard Settings navigation footprints - #260

Open
kyleve wants to merge 2 commits into
mainfrom
codex/guard-settings-navigation-footprints
Open

fix(WhereUI): guard Settings navigation footprints#260
kyleve wants to merge 2 commits into
mainfrom
codex/guard-settings-navigation-footprints

Conversation

@kyleve

@kyleve kyleve commented Aug 13, 2026

Copy link
Copy Markdown
Owner

Posted by an AI agent on kve's behalf.

Summary

  • add a DEBUG-only heuristic tripwire for oversized concrete content crossing SettingsFocusScope
  • render typed Settings destinations through a nominal SettingsRouteView while preserving the production stack's heterogeneous navigation
  • exercise every push destination plus nested Evidence and archive routes from one production-shaped app scope
  • document nominal child-view extraction as a UI construction defense for agents

Why

The Estimated Time & Planning feature page pushed a large declarative view value over the device stack limit while SwiftUI applied environment values during navigation. The first guard attempt then exposed two problems of its own: its homogeneous [SettingsRoute] test seam prevented child destinations from pushing other value types, and its heuristic size check would have remained an intentional Release crash.

Review focus

  • The 56 KiB threshold is deliberately DEBUG-only. It is a deterministic CI tripwire between the measured 46,912-byte survivor and 62,680-byte failure, not a portable ABI guarantee.
  • Production keeps an unbound NavigationStack, so Evidence and ShareEvidenceFeaturesView.Route can coexist with SettingsRoute.
  • SettingsRouteViewTests owns a heterogeneous NavigationPath, covers every non-sheet destination, and proves both nested route types reach a third navigation level.
  • The test fixture derives its model, session, report, backup, and reminders from one loaded scope, matching production ownership.
  • Route rendering is a production child view; no test-only SettingsView initializer ships or needs SPI exposure.

Compatibility

No persisted data, user-visible behavior, or Release precondition changes. The child PR is stacked on #252 because that feature page supplied the concrete tree that reproduced the crash.

Testing

  • ./swiftformat --lint
  • ./test WhereUITests — 432 tests passed
  • ./test --only 'WhereUITests/SettingsRouteViewTests' — 3 tests and 14 destination arguments passed without the homogeneous-path warning
  • ./test --snapshots — 43 suites passed without recording references
  • after merging latest main, WhereFormatTests passed 27 tests and the Calendar/Year snapshot suites both passed

Stack

@kyleve kyleve changed the title codex/guard settings navigation footprints fix(WhereUI): guard Settings navigation footprints Aug 13, 2026
/// (46,912 bytes) from the 62,680-byte concrete value that overflowed a
/// device stack while SwiftUI applied this scope's environment during a
/// navigation push. Large trees belong behind a small nominal child view.
static var maximumContentFootprint: Int {

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Posted by an AI agent on kve's behalf.\n\nThis threshold is intentionally a DEBUG/CI heuristic, not a portable ABI boundary. If a future destination trips it, extract the large declarative subtree behind a nominal child view rather than raising the threshold; Release deliberately has no corresponding precondition.

Base automatically changed from codex/improve-estimated-time-planning to main August 13, 2026 19:00
@kyleve
kyleve force-pushed the codex/guard-settings-navigation-footprints branch from 6d0a17b to 2aee2fa Compare August 13, 2026 19:00
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