Digital Allies · CMS Specification

The Digital Allies CMS

What the CMS must do, and the plan to build it.

One CMS, one interface. The canonical CMS is the side-navigation dashboard at cms/dashboard.html (served by cms/app.js + cms/style.css). Point every developer, collaborator, and doc here. Earlier prototypes live in cms/_archive/ for reference only — don't build against them.

What the CMS Must Include

Beyond managing records, the CMS has to run the website. It does three core jobs, plus a set of supporting modules. The dashboard shell and basic create/edit/delete already exist as a front-end prototype; the items marked To build are the functional scope to implement against a real backend.

1 · Website page editing Partially built

Full visual website editing — not a single text box. Editors build and change pages by stacking sections they pick from a library, the same way a real website builder works.

Page list — title, slug, status, last-updated Built
Open a page into a block/section editor — the page is an ordered stack of sections, each with its own fields To build
A section / component library to insert from, drawn from the design system: Hero, Departments grid, Field Notes, Rich Text, Call-to-Action, Image / media, Stat strip, Pinned Quote, FAQ / Accordion, Contact footer To build
Add a section → choose its type → edit its content inline To build
Reorder (drag or up/down), duplicate, and remove sections To build
Per-section options (light / dark background, spacing) To build
Draft vs. Published; SEO title, meta description, slug Built (fields)
Live preview rendering the real brand styles before publish To build

2 · Global design-system editing Partially built

Edit the brand tokens the entire website reads from one place, so a change updates every page and template at once — no code edits.

Colors — Pulse Blue, Signal Red, Accent, charcoal, bone, and semantic colors Built (3 colors)
Type — header / body / detail font families and the type scale To build
Spacing scale, border, shadow, and motion values To build
Logo / wordmark upload, favicon, site name, tagline, contact, social links Built (most)
Tokens write to a store the site reads at render (CSS variables, mirroring colors_and_type.css) To build
Preview a sample page with the new tokens; revert to defaults To build

3 · Blog & article publishing Partially built

The Press Office / The Journal — write, schedule, and publish long-form content that appears on the site.

Article list by type (Blog Post / Press Release / Case Study), status, and date Built
Editor — title, slug, excerpt, body, tags, hero image, author Built (fields)
Rich-text / block body (reuse the section library where it helps) To build
Draft / Review / Scheduled / Published, with a schedule date Built (states)
Publishing surfaces the article on the public site and feeds the content calendar To build

Supporting modules (already in the dashboard shell)

Content Calendar — the 30-day marketing run (matches the reusable ContentCalendar component shape)
Projects — Kanban board · Research — notebooks & notes · The Workshop — dev / bug tracker
Settings — site info + the global design-token editor (Pillar 2)
Global search, notifications, and the multi-client switcher (Agency plan)

Build status, honestly. cms/dashboard.html + cms/app.js are a working front-end prototype with in-memory sample data — the shell, navigation, and basic CRUD are real and clickable. The page builder, the section library, the full design-token editor, and live publishing are specified above and get built against the backend in the phases that follow.

The three public surfaces it feeds

Pages built in the page builder (home, about, services, contact, and any new page)
Services Index + Tool Detail templates (ServicesIndex.dc.html, ToolDetail.dc.html) reading Tools & Services
The Journal — published articles + the content calendar

Technology Stack

Backend Node.js + Express / Firebase / Supabase

Database PostgreSQL / MongoDB / Firebase

Frontend (Dashboard) React + Tailwind CSS

API REST / GraphQL

Authentication JWT / OAuth 2.0

Hosting Vercel / Netlify / AWS / Heroku

Implementation Phases

Phase 1: Database Setup (Week 1)

Collections to Create

Collection	Purpose	Key Fields
Tools	Individual service offerings	name, slug, description, icon, features, pricing, problemStatement, solutionStatement, faqs, cta
Services	Department/service categories	name, slug, description, icon, featuredTools[], order
ContentCalendar	30-day social + email schedule	day, week, category, topic, hook, caption, cta, promptRef, status, scheduledDate
Users	CMS editors & admins	email, password (hashed), role, permissions, createdAt
Settings	Global configuration	siteName, tagline, contactEmail, socialLinks, brandColors

Setup Instructions

Choose your database provider (PostgreSQL recommended for relational data)
Create the 5 collections above with the specified fields
Add indexes on: Tools.slug, Services.slug, ContentCalendar.day, Users.email
Set up automated backups (daily)
Create seed data: import the 30-day content calendar CSV

Phase 2: Backend API (Week 2)

Core Endpoints to Build

Tools

GET    /api/tools                    # List all tools
GET    /api/tools/:slug              # Get single tool
POST   /api/tools                    # Create (admin)
PUT    /api/tools/:slug              # Update (admin)
DELETE /api/tools/:slug              # Delete (admin)
      

Services

GET    /api/services                 # List all services
GET    /api/services/:slug           # Get single service + tools
POST   /api/services                 # Create (admin)
PUT    /api/services/:slug           # Update (admin)
DELETE /api/services/:slug           # Delete (admin)
      

Content Calendar

GET    /api/calendar                 # List all entries (30 days)
GET    /api/calendar?status=scheduled # Filter by status
GET    /api/calendar?category=...    # Filter by category
POST   /api/calendar                 # Create entry (editor)
PUT    /api/calendar/:day            # Update entry (editor)
DELETE /api/calendar/:day            # Delete entry (admin)
      

Authentication

POST   /api/auth/login               # Login (returns JWT)
POST   /api/auth/logout              # Logout (invalidate token)
POST   /api/auth/refresh             # Refresh token
GET    /api/auth/me                  # Get current user
      

