# BuxUp Growth Desk

## One domain. Three platform drafts. One review email.

**Working system plan · Version 6 · 3 November 2026**

A single-owner campaign preparation workspace for specialist payment providers serving UK business customers. Enter a domain, optionally narrow the offering and strategy, and Hermes prepares LinkedIn, Instagram, and TikTok copy/images, a concise UK research report, and an email draft for client approval. The pilot stops at email preparation.

The guide's interactive previews use example records and editorial images. They are not live Gemini outputs or actual client decisions. DECTA is a demonstration research example, not a signed client or partner. The separate Implementation plan mode contains the detailed frontend-first/backend-second specification.

## 01 — The business, audience, and pilot

BuxUp's intended paying client is a specialist payment provider serving the UK, typically a smaller or mid-sized payment institution, electronic money institution, or acquirer that accepts legitimate businesses with complex or higher-risk payment needs. Its campaigns reach suitable business customers for a supported service. The provider's acceptance criteria matter before choosing an audience or claim.

Use decta.com as the first research demonstration. Do not imply DECTA hired BuxUp, approved the materials, or appointed a reviewer. A domain-only campaign can let Hermes identify an offering and suitable business audience. Specific user instructions narrow that task. The live pipeline must ground factual claims in the provider's actual sources.

There is one user: the owner/admin/developer. The client reviews exported materials by email outside the app. There are no teammate views, role assignments, client logins or client-review links in the pilot.

## 02 — A dashboard that ends at email

The home screen shows domain workspaces, campaigns, status counts, and New campaign. Keep Needs review, Email draft ready, Awaiting client response, Client approved, Rejected, and active/partial/API-error work visible. Status counts and rows share the same domain/status filters.

An email export is a draft, not proof of sending. The owner may optionally record external sending or a client response manually. A recorded client approval leaves the exact campaign complete in the app; it does not launch an ad. Running campaigns, traffic, leads and ad-platform results are later-version features, not populated pilot KPIs.

<!-- dashboard-preview -->

```mermaid
%% diagram: journey
flowchart LR
  A[Dashboard / New campaign] --> B[Domain + optional brief/mode]
  B --> C[New research or saved context]
  C --> D[Creative prompts and three ads]
  D --> E[UK research report]
  E --> F[Whole-campaign internal review]
  F --> G[Client email draft and attachments]
  G --> H[Stop / optional manual client decision]
```

## 03 — A separate space for each domain

Every canonical domain gets its own profile, files, facts, brand context, campaign history and memory. New domains start fresh; existing domains reuse relevant information. Do not merge unrelated domains into a brand group automatically.

The owner can add, replace or remove source material and inspect its status. PDF, images, and Word documents are pilot inputs. A removed source leaves active retrieval and invalidates dependent facts; a filename must not disappear while its extracted contents remain silently searchable. History remains visible without automatic expiration unless explicitly removed.

```mermaid
%% diagram: client
flowchart TD
  A[One canonical domain] --> B[Profile + brand]
  A --> C[Files + evidence]
  A --> D[Campaign versions]
  B --> E[Website style + official logo]
  C --> F[Domain-private memory]
  D --> G[Three ads + report + email]
```

## 04 — Investigate, continue, and explain gaps

The pilot does not force the user through repeated clarification questions. A domain is enough to begin provider/audience investigation. Missing prices, rates, eligibility details or offers should lead to supported general wording and explicit report notes, not invented facts.

If the user supplies information that conflicts with a website, preserve the requested direction and flag the conflict in the final report with sources and uncertainty. Do not silently convert a user claim into verified evidence. Reports distinguish user-provided, website-derived, inferred, conflicting and stale facts.

Findings do not stop preparation or impose a legal-signoff dialog before the agent returns a draft. Real API failures and unavailable images remain honest partial/error states; the instruction to continue never means fabricating successful output.

## 05 — Domain-only or a specific brief

New campaign asks whether the domain is new or existing. New domains require the domain; saved domains supply it. Offering, audience, instructions and supporting files are optional. UK, English and all three platforms are fixed pilot settings shown to the owner.

