[Medium] No privacy policy; Terms omit refund, revision, delivery, governing law, legal entity

[novaspatial]

Severity: Medium/High (legal/compliance — a business decision).

Summary

There is no privacy-policy page, and the Terms omit refund/cancellation, revision, delivery-timeline, governing law, and the legal entity — while the site collects personal data and takes real payments.

Evidence

• No privacy route exists; the footer Legal group contains only Terms (src/components/layout/Footer.tsx).
• The site collects emails/names/messages (src/app/api/contact/route.ts) and runs analytics (src/app/layout.tsx).
• src/app/terms/page.tsx has 7 sections but no refund/cancellation, revision, delivery-timeline, governing-law/jurisdiction clause, and does not name the legal entity. The footer names "Collide Entertainment Inc." (Footer.tsx), absent from the Terms.

Failure scenario

Launching a paid consumer service without a privacy policy or refund terms is a compliance gap. Stripe and most jurisdictions expect both, and their absence exposes the business at exactly the moment it starts taking money.

Proposed fix

Add a privacy-policy page and expand the Terms to cover refund/cancellation, revisions, delivery timelines, governing law/jurisdiction, and the legal entity. Needs human/legal ownership, not an automated edit.

[novaspatial]

This was generated by AI while working the issue.

Groundwork shipped, and the pack that makes the rest a fill-in-the-blanks

64729ad landed the part of this issue that needed no legal input — it changed zero rendered copy, so no TERMS_VERSION bump and no re-consent.

Three false statements were steering whoever picked this up. The guard comment in terms/page.tsx said "do NOT add refund/cancellation policy (D-refund open)" — but D-refund was answered on 2026-07-14. The same comment cited "#32 unbuilt" for the stem-prep guide, which closed the same day. And retentionPurge.ts cited "T&C §6" as the client-facing disclosure for the 90-day audio purge; §6 is "Service provided as is", and no version of the Terms has ever mentioned retention. All three corrected.

The rulings are citable again. They only existed in docs/devplan-issue-plan.md and issue #1, both deleted on 2026-07-30, so they survived only in git history. Restored verbatim as docs/adr/0002-answered-commerce-and-retention-decisions.md.

The distinction that matters most here: D-refund settled the mechanism (refunds are issued manually through the Stripe dashboard) and said nothing about the policy (when a client is entitled to one). Same for revisions: D-revisions settled that rounds are handled manually and not tracked in-portal, but the number of included rounds appears nowhere in the repo — even though a paid extra_revision add-on (+$50) proves a base number exists.

---

What only you can answer — five facts

Everything else below is drafted. These five are yours:

1. Refund policy. Up to which point can a client cancel and get money back, and what is non-refundable after that? (Options drafted below, keyed to real workflow states.)
2. Included revision rounds. How many are in the base price? The Terms need the number N; the $50 extra-round add-on already implies one exists.
3. Standard turnaround, and when the clock starts. The site sells a 48-hour rush (+$149) against a baseline stated nowhere. Does the clock start at payment, or when usable stems are received?
4. Governing law. Which province's law governs, and are disputes heard in court or arbitration? (The tax code shows a GST/HST-registered Canadian seller, but not where.)
5. The contracting entity. Is Collide Entertainment Inc. the party clients contract with, and what is its registered address? Today it appears in exactly one place — the footer copyright — and nowhere in the Terms, so at the moment of consent the client is not told who they are contracting with.

---

Drafted clauses — refund (pick a letter)

Each is keyed to the lifecycle states that actually exist (pending_payment → uploading → in_review → processing → mixing → review → revision → approved → delivered), so the Terms and the system agree.

A — Generous. Full refund any time before mixing begins. Once your project enters mixing, fees are non-refundable, as studio time has been committed. Refunds are issued to the original payment method.

B — Balanced. Full refund before mixing begins. Once mixing has started, a refund of the unearned portion may be issued at our discretion. After a mix has been delivered for review, fees are non-refundable. Refunds are issued to the original payment method.

