CHC protected workspace

CHC Sasha-Agent Workspace

This is CHC’s primary Sasha-Agent operating surface: a walled-in workspace for web development, marketing, platform building, business admin, and day-to-day execution.

CHC-scoped on the surface. Canonical continuity underneath.

Primary interaction lane

Interactive CHC chat window

This panel is the intended front door for CHC’s ongoing work with Sasha-Agent. The final version should support real two-way interaction here inside the protected workspace.

Sasha-Agent CHC workspace mode
Sasha-Agent

Welcome to the CHC workspace. This lane is for CHC business work only: website updates, marketing, systems, admin/help-desk support, and business operations.

MVP interaction contract

The first shippable loop is request capture plus recent request/status reflection. This page will expose a narrow CHC request API shape rather than pretending to be full live chat before that exists.

Planned MVP contract: POST /api/chc/request, GET /api/chc/requests, and GET /api/chc/health through the browser-safe CHC intermediary.

Current workspace role

What this workspace is for

  • CHC website development and deployment
  • Marketing copy, offers, and landing-page refinement
  • Platform and business-system building
  • Admin/help-desk style support for CHC operations
  • Task follow-through and progress visibility
Current phase Dedicated workspace + access hardening + bridge rollout
Auth posture Cloudflare Access allowlist, 8h session, binding cookie enabled
Next implementation move Complete the browser-safe intermediary for request capture and recent status reflection

Active work areas

The four core operating lanes

Lane 1

Website + deployment

Homepage updates, pricing, forms, conversions, deploys, ops page changes, and technical fixes.

Lane 2

Marketing + messaging

Offer clarity, copywriting, lead capture, campaign ideas, positioning, and business messaging.

Lane 3

Systems + platform

Lead intake, contact records, workflow tooling, automation, voicemail/email flow, and business infrastructure.

Lane 4

Admin + help desk

Questions, support, operating clarifications, requests, follow-up, and day-to-day business assistance.

Scope guardrails

This workspace is intentionally walled in

  • CHC-only scope: business operations, website work, marketing, systems, and CHC admin.
  • No unrelated bleed: this surface should not absorb Marcus’s unrelated private/admin/operator context.
  • Tammy access model: full access to CHC business work does not imply global Marcus-world assistant access.
  • Protected front door: this workspace stays behind explicit Cloudflare Access controls.
  • Execution over chatter: meaningful work should be done, tracked, and reflected — not just discussed.

Continuity rules

How work here should flow

  1. Work begins in the CHC workspace interaction lane.
  2. Meaningful progress is logged locally into canonical continuity and task records.
  3. Important status, current priorities, and business-facing progress are reflected back into this ops surface.

The goal is one CHC lane, one continuity spine, and no Telegram-style split-brain workflow.

Recent CHC requests

Protected local request log

Sasha · 2026-04-01, 11:53:38 a.m.

Intermediary forwarding test

Status: logged through the CHC intermediary into the hardened local CHC request store

Current build state

Phase 2 is now a real bridge-backed rollout

  • Auth/perimeter has been tightened first.
  • The CHC ops surface now lives in a dedicated ops project.
  • A local CHC workspace bridge is live at 127.0.0.1:4314.
  • The bridge is now narrowed with origin restriction and shared-token support.
  • A separate CHC intermediary now forwards request/status semantics successfully to the local bridge.
  • Requests are durably writable into data/chc-workspace/requests.json.
  • Next step: wire this protected page into that working intermediary path cleanly.

How the interaction path works

Protected UI to local continuity

  1. Work starts in the protected CHC workspace.
  2. Requests flow into the local CHC bridge service.
  3. The bridge writes durable entries into the canonical local CHC request log.
  4. Recent work/status is then reflected back into the protected workspace.

What comes next

Immediate implementation priorities

  • Finish the browser-safe intermediary contract for CHC request capture
  • Render recent requests and status cleanly from the canonical local CHC log path
  • Add task/status modules that reflect real CHC execution state
  • Keep the workspace easy for Tammy while preserving CHC-only boundaries