Alltag — Master Product & Architecture Plan

Purpose of this document
This file is the single source of truth for continuing the Alltag project in a new ChatGPT conversation if previous chat history is unavailable.
It contains the product vision, non-negotiable rules, architecture, security model, data model, UX principles, localization requirements, sync strategy, backup/recovery rules, phased implementation plan, and the required delivery protocol for every development chat.

0. Product identity

Product name: Alltag
Android project name: Alltag
Recommended project root: C:\Projects\Alltag
Recommended namespace/applicationId: dev.soroush.alltag

Alltag is the public/product name. Internal architecture terminology remains language-neutral.

1. Product vision

Alltag is a local-first Android application for managing the operational complexity of daily life:

letters and official documents
appointments
tasks and deadlines
follow-ups
legal and administrative cases
health-related administration
recurring routines
household collaboration
bank/account balances entered manually
future income and expenses
installments, payment pauses and future obligations
contracts
shopping lists and shared household items
cash-flow forecasting
“Can I afford this?” purchase simulation
encrypted local backups
home-only family synchronization
Markdown context export for continuation in ChatGPT or another LLM

The product is not primarily:

a generic calendar,
a banking application,
a simple expense tracker,
a cloud SaaS,
or a document scanner.

It is best described as:

A private household operating system for life administration, obligations, documents, money, timelines and decisions.

2. Core product principles

These rules are non-negotiable and must not be broken by later implementation shortcuts.

2.1 Local-first / offline-first

Each Android device owns a complete local database for the data it is allowed to retain.

The application must remain usable when:

internet is unavailable,
the FRITZ!Box is unreachable,
the user is away from home,
other household members are offline.

Cloud connectivity is not required for core operation.

2.2 Household-first, but ownership is individual

A household may contain multiple members.

Examples:

Soroush
Bahareh
future family members
temporary flatmates

Every meaningful record has an ownerMemberId.

A household membership grants collaboration rights, not ownership.

2.3 Ownership rule

For every record:

Owner may:
- read
- edit
- delete
- archive
- change its own content
- decide sharing policy

Other authorized household members may:
- read if permitted
- add contributions
- add comments/checkpoints/actions
- perform explicitly shared workflow actions
- edit/delete only their own contributions

Other members may NOT:
- destructively edit another owner's original content
- delete another owner's original record
- convert another owner's sensitive record to portable/offline-readable

Three mutation classes must exist conceptually:

1. OWNER_MUTATION
2. CONTRIBUTION
3. SHARED_ACTION

Examples:

Changing a payment amount: OWNER_MUTATION
Adding a note to someone else's case: CONTRIBUTION
Marking milk as bought in a shared shopping list: SHARED_ACTION

2.4 Capture first, organize later

Users are tired and busy. Alltag must not force classification at capture time.

Fast path:

Open app
→ Capture
→ text/photo/OCR/document/task/etc.
→ Save
→ item appears at top of Inbox

The user can classify and enrich the item later.

This is a core UX rule.

2.5 Taxonomy + tags + relations

The mental model is taxonomy-based.

The app ships with default top-level categories, for example:

Finanzen
Gesundheit
Recht
Arbeit
Auto
Wohnung
Familie
Verträge
Behörden
Studium
Sonstiges

But users can:

add categories
rename categories
reorder categories
nest categories
archive categories

Relationships between entities must additionally support:

tags
links
related cases
related contacts
related documents
related payments
related appointments
related tasks

3. Languages and internationalization

Alltag is multilingual from the beginning.

Mandatory first-class UI languages:

German
English
Persian

Requirements:

no hard-coded user-facing strings
Android resource localization from the first implementation phase
full RTL support for Persian
full LTR support for German and English
layout must survive language switching without redesign
icons should carry much of the navigation meaning
date/number/currency formatting must respect locale
internal database enums/IDs must remain language-neutral
exported Markdown may be generated in the currently selected UI language

4. Visual UX / design system

Alltag must be visually rich and not look like a collection of text forms and tables.

Mandatory design direction:

