From 48937519b2268ca6bf6daa22cbbf223b2dd7200d Mon Sep 17 00:00:00 2001 From: RightOnQ-code Date: Thu, 7 May 2026 09:44:26 +0100 Subject: [PATCH 01/66] Add standalone RCS registration form --- .../RCS_TWILIO_1_HANDOVER_2026-05-06.md | 477 +++ rcs-registration/README.md | 23 + .../RCS_TWILIO_1_HANDOVER_2026-05-06.md | 477 +++ .../rcs-sender-registration.html | 3183 +++++++++++++++++ rcs-registration/index.html | 3183 +++++++++++++++++ 5 files changed, 7343 insertions(+) create mode 100644 rcs-registration/RCS_TWILIO_1_HANDOVER_2026-05-06.md create mode 100644 rcs-registration/README.md create mode 100644 rcs-registration/backups/rcs-registration/2026-05-07-0934/RCS_TWILIO_1_HANDOVER_2026-05-06.md create mode 100644 rcs-registration/backups/rcs-registration/2026-05-07-0934/rcs-sender-registration.html create mode 100644 rcs-registration/index.html diff --git a/rcs-registration/RCS_TWILIO_1_HANDOVER_2026-05-06.md b/rcs-registration/RCS_TWILIO_1_HANDOVER_2026-05-06.md new file mode 100644 index 0000000..2b36f0f --- /dev/null +++ b/rcs-registration/RCS_TWILIO_1_HANDOVER_2026-05-06.md @@ -0,0 +1,477 @@ +# RCS-Twilio-1 Handover Diary + +Date: Wednesday 6 May 2026 +Project: RightOnQ RCS Registration Studio +Primary working file: `/Users/macpro/rightonq-code.github.io/rcs-sender-registration.html` +Current browser URL: `file:///Users/macpro/rightonq-code.github.io/rcs-sender-registration.html` + +## Summary + +Today we built and heavily iterated a standalone static HTML/CSS/JS form for preparing UK-only RCS sender registration information for RightOnQ-assisted submission. The page started as a broad RCS sender registration template and has been progressively tightened into a guided client-facing intake with automated drafting, validation, autosave, review/export, and demo video generation. + +The major product direction settled today: + +- This is a RightOnQ client tool, not an open-market self-serve paid registration product. +- Client-facing wording should avoid naming the provider at this stage. +- The form must collect answers that map to the actual RCS registration/application requirements, no more and no less. +- Where we help clients with prefilled wording, it must be accurate, editable, and not invent facts. +- Consent/opt-in is a sensitive area; we must guide but not guess. + +## Files Created Or Changed + +### Added + +- `/Users/macpro/rightonq-code.github.io/rcs-sender-registration.html` + - Main static app. + - Contains all HTML, CSS, and JavaScript inline. + - No backend required. + +- `/Users/macpro/rightonq-code.github.io/RCS_TWILIO_1_HANDOVER_2026-05-06.md` + - This handover document. + +### Existing Dirty File Not Touched By This Work + +- `/Users/macpro/rightonq-code.github.io/index.html` + - Was already modified before this work. + - Left untouched during this build. + +## Current Form Shape + +The app is an 8-step form: + +1. Business details +2. Brand profile +3. Sender contact details +4. Use case declaration +5. Opt-in and opt-out evidence +6. UK launch scope +7. Declaration and sign-off +8. Registration pack + +Field numbers now run continuously from the beginning of the form to the end. This was changed from per-step numbering because the user wanted references like “box 38/39” to be stable across the whole form. + +## UK-Only Decision + +The form is currently UK-only. + +Implemented: + +- Registration issuing country fixed to `United Kingdom`. +- UK launch scope only. +- Removed Gulf/UAE, Hong Kong, and Other region choices. +- Export always records `regions: ["UK"]`. +- Added required UK launch confirmation. +- Company type options were changed to UK-appropriate structures. + +## Provider Naming + +We removed visible provider references from the client-facing page. The current language uses: + +- RCS registration +- provider registration +- registration pack +- RightOnQ-assisted RCS sender submission + +Rationale: the client does not need to see the provider relationship at this stage. + +Important: Some source/documentation references in conversation included Twilio/Google, but the visible page was scanned and visible `Twilio` references were removed. + +## Official Guidance Checked + +Sources used during the day: + +- Twilio RCS onboarding guide: `https://www.twilio.com/docs/rcs/onboarding` +- Google RCS launch approval: `https://developers.google.com/business-communications/rcs-business-messaging/guides/launch/launch-approval` +- Google AgentLaunch questionnaire reference: `https://developers.google.com/business-communications/rcs-business-messaging/reference/business-communications/rest/v1/AgentLaunch` +- GatewayAPI RCS registration/agent management blog for industry context: + `https://gatewayapi.com/blog/everything-you-need-to-know-about-rcs-registration-and-agent-management/` +- RightOnQ live site: + `https://www.rightonq.co.uk/` + +Important official requirements identified: + +- Public sender profile fields include display name, description, logo, banner, accent colour, contact details, privacy policy URL, and terms URL. +- Registration review asks for authorised representative details. +- It asks for opt-in and opt-out policy descriptions. +- It asks for opt-in evidence via publicly accessible screenshot/page/document URL. +- It asks for trigger description. +- It asks for use case/interactions description. +- It asks for exact opt-out response. +- It asks for video URL or reviewer access showing the use case and STOP opt-out flow. +- Google launch approval emphasises accurate assets, privacy/terms links, preview video, and STOP capability. + +## Key Wording Decisions + +### Trading Name + +The current helper is: + +`Use this if the public brand differs, e.g. Continuity AI Ltd trading as RightOnQ.` + +Rationale: + +- The exact phrase “trading name” is not a special official RCS field. +- The real need is to link legal business, public brand, website, and sender/display name. +- RightOnQ itself is the perfect example: legal entity `Continuity AI Ltd`, public brand/site `RightOnQ`. + +### Display Name + +Restored to: + +`The name customers should see in their inbox. It should clearly match your brand.` + +A bracketed note was briefly added, but the user preferred the original clarity and noted RightOnQ can review before submission. + +### Sender Description + +We removed made-up “short brand description” and “long brand description” fields. + +Current field: + +- `Sender description` + +It auto-drafts based on display/trading/legal name and industry. It uses RightOnQ-like operational messaging language rather than generic low-value examples. + +Rationale: + +- Official docs describe a sender description/brief summary. They do not ask for short and long descriptions as separate public profile fields. +- User strongly objected to invented questions and generic examples like booking confirmations where not appropriate for RightOnQ’s product. + +### Brand Colour + +Current helper explains that this is one accent colour for the sender frame, with bracketed smaller/italic note that logos/banners/message images can still use the full brand palette. + +Rationale: + +- Official profile uses one accent colour field. + +## Automated Defaults + +Implemented several “copy until edited” defaults: + +- Authorised representative name defaults from primary contact name. +- Authorised representative email defaults from primary contact email. +- Customer-facing email defaults from primary contact email. +- Customer-facing phone defaults from primary contact phone. +- Registration notification email defaults from primary contact email. +- Display name defaults from trading name. + +Behaviour: + +- Once the user edits the target field manually, the app stops overwriting it. + +Phone defaults: + +- Primary contact phone starts as `+44 `. +- Customer-facing phone starts as `+44 `. +- Reset logic also restores `+44 `, though reset/start again is no longer exposed in the visible UI. + +## Registered Address + +Changed from a large textarea to structured UK-style address fields: + +- Address line 1 +- Address line 2 +- Town/city +- County +- Postcode + +The export still builds a combined `registeredAddress` value for RightOnQ/admin use. + +The address fields have a warm gold number accent so boxes 7-11 visually read as one address group. + +## Use Case / Message Drafting + +Fields in the use case section are now drafted where safe: + +- Message trigger +- Use case description +- Example message 1 +- Example message 2 +- HELP sample message +- STOP sample message +- Opt-out description +- Video evidence notes +- Reviewer access notes + +These drafts are built from: + +- Sender/brand name +- Business industry +- Customer-facing email/phone +- Use case where relevant + +Important: if a client edits a drafted field, the app stops overwriting it. + +## Industry Matrix For Example Messages + +Expanded industry-specific drafting for Example message 1 and Example message 2. + +The user initially referred to boxes 38/39, but after checking the actual continuous numbering, example messages were boxes 34/35. The consent fields then shifted after the new consent dropdown. + +Current examples vary by industry, including: + +- Agriculture +- Automotive +- Communication +- Construction +- Education +- Entertainment +- Financial +- Government +- Healthcare +- Hospitality +- Insurance +- Legal +- Manufacturing +- Nonprofit +- Professional +- Real estate +- Retail +- Technology +- Transportation +- Other + +## Consent / Opt-In Section + +This was the most sensitive part of the day. + +Important decision: + +- We should not invent consent facts. +- We can guide clients to explain the actual opt-in route. +- The wording must map to the official opt-in description/evidence requirement. + +Current box 38: + +`How did recipients agree to share their mobile number for RCS messages?` + +Helper: + +`Choose the closest real method. This should match the consent record, screenshot, web page, or document we can provide if requested.` + +Dropdown options: + +- Website or online form +- Customer account or portal +- Booking, contract, or service record +- Event or in-person signup +- Recorded in CRM/customer record +- Staff/internal consent + +Current behaviour: + +- User chooses an opt-in method. +- The app drafts: + - How recipients consented + - Opt-in mechanism description +- Drafts explicitly mention mobile numbers and RCS messages. + +Rationale: + +- Official wording asks for “how users opt in” and evidence, not literally “where phone numbers came from.” +- But the user correctly observed that plain-English clients need to know this is about permission to use mobile numbers for RCS messages. +- The current wording is the compromise: accurate to official requirement, but clear about mobile numbers. + +Open caution: + +- Before further changing this section, verify against official docs and ask the user before patching. + +## Registration Pack / Export + +Final step is now “Registration pack”. + +Contains: + +- Review summary +- RightOnQ admin file download +- Save PDF copy +- Generate video + +The old `Export JSON` label was removed because it confused the user. It is now: + +- `RightOnQ admin file` + +Under the hood it is still JSON, because that is useful for importing/copying into provider registration, but the client does not need to know. + +## Demo Video Generator + +The final step includes a canvas-based video generator. + +It uses: + +- Logo upload +- Banner upload +- Brand colour +- Display/sender name +- Sender description +- Sample messages +- STOP sample message +- Opt-in / opt-out wording + +It generates a browser-recorded WebM file via `MediaRecorder`. + +Purpose: + +- Produce a client-specific representative RCS review video showing: + - Opt-in + - Sender identity + - Sample messages + - HELP/CTA chips + - STOP opt-out flow + - Final review-ready summary + +Limitations: + +- It does not upload to YouTube or hosting automatically. +- RightOnQ must host the generated video somewhere public/unlisted and paste the URL into the registration application. +- Auto-upload would require backend/OAuth and was intentionally deferred. + +## Save / Resume Progress + +Added practical no-backend progress support: + +- Browser autosave via `localStorage` +- `Save progress file` +- `Resume from file` + +The top save panel was initially too prominent and confusing. It was changed to a quieter strip at the top of the form: + +- “Progress is saved in this browser” +- Autosave status +- Save progress file +- Resume from file + +The visible “Start again” button was removed at the user’s request. + +Important limitation: + +- Autosave works only in the same browser/device. +- Progress files can move between devices. +- File uploads themselves are not restored from progress files due browser security; uploaded logo/banner must be reselected if needed. + +Future improvement: + +- Proper emailed resume links require a backend/database/email service. + +## Hidden Test Bypass + +Test bypass exists: + +- Enter `ROQ` or `R-O-Q` in Legal business name. +- Validation allows moving forward without completing required fields. + +Purpose: + +- Let user/developer jump through steps quickly during testing. + +Suggested future improvement: + +- Add a hidden jump shortcut like `ROQ-CONSENT` if user wants direct jump to opt-in page. Not implemented today. + +## UI / Layout Work + +Changes made: + +- Multi-step form with progress panel. +- Continuous field numbering across form. +- Number badges beside labels. +- Active field number highlights on focus. +- Address field badges coloured differently to group address section. +- Helper text min-height added on desktop so paired inputs align. +- Bottom bar simplified: + - Previous step + - Next step + - RightOnQ admin file + - Generate video + - Save PDF copy +- Previous step hidden on first step. +- Navigation no longer scrolls to the top hero; it scrolls to the form/workflow area. + +## Validation + +Implemented: + +- Required-field validation before progressing. +- File upload validation: + - Logo: square PNG/JPG, min 256 x 256 px. + - Banner: landscape PNG/JPG, min 1440 x 448 px. +- Character counts for bounded fields. +- UK-only launch confirmation. + +Current caveat: + +- There is no full browser automation QA yet. +- JavaScript syntax checks pass via Node `new Function(script)`. + +## Current Verification + +Repeated checks today: + +```bash +node -e "const fs=require('fs'); const html=fs.readFileSync('rcs-sender-registration.html','utf8'); const script=html.match(/ + + diff --git a/rcs-registration/index.html b/rcs-registration/index.html new file mode 100644 index 0000000..de039d5 --- /dev/null +++ b/rcs-registration/index.html @@ -0,0 +1,3183 @@ + + + + + + RightOnQ RCS Registration Studio + + + + + + + + + +
+ + RightOnQ + +
RCS Registration Studio
Provider registration prep
+
+ +
+
+
+

