# BuxUp — Implementation Plan

## Implementation plan

**Frontend first. Backend second.** Version 6 incorporates the owner's answers to all 32 product questions. This first implementation draft is ready for build planning; the later-version questions are parked separately. Updated 3 November 2026.

**Pilot contract:** one owner/admin; UK; English; a separate workspace per domain; flexible domain-only intake; LinkedIn, Instagram, and TikTok; one copy and one distinct image per platform; a source-linked UK research report; campaign-wide internal approval; and a ready-to-send client-review email. The pilot ends at email preparation.

Use **decta.com as a research demonstration**, never as a confirmed client, partner, campaign approver, or endorsed advertisement. Demonstration assets and email recipients are labelled examples. The current HF page remains a guide and interactive prototype, not a deployed live campaign agent.

Lead generation, Traffic, and Affiliate marketing are optional strategy hints. They do not add lead collection, click tracking, billing, commission tracking, or publishing to this first build. Canada, other countries, multiple languages, campaign chat, teammates, and live-ad operations are later scope.

The answered questionnaire is preserved locally. BuxUp_Pilot_Decisions.md records how answers map to this draft; BuxUp_Later_Version_Questions.md preserves Q24, Q25, Q27 and groups future questions. There is no new blocking product questionnaire.

## F01 — Frontend foundation and code structure

Use React and TypeScript for the production interface. Organise by dashboard, domains/clients, campaign intake, finished pack, platform regeneration, email handoff, and a separate Hermes activity screen. Shared components cover buttons, labelled forms, dialogs, status badges, source inspection, file upload, error/partial states, and theme controls. This is an implementation choice, not a claim that the production application already exists.

| Component group | Concrete responsibility |
| --- | --- |
| App shell | One authenticated owner context, navigation, Light / Dark / System, and a link to Hermes dashboard |
| Campaign dashboard | Domain filter, current campaign/version, UK/English context, useful status counts and next action |
| Campaign form | New/existing domain, optional offering/audience/instructions/files/mode, with fixed pilot market/platforms |
| Finished pack | Exactly three platform treatments, their individual images, UK report, evidence, issues, and history |
| Redo controls | Redo LinkedIn, Redo Instagram, Redo TikTok, and Rethink campaign after rejection |
| Email handoff | Editable/copyable subject and body, attachments, Redraft email, and download package |
| Hermes activity | Separate dashboard showing automatic changes, why, checks, versions, notifications, and recovery |

Separate saved server records from local view state. Cache records by domain/campaign/version; form contents, tabs, and dialogs remain local. Preserve unsaved input on failed requests. Keep secrets and source-document contents out of browser preference storage. The API owns campaign state; the UI never invents successful research, an image, a sent email, or client approval.

## F02 — Application shell, routes, and single-user access

The landing screen is Dashboard. Navigation covers Dashboard, Domains/Clients, Campaign details, Email draft, and Open Hermes dashboard. The sole signed-in owner can manage all domain workspaces. There are no colleague permission variants, assigned reviewers, client accounts, private client-review links, or team invitation flows in the pilot.

| Proposed route | What the owner sees |
| --- | --- |
| /dashboard | All pilot campaigns, domain/status filters, New campaign |
| /clients and /clients/:id | One canonical-domain workspace, saved profile, sources, files, history |
| /campaigns/:id | Stored brief, run progress, current pack, versions, and next action |
| /campaigns/:id/versions/:version | Exact copy/image/report snapshot and decision history |
| /campaigns/:id/email | Email preview, subject/body, attachment manifest, redraft and downloads |
| /hermes | Separate Hermes dashboard, reachable from BuxUp and with a return link |

Use the established cream/green light palette and forest dark palette. Theme switching preserves page, selected domain, input, and campaign context. On desktop use a sidebar; on phones stack controls and place wide tables in contained scrollers. Validate 390, 768, and 1440 pixel layouts. A single-user design still protects source files and stored records behind the owner session; the separate Hermes screen uses the same owner access.