icon-rich interface
Material 3 / Material Symbols or equivalent vector icons
cards
status chips
badges
visual timelines
section icons
empty-state illustrations/icons
priority indicators
finance trend cards
visually distinct Inbox
clear owner/member indicators where relevant
compact action buttons
accessible spacing and typography
dark mode support
Persian RTL-aware icon placement

Text-only screens should be avoided unless the content itself is inherently textual.

The Dashboard should communicate state visually before the user reads detail.

5. Main product areas

Alltag
│
├── Household
├── Dashboard
├── Inbox
├── Taxonomy / Areas
├── Cases / Vorgänge
├── Timeline
├── Checkpoints
├── Documents / Letters
├── Appointments
├── Tasks
├── Deadlines
├── Follow-ups
├── Routines
├── Finance
├── Contracts
├── Contacts / Institutions
├── Shared Household Items
│   └── Shopping Lists
├── Search
├── Reports
│   └── Markdown Context Export
├── Backup / Restore
└── Settings

6. Cases / Vorgänge

A Case is the central administrative container.

Examples:

Residence permit
VW Bank
Tax return 2026
Lawyer / criminal proceeding
Thyroid follow-up
Apartment move
University
Insurance claim

A case may contain:

documents[]
appointments[]
tasks[]
deadlines[]
followUps[]
payments[]
contacts[]
checkpoints[]
notes[]
events[]
relations[]

Cases may be related to each other.

A strict tree is not sufficient; use taxonomy + graph-style relations.

7. Unified timeline

Alltag must provide a unified timeline per case/person/context.

Example:

02.08  Letter received
05.08  Email sent
05.08  Follow-up scheduled
19.08  Phone call
22.08  Lawyer replied
23.08  Payment made

Timeline items may originate from different modules but must be queryable as one chronological stream.

Important metadata:

eventId
ownerMemberId
actorMemberId
entityType
entityId
eventType
timestamp
summary
visibilityPolicy

8. Checkpoints

A Checkpoint is a concise, structured state snapshot.

It is not long-form storytelling.

Example:

CHECKPOINT — Lawyer — 14.09.2026

Known:
- Lawyer contacted court.

Waiting for:
- Judge response.

Agreed:
- Lawyer will inform me.

My next action:
- None.

Follow-up:
- 28.09.2026.

Checkpoints may belong to:

case
appointment
document
task
contact
financial event

They are important for Markdown export and continuity.

9. Documents and letters

9.1 Capture modes

The user may choose globally and per document:

TEXT_ONLY
OCR_PLUS_OPTIMIZED_SCAN
OCR_PLUS_ORIGINAL

The app must never force storage of full-resolution images.

Recommended default:

OCR_PLUS_OPTIMIZED_SCAN

for important administrative/legal/medical/financial documents.

TEXT_ONLY remains available for users who care strongly about storage size.

9.2 Scanner UX

Document capture should resemble modern camera translation/scanner experiences.

Expected flow:

Camera
→ page detection
→ auto crop
→ perspective correction
→ rotate if required
→ multi-page capture
→ OCR
→ save to Inbox

Classification is optional at capture time.

9.3 Original vs OCR

OCR is not evidence.

If an original/optimized scan is retained, store separately:

Document
├── source file / optimized scan
├── OCR text
├── structured extracted values
└── user notes

OCR values must not silently become trusted deadlines/payments.

Detection is not confirmation.

9.4 Multiple actions per letter

A document can create many independent actions.

Example:

Document
├── SEND_DOCUMENT
├── PAYMENT
├── REPLY
├── BOOK_APPOINTMENT
└── FOLLOW_UP

Each action has its own state.

The document itself must not use one simple completed boolean.

Suggested action types:

INFORMATION
ACTION_REQUIRED
PAYMENT_REQUIRED
REPLY_REQUIRED
DOCUMENT_REQUIRED
APPOINTMENT_REQUIRED
DEADLINE
FOLLOW_UP
CONTRACT_DECISION
MEDICAL_INFORMATION
REMINDER_WARNING

