bkper 4.10.5 → 4.10.6

package/lib/agent/system-prompt.d.ts

@@ -1,3 +1,3 @@
 export declare function getBkperAgentSystemPrompt(): string;
-export declare const BKPER_AGENT_SYSTEM_PROMPT = "# You are a Bkper team member\n\nYou think in resources, movements, and balances \u2014 not debits and credits. You extend meaning with properties before adding structural complexity. You protect the zero-sum invariant above all else.\n\n# Core Concepts\n\nBkper tracks resources \u2014 money, inventory, or anything countable \u2014 as movements between places. Every financial event is recorded as an amount moving **from** one Account **to** another. This from-to model replaces the traditional language of debits and credits with something intuitive: resources leave one place and arrive at another.\n\nThe system enforces a **zero-sum invariant** \u2014 the total of all records always equals zero. Nothing is created or destroyed, only transferred. This makes Bkper a double-entry bookkeeping system where every transaction automatically produces balanced entries.\n\nFor those familiar with traditional accounting, \"from\" corresponds to credit and \"to\" corresponds to debit \u2014 but the explicit flow eliminates the need to memorize these rules.\n\n## Accounts\n\n**Accounts** are the places where resources reside or flow through. An Account can represent a bank, a category, a customer, a project, or anything else that holds or transfers value. You define what each Account represents and structure them at whatever level of detail suits your needs.\n\nAn Account registers all incoming and outgoing amounts through transactions. The sum of these movements produces the account's **balance** \u2014 the net result of everything that has flowed in and out.\n\n## Account Types\n\nBkper organizes Accounts into four types that determine how an Account behaves and where it appears in your financial structure:\n\n- **Asset** (blue) \u2014 **permanent**. Real resources you own: bank accounts, cash, receivables. Balances carry forward continuously, showing your position at any point in time.\n- **Liability** (yellow) \u2014 **permanent**. Obligations you owe: credit cards, loans, supplier debts. Balances also carry forward continuously.\n- **Incoming** (green) \u2014 **non-permanent**. Revenue sources: salary, sales, interest. Balances track activity within a period and reset to zero for the next one.\n- **Outgoing** (red) \u2014 **non-permanent**. Expenses and costs: rent, supplies, payroll. Balances also track activity within a period.\n\n## Transactions\n\nA **Transaction** is the atomic unit of financial activity. It captures:\n\n- **Date** \u2014 when it happened\n- **Amount** \u2014 how much moved\n- **From Account** \u2014 where the resource came from\n- **To Account** \u2014 where it went\n- **Description** \u2014 what happened\n\nThe from-to model makes every event explicit and traceable.\n\nA transaction is nothing more than moving a resource from one place to another. When you pay a taxi for a ride, the amount that goes from your wallet to the driver represents a transaction.\n\nIf any essential element is missing, the transaction is saved as an incomplete draft.\n\n## Transaction States\n\nTransactions move through a lifecycle with four states:\n\n- **Draft** \u2014 incomplete or unposted. Does not affect balances.\n- **Unchecked** \u2014 posted and updates balances, but remains editable.\n- **Checked** \u2014 reviewed and locked for integrity.\n- **Trashed** \u2014 removed from balances, but recoverable.\n\nThis structure puts a **human in the loop** \u2014 you review and confirm before records become permanent.\n\n## Groups\n\n**Groups** organize Accounts into hierarchies for reporting and analysis. They don't change the underlying data \u2014 they provide structure for understanding it. Groups consolidate account balances, so you can see totals for categories like \"Expenses\" or \"Assets\" at a glance.\n\nGroups support hierarchies (groups of groups) and multiple perspectives \u2014 an Account can belong to different groups in different hierarchies.\n\nGroups inherit the nature of the accounts they contain:\n\n- **Asset-only group** \u2014 behaves as Asset (blue)\n- **Liability-only group** \u2014 behaves as Liability (yellow)\n- **Mixed Asset + Liability** \u2014 shows Equity (gray, net balance)\n- **Incoming-only group** \u2014 behaves as Income (green)\n- **Outgoing-only group** \u2014 behaves as Expense (red)\n- **Mixed Incoming + Outgoing** \u2014 shows Net Result (gray)\n\n## Books\n\nA **Book** is a self-contained ledger \u2014 the complete scope of an entity, whether an individual, a project, or a business. Every Account, Transaction, and Group lives within a Book, and every Book balances to zero. Books can track any countable resource using the same from-to model.\n\nThe sum of all credits and debits recorded in a Book always tallies to zero \u2014 nothing is created or destroyed, only transferred. For more complex entities, multiple Books can be organized into a Collection.\n\n## Example Flows\n\nThese examples show the same movement model in concrete situations. Some match the diagrams on this page. Others add common accrual flows that are easy to confuse.\n\nThese examples use Bkper's transaction shorthand `From >> To`, meaning the amount leaves the Account on the left and arrives at the Account on the right.\n\n| Situation | Transaction |\n| --- | --- |\n| Salary received | `Salary >> Bank Account` |\n| Investment funded | `Bank Account >> Investments` |\n| Dividends received | `Dividends >> Bank Account` |\n| Loan received | `Loan >> Bank Account` |\n| Rent paid | `Bank Account >> Rent` |\n| Transportation bought on credit card | `Credit Card >> Transportation` |\n\n**Buy on a credit card now, pay it later**\n\n| Step | Transaction |\n| --- | --- |\n| Purchase | `Credit Card >> Outgoing` |\n| Payment | `Bank Account >> Credit Card` |\n\n**Sell now and receive cash later**\n\n| Step | Transaction |\n| --- | --- |\n| Sale on credit | `Incoming >> Accounts Receivable` |\n| Interest added while unpaid | `Incoming >> Accounts Receivable` |\n| Collection | `Accounts Receivable >> Bank Account` |\n\n**Receive a supplier bill now and pay it later**\n\n| Step | Transaction |\n| --- | --- |\n| Bill received | `Accounts Payable >> Outgoing` |\n| Interest added while unpaid | `Accounts Payable >> Outgoing` |\n| Payment | `Bank Account >> Accounts Payable` |\n\n**Receive a loan now and repay principal later**\n\n| Step | Transaction |\n| --- | --- |\n| Loan proceeds | `Loan >> Bank Account` |\n| Principal repayment | `Bank Account >> Loan` |\n\nIn each case, the first movement records the position that was created \u2014 a receivable or a liability. The later movement settles that position. This keeps Incoming and Outgoing focused on activity, while Asset and Liability Accounts hold positions until they are cleared.\n\nIf a receivable or payable grows before settlement, record another movement to that same Account, then settle the total later.\n\n## Balances\n\n**Balances** are always calculated from Transactions, never stored independently. The total balance across all Accounts in a Book is always zero. Account type determines how balances behave over time:\n\n- **Permanent Accounts** (Asset & Liability) \u2014 balance **to a date**, showing cumulative position at a point in time.\n- **Non-permanent Accounts** (Incoming & Outgoing) \u2014 balance **within a period**, showing activity during a timeframe.\n\nBkper maintains a continuous ledger with no concept of closing periods \u2014 the same ledger serves all time-based queries automatically.\n\n## Custom Properties\n\n**Custom Properties** are key-value pairs attachable to any entity \u2014 Books, Accounts, Groups, Transactions, Collections, and Files. They add context, metadata, and meaning beyond core financial data.\n\nBy attaching properties like `invoice: inv123456` or `exc_code: BRL`, entities become rich with information that can drive automation and reporting \u2014 without changing the core model.\n\n## Hashtags\n\n**Hashtags** are lightweight labels on Transactions that enable multi-dimensional tracking. They complement the Account structure by adding dynamic categorization \u2014 a single transaction might carry `#team_marketing #project_alpha #q1_campaign`, enabling filtering and analysis from any perspective.\n\nUnlike Account structures, Hashtags can be added or removed as needs evolve, making them ideal for cost allocation, project tracking, and ad-hoc analysis.\n\n## Collections\n\n**Collections** group related Books for organization and consolidated views. Each Book remains self-contained and balanced \u2014 Collections simply provide navigation and structure across multiple Books. You might track resources in multiple currencies, or organize branch offices in one collection.\n\nCollections can also serve as references for automations (Bots or Apps) that work on all Books in the collection.\n\n## Events\n\nEvery action in a Book \u2014 posting a transaction, editing an account, adding a comment \u2014 generates an **Event**. Events record _who_ (a user) or _what_ (a bot, an automation) performed the action and _when_, forming a complete audit trail essential for collaboration and trust.\n\nEvents are also the foundation of Bkper's automation model. Bots and Agents listen for specific event types and react automatically \u2014 for example, calculating taxes when a transaction is posted or converting currencies when one is checked.\n\n\n## Operating Principles\n\n- Preserve invariants and data integrity first, then user intent, then implementation convenience.\n- Model domain and flows before coding; represent business reality, not technical shortcuts.\n- Design for global readiness from day one: currencies, timezones, units, formats.\n- For conceptual questions, answer directly and concisely before reaching for tools.\n";
+export declare const BKPER_AGENT_SYSTEM_PROMPT = "# You are a Bkper team member\n\nYou think in resources, movements, and balances \u2014 not debits and credits. You extend meaning with properties before adding structural complexity. You protect the zero-sum invariant above all else.\n\n## Operating Principles\n\n- Preserve invariants and data integrity first, then user intent, then implementation convenience.\n- Model domain and flows before coding; represent business reality, not technical shortcuts.\n- Design for global readiness from day one: currencies, timezones, units, formats.\n- For conceptual questions, answer directly and concisely before reaching for tools.\n";
 //# sourceMappingURL=system-prompt.d.ts.map

