plasalid 0.5.7 → 0.6.0

package/README.md

@@ -19,21 +19,21 @@ In markets like Thailand there's no Plaid: no public API that gives apps a unifi
 
 ## Features
 
-Plasalid is a chain of three stages: **Scan → Review → Chat.** Underneath sits a three-layer ledger: hierarchical accounts (small, stable, colon-path ids like `expense:food:groceries`), deduplicated merchants (raw statement descriptors collapse to one canonical name with a learned default category), and balanced transactions with postings. Today's chat is one consumer; the same data will power a local MCP / API server next.
+Plasalid is a chain of three stages: **Scan → Resolve → Chat.** Underneath sits a three-layer ledger: hierarchical accounts (small, stable, colon-path ids like `expense:food:groceries`), deduplicated merchants (raw statement descriptors collapse to one canonical name with a learned default category), and balanced transactions with postings. Today's chat is one consumer; the same data will power a local MCP / API server next.
 
 ### Scan — parse without blocking
 
 - **Drop PDFs in, get balanced transactions out.** The scanner infers account type, masks account numbers, converts Buddhist-Era dates, and posts a double-entry record for every transaction.
 - **Merchants as first-class.** Statement descriptors (`STARBUCKS #1234 BKK`, `Starbucks #5678 BANGKOK`) normalize to one canonical merchant. Categorize a merchant once; future statements use the cached default category — the LLM skips re-categorizing known merchants.
-- **Never pauses to ask you.** Ambiguous rows post best-guess transactions with a structured *concern* attached; lines the scanner can't confidently categorize land in `expense:uncategorized` for the review cleanup pass; unparseable rows are skipped, not guessed. A missing row is better than a wrong row — review clears them up later.
+- **Never pauses to ask you.** Ambiguous rows post best-guess transactions with a structured *unknown* attached; lines the scanner can't confidently categorize land in `expense:uncategorized` for the resolve cleanup pass; unparseable rows are skipped, not guessed. A missing row is better than a wrong row — resolve clears them up later.
 - **Encrypted PDFs handled inline.** Statement password-protected? Plasalid prompts you once, remembers the password (AES-GCM at rest) under a filename pattern, and unlocks next month's statement silently.
 
-### Review — see the whole picture
+### Resolve — close every open unknown
 
 - **Uncategorized cleanup.** Every posting parked in `expense:uncategorized` shows up here; categorizing one teaches the merchant's default account for next time, so a single answer can resolve dozens of rows across future months.
 - **Connects related transactions.** A transfer that lands on both a bank statement and a credit-card statement is surfaced as one pair; merge on confirmation.
 - **Recurrences as first-class data.** Spotify, salary, rent get their own `recurrences` rows with cadence (weekly / biweekly / monthly / annually) and next-expected dates, linked back to every member transaction. Not a UI category — a structured fact any AI consumer can read.
-- **Step-by-step clarification.** Re-poses every scan-noted concern as one focused question; loops until concerns are clear or you skip them. `--dry-run` previews everything; writes only after you confirm.
+- **Step-by-step clarification.** Re-poses every scan-noted unknown as one focused question; loops until unknowns are clear or you skip them.
 
 ### Chat — ask questions about your data
 
@@ -66,14 +66,14 @@ Then:
 
 1. Run `plasalid open` to pop open your data folder in Finder/Explorer, then drag in any bank or credit-card statement PDF you've got. **One file is enough to start** — Plasalid will already give you useful answers about that account. More files make the picture richer.
 2. Run `plasalid scan` — it parses your PDFs end-to-end without stopping.
-3. Run `plasalid review` to connect related transactions, learn your recurring rhythms, and clear up anything the scanner flagged as a concern.
+3. Run `plasalid resolve` to connect related transactions, learn your recurring rhythms, and clear up anything the scanner flagged as a unknown.
 4. Run `plasalid` to chat with what was scanned.
 
 Other day-to-day commands:
 
 - `plasalid scan <regex>` — only scan files whose path matches the regex.
 - `plasalid scan <regex> --force` — re-scan matching files (replaces prior records).
-- `plasalid review --dry-run` — preview the picture (correlated transactions, recurrences, open concerns) without writing; re-run without `--dry-run` to step through fixes interactively.
+- `plasalid resolve` — walk every open unknown one at a time and apply your decision (categorize, merge duplicates, link recurrences, skip). Filter with `--account`, `--from`, `--to`, or `--kind`.
 - `plasalid revert <regex>` — delete scanned files matching the regex and every transaction derived from them.
 
 ## Commands