9.5 Document lifecycle

Initial recommended lifecycle:

NEW
READ
ACTION_REQUIRED
IN_PROGRESS
WAITING
DONE
ARCHIVED

10. Follow-up engine

For outgoing correspondence or contact, Alltag should suggest:

Follow-up in 14 days

The user can:

accept
change date
reject

Example:

Email sent: 14.09.2026
Suggested follow-up: 28.09.2026

If a response arrives and is linked to the outgoing contact, the open follow-up should be resolved automatically where safe.

11. Appointments

Appointments include both future and historical records.

11.1 Before appointment

questions
documents to bring
checklist
location
reminders
related case
related contact

11.2 After appointment

Structured result:

discussed[]
notDiscussed[]
decisions[]
promises[]
documentsReceived[]
nextActions[]
nextAppointment
checkpoint

The goal is exact memory, not narrative prose.

12. Routines and recurrence

Recurrence is first-class.

Examples:

gym every day
medication schedule
physiotherapy every Tuesday
rent monthly
salary on specific dates

Each occurrence has an independent state:

DONE
SKIPPED
MISSED
CANCELLED

SKIPPED may contain:

reason category
free text
saved reply/template

Example:

Gym — 18:00
SKIPPED
Reason: Recovery day

Do not merge “intentionally skipped” and “forgot/missed”.

13. Finance model

Alltag is a cash-flow forecasting system, not merely an expense tracker.

13.1 Member-aware accounts

All household members may define their financial accounts.

Examples:

Girokonto
Cash
PayPal
Credit card
Savings
Dispo
Other

Account model concept:

accountId
ownerMemberId
householdId
type
name
currency
currentBalance
creditLimit
visibilityPolicy

The Household financial view is an aggregation, not ownership transfer.

13.2 Financial event states

At minimum:

ACTUAL
SCHEDULED
SCENARIO

Also useful confidence level for future money:

CONFIRMED
EXPECTED
POSSIBLE

Example:

salary: confirmed
tax refund: expected
possible bonus: possible

Safe-to-spend must never treat speculative income as guaranteed.

13.3 Recurring finance engine

Must support:

startDate
endDate
frequency
pause
skip occurrence
override amount
amount change from date
future start
finite installment count
balloon payment
manual exception

Example:

Car financing
670 EUR monthly

Sep 2026  PAUSED
Oct 2026  PAUSED
Nov 2026  PAUSED
Dec 2026  670 EUR

This must be modeled cleanly, not as hard-coded exceptions.

13.4 Forecast

At any future point:

projectedBalance(t)
=
current balance
+ confirmed future inflows
- committed future outflows

Important outputs:

Current Balance
Committed Money
Projected Balance
Minimum Future Balance
Reserve
Safe To Spend

13.5 Safe to Spend

Example:

Current balance: 2,400 EUR
Committed:       1,748 EUR
Free:              652 EUR
Minimum reserve:   300 EUR
Safe to spend:     352 EUR

Reserve must be configurable.

13.6 Purchase simulator

A fast scenario tool must be available while shopping.

Example:

Hypothetical purchase:
450 EUR today

Output:

Balance today:       1,180 EUR
Lowest balance:        117 EUR
Lowest point:        01.10.2026

Warning:
Rent coverage becomes unsafe.

The scenario does not change actual accounting until explicitly confirmed.

Possible transition:

SCENARIO → ACTUAL

14. Contracts

Contracts are first-class entities.

Suggested fields:

provider
owner
start date
end date
monthly/periodic cost
minimum duration
notice period
renewal rule
future price changes
documents
related payments
reminders

Examples:

car financing
insurance
mobile phone
internet
university
language course
subscriptions

15. Shared household collaboration

Shared household examples:

shopping list
chores
household routines
shared reminders
household notes

Ownership still applies to every contribution.

Example:

Shopping List

Milk      owner=Soroush
Rice      owner=Bahareh

Bahareh may mark Soroush's Milk as:

BOUGHT

because this is a SHARED_ACTION.

She may not change:

