Trust, Community & Operations

A product includes its operating surfaces

ShoppyCat includes feedback with threaded developer comments, community recipes and meal plans, shared themes, item contributions, release announcements, notifications, account deletion, premium management, and an administrative portal.

These are not decorative extras around the app. They are how a real product learns, responds, governs shared data, and lets a person leave.

Rules before reach

Default-deny Firestore fallback for unmatched documents
Self-only access for personal collections
Member and administrator checks for household collections
Field-level validation for public contributions and interaction counters
Author or developer ownership rules for deletion and moderation
Server-side entitlement synchronization and administrative actions
Account deletion path exposed publicly without requiring a support ritual
No secret configuration or administrative credentials shipped as portfolio artifacts

Validate the proposed change

Public interaction documents should not accept an arbitrary replacement object. The server can permit a narrow reaction update while proving that identity, authorship, and content remain unchanged.

ArcoBASICArcoBASIC communication example: validate a community reaction update

' Allow interaction counters to change without changing authorship.
FUNCTION ValidReactionUpdate(before, after, actor)
    IF actor.UserId == "" THEN RETURN FALSE

    ' Immutable identity fields must survive the update exactly.
    IF before.Id <> after.Id THEN RETURN FALSE
    IF before.AuthorId <> after.AuthorId THEN RETURN FALSE
    IF before.Content <> after.Content THEN RETURN FALSE

    ' A reaction update may change only the bounded counters.
    IF after.Likes < 0 OR after.Saves < 0 THEN RETURN FALSE
    IF ABS(after.Likes - before.Likes) > 1 THEN RETURN FALSE
    IF ABS(after.Saves - before.Saves) > 1 THEN RETURN FALSE

    RETURN TRUE
END FUNCTION

Transparency is part of maintainability

The website porting scope classifies what is implemented, partially implemented, administrative, external, or intentionally deferred. The API map records listener lifecycles and every callable boundary. That documentation reduces the risk that a future client invents a second, subtly incompatible product.

The same principle governs the portfolio page: it describes current code and current boundaries. It does not expose credentials, private user data, signing material, or Firebase configuration merely to make the artifact look more complete.

What you document is part of what you built

Default-deny rules and a reaction-update validator are ShoppyCat's specific safeguards. A different system will protect different fields against different kinds of tampering. The instinct to make illegal states unrepresentable, and to write down what the system actually does, is what generalizes.

The same instincts show up in API design that rejects unknown fields instead of ignoring them, in database migrations that validate invariants rather than trusting application code to preserve them, and in any technical documentation meant to outlive the person who wrote it. What a system refuses to allow, and what it writes down about itself, says as much about its quality as what it lets you do.

The Firestore fallback rule denies access to any document shape nobody explicitly matched, rather than defaulting to allow. Any access-control system is safer starting from deny and opening specific paths than starting from allow and trying to close every hole after the fact.
ValidReactionUpdate checks that a document's identity, author, and content survive an update byte-for-byte, and only then allows the like and save counters to move by at most one. Validating what must stay the same is often more important than validating what is allowed to change; an attacker rewriting a whole document to inflate a counter is caught by the fields that were never supposed to move.
The website's porting scope classifies every feature as implemented, partial, administrative, external, or deferred, and the API map records every callable boundary and listener lifecycle. Writing down what a system does and does not do, in a form specific enough to prevent a future rebuild from silently diverging, is itself an engineering deliverable, not an afterthought.
The portfolio page describes current code and current boundaries without shipping credentials or configuration to look more complete. Demonstrating a system honestly does not require exposing what would make it exploitable; restraint about what gets shown is part of the trust the system is trying to build.

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.

Role-based access: Authorization based on both membership and assigned responsibility, such as household member or administrator. A role grants a limited set of operations rather than unrestricted access.
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.
Callable function: A server-side operation invoked by an authenticated application client. It is useful for protected work such as entitlement checks, notifications, and bounded model-assisted requests.
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.