DR-013 — Content Operations Platform is Lovable React/Supabase; HTML Portal is Legacy Bridge Only

Decision

The canonical content operations platform is the Lovable React/Supabase application at github.com/eco-monetize/ecomonetize-factory. The HTML content portal at /Claude/dashboards/content-portal.html is a legacy bridge artifact, not a parallel or alternative build target. All new content-ops feature work, bug fixes, and architectural investment go to the Lovable app. The HTML portal receives no further enhancement investment beyond what is strictly required to serve as a short-term bridge until the Lovable app's equivalent features are populated and promoted.

Context

This decision was made in early April 2026 (no later than 2026-04-07) during the original Content Engine consolidation workstream, well before HumanX context entered the roster. The choice was triggered by:

1. Content pipeline stall (5 overdue LinkedIn posts) surfacing in early April
2. The Lovable Content Engine already having substantial architecture in place: 10 pages, 23 edge functions, 15 Supabase tables, 45+ UI components, always-on brand guidelines injection via brand_guidelines + brand_guideline_overrides tables + generation_context table
3. The HTML portal being a point-solution originally built to scaffold immediate content generation, not to be the durable platform
4. CMO Requirements Brief v1.0 + HumanX-related prioritization surfacing the need for a single durable platform

Evidence anchors

Artifact	Path	Date	What it confirms
Content Engine Design Spec v2.0	/Users/rhartley/ecomonetize/Project.Manager/CDO/workstreams/content-engine-design-spec-v2.0.md	2026-04-07	Canonical architecture spec; explicitly identifies ecomonetize-factory as the repository and corrects v1.0 framing
WSB Content Engine Migration Brief	/Users/rhartley/ecomonetize/Project.Manager/CDO/workstreams/wsb-content-engine-migration.md	2026-04-07	Consolidation workstream; P0 priority; cites CMO Brief + HumanX escalation as source
Content Module Design Spec v1.0	/Users/rhartley/ecomonetize/Project.Manager/CDO/workstreams/content-module-design-spec-v1.0.md	2026-04-07	Pre-correction spec; DR-013 is aware v2.0 superseded v1.0's embed-in-ERI framing
Content Engine Mockups Council Review v3.0 (final)	/Users/rhartley/ecomonetize/Project.Manager/CDO/workstreams/content-engine-mockups-council-review-v3.0-final.json	2026-04-08	Final council sign-off on the Lovable-app UI direction
WSB Content Engine Recovery Sprint	/Users/rhartley/ecomonetize/Project.Manager/CDO/workstreams/wsb-content-engine-recovery-sprint.md	2026-04-12	Subsequent sprint plan reaffirming Lovable as the build target
code.platform Content Portal Review (2026-04-20/21)	/Users/rhartley/Claude/sessions/cdo/code-platform-content-portal-review-2026-04-20.md	2026-04-20/21	Confirms Lovable has the always-on brand injection, dashboard, 15-table schema that HTML portal lacks

What this means operationally

For M-2026-0417 Content Portal Recovery (active Mission)

• Scope is not HTML portal remediation. Scope is: bring the Lovable React/Supabase app into production-ready state for internal content operations use.
• Worker Features target the Lovable codebase (ecomonetize-factory), not the HTML portal file.
• The 10-enhancement-fix list surfaced by code.platform's review applies to the Lovable app where equivalent functionality is needed; HTML-portal-specific fixes are deprioritized unless they serve the short bridge window.
• Brand guidelines loading is already architected in Lovable (Supabase tables + edge function injection). Mission scope is to populate brand_guidelines + brand_guideline_overrides tables with Michelle's consolidated guidelines, not to build a brand-loading mechanism from scratch.
• HTML portal stays live as a bridge only until Lovable's equivalent pages are data-populated and verified.

For all CDO-department agents (code.platform, revenue.os, mining.mind, qa.testing, qa.visuals, qa.dataquality, qa.applications, documentation.engineering)

