For AI agents: llms.txt is a short guide that sends you to the rules your problem needs, and rules.json holds every rule of this playbook as JSON.

Risk if broken

Data leaked or lost

Applies when

The project it has user accounts.

How to do it

In Firebase Cloud Messaging, client apps can subscribe to any existing topic. So anyone who guesses a topic named after a user or an order can read it. Firebase calls topics best suited for publicly available information, such as weather alerts. Mark each catalogue type public or personal, and let only public types use a topic send. Keep the payload itself small as Send only what the message needs asks.

Examples

Using these examples: they show one way to follow this rule. Keep the behaviour and the check, not the syntax. Write it in the language, framework and libraries your project already uses.

JavaScript example

export function fcmTarget(type, recipient) {
  if (type.audience === 'public') return { topic: type.topic };
  if (!recipient?.token) throw new Error(`Personal type ${type.id} needs a device token`);
  return { token: recipient.token };
}

Python example

def fcm_target(kind, recipient=None) -> dict:
    if kind.audience == "public":
        return {"topic": kind.topic}
    if recipient is None or not recipient.token:
        raise ValueError(f"Personal type {kind.id} needs a device token")
    return {"token": recipient.token}

How to check

A unit test runs every catalogue type through the send code. No personal type produces a topic or condition target. A grep finds no topic name built from a user, order or account ID.

Sources

• Firebase, Topic messaging
• Firebase, Manage topic subscriptions

Related rules

• Send only what the message needs in Email