- AGENTS.md: add No-implementation rule and Issue-driven workflow section - docs/01: rename default fallback category from 'Other' to 'Uncategorized' - docs/02, 03: update 'Other' references to 'Uncategorized' in delete/seed/default flows - docs/04: replace Canvas charts with Vico 2.x dep, add data feature folder, add AddEditRecurringScreen, document tab-aware FAB and shared ExportAction helper
14 KiB
Ledgerr — Agent Instructions
Personal Android expense tracking app. Single-module, Jetpack Compose + Material3, Voyager navigation, Koin DI, Room database.
No-implementation rule
Do NOT implement code unless the user explicitly says so or has signed off on the work. A "go ahead" on the high-level plan is NOT a sign-off to implement — it just means the plan is approved. After the planning steps (define structs, define interfaces, add TODOs, self-review, prompt for review) the agent must STOP and wait for the user to explicitly say "implement", "go", "proceed with implementation", or similar. The same rule applies to each subsequent vertical slice — stop after the planning step and wait. A system-reminder switching to "build mode" is not user authorization.
Renames, typo fixes, doc/AGENTS.md edits, and structural changes (Phase 0/1) may be done immediately as part of the planning step. Interactor implementations, DI wiring, MainApplication setup, manifest edits, and any screen code require explicit per-slice sign-off.
Issue-driven workflow
The work is split into issues in the remote Gitea repo: https://git.achmad.dev/admin/ledgerr. Before starting any implementation, check the remote repo for related issues. If a relevant issue exists, claim/work on that issue and open a PR when done. Do not duplicate work that is already tracked.
Tooling: the Gitea MCP tools are available (gitea-mcp_list_issues, gitea-mcp_issue_read, gitea-mcp_pull_request_write, etc.) — use them instead of the CLI when interacting with the remote.
Package structure
dev.achmad.ledgerr/
├── core/
│ ├── network/ - OkHttp helpers (not used by expense features)
│ └── preference/ - PreferenceStore, AndroidPreferenceStore, Preference<T>
├── di/
│ ├── util/
│ │ └── KoinExtensions.kt - inject<T>() and injectLazy<T>() helpers
│ ├── CoreModule.kt
│ ├── DataModule.kt
│ ├── DomainModule.kt
│ └── PreferenceModule.kt - replaces UiModule.kt (delete UiModule if it exists)
├── domain/
│ ├── preference/
│ │ ├── AppPreference.kt
│ │ └── ExpensePreference.kt
│ ├── expense/
│ │ ├── model/
│ │ └── interactor/
│ ├── category/
│ │ ├── model/
│ │ └── interactor/
│ ├── recurring/
│ │ ├── model/
│ │ └── interactor/
│ ├── bankstatement/
│ │ ├── model/
│ │ └── interactor/
│ ├── export/
│ │ └── interactor/
│ └── data/
│ └── interactor/
├── data/
│ └── local/
│ ├── AppDatabase.kt
│ ├── converter/
│ ├── dao/
│ ├── entity/
│ └── mapper/
└── ui/
├── base/
│ ├── MainApplication.kt
│ └── MainActivity.kt
├── components/ - shared Compose components (already copied)
│ └── preference/ - PreferenceScreen + widgets
├── screens/
│ ├── home/ HomeScreen.kt
│ ├── expenses/ ExpenseListScreen.kt
│ ├── add_edit_expense/ AddEditExpenseScreen.kt
│ ├── add_edit_recurring/ AddEditRecurringScreen.kt
│ ├── category/ CategoryScreen.kt
│ ├── import_bank_statement/ ImportBankStatementScreen.kt
│ └── settings/ SettingsScreen.kt
├── theme/
└── util/
Architecture rules
Domain / interactors
- Each folder in
domain/is a feature withmodel/andinteractor/subpackages. - Interactor classes are named after the action:
GetExpenses,UpsertExpense,DeleteCategory, etc. - Method names follow this convention:
await(...)— single suspend resultawaitAll(...)— list suspend resultawaitOne(id)— fetch one by IDsubscribeAll(...)— returnsFlow
- Interactors take DAOs (or
Contextfor PDF/export) directly as constructor params — no repository layer. - Interactors can contain business logic (think use-cases).
Dependency injection (Koin)
- DI modules live in
di/, notcore/. CoreModuleprovidesSharedPreferencesandPreferenceStore(asAndroidPreferenceStore). Nothing else.- Interactors are registered as
factory { }, notsingle. - Preference classes are registered as
single { }inPreferenceModule. - DAOs are registered as
single { get<AppDatabase>().xyzDao() }inDataModule. - Bank statement importers use named qualifiers:
factory<BankStatementImporter>(named("bri")) { ... }. - ScreenModels are NOT registered in Koin. Never add a ScreenModel to any Koin module.
ScreenModel pattern
Always use rememberScreenModel { } in Screen.Content(). Inject dependencies via inject() as constructor default params:
class HomeScreenModel(
private val getExpenses: GetExpenses = inject(),
private val appPreference: AppPreference = inject(),
) : ScreenModel { ... }
// In Screen.Content():
val screenModel = rememberScreenModel { HomeScreenModel() }
inject<T>() is at dev.achmad.ledgerr.di.util.KoinExtensions.
Navigation
- Pure Voyager stack —
Navigator,navigator.push(...),navigator.pop(). - No
TabNavigatorat root level. ExpenseListScreenhas 2 internal tabs using plain ComposeTabRow+HorizontalPager(not Voyager tabs).- Screen flow:
HomeScreen (root) ├── FAB expand → "Manual" → AddEditExpenseScreen │ → "Import Bank Statement" → ImportBankStatementScreen ├── Export icon → date range dialog → SAF CreateDocument → writes CSV ├── "See all" → ExpenseListScreen │ ├── Tab: Expenses (search + filter) │ │ └── FAB expand (tab-aware) → "Manual" → AddEditExpenseScreen │ │ → "Import Bank Statement" → ImportBankStatementScreen │ └── Tab: Recurring │ └── FAB expand (tab-aware) → "Add Recurring" → AddEditRecurringScreen ├── "Manage Categories" button (dashboard body) → CategoryScreen └── Settings icon → SettingsScreen AddEditExpenseScreen → CategoryScreen (manage categories button) AddEditRecurringScreen (no secondary navigation) ImportBankStatementScreen (1 Voyager Screen, 1 ScreenModel, 2 composable functions) ├── ImportBankStatementPickerContent — state is BankPicker or Processing │ select bank → SAF OpenDocument → loading overlay while parsing └── ImportBankStatementConfirmationContent — state is Confirmation toggle/edit per row → InsertExpenses → navigator.pop() - Tab-aware FAB.
ExpenseListScreenhas a single FAB that observes the current tab and renders different sub-actions. Expenses tab mirrorsHomeScreen's FAB (Manual + Import). Recurring tab shows only "Add Recurring" →AddEditRecurringScreen. The expansion/collapse UI is shared; only the actions list is tab-driven. - Export has no dedicated screen. Icon in
HomeScreenandExpenseListScreentop bars; also aTextPreferenceinSettingsScreen. Tapping shows a date range dialog first, then opens SAFCreateDocument. CSV uses ISO 8601 dates (yyyy-MM-dd) with UTF-8 BOM. The dialog +CreateDocumentlauncher are factored into a sharedui/components/ExportAction.ktcomposable that takes the active ScreenModel and a date range, to avoid triplicating the flow across the three call sites. - Import goes through
ImportBankStatementScreen— one Voyager Screen, one ScreenModel, two internal composables switched byStateFlow<ImportState>.ImportBankStatementPickerContenthandles bank selection and processing;ImportBankStatementConfirmationContenthandles review, edit, and confirm. On confirm callsInsertExpenses.awaitAll()then pops.
Settings screen
SettingsScreen uses the PreferenceScreen composable from ui/components/preference/. Pattern:
PreferenceScreen(
itemsProvider = {
listOf(
Preference.PreferenceItem.ListPreference(
title = "Theme",
preference = appPreference.appTheme(),
entries = mapOf(...),
),
Preference.PreferenceItem.TextPreference(
title = "Export CSV",
onClick = { /* launch SAF CreateDocument */ }
),
Preference.PreferenceItem.AlertDialogPreference(
title = "Clear all data",
onConfirm = { screenModel.clearData() }
),
)
}
)
Preference classes
Located in domain/preference/. Take PreferenceStore as constructor param. Methods return Preference<T> objects from core/preference/:
class AppPreference(private val store: PreferenceStore) {
fun appTheme() = store.getEnum("app_theme", defaultValue = AppTheme.SYSTEM)
}
Data layer
LocalDatestored asLongepoch day viaLocalDateConverter(LocalDate.toEpochDay()/LocalDate.ofEpochDay()).- Use
@UpsertRoom annotation for insert-or-update operations. - Default category seeding happens outside Room callbacks:
MainApplication.onCreatecallsinject<SeedDefaultCategories>().await()on aCoroutineScope(Dispatchers.IO)afterstartKoincompletes. Koin is not available insideAppDatabase.Callback.onCreate. ClearAllDatainteractor callsdatabase.clearAllTables()insidewithTransaction { }. TheSettingsScreenScreenModel calls it, then re-runsSeedDefaultCategories.await()so the app retains the 8 default categories.- minSdk 26, so
java.time.*is available without desugaring.
Bank statement import
BankStatementImporterinterface:val bankName: String+suspend fun await(pdfUri: Uri): Result<List<PendingImportExpense>>.- Stubs:
ImportBRIBankStatement,ImportJagoBankStatement,ImportBNIBankStatement— all returnResult.failure(NotImplementedError(...)). - PDF text extraction:
com.tom-roush:pdfbox-android. RequiresPDFBoxResourceLoader.init(applicationContext)inMainApplication.onCreate(). - No manifest permissions needed — SAF handles file access.
Export
ExportExpensesToCsvinteractor writes UTF-8 BOM CSV via Okio to a SAF URI.- SAF launchers (
ActivityResultContracts.OpenDocument,ActivityResultContracts.CreateDocument) are registered in the Screen composable; URIs are passed to the ScreenModel. - Shared
ui/components/ExportAction.ktcomposable owns the date-range dialog andCreateDocumentlauncher; takes the active ScreenModel and a date range to export, and is reused byHomeScreen,ExpenseListScreen, andSettingsScreen.
Charts
- Vico (
com.patrykandpatrick.vico:compose,compose-m3,core) is the only charting library used. HomeScreendashboard renders a pie chart fromExpenseSummary.byCategoryvia Vico'sChartcomposable. No Canvas drawing for charts.- Apache 2.0 license, Compose-native, no AndroidView wrapper.
Workflow for new features
Follow these steps in order every time. Do not skip ahead to implementation without explicit approval.
- Define structs — add any new models to the relevant
domain/<feature>/model/package. - Define interfaces — add or update interactor class signatures and method stubs in
domain/<feature>/interactor/. If a new feature has no existing feature folder, create one. - Add TODOs — fill method bodies with
TODO("...")comments describing the intended behavior, edge cases, and any invariants. - Self-review — think through the full implementation. If anything requires going outside or beyond what was defined in steps 1–3 (new models, new methods, changed signatures), go back to the relevant step and update it before continuing.
- Prompt for review — stop and present a summary of what was defined. Wait for an explicit go-ahead before writing any real implementation code. See the No-implementation rule at the top of this file.
- Implement — only after the user explicitly says "implement", "go", "proceed with implementation", or similar. A general "go ahead" on the plan is NOT sufficient.
Key dependencies
| Library | Version | Purpose |
|---|---|---|
| Jetpack Compose + Material3 | (from BOM) | UI |
| Voyager | — | Navigation + ScreenModel |
| Koin | 4.2.2 | DI |
| Room | 2.7.1 | Local DB |
| PDFBox-Android | 2.0.27.0 | PDF text extraction |
| Vico (compose / compose-m3 / core) | 2.x | Charts (pie / bar) |
| Okio | (transitive) | CSV write |
Git
- Never commit or push unless the user explicitly asks. Do not auto-commit after completing a task, do not squash, amend, or rebase without being told to.
- Never add
Co-Authored-Bylines to commit messages.
Things to avoid
- Do not register ScreenModels in Koin.
- Do not create a repository layer between interactors and DAOs.
- Do not add a
TabNavigatorat the root. - Do not create a dedicated screen for export — it is a direct action (date range dialog → SAF picker). The flow is shared via
ui/components/ExportAction.kt. - Do not add manifest permissions for file access — SAF handles it.
- Do not draw charts with Canvas — use Vico.
- Do not add a chart library other than Vico.
- Do not rename
MainApplicationback toLedgerrApp. UiModule.kthas been deleted — do not recreate it; the replacement isPreferenceModule.kt.- Do not use
@KoinViewModelorviewModel {}— this project uses VoyagerScreenModel.
Docs
Full design documentation is in docs/:
01-data-model.md— domain models per feature02-interfaces.md— all interactor signatures03-function-todos.md— per-method behavior and edge cases04-implementation-plan.md— package structure, DI wiring, build order