尚未偵測到更新。GitHub 發布版本後會顯示在這裡。
個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證製作者的介紹僅有上面的一句話。 更多詳情請閱讀儲存庫 README。 儲存庫 README ↗
正在載入完整 README。
檢視完整 README ↗Personal spending tracker. Exports Come Citizens Bank transaction CSV, categorizes each line with a local Ollama LLM (100% offline), keeps a master history, and generates HTML budget reports.
pandasMODEL_NAME in the scripts (currently qwen2.5:3b; run ollama pull qwen2.5:3b once)docs/ is served by GitHub Pages at https://erikfol.github.io/erik-life-app/: the Erik's Life App home page (docs/index.html) that links to each app.
docs/bills-etc/ holds a browser version of the whole bills workflow, at
https://erikfol.github.io/erik-life-app/bills-etc/.
docs/health/ is the Health app (General Health, Dental, Eye, Health Savings Account (HSA) tables), which saves to inputs/health/ in the same folder.
docs/vehicles/ is the Vehicles app (one page per vehicle: information + maintenance table), which saves to inputs/vehicles/.
docs/shared/ holds the editable record table and folder prompt that Health and Vehicles share. It's static HTML and JavaScript with no build step. Your data is never put on GitHub:
inputs/, output_master_data/, config.json), so you can mix the GUI and the scripts.Dropbox\Apps\ErikLifeApp\, so a tablet or phone can use it too: there the app signs in with Dropbox (docs/shared/js/dropbox.js, Dropbox app "ErikLifeApp", app-folder access only) and reads and writes the same files through Dropbox. On the PC, inputs/, output_master_data/ and reports/ in this repo are links (junctions) into that folder and config.json is found next to them, so the scripts work as before.setx OLLAMA_ORIGINS "https://erikfol.github.io"config.json scheduled_bills: paid / due / late each month, 12-month grid, suggestions from history; transactions matching a bill's merchant count as scheduled, everything else as unscheduled), Dashboard (history report and AI analysis), Finance Table (fix the processed month or the master), Config (tabs: Income & Bills, Categories, Merchants — one table of merchant rules and the names that still need one).To run it locally instead: python -m http.server 8000 -d docs and open http://localhost:8000. Ollama allows localhost by default.
Merchant names and forced categories come only from merchant_rules in config.json (edit them on Config → Merchants); the GUI and the scripts apply them the same way. The rules that used to be hardcoded were moved there by tools/migrate_rules.py.
inputs/past_months/.python 1_backfill_prev_months_to_master.py
output_master_data/all_time_finances.csv.python 2_process_master_data_plus_report.py to view the data —
writes a styled HTML report (cash flow, category breakdowns, trends, transaction tabs, AI analysis) to reports/<latest_month>_report.html and opens it.inputs/current_month/ (exactly one file).python 3_process_current_month.py --ai to categorize any new transactions with AI (results are cached).output_master_data/processed_current_month.csv and fix any categories by hand.python 3_process_current_month.py again (no --ai) to regenerate the projection:
config.json).(spent / days_elapsed) * days_in_month.reports/<YYYY_MM>_projection.html and opens it.python 4_close_month.py.
inputs/past_months/<YYYY_MM>_closed.csv, archives the processed file, and clears inputs/current_month/.config.json| Key | Purpose |
|---|---|
monthly_income_* | Expected monthly take-home pay; summed by script 3 |
fixed_expenses | Bills that hit every month (~same amount) |
variable_categories | Categories that are day-scaled to project the full month |
categories | Your category list (optional; defaults to the built-in 12). Managed on the GUI's Config page |
category_renames | Old → new names, so the built-in rules and older data follow a rename (managed by the GUI) |
merchant_rules | {name?, bank_text: [...], match: [...], category?}: when the bank text contains one of bank_text (letters only) or the merchant is one of match, use this name and/or category. The only place merchant names and forced categories come from, in the GUI and the scripts (bills_config.py). Managed on Config → Merchants |
Keys starting with _ are ignored. See the notes in the file itself.
| Path | Contents |
|---|---|
inputs/past_months/ | Bank CSVs for history to backfill |
inputs/current_month/ | Bank CSV for the current month (one file) |
output_master_data/all_time_finances.csv | Master history of all transactions |
output_master_data/processed_current_month.csv | Current month's categorized rows (edit here) |
output_master_data/categorized_cache.csv | AI categorization cache for the current month |
reports/ | Generated HTML reports |
Groceries, Dining Out, Utilities, Rent/Mortgage, Entertainment, Shopping, Transport, Gas, Income, Savings, Credit Card, Miscellaneous
Categorization order: manual edits in the processed file → your history → cache → AI (with --ai) → override/keyword rules.
History-first: a transaction whose merchant (first three words of the description, letters only, so store numbers are ignored) already appears in the master gets that merchant's most common category, as long as that category is a strict majority. That covers roughly 80% of transactions, so the AI only sees new merchants. Fixing a category in the master teaches the lookup. The logic is in history_lookup.py and docs/js/history.js; keep them in sync. Known merchants that the AI gets wrong are pinned in each script's CATEGORY_OVERRIDES / MERCHANT_CATEGORY_OVERRIDES lists — add entries there for anything else it keeps miscategorizing.
DESCRIPTION_COL / AMOUNT_COL in script 1 if your bank's export differs.