## F03 — Dashboard, counts, and end states

Show New campaign, domain filter, status filter, campaign table/cards, and counts for Needs review, Email draft ready, Awaiting client response, Client approved, and Rejected. Researching, partial/API error, and cancelled work remain visible in the list. These are working-pilot states, not fictional advertising-performance metrics.

Rows identify domain/client, campaign name or agent-selected offering, strategy mode if chosen, version, current status, last activity, and next action. One campaign includes all three platform variants. No Running, ad spend, leads, impressions, clicks, or booked-call KPI is populated in this pilot. Those metrics are explicitly deferred.

Generating or downloading an email does not mark it sent. If the owner later chooses Record sent externally, store that manual statement separately from the actual package-creation event. An optional Record client approval action stores the owner's reference/note against the exact campaign version, then leaves the campaign at Client approved — pilot complete. No publication follows.

Counters and rows must use the same filter scope and persisted state. Empty/loading/error states are distinct. Repeated clicks or a refreshed page must not duplicate a client, run, or email export. Keep historical rejected and superseded versions inspectable.

## F04 — Flexible new campaign form

A new domain is the only required business input. Existing domain selection supplies it automatically. UK, English, and all three platforms are fixed pilot defaults shown to the user, not mandatory choices they must repeat. The New campaign dialog supports a new domain or an existing saved domain.

| Input | Pilot behavior |
| --- | --- |
| Domain | Required for new client; validate and normalise; reuse an existing matching domain |
| Client/display name | Optional; agent may derive it from research |
| Offering, audience, goal, instructions | Optional. If supplied, constrain the task to that direction rather than advertising unrelated offerings |
| Strategic mode | Optional: Lead generation, Traffic, Affiliate marketing; blank is valid |
| Supporting material | Optional PDFs, images, Word documents, or text context |
| Market/language | Fixed United Kingdom / English |
| Platforms | Fixed LinkedIn + Instagram + TikTok |

Domain-only input instructs Hermes to investigate, select a supported offering and suitable business audience, explain the chosen angle, then produce the full pack. The optional modes guide objective, CTA, and tone; the model must not invent the provider's agreement to pay per lead/visit or an affiliate contract. The destination defaults to the provider domain. No landing-page generation or lead-capture setup is required.

Missing commercial facts do not trigger a clarification loop. The agent continues with source-supported general wording, omits unsupported specifics when possible, and records assumptions/gaps in the final report. When explicit user information conflicts with a website, preserve the requested direction and show the conflict, both sources, and uncertainty clearly rather than silently treating it as verified.

## F05 — Domain workspace, brand, files, and reuse

Every distinct canonical domain gets its own workspace. Case, scheme, trailing slash, and a basic www alias normalisation must not create duplicates; do not silently merge unrelated domains, regional brands, or subdomains into a parent company. The single owner can browse all spaces, but agent retrieval remains restricted to the selected domain.

Show profile, offerings, files/sources, learned preferences, campaigns, and history. Start new domains from fresh client context. Existing-domain campaigns reuse relevant saved facts, prior creative history, and brand context, while refreshing campaign-relevant offers, discounts, feature changes, expired terms, or conflicts. Ongoing background monitoring is deferred with Q27.

Follow the provider website's visual style; avoid people's faces. Retrieve the provider's official logo if accessible, retain its source, and use the actual asset where appropriate. If no usable logo is available, record that gap rather than fabricating a logo or claiming to have used one. The guide's editorial illustrations are placeholders, not real Gemini outputs or DECTA-branded ads.

Support PDF, PNG/JPEG images, and Word DOC/DOCX through verified extraction/conversion paths. Show selected, uploaded, extracting, ready, and failed states. Unsupported/encrypted/unreadable material gets a visible explanation; other usable context may still produce a partial pack. No artificial product-wide file/count cap is selected; real service/format limitations must be disclosed. Records remain visible with no automatic expiry. Explicit removal still invalidates active source retrieval and dependent facts.

