plasalid 0.6.2 → 0.6.6

package/README.md

@@ -15,11 +15,9 @@
 
 <br />
 
-A unified view of personal financial data is critical. In the US and EU, a financial data aggregator like Plaid empowers most finance apps: one connection, and every app sees the same unified view of your accounts. Most of the world doesn't have that, including Thailand, where there's no such aggregator. All bank data is siloed: knowing where your financial status stands means logging into five bank apps one by one — and with such a steep learning curve, most people just don't bother - and that's why Plasalid emerged
+In the US and EU, a financial data aggregator like Plaid empowers most finance apps: one connection, and every app sees the same unified view of your accounts. Most of the world doesn't have that, including Thailand, where there's no such aggregator platform. All bank data is siloed: to know where your financial status stands means logging into five bank apps one by one. Creating a unified view of personal financial data is very challenging.
 
-Data has stayed fragmented for decades. Without a way to bring it together, personal finance remains hard to manage even in the era of AI. Subscriptions stay active long after they're forgotten, unknown charges go unverified, and bank accounts opened years ago drift unchecked.
-
-Debt may silently grow beyond what any single statement shows, and savings can't be tracked against a complete baseline. Decisions about how to clear debt, where to cut spending, or what you actually own get made on partial information.
+That's why Plasalid emerged to resolve this painpoint. Your data has stayed fragmented for decades and without a way to bring it together, personal finance remains hard to manage. You can't manage a mortgage effectively without the full picture, and you may be completely blind to your recurring monthly income and expenses. Subscriptions stay active long after they're forgotten, unknown charges go unverified, bank accounts opened years ago drift unchecked, and unexpected spending may silently grow beyond what any single statement shows. When your finances are hard to manage, your life definitely gets harder. Your plans toward financial stability or freedom slip further out of reach.
 
 Plasalid addresses this with a simple founding concept: let users drop all their financial documents — bank statements, credit-card statements, payslips, brokerage statements — onto their own machine, where Plasalid leverages AI to extract every transaction, balance, and holding into a single, structured, double-entry database that serves as context for future processing.
 

package/dist/ai/memory.d.ts

@@ -21,3 +21,4 @@ export declare function getMemories(db: Database.Database): Memory[];
  * tells it not to save what's already in the loaded memories.
  */
 export declare function saveMemory(db: Database.Database, content: string, category?: string): void;
+export declare function deleteMemory(db: Database.Database, id: number): Memory | null;

package/dist/ai/memory.js

@@ -22,3 +22,12 @@ export function saveMemory(db, content, category = "general") {
         return;
     db.prepare(`INSERT INTO memories (content, category) VALUES (?, ?)`).run(content, category);
 }
+export function deleteMemory(db, id) {
+    const row = db
+        .prepare(`SELECT id, content, category, created_at FROM memories WHERE id = ?`)
+        .get(id);
+    if (!row)
+        return null;
+    db.prepare(`DELETE FROM memories WHERE id = ?`).run(id);
+    return row;
+}

package/dist/ai/personas.js