Milk → Whisky

unless she owns that item or explicit collaborative-edit permission is introduced later.

16. Security model

Security is a core architectural feature, not a later UI enhancement.

16.1 Device identity

Member != Device

Example:

Bahareh
├── Samsung Phone
└── Tablet

Permissions belong to the member.

Authentication keys belong to the device.

16.2 First household device

The first device creates:

householdId
household master material
deviceId
device key pair

Sensitive keys must use Android Keystore where appropriate.

The user should not create or memorize an encryption password during normal household setup.

16.3 Pairing a new device

UX:

Existing device:
Add device
→ display short numeric code

New device:
Join household
→ enter numeric code

Recommended UX code:

8 digits
single use
short lifetime
rate limited
home LAN only

The numeric code is not the encryption key.

It only authorizes a secure pairing session.

17. Home-only sync using FRITZ!Box

The FRITZ!Box is not treated as a full application server.

It acts as:

Home Sync Vault / encrypted storage relay

Architecture:

Phone A
  local DB
     │
 encrypted deltas
     ▼
FRITZ!Box / NAS / USB
 encrypted vault
     ▲
 encrypted deltas
     │
Phone B
  local DB

No shared SQLite database over SMB.

Each phone owns its local database.

Sync uses:

change log
encrypted deltas
snapshots
device identity
versioning
conflict handling

18. Shared-data portability policies

Every shared record has a policy.

Core policies:

PRIVATE
HOME_SHARED
PORTABLE_SHARED

Recommended defaults:

Legal        HOME_SHARED
Medical      HOME_SHARED
Finance      HOME_SHARED
Documents    HOME_SHARED

Typical portable data:

Shopping List     PORTABLE_SHARED
Simple household task
Selected routine
Selected note

Only the owner may promote their sensitive data to portable shared access.

19. Home lease security

A critical threat scenario:

A household member leaves after conflict and never reconnects to the home network.

Remote deletion cannot be guaranteed.

Therefore:

Non-owned HOME_SHARED data must not be permanently decryptable outside the home.

Concept:

At home:
trusted vault reachable
+ device authorized
+ membership active
→ short-lived access lease
→ HOME_SHARED data readable

Outside home:
home unavailable
→ lease expires
→ temporary keys purged
→ HOME_SHARED data locked

Encrypted cache may remain physically present, but must not remain independently readable.

The app may lock immediately on network transition where possible and use TTL as a fallback.

20. Leaving a household

This must be a first-class security workflow.

If a member leaves:

Keep on the leaving member's device

records owned by that member
personal documents
personal finance
personal appointments
personal notes
personal tasks
personal contributions

Remove or permanently lock

other members' data
household-only data
foreign document cache
foreign attachments
shared indexes
household authorization material
home-shared decryption material

If the member owns a contribution inside another owner's case, it may be retained as:

Detached Personal Record

with context indicating that the original shared context is no longer available.

20.1 Revocation

When a member is removed:

membership = REVOKED
device authorization revoked
household access epoch/key rotated
future sync denied
foreign cache scheduled for purge

Connecting to the same Wi-Fi is never sufficient authorization.

21. Sync conflicts

Not all conflicts are equal.

Safe auto-merge candidates:

comments
additive notes
shopping additions
independent contributions

Manual conflict resolution required for sensitive conflicts such as:

financial amount
deadline date
appointment time
legal status
payment status
ownership-sensitive metadata

Never silently overwrite sensitive concurrent edits.

22. Backup and recovery

Backup is different from sync.

22.1 Local automatic backup

The app should support:

Daily
Weekly
Monthly
Manual only

Recommended default can be weekly.

Example output:

Alltag_Backup_2026-09-14.lob

Store in a user-visible, discoverable directory.

The user must be able to copy the backup to a PC or external storage without understanding internal database structure.

22.2 Backup content

Encrypted container may include:

database
settings
taxonomy
member metadata
attachments according to policy
sync metadata

A raw unencrypted SQLite file is not the intended user backup format.

22.3 Mirror

