Alfred — Audit Notes (Living)

Comprehensive no-code stabilization checklist (interactive)

This is a comprehensive checklist of actions that improve foundations without changing Alfred’s code. It focuses on visibility, backup/safety, deployment hygiene, workspace legibility, and reducing “unknown unknowns”.

Export / Import checklist progress

localStorage

Progress + notes are stored in your browser (localStorage). Use export/import to move progress between devices/browsers.

Export

Import

Executive summary

SSH access is working: I can log into Alfred’s machine as techteam over LAN.
Main cause of the “.docx upload page says error/not found”: Alfred does have an upload UI (/p/upload), but the running agent-orchestrator container appears to be on an older build that does not include the upload routes the UI expects (/api/upload, /api/uploads, /uploads).
Very important nuance: in Alfred’s source repo (oc-bot-refactor), cloud/services/agent-orchestrator/main.py does define those upload routes — but the container’s baked /app/main.py does not contain them. That strongly suggests “source has the fix, but it was never rebuilt/deployed”.
Secondary cause (subtle): the upload UI “auto-detects” the upload endpoint by treating any non-404 response as “route exists”. Alfred’s auth middleware often returns 403 for gated/unknown paths before routing, so the page incorrectly concludes /api/upload “exists” and then POSTs to a guaranteed-fail path.
Alfred is multi-surface: Docker orchestrator (alfredhottakes.com) + a voice server (voice.alfredhottakes.com) + an API server (api.alfredhottakes.com). That’s flexible, but it increases “page points at wrong backend” failure modes.
Current constraint: Matt requested “no changes for now”, so this page is a comprehensive list of architectural differences + redundancies + issues that are fixable later.

Why Alfred sometimes says things that aren’t true (and “echo back my texts” fails)

The transcript you shared shows multiple different failure modes that look like “memory issues”, but are usually a mix of: message delivery quirks, split services, and the model confabulating when it lacks ground truth.

1) “I replied earlier but you didn’t receive it”

Real-world iMessage/SMS behavior: replies can drop on Apple’s side, or show in a different thread (1:1 vs group) even when the sender believes it sent.
Bot-side behavior: Alfred may log “sent” when it queued a send request, not when the carrier/device actually delivered it.
Why PING/PONG worked: delivery can be intermittent; a later message can succeed even if an earlier one dropped.

2) “Not yet — you’re Unknown” even for the same number

Normalization bugs: different surfaces can see the sender as +1831..., 1831..., tel:+1831..., etc.
State sticking: once a conversation header is created as “Unknown”, some systems keep that label until explicitly migrated.
Why this happens more on Alfred: Alfred is multi-surface (orchestrator + legacy voice gateway + other services). Each can apply different normalization rules unless centralized.

3) The big one: Alfred “claims it patched / restarted / wired things”

Confabulation: when the model is asked “did you do X?” it may generate a plausible action narrative (patch, restart, verified) even if no tool/action actually occurred.
Deployment drift amplifies this: Alfred can have “source code contains fix” while the running container does not. In that situation, the model may truthfully read code and then wrongly assume it’s deployed.
Cross-session ambiguity: if Alfred doesn’t have a hard audit trail tied to each reply, it can’t reliably distinguish “plan”, “attempt”, “success”, and “deployed”.

4) “Echo back my last texts” failures

Context window vs storage: Alfred can see the recent chat in-context, but older messages may not be persisted in an accessible log, or the log may omit parts (links/attachments) due to how ingestion stores them.
Multiple channels: if some messages arrived via iMessage, some via a web UI, and some via another surface, the “authoritative log” might be split.
Result: Alfred can accurately summarize, but can’t always quote verbatim or retrieve a specific prior line unless it’s stored.

What to do about it (no-code mitigations)

Require evidence in replies: whenever Alfred claims an action (“I restarted”, “I stored a token”, “6/6 returned 200”), have it include a short evidence blob (request ID, timestamp, URL hit, status code).
Distinguish 4 states: “planned”, “attempted”, “succeeded”, “deployed”. Alfred should never say “deployed” without an explicit redeploy step.
Use the interactive checklist above: treat “snapshot / backup / drift verify” as gating steps before trusting action claims.

What’s running on Alfred (high signal)