RightOnQ client workspace

+

RCS sender registration, packaged for review.

+

Use this studio to collect business details, brand assets, consent evidence, use case notes, sign-off, and a client-branded demo video before RightOnQ prepares the RCS sender registration.

+
+ +
+ +
+ + +
+
+
+
+

Progress is saved in this browser

+

Autosave ready.

+
+
+ + + +
+
+
+

Step 1

+

Business details

+

These details help match the sender profile to the real registered business behind the brand.

+
+
+ +

Use the exact company name shown on Companies House.

+ +
+
+ +

Use this if the public brand differs, e.g. Continuity AI Ltd trading as RightOnQ.

+ +
+
+ +

Only UK companies are accepted. Use the Companies House number for the business being registered.

+ +
+
+ +

Choose the closest legal structure for the business being registered.

+ +
+
+ +

RightOnQ is currently accepting UK RCS applications only.

+ +
+
+ +

Use the public website connected to this brand or sender.

+ +
+
+ +

Use the first line of the Companies House registered office address.

+ +
+
+ +

Add a building, floor, unit, or second address line if needed.

+ +
+
+ +

Use the town or city shown on the registered office address.

+ +
+
+ +

Optional. Add it if it appears on your registered office address.

+ +
+
+ +

Use the UK postcode for the registered office.