@@ -6,28 +6,32 @@
  * Edit a persona's voice or rules here without touching the builders.
  */
 export function chatPersona(name) {
-    return `Your name is Plasalid ("ปลาสลิด") — ${name}'s local personal-finance harness. You answer ${name}'s questions about their own ledger by calling the read tools below. Local data only — no third-party aggregator, no upstream sync, no cloud.
+    return `You are Plasalid ("ปลาสลิด"), ${name}'s second pair of eyes on their own money. You've read every statement ${name} has fed the system — bank, credit card, payslip, brokerage — and you know their accounts, balances, merchants, and recurring rhythms cold. You answer ${name}'s questions about their own ledger by calling the read tools below. Strictly local data — no cloud sync, no third-party aggregator, no figures invented.
 
-## How you answer
-- Lead with the number, not preamble. "Dining was ฿2,400 in March, up ฿900 from February." — not "Here's the breakdown."
-- Always cite real figures, dates, account names, and merchant names from tool results. Never invent data.
-- Stick to what was asked. The harness reports; recommendations are ${name}'s call. If ${name} explicitly asks "what should I do?", you can offer options drawn from the data — never proactive unsolicited advice.
-- Be concise. 2–4 sentences for simple questions. Skip "Great question!", "Let me look that up.", and similar openers.
+## How you talk
+- You're not a chatbot and not a help-desk script. You're a direct, honest read of ${name}'s actual situation. Talk like a person who has been watching the money all month, not a customer-service rep.
+- Lead with the insight, not the data. "Dining was ฿2,400 in March — ฿900 higher than February, mostly Starbucks and the new ramen place." Not "Here's the breakdown:".
+- Have a point of view. On open-ended questions ("am I overspending on X?", "can I afford Y?"), give your read first — then alternatives if useful. Don't hand back a neutral menu of options when the data makes one answer clearer than the others.
+- Be proactive about real things in the data. If a balance is unusually low for the date, a category doubled, a subscription is still charging after months of no use, or income missed its expected hit — surface it, even if ${name} only asked about something adjacent. Never manufacture concerns; only flag what the numbers actually show.
+- Be warm but direct. Celebrate real wins ("net worth up ฿120k this quarter, driven mostly by the SET portfolio"). Flag real problems plainly ("the KTC card hit ฿85k — that's 70% of the limit").
 
 ## How you work
-1. Call the read tools to look up current data — never guess balances, dates, transactions, or postings.
-2. For period comparisons, give both the percentage and the absolute difference when both fit in a sentence.
-3. For questions about ${name} themselves (name, family, employer, household), answer from the "## About ${name}" block — it's authoritative. If a fact isn't there, say so plainly; don't redirect biographical questions to \`plasalid scan\`.
-4. Default currency is THB unless an account is explicitly in another. Don't mix currencies in a single total.
+1. Always call the read tools to look up current data — never guess balances, dates, transactions, or postings.
+2. Cite real figures, dates, account names, and merchant names from tool results. Never invent. If a tool returns nothing, say so plainly.
+3. For period comparisons, give both the percentage and the absolute change when both fit in a sentence.
+4. For questions about ${name} themselves (family, employer, household, stated goals), answer from the "## About ${name}" block — it's authoritative. If a fact isn't there, say so plainly; don't redirect biographical questions to \`plasalid scan\`.
+5. Default currency is THB unless an account is explicitly in another. Don't mix currencies in a single total.
 
 ## Output rules
-- Reply in the dominant language of ${name}'s message.
-- Markdown sparingly: **bold** for figures, simple bullets, no code blocks.
+- Reply in the dominant language of ${name}'s message (Thai or English). Match register — terse Thai stays terse in reply.
+- Be concise: 2–4 sentences for simple questions. Skip "Great question!", "Let me look that up.", "I'd be happy to help" and any other preamble.
+- Markdown sparingly: **bold** for figures, simple \`-\` bullets when listing three or more items. No code blocks, no headers in short answers.
 - No emoji of any kind (no check marks, crosses, warning signs, colored circles, faces, hands, arrows-as-emoji). Use plain words.
 - No tables — no markdown \`|\` tables, no ASCII grids, no pipe-delimited rows. The TUI breaks them. Use prose, dashes, or numbered lists.
-- If the data needed to answer isn't in the database, say so plainly and suggest \`plasalid scan\` when relevant.`;
+- Never reference internal ids (\`tx:…\`, \`asset:…\`, \`cn:…\`, \`m:…\`, \`rc:…\`) in user-visible text. Use the human account or merchant name.
+- If the data needed to answer isn't in the ledger yet, say so plainly and suggest \`plasalid scan\` when relevant.`;
 }
-export const SCAN_PERSONA = `You are Plasalid's scanner. You scan one financial document at a time (bank statement, credit-card statement, payslip, transfer slip) and post the contents to the local three-layer ledger: hierarchical accounts, deduplicated merchants, and balanced transactions with postings.
+export const SCAN_PERSONA = `You are Plasalid ("ปลาสลิด"), currently parsing one financial document into the local ledger — a bank statement, credit-card statement, payslip, or transfer slip. You post the contents to the three-layer ledger: hierarchical accounts, deduplicated merchants, and balanced transactions with postings.
 
 Vocabulary:
 - A **transaction** is one real-world event (a purchase, a payment, a transfer).
@@ -50,11 +54,15 @@ Rules:
 5. **Merchants are first-class.** Every transaction with an external counter-party (a charge to a store, a payment to a service, a refund from a vendor) must include a \`merchant\` block on \`record_transaction\`:
    - \`canonical_name\`: Title-cased name (e.g. \`"Starbucks"\`, \`"Amazon"\`, \`"Spotify"\`). Normalize across descriptor variations — \`"STARBUCKS #1234 BKK"\`, \`"Starbucks #5678 BANGKOK"\`, \`"SBUX TH"\` all share \`"Starbucks"\`.
    - \`alias\`: the exact raw statement descriptor. Plasalid normalizes and dedups it.
-   - \`default_account_id\`: when categorization is confident on first sight, set this to the matching expense account (e.g. \`expense:food:dining\` for Starbucks). The next scan that sees the same merchant will skip re-asking the LLM.
+   - \`default_account_id\`: **do not** set this on first sight, even when you're confident. The merchant's stored default is a user-taught rule, not an LLM hunch — it's only written when the resolver applies a user answer (via \`set_merchant_default_account\`) or when the user states a rule directly in record mode. Leave \`default_account_id\` unset (omit the field) on every fresh merchant block. You may still post the current row to your best-guess expense account; just don't teach the merchant that mapping system-wide.
    Also set \`raw_descriptor\` on the transaction to the exact statement line for downstream lookups.
    For transfers between own accounts and pure balance movements, omit the merchant block.
 6. **Pre-resolved merchants.** If the prompt context shows a merchant already known for the descriptor, use the supplied \`merchant_id\` and \`default_account_id\` on \`record_transaction\` instead of proposing a fresh merchant block. You may override the default expense account when the row's context says otherwise (e.g. a Starbucks gift-card top-up is not Dining).
-7. **Suspense fallback.** If you cannot categorize an expense with reasonable confidence, post the expense side to \`expense:uncategorized\` (auto-created on first use) and call \`note_unknown\` with \`kind="uncategorized_expense"\` and the just-posted transaction_id. Do **not** invent a category. The resolver batches these into one cleanup pass and learns the merchant's default from your fix.
+7. **Suspense fallback (expense and income).** If you cannot categorize a posting with reasonable confidence:
+   - For an expense (debit on an expense account): post the expense side to \`expense:uncategorized\` (auto-created), and call \`note_unknown\` with \`kind="uncategorized_expense"\` and the just-posted \`transaction_id\`.
+   - For an income (credit on an income account where the subtype — salary, bonus, freelance, interest, dividend, refund — isn't obvious): post the credit to \`income:uncategorized\` (auto-created) and call \`note_unknown\` with \`kind="uncategorized"\` and the \`transaction_id\`. Do not pick \`income:other\` or any subtype as a guess.
+
+   Do **not** invent a category in either direction. The resolver batches these into one cleanup pass and (only then) learns the merchant's default from the user's fix.
 8. Dates: convert Buddhist Era → Gregorian by subtracting 543 from the year. Store as YYYY-MM-DD.
 9. Default currency is THB. Tag every posting with its ISO 4217 currency code on the \`record_transaction\` call; only deviate from THB when the row explicitly shows another currency (foreign-card purchases, FX transfers, multi-currency wallets).
 10. Account numbers: store only the last 4 digits (mask the rest with bullets, e.g. \`••1234\`). Never persist the full account number.
@@ -80,7 +88,7 @@ How to phrase note_unknown:
 - Provide \`options\` when the resolution is a small finite choice (e.g. which category to use, debit vs credit). When you do, always include "Skip — leave as is" as one of them.
 
 Output formatting: use plain ASCII numbers (\`1.\`, \`2.\`, \`3.\`) for any lists. Never use Unicode circled digits (①②③). Never use emoji of any kind (no check marks, crosses, warning signs, colored circles, faces, hands, etc.) — use plain words.`;
-export const RECORD_PERSONA = `You are Plasalid's recorder. The user typed one short utterance describing something they want logged — a purchase, a transfer, a balance, a new account, or some combination. Your job is to turn that utterance into the right calls against the local three-layer ledger (hierarchical accounts, merchants, transactions+postings) and then stop.
+export const RECORD_PERSONA = `You are Plasalid ("ปลาสลิด"), currently turning one short user utterance into the right ledger entries. The user typed something they want logged — a purchase, a transfer, a balance, a new account, or some combination. Turn that utterance into the right calls against the local three-layer ledger (hierarchical accounts, merchants, transactions+postings) and then stop.
 
 Mission flow:
 1. Classify the utterance into one of: NEW TRANSACTION (an event happened), BALANCE UPDATE (the user is stating a current balance, not an event), NEW ACCOUNT (the user is seeding an account that doesn't exist yet), MULTI-STEP (e.g. "pay all credit card debt from X" needs one transaction per card).
@@ -135,7 +143,7 @@ Output rules:
 - No tables, no markdown grids, no emoji of any kind. Plain ASCII.
 - Never reference internal ids in your reply text. Use human names. (Tool call arguments are fine to use ids.)
 - If you genuinely cannot proceed (non-interactive mode and clarify is required), reply explaining what's missing.`;
-export const RESOLVE_PERSONA = `You are Plasalid's resolver. The user message hands you EVERY open unknown at once. Your goal is to close every one of them with as few user prompts as possible — automate the obvious cases first; ask only when judgment is genuinely required.
+export const RESOLVE_PERSONA = `You are Plasalid ("ปลาสลิด"), currently working through every open unknown the scanner couldn't resolve. The user message hands you EVERY open unknown at once. Your goal is to close every one of them with as few user prompts as possible — automate the obvious cases first; ask only when judgment is genuinely required.
 
 Inputs you receive:
 - One line per open unknown in the user message: id, kind, transaction/account/file ids, prompt, options.
@@ -144,7 +152,7 @@ Inputs you receive:
 
 The workflow is five steps. Do them in order. Do not skip step 1.
 
-**Step 1 — Survey (no tool calls).** Read the entire unknown list. Build a mental map: which kinds appear, which unknowns share a merchant / descriptor / account pair, which rows a loaded memory rule covers, which kinds you can resolve via heuristic alone. The goal is to know the whole shape before mutating anything.
+**Step 1 — Survey.** Read the entire unknown list. Build a mental map: which kinds appear, which unknowns share a merchant / descriptor / account pair, which rows a loaded memory rule covers, which kinds you can resolve via heuristic alone. The goal is to know the whole shape before mutating anything.
 
 **Step 2 — Apply memory-driven silent resolutions.** For every unknown a loaded memory rule covers (merchant→category, known recurrence identity, "these two accounts are separate", account-purpose fact), apply the implied mutation, then call \`close_unknown\` with the implied answer. Group sibling unknowns under one \`close_unknown\` call via \`related_unknown_ids\` — one call per memory rule, not one per row.
 
@@ -152,7 +160,7 @@ The workflow is five steps. Do them in order. Do not skip step 1.
 - kind=\`duplicate\` — if the two transactions share the same merchant on the same date in the same file, default "Keep both" silently. (The inspector already drops these at source, but if one leaks through, suppress it here.)
 - kind=\`correlation\` — if both sides are already linked to a recurrence, default "Keep separate" silently (recurring transfers aren't duplicates).
 - kind=\`recurrence_candidate\` — if a memory rule names the recurrence (e.g. "Monthly ฿199 on KTC Card → Spotify subscription"), call \`record_recurrence\` with the candidate's transaction_ids and the implied frequency, then \`close_unknown\`.
-- kind=\`uncategorized\` / \`uncategorized_expense\` — if the transaction's merchant already has a default_account_id set, apply that category via \`update_posting\` and \`close_unknown\`. No need to re-ask.
+- kind=\`uncategorized\` / \`uncategorized_expense\` — if the transaction's merchant already has a \`default_account_id\` set, apply that category via \`update_posting\` and \`close_unknown\`. The scanner is forbidden from writing \`default_account_id\` on first sight, so any stored default is a past user answer and is authoritative — re-asking would just annoy the user.
 - kind=\`similar_accounts\` — if the two names differ only in casing/whitespace, that's a high-confidence merge; still group with a single \`ask_user\` (don't auto-merge without confirmation, but ask only once).
 
 In each case, call \`close_unknown\` with the implied answer and \`related_unknown_ids\` if any siblings share that answer.

package/dist/cli/commands/rules.d.ts

@@ -0,0 +1,16 @@
+import type Database from "libsql";
+export interface ForgetMatch {
+    displayId: string;
+    text: string;
+}
+export type ForgetOutcome = {
+    ok: true;
+    matched: ForgetMatch[];
+} | {
+    ok: false;
+    error: string;
+};
+export declare function renderRules(db: Database.Database): string;
+export declare function forgetRules(db: Database.Database, pattern: string): ForgetOutcome;
+export declare function showRules(): void;
+export declare function forgetRule(pattern: string): void;

package/dist/cli/commands/rules.js

@@ -0,0 +1,79 @@
+import chalk from "chalk";
+import { getDb } from "../../db/connection.js";
+import { getMemories, deleteMemory } from "../../ai/memory.js";
+import { listMerchants, clearMerchantDefaultAccount, } from "../../db/queries/merchants.js";
+function collectRules(db) {
+    const out = [];
+    for (const m of getMemories(db)) {
+        out.push({
+            displayId: `mem:${m.id}`,
+            text: m.content,
+            forget: (db) => {
+                deleteMemory(db, m.id);
+            },
+        });
+    }
+    const merchants = listMerchants(db, { withDefaultOnly: true });
+    merchants.forEach((m, i) => {
+        out.push({
+            displayId: `mch:${i + 1}`,
+            text: `${m.canonical_name} → ${m.default_account_id}`,
+            forget: (db) => {
+                clearMerchantDefaultAccount(db, m.id);
+            },
+        });
+    });
+    return out;
+}
+export function renderRules(db) {
+    const rules = collectRules(db);
+    if (rules.length === 0) {
+        return ("No rules yet.\n\n" +
+            chalk.dim("Rules accumulate as you resolve unknowns. Run `plasalid resolve` after a scan."));
+    }
+    const width = Math.max(...rules.map((r) => r.displayId.length));
+    const lines = [chalk.bold(`Rules (${rules.length}):`)];
+    for (const r of rules) {
+        lines.push(`  ${chalk.cyan(r.displayId.padEnd(width))}  ${r.text}`);
+    }
+    lines.push("");
+    lines.push(chalk.dim("To remove: plasalid forget <regex>"));
+    return lines.join("\n");
+}
+export function forgetRules(db, pattern) {
+    let re;
+    try {
+        re = new RegExp(`^${pattern}$`);
+    }
+    catch (err) {
+        return { ok: false, error: `Invalid regex /${pattern}/: ${err.message}` };
+    }
+    const snapshot = collectRules(db);
+    const hits = snapshot.filter((r) => re.test(r.displayId));
+    if (!hits.length) {
+        return {
+            ok: false,
+            error: `No rule matches /${pattern}/. Run \`plasalid rules\` to list ids.`,
+        };
+    }
+    const matched = hits.map((r) => {
+        r.forget(db);
+        return { displayId: r.displayId, text: r.text };
+    });
+    return { ok: true, matched };
+}
+export function showRules() {
+    console.log(renderRules(getDb()));
+}
+export function forgetRule(pattern) {
+    const outcome = forgetRules(getDb(), pattern);
+    if (!outcome.ok) {
+        console.error(chalk.red(outcome.error));
+        process.exitCode = 1;
+        return;
+    }
+    const width = Math.max(...outcome.matched.map((m) => m.displayId.length));
+    for (const m of outcome.matched) {
+        console.log(`Forgot ${chalk.cyan(m.displayId.padEnd(width))}  ${m.text}`);
+    }
+}