@@ -90,7 +90,7 @@ plasalid transactions               # List transactions and their postings (filt
 plasalid record <utterance>         # Add a manual transaction, account, balance, or merchant from a plain-language line
 plasalid scan [regex] [--force]     # Scan new PDFs; --force cascade-deletes prior records before re-scanning
 plasalid revert <regex>             # Delete scanned files matching <regex> and their transactions
-plasalid review [--dry-run]         # Connect related transactions, learn recurring rhythms, resolve open concerns (--account, --from, --to also accepted)
+plasalid resolve                    # Walk every open unknown and apply your decision (--account, --from, --to, --kind also accepted)
 ```
 
 ## How It Works
@@ -109,7 +109,7 @@ plasalid review [--dry-run]         # Connect related transactions, learn recurr
        Claude API (PII-redacted)
                   │
        ┌──────────▼──────────┐
-       │     Encrypted DB    │◀──── plasalid review
+       │     Encrypted DB    │◀──── plasalid resolve
        └──────────┬──────────┘       
                   │                   
                plasalid               
@@ -138,7 +138,7 @@ Plasalid stores everything in `~/.plasalid/`:
   data/                # Drop any PDFs here (subfolders allowed; AI classifies)
 ```
 
-`db.sqlite` holds the three-layer ledger (hierarchical accounts, deduplicated merchants with learned default categories, transactions and postings), scan history, open concerns awaiting review, recurring transactions (Spotify, salary, rent — recognized during review and linked from each member transaction), an action log for record-mode audit, persisted long-term memories, and AES-GCM-encrypted PDF passwords keyed by filename pattern. Everything is wrapped in libsql's AES-256 page encryption.
+`db.sqlite` holds the three-layer ledger (hierarchical accounts, deduplicated merchants with learned default categories, transactions and postings), scan history, open unknowns awaiting resolve, recurring transactions (Spotify, salary, rent — recognized during resolve and linked from each member transaction), an action log for record-mode audit, persisted long-term memories, and AES-GCM-encrypted PDF passwords keyed by filename pattern. Everything is wrapped in libsql's AES-256 page encryption.
 
 ### Environment Variables
 

package/dist/accounts/taxonomy.d.ts

@@ -24,7 +24,7 @@ export declare const SUGGESTED_LIABILITY_SUBTYPES: string[];
 export declare const SUGGESTED_EXPENSE_SUBTYPES: string[];
 export declare const SUGGESTED_INCOME_SUBTYPES: string[];
 /**
- * Stringified Thai taxonomy block for the scan/review system prompts.
+ * Stringified Thai taxonomy block for the scan/resolve system prompts.
  * Lists known Thai institutions and suggested subtypes so the model picks
  * consistent `bank_name` and `subtype` values across statements.
  */

package/dist/accounts/taxonomy.js

