← Ideas ⚡ Arti Home

AI Site Editor — Architecture Options

Status: 📋 Spec Draft — Updated Apr 25, 2026


Three Architecture Options

Option 1: OpenClaw Per-Project Agent

How it works: Each project (BuildForce, Golf, etc.) gets its own OpenClaw agent with specific instructions scoped to that project's files. The authenticated user interacts with the agent through a chat widget embedded in the site.

Architecture:

User on bf.oc.beyond20.ca clicks edit widget
        ↓
Chat widget sends message to /api/edit endpoint
        ↓
API checks auth (OAuth cookie) + permissions (email → project mapping)
        ↓
API calls OpenClaw sessions_spawn with:
  - agentId: "bf-editor" (project-specific agent)
  - task: user's message
  - cwd: /var/www/sites/bf.oc.beyond20.ca/
        ↓
Agent edits files, git commits, returns result
        ↓
Widget shows result, page refreshes

Project agent config (AGENTS.md per project):

# bf-editor Agent
You edit BuildForce project sites.
- Only modify files in /var/www/sites/*.bf.oc.beyond20.ca/
- Only change content, text, styling — NOT scripts or config
- Always git commit changes with descriptive message
- Never modify auth, nginx, or system files
- Log all changes to /var/log/ai-edits/bf.json

Pros:

Cons:

Estimated build: 2-3 weeks


Option 2: GitHub Copilot Extensions / Copilot in the App

How it works: Use GitHub Copilot's extensibility to embed Copilot-powered editing directly in the site. GitHub recently launched Copilot Extensions that can be integrated into apps.

Architecture:

User on bf.oc.beyond20.ca clicks edit widget
        ↓
Widget opens a Copilot-powered chat panel
        ↓
Chat sends to a GitHub Copilot Extension endpoint (your server)
        ↓
Extension has access to the repo (sdkibb/BuildForce)
        ↓
Copilot generates the code change as a PR or direct commit
        ↓
Webhook triggers deploy to live site

How Copilot Extensions work:

Pros:

Cons:

Estimated build: 3-4 weeks (includes learning Copilot Extension API)


Option 3: Hybrid — Lightweight Edit API + LLM

How it works: A thin Python/Node API service on the server. Receives edit requests, sends the relevant file + user prompt to any LLM API (Copilot, Claude, GPT), validates the output, writes it back. No full agent framework — just targeted file edits.

Architecture:

User on bf.oc.beyond20.ca clicks edit widget
        ↓
Widget sends: POST /api/edit { site, page, prompt, user_email }
        ↓
API server (Python FastAPI):
  1. Verify OAuth cookie → get user email
  2. Check permissions.json: can this user edit this site?
  3. Read the target HTML file
  4. Build LLM prompt:
     "You are editing {filename} for BuildForce Canada.
      The user wants: {prompt}
      Rules: only change content/styling, preserve structure.
      Return the complete updated file."
  5. Call LLM API (GitHub Copilot API via token, or Claude/GPT)
  6. Validate output: same structure? no script injection? valid HTML?
  7. Write to staging path
  8. Return diff preview to widget
        ↓
User reviews in widget → confirms
        ↓
API copies staging to live, git commits

Pros:

Cons:

Estimated build: 1-2 weeks


Recommendation

Start with Option 3 (Hybrid) for these reasons:

  1. Fastest to build and ship
  2. Lowest risk — simple, predictable, easy to lock down
  3. Can evolve into Option 1 later by swapping the LLM call for an OpenClaw session_spawn
  4. The edit widget UI is the same regardless of backend — build that once

Phase plan:

User Management

For managing who's logged in and where — add a session tracking table to the homepage dashboard:

/api/sessions → returns:
{
  "active": [
    { "email": "seankibbee@gmail.com", "site": "bf.oc.beyond20.ca", "since": "2026-04-25T08:30:00", "edits": 3 },
    { "email": "jane@buildforce.ca", "site": "web.bf.oc.beyond20.ca", "since": "2026-04-25T09:15:00", "edits": 0 }
  ]
}

Display as a "Who's Online" card on the admin dashboard. Shows active sessions, which sites they're on, how many edits they've made. Admin can revoke sessions.

Open Questions