Hostname	Local target	Purpose	Notes
`alfredhottakes.com` `bot.alfredhottakes.com`	`localhost:8887`	Docker container `agent-orchestrator` (ports `8887 → 8787`)	/p/sitemap is public (200). Many API endpoints are gated (403) unless authenticated.
`voice.alfredhottakes.com`	`localhost:8788`	Uvicorn app (`malli/server.py`)	/docs is open (200) but it’s not the pages/upload host.
`api.alfredhottakes.com`	`localhost:8042`	Another Uvicorn app (`main:app`)	Not serving `/p/*` pages; appears to be API-only.

Ground-truth snapshot (collected via SSH; no changes made)

Cloudflare tunnel ingress (Alfred)

~/.cloudflared/config.yml
- alfredhottakes.com  → http://localhost:8887
- bot.alfredhottakes.com → http://localhost:8887
- voice.alfredhottakes.com → http://localhost:8788
- api.alfredhottakes.com → http://localhost:8042

Docker Compose source of truth (agent-orchestrator)

compose working dir:
  oc-bot-refactor/cloud/services/agent-orchestrator/
compose files:
  docker-compose.yml
  docker-compose.override.yml
env file:
  oc-bot-refactor/.env

Container mounts (agent-orchestrator)

- oc-bot-refactor/local → /workspace
  (so host local/pages is container /workspace/pages)
- cloud/services/agent-orchestrator/data → /app/data
- oc-bot-refactor/logs → /logs
- oc-bot-refactor/local/context → /workspace/context
- plus campaign + malli mounts

Upload UI file location (host)

oc-bot-refactor/local/pages/upload.html

Workspace architecture map (Alfred) — what everything is + what to do with it

This is the “make the repo readable again” section. Alfred currently has two separate repos on disk: oc-bot-refactor (newer orchestrator architecture) and oc-bot (older/legacy stack). The biggest source of confusion is that production-facing services pull from both.

0A) Cursor vs Finder vs “what’s running” (why you don’t see `oc-bot` in Cursor)

Cursor only shows the folder(s) you opened as the workspace. If you opened oc-bot-refactor, Cursor will not automatically show sibling folders like oc-bot unless you add them to the workspace.
That does not mean the other repo isn’t used. Services can run from any folder on disk regardless of what Cursor has open.
Ground truth from Alfred’s running processes (observed via SSH):
- voice.alfredhottakes.com is a host-run Uvicorn process whose working directory is /Users/techteam/oc-bot (so oc-bot is actively used today).
- alfredhottakes.com is the Docker agent-orchestrator built from /Users/techteam/oc-bot-refactor.
Practical takeaway: to “clean up,” we need to treat Alfred’s machine as a deployment environment, not just a Cursor folder. The cleanup plan should be based on what’s running + what state is needed.

0) First principle (recommended cleanup goal)

Choose one canonical repo for Alfred’s core web surface (pages + auth + uploads + orchestration). Based on what’s running today, that’s oc-bot-refactor.
Treat the other repo as “legacy support” until you intentionally migrate remaining live services (notably Twilio voice/SMS) into the canonical repo.
Separate code vs state: Alfred has a lot of “stateful” folders living inside repo trees (conversations, attachments, sqlite DBs). That’s workable, but it must be explicit (gitignored, backed up, and easy to locate).

0B) Naming goals (make it “Alfred” without breaking macOS)

Strong recommendation: do not change the macOS username or iCloud Apple ID as part of this cleanup. It’s high-risk and low-return for bot reliability.
Safer path: rename at the application/config layer first:
- Agent branding: AGENT_NAME=Alfred, domain variables, page titles, and UI copy.
- Repo naming: rename the repo folder on disk later (e.g. oc-bot-refactor → alfred) only after deployment is stable; optionally keep a symlink for compatibility.
- Service names: keep the Docker service name agent-orchestrator if it’s already wired everywhere; “pretty names” can be layered on in UI/docs.

1) Repo A: `/Users/techteam/oc-bot-refactor` (new / canonical)

Size snapshot (approx): dashboard/ ~173MB, local/ ~129MB, logs/ ~17MB. Empty/placeholder files found: ~75 (most are virtualenv artifacts under local/services/.venv).

Why there are “loose files” at the repo root (and what to do)

Common root files you’ll see in Cursor (oc-bot-refactor):
- .env / .env.example      env config for services (keep; make sure secrets aren’t committed)
- README.md / CONTEXT.md / MALLI_ROADMAP.md  documentation (keep)
- package.json / package-lock.json           dashboard deps (keep)
- tools.json / mcp-servers.json / memory.json  agent/tool registry + memory (keep; consider consolidating docs)