## F06 — Finished pack, platform redo, rejection, and approval

The completed view contains the chosen offering/angle, strategy hint, UK/English scope, source context, one LinkedIn copy/image, one Instagram copy/image, one TikTok copy/image, and a concise UK-law research report. TikTok is a still creative with appropriate hook/caption, not a generated video. Allow text copying, image inspection/download, and version history.

| Action | Effect |
| --- | --- |
| Redo LinkedIn / Instagram / TikTok | Rework only that platform's copy and image using previous output, saved brief/research, and an instruction to improve/try a different treatment |
| Reject approach | Preserve rejected version and offer Rethink campaign; do not automatically run another campaign |
| Rethink campaign | Restart strategy/creative planning from stored provider research, then regenerate all three variants and review |
| Approve whole campaign | Approve all three platform artifacts and the reviewed pack snapshot together; unlock a send-ready email draft |
| Redraft email | Reword only subject/body using the unchanged approved pack; leave ad copy/images and research alone |

There is no chat box, free-text revision conversation, or direct creative editor in the pilot. A redo button supplies the regeneration instruction; the owner does not have to write feedback. A new platform treatment creates a new complete campaign snapshot with the other two platform versions preserved. Recheck the changed material against report evidence, invalidate earlier campaign approval, and mark earlier email packages superseded.

Research findings are visible information for the owner/client review. They do not stop generation or create mandatory clarification/acceptance dialogs. Never label the pack guaranteed compliant. Genuine failed tool/model calls can produce Partial/API error; retain available copy and research and identify missing images explicitly.

## F07 — Email handoff and separate Hermes dashboard

After internal campaign approval, the next action is Prepare client email. An email preview can be assembled during pack completion, but it is only send-ready for the internally approved exact version. Use recipient placeholders until the owner provides details; no real recipient or established DECTA relationship is assumed.

| Email component | Contents |
| --- | --- |
| Subject/body | Provider/campaign reference, brief explanation, request for the client's review and approval, clear artifact/version reference |
| Campaign attachments | All three platform copies and distinct images, with platform labels |
| Research attachment | Concise client-facing UK report: applicable areas considered, direct sources, potential issues, wording choices, and remaining uncertainty |
| Owner controls | Copy/edit subject/body, Redraft email, inspect attachments, download complete package and a draft email file |

Use the latest preference in Q5 to include that research summary. Exclude internal model traces, credentials, private system prompts, and unrelated records. The wording asks the client to review, comment, and approve; it does not promise legal assurance or state that an email automatically transfers all responsibility. Missing images and unresolved findings stay disclosed in any partial/draft package.

Pilot handoff is manual: no connected mailbox, automatic send, reply reading, recipient outreach, or ad-account action. A MIME .eml draft with attachments plus a ZIP export is a workable first handoff; support owner-edited subject/body without requiring a new model call. A copied/downloaded draft is not Sent. Optionally record external sending/client response manually; the approved record then sits in the app.

Hermes improvements appear on a separate dashboard reachable from BuxUp. Applied updates show why, exact changes, scope, checks, version, time, and recovery; checking/failed/rolled-back states remain inspectable. No pre-approval or activation action is added. In-app activity is sufficient; external notification channels/digests are parked for later.

## F08 — Frontend failure states and acceptance

Define loading, researching, generating, checking report, partial output, API/rate-limit failure, email ready, rejection, and client-response states. If an image fails, show available copy/research plus the precise missing-image state and retry action. A rate limit must say what stopped and which output was preserved. Avoid fake placeholders presented as completed generation.

Controls need labels, visible keyboard focus, accessible dialogs/tabs, readable contrast, and feedback for async actions. Keep platform selection stable while opening findings. Show which campaign version is approved or superseded. A Redraft email action never silently changes an advertisement, and a creative redo cannot keep an approval of the previous pack.

No user-selected client/campaign count limits or campaign-preparation spending cap is imposed. Provider capacity is finite; truthful errors and finite recovery prevent runaway retries. Preparation-time and revision-count targets are measurements to collect in the pilot, not automatic quality guarantees.

