pi-ynabro 2.2.0 → 2.2.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "pi-ynabro",
3
- "version": "2.2.0",
3
+ "version": "2.2.2",
4
4
  "description": "Pi extension that registers YNABro tools for YNAB integration",
5
5
  "type": "module",
6
6
  "main": "./src/index.ts",
@@ -25,7 +25,7 @@
25
25
  ]
26
26
  },
27
27
  "dependencies": {
28
- "ynabro": "file:../ynabro"
28
+ "ynabro": "^2.2.0"
29
29
  },
30
30
  "devDependencies": {
31
31
  "@earendil-works/pi-coding-agent": "^0.74.0",
@@ -59,15 +59,35 @@ Accept replies in these formats:
59
59
 
60
60
  Interpret numbers as row numbers from the table.
61
61
 
62
+ ## Batching — All Transactions, 10 at a Time
63
+
64
+ **Never truncate or self-limit the transaction list.** The API returns all unapproved transactions — process every one of them.
65
+
66
+ When there are more than 10 unapproved transactions:
67
+ 1. Before page 1, state the exact total: e.g. _"239 transactions to review across 24 pages."_
68
+ 2. Present transactions **10 at a time**. Page 1 = items 1–10, page 2 = items 11–20, etc.
69
+ 3. Row numbers are **global** and continuous across all pages — never reset to 1 on a new page.
70
+ 4. Include this header above each table:
71
+
72
+ > **Page X of N — items FIRST–LAST of TOTAL**
73
+ > Reply with actions for this page and I'll execute them, then move to the next page.
74
+
75
+ 5. After the user replies, execute their actions for those rows, then immediately present the next 10 **without waiting to be asked**.
76
+ 6. After the final page is actioned, post a summary: total approved / rejected / switched across the whole run, then update skill state.
77
+
78
+ If there are 10 or fewer transactions, present them all in a single table with no pagination header.
79
+
62
80
  ## Workflow
63
81
 
64
- 1. Fetch pending and unmatched transactions.
65
- 2. Call `getSkillState("match-transactions")` and review both the `memory` array and `auto_approve_enabled` flag.
66
- 3. Analyze existing matches and potential new matches (close dates, similar payees, small amount differences).
67
- 4. Present the review table with Yes/No confidence and recommended actions.
68
- 5. Wait for human reply.
69
- 6. Execute approved actions.
70
- 7. Update the skill state with concise corrections/pitfalls only. If confidence has grown sufficiently after multiple runs, ask the user whether to set `auto_approve_enabled: true`.
82
+ 1. Fetch pending and unmatched transactions via `ynabro_get_pending_transactions`.
83
+ 2. Call `ynabro_get_skill_state` with `skillSlug: "match-transactions"` and review both the `memory` array and `auto_approve_enabled` flag.
84
+ 3. Note the **exact total count**. Calculate page count (ceil(total / 10)). State the total and page count before the first table.
85
+ 4. Analyze the first batch of up to 10 transactions (items 1–10) — existing matches and potential new matches (close dates, similar payees, small amount differences).
86
+ 5. Present the review table with the page header (if paginating) and Yes/No confidence and recommended actions.
87
+ 6. Wait for human reply.
88
+ 7. Execute approved actions for that page.
89
+ 8. If more pages remain, present the next page immediately (go to step 4).
90
+ 9. After all pages are done, update skill state with concise corrections/pitfalls only. If confidence has grown sufficiently after multiple runs, ask the user whether to set `auto_approve_enabled: true`.
71
91
 
72
92
  ## Memory Strategy (Minimal Token Usage)
73
93
 
@@ -83,7 +103,7 @@ Good examples:
83
103
 
84
104
  Avoid storing:
85
105
  - Full transaction details
86
- - Successful matches (they dont teach the agent what to avoid)
106
+ - Successful matches (they don't teach the agent what to avoid)
87
107
  - Verbose JSON
88
108
 
89
109
  The goal is a small number of high-signal notes that help the agent avoid previous mistakes while keeping context usage low.
@@ -97,4 +117,4 @@ The goal is a small number of high-signal notes that help the agent avoid previo
97
117
  - Prioritize user control until the skill has earned trust through consistent performance.
98
118
  - Keep memory entries minimal and focused on corrections.
99
119
 
100
- You are here to make YNAB matching reliable through intelligent, learnable review rather than brittle automation.
120
+ You are here to make YNAB matching reliable through intelligent, learnable review rather than brittle automation.
@@ -18,8 +18,13 @@ If `ready` is `false`, walk the user through setup:
18
18
  - **pi:** Call `ynabro_setup` — it presents a native TUI input popup where the
19
19
  user enters the token directly. It goes straight to pi's AuthStorage and
20
20
  never appears in the conversation.
21
- - **OpenClaw:** Instruct the user to add the token to `openclaw.json` or via
22
- the OpenClaw settings UI, then ask them to confirm when done.
21
+ - **OpenClaw:** Instruct the user to store the token using
22
+ `openclaw secrets configure` (recommended) and select the
23
+ `plugins.entries.openclaw-ynabro.config.token` target. As alternatives,
24
+ they can set it non-interactively with
25
+ `openclaw config set plugins.entries.openclaw-ynabro.config.token --ref-source env|file|exec ...`,
26
+ or via the OpenClaw settings UI's sensitive "YNAB Personal Access Token"
27
+ field. Ask them to confirm when done.
23
28
 
24
29
  2. **Missing plan:** Call `ynabro_setup` to list available plans. Help the user
25
30
  pick one. On OpenClaw, follow up with `ynabro_save_default_plan`.