If a root file is empty or mysterious:
- treat it as suspect until you know who reads it (search references before deleting)
- prefer moving runtime state into local/context or service data dirs, not root.

Path	What it is	Actively used?	Recommendation	Why / how (later)
`cloud/services/agent-orchestrator/`	Main Alfred portal/orchestrator FastAPI service (Docker image build context).	Yes (serves `alfredhottakes.com`).	KEEP (core).	Make this the single owner of pages + uploads + auth. When we “fix Alfred”, most changes should land here.
`cloud/services/agent-orchestrator/main.py`	The orchestrator app entrypoint (huge; owns routes, auth middleware, pipeline wiring).	Yes (source-of-truth), but deployed container may be behind.	CHANGE (deploy hygiene).	Ensure the running container’s `/app/main.py` matches this file (rebuild/redeploy later). Add a version stamp endpoint to detect drift.
`cloud/services/agent-orchestrator/pipeline/`	Core pipeline modules: auth, identity, history, send, tools, tasks, etc.	Yes.	KEEP.	This is the “brains” of the orchestrator. Prefer refactors here over spawning new services.
`cloud/services/agent-orchestrator/portal/`	HTML portal UI (login/dashboard pages served by orchestrator).	Yes.	KEEP.	Central place for “operator UX”. If pages feel confusing, improve these instead of adding more ad-hoc pages.
`cloud/services/agent-orchestrator/data/`	Stateful storage: identity sqlite/dbs, visitors, prompt audits, processed GUIDs.	Yes.	LEAVE ALONE (but document).	Do not delete casually. Later: make a clear backup/rotation policy; consider moving to a dedicated state directory outside the repo tree.
`local/`	Host-mounted workspace data + pages + modes + local services.	Yes (mounted into Docker as `/workspace`).	KEEP (but organize).	Think of `local/` as “runtime workspace”, not product code. Later: tighten which subfolders are “state” vs “config” vs “UX pages”.
`local/pages/`	Public/operator HTML pages (includes `upload.html`).	Yes.	CHANGE (align contracts).	Keep pages, but remove brittle endpoint auto-detection and align to the deployed API surface.
`local/context/`	Stateful conversations + attachments + runner progress.	Yes (core bot memory).	LEAVE ALONE (but fence it).	Do not delete casually. Later: ensure it’s gitignored + backed up; optionally relocate to a dedicated data volume outside repo.
`local/services/cursor-runner/`	“Hardened runner” service (runs agent jobs; orchestrator prefers it).	Yes (called by orchestrator).	KEEP.	Good separation: runner can be sandboxed and scaled later.
`local/services/agent-server/`	Decision-tree / fallback agent service.	Yes (configured fallback).	KEEP (but consider deprecating later).	If `cursor-runner` is stable, you may phase this out to reduce moving parts.
`local/services/rv-park-finder/`	Standalone “RV Park Finder” FastAPI microservice (port 8042).	Yes (serves `api.alfredhottakes.com`).	MOVE / ISOLATE.	It’s not part of Alfred’s basic UX; it can consume resources. Later: move to cloud or separate host; keep the API stable.
`local/services/.venv/`	Checked-in local Python virtualenv for host-run services.	No (not “source of truth”; it’s generated).	DELETE (cleanup) once we confirm nothing is hard-pinned to it.	This is a major repo-noise source and explains many “empty files”. Later: remove the venv dir, ensure it’s ignored, and reinstall from `requirements.txt`.
`dashboard/`	Next.js dashboard frontend.	Unknown (exists in compose, but not mapped in current Cloudflare ingress).	KEEP (for now).	Later: either properly publish it under a hostname or remove it from the default “prod” compose to reduce noise.
`whatsapp-bridge/`	WhatsApp Web bridge service (Baileys).	Unknown (present in compose; not confirmed live).	KEEP (for now).	Later: only run in environments where WhatsApp is actively needed; otherwise disable to reduce surface area.
`logs/`	Runtime logs directory mounted into containers.	Yes.	KEEP (but rotate).	Add log rotation + size caps; don’t keep unbounded logs inside the repo forever.
`.venv-*`, `.pytest_cache/`, `__pycache__/`, `tmp/`, `graphify-out/`	Local caches/build artifacts.	No (not required for runtime correctness).	DELETE (safe cleanup).	Later: remove locally + ensure ignored. This is the fastest “workspace sanity” win with minimal risk.