package/dist/cli/index.js

@@ -131,6 +131,22 @@ program
         kind: opts.kind,
     });
 });
+program
+    .command("rules")
+    .description("List rules the system has learned")
+    .action(async () => {
+    ensureConfigured();
+    const { showRules } = await import("./commands/rules.js");
+    showRules();
+});
+program
+    .command("forget <regex>")
+    .description("Delete every learned rule whose id matches <regex> (anchored). Run `plasalid rules` to list ids.")
+    .action(async (regex) => {
+    ensureConfigured();
+    const { forgetRule } = await import("./commands/rules.js");
+    forgetRule(regex);
+});
 program
     .command("revert <regex>")
     .description("Delete scanned files matching <regex> and all their transactions")
@@ -167,6 +183,14 @@ program.configureHelp({
             name: "resolve",
             desc: "Walk open unknowns one at a time and apply your decision",
         },
+        {
+            name: "rules",
+            desc: "List rules the system has learned",
+        },
+        {
+            name: "forget",
+            desc: "Delete learned rules whose ids match <regex> (anchored)",
+        },
         {
             name: "revert",
             desc: "Delete scanned files matching <regex> and their transactions",

package/dist/db/queries/merchants.d.ts

@@ -40,3 +40,6 @@ export declare function setMerchantDefaultAccount(db: Database.Database, merchan
     before: string | null;
     after: string;
 };
+export declare function clearMerchantDefaultAccount(db: Database.Database, merchantId: string): {
+    before: string | null;
+} | null;

package/dist/db/queries/merchants.js

@@ -118,3 +118,12 @@ export function setMerchantDefaultAccount(db, merchantId, accountId) {
         .run(accountId, merchantId);
     return { before: before.default_account_id, after: accountId };
 }
+export function clearMerchantDefaultAccount(db, merchantId) {
+    const row = db
+        .prepare(`SELECT default_account_id FROM merchants WHERE id = ?`)
+        .get(merchantId);
+    if (!row)
+        return null;
+    db.prepare(`UPDATE merchants SET default_account_id = NULL WHERE id = ?`).run(merchantId);
+    return { before: row.default_account_id };
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "plasalid",
-  "version": "0.6.2",
+  "version": "0.6.6",
   "description": "Plasalid — The Harness Layer for Personal Finance",
   "keywords": [
     "finance",