Optional strategic modes are **Lead generation**, **Traffic**, and **Affiliate marketing**. A blank selection is allowed. These guide the objective and creative approach; the pilot does not collect leads, measure traffic, calculate payments, or assume a commercial affiliate agreement.

Every ad links back to the provider domain. Landing pages, click destinations beyond that default, and lead-capture forms are later work. No product-imposed cap is placed on saved clients, campaign counts or preparation spending; real service limits still produce visible errors.

## 06 — One copy and one image per platform

A dedicated creative node writes platform-specific copy and strong, distinct image prompts. It follows website style, avoids people's faces, and uses a retrievable official logo rather than inventing a brand mark. Each platform gets one copy treatment and one distinct image.

| Platform | Pilot output |
| --- | --- |
| LinkedIn | Business-focused headline/body/CTA plus its own image |
| Instagram | Visual-led headline/caption/CTA plus its own image |
| TikTok | Hook/on-screen wording/caption/CTA plus its own vertical still image; no generated video |

The previews below are editorial composition examples for a fictional provider. Real generation must return actual image assets through the verified image API; a text response or a failed image call is not an image.

<!-- creative-previews -->

## 07 — Model gateway and capability checks

Use the existing gravityyy-proxyyy gateway, the requested main route gemini-3.8-flash-tiered, and requested Gemini image alias gemini-3.1-flash-lite. Confirm actual route availability, grounded search, document reading, extraction, and image bytes with authenticated capability tests. Requested aliases are not proof of upstream capabilities.

The backend owns credentials and proxy calls. The browser receives stored copy, media and report records. Separate adapters normalise reasoning, citations, document content, image output, errors and usage. A partial output keeps usable work and explains what failed; provider rate limits must be shown to the owner.

## 08 — A concise UK-law research report

The UK review node examines the actual three-platform copy and visual content. It identifies potentially relevant areas of UK law/regulatory material, provider restrictions and platform policies, with authoritative links, applicability, checked dates, specific issues, wording choices and remaining uncertainty.

Explain how the draft attempts to address an issue without declaring guaranteed compliance. Unsupported claims and conflicting facts remain visible. No finding imposes an automatic question gate; the owner and client reviewers can inspect the evidence with the exact materials.