2) Repo B: `/Users/techteam/oc-bot` (legacy / still powering Twilio)

Size snapshot (approx): imessage-bridge/ ~888MB, installer/ ~147MB, vercel/ ~156MB, malli/ ~35MB. Empty/placeholder files found: ~433 (overwhelmingly in imessage-bridge/.venv).

Path	What it is	Actively used?	Recommendation	Why / how (later)
`malli/server.py`	Twilio voice/SMS gateway + Malli persona/queue endpoints.	Yes (serves `voice.alfredhottakes.com`).	KEEP (temporarily).	This is “live legacy”. Later: migrate the Twilio surface into `oc-bot-refactor` (or at least unify identity/auth + upload conventions).
`imessage-bridge/`, `messages-bridge/`	Older bridge stacks (iMessage/other messaging surfaces).	Unknown (not confirmed in current Cloudflare ingress).	ARCHIVE / DEPRECATE (if unused).	Later: confirm whether any Alfred surfaces still depend on them; if not, move to an `archive/` folder or separate repo to reduce cognitive load.
`imessage-bridge/.venv/`	Committed Python virtualenv inside the legacy repo.	No (generated).	DELETE (cleanup) once confirmed unused.	This is the single biggest “clutter amplifier” (hundreds of empty REQUESTED/py.typed marker files). Replace with `requirements.txt` + recreate on demand.
`.pycache/`	Unusual cache tree that mirrors absolute paths (e.g. `.pycache/Users/...`).	No (generated).	DELETE (safe cleanup).	It’s almost certainly a cache directory produced by a nonstandard pycache prefix config. Later: delete and add ignore rules; check env like `PYTHONPYCACHEPREFIX`.
`vercel/`	Frontend build/deploy artifacts.	Unknown (likely generated).	DELETE (cleanup) if not actively used.	If nothing is serving from it, it’s pure noise. Later: delete and ensure build output dirs are ignored.
`node_modules/`, `dist/`, `.pnpm-store/`	JS build artifacts/deps.	Maybe (depends on whether legacy frontends are used).	DO NOT TOUCH blindly.	Later: if legacy web frontend isn’t used, remove + regenerate on demand; otherwise keep but ensure it’s not tracked in git.
`pages/`	Legacy HTML pages for the old stack.	Unknown.	ARCHIVE (if unused).	Later: extract any still-valuable content into `oc-bot-refactor/local/pages` and deprecate the rest.
`database/`, `data/`, `agent_data/`, `logs/`	Legacy state directories.	Possibly.	LEAVE ALONE until proven safe.	Later: identify which state is still referenced by running processes; migrate it into the new state layout if needed.

3) “How do we clean this up without breaking progress?” (recommended approach)

Inventory what is actually live: for each public hostname, record the PID/container + working directory + git commit hash (where possible).
Mark state directories as sacred: local/context, cloud/services/agent-orchestrator/data, legacy oc-bot state dirs. Back up before any reorg.
Delete only safe artifacts first: caches, tmp/, __pycache__/, stray venvs, build outputs — the stuff that never should have been in the “mental model”.
Then consolidate repo split-brain: migrate Twilio gateway into oc-bot-refactor (or at minimum unify config/auth and keep it as a clearly named “gateway” service).

4) How to merge toward “one optimized Alfred” (without intense architectural changes yet)

Define the canonical “contracts” in oc-bot-refactor: uploads API, where files land, how pages call APIs, how auth works, where context lives.
Bring Twilio/voice into the canonical repo in the least disruptive way: either move oc-bot/malli/server.py into oc-bot-refactor as a dedicated service, or keep it as a separate service but with a versioned interface and shared identity/auth conventions.
Isolate unrelated product microservices (e.g. RV Park Finder) so Alfred’s core UX doesn’t degrade when product jobs spike.
Only then consider deeper refactors (single-hostname “front door”, collapsing services, cloud migration, etc.).

What are the “three servers” on Alfred? (purpose + redundancy assessment)

When you say “three servers”, you’re seeing three different FastAPI apps exposed through Cloudflare under three hostnames. They are not redundant copies; each has a different responsibility. The confusing part is they also span two different repos (oc-bot-refactor and oc-bot), which strongly suggests a migration was mid-flight.