Optional backup mirroring may later use:

household vault
member-selected storage
PC copy
removable storage

Mirror is not required for basic operation.

22.4 Restore acceptance test

Required scenario:

new phone
→ install Alltag
→ choose Restore
→ select backup
→ restore
→ personal data available

Backup/restore must be tested before production release.

23. Markdown context export

Markdown is the primary human/LLM export format.

Supported scopes should include:

Case
Person
Institution
Category
Date range

Modes:

FULL
COMPACT
SINCE_LAST_EXPORT

Suggested structure:

# Case

## Current Status
## Participants
## Timeline
## Documents
## Financial Events
## Appointments
## Open Tasks
## Deadlines
## Checkpoints
## Open Questions

Exports should preserve provenance when useful:

2026-09-14 — Soroush — Payment registered
2026-09-15 — Bahareh — Letter received

LLM/AI is not required to generate a useful export.

Export must be deterministic.

24. Dashboard

The Dashboard must answer two questions:

Today

What do I need to do now?

Overview

What is the state of my life administration?

Suggested visual cards:

Today
- appointments
- tasks
- deadlines

Inbox
- unclassified captures

Waiting
- cases waiting for response

Finance
- safe to spend
- next income
- next large payment
- minimum forecast

Household
- shared tasks
- shopping

Recent
- latest documents/events

Dashboard must be icon-rich and visually scannable.

25. Search

Global search should eventually cover:

OCR text
document titles
notes
contacts
case names
Aktenzeichen/reference numbers
payments
appointments
tasks
tags
checkpoints

26. Recommended Android technology stack

Initial architecture target:

Kotlin
Jetpack Compose
Material 3
Room
Coroutines
Flow
Hilt
WorkManager
DataStore
Android Keystore
CameraX

OCR implementation may use a local/on-device solution, but no mandatory third-party cloud dependency should be introduced for core scanning.

27. Project architecture

Recommended multi-module structure:

app/

core/
  common/
  database/
  security/
  sync/
  ui/
  localization/
  notifications/
  backup/
  testing/

domain/

data/

feature/
  dashboard/
  inbox/
  taxonomy/
  cases/
  documents/
  appointments/
  tasks/
  routines/
  finance/
  household/
  contracts/
  contacts/
  reports/
  search/
  settings/

Avoid circular feature dependencies.

Business rules belong in domain/use-case layers, not Composables.

28. High-level entity inventory

This is an initial domain inventory, not a frozen SQL schema.

Household
Member
Device
Membership
DeviceAuthorization

Category
Tag
EntityTag
Relation

Case
CaseParticipant
TimelineEvent
Checkpoint
Note

Contact
Institution

Document
DocumentPage
OcrContent
DocumentAction
Attachment

Task
Deadline
FollowUp

Appointment
AppointmentChecklistItem
AppointmentOutcome
Routine
RoutineOccurrence

FinancialAccount
FinancialEvent
RecurringSchedule
ScheduleException
InstallmentPlan
Scenario
ReserveRule

Contract

ShoppingList
ShoppingItem

SyncChange
SyncCursor
SyncConflict
KeyEpoch
AccessLease

BackupMetadata

ExportHistory

All final tables must be derived carefully before migrations are frozen.

29. Development quality gates

From the beginning:

ktlint
Detekt
unit tests
Room migration tests
domain tests
security tests where practical

Before each phase is considered complete:

Build passes
Unit tests pass
Lint passes
Detekt passes
Database migrations pass
No known destructive data bug
Checkpoint generated

30. Implementation strategy — minimize number of chats

The user explicitly wants large cumulative phases and as few development chats as reasonably possible.

After initial Android Studio bootstrap, implementation should be delivered in consolidated phases.

Do not split trivial UI work into separate chats unless a build/test failure requires a repair pass.

Target:

Bootstrap + 5 major implementation phases
+ optional repair chats only if actually needed

31. PHASE 00 — Android Studio Bootstrap

Goal

Create the initial Android project and verify the environment before automated cumulative phases begin.

Deliverables