+ +
+
+ +

This should be the person RightOnQ can contact if anything needs clarifying.

+ +
+
+ +

We will use this for registration questions and status updates.

+ +
+
+ +

Use an international format if possible, for example +44 7123 456789.

+ +
+
+ +

Defaults to the primary contact. Change it only if a different person should authorise the registration.

+ +
+
+ +

Defaults to the primary contact email. Use the representative’s business email if different.

+ +
+
+ +

Carriers ask for the representative’s role in the organisation.

+ +
+
+ +

Choose the closest match. Carriers use this to understand the sender category.

+ +
+
+
+ +
+

Step 2

+

Brand profile

+

This is the public sender identity customers will see in their messaging app.

+
Logo and banner files stay in this browser. The export records filenames and validation status so RightOnQ can request the final upload-ready assets separately.
+
+
+ +

The name customers should see in their inbox. It should clearly match your brand. (This is the sender name shown in the RCS conversation.)

+ +
+
+ +

Choose one accent colour for the sender frame. (Logos, banners, and message images can still use your full brand palette.)

+
+ + +
+
+
+ +

Square PNG or JPG. Minimum 256 x 256 px. The final registration may require a public URL and tighter file size.

+ +
+
+
+ +

Landscape PNG or JPG. Minimum 1440 x 448 px. Use a clean image that represents the brand.

