Let users shape future household-load estimates from the iPhone #1737

The owner wants to shape the future household-load curve with a finger in the iPhone Load view. The user may know that they will be home tomorrow or away next week, including on a new site before FTW has learned its load. Keep this out of the upcoming beta. This issue records the proposed scope and delivery; it does not claim that the feature has shipped.

Proposed experience

• Keep history, now and the future on the continuous timeline in Join iOS history and live in one timeline ftw-app#93. Preserve pan, pinch, held-point readings and Back to now.
• Add a small Forma / Shape action in the expanded Load view. In that mode, a drag raises or lowers the nearby future curve with a smooth falloff. Freeze the time window, y scale and brush width for the gesture so the curve stays under the finger. A wider time view changes a wider span without a brush-size setting.
• Allow moving through days and a week view. Start with a proposed 14-day editable range so a full trip next week fits; keep that bound explicit in the contract. This is separate from the current planning horizon and from available market prices.
• Keep the original estimate faintly visible. Label the modified span as Din uppskattning / Your estimate. Future curves keep forecast styling, without live motion or glow. Preserve gaps and source intervals; smooth drawing must not change the energy represented by interval means.
• Offer Undo for the last gesture and Reset for the shown future day/range. Reset removes that range's user input and reads the current automatic forecast. It must never call the existing forecast-learning reset API.
• Make an immediate local preview. On release, send one bounded, atomic patch for affected intervals. Show pending, accepted and failed writes; show that the plan changed only after Core publishes the matching revision. Cancelling a gesture restores the prior draft.
• Support VoiceOver and non-drag adjustments through time selection and increase/decrease actions. Use Swedish and English words, Dynamic Type and Reduce Motion. Apple's adjustable actions cover the native control pattern. Confirm the gesture choice in the simulator and on an iPhone.

The user supplies an expected household demand. The feature does not schedule or directly control appliances. Only household load can be shaped in this scope; solar keeps its data-based forecast.

Core owns the saved input

The current Core pipeline resolves the base forecast in go/internal/mpc/service.go, captures forecast inputs, overlays fresh household measurements on the in-flight interval, and then applies input recovery, forecast caution and plan validation. The normal fallback horizon is 48 hours; available price/input coverage can shorten it. A saved change further ahead must wait until that time enters the usable planning horizon. The app must not imply that next week's prices or dispatch plan already exist.

Store explicit target watts for edited, future UTC intervals, separately from the learned model and measured history. Prefer watts to a percentage so a zero starting estimate can be raised. Unedited intervals continue to follow the automatic forecast. Each edit expires with its finite interval; no implicit weekly recurrence or permanent profile change.

Use the same household-load basis as the planner. telemetry/forecast.go removes battery, EV and V2X flows from the complete site balance. Do not add planned charging a second time. The display basis needs an explicit review alongside srcfl/ftw-app#94 before connecting the editor to the node view.

Persist the edits on the box through go/internal/state, including a revision, time interval, target watts, author identity and change time. Persist before reporting acceptance. Keep them through a box restart and the phone closing or disconnecting. Expired intervals no longer affect planning and need a bounded retention policy.

Compose the future edits after base-forecast selection and before planner input snapshots, uncertainty handling and plan construction. Preserve the unmodified base separately for reset, diagnosis and model scoring. Fresh measurements retain authority over the current interval. Apply the same effective load to the active planner and its safe fallback. Existing fuse, SoC, equipment, freshness and command checks still run.

Do not train on user targets as measurements. Keep base-model error and effective/user-adjusted error separate. An edit does not assert zero uncertainty. Define how the uncertainty bands move around a target and retain their ordering and nonnegative load bounds. Archive the base issue, edit revision and effective input together for reproducible replay. Do not reset learned state on every edit.

At cold start, Core must provide a clearly marked starting estimate across the editable range. Missing measurements remain missing. This must be useful without several days of observations and must permit absolute edits even when the starting load is zero.

Use the existing app-to-box session

Reuse the authenticated encrypted session carried through FTW Cloud. No new service, phone-side solver or direct hardware path is needed. Review a bounded API write over the existing API channel; register its capability, permission, operations and errors before using it. The canonical registry lives in srcfl/ftw-webapp, with byte-identical copies in Core and the native app. Current invitation/setup PRs have right of way on that file.

The contract needs reads of base/effective forecasts and saved edit state, an atomic patch, and a range reset. Exact wire names remain open until the paired implementation PRs. Define limits for future range, interval count, payload size and finite nonnegative watts; reject invalid input as a whole rather than silently dropping pieces. Aggregate interval overlaps by duration so a target retains its energy when planner slot widths differ.

Use the saved-edit revision for compare-and-set, separate from the changing base-forecast issue ID. Two phones must not overwrite each other. Include a mutation ID and replay-safe result so a timeout after a durable write cannot double-apply an edit. Undo after acceptance is a new checked write, not a full stale-document replacement. Read-only viewers cannot edit. An old box without the capability retains its current view.

Offline input remains a named local draft. Reconnect reads the current box state before applying anything; elapsed intervals and conflicting edits require visible handling. A phone cache must never claim a draft reached Core. Keep a draft separate from the accepted cache and cover app restart.

Delivery

1. Study the interaction in isolation and add a pure Swift draft model with tests. The first model must not send commands or attach to the current app view. Keep the work on a separate draft branch for a later release.
2. Add the canonical contract and Core persistence/read/write/composition in paired PRs. Include the published forecast provenance and revision needed by clients. Extend the forecast-only read horizon without inventing prices, weather coverage or a dispatch plan for those dates. Prove restart, expiry, permissions and replanning before enabling an editor.
3. Connect the iPhone editor to the continuous timeline after fix(mpc): treat non-positive battery-limit overrides as config error #93, following the load-basis review in fix(mpc): preserve one-sided zero battery limits (Codex follow-up) #94. Keep pan/read gestures intact; use the existing chart geometry and material. Confirmed writes update all clients from Core. No polling loop or per-finger-event network call.
4. Review the end-to-end result on a named test box and physical iPhone before release. Record the build IDs, delivery/result evidence and device frame-time measurements. Merge and release only in a later agreed scope, after the upcoming beta.

Required evidence

• Pulling an evening peak down, lifting a zero cold-start estimate, repeated reshaping, Undo, range reset, cancelled drag and unchanged surrounding intervals/history/solar.
• Day/week navigation, different display scales, missing forecast spans, interval-energy preservation, midnight, time zones, both DST changes and edits that expire while the view is open.
• Durable write followed by a restart; expiry without a phone; accepted change outside the current plan horizon appearing when that horizon advances.
• Rejected writes, viewer denial, old box, network loss before/after commit, idempotent retry, two-phone revision conflict and offline draft recovery.
• Effective forecast and new plan use the accepted revision, include EV exactly once, preserve current measured load and normal input/safety fallback checks, and leave base-model learning and scores separate.
• Native simulator review in light/dark mode and the largest accessibility text, a device VoiceOver pass, a screen recording and Animation Hitches measurement. A browser study and pure model tests alone do not prove native feel or a changed hardware outcome.

Current starting work

The isolated iOS study in ftw-app draft PR #96 adds only a LoadShapeDraft value and tests; no app view or wire contract calls it. All 825 Swift package tests pass, including 12 new tests for the draft model. A local browser study uses synthetic data to try shaping, day/week views, Undo and range reset. Neither is connected to a box. The production feature and all Core/transport integration remain to be built.