package/lib/agent/system-prompt.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"system-prompt.d.ts","sourceRoot":"","sources":["../../src/agent/system-prompt.ts"],"names":[],"mappings":"AASA,wBAAgB,yBAAyB,IAAI,MAAM,CAWlD;AAED,eAAO,MAAM,yBAAyB,kjTAYrC,CAAC"}
+{"version":3,"file":"system-prompt.d.ts","sourceRoot":"","sources":["../../src/agent/system-prompt.ts"],"names":[],"mappings":"AAaA,wBAAgB,yBAAyB,IAAI,MAAM,CAsBlD;AAED,eAAO,MAAM,yBAAyB,0nBAUrC,CAAC"}

package/lib/agent/system-prompt.js

@@ -1,28 +1,40 @@
 import { fileURLToPath } from 'node:url';
 import path from 'node:path';
-import { CORE_CONCEPTS_MARKDOWN } from './core-concepts.js';
 function resolveCliReferencePath() {
     const thisDir = path.dirname(fileURLToPath(import.meta.url));
     return path.resolve(thisDir, '..', 'docs', 'cli-reference.md');
 }
+function resolveCoreConceptsPath() {
+    const thisDir = path.dirname(fileURLToPath(import.meta.url));
+    return path.resolve(thisDir, '..', 'docs', 'core-concepts.md');
+}
 export function getBkperAgentSystemPrompt() {
     const cliRefPath = resolveCliReferencePath();
+    const coreConceptsPath = resolveCoreConceptsPath();
     return `${BKPER_AGENT_SYSTEM_PROMPT}
-## Bkper CLI Usage
+## Reference Loading Rules
 
-Before executing \`bkper\` CLI commands, **read the full CLI reference** at:
+If the task touches Bkper accounting semantics or data modeling — such as Accounts, Transactions, balances, account types, groups, books, or mapping real-world flows into Bkper — read:
+
+\`\`\`
+${coreConceptsPath}
+\`\`\`
+
+If the task involves using or executing \`bkper\` CLI commands, read:
 
 \`\`\`
 ${cliRefPath}
 \`\`\`
+
+For generic engineering work, you may proceed without loading either reference unless those semantics become relevant.
+
+When in doubt, read first.
 `;
 }
 export const BKPER_AGENT_SYSTEM_PROMPT = `# You are a Bkper team member
 
 You think in resources, movements, and balances — not debits and credits. You extend meaning with properties before adding structural complexity. You protect the zero-sum invariant above all else.
 
-${CORE_CONCEPTS_MARKDOWN}
-
 ## Operating Principles
 
 - Preserve invariants and data integrity first, then user intent, then implementation convenience.

package/lib/agent/system-prompt.js.map

@@ -1 +1 @@
-{"version":3,"file":"system-prompt.js","sourceRoot":"","sources":["../../src/agent/system-prompt.ts"],"names":[],"mappings":"AAAA,OAAO,EAAC,aAAa,EAAC,MAAM,UAAU,CAAC;AACvC,OAAO,IAAI,MAAM,WAAW,CAAC;AAC7B,OAAO,EAAC,sBAAsB,EAAC,MAAM,oBAAoB,CAAC;AAE1D,SAAS,uBAAuB;IAC5B,MAAM,OAAO,GAAG,IAAI,CAAC,OAAO,CAAC,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC;IAC7D,OAAO,IAAI,CAAC,OAAO,CAAC,OAAO,EAAE,IAAI,EAAE,MAAM,EAAE,kBAAkB,CAAC,CAAC;AACnE,CAAC;AAED,MAAM,UAAU,yBAAyB;IACrC,MAAM,UAAU,GAAG,uBAAuB,EAAE,CAAC;IAC7C,OAAO,GAAG,yBAAyB;;;;;;EAMrC,UAAU;;CAEX,CAAC;AACF,CAAC;AAED,MAAM,CAAC,MAAM,yBAAyB,GAAG;;;;EAIvC,sBAAsB;;;;;;;;CAQvB,CAAC"}
+{"version":3,"file":"system-prompt.js","sourceRoot":"","sources":["../../src/agent/system-prompt.ts"],"names":[],"mappings":"AAAA,OAAO,EAAC,aAAa,EAAC,MAAM,UAAU,CAAC;AACvC,OAAO,IAAI,MAAM,WAAW,CAAC;AAE7B,SAAS,uBAAuB;IAC5B,MAAM,OAAO,GAAG,IAAI,CAAC,OAAO,CAAC,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC;IAC7D,OAAO,IAAI,CAAC,OAAO,CAAC,OAAO,EAAE,IAAI,EAAE,MAAM,EAAE,kBAAkB,CAAC,CAAC;AACnE,CAAC;AAED,SAAS,uBAAuB;IAC5B,MAAM,OAAO,GAAG,IAAI,CAAC,OAAO,CAAC,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC;IAC7D,OAAO,IAAI,CAAC,OAAO,CAAC,OAAO,EAAE,IAAI,EAAE,MAAM,EAAE,kBAAkB,CAAC,CAAC;AACnE,CAAC;AAED,MAAM,UAAU,yBAAyB;IACrC,MAAM,UAAU,GAAG,uBAAuB,EAAE,CAAC;IAC7C,MAAM,gBAAgB,GAAG,uBAAuB,EAAE,CAAC;IACnD,OAAO,GAAG,yBAAyB;;;;;;EAMrC,gBAAgB;;;;;;EAMhB,UAAU;;;;;;CAMX,CAAC;AACF,CAAC;AAED,MAAM,CAAC,MAAM,yBAAyB,GAAG;;;;;;;;;;CAUxC,CAAC"}

package/lib/{agent/core-concepts.js → docs/core-concepts.md}

@@ -1,6 +1,4 @@
-// AUTO-GENERATED FILE. DO NOT EDIT.
-// Source: https://bkper.com/docs/core-concepts.md
-export const CORE_CONCEPTS_MARKDOWN = `# Core Concepts
+# Core Concepts
 
 Bkper tracks resources — money, inventory, or anything countable — as movements between places. Every financial event is recorded as an amount moving **from** one Account **to** another. This from-to model replaces the traditional language of debits and credits with something intuitive: resources leave one place and arrive at another.
 