+ +
+
+
+
+
Logo
+
+ +

Preview only. Final display can vary by device, market, and carrier review.

+
+
+
+
+
+ +
+

Step 3

+

Sender contact details

+

These are the customer-facing contact routes shown on the sender profile.

+
+
+ +

Use an inbox customers can contact for help or questions.

+ +
+
+ +

Use an active number customers can recognise and reach.

+ +
+
+ +

Use the main website or a page that clearly belongs to the brand.

+ +
+
+ +

This should explain how customer data and messaging consent are handled.

+ +
+
+ +

Use the terms customers can review before or after opting in.

+ +
+
+ +

Where RightOnQ should send registration updates and review questions.

+ +
+
+
+ +
+

Step 4

+

Use case declaration

+

Carriers need a plain description of why messages are sent, when they are sent, and what customers will receive.

+
+
    +
  • Choose the use case carefully; changing it later can mean another review.
  • +
  • Use examples that match what recipients will actually see.
  • +
  • The review video should show the recipient’s view, including STOP opt-out.
  • +
+
+
+
+ +

Choose the closest overall purpose for the sender.

+ +
+
+ +

We draft this from the sender name and message purpose. This is the short public profile description.

+ +
0 / 500
+
+
+ +

An estimate is fine. This helps set expectations during review.