• Do not reopen HTML-vs-Lovable as a live question. It is settled. If evidence surfaces that feels like the decision might be reopened (new features needed, unexpected Lovable constraints), escalate to CDO as a DR amendment request per DR-013 Section "Amendment Protocol" below — do not proceed by quietly forking back to HTML work.
• When a new content-ops feature request lands in your queue, default assumption: "this is a Lovable feature." If the request implies HTML portal work, clarify with dispatcher before building.
• When reading legacy artifacts that reference HTML portal fixes (the 10-enhancement list, Fix 1-10 tasks, etc.), interpret them as "fix in Lovable at equivalent surface" unless explicitly scoped as HTML-bridge work.

For cross-department agents (cmo/category.positioning, cro/sales.ops/customer.success, coo department)

• Content deliverables (brand guidelines, email sequences, positioning language) that need a "content ops platform to live in" target the Lovable app.
• HTML portal is not a canonical intake surface. If you're used to "drop it in the portal," drop it in Lovable (or its Supabase tables, depending on artifact type) instead.

What this does NOT mean

• HTML portal is not deleted today. It continues running on the Mac Studio Tailscale endpoint (:8443) until Lovable's equivalent is populated and promoted. The bridge window is Mission-scoped, not indefinite.
• Lovable is not "the new strategic direction." It has been the direction since 2026-04-07. This DR is codifying an already-made decision that got lost in per-agent memory, not announcing a new one.
• The 10-enhancement-fix list is not invalidated. The problems those fixes address are real (brand context injection, LinkedIn URL tracking, topic persistence, etc.). Where Lovable already solves them, they're already-solved. Where Lovable doesn't yet solve them, they're Mission scope in the Lovable codebase.

Amendment protocol

This DR can only be amended by CEO direction. If any agent believes operational evidence warrants reopening the HTML-vs-Lovable question — e.g., Lovable proves architecturally unworkable, a hard external constraint emerges — the path is:

1. File a written proposal to CDO with evidence (not a dispatch, not a quiet fork back to HTML work)
2. CDO surfaces to CEO in Daily Summary
3. CEO decides
4. If amended, a new DR (DR-NNN) is filed that supersedes this one; this DR's status flips to superseded

No agent amends by action. Actions on HTML portal outside the bridge window constitute governance drift and should be flagged to chief.staff (Eva).

Rationale for codifying now (2026-04-22)

On 2026-04-22 morning, during CDO's scope response to the Content Portal Recovery Mission nudge, the CDO session drafted a scope note that framed HTML-vs-Lovable as a live architectural fork requiring CEO decision. CEO corrected: "the decision to move to the lovable react platform was made way before humanx." The decision had been made but was not preserved durably in:

• CDO session memory (memory-notes.md)
• code.platform session memory (which also framed the question as open in its 2026-04-20 review)
• Any decision record in /Claude/knowledge/decisions/

The memory gap created a real risk: CDO was within minutes of escalating a settled decision back to CEO, and if not caught, code.platform would have received a dispatch that re-opened HTML work. This DR closes the gap by making the decision discoverable at agent respawn via the DR index, independent of whether any individual agent's session memory preserved it.

The broader pattern — strategic decisions getting lost across per-agent memory because there's no cross-agent canonical store — is being addressed separately via a memory-hygiene proposal from CDO to CEO (2026-04-22).

Related

• DR-012 (shared governance baseline + session-dir context files) — established the memory model; DR-013 exposes a gap where strategic decisions need a second layer (cross-agent DRs, not per-agent memory) to survive session turnover
• M-2026-0417 Content Portal Recovery — Mission operating under this DR's scope definition
• M-2026-0421 ERI UI Improvements — distinct Mission; WS-A works on ERI Platform (separate app, ecomonetize-platform repo), not the Content Engine

Review cadence

This DR is reviewed alongside the next major content-ops milestone (Lovable promotion to primary) or at the next chief.staff quarterly DR review, whichever comes first.