A) Public surfaces (Cloudflare hostnames → local ports)

Public hostname	Local port	Running process	What it does (evidence)	Redundancy
`alfredhottakes.com` `bot.alfredhottakes.com`	`8887`	Docker `agent-orchestrator` (container port `8787`)	Pages + auth + orchestration layer. Docker Compose config pins: `PAGES_ROOT=/workspace/pages`, `CONTEXT_ROOT=/workspace/context`. This is the “main” Alfred web surface people hit.	Not redundant; it’s the portal/orchestrator.
`voice.alfredhottakes.com`	`8788` (bound to `127.0.0.1`)	`python -m uvicorn malli.server:app`	OpenAPI title: “Alfred Twilio Pipeline”. Exposes Twilio SMS/voice endpoints and Malli persona endpoints (e.g. `/twilio/sms`, `/twilio/voice/*`, `/malli/persona`, queue/followup runners). The codebase for this process lives under `/Users/techteam/oc-bot` (older repo) and loads a hot-reloaded `pipeline.json` from that directory.	Not redundant; it’s the Twilio/voice/SMS gateway. It is architecturally “separate” and currently split from orchestrator.
`api.alfredhottakes.com`	`8042` (bound to `0.0.0.0`)	`python -m uvicorn main:app`	OpenAPI title: “RV Park Finder”. Endpoints are deal-sourcing specific: `/rv-parks/search`, `/brokers/search`, `/ingest/run`. Process cwd is `oc-bot-refactor/local/services/rv-park-finder`.	Not redundant; it’s a separate product microservice. It is optional to Alfred’s “chat/upload” UX but competes for machine resources.

B) Internal helper services (called by orchestrator)

Alfred’s orchestrator is configured to call two more local services (not currently exposed via Cloudflare in the ingress shown above):

cursor-runner (port 8791): OpenAPI title “Cursor Runner” with /run, /cancel, /health, and a pages route. This is the “hardened runner” the orchestrator prefers (PREFER_CURSOR_RUNNER=1).
agent-server (port 8792): OpenAPI title “Agent Server” with conversation + mode routing endpoints (/modes, /pipeline/reload, /run, etc.). This appears to be a fallback/decision-tree server.

C) So… is having 3 public apps “necessary”?

Reasonable / intentional: separating the Twilio/voice gateway from the orchestrator can be a good idea (different security posture, realtime/streaming concerns, separate scaling).
Probably incidental / migration artifact: the fact that voice/twilio is running from oc-bot while orchestrator is running from oc-bot-refactor is a classic “mid-migration split-brain” smell. It’s likely Nathan was partway through moving capabilities into the orchestrator pattern.
Optional microservice: RV Park Finder being on the same box is fine, but it’s unrelated to the upload UX and adds operational load/attack surface. Long-term it probably belongs in “cloud app land” (or a separate host) so Alfred’s core doesn’t regress when RV ingest spikes.

D) Why this topology can make Alfred feel “lobotomized” or flaky

Split repos (oc-bot vs oc-bot-refactor): fixes/feature additions can land in the “wrong” codebase and never reach the public surface you’re using.
Split hostnames: cookies/auth and CORS policies differ per hostname; a UI can load but POST to an endpoint that’s missing or gated on that hostname.
Route existence is masked by auth: Alfred returns 403 in ways that make naive “is this route available?” checks unreliable (this directly breaks the current upload page’s auto-detection logic).
More moving pieces: more processes to restart, more logs, more “which service owns this feature?” ambiguity.

Why your upload UI is failing

Observed behavior

alfredhottakes.com/p/sitemap returns 200 (public).
/api/pages and /api/page-search exist but return 403 without auth (expected; these back the sitemap’s search).
Upload-related pages/routes on the public host return 403 (gated) or 404 (not implemented) depending on URL + auth state.
Deployment drift: Alfred’s source repo defines upload routes in oc-bot-refactor/cloud/services/agent-orchestrator/main.py, but the running container’s baked /app/main.py does not contain those routes. So from the public site’s perspective, the upload endpoints are “missing”.
Upload UI exists but can’t succeed: Alfred’s upload page (file: oc-bot-refactor/local/pages/upload.html) posts to one of /api/upload, /api/uploads, or /uploads and expects list/download/delete helpers. Until the orchestrator container is rebuilt/redeployed (and ACLs aligned), uploads will keep failing.