Verify domain-only submission, optional-mode omission/selection, explicit-brief adherence, fixed UK/English/three-platform outputs, partial-image delivery, targeted redo, rejection/rethink, whole-campaign approval, attachment freshness, email-only redraft, and independent theme/read-mode navigation. Do not require a real DECTA approval to validate a demonstration workflow.

## B01 — Services and single-owner boundary

Use a React/TypeScript frontend, Python FastAPI API, PostgreSQL business records, object storage for documents/media/packages, and durable queued workers. A dedicated Hermes adapter coordinates model/tool tasks. The public static HF guide can host documentation or a static frontend build; the actual API, workers, database and file persistence require runtime services.

Use a single authenticated owner rather than implementing organisations, teammate roles, client accounts, and reviewer invitations for the pilot. Authorise record/file access for that owner on every API/export action. Pass an explicit domain/client context into every task, extraction, retrieval, and artifact write. Owner visibility across clients does not permit agent context to mix private client material.

Keep proxy credentials, queue/database access, and object-storage signing on the server. Separate identity/session bootstrap, clients, sources, campaigns, runs, artifacts/reports, approval/email, and Hermes updates into clear service modules. No mailbox or ad-publishing integration is a dependency of the first release.

## B02 — Data, evidence, and version records

| Record | Minimum fields |
| --- | --- |
| Owner | Account/session identity and access state |
| Client/domain | Canonical domain, display name, profile, products, brand assets and their sources |
| Source/file | Domain, source/version ID, URL/object reference, extraction status, checked date, deletion state |
| Fact/context | Value, source, product/audience applicability, confirmed/inferred/conflicting/stale status |
| Campaign | Domain, optional instructions/mode, chosen offer/angle, UK/English, current state/version |
| Campaign version | Brief snapshot, context/source manifest, strategy, artifact versions, report version, configuration snapshot |
| Artifact | Platform, copy, image prompt, image asset/status, version, requested/resolved model and source references |
| UK report | Exact artifacts, law/policy area, sources/check dates, applicability, issue, mitigation, uncertainty |
| Decision | Owner internal approval or manually recorded client outcome, timestamp, exact campaign/manifest hash |
| Email/package | Campaign/version, subject/body revision, recipient placeholder or owner entry, attachment hashes, draft/export state |
| Job/step | Action type, inputs/output hashes, attempts, state, error, run context, usage when available |
| Memory/update | Client/geographic/global scope, evidence, version, applied/failed/rollback state, update record |

Versions are immutable. A platform redo builds a new campaign manifest that references unchanged artifacts for the other platforms. Never rewrite an old approved version or its attachments in place. Retain records without automatic expiry while honoring explicit source deletion/invalidation. All timestamps are timezone-aware and displayed in the user's locale.

## B03 — API contracts and internal events

| Proposed operation | Pilot contract |
| --- | --- |
| GET /session | Single owner identity and current access; no team-role editor |
| POST /clients; GET /clients | Canonical-domain identity, duplicate reuse, searchable workspace list |
| POST /campaigns | New/existing domain plus optional brief/mode/files; inject UK/English/all three platforms |
| POST /campaigns/{id}/runs | Start full preparation with an idempotency key; domain-only is valid |
| GET /dashboard; GET /campaigns | Consistent scoped counts/status rows without performance metrics |
| GET /runs/{id} and progress stream | Stored step states, partial outputs, precise API/error status, resumable event IDs |
| GET /campaigns/{id}/versions/{v}/pack | Exact three-platform copy/image/report/source/history snapshot |
| POST /campaigns/{id}/redo/{platform} | Targeted creative regeneration from a base version; no discovery-loop restart |
| POST /campaigns/{id}/reject; POST /campaigns/{id}/rethink | Record rejected approach, then a separate owner-triggered strategy restart |
| POST /campaigns/{id}/approve | Whole-campaign decision with expected current version/manifest hash |
| POST /campaigns/{id}/email; POST /emails/{id}/redraft | Assemble/redraft email from exact pack; redraft changes only email wording |
| PATCH /emails/{id}; GET /emails/{id}/package | Save owner-edited subject/body, return draft .eml/ZIP with manifest; never send |
| POST /campaigns/{id}/external-status | Optional manual sent/client-response record; no launch or reply automation |
| POST /sources; DELETE /sources/{id} | Upload/extract, replace/version, or invalidate source and dependencies |
| GET /hermes/updates; POST /hermes/updates/{id}/rollback | Separate activity, exact automatic changes, evidence and recovery |

