PROJECT 07 // HOUSEHOLD PLANNING & COORDINATION

ShoppyCat

A family shopping, pantry, recipe, and meal-planning system that lets one household actually think like a household -- turning shared state into useful, reviewable actions across Android, Firebase, and the web.

STATUS ActivePROGRESS 82%

EXPLORE THE HOUSEHOLD SYSTEM

08 SECTIONS

ShoppyCat turns shopping, pantry inventory, recipes, meal plans, recognition, and household collaboration into one continuous product. Each section below follows a real implementation path and explains it in commented ArcoBASIC.

VISIT SHOPPYCAT.APP ↗

S01 // Reactive workflow active

Shopping Workflow

Personal and shared lists stay useful under rapid edits, multiple contributors, uncertain connectivity, and the ordinary disorder of a real shopping trip.

OPEN SECTION →S02 // Weekly planning active

Pantry & Meal Planning

Pantry inventory, recipes, weekly meal slots, and generated shopping lists form one loop instead of four disconnected features.

OPEN SECTION →S03 // Structured import active

Recipes & Import

Recipes move from web pages or manual entry into editable, scalable cooking objects with ingredients, steps, images, pantry actions, and focused cooking sessions.

OPEN SECTION →S04 // Shared data active

Households & Synchronization

Household membership, invitations, live collections, activity, notifications, and server rules let several people coordinate without turning every user into an administrator.

OPEN SECTION →S05 // Barcode and image paths active

Product Recognition

Barcode lookup, on-device text recognition, learned community corrections, and bounded image analysis converge on an editable product suggestion with an explicit confidence level.

OPEN SECTION →S06 // Bounded assistance active

Assistant & Kitchen Ears

Suggestion, cooking, and voice surfaces convert household context into reviewable actions while deterministic command routing keeps ordinary control predictable.

OPEN SECTION →S07 // Android and Firebase active

Platform Architecture

A Compose application, focused domain repositories, reactive ViewModels, Firebase services, local preferences, and portable parsing rules keep a broad product understandable.

OPEN SECTION →S08 // Rules and operations active

Trust, Community & Operations

Community recipes, plans, themes, feedback, moderation, release notices, account controls, and administration sit behind explicit data shapes and role checks.

OPEN SECTION →

Household coordination without household paperwork

ShoppyCat connects shopping lists, pantry inventory, recipes, meal plans, product recognition, and collaboration so the same information can keep doing useful work. A checked grocery can enter the pantry, pantry state can explain recipe feasibility, a meal plan can produce a shopping list, and a correction can improve future recognition.

The Android application is the primary implemented product surface. Firebase provides identity, reactive shared state, storage, callable services, and notifications. A web port and recipe-capture extension extend the same product rather than becoming disconnected demonstrations.

What is working

Personal, directly shared, and household shopping lists
Quick Add, categories, quantities, prices, focus filters, undoable actions, and live synchronization
Pantry inventory, low-stock context, recipe feasibility, and ingredient consumption
Recipe creation, import, scaling, cooking sessions, images, and community remixes
Weekly meal slots with generated grocery lists and reviewable suggestions
Barcode lookup, product photography, OCR, confidence, and learned corrections
Household invitations, roles, activity, notifications, themes, feedback, and account controls
Deterministic voice commands and bounded assistant functions for planning and cooking

ArcoBASIC explains the product

ShoppyCat is a good example of why ArcoBASIC also exists as a communication language. The implementation spans mobile interface state, reactive data, security rules, parsers, image evidence, cloud functions, and human review. The project pages express those mechanisms as commented, executable ArcoBASIC so a reader can understand the policy before getting lost in framework ceremony.

This does not disguise the production stack. It gives the architecture one consistent language of explanation, invented inside the same Arcology philosophy: technical ideas should become more accessible without becoming less real.

Trust is a feature

Suggestions remain proposals. Recognition reports confidence. Raw recipe extraction asks for review. Optimistic actions can roll back. Household permissions are enforced by server rules rather than hidden controls. Personal and shared scopes remain distinct.

The same care applies to artifacts. Public documentation can explain structures and decisions without publishing signing material, user records, private configuration, or credentials.

Let data keep working after its first use

ShoppyCat's real trick is not any single screen. It is refusing to let a checked-off grocery item, a cooked recipe, or a corrected barcode scan become a dead end. Each one feeds the next decision instead of just closing out the task it started with.

Design state so one honest action produces several useful downstream effects automatically, the way a checked grocery item can enter the pantry, which can then explain a recipe's feasibility, without asking the person to re-enter anything.
Enforce trust boundaries on the server, not just in the interface, and enforce them per scope. Household permissions being server-rule based rather than UI-hidden means a client bug cannot leak or corrupt data another household member should not touch.
Keep automated suggestions labeled as proposals and give every optimistic action a rollback path. A system that can act quickly but never claims more certainty than it has earns the confidence to be trusted with the next automation, instead of losing it after the first wrong guess.

LEARNING LAYER

Key terms, in plain language

You do not need a systems background to follow the work. These are the specialized terms used on this page.

Reactive stream: A continuing sequence of values that updates subscribers when state changes. ShoppyCat uses streams so lists, pantry items, recipes, and household data can update the interface without manual refreshes.
Cloud Firestore: A document database that can synchronize data and notify connected clients when documents change. Security Rules independently decide which authenticated operations are allowed.
Optimistic update: Updating the interface immediately before a remote write finishes, then confirming or reverting the change. It makes interaction fast while retaining a recovery path when persistence fails.
Repository boundary: An interface that describes domain operations while hiding where and how data is stored. Screens can request recipe or list behavior without becoming coupled to Firestore details.
Schema validation: Checking that proposed data has the expected fields, types, ownership, and limits before accepting it. This protects shared collections from malformed or overpowered writes.