Practical implication

If you were given a page that posts to /uploads (legacy) or /api/upload (Jarvis-style), it will fail unless the alfredhottakes.com backend implements that exact endpoint in the deployed container. Today, it appears the deployed container is behind the source repo, so “not found / error” is expected even if the repo contains the code.

Core architectural differences: Jarvis vs Alfred (what’s intentional vs accidental)

This is the “why Alfred trips over basics” section. The short version: Jarvis is closer to a single, coherent monolith, while Alfred is an orchestrator + multiple microservices with a legacy sidecar (the Twilio pipeline in oc-bot) and at least one unrelated product service (RV Park Finder). That’s not inherently bad, but it requires stricter contracts and better observability.

1) Monolith vs orchestrator graph

Jarvis: one primary FastAPI app owns pages + APIs + uploads end-to-end, so “UI route ↔ API route” alignment is easy.
Alfred: the “main” surface is agent-orchestrator (Docker) which then calls helper services (cursor-runner, agent-server), while Twilio voice/SMS is a separate app and RV Park Finder is another separate app.
Likely issue driver: more hops means more places for a missing route, ACL mismatch, or config drift to break a user-facing feature.
Intentional vs accidental: orchestrator + runner separation looks intentional; the split between oc-bot and oc-bot-refactor looks accidental/migration-in-progress.

2) Repo split-brain (highest-signal “testing grounds” smell)

Alfred: Twilio/voice pipeline runs from /Users/techteam/oc-bot (legacy). Orchestrator + runner services live under /Users/techteam/oc-bot-refactor (new).
Likely issue driver: a feature can be “implemented” in one repo and never show up in the surface you’re using (or vice versa). This also makes “who owns uploads?” ambiguous.
Why it might exist: very consistent with Nathan migrating functionality into the new orchestrator architecture while keeping the Twilio gateway stable.

3) Hostname/port split (and cookie/auth implications)

Jarvis: fewer hostnames → fewer cookie domains → fewer CORS/auth edge cases.
Alfred: alfredhottakes.com, voice.alfredhottakes.com, api.alfredhottakes.com route to different apps.
Likely issue driver: UIs and API calls can silently cross the wrong “surface” (or be blocked), especially when endpoints are assumed to exist everywhere.
Intentional vs accidental: separating “voice” is reasonable; separating RV Park Finder is reasonable; but sharing one box without strong contracts/logs increases incidents.

4) Security posture differences (403-before-routing)

Jarvis: tends to have explicit public slugs and straightforward auth gates.
Alfred: often returns 403 early for non-whitelisted paths, which can happen before the router decides if a route exists.
Likely issue driver: breaks “endpoint detection” heuristics and makes debugging by HTTP status misleading. This is directly implicated in the upload page’s failure mode.
Intentional vs accidental: the strict gate is intentional; the upload UI’s “non-404 means exists” heuristic is accidental/brittle.

5) Mutable runtime vs release-driven runtime

Alfred orchestrator: has a hybrid runtime:
- Mounted: local → /workspace (pages, modes, context) can change immediately with host edits.
- Baked: the actual FastAPI server code lives under /app inside the container image and only changes after a rebuild/redeploy.
Likely issue driver: great for rapid testing, but “prod-like” stability suffers unless changes are tracked and validated.
Intentional vs accidental: likely intentional for dev velocity (“testing grounds”), but it needs guardrails for reliability.

6) Resource contention / unrelated workloads

Alfred: runs at least one unrelated microservice (RV Park Finder) alongside the bot stack.
Likely issue driver: ingest jobs or bursts can steal CPU/RAM/IO from the orchestrator and make Alfred feel slow or unreliable.
Intentional vs accidental: intentional to colocate early prototypes, but long-term a strong candidate to move “into the cloud” first.

Comprehensive architecture differences + redundancies + fixable issues

Organized by subsystem. Each item is fixable later; we are not executing changes right now.

1) Service topology (single-server vs multi-surface)

Jarvis: one dominant web server (FastAPI bridge) that serves pages + APIs + uploads from one origin/port.
Alfred: at least three surfaces: alfredhottakes.com (Docker orchestrator), voice.alfredhottakes.com (voice Uvicorn), api.alfredhottakes.com (API Uvicorn).
Issue: higher probability of “page renders, but POST goes to missing endpoint” when UI + API are split.
Fixable: standardize which surface owns uploads/pages, or add deliberate reverse-proxying between surfaces.