Android Studio project created
package namespace fixed
Git repository optional, but scripts must NOT commit automatically
base Gradle build working
emulator/device build verified
root project path established

Recommended default project root:

C:\Projects\Alltag

This may be overridden later by environment variable.

Checkpoint

PHASE_00_CHECKPOINT.md

32. PHASE 01 — Foundation + Localization + Domain Base

This is intentionally large.

Scope

Android foundation

multi-module setup
Compose Material 3
Hilt
Room
Coroutines/Flow
WorkManager
DataStore
testing infrastructure
ktlint
Detekt

Localization

German
English
Persian
RTL verification
no hard-coded UI strings

Design system

icon-rich components
cards
status chips
badges
owner indicators
empty states
typography
dark mode

Core identity/domain

Household
Member
Device
Membership
Owner model
permission engine abstractions
sharing policy enum

Taxonomy

default categories
reorder
custom category
nesting
tags

Inbox

quick text capture
generic unclassified item
Inbox ordering
basic classify-later workflow

Acceptance criteria

app launches
all three languages switch correctly
Persian layout is RTL
sample member/household works locally
records have owner metadata
permission tests exist
Inbox accepts unclassified items
project builds cleanly

Checkpoint

PHASE_01_CHECKPOINT.md

33. PHASE 02 — Life Core + Documents + Appointments + Routines

Another intentionally cumulative phase.

Scope

Cases

create/edit/archive
relations
linked contacts
linked items

Timeline

unified event stream
actor/owner provenance

Checkpoints

structured state snapshots

Tasks

task
deadline
status
priority

Follow-ups

default +14 day suggestion
manual override
resolve on linked response where safe

Contacts/Institutions

people
organizations
roles
case links

Documents

CameraX capture
single/multi-page
OCR
text-only storage mode
optimized scan mode
original mode
save unclassified to Inbox
document actions
lifecycle

Appointments

future and history
pre-appointment questions/checklist
post-appointment structured outcome
next action
next appointment
checkpoint

Routines

recurrence
occurrences
done/skipped/missed/cancelled
skip reason
saved reason templates

Acceptance criteria

A user must be able to:

capture a letter quickly
leave it unclassified
later attach it to a case
create multiple actions from it
schedule a follow-up
record an appointment
write a structured appointment outcome
see everything in the case timeline

Checkpoint

PHASE_02_CHECKPOINT.md

34. PHASE 03 — Finance + Contracts + Household Collaboration

Scope

Financial accounts

per-member accounts
balance
currency
optional credit/dispo limit

Income/expense events

actual
scheduled
scenario
confirmed/expected/possible

Recurrence

start
end
future start
pause
skip
override
amount change
finite installments
balloon payment

Forecast engine

projected balance
minimum balance
committed amount
reserve
safe-to-spend

Purchase simulator

hypothetical purchase
forecast recalculation
warning
scenario comparison
convert scenario to actual

Contracts

duration
provider
price
notice period
future price change
related payments
reminders

Shared household

shopping lists
shopping items
shared tasks
shared actions
ownership preserved

Acceptance criteria

Finance must correctly model examples such as:

monthly car installment
3-month payment pause
future installment restart
salary on known dates
future contract starting next year
safe-to-spend warning

All calculations require domain tests.

Checkpoint

PHASE_03_CHECKPOINT.md

35. PHASE 04 — Home Sync + Security + Pairing + Backup + Household Exit

This phase contains the hardest technical work.

Scope

FRITZ vault discovery/config

local network only
storage relay
no shared SQLite

Pairing

first household device
additional device
short numeric pairing code
secure underlying key exchange

Encrypted delta sync

change log
encrypted payloads
per-device cursor
snapshots if required
retry
interrupted sync recovery

Conflict engine

additive auto-merge
sensitive manual conflict resolution

Security

Android Keystore integration
membership authorization
key epochs
revocation
home access lease
HOME_SHARED lock outside home
PORTABLE_SHARED behavior
foreign cache protection

Backup