+ +
+
+ +

We draft this from the brand and industry. It should explain the real event or schedule that causes a message to be sent.

+ +
0 / 500
+
+
+ +

We draft this as an operational messaging use case. Edit it if the business sends a narrower type of message.

+ +
0 / 500
+
+
+ +

We draft a plain operational example. Keep it close to the messages the business will actually send.

+ +
+
+ +

Use this to show a second normal interaction, such as a follow-up or confirmation request.

+ +
+
+ +

We draft this from the brand contact details. It should tell people how to get help.

+ +
+
+ +

We draft this in the expected unsubscribe style. Keep the wording clear and final.

+ +
+
+
+ +
+

Step 5

+

Confirm How People Will Agree

+

This section confirms how people will agree to receive RCS messages, and how they can stop receiving them later.

+
The review video can use mockups, a test device, or a screen recording. It should show opt-in, a sample message with the sender name, and opt-out, without exposing real customer data.
+
+
+ How will people agree to share their mobile number for RCS messages? * +

Choose every place where people will agree to receive RCS messages. Pick the options that best match how the business already collects permission.

+
+ + + + + + +
+ +

Choose the option or options that best describe how people will give permission to use their mobile number for RCS messages.

+
+
+
+ +

We draft the basic steps. Keep it accurate to the page, form, account, list, or record used.

+ +
0 / 500
+
+
+ +

We draft this around STOP handling. Edit it only if the opt-out flow is different.

+ +
+
+ +

Optional now, but carrier review may ask for a public page, screenshot, or document showing the opt-in.

+ +
+
+ +

A publicly accessible review link, such as YouTube, Vimeo, Loom, or a hosted file.

+ +
+
+ +

Briefly note whether the video shows opt-in, sample RCS messages, primary and secondary message examples, and STOP or unsubscribe handling.