All paths are planned contracts. Validate type/scope and duplicate submissions. Reject stale approval/email writes with a version conflict. Persist meaningful events such as pack.ready, artifact.failed, campaign.approved, email.draft_ready, agent_update.applied, and agent_update.rolled_back; no event named email.sent is emitted by an export.

## B04 — Campaign pipeline and selective reruns

1. Capture domain, optional brief/mode, fixed UK/English/all-platform scope, run ID, and active workflow versions. Load only that client's permitted context.
2. Research a new domain or reuse saved facts for an existing one. Refresh relevant offers/features/terms; extract supporting PDFs/images/Word documents and record gaps/conflicts.
3. Choose a supported offering and suitable business audience when the brief is open. Explicit instructions constrain that choice. Explain the angle and provider/audience fit.
4. Run a dedicated **creative-prompt and copy node**. Return one headline/body/CTA and a separate high-quality image brief/prompt per platform, with website brand cues, no faces, logo asset reference, supported claims, and composition requirements.
5. Request **three distinct images** from the verified Gemini image adapter. Store returned assets and failures separately. Never substitute text or an unrelated cached image as a successful result.
6. Run a **UK law/review node** against the actual copy and image content. Identify potentially relevant areas, authoritative sources, applicability, flagged passages, how wording addresses issues, and remaining uncertainty. This is research support, not a legal guarantee.
7. Assemble the pack and email preview. Return available results despite unresolved findings; mark real failed components partial. Finish at a draft; no legal-question gate, automatic send, or publication.
8. Let the owner redo a platform, reject/rethink, approve the whole campaign, prepare/redraft the email, and export the exact attachments. Optional manually recorded client approval ends the pilot workflow.

A platform redo reruns step 4 for that platform, its image request, affected UK review, and pack/email dependency assembly. It reuses the other two artifacts and provider evidence. Rethink restarts at the strategy stage using saved research. Redraft email invokes only the email wording step. Expired/missing required input evidence can be refreshed narrowly, without blindly repeating all discovery.

Persist each step and its outputs, checkpoint after success, and resume safely after restart. Retry transient errors only a finite number of times; expose provider rate limits or persistent failures and preserve partial work. Do not use an infinite 'nothing should stop the agent' loop. That instruction means avoiding discretionary question/approval gates during preparation, not pretending a failed external service succeeded.

## B05 — Hermes and proxy adapters

Keep the owner's requested reasoning route gemini-3.8-flash-tiered and image alias gemini-3.1-flash-lite configurable through the existing gravityyy-proxyyy gateway. Verify actual route availability, grounded search citations, PDF/image reading, Word extraction, and image bytes before declaring a capability live. Image-input support alone does not establish image generation; retain explicit unavailable states and resolved route information.

The creative node returns structured per-platform copy, visual rationale, image prompt, brand/source references, and output requirements. Keep the image asset separate from the official logo asset; use a verified placement/compositing step where necessary so the model does not invent a brand mark. Inspect visible image text as part of the review.

The UK node distinguishes applicable legislation/regulator material, platform policies, and provider acceptance rules. Each finding references the exact artifact version, source URL, checked date, relevant area, reasoning, proposed wording choice, and uncertainty. A citation is not evidence of universal applicability, and the email must not present automated research as complete legal clearance. Findings do not block draft assembly or make decisions for the client.