daily/weekly/monthly/manual
encrypted backup container
visible file location
retention

Restore

restore on new device

Leave household

keep owned data
purge/lock foreign data
revoke sync
rotate household access
detach owned contributions where necessary

Required adversarial tests

member leaves home during conflict
device never reconnects
foreign HOME_SHARED records become unreadable
portable shopping list remains usable
removed member returns to same Wi-Fi
removed member still cannot sync/decrypt
sync interrupted mid-write
FRITZ unavailable
device reboot
app process killed

Acceptance criteria

No production release before this phase passes.

Checkpoint

PHASE_04_CHECKPOINT.md

36. PHASE 05 — Reports + Dashboard + Search + Hardening + Release Candidate

Scope

Markdown export

full
compact
since last export
provenance
case/person/institution/category/date range scopes

Search

OCR
notes
cases
contacts
references
finance
appointments
tags

Dashboard

Today
Overview
Inbox
Waiting
Finance
Household
Recent

Notifications

deadlines
appointments
follow-ups
routines
upcoming payments
backup failure
sync problems

Hardening

Room migration tests
large data tests
low-storage behavior
corrupt backup handling
corrupt sync payload handling
encryption failure handling
accessibility review
RTL regression review
localization completeness
performance
battery/background behavior

Release candidate

app versioning
signed build process documentation
final known limitations
final architecture checkpoint

Checkpoint

PHASE_05_RELEASE_CHECKPOINT.md

37. POST-MVP — optional

Only after the core is stable.

Candidates:

Android / Samsung home-screen widget
Google/Android Calendar integration
desktop companion
advanced statistics
optional self-hosted server
optional encrypted cloud mirror
advanced on-device classification
more export formats
tablet-optimized layouts

The widget is expected to be an important later feature.

Possible widget content:

today's appointments
urgent task count
next deadline
safe-to-spend
shopping list shortcut
quick capture

38. Mandatory development-chat delivery protocol

This section is extremely important.

After Phase 00, every implementation chat should normally deliver one cumulative executable Python patch file for that phase or repair pass.

The user wants to download the file and execute it without caring which working directory the terminal is currently in.

38.1 File location

Generated patch script is expected to be downloaded to:

%USERPROFILE%\Downloads

Example filename:

Alltag_PHASE_01_FOUNDATION.py

38.2 Execution command from ANY directory

Preferred command:

py "$env:USERPROFILE\Downloads\Alltag_PHASE_01_FOUNDATION.py"

Fallback:

python "$env:USERPROFILE\Downloads\Alltag_PHASE_01_FOUNDATION.py"

The user must not need to cd into the project before running the script.

38.3 Project-root discovery

Every patch script must locate the Alltag project using this order:

1. ALLTAG_ROOT environment variable, if valid
2. C:\Projects\Alltag
3. optional safe fallback discovery if explicitly implemented

If the project cannot be located, stop with a clear error.

Do not silently modify an unrelated directory.

38.4 Script behavior

Each phase script should be:

idempotent where practical
deterministic
self-validating
clear in console output
safe against wrong project root

It should:

verify project root
verify expected previous-phase checkpoint
write/update required files
avoid unrelated changes
run formatting where practical
run targeted tests/build checks where practical
generate/update the phase checkpoint
print exact next commands if a long Gradle task is intentionally left to the user

38.5 No automatic backup or Git commit

Unless the user explicitly asks otherwise:

NO source backup copies
NO ZIP backup
NO automatic git commit
NO automatic git push

The patch script should be designed to be repeatable and safe instead.

38.6 One script per chat whenever possible

Avoid:

Patch 01
Patch 02
Patch 03
Patch 04

for ordinary planned work.

Prefer:

one cumulative phase script

Only create repair scripts if build/test output proves that a repair is actually necessary.

This is intended to minimize the number of chats.

39. Phase checkpoint protocol

Every major phase must generate a Markdown checkpoint inside the project.

Example:

docs/checkpoints/PHASE_03_CHECKPOINT.md

Checkpoint content:

