Keep authority scoped, explicit and observable.

The Site has an existing Vercel deployment. Owner account identity has been checked; final project access, exact release provenance and rollback acceptance remain unresolved. This is not evidence of the App's hosting controls.

App backup and restore evidence belongs to the App release owner. No backup frequency, recovery-time or recovery-point promise is made here. A verified restore and retention record is needed before publishing those commitments.

Workspace data must stay within authorized boundaries. This Site does not certify App database policies, tenant isolation or cross-workspace access tests. Accepted App evidence is required; the Site contact relay is not an App database.

App sign-in, password handling, session expiry and account recovery need accepted configuration and tests. The public Site does not handle App passwords or certify its authentication provider; App sign-in links remain release-gated.

Sensitive App actions must be authorized on the server for the correct user, role and workspace. A visible button is not permission. This Site cannot establish that the accepted App enforces every authority boundary.

Least-privilege access, approval, access removal and administrative audit records require verification. We do not claim that staff can never access customer data or that all administrative actions are audited without current evidence.

Production configuration, privileged services and environment separation must be reviewed on the owner-controlled deployment. Local tests do not prove operating-system hardening, continuous protection or the security of every underlying service.

Underlying hosting providers operate physical infrastructure. Rellooma does not claim ownership of data centers. Provider controls must be evaluated for the actual contracted service; their certificates do not certify Rellooma's application.

Paid checkout and Paddle Live are release-disabled. A payment processor's identity, card-data flow and Merchant-of-Record contract must be verified before activation. No operational card-handling or refund assurance is made here.

Hosted transport, storage encryption, key management and transfer locations require environment-specific evidence. No universal encryption, end-to-end encryption or data-residency guarantee is inferred from a local Site build.

The Site source configures a nonce-based content policy and security response headers. Hosted headers, browser compatibility and provider-edge protections still need release validation. These controls are not a guarantee against network attacks.

App message-safe telemetry and access to logs need accepted evidence. Site runtime, contact delivery and alert paths also need hosted checks. No claim of round-the-clock monitoring or a tested response time is made.

Incident ownership, escalation, secure reporting and customer communication must be approved and exercised. The vulnerability-reporting page is a draft, not a verified mailbox, response SLA or authorization to test customer systems.

Release rollback, recovery contacts and service dependency plans need owner acceptance. No guaranteed uptime or continuity commitment is published without an agreed service level and current operational evidence.

The Site runs automated format, lint, type, build, route, secret and browser checks. Their results apply to the tested source revision, not every App service or an independent security assessment.

Site release flags keep App access, paid checkout, live messaging, public assistant and contact delivery disabled until their evidence is accepted. A flag controls Site presentation; it does not activate or certify an App provider.

The Site uses a lockfile and a production dependency audit in its checks. The latest recorded repair pins the patched image-processing dependency. A clean audit is a point-in-time result, not proof that no vulnerability exists.

Automated Site scans check source and client bundles for secret material. Contact credentials are server configuration, not public content. Scans do not replace provider access review, rotation or human review of release artifacts.

Site checks cover selected risks such as input validation, same-origin contact requests, bounded bodies and response policies. This is not a claim of complete OWASP compliance or an accepted independent penetration test.

The disabled Site contact relay includes outbound HMAC signing. Receiver signature validation, replay handling and durable deduplication must be verified before delivery is enabled. Source signing alone does not prove receiver acceptance.

Contact reads have a size budget and deadline. In-memory limits are not a distributed production defense. Durable or provider-edge limits, challenge validation and downstream idempotency remain activation requirements; contact delivery is disabled.

The public Site assistant is disabled. Future public assistance requires public-only knowledge, bounded cost and abuse controls. App tools must respect server authority and customer permissions; Site tests do not certify their enforcement.

High-risk actions must retain human approval where required. Conversation takeover, pause and deliberate resume are App design requirements whose availability must be checked against the accepted App release.

Site source checks and local browser tests are separate from hosted release acceptance. App Test Center and provider sandbox results need their own accepted App evidence; a green Site build is not permission to activate live channels.

Read the disclosure page before preparing a report. Mailbox delivery, secure evidence handling and triage approval remain pending. Do not test private workspaces, disrupt services or include customer data; no bounty or testing authorization is offered.

Site security changes are tracked as commits with tests and CI evidence. Publishing a repair requires owner-verified deployment and hosted checks. This does not establish a fixed patch SLA, independent audit or certification.