Use a scoped Hermes profile/session or an external scoped memory adapter per domain/job as appropriate; do not run concurrent private-memory writers into one shared Hermes home. Store durable business state in the application database. Tool and model traces stay redacted and separate from the user-facing summary.

## B06 — Client, UK, and global learning

New domains start without another client's private context. Existing-domain campaigns retrieve relevant facts, brand preferences, prior offers and artifacts, and recorded outcomes. Refresh changes that matter to the current brief, including new features/discounts and stale terms. No periodic background refresh schedule is selected; preserve Q27 for later.

Client memory remains private to that domain. UK geographic memory stores dated public evidence and applicability. Global memory contains generalized workflow improvements stripped of private client content. Each memory has evidence, scope, validity/status, version, and dependencies. Removing a source invalidates its active chunks and dependent claims rather than merely hiding a filename.

There is no chat-based preference editor in the pilot. Existing instructions and website style guide generation; selecting a redo records dissatisfaction with that treatment, not a new universal legal or brand rule. Detailed one-time versus lasting correction controls belong to the later chat/editing iteration.

## B07 — Autonomous Hermes updates

Keep the agreed lifecycle: detect an improvement, prepare a versioned change with reason/evidence, run automatic checks, apply passing changes automatically, record/notify afterward, monitor and restore a compatible prior version on regression. No pre-approval queue is introduced.

Update handlers cover supported skills/prompts, modes, configuration, memory policies and versioned application changes through actual granted runtime/deployment access. Store exact diff, scope, previous/new versions, checks, timestamps, outcome, notification state, and rollback history. A missing capability is reported accurately; it is not fabricated or converted into approval for a nonexistent permission.

Each campaign run captures the active workflow/configuration version set; already approved packs remain immutable. The separate Hermes dashboard presents applied/checking/failed/rolled-back records and recovery actions. In-app records satisfy pilot notification needs; external email digests and channels are postponed.

## B08 — Reliability, package generation, and boundaries

Campaign generation, whole-pack approval, email revision, manual external response, and Hermes update state are separate records. Use transactions and durable outgoing events; deduplicate run requests, stage writes, and package exports. A failure after two successful images must not discard those images or recreate them on a narrow retry.

Generate .eml with a proper multipart MIME structure and correctly labelled attachments, plus a ZIP containing three copy files, available images, the client-facing report, and a manifest of versions, hashes, gaps and approvals. Validate filename/media types, attachment consistency, recipients/placeholders, and package freshness. Redrafting an email changes its subject/body version, not the approved campaign content. Do not claim every mail client will open a saved .eml as an editable compose window; provide copyable text and extracted attachments as the reliable fallback.

There are no product-imposed limits on saved clients/campaigns or campaign spending in this pilot. Actual API rate limits, storage/file constraints, retry counts and request timeouts still exist and must be visible. Report errors with safe messages, failing stage, preserved output, retryability and a correlation ID. Bounded technical recovery avoids indefinite or duplicate work; it is not a purchased campaign-count quota.

Protect owner access and server secrets, validate uploads, block private/internal network destinations in web fetches, and treat retrieved content as evidence rather than tool instructions. Keep backups, resumable jobs and restoration procedures. No automatic data expiry is selected; explicit removal remains possible. Publication, mail sending, analytics ingestion, earnings tracking, and recurring monitoring are outside the pilot.

## R01 — Build order and dependencies

