BUILD NOTES / OCTOBER 14–15, 2026
Features, design decisions, and testing.
The latest iteration makes request data and confirmation state explicit, so a conversational reply can be traced to the intended record change.
Managing groceries: add, remove, and update items
Let the model interpret; make the workflow execute.
A local qwen2.5:7b model runs through n8n’s Basic LLM Chain. A JavaScript Code node parses structured intents, items, and updates; regular Notion nodes handle the writes. This replaces the earlier direct agent-tool approach.
- Add: normalize names, check existing records, and distinguish new, already-listed, and previously purchased items. The branch creates or reactivates a record, classifies new items, confirms, and refreshes the list.
- Remove: mark an existing item purchased so it leaves the active list while retaining history. Missing and already-inactive items have separate reply paths.
- Update: quantity changes have been tested. If the requested item is missing, ask whether to add it instead of creating it automatically.
- Display: format active groceries by category for Telegram.
These branches are implemented with partial test evidence. Consistent quantity persistence on new items, other property updates, and multi-item behavior still need validation or further implementation.
Confirming changes before adding a missing item
Remember the action across messages.
When an update refers to a missing item, the workflow saves a pending add request in an n8n Data Table and asks for confirmation. The next message looks up that chat’s pending request and routes to Confirm, Cancel, or Normal Message.
Confirmation reuses the add branch and its duplicate checks. The cancel path is designed to clear the pending request without changing groceries. The Data Table holds temporary conversation state; Notion remains the authoritative grocery list.
Evidence from testing
A confirmed request recovered the item and quantity from saved state and reached the duplicate checker as a new item. The confirmed-add cleanup IF and row deletion nodes were reported to fire. Final row deletion and downstream Notion persistence were not independently verified.
What is still open
Expanded cancellation wording did not consistently reach the cancel branch. Stale requests, multiple pending rows, unrelated interruptions, and write-failure cleanup need further testing. The successful component checks do not establish that every confirmation path works end to end.
Earlier features: viewing tasks, meals, and groceries
Reuse the existing planning systems.
/today previously returned “This Week” tasks grouped by priority using JavaScript. The tested response showed the weekly list rather than enforcing the original top-three limit. /dinner returned available meals, and /groceries displayed the shopping list.
All three commands remain part of the intended router. After adding pending-action handling, the normal-message path and empty-lookup behavior need regression so messages continue to reach the correct branch.
Dinner planning remains a flexible list of options. Pantry inventory, inferred stock levels, and a mandatory weekly menu are outside the scope.
Technology used and what each tool does
| Technology | Role in the current implementation |
|---|---|
| Docker | Hosts the local n8n instance. |
| Telegram Bot API | Receives requests and returns lists, questions, and confirmations. |
| Cloudflare / cloudflared | Connects Telegram’s HTTPS webhook to the local instance through a tunnel. |
| n8n | Routes commands and intents, performs queries and writes through Notion nodes, and sends responses. |
| Ollama / Qwen | Interprets conversational intent locally through a Basic LLM Chain. |
| JavaScript | Parses structured model output, normalizes item names, checks duplicates, selects pending requests, and formats messages. |
| n8n Data Tables | Stores pending-action state across messages and supports confirmation cleanup. |
| Notion | Stores authoritative task, dinner, and grocery records. |
| ChatGPT | Supports specification, troubleshooting, and authorized Notion maintenance separately from local model inference. |
Planned feature: mark a dinner as eaten
PROPOSED FEATURE / DRAFT SPECIFICATION
Mark Dinner as Eaten.
A small next increment can start with a short, testable specification. This example shows how I define the user outcome, scope, failure behavior, and unresolved decisions before implementation.
Problem
The user currently has to open Notion to update dinner status after a meal.
User story
As a household planner, I want to tell Barnaby that we ate a particular dinner so my Notion dinner plan stays current.
Scope
Support selecting one existing dinner and updating its status through Telegram.
Acceptance criteria
- A known dinner can be selected and updated.
- Barnaby confirms the actual Notion update.
- An unknown dinner does not modify anything.
- Ambiguous dinner names prompt clarification.
- A failed Notion update returns an error rather than a success message.
Technical questions before implementation
- Which exact Notion status value represents an eaten dinner, and how should the existing Last Made field be updated?
- Does the user need to confirm before changing the dinner?
- How should duplicate dinner names be handled?
Out of scope
Inventory management, recipe recommendations, and meal scheduling.
Draft requirements, not a shipped capability or passing test record. Dinner editing remains planned; each acceptance criterion needs implementation and execution evidence before completion is claimed.
Key decisions, testing gaps, and next steps
Make the boundaries explicit.
The earlier category issue exposed a weak handoff: a useful model reply could still omit a field needed by Notion. The newer architecture makes interpretation, matching, writes, and confirmation separate workflow steps that can be inspected and tested.
Another distinction emerged around state: a pending conversation needs persistence, but it should not become a second grocery database. Temporary n8n state and authoritative Notion records have different responsibilities.
Validate before expanding
- Regression-test slash commands, chat, add, duplicate, reactivation, remove, quantity update, confirm, and cancel.
- Preserve messages when a pending-action lookup returns no rows; reconnect and verify the normal-message route.
- Handle stale or multiple pending actions and determine request source from the current branch.
- Confirm successful writes before cleanup; test retries, authorization, quantities on new records, and restart behavior.
Planned next: dinner and task editing
The Notion spec adds dinner creation, marking a dinner eaten with a last-made date, reactivation, task completion, and task creation. These are proposed increments that will reuse the structured intent router, record matching, and confirmation mechanism. No new edit capability is presented as complete.
Based on the Notion implementation update dated October 15, 2026. Component successes and partial tests are distinguished from pending end-to-end regression. Calendar, email, scheduled briefings, and measured time savings remain future work.