Reading additional input from stdin...
OpenAI Codex v0.125.0 (research preview)
--------
workdir: /home/teodor/little-projects/heapzilla-ai
model: gpt-5.5
provider: openai
approval: never
sandbox: read-only
reasoning effort: medium
reasoning summaries: none
session id: 019dceb0-fb3b-7143-ba31-19e6d5cd89e8
--------
user
Build an implementation plan for the eventa Android app. The spec is settled:
- Android-native, Kotlin + Jetpack Compose + Material 3
- Room (SQLite) for entities, DataStore for prefs
- ViewModel + StateFlow architecture
- On-device only, single user, no backend
- MVP-5: Event Brief, Guest List with RSVP (+ Contacts import), Planning Checklist, Deadline Timeline (+ local notifications), Budget Buckets (+ receipt photos)
- V1-required infra: JSON export + import + Android Auto Backup
- Hard non-goals: no auth, no sync, no sharing, no recurring tasks, no payment settlement
Produce a concrete itemized TODO list to build the MVP + the V1-required backup/export. Constraints:
1. Each task is HALF-A-DAY to 2-DAY sized — concrete enough that you start it after lunch and know what done looks like. NOT "design the system" or "implement guest list".
2. Tasks are in EXECUTION ORDER. If task B depends on task A, A comes first.
3. Group into PHASES with names. Each phase has a clear goal and outcome ("at the end of phase 2 you can add a guest and see them in a list").
4. For each task: 1-line title, 1-line "what done looks like" (acceptance criteria, observable behavior).
5. Be honest about what is infrastructure (DB schema, theme setup, navigation skeleton) vs feature work.
6. Include the V1-required backup/export — do not defer it as "after MVP". Codex round 4 said it is non-negotiable for V1.
Format as numbered phases (Phase 1, 2, ...) with numbered tasks inside (1.1, 1.2, ...). Aim for 5-7 phases, ~30-45 total tasks.
codex
Phase 1: App Foundation
Goal: establish the app shell, architecture, persistence base, and build conventions. At the end of phase 1, the app launches into a navigable Compose shell backed by Room/DataStore wiring.
1.1 Create Android project baseline
Done: Kotlin Android app builds, runs on emulator/device, uses Compose, Material 3, Kotlin serialization, Room, DataStore, WorkManager, and Coil dependencies.
1.2 Set up package/module structure
Done: Codebase has clear `data`, `domain`, `ui`, `notifications`, `backup`, and `core` areas with no feature logic in the app entry point.
1.3 Add Material 3 theme and app scaffold
Done: App has light/dark Material 3 theme, typography, color tokens, top app bar, and stable system bar styling.
1.4 Add navigation skeleton
Done: Bottom or primary navigation routes exist for Event, Guests, Checklist, Timeline, Budget, and Settings/Backup.
1.5 Add ViewModel + StateFlow base pattern
Done: One sample screen reads immutable UI state from a ViewModel via StateFlow and handles loading/error/empty states consistently.
1.6 Create Room database shell
Done: Room database initializes successfully with migration support enabled and an initial empty schema committed/exported.
1.7 Create DataStore preferences shell
Done: Preferences repository can read/write simple settings such as notification enablement and backup/export metadata.
1.8 Add app-wide error/result helpers
Done: Repositories expose predictable success/error results, and UI has a reusable way to show validation and persistence failures.
Phase 2: Core Data Model And Event Brief
Goal: define the durable local model and make the first real feature usable. At the end of phase 2, you can create/edit the event brief and see it persist after app restart.
2.1 Define core Room entities
Done: Room entities exist for EventBrief, Guest, ChecklistItem, Deadline, BudgetBucket, BudgetExpense, ReceiptPhoto, and import/export metadata where needed.
2.2 Add DAO interfaces for all MVP entities
Done: DAOs expose insert/update/delete/query flows needed by the MVP without UI code depending directly on Room.
2.3 Add repository layer for core entities
Done: Repositories wrap DAOs and expose StateFlow/Flow-friendly APIs for event, guests, checklist, deadlines, and budget data.
2.4 Implement initial database migration test
Done: A basic migration test verifies schema creation and establishes the pattern for future migrations.
2.5 Build Event Brief edit screen
Done: User can enter event name, date/time, venue/location text, notes, and optional host/contact details.
2.6 Build Event Brief read/summary screen
Done: Saved event information appears on the Event tab with an edit path and survives app restart.
2.7 Add Event Brief validation
Done: Empty required fields and invalid dates are blocked with visible inline errors.
2.8 Add empty-state behavior for first launch
Done: First launch clearly prompts the user to create an event brief without exposing broken or placeholder data.
Phase 3: Guest List And Contacts Import
Goal: deliver the guest workflow. At the end of phase 3, you can manually add guests, update RSVP state, and import contacts into the guest list.
3.1 Implement guest list data model details
Done: Guest supports name, phone, email, notes, household/group text, RSVP status, plus timestamps for sorting and export.
3.2 Build guest list screen
Done: Guests appear in a searchable/scannable list grouped or sorted predictably, with empty state when none exist.
3.3 Build add/edit guest screen
Done: User can create, edit, and delete a guest with validation for required name.
3.4 Implement RSVP controls
Done: User can set RSVP to unknown, invited, yes, no, maybe, and the list updates immediately.
3.5 Add guest summary counts
Done: Guest screen shows accurate totals by RSVP status and updates after edits.
3.6 Add Android Contacts permission flow
Done: App requests Contacts permission only when importing, handles denial, and explains the blocked state in UI.
3.7 Implement contacts picker/import
Done: User can select contacts from the device and import names plus available phone/email into guests.
3.8 Add duplicate handling for imported contacts
Done: Import flow detects likely duplicates by phone/email/name and lets the user skip or add without corrupting existing guests.
Phase 4: Checklist And Timeline
Goal: add task planning, deadlines, and reminders. At the end of phase 4, you can track checklist items, create deadlines, and receive local notifications.
4.1 Implement checklist item persistence
Done: Checklist items support title, notes, done status, optional due date, sort order, and created/updated timestamps.
4.2 Build checklist list screen
Done: User sees pending and completed items, can toggle done, and empty state is clear.
4.3 Build add/edit checklist item screen
Done: User can create, edit, delete, and set optional due date/notes for checklist items.
4.4 Add checklist ordering/filtering
Done: Checklist can be sorted by due date or manual/default order, with completed items visually distinct.
4.5 Implement deadline persistence
Done: Deadline records support title, date/time, notes, linked checklist item optional, notification enabled flag, and notification lead time.
4.6 Build deadline timeline screen
Done: Deadlines appear chronologically with overdue, today, upcoming, and completed/linked states visible.
4.7 Build add/edit deadline screen
Done: User can create, edit, delete, and configure local reminder timing for deadlines.
4.8 Add local notification scheduler
Done: Creating/updating/deleting a deadline schedules, updates, or cancels the matching local notification.
4.9 Add notification permission handling
Done: Android notification permission is requested when enabling reminders, with denied state handled gracefully.
4.10 Add boot/reschedule support
Done: Existing future deadline notifications are rescheduled after device reboot or app update where Android permits it.
Phase 5: Budget Buckets And Receipt Photos
Goal: deliver local event budgeting with receipt capture. At the end of phase 5, you can create budget buckets, record expenses, and attach receipt photos stored on device.
5.1 Implement budget bucket persistence
Done: Budget buckets support name, planned amount, notes, sort order, and computed actual spend from expenses.
5.2 Build budget overview screen
Done: User sees total planned, total spent, remaining/overage, and a list of buckets.
5.3 Build add/edit budget bucket screen
Done: User can create, edit, delete buckets with currency-safe amount input.
5.4 Implement expense persistence
Done: Expenses support bucket, title, amount, date, vendor/payee text, notes, and optional receipt photo links.
5.5 Build bucket detail screen
Done: User can view bucket planned amount, actual spend, remaining amount, and expense list.
5.6 Build add/edit expense screen
Done: User can create, edit, and delete expenses with validation for title, amount, and bucket.
5.7 Add receipt photo capture/import
Done: User can attach a receipt photo from camera or gallery to an expense using scoped storage-safe APIs.
5.8 Add receipt photo display and delete
Done: Attached receipt thumbnails display in expense detail/edit UI and can be removed without leaving broken references.
5.9 Add budget calculations tests
Done: Unit tests cover planned, spent, remaining, over-budget, and deleted expense scenarios.
Phase 6: JSON Export, Import, And Android Auto Backup
Goal: make local data portable and restorable as a V1 requirement. At the end of phase 6, the app can export/import a complete JSON backup and participates correctly in Android Auto Backup.
6.1 Define JSON backup schema
Done: Versioned JSON schema includes event brief, guests, checklist items, deadlines, budget buckets, expenses, receipt photo references/metadata, and preferences needed for restore.
6.2 Implement export serializer
Done: App can generate a deterministic JSON export from current Room/DataStore state.
6.3 Add export destination flow
Done: User can choose a destination through Android document APIs and save the JSON file without storage permissions.
6.4 Implement import parser and validation
Done: App validates version, required fields, IDs, references, and malformed JSON before mutating local data.
6.5 Implement import conflict strategy
Done: Import flow clearly supports replacing current local data after confirmation, with no partial writes on failure.
6.6 Add import UI
Done: User can pick a JSON file, preview basic contents, confirm replace, and see success/failure result.
6.7 Add receipt photo export/import policy
Done: V1 behavior is explicit and implemented: either receipt photos are included as encoded payloads or exported/imported with documented URI limitations.
6.8 Add transactional restore
Done: Import replace runs in a Room transaction and leaves existing data intact if validation or write fails.
6.9 Configure Android Auto Backup
Done: Manifest and backup rules include Room DB, DataStore prefs, and receipt photo storage while excluding caches/temp files.
6.10 Add backup/export regression tests
Done: Tests verify export round-trip, invalid import rejection, reference integrity, and restore of representative MVP data.
Phase 7: Hardening, Polish, And Release Readiness
Goal: close functional gaps, make the app reliable, and verify the full MVP path. At the end of phase 7, the V1 MVP is testable end-to-end on a real Android device.
7.1 Add end-to-end smoke flow
Done: Manual or instrumented smoke path covers create event, add guest, set RSVP, add checklist item, add deadline reminder, add budget expense, attach receipt, export, import.
7.2 Add empty/loading/error polish across screens
Done: Every primary screen has useful empty states, no indefinite spinners, and visible recovery for repository errors.
7.3 Add delete confirmations for destructive actions
Done: Deleting event data, guests, checklist items, deadlines, budget buckets, expenses, receipts, and import-replace actions require confirmation where data loss occurs.
7.4 Add accessibility pass
Done: Interactive controls have content descriptions where needed, text scales reasonably, touch targets are adequate, and forms are keyboard-friendly.
7.5 Add date/time/currency formatting pass
Done: Dates, times, and money render consistently using device locale without corrupting stored canonical values.
7.6 Add notification behavior QA
Done: Reminder scheduling, permission denial, cancellation, reboot reschedule, and past-deadline behavior are verified on supported Android versions.
7.7 Add database migration safety check
Done: Migration tests pass from schema version 1 to current, and destructive migration is not used for release builds.
7.8 Add release build verification
Done: Release variant builds successfully, minification/resource config does not break Room, serialization, notifications, image loading, or backup rules.
7.9 Add local privacy/about settings screen
Done: Settings clearly state data is on-device only and provides export/import entry points plus app/version info.
7.10 Final MVP acceptance pass
Done: All five MVP areas plus JSON import/export and Android Auto Backup are present, manually verified, and no hard non-goals are accidentally introduced.
2026-04-27T11:27:25.244430Z ERROR codex_core::session: failed to record rollout items: thread 019dceb0-fb3b-7143-ba31-19e6d5cd89e8 not found
tokens used
4,737
Phase 1: App Foundation
Goal: establish the app shell, architecture, persistence base, and build conventions. At the end of phase 1, the app launches into a navigable Compose shell backed by Room/DataStore wiring.
1.1 Create Android project baseline
Done: Kotlin Android app builds, runs on emulator/device, uses Compose, Material 3, Kotlin serialization, Room, DataStore, WorkManager, and Coil dependencies.
1.2 Set up package/module structure
Done: Codebase has clear `data`, `domain`, `ui`, `notifications`, `backup`, and `core` areas with no feature logic in the app entry point.
1.3 Add Material 3 theme and app scaffold
Done: App has light/dark Material 3 theme, typography, color tokens, top app bar, and stable system bar styling.
1.4 Add navigation skeleton
Done: Bottom or primary navigation routes exist for Event, Guests, Checklist, Timeline, Budget, and Settings/Backup.
1.5 Add ViewModel + StateFlow base pattern
Done: One sample screen reads immutable UI state from a ViewModel via StateFlow and handles loading/error/empty states consistently.
1.6 Create Room database shell
Done: Room database initializes successfully with migration support enabled and an initial empty schema committed/exported.
1.7 Create DataStore preferences shell
Done: Preferences repository can read/write simple settings such as notification enablement and backup/export metadata.
1.8 Add app-wide error/result helpers
Done: Repositories expose predictable success/error results, and UI has a reusable way to show validation and persistence failures.
Phase 2: Core Data Model And Event Brief
Goal: define the durable local model and make the first real feature usable. At the end of phase 2, you can create/edit the event brief and see it persist after app restart.
2.1 Define core Room entities
Done: Room entities exist for EventBrief, Guest, ChecklistItem, Deadline, BudgetBucket, BudgetExpense, ReceiptPhoto, and import/export metadata where needed.
2.2 Add DAO interfaces for all MVP entities
Done: DAOs expose insert/update/delete/query flows needed by the MVP without UI code depending directly on Room.
2.3 Add repository layer for core entities
Done: Repositories wrap DAOs and expose StateFlow/Flow-friendly APIs for event, guests, checklist, deadlines, and budget data.
2.4 Implement initial database migration test
Done: A basic migration test verifies schema creation and establishes the pattern for future migrations.
2.5 Build Event Brief edit screen
Done: User can enter event name, date/time, venue/location text, notes, and optional host/contact details.
2.6 Build Event Brief read/summary screen
Done: Saved event information appears on the Event tab with an edit path and survives app restart.
2.7 Add Event Brief validation
Done: Empty required fields and invalid dates are blocked with visible inline errors.
2.8 Add empty-state behavior for first launch
Done: First launch clearly prompts the user to create an event brief without exposing broken or placeholder data.
Phase 3: Guest List And Contacts Import
Goal: deliver the guest workflow. At the end of phase 3, you can manually add guests, update RSVP state, and import contacts into the guest list.
3.1 Implement guest list data model details
Done: Guest supports name, phone, email, notes, household/group text, RSVP status, plus timestamps for sorting and export.
3.2 Build guest list screen
Done: Guests appear in a searchable/scannable list grouped or sorted predictably, with empty state when none exist.
3.3 Build add/edit guest screen
Done: User can create, edit, and delete a guest with validation for required name.
3.4 Implement RSVP controls
Done: User can set RSVP to unknown, invited, yes, no, maybe, and the list updates immediately.
3.5 Add guest summary counts
Done: Guest screen shows accurate totals by RSVP status and updates after edits.
3.6 Add Android Contacts permission flow
Done: App requests Contacts permission only when importing, handles denial, and explains the blocked state in UI.
3.7 Implement contacts picker/import
Done: User can select contacts from the device and import names plus available phone/email into guests.
3.8 Add duplicate handling for imported contacts
Done: Import flow detects likely duplicates by phone/email/name and lets the user skip or add without corrupting existing guests.
Phase 4: Checklist And Timeline
Goal: add task planning, deadlines, and reminders. At the end of phase 4, you can track checklist items, create deadlines, and receive local notifications.
4.1 Implement checklist item persistence
Done: Checklist items support title, notes, done status, optional due date, sort order, and created/updated timestamps.
4.2 Build checklist list screen
Done: User sees pending and completed items, can toggle done, and empty state is clear.
4.3 Build add/edit checklist item screen
Done: User can create, edit, delete, and set optional due date/notes for checklist items.
4.4 Add checklist ordering/filtering
Done: Checklist can be sorted by due date or manual/default order, with completed items visually distinct.
4.5 Implement deadline persistence
Done: Deadline records support title, date/time, notes, linked checklist item optional, notification enabled flag, and notification lead time.
4.6 Build deadline timeline screen
Done: Deadlines appear chronologically with overdue, today, upcoming, and completed/linked states visible.
4.7 Build add/edit deadline screen
Done: User can create, edit, delete, and configure local reminder timing for deadlines.
4.8 Add local notification scheduler
Done: Creating/updating/deleting a deadline schedules, updates, or cancels the matching local notification.
4.9 Add notification permission handling
Done: Android notification permission is requested when enabling reminders, with denied state handled gracefully.
4.10 Add boot/reschedule support
Done: Existing future deadline notifications are rescheduled after device reboot or app update where Android permits it.
Phase 5: Budget Buckets And Receipt Photos
Goal: deliver local event budgeting with receipt capture. At the end of phase 5, you can create budget buckets, record expenses, and attach receipt photos stored on device.
5.1 Implement budget bucket persistence
Done: Budget buckets support name, planned amount, notes, sort order, and computed actual spend from expenses.
5.2 Build budget overview screen
Done: User sees total planned, total spent, remaining/overage, and a list of buckets.
5.3 Build add/edit budget bucket screen
Done: User can create, edit, delete buckets with currency-safe amount input.
5.4 Implement expense persistence
Done: Expenses support bucket, title, amount, date, vendor/payee text, notes, and optional receipt photo links.
5.5 Build bucket detail screen
Done: User can view bucket planned amount, actual spend, remaining amount, and expense list.
5.6 Build add/edit expense screen
Done: User can create, edit, and delete expenses with validation for title, amount, and bucket.
5.7 Add receipt photo capture/import
Done: User can attach a receipt photo from camera or gallery to an expense using scoped storage-safe APIs.
5.8 Add receipt photo display and delete
Done: Attached receipt thumbnails display in expense detail/edit UI and can be removed without leaving broken references.
5.9 Add budget calculations tests
Done: Unit tests cover planned, spent, remaining, over-budget, and deleted expense scenarios.
Phase 6: JSON Export, Import, And Android Auto Backup
Goal: make local data portable and restorable as a V1 requirement. At the end of phase 6, the app can export/import a complete JSON backup and participates correctly in Android Auto Backup.
6.1 Define JSON backup schema
Done: Versioned JSON schema includes event brief, guests, checklist items, deadlines, budget buckets, expenses, receipt photo references/metadata, and preferences needed for restore.
6.2 Implement export serializer
Done: App can generate a deterministic JSON export from current Room/DataStore state.
6.3 Add export destination flow
Done: User can choose a destination through Android document APIs and save the JSON file without storage permissions.
6.4 Implement import parser and validation
Done: App validates version, required fields, IDs, references, and malformed JSON before mutating local data.
6.5 Implement import conflict strategy
Done: Import flow clearly supports replacing current local data after confirmation, with no partial writes on failure.
6.6 Add import UI
Done: User can pick a JSON file, preview basic contents, confirm replace, and see success/failure result.
6.7 Add receipt photo export/import policy
Done: V1 behavior is explicit and implemented: either receipt photos are included as encoded payloads or exported/imported with documented URI limitations.
6.8 Add transactional restore
Done: Import replace runs in a Room transaction and leaves existing data intact if validation or write fails.
6.9 Configure Android Auto Backup
Done: Manifest and backup rules include Room DB, DataStore prefs, and receipt photo storage while excluding caches/temp files.
6.10 Add backup/export regression tests
Done: Tests verify export round-trip, invalid import rejection, reference integrity, and restore of representative MVP data.
Phase 7: Hardening, Polish, And Release Readiness
Goal: close functional gaps, make the app reliable, and verify the full MVP path. At the end of phase 7, the V1 MVP is testable end-to-end on a real Android device.
7.1 Add end-to-end smoke flow
Done: Manual or instrumented smoke path covers create event, add guest, set RSVP, add checklist item, add deadline reminder, add budget expense, attach receipt, export, import.
7.2 Add empty/loading/error polish across screens
Done: Every primary screen has useful empty states, no indefinite spinners, and visible recovery for repository errors.
7.3 Add delete confirmations for destructive actions
Done: Deleting event data, guests, checklist items, deadlines, budget buckets, expenses, receipts, and import-replace actions require confirmation where data loss occurs.
7.4 Add accessibility pass
Done: Interactive controls have content descriptions where needed, text scales reasonably, touch targets are adequate, and forms are keyboard-friendly.
7.5 Add date/time/currency formatting pass
Done: Dates, times, and money render consistently using device locale without corrupting stored canonical values.
7.6 Add notification behavior QA
Done: Reminder scheduling, permission denial, cancellation, reboot reschedule, and past-deadline behavior are verified on supported Android versions.
7.7 Add database migration safety check
Done: Migration tests pass from schema version 1 to current, and destructive migration is not used for release builds.
7.8 Add release build verification
Done: Release variant builds successfully, minification/resource config does not break Room, serialization, notifications, image loading, or backup rules.
7.9 Add local privacy/about settings screen
Done: Settings clearly state data is on-device only and provides export/import entry points plus app/version info.
7.10 Final MVP acceptance pass
Done: All five MVP areas plus JSON import/export and Android Auto Backup are present, manually verified, and no hard non-goals are accidentally introduced.