Alaro Reminder Overhaul

Read the implementation checklist at /home/dev/projects/alaro/docs/implementation-checklist.md (section 1) and the referenced docs: /home/dev/projects/alaro/docs/api-contract.md and /home/dev/projects/alaro/docs/delivery-architecture.md Implement: - Remove notification_count from reminder request, update, storage, and read models - Add stop_window_minutes everywhere reminders are created, updated, stored, validated, and returned - Restore default handling: max_urgency=critical, interval_minutes=5, stop_window_minutes=60, prearm_rescue=true - Update create and update validation to match the new reminder model - Update read-model status handling for: scheduled, completed, expired, deleted After implementation: run a Codex review on all changes. If Codex has findings, fix the ones that actually make sense. Then commit all changes with a clear message and push.

Read the implementation checklist at /home/dev/projects/alaro/docs/implementation-checklist.md (section 2) and the referenced docs: /home/dev/projects/alaro/docs/delivery-architecture.md and /home/dev/projects/alaro/docs/scheduling-model.md Implement: - Replace the old fixed-count reminder scheduling model with the new reminder timeline - Implement lower reminder stages before scheduled time when there is enough time - Implement strongest stage at scheduled time - Implement repeated strongest stage after scheduled time until acknowledgement or stop-window expiry - Implement late-start behavior so delivery jumps directly to the stage implied by elapsed time - Keep critical degradation to time-sensitive when critical_unavailable After implementation: run a Codex review on all changes. If Codex has findings, fix the ones that actually make sense. Then commit all changes with a clear message and push.

Read the implementation checklist at /home/dev/projects/alaro/docs/implementation-checklist.md (section 3) and the referenced docs: /home/dev/projects/alaro/docs/api-contract.md and /home/dev/projects/alaro/docs/delivery-architecture.md Implement: - Store reminder completion and expiry distinctly - Ensure reminder history uses acknowledgement time for completed, expiry time for expired - Keep alarm history based on trigger time - Update list ordering and history ordering to match the docs - Update tombstone handling so deletes still work with the new statuses After implementation: run a Codex review on all changes. If Codex has findings, fix the ones that actually make sense. Then commit all changes with a clear message and push.

Read the implementation checklist at /home/dev/projects/alaro/docs/implementation-checklist.md (section 4) and the referenced docs: /home/dev/projects/alaro/docs/delivery-architecture.md and /home/dev/projects/alaro/docs/app-state-and-sync.md Implement: - Update snapshot payloads to reflect the new reminder state model - Include enough reminder data for the app to rebuild remaining stages after reconnect - Ensure active reminder occurrences remain active on repair - Ensure expired reminder occurrences move to retained history correctly After implementation: run a Codex review on all changes. If Codex has findings, fix the ones that actually make sense. Then commit all changes with a clear message and push.

Read the implementation checklist at /home/dev/projects/alaro/docs/implementation-checklist.md (section 5) and the referenced docs: /home/dev/projects/alaro/docs/delivery-architecture.md, /home/dev/projects/alaro/docs/scheduling-model.md, and /home/dev/projects/alaro/docs/app-state-and-sync.md Implement: - Remove old local fixed-count reminder staging - Implement local reminder timeline generation from: scheduled time, max_urgency, interval_minutes, stop_window_minutes - Schedule lower stages before scheduled time when possible - Schedule strongest stage at scheduled time - Schedule strongest stage repeatedly after scheduled time until stop-window expiry - Cancel future local reminder attempts when the occurrence is acknowledged - Current target: schedule the full remaining local timeline through end of stop window in one go After implementation: run a Codex review on all changes. If Codex has findings, fix the ones that actually make sense. Then commit all changes with a clear message and push.