The client-facing summary accompanies the email, following the latest preference in Q5. It asks for review/approval rather than promising legal assurance or claiming that sending an email transfers all responsibility. The [FCA overview](https://www.fca.org.uk/firms/financial-promotions-adverts) is a starting reference, not a universal finding for every payment-service advertisement.

## 09 — What the owner sees at the end

The finished pack contains the chosen angle, optional strategy mode, three platform copies/images, a concise UK report, sources/gaps, versions, and whole-campaign review actions. Inspect images, copy text, open findings, and download available assets. Partial-image failures keep the useful copy and research visible.

**Redo LinkedIn / Instagram / TikTok** changes that platform's copy/image only, then refreshes affected report/email dependencies. No chat or free-text creative revision is required. **Reject approach** preserves that version and offers **Rethink campaign**, which restarts the strategy using saved research. One internal approval covers the full exact campaign version.

After approval, prepare an email containing the three ads/images and a concise research attachment. Copy/edit the subject/body, download the package or draft email, or select Redraft email. This changes email wording only. Sending, reading replies and publication are outside the pilot. Any later client decision is manually recorded, then the work sits complete.

<!-- results-preview -->

## 10 — Hermes and the work loop

Hermes loads domain-scoped context, chooses an offering/angle or follows the brief, writes copy/image prompts, requests media, prepares the UK report, stores artifacts, and assembles the email preview. No routine clarification conversation is required. The backend tracks durable steps, versions and partial failures.

```mermaid
%% diagram: agent
flowchart LR
  A[Domain and optional instructions] --> B[Load or refresh context]
  B --> C[Choose campaign strategy]
  C --> D[Copy + image prompt node]
  D --> E[Three images + UK report]
  E --> F[Owner reviews full pack]
  F --> G[Email draft and export]
  G --> H[Persist domain learning]
```

A selective redo reuses saved context and untouched platform artifacts. Email redrafting never triggers research or changes approved advertisements. Actual API errors have finite recovery and transparent stop/partial states rather than an endless loop.

## 11 — Hermes updates on a separate dashboard

Hermes improves supported skills, prompts, modes, settings, workflow configuration and versioned system behavior automatically, runs checks, applies passing updates, and records what changed and why. There is no approval or activation queue for those updates.

The owner can reach a separate Hermes dashboard from BuxUp and return afterward. It shows applied/checking/failed/rolled-back changes, exact versions/diffs, evidence, checks and recovery history. In-app activity is sufficient for the pilot; external alert/digest preferences are future questions. Self-improvement does not send an email or approve/publish an advertisement.

<!-- hermes-preview -->

```mermaid
%% diagram: admin
flowchart LR
  A[Detect an improvement] --> B[Prepare diff and evidence]
  B --> C[Automatic checks]
  C --> D[Apply automatically]
  D --> E[Record and notify afterward]
  E --> F[Monitor / recover]
```

## 12 — Domain, UK, and global learning

Domain memory stores only that provider's relevant facts, brand context, sources and campaign history. UK knowledge stores dated public research and applicability. Global skills hold general improvements without private client content.

```mermaid
%% diagram: learning
flowchart LR
  A[Campaign outputs and feedback] --> B[Private domain memory]
  B --> C[Next campaign reuse]
  A --> D[General lesson]
  D --> E[Scope and evidence check]
  E --> F[UK knowledge / global skill]
  F --> G[Check / auto-apply / record]
```

On a new campaign, check relevant changes such as offers, discounts, terms and features while reusing stable context. Ongoing background monitoring is deliberately unanswered and parked with Q27. Saved records do not automatically expire; evidence can still become stale and require a fresh check.

## 13 — Application architecture

The product frontend shows dashboard, domain workspaces, packs, redos and email handoff. A single-owner backend enforces access and domain scope, stores records, queues work and calls Hermes/proxy services. Persistent files/media/email packages live in object storage; business/version records live in a durable database.

```mermaid
%% diagram: architecture
flowchart LR
  A[Single-owner dashboard] --> B[Application API and jobs]
  B --> C[Hermes coordinator]
  C --> D[Existing model proxy]
  D --> E[Reasoning / images / search]
  B --> F[Domain data and files]
  C --> G[Scoped evidence and memory]
```

Email packaging exports a draft with attachment/version metadata. There is no mail-send, lead-capture, ad-account, analytics or payment integration in the pilot. Technical capability and persistence checks are part of the implementation work.

## 14 — The next campaign reuses useful context

For the same domain, start from its saved provider profile, brand style, relevant prior campaigns, and sourced facts. A new offering or specific instruction narrows the work. Refresh information that matters rather than repeating unchanged discovery.

A platform redo creates a new pack snapshot and invalidates the prior approval/email. A rejected approach stays in history. An email-only redraft preserves the exact approved campaign. No previous approval transfers to changed advertisements.

## 15 — First-draft scope and later questions

The first pilot proves domain-only generation, three platform treatments, image-prompt writing, UK research reporting, scoped reuse, targeted redo, campaign-wide approval and a draft-to-email handoff. DECTA remains an example; no actual client approval or publishing outcome is assumed.

Later-version questions are saved separately: **Q24 campaign results**, **Q25 changes after approval/live ads**, **Q27 recurring refresh**, Canada and other countries, languages, campaign chat/editing, publishing/sending, lead/traffic/affiliate outcomes, teammates/client access, and video/creative expansion. Those are deliberate exclusions from the first implementation draft.

## Sources and review notes

- [DECTA public website](https://www.decta.com/): example research domain, not a confirmed client.
- [Existing proxy](https://huggingface.co/spaces/bardd/gravityyy-proxyyy): requested inference gateway; real capabilities need authenticated checks.
- [Hermes memory](https://hermes-agent.nousresearch.com/docs/user-guide/features/memory) and [skills](https://hermes-agent.nousresearch.com/docs/user-guide/features/skills): underlying mechanisms for the planned integration.
- [FCA financial promotions overview](https://www.fca.org.uk/firms/financial-promotions-adverts): starting source for applicable UK research, not campaign-specific legal clearance.

Updated 3 November 2026 from the answered product questionnaire. This is a plan and interactive design preview; publishing it does not implement a live backend or send any client email.