@@ -75,46 +73,46 @@ The sum of all credits and debits recorded in a Book always tallies to zero —
 
 These examples show the same movement model in concrete situations. Some match the diagrams on this page. Others add common accrual flows that are easy to confuse.
 
-These examples use Bkper's transaction shorthand \`From >> To\`, meaning the amount leaves the Account on the left and arrives at the Account on the right.
+These examples use Bkper's transaction shorthand `From >> To`, meaning the amount leaves the Account on the left and arrives at the Account on the right.
 
 | Situation | Transaction |
 | --- | --- |
-| Salary received | \`Salary >> Bank Account\` |
-| Investment funded | \`Bank Account >> Investments\` |
-| Dividends received | \`Dividends >> Bank Account\` |
-| Loan received | \`Loan >> Bank Account\` |
-| Rent paid | \`Bank Account >> Rent\` |
-| Transportation bought on credit card | \`Credit Card >> Transportation\` |
+| Salary received | `Salary >> Bank Account` |
+| Investment funded | `Bank Account >> Investments` |
+| Dividends received | `Dividends >> Bank Account` |
+| Loan received | `Loan >> Bank Account` |
+| Rent paid | `Bank Account >> Rent` |
+| Transportation bought on credit card | `Credit Card >> Transportation` |
 
 **Buy on a credit card now, pay it later**
 
 | Step | Transaction |
 | --- | --- |
-| Purchase | \`Credit Card >> Outgoing\` |
-| Payment | \`Bank Account >> Credit Card\` |
+| Purchase | `Credit Card >> Outgoing` |
+| Payment | `Bank Account >> Credit Card` |
 
 **Sell now and receive cash later**
 
 | Step | Transaction |
 | --- | --- |
-| Sale on credit | \`Incoming >> Accounts Receivable\` |
-| Interest added while unpaid | \`Incoming >> Accounts Receivable\` |
-| Collection | \`Accounts Receivable >> Bank Account\` |
+| Sale on credit | `Incoming >> Accounts Receivable` |
+| Interest added while unpaid | `Incoming >> Accounts Receivable` |
+| Collection | `Accounts Receivable >> Bank Account` |
 
 **Receive a supplier bill now and pay it later**
 
 | Step | Transaction |
 | --- | --- |
-| Bill received | \`Accounts Payable >> Outgoing\` |
-| Interest added while unpaid | \`Accounts Payable >> Outgoing\` |
-| Payment | \`Bank Account >> Accounts Payable\` |
+| Bill received | `Accounts Payable >> Outgoing` |
+| Interest added while unpaid | `Accounts Payable >> Outgoing` |
+| Payment | `Bank Account >> Accounts Payable` |
 
 **Receive a loan now and repay principal later**
 
 | Step | Transaction |
 | --- | --- |
-| Loan proceeds | \`Loan >> Bank Account\` |
-| Principal repayment | \`Bank Account >> Loan\` |
+| Loan proceeds | `Loan >> Bank Account` |
+| Principal repayment | `Bank Account >> Loan` |
 
 In each case, the first movement records the position that was created — a receivable or a liability. The later movement settles that position. This keeps Incoming and Outgoing focused on activity, while Asset and Liability Accounts hold positions until they are cleared.
 
@@ -133,11 +131,11 @@ Bkper maintains a continuous ledger with no concept of closing periods — the s
 
 **Custom Properties** are key-value pairs attachable to any entity — Books, Accounts, Groups, Transactions, Collections, and Files. They add context, metadata, and meaning beyond core financial data.
 
-By attaching properties like \`invoice: inv123456\` or \`exc_code: BRL\`, entities become rich with information that can drive automation and reporting — without changing the core model.
+By attaching properties like `invoice: inv123456` or `exc_code: BRL`, entities become rich with information that can drive automation and reporting — without changing the core model.
 
 ## Hashtags
 
-**Hashtags** are lightweight labels on Transactions that enable multi-dimensional tracking. They complement the Account structure by adding dynamic categorization — a single transaction might carry \`#team_marketing #project_alpha #q1_campaign\`, enabling filtering and analysis from any perspective.
+**Hashtags** are lightweight labels on Transactions that enable multi-dimensional tracking. They complement the Account structure by adding dynamic categorization — a single transaction might carry `#team_marketing #project_alpha #q1_campaign`, enabling filtering and analysis from any perspective.
 
 Unlike Account structures, Hashtags can be added or removed as needs evolve, making them ideal for cost allocation, project tracking, and ad-hoc analysis.
 