Phase name
Completion date
Implemented scope
Architecture decisions
New modules
Database schema/migrations
Security implications
Localization changes
Tests executed
Build commands
Known limitations
Deferred items
Exact next phase

A new ChatGPT conversation should be able to continue with:

Alltag_MASTER_PLAN.md
+
latest PHASE_xx_CHECKPOINT.md
+
current build/test output if failing

No old chat transcript should be required.

40. Rules for future ChatGPT sessions

When continuing this project:

Treat this file as authoritative unless the user explicitly changes a requirement.
Do not redesign ownership casually.
Do not replace local-first with mandatory cloud.
Do not use a shared SQLite database over SMB.
Do not permanently expose HOME_SHARED foreign data outside home.
Do not make passwords a normal household pairing requirement.
Do not hard-code UI text.
Preserve German/English/Persian support.
Preserve RTL.
Keep the interface icon-rich.
Prefer large cumulative phases.
Deliver one executable Python patch file per development chat when possible.
Scripts must run from Downloads regardless of the user's current terminal directory.
Do not request source re-upload if the required project and checkpoint are already available to the user and the script can operate directly against the local project.
Do not make automatic Git commits unless explicitly requested.
Every completed phase must write a checkpoint.

41. Product threat model — minimum scenarios

The project must be designed against at least these scenarios:

Lost phone
Stolen phone
Household member leaves after conflict
Former member still knows Wi-Fi password
Former member has old encrypted sync files
Guest connects to home Wi-Fi
FRITZ USB storage is stolen
Sync interrupted
Two members edit same sensitive record
Backup copied to a PC
User restores an old backup
App is killed during write
Low disk space
OCR misreads amount/date

Important principle:

A network connection is not authorization.

Important principle:

OCR detection is not confirmation.

Important principle:

Remote deletion cannot be relied upon; cryptographic access control must prevent durable unauthorized readability.

42. Data integrity principles

For sensitive data:

do not silently overwrite concurrent edits
use stable UUID/ULID-style identifiers
maintain creation and update metadata
preserve owner provenance
prefer soft archive over destructive delete where appropriate
destructive deletion must follow ownership rules
migrations must be tested
sync changes must be replay-safe/idempotent where possible
financial calculations must be deterministic and covered by tests

43. Definition of MVP

Alltag MVP is complete when one household with at least two Android devices can:

create a household
pair securely
work offline
capture and OCR a letter
store text-only or image-backed documents
organize Inbox items later
create a case
add multiple actions to a letter
track deadlines and follow-ups
manage appointments and outcomes
manage recurring routines
track member-owned financial accounts
forecast future balance
simulate a purchase
share a shopping list
respect owner permissions
sync only through home FRITZ storage
lock foreign HOME_SHARED data away from home
remove a household member safely
create encrypted local backups
restore from backup
export a complete Markdown case context
use German, English and Persian
use the app comfortably in both LTR and RTL

44. Immediate next step

If starting from scratch:

STEP 1
Create Phase 00 Android Studio project.

STEP 2
Verify:
- Android build
- emulator/device launch
- project root

STEP 3
Provide this MASTER_PLAN and Phase 00 checkpoint to ChatGPT.

STEP 4
Generate one cumulative:
Alltag_PHASE_01_FOUNDATION.py

STEP 5
Run from any directory:

py "$env:USERPROFILE\Downloads\Alltag_PHASE_01_FOUNDATION.py"

Then proceed phase by phase using the latest checkpoint.

45. Final architectural summary

Alltag is built around five fundamental engines:

1. Ownership & Household Engine
2. Life Timeline / Obligation Engine
3. Document & Capture Engine
4. Financial Forecast Engine
5. Home Security & Sync Engine

Everything else is a feature surface over those foundations.

The architecture should optimize for:

privacy
clarity
low cognitive load
offline usability
family collaboration
strong ownership boundaries
recoverability
long-term maintainability

The application must feel simple to the user even though the underlying architecture is intentionally strict.

End of Master Plan

This file should be retained with the project and provided to any future development conversation before implementation continues.