| Phase | Work | Done when |
| --- | --- | --- |
| 0 | Verify proxy reasoning/search/extraction/image capabilities and record unavailable states | One real output of each required supported capability or an explicit diagnosed gap |
| 1 | Single-owner session, domain records, files, persistence, dashboard and flexible intake | Domain-only creates one job; optional strategy mode remains optional; fixed UK/English/three platforms |
| 2 | New/existing-domain research, brand/logo source capture and selective refresh | New domains start fresh; repeat campaigns reuse relevant facts and inspect changes |
| 3 | Strategy + dedicated copy/image-prompt node + three image requests | One copy and one distinct image per platform, or a transparent partial result |
| 4 | UK review/report and pack assembly | Source-linked areas/issues/wording rationale visible; findings do not force a clarification gate |
| 5 | Targeted platform redo, reject/rethink, versions, campaign-wide approval | Rechecks invalidate stale approvals/emails while preserving other platform artifacts |
| 6 | Email preview, approved handoff, redraft, copy/edit/export, optional manual response | Exact pack attached; .eml/ZIP available; no send or publish occurs |
| 7 | Client/UK/global learning and separate Hermes update dashboard | Automatic changes apply and report without approval; recovery is inspectable |
| 8 | End-to-end DECTA research demonstration and recovery checks | Demonstration labels remain clear; evidence and outputs match the tested workflow |

Build frontend against typed contract fixtures, then connect services and workers. Do not represent editorial preview images or simulated tests as model outputs. Existing public guide modes, themes, and chapter links must continue to work when its specification is updated.

## R02 — Acceptance criteria for the first draft

| Scenario | Expected behavior |
| --- | --- |
| New decta.com domain only | Demonstration-labelled UK/English brief chosen by agent; all three platforms prepared; no assumed DECTA relationship |
| Domain with a specific offering and mode | Instructions constrain strategy; optional mode influences objective without inventing a commercial agreement |
| Existing domain | Reuse relevant facts/history; investigate only needed changes rather than full repeated discovery |
| Normal completion | Three individual copies/images plus a concise UK report and email preview |
| Explicit information conflicts with a website | Continue; preserve direction and flag the exact conflict with evidence/uncertainty |
| UK report has unresolved issues | Findings remain visible; draft/email preparation continues; no compliance guarantee |
| One image fails or the API is rate limited | Preserve copy/research/successful images, explain failure, provide partial status and a retry path |
| Redo Instagram | Revise Instagram copy/image only, recheck report dependencies, new campaign snapshot; other two preserved |
| Reject + Rethink | Rejected record kept; strategy restarts from stored research after the separate user action |
| Internal approval | One decision covers the exact whole campaign and unlocks a send-ready email |
| Redraft/edit email | Subject/body updated; approved ad copy/images untouched; attachment manifest still exact |
| Export email | Draft .eml/ZIP with current files/report; no sent status, delivery claim, mail contact, or publication |
| Record client approval manually | Exact version recorded and left complete; no launch, Running metric, or further automatic pipeline |
| Hermes improvement | Separate activity screen, automatic checks/application, after-update record and recovery without approval |
| Later scope | No Canada, extra language, chat, client login, publishing, analytics, or recurring-monitoring dependency |

The owner's examples suggest reduced preparation time and fewer revision cycles as pilot success measures. Actual timing, research quality, image success, context reuse and user acceptance are measured after capability checks; no signed DECTA outcome or production performance is implied.

## References and deferred decisions

The first draft is sufficiently specified to start implementation planning. Live model capability, extraction quality and deployment persistence are engineering verification tasks. The email handoff interpretation is deliberately concrete: owner sends externally, concise report included, optional manual client-response record.

Deferred questions are grouped in BuxUp_Later_Version_Questions.md: explicitly preserved Q24 results, Q25 post-approval/live changes, Q27 recurring refresh; Canada/other countries; multiple languages; campaign chat/editing; sending/publishing; lead/traffic/affiliate outcomes; teammates/client access; later creative options.

- [DECTA public website](https://www.decta.com/): demonstration research source, not a confirmed client relationship.
- [Existing model proxy](https://huggingface.co/spaces/bardd/gravityyy-proxyyy): requested gateway; live capabilities require authenticated verification.
- [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; scoped BuxUp workflow/update services must be built.
- [FCA financial promotions overview](https://www.fca.org.uk/firms/financial-promotions-adverts): starting source for relevant UK research, with product/audience applicability checked per campaign.

Updated 3 November 2026. This is the agreed-scope implementation draft and design preview; the live agent backend is not implemented by publishing this document.