Read the implementation checklist at /home/dev/projects/alaro/docs/implementation-checklist.md (section 6) and the referenced docs: /home/dev/projects/alaro/docs/delivery-architecture.md and /home/dev/projects/alaro/docs/app-state-and-sync.md Implement: - Update late-arrival repair logic for reminders - If a reminder occurrence is still inside stop window, compute current stage and schedule remaining local attempts - If a reminder occurrence is already acknowledged or expired, move it into retained past state - Keep dirty-op coalescing by latest desired writable state - Keep delete and acknowledgement local-first After implementation: run a Codex review on all changes. If Codex has findings, fix the ones that actually make sense. Then commit all changes with a clear message and push.

Read the implementation checklist at /home/dev/projects/alaro/docs/implementation-checklist.md (section 7) and the referenced docs: /home/dev/projects/alaro/docs/api-contract.md, /home/dev/projects/alaro/docs/scheduling-model.md, and /home/dev/projects/alaro/docs/app-state-and-sync.md Implement: - Add stop_window_minutes to local reminder models - Add reminder occurrence completion vs expiry handling - Ensure occurrence rows can represent: active, completed, and expired recurring occurrences - Keep instant notifications out of the persisted alarm/reminder store After implementation: run a Codex review on all changes. If Codex has findings, fix the ones that actually make sense. Then commit all changes with a clear message and push.

Read the implementation checklist at /home/dev/projects/alaro/docs/implementation-checklist.md (section 8) and the referenced docs: /home/dev/projects/alaro/docs/app-ui-behavior.md and /home/dev/projects/alaro/docs/api-contract.md Implement: - Update reminder editor: remove notification_count UI, keep Final alert, Minutes apart, Stop after, Open app if needed - Implement Stop after wheel exactly as: 30 minutes, every hour from 1 through 24 - Keep alarms separate from reminders in navigation - Keep active reminders and active alarms as separate top-level areas After implementation: run a Codex review on all changes. If Codex has findings, fix the ones that actually make sense. Then commit all changes with a clear message and push.

Read the implementation checklist at /home/dev/projects/alaro/docs/implementation-checklist.md (section 9) and the referenced docs: /home/dev/projects/alaro/docs/app-ui-behavior.md and /home/dev/projects/alaro/docs/delivery-architecture.md Implement: - Add Needs attention section above active reminders - Show unseen expired reminder occurrences there only - Row content: warning symbol, title, expiry time - Tapping opens read-only expired reminder detail - After user opens it once, remove from Needs attention - Keep it in History - Show Completed vs Expired explicitly in history rows and details After implementation: run a Codex review on all changes. If Codex has findings, fix the ones that actually make sense. Then commit all changes with a clear message and push.

Read the implementation checklist at /home/dev/projects/alaro/docs/implementation-checklist.md (section 10) and the referenced docs: /home/dev/projects/alaro/docs/app-ui-behavior.md and /home/dev/projects/alaro/docs/delivery-architecture.md Implement: - Implement reminder acknowledgement sheet - Show it after the app opens from: reminder notification tap, reminder-backed alarm dismissal - Actions: Acknowledge, Keep Active - Acknowledgement must affect only the current occurrence After implementation: run a Codex review on all changes. If Codex has findings, fix the ones that actually make sense. Then commit all changes with a clear message and push.

Read the implementation checklist at /home/dev/projects/alaro/docs/implementation-checklist.md (section 11) and the referenced docs: /home/dev/projects/alaro/docs/app-ui-behavior.md and /home/dev/projects/alaro/docs/delivery-architecture.md Implement: - Implement the shared rescue sheet for alarms and reminders - Show: title, body, occurrence or scheduled time, explanation text, background tip, Continue - Do not use the rescue sheet as an acknowledgement flow After implementation: run a Codex review on all changes. If Codex has findings, fix the ones that actually make sense. Then commit all changes with a clear message and push.