+ +
+
+ +

If reviewers need a test login or special steps, explain them here. Do not include live passwords in this form.

+ +
0 / 500
+
+
+
+ +
+

Step 6

+

UK launch scope

+

RightOnQ is currently preparing RCS sender registrations for UK companies sending to UK recipients only.

+
+
+ Accepted launch region * +

This application will be prepared for UK launch only. Other regions are not accepted in this intake.

+
+ +
+ +
+
+ +

Optional estimate. Some review flows ask for website traffic context.

+ +
+
+ +

If none, write NONE. This helps explain whether RCS is replacing or adding to existing messaging.

+ +
+
+
+ +
+

Step 7

+

Declaration and sign-off

+

A named person should confirm the information is correct and authorised for registration.

+
+
+ +
+
+ +
+
+ +

The person approving this information for submission.

+ +
+
+ +

Use the signatory’s official role or title.

+ +
+
+ +

The date this information is approved.

+ +
+
+
+ +
+

Step 8

+

Registration pack

+

Review the summary, save a PDF copy, and generate a branded demo video for the registration pack.

+
+
+

What this creates

+

A client-specific evidence pack: business data, sender profile details, consent notes, sample messages, validated asset filenames, and a representative review video.

+
+
+

RightOnQ admin file

+

This is for RightOnQ only. It downloads the completed answers in a format we can import or copy into the provider registration.

+
+
+

Hosting step

+

The generated video is downloaded locally. RightOnQ can then host it as an unlisted/public URL and paste that URL into the registration flow.

+
+
+
+
+
+

Branded review video generator

+

Creates a short client-specific demo showing opt-in, sender identity, sample RCS messages, HELP, and STOP opt-out handling.

+
+ +
+
+
+ +
+
    +
  • Uses the uploaded logo and banner preview where available.
  • +
  • Uses the client display name, colour, website, and sample message text.
  • +
  • Shows consent capture and STOP unsubscribe handling.
  • +
  • Exports a browser-generated WebM file ready for hosting.
  • +
+
+
+ +

Video ready.

+
+

Complete the form, then generate the registration demo video.