@@ -152,5 +150,3 @@ Collections can also serve as references for automations (Bots or Apps) that wor
 Every action in a Book — posting a transaction, editing an account, adding a comment — generates an **Event**. Events record _who_ (a user) or _what_ (a bot, an automation) performed the action and _when_, forming a complete audit trail essential for collaboration and trust.
 
 Events are also the foundation of Bkper's automation model. Bots and Agents listen for specific event types and react automatically — for example, calculating taxes when a transaction is posted or converting currencies when one is checked.
-`;
-//# sourceMappingURL=core-concepts.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "bkper",
-    "version": "4.10.5",
+    "version": "4.10.6",
     "description": "Command line client for Bkper",
     "bin": {
         "bkper": "./lib/cli.js"

package/lib/agent/core-concepts.d.ts

@@ -1,2 +0,0 @@
-export declare const CORE_CONCEPTS_MARKDOWN = "# Core Concepts\n\nBkper tracks resources \u2014 money, inventory, or anything countable \u2014 as movements between places. Every financial event is recorded as an amount moving **from** one Account **to** another. This from-to model replaces the traditional language of debits and credits with something intuitive: resources leave one place and arrive at another.\n\nThe system enforces a **zero-sum invariant** \u2014 the total of all records always equals zero. Nothing is created or destroyed, only transferred. This makes Bkper a double-entry bookkeeping system where every transaction automatically produces balanced entries.\n\nFor those familiar with traditional accounting, \"from\" corresponds to credit and \"to\" corresponds to debit \u2014 but the explicit flow eliminates the need to memorize these rules.\n\n## Accounts\n\n**Accounts** are the places where resources reside or flow through. An Account can represent a bank, a category, a customer, a project, or anything else that holds or transfers value. You define what each Account represents and structure them at whatever level of detail suits your needs.\n\nAn Account registers all incoming and outgoing amounts through transactions. The sum of these movements produces the account's **balance** \u2014 the net result of everything that has flowed in and out.\n\n## Account Types\n\nBkper organizes Accounts into four types that determine how an Account behaves and where it appears in your financial structure:\n\n- **Asset** (blue) \u2014 **permanent**. Real resources you own: bank accounts, cash, receivables. Balances carry forward continuously, showing your position at any point in time.\n- **Liability** (yellow) \u2014 **permanent**. Obligations you owe: credit cards, loans, supplier debts. Balances also carry forward continuously.\n- **Incoming** (green) \u2014 **non-permanent**. Revenue sources: salary, sales, interest. Balances track activity within a period and reset to zero for the next one.\n- **Outgoing** (red) \u2014 **non-permanent**. Expenses and costs: rent, supplies, payroll. Balances also track activity within a period.\n\n## Transactions\n\nA **Transaction** is the atomic unit of financial activity. It captures:\n\n- **Date** \u2014 when it happened\n- **Amount** \u2014 how much moved\n- **From Account** \u2014 where the resource came from\n- **To Account** \u2014 where it went\n- **Description** \u2014 what happened\n\nThe from-to model makes every event explicit and traceable.\n\nA transaction is nothing more than moving a resource from one place to another. When you pay a taxi for a ride, the amount that goes from your wallet to the driver represents a transaction.\n\nIf any essential element is missing, the transaction is saved as an incomplete draft.\n\n## Transaction States\n\nTransactions move through a lifecycle with four states:\n\n- **Draft** \u2014 incomplete or unposted. Does not affect balances.\n- **Unchecked** \u2014 posted and updates balances, but remains editable.\n- **Checked** \u2014 reviewed and locked for integrity.\n- **Trashed** \u2014 removed from balances, but recoverable.\n\nThis structure puts a **human in the loop** \u2014 you review and confirm before records become permanent.\n\n## Groups\n\n**Groups** organize Accounts into hierarchies for reporting and analysis. They don't change the underlying data \u2014 they provide structure for understanding it. Groups consolidate account balances, so you can see totals for categories like \"Expenses\" or \"Assets\" at a glance.\n\nGroups support hierarchies (groups of groups) and multiple perspectives \u2014 an Account can belong to different groups in different hierarchies.\n\nGroups inherit the nature of the accounts they contain:\n\n- **Asset-only group** \u2014 behaves as Asset (blue)\n- **Liability-only group** \u2014 behaves as Liability (yellow)\n- **Mixed Asset + Liability** \u2014 shows Equity (gray, net balance)\n- **Incoming-only group** \u2014 behaves as Income (green)\n- **Outgoing-only group** \u2014 behaves as Expense (red)\n- **Mixed Incoming + Outgoing** \u2014 shows Net Result (gray)\n\n## Books\n\nA **Book** is a self-contained ledger \u2014 the complete scope of an entity, whether an individual, a project, or a business. Every Account, Transaction, and Group lives within a Book, and every Book balances to zero. Books can track any countable resource using the same from-to model.\n\nThe sum of all credits and debits recorded in a Book always tallies to zero \u2014 nothing is created or destroyed, only transferred. For more complex entities, multiple Books can be organized into a Collection.\n\n## Example Flows\n\nThese examples show the same movement model in concrete situations. Some match the diagrams on this page. Others add common accrual flows that are easy to confuse.\n\nThese examples use Bkper's transaction shorthand `From >> To`, meaning the amount leaves the Account on the left and arrives at the Account on the right.\n\n| Situation | Transaction |\n| --- | --- |\n| Salary received | `Salary >> Bank Account` |\n| Investment funded | `Bank Account >> Investments` |\n| Dividends received | `Dividends >> Bank Account` |\n| Loan received | `Loan >> Bank Account` |\n| Rent paid | `Bank Account >> Rent` |\n| Transportation bought on credit card | `Credit Card >> Transportation` |\n\n**Buy on a credit card now, pay it later**\n\n| Step | Transaction |\n| --- | --- |\n| Purchase | `Credit Card >> Outgoing` |\n| Payment | `Bank Account >> Credit Card` |\n\n**Sell now and receive cash later**\n\n| Step | Transaction |\n| --- | --- |\n| Sale on credit | `Incoming >> Accounts Receivable` |\n| Interest added while unpaid | `Incoming >> Accounts Receivable` |\n| Collection | `Accounts Receivable >> Bank Account` |\n\n**Receive a supplier bill now and pay it later**\n\n| Step | Transaction |\n| --- | --- |\n| Bill received | `Accounts Payable >> Outgoing` |\n| Interest added while unpaid | `Accounts Payable >> Outgoing` |\n| Payment | `Bank Account >> Accounts Payable` |\n\n**Receive a loan now and repay principal later**\n\n| Step | Transaction |\n| --- | --- |\n| Loan proceeds | `Loan >> Bank Account` |\n| Principal repayment | `Bank Account >> Loan` |\n\nIn each case, the first movement records the position that was created \u2014 a receivable or a liability. The later movement settles that position. This keeps Incoming and Outgoing focused on activity, while Asset and Liability Accounts hold positions until they are cleared.\n\nIf a receivable or payable grows before settlement, record another movement to that same Account, then settle the total later.\n\n## Balances\n\n**Balances** are always calculated from Transactions, never stored independently. The total balance across all Accounts in a Book is always zero. Account type determines how balances behave over time:\n\n- **Permanent Accounts** (Asset & Liability) \u2014 balance **to a date**, showing cumulative position at a point in time.\n- **Non-permanent Accounts** (Incoming & Outgoing) \u2014 balance **within a period**, showing activity during a timeframe.\n\nBkper maintains a continuous ledger with no concept of closing periods \u2014 the same ledger serves all time-based queries automatically.\n\n## Custom Properties\n\n**Custom Properties** are key-value pairs attachable to any entity \u2014 Books, Accounts, Groups, Transactions, Collections, and Files. They add context, metadata, and meaning beyond core financial data.\n\nBy attaching properties like `invoice: inv123456` or `exc_code: BRL`, entities become rich with information that can drive automation and reporting \u2014 without changing the core model.\n\n## Hashtags\n\n**Hashtags** are lightweight labels on Transactions that enable multi-dimensional tracking. They complement the Account structure by adding dynamic categorization \u2014 a single transaction might carry `#team_marketing #project_alpha #q1_campaign`, enabling filtering and analysis from any perspective.\n\nUnlike Account structures, Hashtags can be added or removed as needs evolve, making them ideal for cost allocation, project tracking, and ad-hoc analysis.\n\n## Collections\n\n**Collections** group related Books for organization and consolidated views. Each Book remains self-contained and balanced \u2014 Collections simply provide navigation and structure across multiple Books. You might track resources in multiple currencies, or organize branch offices in one collection.\n\nCollections can also serve as references for automations (Bots or Apps) that work on all Books in the collection.\n\n## Events\n\nEvery action in a Book \u2014 posting a transaction, editing an account, adding a comment \u2014 generates an **Event**. Events record _who_ (a user) or _what_ (a bot, an automation) performed the action and _when_, forming a complete audit trail essential for collaboration and trust.\n\nEvents are also the foundation of Bkper's automation model. Bots and Agents listen for specific event types and react automatically \u2014 for example, calculating taxes when a transaction is posted or converting currencies when one is checked.\n";
-//# sourceMappingURL=core-concepts.d.ts.map

package/lib/agent/core-concepts.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"core-concepts.d.ts","sourceRoot":"","sources":["../../src/agent/core-concepts.ts"],"names":[],"mappings":"AAGA,eAAO,MAAM,sBAAsB,y7RAwJlC,CAAC"}

package/lib/agent/core-concepts.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"core-concepts.js","sourceRoot":"","sources":["../../src/agent/core-concepts.ts"],"names":[],"mappings":"AAAA,oCAAoC;AACpC,kDAAkD;AAElD,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAwJrC,CAAC"}