Read the implementation checklist at /home/dev/projects/alaro/docs/implementation-checklist.md (section 12) and all referenced docs. Implement server tests: - Reminder defaulting, validation, timeline stage computation, late-start stage selection, acknowledgement vs expiry transitions, critical degradation, history ordering iOS tests: - Reminder local timeline generation, full stop-window scheduling, acknowledgement cancellation, late repair scheduling, expired reminder movement into Needs attention and History End-to-end scenarios: - Normal/time-sensitive/critical reminder, recurring acknowledgement, expired reminder, reminder rescue flow, reminder-backed alarm dismissal flow, alarm rescue flow, delete during active lifecycle After implementation: run a Codex review on all changes. If Codex has findings, fix the ones that actually make sense. Then commit all changes with a clear message and push.

This is the final verification task. Read ALL documentation files: - /home/dev/projects/alaro/docs/api-contract.md - /home/dev/projects/alaro/docs/delivery-architecture.md - /home/dev/projects/alaro/docs/scheduling-model.md - /home/dev/projects/alaro/docs/app-state-and-sync.md - /home/dev/projects/alaro/docs/app-ui-behavior.md - /home/dev/projects/alaro/docs/implementation-checklist.md Then compare each documented behavior against the actual implementation. Check every detail: field names, defaults, status transitions, UI elements, ordering, edge cases. If ANYTHING in the implementation differs from what the docs describe, create new tasks in this nightshift run for each discrepancy that needs fixing. Use the dashboard API: POST http://127.0.0.1:9100/api/runs/{run_id}/tasks with JSON body {"title": "...", "description": "..."}. Do not weaken or rewrite the docs to fit the code. The docs are the source of truth. After verification: commit and push any minor fixes found during the review.

API contract docs specify reminder writable fields as title, body, and schedule. The server implementation uses message, alarm_label, and alarm_time instead. This affects models.go (Reminder, ReminderRequest structs), store_reminder.go (SQL columns), store_normalize.go (validation), server_handler_reminder.go, and all iOS model/view code referencing these fields. Rename all three fields to match the documented contract.

API contract and scheduling-model docs require reminders to use the same typed schedule object as alarms (supporting fixed, relative_weekly, relative_monthly, relative_yearly). Currently reminders only have alarm_time (a plain timestamp), which means recurring reminders are impossible. Add a schedule field to the Reminder model matching the AlarmSchedule shape, update server storage, validation, and iOS models.

API contract docs specify alarm writable field as title. The server uses label. Rename in models.go (Alarm, AlarmRequest, AlarmPatchRequest structs), store_normalize.go, store_alarm.go SQL columns, and iOS Alarm model.

Scheduling model docs require recurring schedules to include anchor (device_local or time_zone) and an optional IANA time_zone identifier when anchor=time_zone. The AlarmSchedule struct in models.go has no anchor or time_zone fields. Add these fields, update normalizeSchedule validation (anchor=time_zone requires time_zone, anchor=device_local must not include time_zone), and update iOS schedule models.

API contract docs specify that create requests may include optional external_id. external_id must be unique per device and resource type. Same external_id + same payload deduplicates; same external_id + different payload returns 409 Conflict. Neither the Alarm nor Reminder models have this field. Add external_id to both server models, storage, and iOS models.

API contract specifies: exact effective duplicates deduplicate to existing resource (returning 200 OK), duplicate detection applies even without external_id, same external_id + different payload returns 409 Conflict. None of this logic exists in the server. Implement in store_alarm.go and store_reminder.go create paths.

API contract specifies read responses should include delivery_type (local | server | null). Delivery architecture docs define the mapping from internal states (pending_local→null, local_confirmed→local, server_fallback→server, etc.). This field does not exist anywhere in the implementation. Add to server models, storage, and include in read/list responses.

API contract specifies deleted resources should include deletion_status (pending_device_confirmation | confirmed). Current implementation has deleted_via but not deletion_status. Add this field to the Reminder and Alarm models, track confirmation state on the server, and include in read responses for deleted items.

API contract specifies public create response fields: id, status, deduplicated, optional warnings. The server currently returns the full Reminder/Alarm object on create (201). Define a separate CreateResponse struct with just id, status, deduplicated, and optional warnings array, and use it in handleCreateReminder and handleCreateAlarm.