Response Format Example

{
  "success": true,
  "data": {
    "id": "tool-001",
    "name": "Brand Discovery",
    "slug": "brand-discovery",
    "description": "From brief to brand board in one session",
    "icon": "🎨",
    "features": ["Logo variations", "Color palette", ...],
    "pricing": "From $475",
    "status": "published",
    "createdAt": "2026-06-18T14:30:00Z",
    "updatedAt": "2026-06-18T14:30:00Z"
  },
  "timestamp": "2026-06-18T14:35:00Z"
}
      

Setup Instructions

Create Express.js (or equivalent) server
Set up database connections
Implement all 15 endpoints above
Add authentication middleware (JWT validation)
Add error handling & validation
Test all endpoints with Postman or Insomnia
Add CORS headers for front-end access

Phase 3: Dashboard Frontend (Week 3)

Main Dashboard Views

Overview: Recent edits, publishing status, quick links
Tools Manager: Create/edit/delete service tools
Services Manager: Manage service categories
Content Calendar: 30-day schedule with edit inline
Users: Manage editor permissions (admin only)
Settings: Global configuration (admin only)

Key Features

Login/logout (JWT auth)
Role-based access control (Admin / Editor / Viewer)
Live preview of changes (connected to design system templates)
Bulk import (CSV for content calendar)
Publish/unpublish content
Version history (track changes)
Search across all content
Mobile-responsive dashboard

Setup Instructions

Create React app (Vite or Create React App)
Set up routing (React Router)
Create login page with JWT handling
Build 6 main dashboard views (above)
Wire up API calls to backend endpoints
Add form validation & error handling
Test authentication flow

Phase 4: Design System Integration (Week 4)

How Templates Connect

The design system's CMS-ready templates (ServicesIndex.dc.html, ToolDetail.dc.html) consume data from Barcelona via API:

// In your Design Component (DC):
<sc-for list="{{ tools }}" as="tool">
  <!-- renders each tool from /api/tools -->
</sc-for>

// Props passed from API:
{{ toolName }}        # from /api/tools/:slug
{{ features }}        # from /api/tools/:slug
{{ pricingDisplay }}  # from /api/tools/:slug
{{ faqs }}            # from /api/tools/:slug
      

Integration Checklist

Create an environment variable file (.env) with API base URL
In design system templates, fetch from /api/tools and /api/services
Set up auto-refresh (poll API every 30 seconds for live updates)
Add error handling for missing/invalid data
Test end-to-end: edit in CMS → see change in design system

Example Integration Code

// In ToolDetail.dc.html logic class:
async componentDidMount() {
  const slug = window.location.pathname.split('/').pop();
  const res = await fetch(`/api/tools/${slug}`);
  const { data } = await res.json();
  this.setState({ tool: data });
}

renderVals() {
  const { tool } = this.state;
  return {
    toolName: tool?.name || '',
    features: tool?.features || [],
    pricingDisplay: tool?.pricing || '',
    faqs: tool?.faqs || []
  };
}
      

Phase 5: Deployment & Launch (Week 5)

Deployment Checklist

Set up environment variables (API keys, database URLs, JWT secret)
Configure CORS to allow design system origin
Set up HTTPS (required for JWT auth)
Deploy backend (Vercel, Heroku, AWS)
Deploy frontend dashboard (Vercel, Netlify)
Deploy design system with API URL pointing to live backend
Test end-to-end in production
Set up monitoring & error tracking
Create admin account for yourself
Invite editors and set permissions

Post-Launch

Monitor API performance (response times)
Set up automated daily backups
Create user documentation (how to use dashboard)
Establish content review workflow
Plan content calendar (weekly meetings)

User Roles & Permissions

Role	Permissions
Admin	Create/edit/delete tools, services, users. View all. Change settings.
Editor	Create/edit content (tools, calendar). Can't delete. Can't manage users.
Viewer	Read-only access. See all content but can't make changes.

Data Flow Diagram

┌─────────────────┐
│  CMS Dashboard  │  (React frontend)
│   (Barcelona)   │
└────────┬────────┘
         │ POST/PUT/GET
         │
┌────────▼────────┐
│   Backend API   │  (Express.js)
│  /api/tools     │
│  /api/services  │
│  /api/calendar  │
└────────┬────────┘
         │ Read/Write
         │
┌────────▼────────┐
│    Database     │  (PostgreSQL)
│  - Tools        │
│  - Services     │
│  - Calendar     │
│  - Users        │
└────────────────┘
         ▲
         │ GET /api/tools/:slug
         │
┌────────┴────────┐
│  Design System  │
│  Templates      │  (Shows live data)
│  (Services,     │
│   Tools, etc)   │
└─────────────────┘
    

Timeline Summary

Week	Phase	Deliverables
1	Database Setup	5 collections, indexes, seed data
2	Backend API	15 endpoints, authentication, testing
3	Dashboard Frontend	6 main views, forms, validation
4	Design System Integration	Live API connections, end-to-end testing
5	Deployment & Launch	Live platform, user accounts, monitoring

Next Steps

Decide on tech stack (database, backend framework, hosting)
Start Phase 1: Database Setup (this week)
Once API is ready, I can build the dashboard UI mockup (jump to Phase 3)
Wire up design system templates to API (Phase 4)
Deploy to production (Phase 5)

Questions?

Ready to proceed? Next, I can create:

Complete CMS Dashboard UI mockup (interactive HTML/React)
Database schema (SQL file for your database setup)
API starter code (Node.js/Express boilerplate)
Integration code for design system templates