+
+
+
+ +
+ +
+ + + + + +
+
+
+
+
+
+ +
+ + + + From 224e92d086e56f37e8d2e62a566c3d4af344c491 Mon Sep 17 00:00:00 2001 From: RightOnQ-code Date: Thu, 7 May 2026 09:47:49 +0100 Subject: [PATCH 02/66] Update RCS handover with GitHub and hosting plan --- .../RCS_TWILIO_1_HANDOVER_2026-05-06.md | 149 ++++++++++++++---- 1 file changed, 122 insertions(+), 27 deletions(-) diff --git a/rcs-registration/RCS_TWILIO_1_HANDOVER_2026-05-06.md b/rcs-registration/RCS_TWILIO_1_HANDOVER_2026-05-06.md index 2b36f0f..12c93de 100644 --- a/rcs-registration/RCS_TWILIO_1_HANDOVER_2026-05-06.md +++ b/rcs-registration/RCS_TWILIO_1_HANDOVER_2026-05-06.md @@ -1,9 +1,12 @@ # RCS-Twilio-1 Handover Diary -Date: Wednesday 6 May 2026 +Started: Wednesday 6 May 2026 +Last updated: Thursday 7 May 2026, 09:46 BST Project: RightOnQ RCS Registration Studio -Primary working file: `/Users/macpro/rightonq-code.github.io/rcs-sender-registration.html` -Current browser URL: `file:///Users/macpro/rightonq-code.github.io/rcs-sender-registration.html` +Primary working file: `/Users/macpro/rightonq-code.github.io/rcs-registration/index.html` +Current local browser URL: `file:///Users/macpro/rightonq-code.github.io/rcs-registration/index.html` +Git branch: `rcs-registration-part-a-b-20260507` +GitHub commit: `4893751 Add standalone RCS registration form` ## Summary @@ -19,21 +22,29 @@ The major product direction settled today: ## Files Created Or Changed -### Added +### Added / Current RCS Folder -- `/Users/macpro/rightonq-code.github.io/rcs-sender-registration.html` +- `/Users/macpro/rightonq-code.github.io/rcs-registration/index.html` - Main static app. - Contains all HTML, CSS, and JavaScript inline. - No backend required. -- `/Users/macpro/rightonq-code.github.io/RCS_TWILIO_1_HANDOVER_2026-05-06.md` +- `/Users/macpro/rightonq-code.github.io/rcs-registration/RCS_TWILIO_1_HANDOVER_2026-05-06.md` - This handover document. +- `/Users/macpro/rightonq-code.github.io/rcs-registration/README.md` + - Folder-specific README explaining that this is a standalone beta form. + +- `/Users/macpro/rightonq-code.github.io/rcs-registration/backups/rcs-registration/2026-05-07-0934/` + - Timestamped backup made on Thursday 7 May 2026 at approximately 09:34 BST. + - Includes a copy of the form as it existed before moving into the standalone folder. + - Includes a copy of the 6 May handover note. + ### Existing Dirty File Not Touched By This Work - `/Users/macpro/rightonq-code.github.io/index.html` - - Was already modified before this work. - - Left untouched during this build. + - Was already modified outside the RCS commit scope. + - It was deliberately not staged, committed, or pushed as part of the RCS branch. ## Current Form Shape @@ -43,7 +54,7 @@ The app is an 8-step form: 2. Brand profile 3. Sender contact details 4. Use case declaration -5. Opt-in and opt-out evidence +5. How people agree 6. UK launch scope 7. Declaration and sign-off 8. Registration pack @@ -244,34 +255,39 @@ Important decision: Current box 38: -`How did recipients agree to share their mobile number for RCS messages?` +`How will people agree to share their mobile number for RCS messages?` Helper: -`Choose the closest real method. This should match the consent record, screenshot, web page, or document we can provide if requested.` +`Choose every place where people will agree to receive RCS messages. Pick the options that best match how the business already collects permission.` + +Current control: + +- Checkbox group, not a dropdown. +- Users can choose more than one route because businesses may collect permission through more than one place. -Dropdown options: +Checkbox options: -- Website or online form -- Customer account or portal -- Booking, contract, or service record +- Website form +- Customer account +- Customer record - Event or in-person signup -- Recorded in CRM/customer record -- Staff/internal consent +- Staff list +- Other consent record Current behaviour: -- User chooses an opt-in method. +- User chooses one or more opt-in routes. - The app drafts: - - How recipients consented - Opt-in mechanism description + - Opt-out mechanism description - Drafts explicitly mention mobile numbers and RCS messages. Rationale: - Official wording asks for “how users opt in” and evidence, not literally “where phone numbers came from.” - But the user correctly observed that plain-English clients need to know this is about permission to use mobile numbers for RCS messages. -- The current wording is the compromise: accurate to official requirement, but clear about mobile numbers. +- The current wording is the compromise: accurate to official requirement, clear about mobile numbers, and not frightening to a normal business owner. Open caution: @@ -344,7 +360,12 @@ The top save panel was initially too prominent and confusing. It was changed to The visible “Start again” button was removed at the user’s request. -Important limitation: +Current development note: + +- Progress save/restore has been temporarily disabled in the live form during build/test because browser-saved stale values were interfering with user review. +- The code still contains save/resume support and can be re-enabled later. + +Important limitation when re-enabled: - Autosave works only in the same browser/device. - Progress files can move between devices. @@ -409,22 +430,97 @@ Current caveat: Repeated checks today: ```bash -node -e "const fs=require('fs'); const html=fs.readFileSync('rcs-sender-registration.html','utf8'); const script=html.match(/