API contract specifies: delete returns 202 Accepted (local deletion unconfirmed) or 200 OK (local deletion confirmed), with the full original object plus deletion metadata. Currently handleDeleteReminder returns 204 No Content with no body. Fix to return the appropriate status code and full deleted object response.

The API contract docs list PUT /v1/alarms/{id} for updates but do not include a PATCH endpoint. The server registers PATCH /v1/alarms/{id} with handlePatchAlarm. Either remove it or, if it is intentionally needed, add it to the API contract docs. Per task instructions, docs are source of truth, so remove the PATCH endpoint.

API contract lists POST /v1/notifications as an endpoint for immediate push delivery. The server does not have this route. Add the endpoint per the docs: instant notifications are fire-and-forget, not part of alarms/reminders list/read surfaces, and do not create retained history rows.

Delivery architecture docs state: v1 does not expose a public reminder acknowledge endpoint. However the server has POST /v1/reminders/{id}/acknowledge. Either remove the endpoint to match docs, or update delivery-architecture.md if acknowledge was intentionally added. Per task instructions, docs are source of truth.

API contract says alarm writable fields are: title, schedule, prearm_rescue (optional), and optional external_id. The current Alarm model has many undocumented fields: enabled, snooze_enabled, snooze_duration_minutes, reminder_enabled, reminder_message, reminder_notification_count, reminder_interval_minutes, alarm_sound_enabled, ringtone, created_via, api_created, is_demo, acknowledged_by_user, push_attempts. These should either be removed or the docs updated. Per task instructions, docs are source of truth.

API contract docs list prearm_rescue as an optional writable field for alarms, defaulting to true. The server Alarm struct does not have this field. Add prearm_rescue to the Alarm model, AlarmRequest, storage, and validation. Default to true. Also add to iOS Alarm model.

API contract and app-ui-behavior docs specify active alarms sorted by next trigger time ascending. The iOS AlarmListView uses @Query sorted by updatedAt DESC, label ASC. Change to sort by next trigger/fire time ascending with stable ID tie-break, matching the documented active list ordering.

app-ui-behavior docs specify: active reminders title="No reminders yet", active alarms title="No alarms yet", deleted title="Nothing deleted recently". Current implementation: ReminderListView shows "No scheduled reminders" (should be "No reminders yet"), ReminderHistoryView deleted section shows "No recent activity" (should be "Nothing deleted recently"). Fix these text strings to match docs exactly.

API contract says: request bodies must reject unknown additional fields and must also reject server-managed fields even if those fields exist internally. The current JSON decoding in Go uses standard json.Unmarshal which silently ignores unknown fields. Add strict unknown-field rejection to decodeJSON or add a custom decoder that returns 422 for any unrecognized keys in reminder and alarm create/update request bodies.

Read ALL documentation files that serve as the source of truth: - /home/dev/projects/alaro/docs/api-contract.md - /home/dev/projects/alaro/docs/delivery-architecture.md - /home/dev/projects/alaro/docs/scheduling-model.md - /home/dev/projects/alaro/docs/app-state-and-sync.md - /home/dev/projects/alaro/docs/app-ui-behavior.md - /home/dev/projects/alaro/docs/implementation-checklist.md Then compare every documented behavior against the actual implementation. Check field names, defaults, status transitions, UI elements, ordering, edge cases — everything. The docs are the source of truth. Do NOT weaken or rewrite the docs to fit the code. For every discrepancy found, create a new task in this nightshift run using the dashboard API: POST http://127.0.0.1:9100/api/runs/fa2271c7-4c8b-4e10-a30c-6889011c761d/tasks Content-Type: application/json {"title": "Fix: <description>", "description": "<details of what the docs say vs what the code does>"} After creating all fix tasks, also add one final task: POST http://127.0.0.1:9100/api/runs/fa2271c7-4c8b-4e10-a30c-6889011c761d/tasks {"title": "Commit and push all changes", "description": "Stage all changes on the nightshift branch, commit with a clear summary message covering the full reminder overhaul, and push to the remote. Make sure nothing is left uncommitted."} Commit and push any minor fixes found during the verification itself.