@@ -122,7 +122,7 @@ export const ACCOUNT_TYPE_DESCRIPTIONS = {
     liability: "Credit cards, loans, mortgages, money the user owes.",
     income: "Salary, side income, dividends, refunds.",
     expense: "Spending categories (food, transport, utilities, etc.).",
-    equity: "Owner's equity / opening balance equity (for review adjustments).",
+    equity: "Owner's equity / opening balance equity (for ledger adjustments).",
 };
 export const SUGGESTED_ASSET_SUBTYPES = [
     "bank",
@@ -169,7 +169,7 @@ export const SUGGESTED_INCOME_SUBTYPES = [
     "other",
 ];
 /**
- * Stringified Thai taxonomy block for the scan/review system prompts.
+ * Stringified Thai taxonomy block for the scan/resolve system prompts.
  * Lists known Thai institutions and suggested subtypes so the model picks
  * consistent `bank_name` and `subtype` values across statements.
  */

package/dist/ai/agent.d.ts

@@ -1,16 +1,14 @@
 import type Database from "libsql";
-import { type ScanPromptOptions, type ReviewPromptOptions, type RecordPromptOptions } from "./system-prompt.js";
+import { type ScanPromptOptions, type ResolvePromptOptions, type RecordPromptOptions } from "./system-prompt.js";
 import { type AgentExecutionContext } from "./tools/index.js";
 import type { NormalizedMessage } from "./provider.js";
+export { AbortedError } from "./errors.js";
 export type ProgressCallback = (event: {
     phase: "tool" | "responding";
     toolName?: string;
     toolCount: number;
     elapsedMs: number;
 }) => void;
-export declare class AbortedError extends Error {
-    constructor();
-}
 /**
  * Conversational chat used by the Ink TUI. Reuses conversation_history for context
  * continuity, redacts PII on the way out, restores it on the way in for display.
@@ -43,14 +41,15 @@ export declare function runRecordAgent(opts: {
     signal?: AbortSignal;
 }): Promise<string>;
 /**
- * Review-time agent loop. Surveys the existing transactions with the review
- * tool profile (read tools + write/merge/delete primitives + recurrence
- * detection/recording).
+ * Resolve-time agent loop. The pipeline calls this once per open unknown with
+ * that unknown's id/prompt/options in the initial messages. The agent surfaces
+ * the question, applies the user's chosen answer via mutation tools, and
+ * finishes with mark_resolve_done.
  */
-export declare function runReviewAgent(opts: {
+export declare function runResolveAgent(opts: {
     db: Database.Database;
     initialMessages: NormalizedMessage[];
-    prompt: ReviewPromptOptions;
+    prompt: ResolvePromptOptions;
     agentCtx: AgentExecutionContext;
     onProgress?: ProgressCallback;
     signal?: AbortSignal;

package/dist/ai/agent.js

@@ -1,17 +1,13 @@
 import { config } from "../config.js";
-import { buildChatSystemPrompt, buildScanSystemPrompt, buildReviewSystemPrompt, buildRecordSystemPrompt, } from "./system-prompt.js";
+import { buildChatSystemPrompt, buildScanSystemPrompt, buildResolveSystemPrompt, buildRecordSystemPrompt, } from "./system-prompt.js";
 import { getToolDefinitions, executeTool } from "./tools/index.js";
 import { getConversationHistory, saveMessage } from "./memory.js";
 import { redact, unredact } from "./redactor.js";
 import { createProvider } from "./providers/index.js";
+import { AbortedError, ApiAuthError, ApiError, RateLimitError, } from "./errors.js";
+export { AbortedError } from "./errors.js";
 const provider = createProvider();
 const MAX_TOOL_STEPS = 20;
-export class AbortedError extends Error {
-    constructor() {
-        super("aborted");
-        this.name = "AbortedError";
-    }
-}
 async function runAgent({ db, systemPrompt, tools, initialMessages, agentCtx, onProgress, signal, maxToolSteps, }) {
     const messages = [...initialMessages];
     const useThinking = config.thinkingBudget > 0 && provider.supportsThinking;
@@ -102,17 +98,21 @@ export async function handleChatMessage(db, userMessage, onProgress, signal) {
         return text || "I couldn't formulate a response. Could you rephrase?";
     }
     catch (error) {
-        if (error instanceof AbortedError || error?.name === "AbortError" || signal?.aborted) {
+        if (error instanceof AbortedError)
+            throw error;
+        if (signal?.aborted)
             throw new AbortedError();
-        }
-        if (error.status === 401 || error.status === 403) {
+        if (error instanceof ApiAuthError) {
             return "API key was rejected. Run `plasalid setup` to reconfigure your credentials.";
         }
-        if (error.status === 429) {
+        if (error instanceof RateLimitError) {
             return "Rate limited. Wait a moment and try again.";
         }
-        const safeMessage = error.status ? `API error (${error.status}): ${error.message || ""}` : error.message || "internal error";
-        console.error("AI error:", safeMessage);
+        if (error instanceof ApiError) {
+            console.error("AI error:", `API error (${error.status ?? "?"}): ${error.message}`);
+            return "Sorry, I had trouble processing that. Could you try again?";
+        }
+        console.error("AI error:", error.message || "internal error");
         return "Sorry, I had trouble processing that. Could you try again?";
     }
 }
@@ -155,21 +155,22 @@ export async function runRecordAgent(opts) {
     return text;
 }
 /**
- * Review-time agent loop. Surveys the existing transactions with the review
- * tool profile (read tools + write/merge/delete primitives + recurrence
- * detection/recording).
+ * Resolve-time agent loop. The pipeline calls this once per open unknown with
+ * that unknown's id/prompt/options in the initial messages. The agent surfaces
+ * the question, applies the user's chosen answer via mutation tools, and
+ * finishes with mark_resolve_done.
  */
-export async function runReviewAgent(opts) {
-    const systemPrompt = redact(buildReviewSystemPrompt(opts.db, opts.prompt));
+export async function runResolveAgent(opts) {
+    const systemPrompt = redact(buildResolveSystemPrompt(opts.db, opts.prompt));
     const { text } = await runAgent({
         db: opts.db,
         systemPrompt,
-        tools: getToolDefinitions("review"),
+        tools: getToolDefinitions("resolve"),
         initialMessages: opts.initialMessages,
         agentCtx: opts.agentCtx,
         onProgress: opts.onProgress,
         signal: opts.signal,
-        maxToolSteps: 60,
+        maxToolSteps: 30,
     });
     return text;
 }

package/dist/ai/errors.d.ts

@@ -0,0 +1,16 @@
+export declare class AbortedError extends Error {
+    constructor();
+}
+export declare class ApiAuthError extends Error {
+    readonly status: number;
+    constructor(status: number);
+}
+export declare class RateLimitError extends Error {
+    readonly status = 429;
+    constructor();
+}
+export declare class ApiError extends Error {
+    readonly status: number | undefined;
+    constructor(status: number | undefined, message: string);
+}
+export declare function classifyProviderError(err: unknown, signal?: AbortSignal): never;

package/dist/ai/errors.js

@@ -0,0 +1,47 @@
+export class AbortedError extends Error {
+    constructor() {
+        super("aborted");
+        this.name = "AbortedError";
+    }
+}
+export class ApiAuthError extends Error {
+    status;
+    constructor(status) {
+        super(`auth ${status}`);
+        this.status = status;
+        this.name = "ApiAuthError";
+    }
+}
+export class RateLimitError extends Error {
+    status = 429;
+    constructor() {
+        super("rate limited");
+        this.name = "RateLimitError";
+    }
+}
+export class ApiError extends Error {
+    status;
+    constructor(status, message) {
+        super(message);
+        this.status = status;
+        this.name = "ApiError";
+    }
+}
+export function classifyProviderError(err, signal) {
+    if (err instanceof AbortedError ||
+        err instanceof ApiAuthError ||
+        err instanceof RateLimitError ||
+        err instanceof ApiError) {
+        throw err;
+    }
+    const e = (err ?? {});
+    if (signal?.aborted || e.name === "AbortError")
+        throw new AbortedError();
+    if (e.status === 401 || e.status === 403)
+        throw new ApiAuthError(e.status);
+    if (e.status === 429)
+        throw new RateLimitError();
+    if (typeof e.status === "number")
+        throw new ApiError(e.status, e.message ?? "");
+    throw new ApiError(undefined, e.message ?? "internal error");
+}

package/dist/ai/personas.d.ts

@@ -8,4 +8,4 @@
 export declare function chatPersona(name: string): string;
 export declare const SCAN_PERSONA: string;
 export declare const RECORD_PERSONA: string;
-export declare const REVIEW_PERSONA: string;
+export declare const RESOLVE_PERSONA: string;

package/dist/ai/personas.js

@@ -51,21 +51,21 @@ Rules:
    - \`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.
-   Also set \`raw_descriptor\` on the transaction to the exact statement line for downstream review.
+   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_concern\` with \`kind="uncategorized_expense"\` and the just-posted transaction_id. Do **not** invent a category. The reviewer batches these into one cleanup pass and learns the merchant's default from your fix.
+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.
 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.
 11. If the document reveals an account that doesn't exist yet, call \`create_account\` once before posting transactions to it. Reuse existing accounts; don't create duplicates — call \`list_accounts\` first.
 12. Persist account metadata when the document carries it: bank name, masked number, statement day, due day, points balance.
 13. **Never pause for the user.** Your only job is to parse this document as accurately as possible.
-    - If a row is ambiguous (unclear category, unclear sign, suspicious total), still post your best-guess \`record_transaction\`, then call \`note_concern\` with the row's date, amount (฿N,NNN.NN), description, and exactly what you're unsure about. Pass the just-posted \`transaction_id\` so review can find it.
-    - If a row is *unparseable* (amount unreadable, date missing entirely, can't tell what account is involved), **skip the row entirely** — do not call \`record_transaction\` with placeholder values. Call \`note_concern\` with the raw row text and no \`transaction_id\`. A missing row is better than a wrong row.
-    - If you have a concern about an **account itself** — the statement's bank name disagrees with the stored account, the currency disagrees, the statement_day/due_day on the statement conflicts with what's stored, or you suspect the account you're about to \`create_account\` duplicates an existing one but can't be sure — call \`note_concern\` with \`account_id\` set. You can combine \`account_id\` and \`transaction_id\` if a single row triggered the doubt.
-    - The reviewer will resolve concerns later with the full picture across statements.
-    - **Apply what you've already been told.** Before flagging a concern, scan the "Rules you've already learned" section below. If a saved rule classifies the row — a merchant→category mapping, an account identity, a recurring-charge identity — apply it silently and do **not** raise a concern. Only flag a concern when the row genuinely doesn't fit any saved rule. Asking the user about something they've already told us is bad UX.
+    - If a row is ambiguous (unclear category, unclear sign, suspicious total), still post your best-guess \`record_transaction\`, then call \`note_unknown\` with the row's date, amount (฿N,NNN.NN), description, and exactly what you're unsure about. Pass the just-posted \`transaction_id\` so the resolver can find it.
+    - If a row is *unparseable* (amount unreadable, date missing entirely, can't tell what account is involved), **skip the row entirely** — do not call \`record_transaction\` with placeholder values. Call \`note_unknown\` with the raw row text and no \`transaction_id\`. A missing row is better than a wrong row.
+    - If you have a unknown about an **account itself** — the statement's bank name disagrees with the stored account, the currency disagrees, the statement_day/due_day on the statement conflicts with what's stored, or you suspect the account you're about to \`create_account\` duplicates an existing one but can't be sure — call \`note_unknown\` with \`account_id\` set. You can combine \`account_id\` and \`transaction_id\` if a single row triggered the doubt.
+    - The resolver will work through unknowns later with the full picture across statements.
+    - **Apply what you've already been told.** Before flagging a unknown, scan the "Rules you've already learned" section below. If a saved rule classifies the row — a merchant→category mapping, an account identity, a recurring-charge identity — apply it silently and do **not** raise a unknown. Only flag a unknown when the row genuinely doesn't fit any saved rule. Asking the user about something they've already told us is bad UX.
 14. When the file is fully processed, call \`mark_file_scanned\` with a short summary.
 
 Common Thai statement patterns to expect:
@@ -74,9 +74,9 @@ Common Thai statement patterns to expect:
 - Payslips list gross salary, tax, social-security, and net pay.
 - Transfer slips (PromptPay / mobile banking) show source account, destination account, amount, and a reference number.
 
-How to phrase note_concern:
-- Write a complete sentence with enough context for a later reviewer who doesn't have the PDF open: include the date, the amount (formatted as ฿N,NNN.NN), and the row's description.
-- Never reference accounts or transactions by internal id (\`asset:…\`, \`tx:…\`) in the prompt text. Use the human account name (e.g. "KBank Savings ••8745"). The structured \`transaction_id\` and \`account_id\` arguments are fine — those are for the reviewer to join on.
+How to phrase note_unknown:
+- Write a complete sentence with enough context for a later resolver who doesn't have the PDF open: include the date, the amount (formatted as ฿N,NNN.NN), and the row's description.
+- Never reference accounts or transactions by internal id (\`asset:…\`, \`tx:…\`) in the prompt text. Use the human account name (e.g. "KBank Savings ••8745"). The structured \`transaction_id\` and \`account_id\` arguments are fine — those are for the resolver to join on.
 - 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.`;
@@ -105,7 +105,9 @@ Action dispatch:
 - REFUND ("got refund X to <account>" or "refund X from <merchant>"): DR <account>; for the credit side, prefer reversing the related expense category if one is obvious from the utterance or saved memory, otherwise CR income:refunds (auto-create on demand with parent_id=\`income\`). Attach the merchant block when the merchant is named. Never use adjust_account_balance for a refund — money moved.
 - MULTI-ITEM single receipt ("lunch 200, drinks 100 from cash") → ONE \`record_transaction\` with one debit posting per item (each posting carries its own memo) and one credit posting totalling the sum. Don't split into separate transactions unless items are on different days or use different funding accounts.
 - BALANCE update ("set / update / now has / is now / networth of / portfolio is X") → adjust_account_balance with target_balance = the stated amount. The tool reads the current balance and posts the delta against equity:adjustments.
-- METADATA update ("set my KTC due day to 20", "statement day 28", "rename ...") → update_account_metadata. No money moved; no transaction.
+- METADATA update ("set my KTC due day to 20", "statement day 28", "change masked number") → update_account_metadata. No money moved; no transaction.
+- RENAME ("rename SCB to Bangkok Bank") → resolve the account via find_similar_accounts, then rename_account.
+- DELETE ("delete my old empty cash account", "remove asset:old-savings") → resolve the account via find_similar_accounts, then delete_account. delete_account refuses if the account still has postings — tell the user to merge or recategorize first.
 - ACCOUNT-ONLY create ("create a new investment at Diem", "open a savings at SCB") → resolve any duplicate via find_similar_accounts first, then create_account. No transaction, no balance.
 - MERCHANT teaching ("Starbucks is Dining", "mark Lazada as Shopping") → find_or_create_merchant with the canonical name and default_account_id. No transaction.
 - "Pay all <category>" (e.g. "pay all credit card debt from X"): list_accounts filtered by type, get_account_balance for each, build the plan, call clarify with a one-line summary ("Settle 3 cards totaling ฿38,500 from SCB Savings — proceed?") before any record_transaction. Then post one transaction per liability.
@@ -133,61 +135,62 @@ 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 REVIEW_PERSONA = `You are Plasalid's reviewer. The scanner has already parsed every statement and posted its best-guess transactions. Your job is to look at the whole picture — open concerns, correlated transactions, recurring patterns, account hygiene, merchant categorization — and walk the user through clarifying anything that's still ambiguous.
-
-Hard rules:
-1. **Survey deeply, then group, then ask.** Before *any* call to ask_user, you must have:
-   1. Pulled the full list with list_open_concerns. Separate uncategorized-expense concerns (kind='uncategorized_expense') from the rest — these batch easily.
-   2. Cross-referenced with find_duplicate_transactions, find_correlated_transactions, find_recurrences, find_similar_accounts, find_unused_accounts to surface higher-order patterns.
-   3. Read every rule in the "Rules you've already learned" section below and silently resolved every concern they cover (apply the change, then resolve_concerns / merge / update; no user prompt needed).
-   4. **Grouped** what remains: concerns that share the same answer (10 Lazada rows that all categorize Shopping, 4 transfer-pair duplicates between the same two accounts, 3 Netflix-looking monthly charges) belong in *one* question, not N. The user's time is the most expensive resource in this loop.
-2. **Prioritize.** Work in this order:
-   (a) **Uncategorized cleanup** — postings parked in \`expense:uncategorized\` await a real category. Resolving one should also call \`set_merchant_default_account\` when the transaction has a merchant_id, so future statements of the same merchant skip the categorizer.
-   (b) other open concerns from scan — the user is already on record as uncertain about these.
-   (c) correlated transactions — merging duplicate transfers across two statements cleans up multiple files at once.
-   (d) recurrences — recording a recurring series enriches the picture for the chat agent.
-   (e) chart-of-accounts hygiene (similar/unused accounts).
-3. **Ask once, resolve many.** When you have grouped sibling concerns (same merchant, same correlated-transfer pair, same recurrence candidate, same account-rename), call ask_user ONCE with the representative question. Pass *all* the sibling concern ids in \`related_concern_ids\` so a single answer marks the entire group resolved in one shot. Re-survey only if the change invalidated other candidates; otherwise move directly to the next item.
-4. **Loop until concerns are clear.** Done means \`SELECT COUNT(*) FROM concerns WHERE resolved_at IS NULL = 0\`. If the user repeatedly chooses "Skip — leave as is", honor it and proceed; deferred-but-acknowledged is fine. Then call mark_review_done.
-5. **Conservative defaults.** When uncertain, save_memory and skip. Never delete without explicit user confirmation. If dry-run is enabled, write tools return "Would ..." messages — relay those to the user without further action.
-6. **Bookkeeping rules still apply.** record_transaction must balance. For amount fixes, delete the broken transaction and record a fresh replacement.
-7. **Learn from every answer.** Every time ask_user resolves with a non-skip answer that implies a generalizable rule, immediately call save_memory with a reusable phrasing of the rule (see "How to remember what the user taught you" below). For merchant categorization specifically, also call set_merchant_default_account so the cache is updated for the next scan.
-
-How to phrase ask_user:
-- Keep \`prompt\` to a single sentence focused on the decision. Don't restate the amount, date, merchant, or account names in prose — the prompter renders those for you as a colored header above the question (see \`facts\` below).
-- Never reference transactions, accounts, or recurrences by their internal id (\`tx:…\`, \`asset:…\`, \`rc:…\`) in the question text. (The structured \`concern_id\` / \`related_concern_ids\` / \`transaction_id\` / \`account_id\` arguments are fine — those are for plumbing.)
-- Always include "Skip — leave as is" as one of the options so the user has an explicit do-nothing path.
-- **Pass the key facts as \`facts\`.** Every transactional \`ask_user\` should populate whichever of these apply:
-  - \`facts.amount\` — ฿-formatted, e.g. \`"฿1,200.00"\`.
-  - \`facts.date\` — ISO \`YYYY-MM-DD\` or a compact range like \`"2026-02-15 to 2026-04-15"\` for recurrences and grouped categorizations.
-  - \`facts.merchant\` — the human counterparty (e.g. \`"LAZADA TH"\`, \`"Spotify"\`) when one applies.
-  - \`facts.accounts\` — human account names involved (e.g. \`["KBank Savings ••8745", "KTC Card ••5678"]\`). For merges, list the survivor first.
-  The prompter renders these on one colored line (amount yellow, date cyan, merchant green, accounts magenta). Skip a field when it doesn't apply; never invent values to fill it.
-- Examples:
-  - Uncategorized cleanup: \`prompt: "Categorize all 12 as Shopping?", facts: { amount: "฿500", date: "2026-02 to 2026-04", merchant: "LAZADA TH", accounts: ["KTC Card ••5678"] }, related_concern_ids: [...], options: ["Yes — all Shopping", "No — ask me one at a time", "Skip — leave as is"]\`
-  - Duplicate transfer: \`prompt: "Same transfer recorded twice. Merge?", facts: { amount: "฿1,200", date: "2026-04-15", accounts: ["KBank Savings ••8745", "KTC Card ••5678"] }, options: ["Yes — keep the KBank side, delete the KTC side", "Yes — keep the KTC side, delete the KBank side", "No — these are two real events", "Skip — leave as is"]\`
-  - Recurrence proposal: \`prompt: "Looks monthly. Record as a recurrence?", facts: { amount: "฿199", date: "2026-02-15 to 2026-05-15", merchant: "Spotify", accounts: ["KTC Card ••5678"] }, options: ["Yes — Spotify", "Yes — name it later", "No — not recurring", "Skip — leave as is"]\`
-
-How to remember what the user taught you (save_memory):
-- After every non-skip ask_user answer that implies a generalizable rule, immediately call \`save_memory(content=<rule>, category="scanning_hint")\`. The "scanning_hint" category flows back into the next scan automatically.
-- Phrase rules as reusable classifications, not records of one event:
-  - GOOD: \`"Lazada Thailand transactions on KTC Card ••5678 go to expense:shopping."\`
-  - GOOD: \`"Monthly ฿199 charges on KTC Card ••5678 are Spotify subscription."\`
-  - GOOD: \`"Account asset:bbl-savings-1234 is the joint account with my wife."\`
-  - BAD: \`"On 2026-03-15 the user said the ฿500 Lazada charge was Shopping."\` (too specific; won't apply to next month's Lazada row.)
-- Don't save a rule that already appears in the loaded memories above — duplicates are noise.
-- Skip the save when the user picked "Skip — leave as is" — nothing to learn from a deferral.
-
-How to write the mark_review_done summary:
-- Plain language, user-facing. Lead with what was applied; tail with what was skipped or deferred.
-- Include counts: merges, recurrences recorded, edits, deletes, skipped concerns, merchants taught.
-- Never reference internal detector names (\`find_duplicate_transactions\`, \`find_recurrences\`, "Group 1", "candidate N") — those are tool internals.
-- One to three sentences. Examples:
-  - "Categorized 12 Lazada postings as Shopping and taught the merchant default. Merged 3 duplicate transfers and recorded 2 monthly recurrences (Spotify, Netflix). 1 concern deferred."
-  - "No duplicates or recurrences found. Cleared 4 concerns from the last scan."
+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.
+
+Inputs you receive:
+- One line per open unknown in the user message: id, kind, transaction/account/file ids, prompt, options.
+- The "Rules you've already learned" section in the system prompt — authoritative; apply silently.
+- The current chart of accounts + balances in the system prompt.
+
+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 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.
+
+**Step 3 — Apply per-kind heuristic defaults.** For unknowns not covered by memory, apply automatically when the heuristic is high-confidence:
+- 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=\`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.
+
+**Step 4 — Group remaining unknowns, then ask ONCE per group.** Whatever survives steps 2-3 needs the user. Group by shared answer:
+- All \`uncategorized\` / \`uncategorized_expense\` unknowns on the same merchant or \`raw_descriptor\` → one group.
+- All \`duplicate\` unknowns sharing the same pair of source files → one group.
+- All \`correlation\` unknowns between the same pair of accounts → one group.
+- All \`recurrence_candidate\` unknowns on the same account + amount → one group.
+- All \`similar_accounts\` unknowns on the same account pair → one group (usually one row already).
+
+For each group, call \`ask_user\` ONCE, passing every sibling's id in \`related_unknown_ids\`. Include "Skip — leave as is" as the last option. After the user answers, apply the mutation(s) the answer implies for every member of the group.
+
+**Step 5 — Learn and finalize.** After every non-skip user answer that implies a generalizable rule (e.g. "Lazada on KTC Card → Shopping"), call \`save_memory(content=<rule>, category="scanning_hint")\` so the next scan applies it silently. For merchant categorization, also call \`set_merchant_default_account\`. Phrase rules as reusable classifications, not one-event records (GOOD: "Lazada Thailand on KTC Card ••5678 → expense:shopping." BAD: "On 2026-03-15 the user said Shopping.").
+
+**Closing invariant.** Every unknown in the input list must have \`resolved_at\` set by the end. If anything is still open after step 4, close it with \`close_unknown(answer="Skip — could not interpret")\`.
+
+End with one \`mark_resolve_done\` call. Summary format: a single sentence with counts. Examples:
+- "Applied 9 from memory; resolved 2 groups (5 unknowns) by user answer; deferred 1 via Skip."
+- "All 14 unknowns applied silently from memory rules."
+- "Resolved 1 group (3 Lazada postings) as Shopping; saved the merchant default."
+
+Unknown kind → mutation tool map (use after a user answer in step 4):
+- \`uncategorized\` / \`uncategorized_expense\` → \`update_posting(account_id=...)\` for each posting on the transaction. If the transaction has a merchant_id, also \`set_merchant_default_account\`.
+- \`duplicate\` → "Delete this one" → \`delete_transaction\` on the unknown's transaction_id. "Delete the older one" → identify the older tx from the prompt body, then \`delete_transaction\`. "Keep both" / "Skip" → no mutation.
+- \`correlation\` → "Merge into one transaction" → \`delete_transaction\` on one side and \`update_posting\` on the other so it reflects the cross-account movement. "Keep separate" / "Skip" → no mutation.
+- \`recurrence_candidate\` → "Link as recurring" → \`record_recurrence\` with the candidate's transaction_ids and the implied frequency. "Not recurring" / "Skip" → no mutation.
+- \`similar_accounts\` → "Merge A into B" / "Merge B into A" → \`merge_accounts(from_id, to_id)\`. "Keep separate" / "Skip" → no mutation.
+
+How to phrase \`ask_user\`:
+- Use the unknown's \`prompt\` verbatim (or a tightened version when grouping). Don't restate amounts/dates/accounts in prose — that's what \`facts\` is for.
+- Pass the unknown's existing \`options\` verbatim. Don't invent options.
+- Always pass the primary unknown's id as \`unknown_id\` and the siblings as \`related_unknown_ids\`.
+- Populate \`facts\` whenever the unknown mentions an amount, date, merchant, or accounts (amount=yellow, date=cyan, merchant=green, accounts=magenta).
+- Never reference internal ids (\`tx:…\`, \`asset:…\`, \`rc:…\`, \`cn:…\`) in the prompt text.
 
 Output formatting:
-- Use plain ASCII numbers (\`1.\`, \`2.\`, \`3.\`) for any lists or option numbering you generate. 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.
+- Use plain ASCII numbers (\`1.\`, \`2.\`, \`3.\`) for any lists. Never use Unicode circled digits.
+- Never use emoji of any kind — use plain words.
 - Always reply in English.
-- Be brief in prose; the user is reviewing in real time and wants to confirm fast.`;
+- Be terse; the user wants the final summary, not narration.`;

package/dist/ai/prompt-sections.d.ts

@@ -12,13 +12,13 @@ import type Database from "libsql";
 /** Date headers */
 /** Long-form date for chat ("Today is Friday, March 5, 2026."). */
 export declare function renderTodayHuman(): string;
-/** ISO date for scan/review ("Today is 2026-03-05."). */
+/** ISO date for scan/resolve ("Today is 2026-03-05."). */
 export declare function renderTodayIso(): string;
 /** Chart of accounts */
 export interface ChartOfAccountsOptions {
     withBalance: boolean;
-    /** Empty-state copy. `scan` hints at creating accounts; `review` is terse. */
-    emptyState: "scan" | "review";
+    /** Empty-state copy. `scan` hints at creating accounts; `resolve` is terse. */
+    emptyState: "scan" | "resolve";
 }
 export declare function renderChartOfAccounts(db: Database.Database, opts: ChartOfAccountsOptions): string;
 /**
@@ -37,12 +37,11 @@ export interface MemoriesOptions {
     showCategory: boolean;
 }
 export declare function renderMemories(db: Database.Database, opts: MemoriesOptions): string | null;
-/** Review scope */
+/** Resolve scope */
 export interface ScopeOptions {
     accountId?: string;
     from?: string;
     to?: string;
-    dryRun: boolean;
 }
 export declare function renderScope(opts: ScopeOptions): string;
 /** Chat user context */