2) Cloudflare Tunnel routing complexity

Alfred tunnel split: different hostnames route to different local ports (8887 / 8788 / 8042).
Observed redundancy: Alfred has multiple simultaneous cloudflared tunnel ... run processes for his primary tunnel config, plus multiple BlueBubbles-managed cloudflared tunnel --url localhost:1234 processes.
Issue: redundant tunnel processes increases “intermittent” failure modes and makes config debugging ambiguous.
Issue: cookies/auth are tied to hostnames; split surfaces complicate auth UX and debugging.
Fixable: collapse to one origin where possible, or implement a single “front door” hostname that reverse-proxies internally.

3) Auth model and operational friction

Jarvis: simple one-time links and public slug allowlist; easy to share “upload here” links.
Alfred: identity store + portal/access cookies; most endpoints return 403 without an authenticated identity.
Issue: if upload page is gated, users must complete auth flow first or they see 403 and assume “broken”.
Fixable: dedicated upload flow: either make /p/upload public with strong limits, or generate one-tap auth links that redirect into the upload page.

4) Pages system and page index

Alfred: sitemap HTML loads pages via /api/pages (currently gated 403 without auth), but /p/sitemap itself is public.
Issue: public sitemap can be partially “non-functional” (no list) if the backing JSON is gated.
Fixable: make /api/pages public-read (safe fields only) or embed the page list at build time.

5) Upload pipeline gap (root cause of DOCX pain)

Jarvis: has POST /api/upload to store arbitrary files and returns saved_to.
Alfred orchestrator (deployed container): the running agent-orchestrator container’s baked /app/main.py does not contain /uploads / /api/upload(s) routes (even though the UI expects them).
Alfred orchestrator (source code): Alfred’s source repo oc-bot-refactor/cloud/services/agent-orchestrator/main.py does define /uploads / /api/upload(s) routes, which implies the container image is behind source (needs rebuild/redeploy later).
Issue: the current upload UI picks a base endpoint by checking “not 404”. Alfred will return 403 for unauthenticated/gated paths even when the route doesn’t exist, so the UI “locks onto” a non-existent endpoint.
Fixable:
- Add one canonical upload API (recommended: POST /api/upload + GET /api/uploads + download/delete helpers) to the agent-orchestrator app.
- Update the upload UI to call only the canonical API (remove the auto-detect heuristic).
- Actually deploy it: rebuild/restart the container so /app/main.py matches the repo version.
- Decide gating: public + strict limits, or “signed auth-link” redirect then upload.

6) Container/volume layout (where state actually lives)

Agent-orchestrator runs via Docker Compose from oc-bot-refactor/cloud/services/agent-orchestrator/docker-compose.yml (+ override).
Key mounts observed:
- oc-bot-refactor/local → /workspace (so /workspace/pages is host local/pages).
- cloud/services/agent-orchestrator/data → /app/data (durable app data).
- oc-bot-refactor/logs → /logs
- oc-bot-refactor/local/context → /workspace/context
Issue: without one documented “upload destination”, files may land in inconsistent paths (host vs container), making ingestion brittle.
Fixable: pick and document a single host-backed upload destination and have the API return it explicitly.

7) Dependency/runtime drift

Jarvis: bridge stability depends on restarting with the correct Python runtime (multipart is required for several routes).
Alfred: host Python + Docker Python; different deps and behaviors per surface.
Important nuance: Alfred’s orchestrator dependencies already include python-multipart. So the likely root cause is deployment drift (container build behind source) plus route/ACL alignment, not “multipart isn’t installed”.
Issue: fixes applied to one runtime don’t automatically affect the other; “it works on voice but not on bot domain”.
Fixable: pin runtime per surface and add startup self-checks for critical features (upload, auth, pages).

8) Route existence vs auth ambiguity

Pattern: Alfred can return 403 before routing for paths that aren’t whitelisted/public, even if they don’t exist.
Issue: UIs that use “status != 404” to infer route existence will misbehave under this security model.
Fixable: add a small, safe /api/capabilities endpoint (public-read) or make the upload UI use a single known endpoint only.

9) Redundancy and failure modes