Read ALL documentation files that serve as the source of truth: - /home/dev/projects/alaro/docs/api-contract.md - /home/dev/projects/alaro/docs/delivery-architecture.md - /home/dev/projects/alaro/docs/scheduling-model.md - /home/dev/projects/alaro/docs/app-state-and-sync.md - /home/dev/projects/alaro/docs/app-ui-behavior.md - /home/dev/projects/alaro/docs/implementation-checklist.md Then compare every documented behavior against the actual implementation. Check field names, defaults, status transitions, UI elements, ordering, edge cases — everything. The docs are the source of truth. Do NOT weaken or rewrite the docs to fit the code. For every discrepancy found, create a new task in this nightshift run using the dashboard API: POST http://127.0.0.1:9100/api/runs/fa2271c7-4c8b-4e10-a30c-6889011c761d/tasks Content-Type: application/json {"title": "Fix: <description>", "description": "<details of what the docs say vs what the code does>"} After creating all fix tasks, also add one final task: POST http://127.0.0.1:9100/api/runs/fa2271c7-4c8b-4e10-a30c-6889011c761d/tasks {"title": "Commit and push all changes", "description": "Stage all changes on the nightshift branch, commit with a clear summary message covering the full reminder overhaul, and push to the remote. Make sure nothing is left uncommitted."} Commit and push any minor fixes found during the verification itself.

Read ALL documentation files that serve as the source of truth: - /home/dev/projects/alaro/docs/api-contract.md - /home/dev/projects/alaro/docs/delivery-architecture.md - /home/dev/projects/alaro/docs/scheduling-model.md - /home/dev/projects/alaro/docs/app-state-and-sync.md - /home/dev/projects/alaro/docs/app-ui-behavior.md - /home/dev/projects/alaro/docs/implementation-checklist.md Then compare every documented behavior against the actual implementation. Check field names, defaults, status transitions, UI elements, ordering, edge cases — everything. The docs are the source of truth. Do NOT weaken or rewrite the docs to fit the code. For every discrepancy found, create a new task in this nightshift run using the dashboard API: POST http://127.0.0.1:9100/api/runs/fa2271c7-4c8b-4e10-a30c-6889011c761d/tasks Content-Type: application/json {"title": "Fix: <description>", "description": "<details of what the docs say vs what the code does>"} After creating all fix tasks, add one final task: POST http://127.0.0.1:9100/api/runs/fa2271c7-4c8b-4e10-a30c-6889011c761d/tasks {"title": "Commit, push, and merge to main", "description": "Stage all changes on the nightshift branch. Commit with a clear summary message covering the full reminder overhaul. Push to the remote. Then merge the branch into main. Make sure nothing is left uncommitted."} Commit and push any minor fixes found during the verification itself.

Doc says: server generates id, body is optional, PUT uses same writable shape as POST, must reject unknown/server-managed fields. Code: requires client-supplied id, requires non-empty body, PUT enforces body id matching path. Files: models.go, store_normalize.go, store_reminder.go.

Doc says public statuses are scheduled, completed, expired, deleted (lowercase). Code returns alarm create status as active/disabled, reminder statuses as uppercase SCHEDULED/DELETED, alarm read model has no public status field. Files: server_handler_alarm.go, models.go, store_reminder.go.

Doc says delete returns 202 Accepted (unconfirmed) or 200 OK (confirmed) plus the full original object with deletion metadata (deleted_at, deletion_status). Code returns 204 No Content. File: server_handler_alarm.go.

Doc says warnings is an array of {code, message} objects and only critical_unavailable is defined. Code models warnings as []string and emits notification_permission_denied instead. Files: models.go, server_handler_reminder.go.

