your-ai-workflow-firebase-os 1.14.20 → 1.14.22

package/README.md

@@ -33,10 +33,11 @@ That's it. **One component. Zero configuration files.**
 | 📁 **File Storage** | An admin-only Assets screen for public images, plus a drive preset any page can be built on |
 | 📬 **Forms** | Created with their pages on `/pages` — say in one box what a form should ask and what happens after (or name one you already have) and the AI builds it with the page; see and hand-edit every form afterwards on `/forms`. Questions can ask for a file — a CV, a photo, a receipt — and the upload works signed out |
 | 📥 **Inbox** | Every form entry in one list at `/inbox`, filtered "From anyone" or "From signed-in users"; an attached file opens from the entry by its own name |
-| 💳 **Payments** | Stripe checkout in one line — a Take payments switch at the top of `/payments` pauses every Pay button and checkout at once (read by the server, so a built page stops too), then the owner configures what they sell under What you sell on `/payments` (things paid for once — each a name and a price, grouped under one entry — or plans and their Stripe ids), answers How your payments work in one box per payment (start to finish; whatever is skipped, the AI decides), then under Wire it into your pages opens each payment a third time, ticks the pages THAT payment goes on and, optionally, says what should appear there or names a page to add — and copies ONE request that wires all of it: the exact `<PayButton>` tags, each page's content file, the owner's words, and the way this app makes a page, a form and a link — public and signed-in pages sell with `<PayButton>`, internal and admin pages show the team the sales through `useSales()`, and before-paying questions go through the app's own forms. A Go live switch, shown under Connection once the webhook is in, walks the test→live change (live price ids collected, test ids kept, and the id-swap prompt for the assistant generated), buyers get a built-in `/billing` page that appears after their first purchase, and every cancel/switch/invoice screen is Stripe's own billing portal |
+| 💳 **Payments** | Stripe checkout in one line — a Take payments switch at the top of `/payments` pauses every Pay button and checkout at once (read by the server, so a built page stops too), then the owner configures what they sell under What you sell on `/payments` (things paid for once — each a name and a price, grouped under one entry — or plans and their Stripe ids), answers How your payments work in one box per payment (start to finish; whatever is skipped, the AI decides), then under Wire it into your pages opens each payment a third time, ticks the pages THAT payment goes on and, optionally, says what should appear there or names a page to add — and copies ONE request that wires all of it: the exact `<PayButton>` tags, each page's content file, the owner's words, and the way this app makes a page, a form and a link — public and signed-in pages sell with `<PayButton>`, internal and admin pages show the team the sales through `useSales()`, and before-paying questions go through the app's own forms. Connection says Test mode connected and nothing about webhooks while the owner practises; the Go live switch under it is always there and, once flipped, walks the test→live change — the live secret key, live price ids only when a subscription is sold (test ids kept, and the id-swap prompt for the assistant generated), and last the webhook, locked until step 3 of `/publish` is ticked because Stripe needs the published address, which it then hands over with a copy button — buyers get a built-in `/billing` page that appears after their first purchase, and every cancel/switch/invoice screen is Stripe's own billing portal |
 | 📅 **Schedule** | Calendly-style booking, built in — on `/schedule` the owner adds schedules, one per kind of meeting a team member offers (a 1-hour session, a 2-hour workshop): a name — or none, and it is called after its length, A short meeting — a line about it, whose time it is, the hours in that person's own time zone, the length, how far ahead, how much notice, and a one-time payment taken first when they want one. A person's schedules share one availability, so a time booked under any of them is gone from all. Every schedule has a shipped booking page at `/book/{id}` to send as a link — the app's theme and name, a full calendar in the visitor's own time zone, name, email, a note, and Stripe checkout before the time is confirmed when a payment is attached. Every team member gets a My calendar tab at `/my-calendar` the moment a schedule exists for them: every booking made with them on a month grid, Paid beside the paid ones, Cancel to free the time. A schedule can also be picked on `/pages` under Booking on this page (one per person, from a select) or as a Pick-a-time question on `/forms`, and the page's sentence asks the assistant for ONE `schedule` field in a `*Form.config.ts`; the built-in form draws the picker, claims the time so two people can never take the same minute, and saves the booking as a form entry in the Inbox. The assistant never builds a calendar, a time picker or a bookings collection |
 | 🔗 **Payment links** | Every one-time payment has a shipped page at `/pay/{id}` in the app's theme and name — under Payment links on `/payments` the owner adds one from a name, a line about it and a price, copies the link and sends it to anyone; Customise this page makes a real page on `/pages` and hands over the sentence that builds it, and the link goes there once it is built |
 | ✉️ **Email** | Resend in one line — a Send email switch at the top of `/email` stops every send at once (the server reads it before each one); while it is on, every page can send email once it is connected: `emailOwner()` tells the owner what happened, `emailPerson()` confirms to the person a record names, `emailAnyone()` lets a team page write to any address (a signed-in admin or team member only), receipts and sale alerts send themselves off a Pay button's settings, and `/email` says what the app can do with email and where owner mail goes |
+| 🚀 **Publish App** | The admin's last tab, `/publish`: going live one step at a time — each step appears only once the one before it is ticked, and a finished step folds under its checkmark and reopens on a click. 1 publish in AI Studio and save the app name; 2 map your own domain in Google Cloud Run (Search Console TXT record, the four A records) and save the domain; 3 add both addresses as Firebase authorised domains and verify the email sender, with both addresses handed back to copy; 4 — only while Stripe is still on a test key or has no live webhook — finish Go live on `/payments`, whose webhook step unlocks on step 3. Email and WhatsApp buttons at the top reach support |
 | 📖 **Guide** | A walkthrough at `/guide` with the sentences to paste into your assistant |
 | 📊 **Dashboard** | Personalised user dashboard |
 
@@ -92,10 +93,6 @@ APP_NAME=""
 ADMIN_EMAILS=""
 EMAIL_FROM=""
 
-# Admin Config
-# Comma-separated list of admin emails
-VITE_ADMIN_EMAILS=""
-
 # AI features — server side only, never sent to the browser
 GEMINI_API_KEY=""
 ```
@@ -156,7 +153,6 @@ export default function App() {
         messagingSenderId: import.meta.env.VITE_FIREBASE_MESSAGING_SENDER_ID,
         appId: import.meta.env.VITE_FIREBASE_APP_ID,
       }}
-      adminEmails={['you@yourcompany.com']}
     />
   );
 }
@@ -181,16 +177,6 @@ interface FirebaseOSProps {
     appId: string;
   };
 
-  /**
-   * Optional. Who owns the app is decided by the Firestore rules alone: the
-   * /setup page has a bar where the owner types their address and generates
-   * rules that already name them, and the app simply asks Firebase for the
-   * role — the rules say yes to the listed addresses and no to everyone else.
-   * This prop only prefills that bar (handy for pre-configured installs);
-   * nothing requires it any more.
-   */
-  adminEmails?: string[];
-
   /** Theme defaults from your own theme.config.ts. */
   themeConfig?: any;