Issue: if the orchestrator container or tunnel dies, the public site is down.
Fixable: run multiple tunnel connectors (HA), and/or static-host brochure pages outside the tunnel while keeping APIs tunneled.

10) Secrets + configuration sprawl

Observation: Alfred injects a large env surface (dozens of keys) into the orchestrator container via Docker Compose .env.
Issue: the more secrets sit in a single .env, the harder it is to rotate/limit blast radius; it also increases “oops, logged env” risk.
Fixable: move to a structured secrets store (or a secrets manager), split by subsystem (tunnel vs messaging vs LLM vs pipeline), and redact env printing in diagnostics.

11) Upload UX claims vs infra realities

Observation: Alfred’s /p/upload page claims “Up to 2 GB per file, 7-day retention”.
Issue: Cloudflare + FastAPI default limits/timeouts rarely support 2GB uploads without explicit tuning (streaming, chunking, timeout config). “7-day retention” also implies a cleanup job that doesn’t currently exist in the visible API.
Fixable: implement chunked uploads or signed direct-to-object-storage uploads, enforce max size, and add a scheduled cleanup worker.

12) Storage + ingestion are not defined for DOCX

Issue: even with a working upload endpoint, Alfred still needs a defined ingestion step for .docx (extract text, store, index, attach to a job/conversation).
Fixable: add a “post-upload hook” that detects document types and extracts text (docx→text), then stores both the raw file and extracted text with a stable ID.

13) Public pages allowlist mismatch

Observation: Alfred’s site makes /p/sitemap public, but /p/upload (and upload APIs) are not reliably usable without auth + correct whitelisting.
Issue: when a page exists but is gated, users interpret 403 as “broken” rather than “requires login”.
Fixable: either make upload explicitly public with rate limits + per-link tokens, or provide a dedicated “upload link generator” that creates one-tap authenticated sessions.

14) Observability gaps

Issue: diagnosing failures requires SSH + Docker + knowledge of which hostname maps to which service.
Fixable: add a “single pane” status page that reports: active tunnel routes, effective ports, auth mode, available APIs, upload destination path, and last N errors.

15) Coupling between projects (oc-bot-refactor vs agent-orchestrator)

Observation: Alfred’s orchestrator container mounts the entire oc-bot-refactor/local tree into /workspace, so runtime behavior can change with host file edits.
Issue: “mutable runtime” is powerful but makes reproducibility harder (a hot edit can break prod without a deploy record).
Fixable: move toward image-based deploys for production, with explicit releases; keep live-mounted dev mode as an opt-in.

16) Security hardening opportunities

Issue: a generic upload endpoint, if made public, is an abuse magnet (storage exhaustion, malware, SSRF via “upload-from-url”, etc.).
Fixable: enforce per-link tokens, per-IP rate limits, content-type allowlists, max sizes, virus scanning (optional), and store uploads outside the web root.

Fix queue (doable later; not executed now)

Standardize uploads: implement POST /api/upload on Alfred’s orchestrator + matching /p/upload UI.
Make it usable: either add upload to PUBLIC_PAGE_SLUGS (rate-limited) or provide one-tap auth redirect to upload.
Remove upload endpoint auto-detect: make the UI call only the canonical endpoint (or consult a /api/capabilities contract).
Unify “front door”: reduce split surfaces by proxying pages+uploads behind one hostname.
Observability: add a status page that prints hostname→port mapping + last errors + upload destinations.
Runtime hardening: prevent restarts from switching Python/env unexpectedly; verify multipart/upload dependencies at startup.
Tunnel process hygiene: converge to one managed tunnel runner (avoid multiple simultaneous cloudflared ... run processes for the same config).
Large-file readiness: implement size limits + chunking (or direct-to-object-storage uploads) before promising multi-GB uploads publicly.

Notes on “why Jarvis works better” (early signals)

Single, consistent upload contract: Jarvis uses POST /api/upload and the UI posts to that exact endpoint.
Fewer “multi-service” mismatches: Alfred currently routes different subdomains to different ports/apps, increasing the odds a page hits the wrong backend.
Dependency consistency: Alfred has multiple runtimes (Docker Python 3.11 + host Python 3.9 + other services). Missing/partial features in the “main” container is the bottleneck.

Next update slot

Next I will: keep expanding this list (still read-only), and attach exact “fix diffs” (what I would change, where) without deploying them until you say go.