Doc says exact effective duplicates should deduplicate even when external_id is absent, based on same user-visible scheduled behavior after defaults. Code only checks same reminder id, and equality check requires same id. Files: store_reminder.go.

Doc says reminders become completed only when acknowledged before expiry; expired reminders stay expired. Code only special-cases COMPLETED, so acknowledging an already expired reminder flips it to completed. File: store_reminder.go.

Doc says active = currently active scheduled items, history = past non-deleted items within 30-day window. Code puts any enabled=1 alarm in active even if past, and history is enabled=0 OR acknowledged_by_user=1 so future disabled alarms appear in history. File: store_alarm.go.

Doc says active sorts by next_delivery_at ASC with id tie-breaker, all shows active first then history/deleted by recency. Code falls back to created_at for recurring active items and uses same sort key for non-active in view=all. Files: store_reminder.go, store_alarm.go.

Doc says not to expose internal states. Alarm JSON exposes device_id, created_via, api_created, is_demo, acknowledged_by_user, push_attempts, deleted_via. Reminder JSON exposes device_id, alarm_id, degraded, reason, deleted_via. File: models.go.

Doc says reminders should edit full schedule supporting once/weekly/monthly/yearly plus timezone behavior (device_local and time_zone anchor). Code only stores a fixed fire time in form state and editor only shows a time wheel. Files: ReminderFormState.swift, ReminderEditView.swift.

Doc says alarms expose only title, schedule, and prearm_rescue. Code keeps/edits snooze and ringtone fields, and model carries legacy reminder-backed alarm fields. Files: AlarmFormState.swift, AlarmEditView.swift, Alarm.swift.

Doc says labels should be: Final alert, Minutes apart, Stop after (sentence case). Code uses: Final Alert, Minutes Apart, Stop After (title case). File: ReminderEditView.swift.

Doc says active reminder rows should show only: title, next delivery date/time, short recurrence label. Do not show raw API terms. Code also shows urgency badges and Pending Sync. File: ReminderRowView.swift.

Doc says alarms should have separate Active and History screens, with Deleted inside History. Code has no alarm history screen; it inlines a Past section into the active list. File: AlarmListView.swift.

Doc says alarm rows should show only: title, next trigger time, short recurrence label. Code also shows schedule verification, snooze/reminder badges, Past/Snoozed/Pending Sync labels, and an enable toggle. File: AlarmRowView.swift.

Doc says: active reminders title=No reminders yet, primary action=API Documentation, secondary=Use the + button to create one here. Same pattern for alarms. Code has no primary action for reminders; alarm empty state uses different copy entirely. Files: ReminderListView.swift, AlarmListView.swift.

Doc says app should open the reminder edit/history context first, then present the acknowledgement sheet above it. Code presents the sheet from ReminderListView without navigating to the target screen underneath. File: ReminderListView.swift.

Doc says rescue should open edit/history/deleted detail, then show rescue sheet. Code only switches tabs and presents a global sheet without navigating to the specific resource. Files: AlaroApp.swift, ReminderDeepLinkHandler.swift.

Doc says create returns {id,status,deduplicated,warnings}, list returns {items,view,next_cursor}, delete returns deleted object. Code expects full objects on create, {alarms}/{reminders} on list, empty delete responses, sends extra write fields, and encodes acknowledged inside reminder escalation. Files: APIClient+Alarm.swift, APIClient+Reminder.swift, APIClientModels.swift.

Doc says create and edit screens should show a visible critical_unavailable warning before save when critical fallback is unavailable. Recommended message: Critical fallback is unavailable on this iPhone. If server fallback is needed, Alaro will use a time-sensitive notification instead. Code only shows validation/save errors with no capability-based warning path. Files: ReminderEditView.swift, AlarmEditView.swift.

Stage all changes on the nightshift branch. Commit with a clear summary message covering the full reminder overhaul. Push to the remote. Then merge the branch into main. Make sure nothing is left uncommitted.