C — Strict. Fees are non-refundable once your order is placed, as capacity is reserved on receipt. If we cannot deliver your mix, we will refund in full. Refunds are issued to the original payment method.

All three end with the D-refund mechanism sentence, which needs no ruling.

Drafted clauses — the other four

Revisions. Your mix includes [N] rounds of revisions. Revision requests are made through the client portal and handled by your engineer; additional rounds beyond those included are quoted and invoiced separately. Extra revision rounds may also be purchased at checkout.

Delivery. Standard turnaround is [X] business days from [payment / receipt of usable stems]. The 48-hour rush option shortens this to two business days from the same starting point. Turnaround depends on receiving stems that meet the preparation guidance in your portal; time spent waiting on missing or unusable material does not count toward it.

Governing law. These terms are governed by the laws of the Province of [PROVINCE] and the federal laws of Canada applicable therein, without regard to conflict-of-law rules. The parties submit to the exclusive jurisdiction of the courts of [PROVINCE], except where mandatory consumer-protection law provides otherwise. (The zero-rated non-CA path means cross-border consumers, so that carve-out is worth keeping.)

Entity. These terms are an agreement between you and [ENTITY], a company incorporated in [PROVINCE], with its registered office at [ADDRESS] ("we", "us"). Notices may be sent to contact@nova-spatial.com.

Retention — no blank, and this one is overdue. Fully settled by D7/D7b; it is missing only because nobody wrote it down, while the cron has been deleting audio in production since 2026-07-27:

We keep your uploaded stems and delivered mixes for 90 days after delivery, after which the audio files are permanently deleted from our systems. Please download and archive your deliverables before then. Your project record — order details, invoice, and consent — is retained after the audio is removed as our business and tax record.

---

Privacy policy — drafted from the repo, three blanks

Full draft below; every fact is verified against the code, so the only blanks are [ENTITY], [PROVINCE], [CONTACT].

What we collect. Account email and display name; contact-form submissions (name, email, subject, message, plus a hashed IP used only for rate limiting — the address itself is never stored); order details (song count, add-ons, billing country and province for tax); audio you upload (stems, reference tracks) and mixes we deliver; comments you leave on mixes.

What we never hold. Card numbers. Payment details go directly to Stripe; we store only Stripe's payment identifier and the amount.

Who processes it — Supabase (database, authentication, audio storage), Stripe (payments), Resend (transactional email), Vercel (hosting, plus Vercel Analytics and Speed Insights for aggregate traffic measurement — no advertising cookies, no cross-site tracking).

How long. Audio: 90 days after delivery, then permanently deleted. Project and order records: retained as business and tax records. Contact submissions: retained until no longer needed for the enquiry.

Your rights. Access, correction, deletion, and a copy of your data — by writing to [CONTACT]; deletion requests are honoured except where we must retain order records for tax purposes.

Legal basis / jurisdiction. [ENTITY], [PROVINCE], Canada — PIPEDA, or the applicable provincial equivalent.

---

When you answer

I can land the whole thing in one commit: /privacy (self-referential canonical, footer link, sitemap entry, metadata test — the #53 pattern), the expanded Terms, the entity hoisted next to TERMS_VERSION so the footer and Terms can never drift, and the version bump.

One deploy consequence, worth planning rather than discovering. Bumping TERMS_VERSION makes the checkout route reject any previously-accepted version, so every returning client re-ticks the consent box, and anyone mid-checkout on a cached bundle at deploy time gets a 400 on submit. Historical orders keep their own terms_version on the row, so the audit trail is safe — the exposure is only the deploy window. Deploy off-peak and smoke-test one checkout immediately after; that can share a window with the #50 CSP flip, which wants the same smoke test.

Since this is outward-facing legal copy on a site taking live payments, I will not push it without your explicit go, even after the five answers.