QWU Backoffice User Manual

Version: 3.30 | Started: 251223 | Updated: 260302

A comprehensive guide to the QWU Backoffice agent workspace, covering architecture, daily operations, automation, and development workflows. These notes serve both as operational documentation and educational curriculum for Missing Pixel students.

Table of Contents

1. [[#Environment Overview]]
2. [[#Getting Started]]
3. [[#Daily Operations]]
4. [[#One-Tap Mobile VM Control via n8n ⭐]]
5. [[#Running Agent Jobs]]
6. [[#Overnight/Long-Running Jobs]]
7. [[#Mobile Access via Termux (Android) ⭐]]
8. [[#Obsidian + GitHub Integration: Unified Workspace]]
9. [[#Sparse Checkout: Filtering Files on Azure VM]]
10. [[#Syncing Workflow]]
11. [[#Claude Code: Modes and Commands]]
12. [[#Quick Reference Sheets]]
13. [[#DOE Architecture & Skills System]]
14. [[#Morning Briefing System ⭐]]
15. [[#Daily Summary System ⭐]]
16. [[#Google Calendar Integration]]
17. [[#Google Docs Sync System]]
18. [[#Video Content Pipeline]]
19. [[#Voice Profiles]]
20. [[#Expert Intelligence System ⭐]]
21. [[#Wisdom Synthesis System ⭐]]
22. [[#Canonical Datetime System]]
23. [[#Azure Cost Tracking]]
24. [[#Lead Generation System]]
25. [[#Communications Architecture]]
26. [[#Data Architecture]]
27. [[#Project Organization]]
28. [[#YAML Frontmatter Standards]]
29. [[#Docker Fundamentals: Running Isolated Tasks]]
30. [[#Docker Sandbox Security]]
31. [[#Meeting Intelligence System ⭐]]
32. [[#Outlook Email Processing ⭐]]
33. [[#SuiteDash CRM Integration ⭐]]
34. [[#Transcript Extraction System (Planned)]]
35. [[#Ez/Ezer Mascot]]
36. [[#Ez Terminal (Scheduler) ⭐ NEW]]
37. [[#Troubleshooting]]
38. [[#Resources]]
39. [[#BNI Member Dossier System]]
40. [[#BNI Meeting Recap System ⭐ NEW]]
41. [[#System Architecture Audit ⭐ NEW]]
42. [[#EPIC Appointment Intelligence System v2.0 ⭐ NEW]]
43. [[#Ezer Aión Assistant System ⭐ NEW]]
44. [[#Strategic Goals Framework ⭐ NEW]]
45. [[#QWU Cosmic Style Guide ⭐ NEW]]
46. [[#Content Calendar System ⭐ NEW]]
47. [[#Daily Journal Command Center ⭐ NEW]]
48. [[#Supervisor Observability System (SOS) ⭐ NEW]]
49. [[#Relationship Intelligence Layer ⭐ NEW]]
50. [[#Parallel Execution System ⭐ NEW]]
51. [[#Ezer Universal Interface ⭐ NEW]]
52. [[#Project System Status Files ⭐ NEW]]
53. [[#Supervisor Architecture]]
54. [[#HQ Command Center ⭐ NEW]]
55. [[#QWR SEO Intelligence ⭐ NEW]]
56. [[#Customer System Safeguards ⭐ NEW]]
57. [[#GreenCal Command Center ⭐ NEW]]
58. [[#Pocket Ez Companion App ⭐ NEW]]
59. [[#Public Manual Generation System ⭐ NEW]]
60. [[#QWR Audience Intelligence System ⭐ NEW]]
61. [[#QKN Quietly Knocking ⭐ NEW]]
62. [[#QSP Quietly Spotting ⭐ NEW]]
63. [[#QNT Quietly Networking ⭐ NEW]]
64. [[#QWR Content Performance Intelligence ⭐ NEW]]
65. [[#QWR Press Release Service ⭐ NEW]]
66. [[#Cost Intelligence System ⭐ NEW]]
67. [[#QWR Reverse Benchmarking Intelligence ⭐ NEW]]
68. [[#QWR Content Strategy System ⭐ NEW]]
69. [[#QWR Preparation Workbook ⭐ NEW]]
70. [[#QWF Ecosystem Landing Section ⭐ NEW]]
71. [[#Auto-Remediation System ⭐ NEW]]
72. [[#QTR Quietly Tracking ⭐ NEW]]
73. [[#QWF Ecosystem Widget ⭐ NEW]]
74. [[#QWR Team Accounts System ⭐ NEW]]
75. [[#QWF Documentation Standard ⭐ NEW]]
76. [[#Session Log]]

Environment Overview

What is the QWU Backoffice?

The QWU Backoffice is an AI agent workspace running on Microsoft Azure, designed to automate operations for The Quietly Working Foundation. It provides a secure, sandboxed environment where Claude Code agents can execute tasks, process data, and manage workflows.

Architecture: Azure VM + Docker + VS Code Remote

┌─────────────────────────────────────────────────────────────────┐
│  YOUR DEVICES                                                    │
├─────────────────────────────────────────────────────────────────┤
│  Windows PC          │  Android Phone       │  Any Browser      │
│  VS Code + SSH       │  Termux + SSH        │  Azure Portal     │
└──────────┬───────────┴──────────┬───────────┴─────────┬─────────┘
           │                      │                     │
           └──────────────────────┼─────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────┐
│  AZURE CLOUD                                                     │
├─────────────────────────────────────────────────────────────────┤
│  ┌─────────────────────────────────────────────────────────┐    │
│  │  Ubuntu VM (claude-dev-vm)                              │    │
│  │  ┌─────────────────┐  ┌─────────────────────────────┐   │    │
│  │  │  Docker         │  │  qwu_backOffice/            │   │    │
│  │  │  (isolated      │  │  ├── .claude/               │   │    │
│  │  │   containers)   │  │  ├── 005 Operations/        │   │    │
│  │  └─────────────────┘  │  │   ├── Directives/        │   │    │
│  │                       │  │   └── Execution/         │   │    │
│  │                       │  └── [obsidian vault]       │   │    │
│  │  ┌─────────────────┐  └─────────────────────────────┘   │    │
│  │  │  Claude Code    │                                    │    │
│  │  │  (AI agent)     │                                    │    │
│  │  └─────────────────┘                                    │    │
│  └─────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────┘

VM Details

Infrastructure Monitoring & Backups

The QWU infrastructure is monitored at three layers, all documented in 005 Operations/Directives/infrastructure_monitoring.md.

External Monitoring (Betterstack)

• HTTP monitor pings n8n.quietlyworking.org/healthz every 60 seconds (updated 2026-02-23; root path blocked by n8n for bot user agents)
• Heartbeat monitors expect a check-in every 6 hours from each VM
• Alerts: phone call + SMS + email + push notification
• Outgoing webhook (ID 80218) fires on incident events → triggers auto-remediation (see [[#Auto-Remediation System ⭐ NEW]])
• Status page: status.quietlyworking.org (also embedded in SuiteDash CRM dashboard)

Internal Health Checks

• check_vm_health.py runs every 6 hours via cron on both VMs
• Collects: disk, memory, load, Docker containers, n8n workflow failures
• Posts health embed to Discord #system-status
• Always pings Betterstack heartbeat regardless of health status (v1.1.0). The heartbeat proves "VM is alive and monitoring is running." Service-level issues are reported via Discord alerts separately. A missing heartbeat should only mean "VM is unreachable."
• Thresholds: 80% warning, 90% critical for disk/memory
• Systemd services monitored: sms-webhook, digital-twin, qnt-webhook, caddy

Application Health Checks

• check_calendar_health.py runs every 2 hours via cron on claude-dev
• Validates HQ Command Center's google-calendar-events Supabase edge function
• Auto-redeploys known-good source via Supabase CLI if broken
• Posts to Discord #system-status (healthy/healed/still-broken)

Database Backups

• Nightly at 3 AM UTC: backup_n8n_postgres.sh on n8n VM
• Local rotation: 7 daily + 4 weekly (~8MB compressed per backup)
• Offsite: uploaded to Azure Blob Storage (<STORAGE_ACCOUNT> account, n8n-backups container)
• Restore: az storage blob download ... && gunzip -c restore.sql.gz | docker exec -i n8n-postgres psql -U n8n n8n

Getting Started

Accessing the Workspace (VS Code Connection)

1. Start the VM (Azure Portal or one-tap mobile script)
2. Open VS Code
3. Click green button (bottom-left) → Connect to Host → claude-dev
4. You're in!

First-Time Setup for New Team Members

1. Generate SSH key on your machine
2. Send public key to admin
3. Admin adds to VM's ~/.ssh/authorized_keys
4. Configure SSH in ~/.ssh/config:

Host claude-dev
    HostName <VM_IP_CLAUDE_DEV>
    User <VM_USER>
    IdentityFile ~/.ssh/your-key.pem

Understanding the Dev Container

The .devcontainer/ folder contains configuration for isolated development:

• Dockerfile - Container image definition
• devcontainer.json - VS Code settings
• init-firewall.sh - Network security rules

"Reopen in Container" — When to Click vs Dismiss

When you connect via VS Code Remote SSH, you may see a popup asking to "Reopen in Container." Here's when to use each option:

Click "Reopen in Container" when you want to:

• Work inside the sandboxed Claude Code agent environment
• Develop/test in the isolated Docker container
• Run agent operations that need that specific secure environment

Click "Don't Show Again" or dismiss when you want to:

• Work directly on the VM itself
• Access the Obsidian vault, check logs, manage Docker containers from the host
• Run tmux sessions for overnight agent monitoring
• General system administration

Typical daily workflow: For most day-to-day work—checking on agents, syncing the vault, running n8n-triggered operations—you probably want to stay on the SSH connection to the VM host rather than reopening inside the container.

Switching between them:

• To enter container: Command Palette (Ctrl+Shift+P) → Dev Containers: Reopen in Container
• To return to VM host: Command Palette → Remote-SSH: Connect to Host → claude-dev

Daily Operations

Starting Your Work Day

Option 1: One-Tap Mobile (Recommended)
Tap qwu-start.sh widget on phone → auto-connects when ready

Option 2: Manual Start

1. Azure Portal → Find claude-dev-vm
2. Click Start
3. Wait ~60 seconds
4. VS Code → Connect to claude-dev

Stopping the VM When Done

Option 1: One-Tap Mobile
Tap qwu-stop.sh widget

Option 2: From VS Code Terminal

sudo shutdown now

Option 3: Let Auto-Shutdown Handle It
VM stops at 7 PM Pacific automatically.

Checking Costs in Azure Portal

1. Azure Portal → Cost Management
2. Filter by resource group: <RESOURCE_GROUP>
3. Review daily/monthly spend

One-Tap Mobile VM Control via n8n ⭐

Start and stop your Azure VM from your phone with a single tap... no Azure Portal needed.

Architecture

Phone (Termux Widget)
    → n8n Webhook (cloud, always on)
    → Azure API (start/stop/status)
    → VM responds
    → Termux polls for SSH
    → Auto-connects when ready

Components

Azure Service Principal Details

Created via Azure Cloud Shell:

az ad sp create-for-rbac \
  --name "n8n-vm-automation" \
  --role "Virtual Machine Contributor" \
  --scopes "/subscriptions/{sub-id}/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Compute/virtualMachines/claude-dev-vm"

n8n Webhook Endpoints

Termux Scripts

~/.shortcuts/qwu-start.sh - Start VM + wait + connect:

#!/data/data/com.termux/files/usr/bin/bash
# Version: 1.0.0
# QWU Start + Connect

WEBHOOK_URL="https://n8n.quietlyworking.org/webhook/vm-control?action=start"
VM_IP="<VM_IP_CLAUDE_DEV>"
MAX_ATTEMPTS=24

echo "🚀 Starting QWU Backoffice..."
curl -s "$WEBHOOK_URL"

echo "⏳ Waiting for VM..."
ATTEMPTS=0
until nc -z -w 5 $VM_IP 22 2>/dev/null; do
    ATTEMPTS=$((ATTEMPTS + 1))
    if [ $ATTEMPTS -ge $MAX_ATTEMPTS ]; then
        echo "❌ VM didn't respond in time"
        exit 1
    fi
    echo "   Attempt $ATTEMPTS/$MAX_ATTEMPTS..."
    sleep 5
done

echo "✅ Connecting..."
ssh qwu

~/.shortcuts/qwu-stop.sh - Deallocate VM (saves money):

#!/data/data/com.termux/files/usr/bin/bash
# Version: 1.0.0
# QWU Stop

WEBHOOK_URL="https://n8n.quietlyworking.org/webhook/vm-control?action=stop"

echo "🛑 Stopping QWU Backoffice..."
curl -s "$WEBHOOK_URL"
echo "✅ Shutdown initiated"

Setup in Termux

# Create shortcuts directory
mkdir -p ~/.shortcuts

# Create and edit scripts
nano ~/.shortcuts/qwu-start.sh
nano ~/.shortcuts/qwu-stop.sh

# Make executable
chmod +x ~/.shortcuts/qwu-start.sh
chmod +x ~/.shortcuts/qwu-stop.sh

# Install netcat if needed
pkg install netcat-openbsd

Then add Termux:Widget to your home screen.

Credential Rotation

The Azure client secret expires after 12 months. To rotate:

1. Azure Portal → Microsoft Entra ID → App registrations → n8n-vm-automation
2. Certificates & secrets → New client secret (12 months)
3. Copy the new secret value
4. n8n → Variables → Update azure_client_secret
5. Delete the old secret in Azure

Calendar reminder set for 2 weeks before expiration (December 2026).

Self-Hosted n8n Instance (n8n.quietlyworking.org) ⭐ NEW

As of January 2026, we migrated from n8n Cloud to a self-hosted instance to reduce costs.

Environment Variables (in .env):

N8N_API_URL=https://n8n.quietlyworking.org/api/v1
N8N_API_KEY=<API_KEY>  # Full key in .env

API Usage (from QWU Backoffice VM):

# List all workflows
curl -s "$N8N_API_URL/workflows" -H "X-N8N-API-KEY: $N8N_API_KEY" | jq '.data[] | {name, id, active}'

# Import a workflow
cat workflow.json | jq '{name, nodes, connections, settings}' | \
  curl -s -X POST "$N8N_API_URL/workflows" \
  -H "X-N8N-API-KEY: $N8N_API_KEY" \
  -H "Content-Type: application/json" -d @-

# Activate a workflow
curl -s -X POST "$N8N_API_URL/workflows/{workflow_id}/activate" \
  -H "X-N8N-API-KEY: $N8N_API_KEY"

Naming Convention for .env:

• API keys should follow: SERVICE_API_KEY format (e.g., N8N_API_KEY, SUITEDASH_SECRET_KEY)
• Use UPPERCASE_WITH_UNDERSCORES, not lowercase-with-hyphens
• Include a comment above explaining the key's purpose

SSH Access to n8n VM (from QWU Backoffice):

ssh qwu-n8n                    # Connect to n8n VM
ssh qwu-n8n "docker ps"        # Run single command

Managing n8n Environment Variables:

The self-hosted Community Edition uses server environment variables ($env.VARIABLE_NAME) instead of the Cloud Pro Variables UI ($vars).

# View current variables
ssh qwu-n8n "cat ~/n8n/.env"

# Add new variable (example)
ssh qwu-n8n "echo 'NEW_VAR=value' >> ~/n8n/.env"

# Also add to docker-compose.yml environment section, then restart:
ssh qwu-n8n "cd ~/n8n && docker compose up -d"

Available Discord Webhook Variables:

Usage in n8n Workflows:

{{ $env.DISCORD_WEBHOOK_AGENT_LOG }}

Active Ezer Workflows:

Migrating Workflows from Cloud Pro to Self-Hosted ⭐ MP TRAINING

This section documents how to migrate n8n workflows from Cloud Pro (or any exported JSON) to the self-hosted instance. This is an excellent MP Student training opportunity (Contributor tier+).

Key Differences: Cloud Pro vs Self-Hosted

Step-by-Step Migration Process

1. Export the workflow from Cloud Pro:

# In Cloud Pro: Workflow → ⋮ menu → Export
# Save as JSON file

2. Identify changes needed:

Run this check on the exported JSON:

# Check for $vars references (need to change to $env)
grep -o '\$vars\.[a-z_]*' workflow.json | sort -u

# Check SSH credential references
grep -A5 '"sshPrivateKey"' workflow.json

3. Convert variable references:

4. Update SSH credentials:

Replace any SSH credential block with:

"credentials": {
  "sshPrivateKey": {
    "id": "<SSH_CREDENTIAL_ID>",
    "name": "QWU Backoffice SSH - 20251224a"
  }
}

5. Clean the JSON for API import:

The n8n API rejects certain properties. Remove these before import:

# Create clean version for API
cat workflow.json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for key in ['staticData', 'triggerCount', 'tags', 'id', 'meta']:
    data.pop(key, None)
print(json.dumps(data))
" > workflow-clean.json

6. Deploy via API:

# Source environment (or use literal values)
source .env

# Create workflow
curl -s -X POST \
  -H "X-N8N-API-KEY: $N8N_API_KEY" \
  -H "Content-Type: application/json" \
  -d @workflow-clean.json \
  "$N8N_API_URL/workflows"

# Note the returned workflow ID

7. Activate the workflow:

curl -s -X POST \
  -H "X-N8N-API-KEY: $N8N_API_KEY" \
  "$N8N_API_URL/workflows/{WORKFLOW_ID}/activate"

8. Verify deployment:

# List all workflows and check status
curl -s -H "X-N8N-API-KEY: $N8N_API_KEY" "$N8N_API_URL/workflows" | \
  python3 -c "import json,sys; data=json.load(sys.stdin); \
  [print(f\"{w['id']}: {w['name']} (active: {w['active']})\") for w in data.get('data',[])]"

Common Pitfalls

Save the Workflow Locally

Always save the migrated workflow JSON to version control:

# Standard location for workflow JSON files
005 Operations/Workflows/your-workflow-name.json

MP Student Learning Objectives

Students completing this module will learn:

• JSON editing and transformation
• API authentication patterns
• Environment variable conventions
• CI/CD concepts (deploy → activate → verify)
• Debugging API responses
• Version control for infrastructure

n8n Version Management ⭐ NEW

The self-hosted n8n instance uses pinned version tags for stability.

Current Version: 2.8.0 (as of 2026-02-11)

Update Procedure:

# 1. SSH to n8n VM
ssh qwu-n8n

# 2. Backup database
cd ~/n8n
docker exec n8n-postgres pg_dump -U n8n n8n | gzip > backup_$(date +%Y%m%d).sql.gz

# 3. Update version in docker-compose.yml
# Change: image: docker.n8n.io/n8nio/n8n:2.8.0
# To:     image: docker.n8n.io/n8nio/n8n:X.Y.Z

# 4. Pull new image and restart
docker compose pull n8n && docker compose up -d

# 5. Verify version
docker exec n8n n8n --version

# 6. Verify all workflows still active
docker exec n8n-postgres psql -U n8n -d n8n -c \
  "SELECT COUNT(*) as total, SUM(CASE WHEN active THEN 1 ELSE 0 END) as active FROM workflow_entity;"

Version Monitoring (v2.0.0 - Release Intelligence):

• The "n8n Version Monitor" workflow checks GitHub releases every Monday 9 AM
• Parses release notes for QWU-relevant changes using node inventory
• Color-coded notifications by severity:
  • 🚨 Major (X.0.0) - Red, high priority
  • 🔄 Minor (X.Y.0) - Orange, medium priority
  • 📦 Patch (X.Y.Z) - Green, routine
• Skips pre-release versions (e.g., 2.5.x)
• Update the currentVersion constant in the workflow after each upgrade

QWU Node Inventory (what the monitor tracks):

Directive: See 005 Operations/Directives/n8n_version_management.md for full process

Workflow Publishing (n8n 2.x):
n8n 2.x uses a publish/unpublish model instead of activate/deactivate:

# Publish a workflow (after import)
docker exec n8n n8n publish:workflow --id=<workflow_id>

# Unpublish (disable)
docker exec n8n n8n unpublish:workflow --id=<workflow_id>

# Restart required after publishing
cd ~/n8n && docker compose restart n8n

Workflow Archiving:
n8n has a native archive feature via the isArchived database column:

# Archive an old workflow
docker exec n8n-postgres psql -U n8n -d n8n -c \
  "UPDATE workflow_entity SET \"isArchived\" = true WHERE id = '<workflow_id>';"

Archived workflows are hidden from the main list but preserved for reference.

Running Agent Jobs

tmux for Persistent Sessions ⭐

Why it matters: When you disconnect from the workspace, running processes normally stop. tmux keeps your agents running even when you're not connected.

Essential Commands:

# Start a new named session
tmux new -s agents

# Detach from session (process keeps running)
Ctrl+B, then D

# List all sessions
tmux ls

# Reattach to a session
tmux attach -s agents

# Kill a session when done
tmux kill-session -s agents

Multiple Windows Inside tmux:

Ctrl+B, then C          # Create new window
Ctrl+B, then N          # Next window  
Ctrl+B, then P          # Previous window
Ctrl+B, then 0-9        # Jump to window by number
Ctrl+B, then ,          # Rename current window

Best Practice for Overnight Jobs:

1. Start a tmux session with a descriptive name: tmux new -s lead-scraper
2. Run your agent script
3. Detach: Ctrl+B, then D
4. Go to sleep 😴 (VM runs 24/7, no shutdown concerns)
5. Reconnect next day: tmux attach -s lead-scraper

Overnight/Long-Running Jobs

24/7 Operation Mode

As of January 2026, the QWU Backoffice VM runs 24/7. Auto-shutdown has been disabled to enable:

• Continuous n8n workflow execution
• Ezer email response handling at any hour
• Overnight batch processing jobs
• True autonomous operations

Cost Trade-off: ~$50-85/month (vs. ~$35-40 with auto-shutdown). Worth it for always-on automation.

Server Maintenance

With 24/7 operation, we follow a maintenance schedule:

See server_maintenance.md directive for full procedures.

Mobile Access via Termux (Android) ⭐

Access your Azure VM from your phone... check on overnight agent runs from anywhere.

Why This Matters

When you kick off a long-running agent job in tmux and go to bed, you can check on it from your phone without getting out of bed. 📱

Installation (One-Time Setup)

Important: Don't use the Google Play Store version... it's outdated.

1. Install F-Droid from https://f-droid.org
2. Open F-Droid and install these four apps:
   • Termux (main terminal)
   • Termux:API (clipboard, notifications)
   • Termux:Widget (home screen shortcuts)
   • Termux:Styling (customize appearance)

Initial Configuration

Open Termux and run:

# Update packages
pkg update && pkg upgrade -y

# Install essentials
pkg install openssh git termux-api nano curl netcat-openbsd -y

# Grant storage access
termux-setup-storage

Generate SSH Key

ssh-keygen -t ed25519 -C "termux-mobile"

Press Enter for defaults. View your public key:

cat ~/.ssh/id_ed25519.pub

Add Key to Azure VM

From another terminal connected to your VM, add the public key:

echo "YOUR_PUBLIC_KEY_HERE" >> ~/.ssh/authorized_keys

Configure SSH Shortcut

Create the config file:

nano ~/.ssh/config

Add this (update IP if it changes):

Host qwu
    HostName <VM_IP_CLAUDE_DEV>
    User <VM_USER>
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
    ServerAliveCountMax 3

Save (Ctrl+O, Enter, Ctrl+X) and set permissions:

chmod 600 ~/.ssh/config

Daily Use

Keyboard Tips

Termux shows an extra keys row. Useful shortcuts:

• Volume Up + Q = ESC
• Volume Up + E = CTRL
• Swipe left from right edge for drawer with more keys

Troubleshooting

"Connection timed out"

• Rare with 24/7 operation, but could indicate network issue or VM restart. Check Azure Portal for status.

"Connection refused"

• Check if VM IP changed (it can change when stopped/started). Update ~/.ssh/config with new IP.

"Permission denied (publickey)"

• Your key wasn't added to the VM. Re-run the echo command on the VM to add it.

Obsidian + GitHub Integration: Unified Workspace

The QWU Backoffice uses a unified workspace architecture where the Obsidian vault and agent codebase live in the same repository. This allows you to edit agent code (directives, execution scripts) from Obsidian on any device.

Architecture Overview

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│  Obsidian       │     │     GitHub      │     │    Azure VM     │
│  (Windows)      │◄───►│   (Full Repo)   │◄───►│  (Filtered)     │
│  Full vault     │     │                 │     │  Text files only│
└─────────────────┘     └─────────────────┘     └─────────────────┘

Local Vault Location

C:\Users\<USERNAME>\qwu_backOffice

This folder serves as both:

• Your Obsidian vault (open in Obsidian as a vault)
• Your git repository (syncs to GitHub)

Obsidian Git Plugin Settings

The obsidian-git community plugin handles automatic sync:

Manual Sync Commands

In Obsidian, use the Command Palette (Ctrl+P):

• Obsidian Git: Commit all changes - Save current changes
• Obsidian Git: Push - Upload to GitHub
• Obsidian Git: Pull - Download from GitHub

.gitignore Configuration

Located at the root of the vault, excludes files that shouldn't sync:

# Obsidian workspace cache & plugins
.obsidian/workspace.json
.obsidian/workspace-mobile.json
.obsidian/plugins/

# Smart Connections plugin data
.smart-env/
.smart-connections/
smart-chats/

# Trash & temporary files
.trash/
.tmp.driveupload/
.tmp/

# Supervisor escalation outputs (legacy safety net — now routed to ___Supervisor_Escalations/)
000 Inbox/___Tasks/SUPERVISOR-*.md
000 Inbox/___Supervisor_Escalations/

# Environment and credentials (NEVER commit)
.env
.credentials/

# Node.js
node_modules/

# Python
.venv/
__pycache__/
*.pyc

# IDE & OS
.vscode/
.DS_Store
Thumbs.db

Sparse Checkout: Filtering Files on Azure VM

The Azure VM uses sparse checkout to only download files that agents need. This excludes images, canvas files, and other non-text content.

How It Works

Git's sparse checkout feature tells the VM: "Only pull these types of files." The full repo stays on GitHub, but the VM only sees what's relevant for agent work.

Sparse Checkout Configuration File

Located at: ~/qwu_backOffice/.git/info/sparse-checkout

Current configuration:

# Include everything by default
/*

# ===================
# EXCLUDE: Obsidian visual/UI files
# ===================
!*.canvas
!*.excalidraw
!/Excalidraw/

# ===================
# EXCLUDE: Obsidian plugin data (not needed by agents)
# ===================
!/.smart-connections/
!/.smart-env/
!/smart-chats/
!/www.help.obsidian.md/
!/{{savePath}}/

# ===================
# EXCLUDE: Large media files (agents work with text)
# ===================
!*.jpg
!*.jpeg
!*.png
!*.gif
!*.webp
!*.mp4
!*.mp3
!*.pdf

# ===================
# EXCLUDE: Misc
# ===================
!/Omnivore/
!/Clippings/

Editing Sparse Checkout Rules

To add or remove exclusions:

nano ~/qwu_backOffice/.git/info/sparse-checkout

After editing, apply changes:

cd ~/qwu_backOffice
git sparse-checkout reapply

Sparse Checkout Syntax

The ! prefix means "exclude this pattern."

Verifying Sparse Checkout

Check what's included:

ls -la ~/qwu_backOffice

Verify specific files are excluded:

find ~/qwu_backOffice -name "*.canvas" 2>/dev/null
# Should return nothing if working correctly

Syncing Workflow

Your Daily Workflow (Obsidian)

1. Open Obsidian (it auto-pulls on startup)
2. Edit notes, directives, execution scripts
3. Auto-commits every 10 minutes, or manually via Command Palette
4. Changes sync to GitHub automatically

Agent Workflow (Azure VM)

Before agents read/write:

cd ~/qwu_backOffice
git pull

After agents write outputs:

git add .
git commit -m "Agent work log: $(date +%Y-%m-%d)"
git push

These outputs will appear in your Obsidian vault on the next sync!

Handling Sync Conflicts

If you edit on multiple devices simultaneously, you may get merge conflicts.

To resolve:

git status                    # See conflicted files
git diff                      # See the conflicts
nano <conflicted-file>        # Edit to resolve
git add <conflicted-file>
git commit -m "Resolved merge conflict"
git push

Prevention tip: Let auto-sync run before switching devices.

Claude Code: Modes and Commands

Claude Code is a command-line AI assistant that can read, write, and execute code directly on your system.

Starting Claude Code

cd ~/qwu_backOffice
source .env
claude

Operating Modes

Normal Mode (Default)

Claude asks permission before:

• Writing/editing files
• Running terminal commands
• Installing packages

Best for: Learning, careful work, when you want to review each step.

Plan Mode

Toggle on/off by typing /plan inside Claude Code.

Claude will:

• ✅ Read files
• ✅ Think through problems
• ✅ Create detailed plans
• ❌ NOT write any files
• ❌ NOT run any commands

Best for: Complex problems where you want to think before acting. Architecture decisions. Reviewing what SHOULD happen before doing it.

Auto-accept Mode

claude --dangerously-skip-permissions

Claude executes without asking "May I run this command?" each time.

Best for: Trusted, repetitive tasks. Overnight agent runs. When you've already validated the workflow.

⚠️ Use with caution - it will do exactly what it decides to do!

Useful Commands Inside Claude Code

Tips for Effective Use

1. Start in Normal Mode until you're comfortable with how Claude operates
2. Use Plan Mode before tackling complex refactors or new features
3. Be specific in your requests - Claude works better with clear goals
4. Review changes before approving in Normal Mode
5. Use Auto-accept only for well-tested, repetitive workflows

Quick Reference Sheets

Printable reference cards for efficient terminal work. These are designed to be printed and kept nearby while learning.

Terminal Copy/Paste (The Big One!)

Coming from Windows, this is the #1 gotcha:

Line Editing (Readline)

Navigate and edit commands without arrow keys:

Command History

Process Control

tmux Quick Reference

Claude Code Commands

Nano Editor (Quick Edits)

Git Essentials

VS Code Remote Shortcuts

Termux (Android) Tips

DOE Architecture & Skills System

The QWU Backoffice uses a 3-layer DOE (Directive-Orchestration-Execution) architecture.

Architecture Overview

┌─────────────────────────────────────────────────────────────────┐
│  LAYER 1: DIRECTIVE (What to do)                                │
│  Natural language instructions in Markdown                      │
│  Location: 005 Operations/Directives/                           │
├─────────────────────────────────────────────────────────────────┤
│  LAYER 2: ORCHESTRATION (Decision making)                       │
│  AI agent reads directives, makes routing decisions             │
│  Handles errors, asks for clarification, updates directives     │
├─────────────────────────────────────────────────────────────────┤
│  LAYER 3: EXECUTION (Doing the work)                            │
│  Deterministic Python scripts                                   │
│  Location: 005 Operations/Execution/                            │
└─────────────────────────────────────────────────────────────────┘

Key Principles

• Check for tools first - Before writing a script, check if one exists
• Self-anneal when things break - Fix, test, update directive
• Update directives as you learn - Directives are living documents
• Deliverables in cloud - Use Google Sheets, Slides, etc. for outputs
• Local files for processing only - Everything in .tmp/ is temporary

Skills System

Skills provide domain-specific knowledge that agents reference:

.claude/skills/
├── qwf-brand-voice/          # Voice profiles
│   ├── SKILL.md              # Overview + when to use each
│   ├── tig-standard.md       # Full TIG voice profile
│   ├── woh-combat.md         # WOH combat voice
│   └── l4g-b2b.md            # L4G business voice
│
├── qwf-programs/             # Program context
│   ├── SKILL.md
│   ├── acofh.md              # Mission, audience, sensitivities
│   ├── mp.md                 # Missing Pixel details
│   ├── iysr.md
│   ├── woh.md
│   ├── qwc.md
│   └── l4g.md
│
└── qwf-print-specs/          # Production specs
    ├── l4g-postcard.md
    └── apparel.md

Agent Templates

Agents live in .claude/agents/:

.claude/agents/
├── qwf-master-router.md      # Routes incoming work
├── qwf-creative-director.md  # Oversees creative production
├── qwf-writer.md             # Content creation
└── qwf-visual-designer.md    # Graphics execution

MCP Server Configuration

The workspace uses MCP (Model Context Protocol) servers for tool access. MCP servers are configured at the project level in .mcp.json (gitignored, contains tokens) and are opt-in per session to conserve memory.

File: .mcp.json (project root, NOT committed to git)

{
  "mcpServers": {
    "discord-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "discord-mcp@latest"],
      "env": { "DISCORD_BOT_TOKEN": "..." }
    },
    "apify": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@apify/actors-mcp-server"],
      "env": { "APIFY_TOKEN": "..." }
    }
  }
}

Settings: .claude/settings.local.json has enableAllProjectMcpServers: false — new sessions do NOT auto-spawn MCP servers. Enable per-session via /mcp when needed.

Why opt-in: Each MCP server spawns ~3 Node.js processes (~160 MB). With 5 concurrent sessions, auto-spawning Discord MCP alone consumed 786 MB. Most sessions don't need Discord access, so opt-in saves significant memory on the 16 GB VM.

To enable Discord MCP in a session: Use the /mcp command within the session to connect.

Supervisor Architecture

The QWU Backoffice uses five domain-specific supervisors that orchestrate automated script execution across the entire system. Each supervisor owns a domain, runs its scripts on a schedule via n8n, logs results to SQLite, and escalates failures to Discord.

Why Supervisors Exist

Before supervisors, a single router agent handled all automation. As the system grew to 60+ scripts, the router became a bottleneck — errors compounded, scheduling conflicted, and failures in one domain could block others. The supervisor architecture splits responsibility into five independent domains that run in parallel.

The Five Supervisors

How It Works

┌──────────────┐     ┌────────────────────┐     ┌──────────────────┐
│   n8n         │────▶│   Supervisor .py    │────▶│   Scripts         │
│   (schedule)  │     │   (orchestrator)    │     │   (deterministic) │
└──────────────┘     └────────────────────┘     └──────────────────┘
                              │
                     ┌────────┴────────┐
                     ▼                 ▼
              ┌──────────┐     ┌──────────────┐
              │ SQLite DB │     │ Discord Alert │
              │ (logging) │     │ (escalation)  │
              └──────────┘     └──────────────┘

1. n8n triggers the supervisor on schedule (SSH to backoffice VM)
2. Supervisor checks the cross-domain queue for tasks from other supervisors
3. Supervisor runs its pipeline scripts in sequence
4. Each script result is logged to the supervisor's SQLite database
5. On failure, the supervisor retries (up to 2x), then escalates to Discord #supervisor-alerts
6. On completion, the supervisor logs the run summary and notifies Discord

Key Files

Databases

Each supervisor maintains its own SQLite database in 005 Operations/Data/:

Escalation Routing

When a supervisor detects a failure requiring human attention, it escalates via two channels:

1. Discord #supervisor-alerts — Immediate visibility (via escalate_to_discord())
2. Escalation file — Audit trail in 000 Inbox/___Supervisor_Escalations/ (via escalate_to_task() in error_handling.py v2.1.0)

These escalation files are intentionally kept separate from ___Tasks/ so they don't pollute the user's HQ Command Center task list. As defense-in-depth, sync_hq_tasks.py v1.5.0 also skips any files with a SUPERVISOR- prefix.

Running Supervisors Manually

# Run with JSON output (used by n8n)
python "005 Operations/Execution/operations_supervisor.py" --json

# Run specific pipeline
python "005 Operations/Execution/content_pipeline_supervisor.py" --pipeline queue --json

# Dry run (shows what would execute)
python "005 Operations/Execution/lead_intelligence_supervisor.py" --dry-run --json

# Run a single script through the supervisor
python "005 Operations/Execution/content_pipeline_supervisor.py" --script newsletter_monitor.py --json

Cross-Supervisor Queue

Supervisors can create tasks for each other via 000 Inbox/___Supervisor_Queue/. Tasks are YAML-frontmatter Markdown files with from, to, and priority fields. The receiving supervisor picks up tasks on its next run and moves completed tasks to 000 Inbox/___Supervisor_Completed/.

Health Dashboard

Generate a health dashboard at any time:

# Quick summary
python "005 Operations/Execution/generate_supervisor_dashboard.py"

# Full markdown dashboard
python "005 Operations/Execution/generate_supervisor_dashboard.py" --markdown

# JSON for programmatic use
python "005 Operations/Execution/generate_supervisor_dashboard.py" --json

n8n Workflows

Each supervisor has a corresponding n8n workflow:

Troubleshooting

Dashboard shows "CRITICAL" but supervisors are running:
Supervisors with ON_DEMAND_SCRIPTS sets (Content Pipeline v1.1.0+, Lead Intelligence v1.1.0+) automatically skip scripts that need user-provided inputs during automated runs. If you still see failures, check for scripts missing from the ON_DEMAND_SCRIPTS set — they may need required arguments (--sheet-url, --json-file, etc.) that the supervisor can't provide. Fix: add the script to ON_DEMAND_SCRIPTS in the supervisor.

A supervisor isn't running on schedule:

1. Check n8n: ssh <VM_USER>@qwu-n8n "docker exec n8n n8n list:workflow"
2. Verify the workflow is published (not just active)
3. Check recent executions in n8n UI at https://n8n.quietlyworking.org

Script failures escalating to Discord too often:
The supervisor retries each script up to 2 times before escalating. If a script consistently fails, either fix the script or remove it from the supervisor's script list until it's ready.

Cross-supervisor tasks not being picked up:
Check 000 Inbox/___Supervisor_Queue/ for stuck tasks. Verify the to: field in the YAML frontmatter matches the receiving supervisor's domain_name.

Rolling back to legacy workflows:
Follow 005 Operations/Workflows/supervisor-rollback.md for emergency rollback procedures. Legacy workflows are deactivated (not deleted) and can be re-enabled with a single command.

Morning Briefing System ⭐

The Morning Briefing is an automated daily summary that surfaces what matters when you begin work.

What It Shows

Running the Briefing

Manual (via Claude Code):

Let's do a morning briefing

Script (direct):

cd ~/qwu_backOffice && source .env
python "005 Operations/Execution/morning_briefing.py"

Options:

--dry-run    # Preview without writing
--discord    # Also post to Discord (default: daily note only)
--no-daily   # Skip daily note append
--json       # Output JSON for n8n

Output Locations

Project Task Scanning

The briefing also scans all active projects for tasks:

1. Active Tasks section - Items in ## Active Tasks within project _Overview.md files
2. Incomplete checkboxes - Any - [ ] items in project files

Project tasks inherit the project's priority level.

Day Boundary Feature

Late-night work handling: If you're working past midnight (before 4 AM), the briefing logs to "yesterday's" date. This prevents late-night sessions from bleeding into the next day's records.

2:00 AM on Jan 8 → logs to Jan 7's daily note
5:00 AM on Jan 8 → logs to Jan 8's daily note

This feature is powered by the Canonical Datetime System via the effective_date() function in qwu_datetime.py.

Daily Summary System ⭐

End-of-session summaries capture completed work, decisions, and next actions for institutional memory.

When to Use

Run the summary when wrapping up a work session:

Let's summarize this session

or

Wrap up for the day

What Gets Captured

Output Format

## Session Summary - 2026-01-08

### What Was Accomplished
- Implemented morning briefing calendar integration - *Advances: M5 milestone*
- Fixed inbox processing bug - *Advances: Automation reliability*

### Key Decisions Made
| Decision | Reasoning | Implications |
|----------|-----------|--------------|
| Use day boundary | Prevents late-night date confusion | Work before 4am counts as yesterday |

### Proposed Next Actions
1. **[High]** Complete user manual update *(Advances: Documentation)*
2. **[Medium]** Test calendar integration edge cases

Integration Points

The summary system can optionally read:

• 002 Projects/_Goals and Priorities.md - For goal alignment
• 002 Projects/_Current Roadmap.md - For roadmap context

Google Calendar Integration

The backoffice integrates with Google Calendar for morning briefings and scheduling awareness.

Configured Calendars

Setup Requirements

1. Google Cloud Service Account with Calendar API enabled
2. Credentials JSON file stored securely on VM
3. Calendar sharing with service account email

Environment Variables

GOOGLE_CALENDAR_CREDENTIALS="/path/to/service-account.json"
GOOGLE_CALENDAR_MAIN="<ADMIN_EMAIL>"
GOOGLE_CALENDAR_ALERTS="bills-calendar-id@group.calendar.google.com"
GOOGLE_CALENDAR_TIMESLOT="timeslot-calendar-id@group.calendar.google.com"

Testing Calendar Integration

cd ~/qwu_backOffice && source .env
python "005 Operations/Execution/calendar_events.py" --dry-run  # Validate credentials
python "005 Operations/Execution/calendar_events.py"            # Fetch today's events
python "005 Operations/Execution/calendar_events.py" --json     # JSON output

Google Calendar API Timestamp Gotcha (RFC3339)

The Google Calendar API requires RFC3339 timestamps with explicit timezone offset for timeMin/timeMax parameters — not bare ISO 8601 timestamps. This is a subtle but critical distinction:

When building Supabase Edge Functions (TypeScript/Deno) that call Google Calendar API, always include the timezone offset. For Pacific time, calculate the offset dynamically to handle DST:

// Determine Pacific offset (PST = -08:00, PDT = -07:00)
const jan = new Date(now.getFullYear(), 0, 1).getTimezoneOffset();
const jul = new Date(now.getFullYear(), 6, 1).getTimezoneOffset();
const stdOffset = Math.max(jan, jul);
const isDST = now.getTimezoneOffset() < stdOffset;
const tzOffset = isDST ? '-07:00' : '-08:00';

// Build RFC3339 timestamp
const timeMin = `${year}-${month}-${day}T00:00:00${tzOffset}`;

This was the root cause of the HQ Command Center calendar edge function failure (Feb 2026). AI code generators (including Lovable) tend to produce bare timestamps without offsets.

Google Docs Sync System

The backoffice supports two-way synchronization between Obsidian markdown files and Google Docs, enabling external collaboration while preserving Obsidian as the primary editing environment.

Use Case

Share documents with non-technical collaborators (advisors, board members, partners) via Google Docs while maintaining source-of-truth in Obsidian. Format conversion ensures readers see native Google Docs formatting—not raw Markdown or YAML frontmatter.

Architecture

┌─────────────────┐        ┌─────────────────┐        ┌─────────────────┐
│   Obsidian      │  push  │   Google Docs   │  edit  │   Collaborator  │
│   (Markdown)    │───────►│   (Native fmt)  │◄───────│   (Browser)     │
│                 │◄───────│                 │        │                 │
└─────────────────┘  pull  └─────────────────┘        └─────────────────┘

Key Design Decisions:

• Google Docs wins conflicts (Obsidian backed up before overwriting)
• YAML frontmatter stripped from Google Docs (readers never see it)
• Obsidian syntax converted to readable format (wiki-links → plain text)
• 15-minute automated sync via n8n

Enabling Sync on a File

Add YAML frontmatter to opt-in:

---
title: "QWU Backoffice User Manual [PUBLIC]"
google_doc_sync: true
---

After first sync, additional fields are auto-populated:

---
title: "Document Title"
google_doc_sync: true
google_doc_id: 1Abc123XyZ...           # Auto-populated
google_doc_last_sync: '2026-01-10T10:30:00-08:00'  # Auto-updated
---

Format Conversion

Push: Obsidian → Google Docs

Pull: Google Docs → Obsidian

Running Sync Manually

cd ~/qwu_backOffice && source .env

# Dry run - see what would sync
python "005 Operations/Execution/sync_gdocs.py" --dry-run

# Sync all enabled files
python "005 Operations/Execution/sync_gdocs.py"

# Sync specific file
python "005 Operations/Execution/sync_gdocs.py" --file "path/to/file.md"

# Force push local changes
python "005 Operations/Execution/sync_gdocs.py" --force push

# Force pull from Google Docs
python "005 Operations/Execution/sync_gdocs.py" --force pull

# JSON output for automation
python "005 Operations/Execution/sync_gdocs.py" --json

Automated Sync via n8n

Workflow: 005 Operations/Workflows/gdocs-sync-workflow.json

Schedule (15min) → SSH execute script → Parse JSON →
├── Has Activity? → Post to #agent-log
│                   └── Has Errors? → Post to #inbox-alerts
└── No Activity → Skip (silent)

Posts to Discord only when there's actual sync activity (pushes, pulls, creates, or errors).

Environment Variables

# Reuses calendar service account (needs Docs API scope enabled)
GOOGLE_DOCS_CREDENTIALS=/path/to/service-account.json

# Default Drive folder for new synced documents
GOOGLE_DOCS_FOLDER_DEFAULT=<drive-folder-id>

# Directories to scan for sync-enabled files (comma-separated)
GOOGLE_DOCS_SYNC_DIRS=100 Resources,002 Projects,003 Entities

Google Cloud Setup

1. Enable APIs in Google Cloud Console:

   • Google Docs API
   • Google Drive API (if not already)

2. Service account setup:

   • Can reuse existing calendar service account
   • Needs scopes: documents, drive.file

3. Create Drive folder:

   • Create folder in Google Drive
   • Share with service account email (Editor permission)
   • Copy folder ID from URL

Execution Scripts

State and Backups

n8n Environment Variables Used

$env.DISCORD_WEBHOOK_AGENT_LOG     - Sync activity notifications
$env.DISCORD_WEBHOOK_INBOX_ALERTS  - Error alerts

Note: Self-hosted n8n uses $env.VARIABLE_NAME syntax (not $vars).

Video Content Pipeline

Transform YouTube videos into content assets (articles, social snippets, quotes, intelligence) using Gemini transcription, Claude analysis, and voice profile application.

Architecture

URL → Gemini 2.5 Transcribe → Claude Analyze → Voice Profile → Discord Review → Distribute
         (multimodal)         (structure)      (brand voice)    (approve/edit)

Processing a Video

# Full pipeline with Discord review
.venv/bin/python "005 Operations/Execution/process_video_content.py" "https://youtube.com/watch?v=xxx"

# Skip Discord review (just generate drafts)
.venv/bin/python "005 Operations/Execution/process_video_content.py" "https://youtube.com/watch?v=xxx" --skip-discord

# Dry run (preview without saving)
.venv/bin/python "005 Operations/Execution/process_video_content.py" "https://youtube.com/watch?v=xxx" --dry-run

# Different voice profile
.venv/bin/python "005 Operations/Execution/process_video_content.py" "https://youtube.com/watch?v=xxx" --voice "Chaplain TIG"

Output Structure

All generated content is saved to 000 Inbox/___Content/{uid}/:

Discord Review Commands

Reply in #content-review channel:

Automated Review Processing

The n8n workflow content-review-workflow.json polls every 5 minutes:

1. SSH to Azure VM
2. Run process_content_review.py
3. Process any approve/reject/edit commands
4. Log actions to #agent-log

Content Lifecycle

000 Inbox/___Content/{uid}/     → Draft (pending_review)
000 Inbox/___Approved/{uid}/    → Approved (ready for distribution)

Environment Variables

GOOGLE_AI_STUDIO_API_KEY="xxx"           # Gemini API key
DISCORD_CHANNEL_CONTENT_REVIEW="xxx"     # Channel ID for review
DISCORD_WEBHOOK_CONTENT_REVIEW="xxx"     # Webhook URL for notifications

Gemini API Billing

The video content pipeline uses Google's Gemini API for video transcription. Understanding the billing tiers is important for production use.

Free Tier Limits:

• 20 requests/day for Gemini 2.5 Flash
• Sufficient for testing and occasional manual processing
• Will hit 429 RESOURCE_EXHAUSTED errors when exceeded

Enabling Billing (Production Use):

1. Go to Google AI Studio
2. Create a new project (or use existing)
3. Settings → Billing → Link a billing account
4. Create new API key in the billing-enabled project
5. Update GOOGLE_AI_STUDIO_API_KEY in .env

Pricing (Gemini 2.5 Flash):

• Input: $0.30 per 1M tokens
• Output: $2.50 per 1M tokens
• Estimated cost per video: ~$0.003-0.015 (depending on length)
• Daily monitoring of ~20 videos: ~$0.10/day

Cost Tracking:
Monitor usage at Google AI Studio → Activity.

Related Files

• Directive: 005 Operations/Directives/process_video_content.md
• Scripts: 005 Operations/Execution/process_video_content.py, process_content_review.py
• Workflow: 005 Operations/Workflows/content-review-workflow.json

Voice Profiles

Voice profiles define how content should be written for specific personas or brands. They ensure consistent tone, style, and messaging across all generated content.

Location

Voice profiles live in 003 Entities/Voice Profiles/:

003 Entities/
└── Voice Profiles/
    ├── Chaplain TIG/
    │   └── Brand Voice.md
    └── GreenCal Construction/
        └── voice.md

Profile Structure

Each voice profile folder contains:

Available Profiles

Listing Available Profiles

# List all discoverable voice profiles
.venv/bin/python "005 Operations/Execution/wisdom_synthesizer.py" --list-voices

Output:

=== Available Voice Profiles ===

  GreenCal Construction
    Type: folder
    Path: .../Voice Profiles/GreenCal Construction/voice.md

  Chaplain TIG
    Type: folder
    Path: .../Voice Profiles/Chaplain TIG/Brand Voice.md

Using Voice Profiles

Voice profiles are used by both the video content pipeline and wisdom synthesizer:

# Video processing with default voice
.venv/bin/python "005 Operations/Execution/process_video_content.py" "https://..."

# Video processing with specific voice
.venv/bin/python "005 Operations/Execution/process_video_content.py" "https://..." --voice "Chaplain TIG"

# Wisdom synthesis with voice profile
.venv/bin/python "005 Operations/Execution/wisdom_synthesizer.py" \
  --vertical nonprofit --topic ai_adoption --voice "Chaplain TIG"

Creating New Profiles

1. Create folder: 003 Entities/Voice Profiles/{Profile Name}/
2. Create Brand Voice.md with:
   • Core voice attributes
   • Tone spectrum
   • Language preferences
   • Format examples
   • What to avoid
3. Link to supporting resources (wisdom libraries, etc.)

Why Voice Profiles as Entities

Voice profiles are entities (not just templates) because:

• They have identity and evolve over time
• Can link to people: linked_to: [[Person Name]]
• Scale to multiple profiles per person or organization
• Keep operations clean (just reference the profile)

Expert Intelligence System ⭐

Monitor thought leaders and subject matter experts across four platforms (YouTube, Twitter/X, LinkedIn, Newsletters), automatically capturing their new content, indexing it to the wisdom database, and sending Discord notifications.

Architecture

┌─────────────────────────────────────────────────────────────────────────────┐
│                        EXPERT INTELLIGENCE PIPELINE                          │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐    │
│  │YouTube Monitor│ │Twitter Monitor│ │LinkedIn Monitor│ │Newsletter Mon.│    │
│  │  (6 hours)    │ │  (6 hours)    │ │   (6 hours)   │ │  (12 hours)   │    │
│  │youtube_monitor│ │twitter_monitor│ │linkedin_monitor│ │newsletter_mon │    │
│  └───────┬───────┘ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘    │
│          │                 │                 │                 │             │
│          └─────────────────┴─────────────────┴─────────────────┘             │
│                                    │                                         │
│                                    ▼                                         │
│  ┌─────────────────────────────────────────────────────────────────┐        │
│  │                    Raw Captures (Obsidian-readable)              │        │
│  │  000 Inbox/___Intelligence/{youtube,twitter,linkedin,newsletters}│        │
│  └──────────────────────────────┬──────────────────────────────────┘        │
│                                 │                                            │
│                                 ▼                                            │
│  ┌─────────────────────────────────────────────────────────────────┐        │
│  │                   Wisdom Indexer (Claude API)                    │        │
│  │              Classifies by vertical, topic, concern              │        │
│  └──────────────────────────────┬──────────────────────────────────┘        │
│                                 │                                            │
│                                 ▼                                            │
│  ┌─────────────────────────────────────────────────────────────────┐        │
│  │                     .tmp/wisdom.db (SQLite)                      │        │
│  │               Queryable database of classified insights          │        │
│  └─────────────────────────────────────────────────────────────────┘        │
│                                 │                                            │
│                                 ▼                                            │
│  ┌─────────────────────────────────────────────────────────────────┐        │
│  │                  Discord #intel-digest Notifications             │        │
│  └─────────────────────────────────────────────────────────────────┘        │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

Missing Pixel Training Opportunity

The Expert Intelligence Pipeline is an excellent Tier 2 curriculum module covering:

• Multi-source data integration - YouTube, Twitter, LinkedIn, Newsletters into unified workflow
• n8n automation - Scheduled triggers, SSH execution, conditional logic, Discord notifications
• API integrations - YouTube Data API, Apify (Twitter/LinkedIn scraping), MS Graph (Outlook)
• Database design - SQLite for wisdom indexing, classification taxonomies
• Cost management - Understanding API billing (Gemini free tier vs paid)
• Troubleshooting - SSH authentication, rate limiting, API quotas

Students can shadow a working production system, then build their own expert monitoring pipeline for a topic of interest.

Expert Profiles

Expert profiles live in 003 Entities/Experts/ with YAML frontmatter supporting multiple platforms:

---
name: Qiusheng Wu
status: active
priority: A
fields: [gis, geospatial, python, remote-sensing]
platforms:
  youtube:
    url: https://youtube.com/@giswqs
    channel_id: <YOUTUBE_CHANNEL_ID>
    frequency: weekly
    last_checked: '2026-01-14T12:00:00'
  twitter:
    handle: giswqs
    last_checked: '2026-01-14T12:00:00'
---

Managing Experts

# Add a new expert with YouTube
.venv/bin/python "005 Operations/Execution/expert_registry.py" add "Simon Sinek" \
  --priority A --youtube "https://youtube.com/@simonsinek" --fields leadership,culture

# List all active experts
.venv/bin/python "005 Operations/Execution/expert_registry.py" list

# Get specific expert
.venv/bin/python "005 Operations/Execution/expert_registry.py" get "Simon Sinek"

Source 1: YouTube Monitoring

Monitor expert YouTube channels for new videos, then process through the content pipeline.

# Check all channels for new videos
.venv/bin/python "005 Operations/Execution/youtube_monitor.py" --check

# Check A-tier experts only
.venv/bin/python "005 Operations/Execution/youtube_monitor.py" --check --priority A

# Check and process new videos through content pipeline (transcribe + index)
.venv/bin/python "005 Operations/Execution/youtube_monitor.py" --check --process

n8n Workflow: expert-intelligence-workflow.json (every 6 hours)

Source 2: Twitter/X Monitoring

Monitor expert Twitter accounts for recent tweets using Apify.

# Check all experts with Twitter handles for recent tweets
.venv/bin/python "005 Operations/Execution/twitter_monitor.py" --check

# Check and process (capture + index to wisdom database)
.venv/bin/python "005 Operations/Execution/twitter_monitor.py" --check --process

# Check specific expert only
.venv/bin/python "005 Operations/Execution/twitter_monitor.py" --expert "Qiusheng Wu"

# Test specific handles directly
.venv/bin/python "005 Operations/Execution/twitter_monitor.py" --test-handles giswqs,deepseadawn

n8n Workflow: twitter-intelligence-workflow.json (every 6 hours)

Cost: ~$0.40 per 1,000 tweets via Apify (apidojo/tweet-scraper)

Source 3: Newsletter Monitoring

Monitor Outlook inbox for newsletters from whitelisted sources only.

# List whitelisted newsletter sources
.venv/bin/python "005 Operations/Execution/newsletter_monitor.py" --list

# Check for new newsletters (dry run first)
.venv/bin/python "005 Operations/Execution/newsletter_monitor.py" --check --dry-run

# Check and process new newsletters (capture + index)
.venv/bin/python "005 Operations/Execution/newsletter_monitor.py" --check --process

n8n Workflow: newsletter-intelligence-workflow.json (every 12 hours)

Whitelist: 003 Entities/Taxonomies/newsletter_intel_sources.yaml

sources:
  nir_eyal:
    name: Nir Eyal
    email: nir@nirandfar.com
    match_type: email
    priority: A
    topics: [productivity, behavior-design, habits]
  vp_land:
    name: VP Land
    domain: vpland.io
    match_type: domain
    priority: B
    topics: [drone-mapping, surveying, geospatial]

Source 4: LinkedIn Monitoring

Monitor LinkedIn profiles of watched experts for new posts. LinkedIn has become the professional "town square" as many thought leaders shift from Twitter/X.

# List LinkedIn-enabled experts
.venv/bin/python "005 Operations/Execution/linkedin_monitor.py" --list

# Test with a specific profile
.venv/bin/python "005 Operations/Execution/linkedin_monitor.py" --test-profile satyanadella

# Check for new posts (dry run first)
.venv/bin/python "005 Operations/Execution/linkedin_monitor.py" --check --dry-run

# Check and process new posts (capture + index)
.venv/bin/python "005 Operations/Execution/linkedin_monitor.py" --check --process

n8n Workflow: linkedin-intelligence-workflow.json (every 6 hours)

Cost: ~$5 per 1,000 posts via Apify (apimaestro/linkedin-profile-posts)

Priority Tiers

Reviewing Captured Intelligence

Option 1: Browse Raw Captures in Obsidian

000 Inbox/___Intelligence/
├── youtube/           # Full video transcripts with metadata
├── twitter/           # Tweet captures organized by expert
├── linkedin/          # LinkedIn posts organized by expert
└── newsletters/       # Newsletter content with frontmatter

Option 2: Query the Wisdom Database

# See what's available
.venv/bin/python "005 Operations/Execution/wisdom_query.py" --list-filters

# Get wisdom from a specific expert
.venv/bin/python "005 Operations/Execution/wisdom_query.py" --expert "Qiusheng Wu"

# Filter by topic
.venv/bin/python "005 Operations/Execution/wisdom_query.py" --topic gis --limit 10

# Last 7 days only
.venv/bin/python "005 Operations/Execution/wisdom_query.py" --days 7

Environment Variables

GOOGLE_API_KEY="xxx"          # YouTube Data API v3
APIFY_API_TOKEN="xxx"         # Twitter + LinkedIn scraping via Apify
MSGRAPH_CLIENT_ID="xxx"       # Outlook/newsletter access
MSGRAPH_CLIENT_SECRET="xxx"
MSGRAPH_TENANT_ID="xxx"
DISCORD_WEBHOOK_INTEL_DIGEST="xxx"  # #intel-digest notifications

Related Files

Directives:

• 005 Operations/Directives/expert_intelligence.md
• 005 Operations/Directives/twitter_intelligence.md
• 005 Operations/Directives/linkedin_intelligence.md
• 005 Operations/Directives/newsletter_intelligence.md

Scripts:

• expert_registry.py - Expert profile management
• youtube_monitor.py - YouTube channel monitoring
• twitter_monitor.py - Twitter/X monitoring via Apify
• linkedin_monitor.py - LinkedIn monitoring via Apify
• newsletter_monitor.py - Outlook newsletter monitoring
• digest_generator.py - Intelligence digest generation

Workflows:

• expert-intelligence-workflow.json (YouTube)
• twitter-intelligence-workflow.json (Twitter)
• linkedin-intelligence-workflow.json (LinkedIn)
• newsletter-intelligence-workflow.json (Newsletters)

Wisdom Synthesis System ⭐

Aggregate insights from multiple thought leaders across YouTube, Twitter, LinkedIn, and Newsletters, classify by audience vertical and topic, then synthesize audience-specific content with proper attribution and brand voice.

Architecture

┌─────────────────────────────────────────────────────────────────────────────┐
│                          WISDOM SYNTHESIS FLOW                               │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐│
│  │ YouTube Videos │ │ Twitter Tweets │ │ LinkedIn Posts │ │ Newsletters    ││
│  │ (transcripts)  │ │ (tweet text)   │ │ (post text)    │ │ (email content)││
│  └───────┬────────┘ └───────┬────────┘ └───────┬────────┘ └───────┬────────┘│
│          │                  │                  │                  │          │
│          └──────────────────┴──────────────────┴──────────────────┘          │
│                                 ▼                                            │
│                    ┌───────────────────────┐                                 │
│                    │    Wisdom Indexer     │                                 │
│                    │   (Claude API + SQL)  │                                 │
│                    └───────────┬───────────┘                                 │
│                                │                                             │
│           ┌────────────────────┼────────────────────┐                        │
│           ▼                    ▼                    ▼                        │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐              │
│  │   verticals     │  │     topics      │  │    concerns     │              │
│  │  (audiences)    │  │   (subjects)    │  │  (pain points)  │              │
│  │  nonprofit      │  │  ai_adoption    │  │  accuracy       │              │
│  │  surveying      │  │  trust          │  │  cost           │              │
│  │  healthcare     │  │  quality        │  │  compliance     │              │
│  └─────────────────┘  └─────────────────┘  └─────────────────┘              │
│                                │                                             │
│                                ▼                                             │
│                   ┌────────────────────────┐                                 │
│                   │   Wisdom Synthesizer   │                                 │
│                   │   + Voice Profile      │                                 │
│                   │   + Format Templates   │                                 │
│                   └────────────────────────┘                                 │
│                                │                                             │
│                                ▼                                             │
│        ┌───────────────────────────────────────────────┐                     │
│        │  linkedin_post │ twitter_thread │ newsletter  │                     │
│        │  talking_points │ email_outreach │ article    │                     │
│        └───────────────────────────────────────────────┘                     │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

Data Flow

1. Capture: Content from YouTube (transcripts), Twitter (tweets), Newsletters (email body)
2. Index: wisdom_indexer.py extracts insights, classifies by vertical/topic/concern
3. Query: wisdom_query.py retrieves wisdom by audience + topic + expert
4. Synthesize: wisdom_synthesizer.py generates attributed content with voice profile

Indexing Wisdom

# Index wisdom from processed video content
.venv/bin/python "005 Operations/Execution/wisdom_indexer.py" \
  "000 Inbox/___Content/20260111-020429" --expert "Pragmatic Architect"

# View database statistics
.venv/bin/python "005 Operations/Execution/wisdom_indexer.py" --stats

Querying Wisdom

# Find AI adoption wisdom for nonprofits
.venv/bin/python "005 Operations/Execution/wisdom_query.py" \
  --vertical nonprofit --topic ai_adoption

# Get leadership quotes from specific expert
.venv/bin/python "005 Operations/Execution/wisdom_query.py" \
  --expert "Simon Sinek" --topic leadership

# List available filters
.venv/bin/python "005 Operations/Execution/wisdom_query.py" --list-filters

Synthesizing Content

# Generate LinkedIn post for nonprofits about AI adoption
.venv/bin/python "005 Operations/Execution/wisdom_synthesizer.py" \
  --vertical nonprofit --topic ai_adoption --format linkedin_post

# Generate talking points for surveyors with GreenCal voice
.venv/bin/python "005 Operations/Execution/wisdom_synthesizer.py" \
  --vertical surveying --topic quality --format talking_points \
  --voice "GreenCal Construction" --save

# List available content formats
.venv/bin/python "005 Operations/Execution/wisdom_synthesizer.py" --list-formats

Content Formats

Taxonomies

Located in 003 Entities/Taxonomies/:

Output Location

Synthesized content saved to 000 Inbox/___Synthesis/:

000 Inbox/___Synthesis/
└── 20260111-025328-nonprofit.md

Each file includes:

• YAML frontmatter (format, vertical, topic, voice, timestamp)
• Generated content
• Source attribution with links

Wiki Links

Generated content includes Obsidian [[wiki links]] for knowledge graph building:

• Key concepts: [[Explainable AI]], [[Software Architecture]]
• Named people: [[Simon Sinek]], [[Geoffrey Hinton]]
• Organizations: [[OpenAI]], [[Google DeepMind]]

Social snippets remain link-free for platform export.

Related Files

• Directive: 005 Operations/Directives/wisdom_synthesis.md
• Scripts: wisdom_indexer.py, wisdom_query.py, wisdom_synthesizer.py
• Database: .tmp/wisdom.db (SQLite)
• Taxonomies: 003 Entities/Taxonomies/

Canonical Datetime System

The QWU Backoffice runs on an Azure VM in UTC timezone, but all user-facing operations use Pacific Time. The qwu_datetime module provides a single source of truth for date/time operations across all scripts.

Why This Matters

Without canonical timezone handling, morning briefings, calendar queries, and daily notes would display the wrong date for ~8 hours every day.

The Module: qwu_datetime.py

Location: 005 Operations/Execution/qwu_datetime.py

All QWU scripts MUST import from this module instead of using datetime.now() directly:

# CORRECT - Use canonical QWU datetime
from qwu_datetime import now, today, effective_date, format_date

current_time = now()          # Timezone-aware datetime in PST
current_date = today()        # Date in PST
log_date = effective_date()   # Date for logging (handles 4am boundary)

# WRONG - Never use these directly
from datetime import datetime
bad_time = datetime.now()     # Returns UTC on server!

Available Functions

Format Styles

Date styles (format_date):

• "iso" → 2026-01-08
• "display" → January 8, 2026
• "file" → 20260108
• "weekday" → Thursday, January 8, 2026
• "short" → Jan 8

Time styles (format_time):

• "12h" → 10:46 PM
• "24h" → 22:46
• "full" → 10:46:30 PM
• "log" → 22:46:30

Day Boundary Feature

Work before 4 AM counts as "yesterday" for logging purposes:

2:00 AM on Jan 9 → effective_date() returns Jan 8
5:00 AM on Jan 9 → effective_date() returns Jan 9

This prevents late-night sessions from bleeding into the next day's records.

Environment Variables

# Canonical timezone for all QWU operations (IANA format)
QWU_TIMEZONE=America/Los_Angeles

# Day boundary hour (work before this counts as "yesterday")
QWU_DAY_BOUNDARY_HOUR=4

Testing the Module

cd ~/qwu_backOffice && source .env
python "005 Operations/Execution/qwu_datetime.py"            # Human-readable status
python "005 Operations/Execution/qwu_datetime.py" --json     # JSON output

Sample output:

============================================================
QWU DATETIME STATUS
============================================================
Timezone:        America/Los_Angeles
Current offset:  -0800 (PST)
DST active:      False
Day boundary:    4:00 AM
------------------------------------------------------------
Now:             January 8, 2026 at 10:51 PM
Today:           Thursday, January 8, 2026
Effective date:  Thursday, January 8, 2026
============================================================

Scripts Updated

All execution scripts have been updated to use qwu_datetime:

Important: Any new scripts MUST import from qwu_datetime instead of using datetime.now() directly. This ensures consistent timezone handling across the entire codebase.

Lovable Frontend Standard (Foundational Directive)

Promoted to Foundational Directive: February 13, 2026

The same timezone problem affects all QWF Lovable apps. JavaScript's new Date().toISOString() returns UTC. After 4 PM Pacific (midnight UTC), the UTC date flips to the next calendar day. Since Supabase stores dates in Pacific time, all Supabase date-boundary queries silently return wrong results for 8 hours every day. No errors are thrown — dashboards just show empty/stale data.

Every QWF Lovable project must include src/utils/timezone.ts with 7 helper functions. This file is required in every Prompt 001 (foundation prompt) — see CLAUDE.md Lovable Prompt Conventions.

Canonical utility functions:

Wrong patterns (search and replace in every Lovable codebase):

new Date().toISOString().split('T')[0]     // UTC — wrong after 4 PM Pacific
new Date().toISOString().slice(0, 10)       // Same problem
new Date().toLocaleDateString()             // Locale-dependent, unreliable

Correct pattern:

import { getPacificToday, getPacificDaysAgo } from '@/utils/timezone';
const today = getPacificToday();              // Always Pacific YYYY-MM-DD
const weekAgo = getPacificDaysAgo(7);         // 7 days ago in Pacific

Why en-CA? The Canadian English locale formats dates as YYYY-MM-DD (ISO 8601), matching Supabase's date column format. Why America/Los_Angeles? IANA timezone name that handles PST/PDT transitions automatically — never hardcode -08:00.

History: First identified in HQ Command Center (Feb 2026, calendar edge function showed tomorrow's events after 4 PM). Recurred in QQT (11 affected locations) and QMP (18 affected locations) before the convention was established. Root cause: the original timezone directive called frontend JS "Generally safe" — this assessment was wrong for Supabase date queries and was corrected Feb 13, 2026.

3-layer defense:

1. Prevention: Every Prompt 001 must include timezone.ts (CLAUDE.md Lovable Prompt Conventions)
2. Enforcement: Agent instructions require Pacific helpers in all Lovable prompt code examples (never raw new Date())
3. Remediation: 005 Operations/Prompts/timezone-fix-handover.md for auditing/fixing legacy apps built before the convention

Apps fixed: QQT (Prompt 009), QMP (Prompt 008), Pocket Ez (Prompt 007). New apps built after Feb 2026 should not need remediation.

Full directive: 005 Operations/Directives/timezone_standard.md

Training Opportunities

Azure Cost Tracking

Monitor Azure spending directly from the backoffice for cost awareness. Azure is one of 7 variable cost sources tracked by the [[#Cost Intelligence System]] — see that section for the unified cost tracking architecture including LLM, Apify, Supabase, and budget alerting.

What's Tracked

Setup Requirements

Uses the same Azure Service Principal as VM control, but requires Cost Management Reader role:

az role assignment create \
  --assignee $AZURE_CLIENT_ID \
  --role "Cost Management Reader" \
  --scope "/subscriptions/$AZURE_SUBSCRIPTION_ID"

Environment Variables

AZURE_SUBSCRIPTION_ID="your-subscription-id"
AZURE_TENANT_ID="your-tenant-id"
AZURE_CLIENT_ID="your-client-id"
AZURE_CLIENT_SECRET="your-client-secret"

Usage

cd ~/qwu_backOffice && source .env
python "005 Operations/Execution/azure_costs.py"            # Human-readable output
python "005 Operations/Execution/azure_costs.py" --json     # JSON for automation
python "005 Operations/Execution/azure_costs.py" --dry-run  # Validate credentials

Sample Output

AZURE COST SUMMARY
========================================
Yesterday: $0.42
Month-to-date: $12.87
3-day avg: $0.38/day
----------------------------------------
Daily breakdown:
  2026-01-05: $0.35
  2026-01-06: $0.41
  2026-01-07: $0.42

Lead Generation System

The backoffice includes a comprehensive lead generation and enrichment system supporting L4G (Locals 4 Good) business development.

Full L4G Technical Documentation: 003 Entities/Organizations/Locals 4 Good.md

The L4G system includes:

• Website: locals4good.org (Lovable app, published Feb 27, 2026)
• Data Layer: Supabase (<SUPABASE_PROJECT_ID_L4G>) — 14 tables, migrated from Google Sheets
• APIs: 3 Supabase Edge Functions (submit-contact-form, create-checkout-session, check-availability)
• Payments: Stripe Checkout via create-checkout-session edge function + n8n L4G Stripe Payment Handler webhook
• Automation: n8n workflows for payment processing, contact pipeline
• Migration: Data migrated from Google Sheets → Supabase via migrate_l4g_sheets_to_supabase.py (Feb 27, 2026)

Lead Generation Webhook: https://n8n.quietlyworking.org/webhook/lead-request

Available Skills

Lead generation skills live in .claude/skills/:

Execution Scripts

Scripts in 005 Operations/Execution/:

Scraping Scripts:

Enrichment Scripts:

Delivery Scripts:

L4G Cold Email Pipeline

The L4G pipeline is specialized for fundraising cold email campaigns with a two-phase enrichment strategy.

Phase 1: Initial Cold Email (Minimal Cost)
Use for first outreach to new prospects:

1. Scrape from Google Maps (local businesses)
2. Clean company names with AI
3. Find 1-3 decision makers per company
4. Validate emails with Reoon (cheaper)
5. Group into competitor clusters (5-7 per group)

Phase 2: Full Enrichment (Post-Conversion)
Use only after prospect becomes a paying customer:

1. Deep personalization from website scraping
2. Google reviews + AI summaries
3. LinkedIn depth enrichment

Key Features:

• Decision Makers: 1-3 contacts per company with first names for personalization
• Email Validation: Reoon validates emails at lower cost than Anymail
• Competitor FOMO: "We're also reaching out to [Business A], [Business B]..."
• Deep Personalization: AI-extracted hooks from website scraping

Directive: 005 Operations/Directives/generate_l4g_leads.md

Cost Estimates (Per 100 Leads):

Output Destination

Lead data is delivered to Google Sheets (QWU Backoffice shared drive) for team access and further processing. The upload_to_sheets.py script handles the transfer.

Rate Limiting

All scraping scripts include rate limiting via api_rate_limiter.py to avoid bans and respect source terms of service.

Communications Architecture

The QWU ecosystem uses a hybrid communications approach.

Three Layers

Why Discord?

Discord Server Structure

🏠 QWU - UNIVERSE HUB
├── 📢 welcome-and-rules
├── 📢 announcements
├── 💬 general
├── 💬 off-topic
├── 🎉 wins
└── 💰 fundraising-general

🔒 STAFF
├── 🔒 leadership
├── 🔒 staff-only
├── 🔒 operations
└── 🔒 moderator-only

🤖 AGENTS (automation hub)
├── 🤖 agent-log           # Processing summaries
├── 🤖 inbox-alerts        # Notes needing review
├── 🔥 l4g-leads           # Lead notifications
├── 🔔 system-status       # VM/system alerts
└── 📊 daily-digest        # Morning summary

🎓 MISSING PIXEL
├── 📢 mp-announcements
├── 💬 mp-general
├── 📝 mp-assignments
├── ❓ mp-help (forum)
├── 🎨 mp-show-your-work
└── 📚 mp-resources

[Additional categories for ACOFH, IYSR, WOH, QWC, L4G, Community]

Discord Role Hierarchy

Webhook Configuration

Store webhook URLs in .env:

DISCORD_WEBHOOK_AGENT_LOG="https://discord.com/api/webhooks/xxx/yyy"
DISCORD_WEBHOOK_INBOX_ALERTS="https://discord.com/api/webhooks/xxx/yyy"
DISCORD_WEBHOOK_L4G_LEADS="https://discord.com/api/webhooks/xxx/yyy"
DISCORD_WEBHOOK_SYSTEM_STATUS="https://discord.com/api/webhooks/xxx/yyy"
DISCORD_WEBHOOK_DAILY_DIGEST="https://discord.com/api/webhooks/xxx/yyy"

Testing a Webhook

curl -X POST "$DISCORD_WEBHOOK_AGENT_LOG" \
  -H "Content-Type: application/json" \
  -d '{"content": "🧪 Webhook test successful!"}'

Data Architecture

SuiteDash vs Obsidian Boundaries

Principle: Agents facilitate intelligent handoffs between systems. SuiteDash handles transactional/operational data while Obsidian manages knowledge and insights.

Entity Resolution Security (Critical)

The Problem: Substring matching for entity lookups caused critical bugs where display names matched wrong entities.

Example Bug (2026-01-23): A BNI meeting recap email was incorrectly sent to "<EXTERNAL_EMAIL>" (an organization) because:

• Zoom display name: "Chapter President"
• Matched entity: "[Member Name], Associate Vice President..."
• Root cause: "president" substring exists in both strings

The Solution: Centralized entity_resolver.py with safety features:

from entity_resolver import resolve_for_enrichment

# Safe - uses centralized resolver with role blocklist
entity_path = resolve_for_enrichment("John Smith", caller="my_script.py")

# NEVER use substring matching directly:
# DANGEROUS: if name.lower() in f.stem.lower():

Key Features:

Scripts Migrated (18 total):

• All enrich_member_*.py scripts (6)
• All *_121_*.py and briefing scripts (5)
• All *_suitedash_*.py and sync scripts (5)
• predictive_intelligence.py, generate_connection_report.py, update_person_health.py

Rule: Any new script that looks up entity files MUST use entity_resolver.py. Never implement direct substring matching.

What to Store in Entity Notes (003 Entities/)

Mobile-to-Obsidian Workflow

Dual Input System:

• Drop files → 000 Inbox/___Capture/ (Claude artifacts, Perplexity exports, research)
• Quick dumps → 000 Inbox/Notes from my phone.md (rapid mobile text captures)

1. You drop files → 000 Inbox/___Capture/
   OR append quick notes → Notes from my phone.md
2. Agent splits quick notes into individual files → ___Capture/
3. Agent moves each file to → 000 Inbox/___Processing/
4. Agent enriches (YAML, tags, internal links)
5. High confidence → auto-filed to destination
   Low confidence → 000 Inbox/___Review/
6. You review items in ___Review/ (or auto-file based on threshold)
7. Final destination in appropriate folder

Project Organization

Naming Conventions

Projects in 002 Projects/ follow a visual naming convention that indicates lifecycle status at a glance.

Key principles:

• Underscore prefix (_) = ongoing, no foreseeable end date
• zzz-YYYYMMDD- prefix = completed (sorts to bottom, chronological within)

What Makes Something Evergreen?

Test: If you can't imagine a "done" state, it's evergreen.

Project Folder Structure

Every project folder contains:

_ProjectName/
├── _Overview.md              # Index/summary (required)
├── Task1.md                  # Individual tasks as files
├── Task2.md
├── SubProject/               # Sub-projects as folders
│   └── _Overview.md
└── zzz-20251215-Done Thing/  # Completed sub-work (bottom, chronological)

Special Files

Example: Client Container

_Aim High BNI Projects/               # Evergreen (client relationship)
├── _Overview.md                      # Client overview, active work
├── BNI Visitor Host.md               # Task (plain name)
├── 20260108 Presentation/            # Time-bound sub-project
│   └── _Overview.md
└── zzz-20251215-Holiday Card/        # Completed sub-project

Completing a Project

When a project, sub-project, or task is done:

1. Rename with zzz-YYYYMMDD- prefix: zzz-YYYYMMDD-Name/ or zzz-YYYYMMDD-Name.md
2. Add completion notes to the bottom of the _Overview.md or task file
3. Completed items sort to bottom (zzz- after letters)
4. Within completed items, chronological order (by date prefix)
5. Archive during annual reviews if list gets too long

Example folder: Conference 2026/ → zzz-20260315-Conference 2026/

Example task: Design Logo.md → zzz-20260115-Design Logo.md

Completion Notes Template

Add to the bottom of completed project/task files:

---

## Completion Notes (YYYYMMDD)

**Outcome:** [What was delivered/accomplished]

**Lessons Learned:**
- [Key insight 1]
- [Key insight 2]

**Deliverables:**
- [[Link to deliverable]]
- [External URL if applicable]

YAML Frontmatter Standards

Standard Schema for SOPs

---
uid: 20241229-143022
title: "Document Title"
created: 2024-12-20
modified: 2024-12-29
version: 2.0
version_date: 251229
type: [sop]
status: [evergreen]
program: [qwf]
dg-publish: true
tags: []
---

Document History Section

Every SOP includes at the bottom:

---

## Document History

*Do not use content below this line for operations.*

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 2.0 | 251229 | TIG | Added section X |
| 1.0 | 251220 | TIG | Initial release |

Publishing to Transparency Site

Notes with dg-publish: true in YAML frontmatter become eligible for transparency.quietlyworking.org. Publishing is fully automated — no Obsidian Digital Garden plugin needed.

How it works:

1. sync_transparency_site.py scans the vault for all .md files with dg-publish: true in YAML frontmatter
2. Transforms each file: YAML frontmatter → JSON frontmatter, generates permalink, resolves wikilinks
3. Pushes to QuietlyWorking/qwu_transparency GitHub repo
4. Vercel auto-deploys on push (~15 seconds)

To publish a note:

1. Add dg-publish: true to frontmatter
2. Run: python "005 Operations/Execution/sync_transparency_site.py" --json
3. Site updates live at transparency.quietlyworking.org

To keep private:

• Omit the field, or set dg-publish: false

Automated sync:

• After every /session-wrap-up (Step 3C)
• Daily at 4 AM Pacific via n8n workflow YnawyFKfnrOao12P
• Discord notification to #system-status on success/failure

Safety features:

• Private User Manual (QWU Backoffice User Manual.md) is blocklisted by filename stem — only the [PUBLIC] version passes
• Leak detection scans for IP patterns, API tokens, SSH commands before pushing
• --dry-run flag for previewing changes without pushing

Key files:

Currently published pages (14 files):

• Table of Contents (home), QWU Values, Tool Shed, Nonprofit Tech Access Guide
• QWC, Locals 4 Good, Code & Tips Swipe Page, OMW, IP Rights
• 3 SOPs (User Manual [PUBLIC], BNI Workflow, Automation Workflow)
• 2 Resource pages (Unreal Hotkeys, GoBrunch Media Note)

Docker Fundamentals: Running Isolated Tasks

Docker lets you run code in isolated "containers"... mini computers that do one job and disappear. Your VM stays clean, and every task runs the same way every time.

Key Concepts

Lesson 1: Run a Simple Command

docker run ubuntu echo "Hello from inside a container!"

What happens:

1. Docker downloads the ubuntu image (first time only)
2. Creates a container from that image
3. Runs your command inside it
4. Container disappears when done

Lesson 2: Interactive Container

docker run -it ubuntu bash

The flags:

• -i = interactive (keep input open)
• -t = terminal (give me a prompt)

Your prompt changes to something like root@a3b2c1d4:/#... you're INSIDE the container!

Lesson 3: Run Python Without Installing Python

docker run python:3.11 python -c 'print("Hello from Python 3.11")'

Docker grabs Python 3.11 and runs your code. You never installed Python on your VM!

Lesson 4: Access Your Files from Inside a Container

docker run -v $(pwd):/app -w /app python:3.11 python -c 'import os; print(os.listdir("."))'

The magic flags:

• -v $(pwd):/app = Mount current folder INTO the container at /app
• -w /app = Start working in that folder

Lesson 5: Run a Script with Dependencies

docker run -v $(pwd):/app -w /app python:3.11 sh -c 'pip install -r requirements.txt && python your_script.py'

Lesson 6: Pass Environment Variables (API Keys)

Never hardcode API keys! Pass them securely:

docker run -v $(pwd):/app -w /app --env-file .env python:3.11 python your_script.py

Quick Reference: Docker Commands

Real-World Pattern: Running an Agent

docker run \
  -v $(pwd):/app \
  -w /app \
  --env-file .env \
  python:3.11 \
  sh -c 'pip install -r requirements.txt && python execution/your_agent.py'

Docker Sandbox Security

Files in .devcontainer/

Domain Allowlist Categories

# Core services (required)
CORE_DOMAINS=(
    "api.anthropic.com"
    "registry.npmjs.org"
    "github.com"
    "marketplace.visualstudio.com"
)

# Package registries
PACKAGE_DOMAINS=(
    "pypi.org"
    "files.pythonhosted.org"
    "registry.yarnpkg.com"
)

# MCP servers (QWF n8n)
MCP_DOMAINS=(
    "n8n.quietlyworking.org"
    "vistasocial.com"
)

Adding New Domains

1. Edit .devcontainer/init-firewall.sh
2. Add domain to appropriate array
3. Rebuild container: Command Palette → Dev Containers: Rebuild Container

Verifying Firewall

View logs inside container:

cat /var/log/firewall-init.log

Meeting Intelligence System ⭐

Overview

The Meeting Intelligence System transforms Zoom meetings from isolated events into relationship intelligence nodes. Every meeting captures context, every briefing surfaces that context, and over time the system builds a comprehensive map of your professional relationships.

Components:

1. Post-Meeting Processing - Automatically processes Zoom recordings when ready
2. Pre-Meeting Briefings - Generates relationship-aware briefings before meetings
3. Historical Import - Bootstraps the system with past meeting data
4. Transcript Archive - Searchable meeting transcripts deep-linked to Person files

The Intelligence Flywheel

Meeting Scheduled (Calendar)
       ↓
Briefing Generated (20 min before)
   - Pulls context from transcript archive
   - Shows interaction history
   - Lists open action items
       ↓
Meeting Happens
   - You enter prepared
   - Better conversation quality
       ↓
Recording Processed (Zoom Pipeline)
   - Uses calendar attendees for accurate matching
   - Links to Person/Org files
   - Captures decisions, actions, goal alignment
       ↓
Transcript Archived
   - Full text searchable
   - Deep-linked from Person files
       ↓
Next Meeting with Same People
   - Briefing has richer history
   - Pattern recognition emerges

Post-Meeting Processing (Zoom Pipeline)

Trigger: n8n webhook when Zoom recording is ready

Pipeline Stages:

1. Download - OAuth authentication, VTT transcript parsing (inline speaker format + <v> tags)
2. Analyze - Claude API extracts topics, decisions, action items, goal alignment
3. Calendar Enrichment - Match to Google Calendar event for attendee emails
4. Resolve Entities - Match participants to Person/Org files (uses calendar + transcript speakers + analysis-derived names)
5. Contact History - Record interaction in relationship intelligence
6. Person Insights - Extract and update Person files with intelligence, action items, quotes
7. Update Vault - Append meeting section to daily note (dedup-aware, replaces stale sections)
8. Link Projects - Detect and link to relevant project files (word-boundary matching, stop words)
9. HQ Tasks - Owner-based routing: TIG's action items → ___Tasks/ files (sync to HQ), other people's items → entity files (003 Entities/People/[Name].md under "Their Commitments") + Discord notification

Scripts:

Pipeline Flowchart: See 005 Operations/Execution/zoom_pipeline_flowchart.md for the full 8-stage visual diagram including follow-up emails, BCC monitoring, and error handling.

Usage:

# Manual processing (rare - usually triggered by webhook)
.venv/bin/python "005 Operations/Execution/zoom_pipeline.py" --meeting-id ABC123 --json

# With test fixtures (no API calls)
.venv/bin/python "005 Operations/Execution/zoom_pipeline.py" --meeting-id test-123 --use-fixtures --dry-run

Appreciation Followup System (SMS Wait-for-Response)

v1.1 | Updated 2026-03-01 (v1.0 created 2026-02-08)

When send_meeting_followup.py can't find specific quotes for an attendee, instead of immediately sending a generic fallback, it now defers the email and asks TIG for a personal appreciation via SMS. The system waits up to 5 hours for TIG's reply before falling back to the generic message.

Timeline:

• T+0: SMS asks TIG "What do you appreciate about {name}?" — email is staged (not sent)
• T+1h: No response? SMS reminder 1
• T+2h: No response? SMS reminder 2 (last call)
• T+5h: No response? Send email with generic warm fallback, notify TIG
• Any time before T+5h: TIG replies via SMS → personalized email sent immediately

Three actors:

State: appreciation_followup_db.py v1.1.0 with pending_appreciations + appreciation_audit_log tables. Race safety via BEGIN IMMEDIATE transactions.

Commands via SMS (when appreciations are pending):

• Free-form text — used as the personalized appreciation for the next pending attendee
• "skip" / "next" / "pass" — sends the generic fallback immediately
• "don't send to John" / "cancel follow-up for Miller" — cancels the follow-up entirely (no email sent, not even fallback)
• "cancel all" — cancels all pending follow-ups
• Multi-recipient: "don't send to John or Miller" — cancels specific people by name

LLM-based intent classification (v3.5.0): When appreciations are pending, all inbound messages (except compliance, health vitals, and video commands) are routed through an LLM classifier (STANDARD tier) that determines: appreciation text, cancel request, skip, or unrelated. Unrelated messages (e.g., "what's on my calendar?") fall through to normal routing. This replaced a keyword-exclusion list that falsely matched words like "meeting" as calendar queries.

n8n workflow: appreciation-queue-poller.json (ID: <WORKFLOW_ID>) — every 5 min, SSH to poller script, logs actions to #agent-log, SSH errors to #system-status.

Meeting Reconciliation System (Defense-in-Depth)

v2.0 | Updated 2026-01-26

The system ensures zero silent failures through 4-layer protection. With 2-5 Zoom meetings per week, every meeting must be captured for relationship intelligence.

Architecture:

┌───────────────────────────────────────────────────────────────────────┐
│  LAYER 1: Webhook (Primary Path)                                      │
│  ┌──────────┐    ┌──────────────┐    ┌────────────┐                  │
│  │ Zoom     │───▶│ zoom_        │───▶│ #daily-    │ (success)        │
│  │ Webhook  │    │ pipeline.py  │    │ digest     │                  │
│  └──────────┘    └──────┬───────┘    └────────────┘                  │
│                         │            ┌────────────┐                  │
│                         └───────────▶│ #system-   │ (failure)        │
│                                      │ status     │                  │
├───────────────────────────────────────────────────────────────────────┤
│  LAYER 2: Daily Reconciliation (Safety Net) - 9 PM Pacific            │
│  ┌──────────┐    ┌──────────────┐    ┌────────────┐                  │
│  │ 9 PM     │───▶│ zoom_        │───▶│ Catches    │                  │
│  │ Schedule │    │ reconcile.py │    │ 7-day      │                  │
│  └──────────┘    │ --days 7     │    │ misses     │                  │
│                  └──────────────┘    └────────────┘                  │
├───────────────────────────────────────────────────────────────────────┤
│  LAYER 3: Weekly Deep Scan (Full Recovery) - Sunday 3 AM              │
│  ┌──────────┐    ┌──────────────┐    ┌────────────┐                  │
│  │ Sunday   │───▶│ zoom_        │───▶│ Catches    │                  │
│  │ 3 AM     │    │ reconcile.py │    │ 30-day     │                  │
│  └──────────┘    │ --days 30    │    │ misses     │                  │
│                  │ --retry-     │    │ + retries  │                  │
│                  │ failed       │    │ failures   │                  │
│                  └──────────────┘    └────────────┘                  │
├───────────────────────────────────────────────────────────────────────┤
│  LAYER 4: Health Monitoring (Observability) - Every 4 hours           │
│  ┌──────────┐    ┌──────────────┐    ┌────────────┐                  │
│  │ Every    │───▶│ zoom_health_ │───▶│ Alerts if  │                  │
│  │ 4 hours  │    │ check.py     │    │ unhealthy  │                  │
│  └──────────┘    └──────────────┘    └────────────┘                  │
├───────────────────────────────────────────────────────────────────────┤
│                      ┌────────────────────────┐                      │
│                      │  meetings_tracker.db   │                      │
│                      │  (005 Operations/Data/)│                      │
│                      │  • Locking prevents    │                      │
│                      │    race conditions     │                      │
│                      │  • Status tracking     │                      │
│                      └────────────────────────┘                      │
└───────────────────────────────────────────────────────────────────────┘

How It Works:

1. Layer 1 (Webhook): Zoom webhook fires → n8n SSH to zoom_pipeline.py → success to #daily-digest, failure to #system-status
2. Layer 2 (Daily): 9 PM Pacific queries Zoom API for last 7 days → processes any missed webhooks
3. Layer 3 (Weekly): Sunday 3 AM deep scan of last 30 days → force-retries failed meetings
4. Layer 4 (Health): Every 4 hours checks pending count, failure count, hours since success → alerts if unhealthy
5. Locking: SQLite exclusive transactions prevent webhook/reconciliation race conditions

Scripts:

n8n Workflows:

Usage:

# Check health status
.venv/bin/python "005 Operations/Execution/zoom_health_check.py"
.venv/bin/python "005 Operations/Execution/zoom_health_check.py" --json

# Check reconciliation status
.venv/bin/python "005 Operations/Execution/zoom_reconcile.py" --status

# Dry-run reconciliation (check what would be processed)
.venv/bin/python "005 Operations/Execution/zoom_reconcile.py" --dry-run --json

# Run reconciliation (7-day lookback)
.venv/bin/python "005 Operations/Execution/zoom_reconcile.py" --json

# Run deep scan (30-day lookback with retry-failed)
.venv/bin/python "005 Operations/Execution/zoom_reconcile.py" --days 30 --retry-failed --json

# Check tracker stats
.venv/bin/python "005 Operations/Execution/meeting_tracker.py" --stats

# List Zoom recordings from last 7 days
.venv/bin/python "005 Operations/Execution/zoom_list_recordings.py" --days 7

Failure Scenarios:

Missing Pixel Training Opportunity (Tier 3: Specialist)

The Defense-in-Depth architecture teaches enterprise-grade reliability patterns:

• Multi-layer redundancy - Primary + backup + deep scan + monitoring (defense-in-depth)
• SQLite locking - Exclusive transactions, stale lock detection, race condition prevention
• n8n error handling - onError: continueErrorOutput, error branches, failure alerting
• Health monitoring - Threshold-based alerting, status dashboards, observability
• Idempotent design - Making operations safe to retry without side effects

Exercise: Design a Defense-in-Depth system for a different webhook service (e.g., Stripe payments). Include: (1) primary webhook handler with error alerting, (2) daily reconciliation, (3) weekly deep scan, (4) health monitoring. Document your 4-layer architecture diagram.

Pre-Meeting Briefings

Trigger: n8n polls calendar every 15 minutes, generates briefings 20 minutes before meetings

Briefing Includes:

• Attendee profiles with circle status (inner, trusted, professional, new)
• Last interaction history (from daily notes)
• Open action items (unchecked tasks mentioning the person)
• Organization context
• Suggested agenda template
• "Definition of Success" placeholders

Scripts:

Usage:

# Check upcoming meetings
.venv/bin/python "005 Operations/Execution/calendar_monitor.py" --check-upcoming --minutes 60

# Generate briefings for next hour
.venv/bin/python "005 Operations/Execution/calendar_monitor.py" --check-upcoming --generate-briefings --minutes 60 --dry-run

# Manual briefing for specific meeting
.venv/bin/python "005 Operations/Execution/meeting_briefing.py" --topic "Q1 Planning" --names "Sue,[Participant]" --duration 60

Pre-Meeting Prep Emails ⭐ NEW

v1.0 | Added 2026-02-07

Automated 7-day-ahead emails to external meeting attendees, sent in Ezer's voice. Also generates 30-day enriched briefings for the HQ Command Center "Upcoming Meetings" module.

Architecture:

Google Calendar (30-day lookahead)
       ↓
Filter External Attendees (skip TIG, @quietlyworking.org, resource calendars)
       ↓
Vault Enrichment (entity file, meeting history, outstanding actions, intelligence)
       ↓
Contact History (last contact date, relationship health assessment)
       ↓
├── [7-day emails] → SQLite dedup check → MS Graph send → Discord #agent-log
└── [30-day briefings] → Enriched JSON → HQ Upcoming Meetings module

Key Features:

• 7-day lookahead emails — Warm, concise prep email asking attendees for agenda input
• 30-day enriched briefings — Full attendee profiles with vault data, relationship health, outstanding actions
• SQLite dedup — UNIQUE(event_id, attendee_email) prevents duplicate sends
• Relationship health assessment — thriving (≤14d) → healthy (≤30d) → stable (≤60d) → cooling (≤90d) → dormant (>90d)

Scripts:

n8n Workflows:

Usage:

# Send 7-day prep emails (dry run)
.venv/bin/python "005 Operations/Execution/send_meeting_prep_email.py" send --dry-run --json

# Generate 30-day enriched briefings for HQ module
.venv/bin/python "005 Operations/Execution/send_meeting_prep_email.py" briefings --days 30 --json

# Check send status
.venv/bin/python "005 Operations/Execution/send_meeting_prep_email.py" status --json

# Cleanup old records (60+ days)
.venv/bin/python "005 Operations/Execution/send_meeting_prep_email.py" cleanup --days 60

HQ Integration:
The briefings subcommand returns enriched JSON consumed by the HQ Command Center's "Upcoming Meetings" module. Each meeting includes: attendee vault profiles, last met date, outstanding actions, intelligence snippets, relationship health scores, and prep email status.

See 002 Projects/_HQ Command Center/handoff-meeting-intelligence-pipeline.md for the full JSON schema and HQ integration guide.

Meeting-Ready BNI 1-2-1 Briefings ⭐ NEW

v1.0 | Added 2026-01-20

Enhanced briefings specifically for BNI 1-2-1 meetings that serve as working documents during the meeting itself (not just pre-meeting prep).

Key Features:

1. Template Integration - Maps BNI 1-2-1 Meeting Template questions to entity data
2. Intel Status Indicators:
   • ✅ Confirmed - Data exists in entity file
   • ⚠️ Partial - Data exists but needs verification
   • ❓ Unknown - Need to ask during meeting
3. Enhanced Review Intel:
   • Star distribution table (count at each 1-5 star level)
   • Verbatim customer quotes (10-20 examples)
   • "No negative reviews" explicit messaging
   • Review trends (improving/stable/declining)
4. Meeting Capture Space - Action items, relationship assessment, notes

Usage:

.venv/bin/python "005 Operations/Execution/generate_121_briefing.py" "[Member Name]" \
  --date "2026-01-20" --time "13:00" --location "In-person" --type "BNI 1-2-1"

Output Sections:

• Quick Contact info
• Customer Review Intel (star distribution, verbatim quotes)
• Discovery Checklist (with intel status for each template question)
• Power Team Exploration
• Personal Connection gaps
• Communication Preferences
• My Referral TO Them (capture space)
• Action Items (my commitments, their commitments, next 1-2-1)
• Relationship Assessment

Related Scripts:

1-2-1 Recording Processing ⭐ NEW

v1.0 | Added 2026-01-21

Process audio recordings from in-person 1-2-1 meetings (Voice Memos, etc.) into structured intelligence for Person entity files.

Pipeline:

Audio Recording (Voice Memo/m4a)
       ↓
[Compress if >25MB] (ffmpeg)
       ↓
[transcribe_121_recording.py] → Whisper API
       ↓
Transcript (.json + .md)
       ↓
[extract_121_insights.py] → Claude API
       ↓
Structured Insights (personal, professional, action items)
       ↓
Entity File Update
       ↓
[Archive & Cleanup]
├── Transcripts → 100 Resources/Meeting Transcripts/YYYY/YYYYMMDD-slug/
├── Recording → Google Drive: Meetings/YYYY/YYYYMMDD-slug/
└── Delete .tmp files

File Storage Architecture:

Naming Convention: YYYYMMDD-firstname-lastname-121 (all lowercase, hyphens)

Scripts:

Usage:

# Step 1: Transcribe
.venv/bin/python "005 Operations/Execution/transcribe_121_recording.py" \
  --file /path/to/recording.m4a --person "[Member Name]"

# Step 2: Extract insights (preview first)
.venv/bin/python "005 Operations/Execution/extract_121_insights.py" \
  --file .tmp/121_transcripts/2026-01-21_Ramona_Petersen_transcript.json --preview

# Step 3: Apply to entity
.venv/bin/python "005 Operations/Execution/extract_121_insights.py" \
  --file .tmp/121_transcripts/2026-01-21_Ramona_Petersen_transcript.json --update-entity

# Step 4: Archive (after verifying entity updates)
mkdir -p "100 Resources/Meeting Transcripts/2026/20260121-ramona-petersen-121"
mv .tmp/121_transcripts/*Ramona* "100 Resources/Meeting Transcripts/2026/20260121-ramona-petersen-121/"

# Step 5: Upload recording to Drive
.venv/bin/python "005 Operations/Execution/gdrive_upload.py" \
  --file ".tmp/original.m4a" --folder "Meetings/2026/20260121-ramona-petersen-121" --name "original.m4a"

Directive: 005 Operations/Directives/process_121_recording.md

Historical Import

Import past Zoom recordings to bootstrap relationship intelligence.

What it does:

• Scans local folder of downloaded Zoom recordings
• Parses VTT transcripts
• Archives as searchable markdown in 100 Resources/Meeting Transcripts/
• Creates draft Person files for unknown people
• Updates existing Person files with meeting history
• Deep-links everything

Script: zoom_history_import.py

Usage:

# Scan without changes
.venv/bin/python "005 Operations/Execution/zoom_history_import.py" --scan

# Full import (transcripts + drafts + history)
.venv/bin/python "005 Operations/Execution/zoom_history_import.py" --full-import

# Dry run first
.venv/bin/python "005 Operations/Execution/zoom_history_import.py" --full-import --dry-run

Transcript Archive

Location: 100 Resources/Meeting Transcripts/

Format: Searchable markdown with YAML frontmatter

---
type: meeting-transcript
tags: [transcript, imported]
source: "Auto-generated from private manual v3.30 by generate_public_manual.py"
generated: "2026-03-02 07:06"
date: 2025-07-18
topic: "Time with Sue & [Participant]"
duration_minutes: 69
word_count: 6103
speakers: [TIG, [Member Name]]
---

Deep-linked from Person files:

- **2025-07-18** - Time with Sue & [Participant] (69 min) 📝

Configuration

Environment Variables:

# Zoom OAuth (required for live processing)
ZOOM_ACCOUNT_ID=your_account_id
ZOOM_CLIENT_ID=your_client_id
ZOOM_CLIENT_SECRET=your_client_secret
ZOOM_WEBHOOK_SECRET=your_webhook_secret

# Google Calendar (already configured)
GOOGLE_CALENDAR_CREDENTIALS=/path/to/service-account.json
GOOGLE_CALENDAR_MAIN=calendar_id@group.calendar.google.com

# Discord (for notifications)
DISCORD_WEBHOOK_DAILY_DIGEST=https://discord.com/api/webhooks/...

# Anthropic (for analysis)
ANTHROPIC_API_KEY=your_api_key

n8n Workflows:

Directives:

• 005 Operations/Directives/pre_meeting_briefing.md
• 005 Operations/Directives/process_zoom_recording.md
• 005 Operations/Directives/process_121_recording.md

Phase 3 Roadmap

Review scheduled: April 10, 2026

Potential enhancements:

• Morning digest (all meetings for the day)
• Relationship health alerts ("You haven't met with X in 30 days")
• AI-suggested meeting prep questions
• Post-meeting auto-follow-up drafts → ✅ Built (send_meeting_followup.py v1.3.0 — personalized action items, deferred appreciation with SMS wait-for-response, preference footer, opt-out check)
• Appreciation wait-for-response (SMS retry + timeout + cancel) → ✅ Built (appreciation_followup_db.py v1.1.0 + process_appreciation_queue.py v1.0.0 — T+1h/T+2h SMS reminders, T+5h fallback email, Twilio reply handler, LLM-based cancel via SMS)
• Pre-meeting prep emails → ✅ Built (send_meeting_prep_email.py — preference footer, opt-out check)
• Meeting pattern analytics
• Voice capture for quick context additions

Outlook Email Processing ⭐

Overview

The Outlook Email Processing system automatically monitors Microsoft 365 Outlook inbox and sent items, classifies emails, resolves sender entities, updates vault files with correspondence history, and creates tasks for action items. It integrates with SuiteDash CRM for relationship-aware processing.

Philosophy: Email handles people and conversations. RSS feeds handle content and newsletters. This separation keeps the vault focused on relationships.

Pipeline Architecture

Outlook (Inbox + Sent Items)
     │
     ▼
[outlook_fetch_emails.py] ← Microsoft Graph API (OAuth2)
     │  Fetch from: Inbox, SentItems
     │
     ▼
[email_classify.py] ← Claude API
     │  Classifications: action-required, waiting-on, informational,
     │                   conversation, transactional, newsletter
     │
     ▼
[email_entity_resolve.py]
     │  1. Match contact → Person file (email, name, alias)
     │     - Received: resolve sender
     │     - Sent: resolve recipient
     │  2. Query SuiteDash CRM (if not in vault)
     │  3. Create [DRAFT] for significant unknowns
     │  4. Detect circle tier (inner/trusted/professional/new)
     │
     ├── VIP? → Discord #inbox-alerts (immediate)
     │
     ▼
[email_update_vault.py]
     ├── Person file: ### Email Thread section
     ├── Daily journal: ## Email Activity table
     │
     ▼
[email_task_create.py] (if action-required)
     │  → 000 Inbox/___Tasks/
     │
     ▼
[Newsletter Audit] (if newsletter detected)
     └── → 000 Inbox/___Review/Newsletter-Audit.md

Email Classification Types

VIP Handling

VIP contacts get immediate Discord notifications and priority processing:

• Inner circle contacts (from SuiteDash)
• Emails/domains in OUTLOOK_VIP_EMAILS / OUTLOOK_VIP_DOMAINS

Scripts

Task Creation Intelligence (v1.3.0)

Not all action-required emails need a task. The system uses intelligent filtering to reduce noise:

Task Creation Rules:
Only create a task when ALL conditions are met:

1. Classification is action-required
2. effort_level is moderate or significant (not trivial/quick)
3. action_type is research or project (not reply/calendar/routine)
4. Due date is in the future (or not set)
5. Email is NOT forwarded (no "Fw:", "Fwd:" prefix)
6. Subject doesn't match exclude patterns in OUTLOOK_TASK_EXCLUDE_PATTERNS
7. No existing task for same person + similar topic in last 7 days

What DOESN'T Become a Task:

Classification Fields (from Claude):

• effort_level: trivial, quick, moderate, significant
• action_type: reply, calendar, research, project, routine

Duplicate Detection:

• Jaccard similarity (70% threshold) checks existing task titles
• Person+topic dedup: Skip if same person + 2+ matching keywords in last 7 days
• Prevents task pile-up from repeated email reminders

Person Consolidation:

• Multiple action items from the same person/org are grouped into one consolidated task
• Consolidated tasks include a checklist of all action items with email context
• Uses the highest priority among all grouped items
• Tagged with ["email-task", "consolidated"] for filtering

Environment Variable:

# Add to .env for pattern-based filtering
OUTLOOK_TASK_EXCLUDE_PATTERNS=BNI: A visitor has registered,Your invoice is ready,Your weekly report

Example: If Alice sends 3 research-related emails, the system creates one task "Multiple action items from Alice Smith (3 items)" with a checklist. But if she sends a quick "yes, confirmed" reply, no task is created.

Usage

# Manual run (usually triggered by n8n)
.venv/bin/python "005 Operations/Execution/outlook_pipeline.py" --json

# With options
.venv/bin/python "005 Operations/Execution/outlook_pipeline.py" \
  --limit 10 \
  --dry-run \
  --json

# Test with fixtures
.venv/bin/python "005 Operations/Execution/outlook_pipeline.py" \
  --use-fixtures \
  --dry-run \
  --json

n8n Workflow

Workflow: outlook-email-workflow.json
Schedule: Every 15 minutes

Flow:

Schedule Trigger (every 15 min)
    → SSH: Run outlook_pipeline.py --json
    → Parse JSON output
    → If emails_processed > 0:
        → Post to #agent-log
        → If vip_count > 0: Post to #inbox-alerts (VIP alert)
        → If tasks_created > 0: Post to #inbox-alerts (task alert)

Directive

Full documentation: 005 Operations/Directives/process_outlook_email.md

SuiteDash CRM Integration ⭐

Overview

SuiteDash is QWF's CRM platform. The QWU Backoffice integrates with SuiteDash to provide relationship-aware automation across all pipelines (email, meetings, briefings).

Key Concepts:

• Circles = SuiteDash groupings that control portal access and marketing
• Tiers = QWF relationship levels (Inner, Trusted, Professional, New)
• Two-way sync = Vault Person files ↔ SuiteDash contacts

Circle Architecture

The Two Circle Systems

Tier → Priority Mapping

SuiteDash Circle Names

Two-Way Sync Architecture

┌─────────────────────┐         ┌─────────────────────┐
│  Obsidian Vault     │         │  SuiteDash CRM      │
│  003 Entities/      │         │                     │
│  People/*.md        │◀───────▶│  Contacts           │
│                     │         │                     │
│  - YAML frontmatter │  sync   │  - Custom fields    │
│  - circle: trusted  │─────────│  - Circle membership│
│  - suitedash_id     │         │  - Program status   │
└─────────────────────┘         └─────────────────────┘

Sync Direction 1: Vault → SuiteDash

Script: vault_to_suitedash.py
Schedule: Daily at 6:00 AM Pacific
What syncs: Person file frontmatter → SuiteDash custom fields

Sync Direction 2: Tier → Circles

Script: circle_sync.py
Schedule: Daily at 6:30 AM Pacific (after vault sync)
What syncs: Person's calculated tier → SuiteDash Circle membership

How tier is determined:

1. Read Person's program statuses from vault frontmatter
2. Apply tier mapping (e.g., MP maintainer = Inner, QWC active = Trusted)
3. Use highest applicable tier
4. Update SuiteDash Circle membership

Scripts

n8n Workflows

Usage

# Vault → SuiteDash sync
.venv/bin/python "005 Operations/Execution/vault_to_suitedash.py" --all --json

# Circle tier sync
.venv/bin/python "005 Operations/Execution/circle_sync.py" --all --json

# Dry run (preview without changes)
.venv/bin/python "005 Operations/Execution/circle_sync.py" --all --dry-run --json

Integration Points

SuiteDash CRM data is used by:

• Email Processing → Detect circle tier for priority handling
• Meeting Intelligence → Include circle status in briefings
• Pre-Meeting Briefings → Show relationship context
• Entity Resolution → Create full Person files for unknown contacts found in CRM

Directives

Full documentation:

• 005 Operations/Directives/circle_architecture.md (comprehensive tier definitions)
• 005 Operations/Directives/sync_vault_to_suitedash.md (vault → CRM sync)

Transcript Extraction System (Planned)

Purpose

Extract detailed transcripts from Claude Code sessions for:

• Student curriculum (showing how agents think)
• Transparency publishing
• Debugging and improvement

Adaptation from Simon Willison's Tool

Based on claude-code-transcripts, adapted for QWU:

Output Location

qwu_backOffice/
└── transparency/
    └── agent-transcripts/
        ├── _index.md
        ├── 2024-12-30-backoffice-auth-fix.md
        └── 2024-12-30-vista-social-setup.md

Status: Planning phase. Implementation TBD.

Ez/Ezer Mascot

QWF's official mascot... an intelligent, empathetic octopus composed of transformable pixel-blocks.

Character Details

Why an Octopus?

• Multiple arms reaching out to help
• Highly intelligent and adaptable
• Each arm can work independently (like QWF's programs)
• Soft exterior, strong interior (vulnerability + strength)

Character Bible Location

Full character bible (visual guidelines, personality, animation principles) stored in:
Resources/Brand/ez-ezer-character-bible.md

Ez Terminal (Scheduler) ⭐ NEW

Added: Session 42 (January 23, 2026) | Updated: Session 48 (January 24, 2026)

The Ez Terminal is an interactive retro-styled terminal interface for scheduling appointments with TIG. Available at https://qwu-twin.quietlyworking.org (port 8765)

Version History

Features

Core Scheduling:

• Circle-based scheduling with access tiers (inner, trusted, professional, new, unknown)
• Calendar integration with Google Calendar
• Multiple theme support (green, amber, matrix, deep sea, synthwave)

Engagement Systems:

• Daily Wisdom: Rotating quotes from TIG's reading list, one per day per visitor
• Smart Suggestions: Contextual command recommendations based on session state
• Oregon Trail: Classic game ported to JavaScript with full save/load support
• QWU Universe: Text adventure exploring the QWF ecosystem (v5.0.0)
• TIG Trivia: Quiz game on TIG izms, QWF programs, and pop culture (v5.0.0)
• Guestbook: Leave messages for future visitors (v5.0.0)

Achievement System (v3.9.0 → v5.0.0):

• 47 achievements across 8+ categories (expanded in v5.0.0):
  • Explorer (navigation), Traveler (visits), Sage (wisdom), Connector (scheduling)
  • Timekeeper (sessions), Lorekeeper (stories), Legendary (epic feats), Hidden (secrets)
  • Adventurer (games, trivia, guestbook), Easter Eggs (secrets found)
• 5-tier point system: Bronze (10), Silver (25), Gold (50), Platinum (100), Diamond (250)
• Commands: achievements, trophies, badges, achievements all
• Persistent tracking via localStorage

Oregon Trail (v4.0.0):

• Full game with 15 landmarks (Independence, MO → Willamette Valley)
• Party management, shop system, hunting, river crossings
• Random events: diseases, weather, encounters, equipment failures
• Cross-session save: game state persists in localStorage
• Commands: trail, oregon, oregon trail

QWU Universe Adventure (v5.0.0):

• 12+ explorable locations representing the QWF ecosystem
• Locations: Gates of Hope, WHELHO Plaza, TIG's Lighthouse, Dream Forge (L4G), Gratitude Garden, Legacy Summit, Mentor's Grove, Reflection Pool, Archive of Dreams, Chamber of Origins, Hope's Heart
• 9 collectible items with narrative significance
• 5 NPCs with dialog trees (Blacksmith, Mentor, Ez, Keeper, Librarian)
• Commands: adventure, universe

TIG Trivia (v5.0.0):

• Three categories: TIG izms, QWF Programs, Pop Culture (Ted Lasso, Firefly, Star Trek)
• Streak bonuses for consecutive correct answers
• Score tracking with achievements
• Commands: trivia

Easter Eggs (v5.0.0):
14 total secrets discoverable through hidden commands and behaviors:

Commands Reference

Files

Architecture

┌─────────────────────────────────────────────────────────────────┐
│  Ez Terminal v5.0.0 (Browser)                                   │
├─────────────────────────────────────────────────────────────────┤
│  ┌───────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐  │
│  │ Scheduling│ │ Achievements│ │ Oregon Trail│ │QWU Universe │  │
│  │ Flow      │ │ Manager     │ │ Game Engine │ │ Adventure   │  │
│  └─────┬─────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘  │
│        │              │               │               │         │
│        │   ┌──────────┴───────────────┴───────────────┘         │
│        │   │   ┌─────────────┐ ┌─────────────┐                  │
│        │   │   │ TIG Trivia  │ │  Guestbook  │                  │
│        │   │   │ Engine      │ │  System     │                  │
│        │   │   └──────┬──────┘ └──────┬──────┘                  │
│        │   │          │               │                         │
│        └───┴──────────┼───────────────┘                         │
│                       │                                         │
│            ┌──────────▼──────────┐                              │
│            │  localStorage       │                              │
│            │  (session memory)   │                              │
│            └──────────┬──────────┘                              │
└───────────────────────┼─────────────────────────────────────────┘
                        │
    ┌───────────────────┼───────────────────┐
    ▼         ▼         ▼         ▼         ▼
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│Identity│ │ Wisdom │ │ Trail  │ │Universe│ │ Trivia │
│ State  │ │ State  │ │ Save   │ │ Save   │ │ State  │
└────────┘ └────────┘ └────────┘ └────────┘ └────────┘

Missing Pixel Training Opportunity

Tier 2 - Contributor Level

The Ez Terminal demonstrates several teachable concepts:

Portfolio Projects Completed (v5.0.0):

• Text adventure (QWU Universe - 12+ locations, NPCs, items)
• Trivia game (TIG Trivia - 3 categories, streaks)
• Guestbook system (moderated community messages)

Future Extension Ideas:

• Additional QWU Universe locations
• More trivia categories
• Theme creator tool
• Mobile gesture support

Troubleshooting

Can't Connect to VM

1. Check if VM is running - Azure Portal → VM should show "Running"
2. Check IP address - It may have changed after restart
3. Try status webhook - curl "https://n8n.quietlyworking.org/webhook/vm-control?action=status"

VS Code Remote SSH: Stuck at "Opening Remote..."

When VS Code hangs at "Opening Remote..." for more than 2-3 minutes, the VS Code server on the remote VM has likely become corrupted or stuck.

Diagnosis Steps:

1. Verify VM is running

   • Check Azure Portal or use your mobile VM control widget
   • Confirm the VM isn't stopped or deallocated

2. Test direct SSH connection

   ssh claude-dev-vm
   

   • If this hangs: problem is network or VM itself
   • If this connects: problem is VS Code server (continue below)

3. Check VS Code logs

   • In VS Code: View → Output
   • Select "Remote - SSH" from dropdown
   • Look for where the connection stalls

Resolution Steps:

Once SSH confirms the VM is accessible:

1. Kill zombie VS Code server processes

   pkill -f vscode-server
   

2. Remove corrupted VS Code server cache

   rm -rf ~/.vscode-server
   

3. Reconnect from VS Code

   • Close VS Code completely on local machine
   • Reopen and connect to remote
   • VS Code will reinstall server automatically
   • Extensions will reinstall on first connect (takes ~1 minute)

Prevention Tips:

• Avoid force-closing VS Code while remote operations are in progress
• If disconnecting for extended periods, use Remote-SSH: Close Remote Connection command first
• Keep VS Code and Remote SSH extension updated

Related Commands:

Permission Denied Errors

# For Docker
sudo docker run ...

# For file access
ls -la <file>    # Check permissions
chmod +x <file>  # Make executable

Docker Issues

# Check if Docker is running
sudo systemctl status docker

# Restart Docker
sudo systemctl restart docker

# Clean up space
docker system prune -a

Web Server 521 Error (Cloudflare)

Discovered: January 26, 2026

Symptoms:

• Cloudflare shows "521 Web server is down" error
• Browser → Cloudflare: Working
• Cloudflare → Origin: Error
• Sites like terminal.quietlyworking.org or twin.quietlyworking.org unreachable

Root Cause:
Port 80/443 conflict between nginx and Caddy. If nginx starts before Caddy (e.g., after reboot), Caddy fails to bind to ports and the reverse proxy doesn't run.

Diagnosis:

# Check what's using port 80
sudo lsof -i :80

# Check Caddy status
systemctl status caddy

# Check nginx status
systemctl status nginx

Solution:

# Stop and disable nginx
sudo systemctl stop nginx
sudo systemctl disable nginx

# Restart Caddy
sudo systemctl restart caddy

# Verify
systemctl status caddy
curl -s -o /dev/null -w "%{http_code}" http://localhost:80

Prevention:

• nginx was disabled on 2026-01-26 to prevent this conflict
• If nginx is needed for something else, configure it to use different ports or remove Caddy

Systemd Service Port Conflict (Address Already in Use)

Discovered: February 25, 2026

Symptoms:

• BetterStack fires "Missed heartbeat" alert for claude-dev VM
• systemctl status <service> shows failed (Result: exit-code)
• Journal shows OSError: [Errno 98] Address already in use repeated 11 times
• Health check reports critical (v1.0.0 withheld heartbeat; fixed in v1.1.0 — heartbeat now always pings)

Root Cause:
A rogue process started outside systemd (e.g., manual run, previous session) holds the port. When systemd tries to restart its managed service, the new process can't bind and fails. After 11 rapid restart attempts (~5s each), systemd gives up.

Diagnosis:

# Check which process holds the port
ss -tlnp | grep <port>

# Check if systemd thinks the service is running
systemctl status <service>

# Check journal for the crash loop
journalctl -u <service> --since "1 hour ago"

Solution:

# Kill the rogue process
kill <pid_from_ss_output>

# Reset systemd's failure state and restart
sudo systemctl reset-failed <service>
sudo systemctl restart <service>

# Verify
systemctl status <service>

Prevention:

• digital_twin_server.py now uses ReusableHTTPServer with SO_REUSEADDR (added Feb 2026), allowing restarts even if the port is in TIME_WAIT state
• Avoid running services manually when systemd manages them — use systemctl restart instead
• If you must test manually, stop the systemd service first: sudo systemctl stop <service>
• <VM_USER> has passwordless sudo for systemctl (added Mar 2026), allowing the agent to self-heal service failures
• check_vm_health.py v1.1.0 always pings heartbeat regardless of status, so this scenario no longer causes false "VM down" P1 alarms

Disk Space Warnings

# Check disk usage
df -h

# Find large files
du -sh * | sort -h

# Clean Docker
docker system prune -a

MCP Server Connection Issues

1. Check domain is in firewall allowlist
2. Rebuild container after adding domains
3. Test connectivity: curl -I https://domain.com

n8n SSH Node Authentication Error

Discovered: January 17, 2026 during LinkedIn workflow debugging

Symptoms:

• Workflow executes on schedule but fails immediately
• Error: "Node does not have any credentials set for \"sshPassword\""
• SSH credentials (privateKey type) are correctly configured in n8n
• Same credentials work for other workflows

Root Cause:
The n8n SSH node defaults to password authentication. When using SSH private key credentials, you must explicitly set authentication: "privateKey" in the node's parameters. Without this, the node looks for password-type credentials and fails.

Solution:
In your workflow JSON, ensure each SSH node has the authentication parameter:

{
  "parameters": {
    "authentication": "privateKey",  // ← REQUIRED for privateKey credentials
    "command": "your-command-here"
  },
  "type": "n8n-nodes-base.ssh",
  "credentials": {
    "sshPrivateKey": {
      "id": "credential-id",
      "name": "Credential Name"
    }
  }
}

Via API Fix:

# Extract workflow, add authentication to SSH nodes, update
cat workflow.json | jq '
  {name, connections, settings, nodes: [.nodes[] |
    if .type == "n8n-nodes-base.ssh"
    then .parameters.authentication = "privateKey"
    else . end
  ]}
' | curl -s -X PUT "$N8N_API_URL/workflows/{id}" \
  -H "X-N8N-API-KEY: $N8N_API_KEY" \
  -H "Content-Type: application/json" -d @-

Prevention:
Always include "authentication": "privateKey" when creating workflow JSON files that use SSH nodes with private key credentials.

Fleet-Wide Remediation (Feb 13, 2026):
A comprehensive audit found this issue (or variants) in 19 of 78 active workflows. Three patterns were discovered:

1. Missing authentication: privateKey — node defaults to password auth, looks for wrong credential type
2. Wrong credential key (sshPassword instead of sshPrivateKey) — works by accident because n8n looks up credentials by ID, not key name
3. Redundant sshAuthenticateWith: privateKey — non-standard parameter name, harmless but confusing

All 19 workflows were fixed via nuclear export→delete→reimport→publish (SQL UPDATE doesn't affect published versions in workflow_history). Additionally, 2 workflows using Discord httpRequest v4.1 (form-encoded bodyParameters) were upgraded to v4.2 (JSON body) — Cloudflare silently blocks form-encoded Discord webhook payloads for embed-heavy messages.

n8n API Webhook Registration Issue (Self-Hosted)

Discovered: January 15, 2026 during n8n migration

Symptoms:

• Workflows created via n8n REST API activate successfully (logs show "Activated workflow")
• Webhook trigger nodes show as configured and enabled
• Calling the production webhook URL returns {"code":404,"message":"The requested webhook \"xyz\" is not registered"}
• Same workflow imported manually via UI works correctly

What We Tried:

1. Multiple workflow create/delete cycles via API
2. Different webhook paths and configurations
3. Restarting n8n container multiple times
4. Simplifying workflows to minimal webhook → respond patterns
5. Using different webhook node versions (v1, v2)
6. Verifying workflow activation via /workflows/{id}/activate endpoint

Root Cause Analysis:
The n8n REST API (currently in beta) appears to have a bug where webhooks created programmatically don't register in the internal webhook routing table, even though the workflow activates successfully. The issue may be related to:

• Webhook registration happening during UI import but not API import
• Missing internal event trigger when activating via API
• Race condition between workflow activation and webhook registration

Status: Unresolved limitation of n8n REST API (beta)

Workaround Implemented:
Rather than relying on n8n for webhook reception, we created a standalone webhook server:

Twilio → sms.quietlyworking.org → Caddy (SSL) → twilio_webhook_server.py → sms_approval.py

Components:

Should This Be Reported?
Yes. This appears to be a legitimate bug in the n8n REST API. The behavior is:

• API reports success for workflow creation and activation
• Logs confirm activation
• But webhook routing doesn't work

Consider reporting to: https://github.com/n8n-io/n8n/issues with reproduction steps:

1. Create workflow with webhook trigger via REST API
2. Activate workflow via REST API
3. Attempt to call webhook URL
4. Observe 404 despite active workflow

Learning:
For critical webhooks that must work immediately, either:

1. Import workflows manually via n8n UI
2. Build standalone webhook endpoints (as we did for SMS)
3. Use n8n's native integrations where available (Twilio node) instead of custom webhooks

Resources

Key URLs

Environment Variables Reference

All secrets and configuration are stored in .env at the vault root. Here's the complete reference:

Core Services:

# Anthropic API
ANTHROPIC_API_KEY="sk-ant-..."

# OpenAI (for some AI enrichments)
OPENAI_API_KEY="sk-..."

# OpenRouter (LLM calls via model_config.py)
OPENROUTER_API_KEY="sk-or-v1-..."
OPENROUTER_MGMT_KEY="sk-or-v1-..."  # Management Key for Activity API cost cross-validation

Azure (VM Control + Cost Tracking):

AZURE_SUBSCRIPTION_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
AZURE_TENANT_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
AZURE_CLIENT_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
AZURE_CLIENT_SECRET="your-client-secret"

Google Services:

# Calendar integration
GOOGLE_CALENDAR_CREDENTIALS="/path/to/service-account.json"
GOOGLE_CALENDAR_MAIN="email@domain.com"
GOOGLE_CALENDAR_ALERTS="calendar-id@group.calendar.google.com"
GOOGLE_CALENDAR_TIMESLOT="calendar-id@group.calendar.google.com"

# Sheets (for lead delivery)
GOOGLE_SHEETS_CREDENTIALS="/path/to/service-account.json"

# Google Docs (bidirectional sync with Obsidian)
GOOGLE_DOCS_CREDENTIALS="/path/to/service-account.json"
GOOGLE_DOCS_FOLDER_DEFAULT="drive-folder-id-for-synced-docs"
GOOGLE_DOCS_SYNC_DIRS="002 Projects,Quietly Working Universe Public Transparency Project"

Discord Webhooks:

DISCORD_WEBHOOK_AGENT_LOG="https://discord.com/api/webhooks/..."
DISCORD_WEBHOOK_INBOX_ALERTS="https://discord.com/api/webhooks/..."
DISCORD_WEBHOOK_L4G_LEADS="https://discord.com/api/webhooks/..."
DISCORD_WEBHOOK_SYSTEM_STATUS="https://discord.com/api/webhooks/..."
DISCORD_WEBHOOK_DAILY_DIGEST="https://discord.com/api/webhooks/..."

Twilio Phone Registry:

All QWU Twilio numbers are under the <ADMIN_EMAIL> account with Charity A2P messaging service.

# Twilio Account
TWILIO_ACCOUNT_SID="your-account-sid"
TWILIO_AUTH_TOKEN="your-auth-token"

# Phone Numbers by Purpose
TWILIO_BNI_NUMBER="+19492645730"      # Aim High BNI automations
TWILIO_U2SPEAK_NUMBER="+12568277325"  # BNI speaker reminders
TWILIO_L4G_NUMBER="+19493733730"      # Locals 4 Good SMS
TWILIO_VIP_NUMBER="+19493442844"      # VIP/Personal line

For detailed number documentation, see: 003 Entities/Tools/Twilio.md

Lead Generation/Enrichment:

# Anymail Finder (email enrichment)
ANYMAIL_API_KEY="your-api-key"

# Reoon (cheaper bulk email validation)
REOON_API_KEY="your-api-key"

# LinkedIn (Sales Navigator scraping)
LINKEDIN_SCRAPER_API_KEY="your-api-key"

# Apollo.io
APOLLO_API_KEY="your-api-key"

Locals 4 Good (L4G) System:

# Supabase (primary backend — migrated from Google Sheets Feb 2026)
L4G_SUPABASE_URL="https://<SUPABASE_PROJECT_ID_L4G>.supabase.co"
L4G_SUPABASE_ANON_KEY="your-anon-key"
L4G_SUPABASE_SERVICE_ROLE_KEY="your-service-role-key"
L4G_SUPABASE_DB_PASSWORD="your-db-password"

# Stripe
L4G_STRIPE_WEBHOOK_SECRET="whsec_..."

# Legacy (deprecated — kept for reference, data migrated to Supabase)
L4G_AVAILABILITY_SHEET_ID="sheet-id"
L4G_CHECKOUT_API="https://script.google.com/macros/s/.../exec"
L4G_AREA_CONFIG_API="https://script.google.com/macros/s/.../exec"
L4G_POSTCARD_API="https://script.google.com/macros/s/.../exec"

# SMS (Twilio via n8n)
L4G_TWILIO_FROM_NUMBER="949-373-3730"

Social Media:

# Vista Social MCP
VISTA_SOCIAL_API_KEY="your-api-key"

Canonical Datetime (Timezone Handling):

# Timezone for all QWU operations (IANA format)
QWU_TIMEZONE="America/Los_Angeles"

# Day boundary hour (work before this counts as "yesterday")
QWU_DAY_BOUNDARY_HOUR=4

Vault Configuration:

VAULT_PATH="/home/<VM_USER>/qwu_backOffice"

Tips & Gotchas

1. SSH Key is critical - Cannot be re-downloaded. Back it up immediately.

2. VM IP can change - If VM is stopped and started, IP might change. Check Azure Portal and update SSH config if connection fails.

3. VM runs 24/7 - As of Jan 2026, auto-shutdown is disabled for continuous automation. Weekly restart Sunday 3 AM.

4. Budget ~$60-85/month - Always-on cost is higher but enables autonomous operations.

5. Disk can only grow - You can increase disk size later, but cannot shrink it. Start small.

6. B2ms sweet spot - 8GB RAM is comfortable for Docker + VS Code + agents. B2s (4GB) feels cramped.

7. Standard SSD is fine - No need for Premium SSD for development work.

8. tmux is essential - Any serious agent work needs persistent sessions.

Notes for Future Sessions

Add notes here as we continue building...

• Consider setting up static IP (VM IP can change on restart)
• Create custom Docker images for frequently-used agent setups
• Set up Docker Compose for multi-container workflows
• Implement transcript extraction system
• Build inbox processing automation ✅ Completed (n8n workflow)
• Complete Discord server setup ✅ Completed (Session 9)
• Add Timeslot Planning calendar integration for goal-based scheduling
• Build appointment scheduling system with CRM integration (in planning)
• Create Goals & Priorities document for summary alignment ✅ Completed (M7 milestone)
• Set up n8n workflow for scheduled morning briefings
• Implement Vista Social content calendar integration

BNI Member Dossier System

A comprehensive member enrichment and visitor connection system for BNI (Business Network International) chapter management. Designed for the Aim High chapter in Orange County, CA.

Purpose

When visitors register for a BNI meeting, generate personalized Connection Reports for each chapter member containing:

• Icebreakers based on shared interests
• Commonalities between member and visitor
• Customized value propositions
• Email templates for follow-up

Goal: Create deeper connections faster, maximize referrals, increase membership, decrease attrition.

Architecture

┌─────────────────────────────────────────────────────────────────┐
│  DATA SOURCES                                                    │
├─────────────────────────────────────────────────────────────────┤
│  Airtable CSV    │  LinkedIn   │  Website     │  Google/Yelp    │
│  (base member    │  (profiles  │  (services,  │  (reviews,      │
│   data)          │  + posts)   │   about)     │   ratings)      │
└────────┬─────────┴──────┬──────┴───────┬──────┴────────┬────────┘
         │                │              │               │
         ▼                ▼              ▼               ▼
┌─────────────────────────────────────────────────────────────────┐
│  ENRICHMENT PIPELINE                                             │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐           │
│  │ import_bni   │  │ enrich_      │  │ enrich_      │           │
│  │ _members.py  │→ │ linkedin.py  │→ │ website.py   │→ ...      │
│  └──────────────┘  └──────────────┘  └──────────────┘           │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │ enrich_member_orchestrator.py                               │ │
│  │ - Runs full pipeline: LinkedIn → Website → Reviews → AI    │ │
│  │ - Generates final synthesis with ICP, power teams, scripts  │ │
│  └────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────────────────────────────────────┐
│  ENTITY FILES: 003 Entities/People/                              │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │ [Member Name].md                                          │    │
│  │ - YAML frontmatter (tags, contact, enrichment status)    │    │
│  │ - Professional Summary                                   │    │
│  │ - Services & Offerings                                   │    │
│  │ - Ideal Customer Profile (AI-synthesized)                │    │
│  │ - Power Team Connections                                 │    │
│  │ - Personal Interests & Background                        │    │
│  │ - Customer Sentiment (from reviews)                      │    │
│  └─────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────────────────────────────────────┐
│  CONNECTION REPORTS                                              │
│  Visitor × Member matching with icebreakers, value props, etc.  │
└─────────────────────────────────────────────────────────────────┘

Project Files

Enrichment Scripts

Usage

Import members from Airtable:

python import_bni_members.py "Data Imports/aim_high_members_2024.csv"

Enrich single member:

python enrich_member_orchestrator.py "[Member Name]"

Enrich all BNI members:

python enrich_member_orchestrator.py --all

Specific sources only:

python enrich_member_orchestrator.py "[Member Name]" --sources linkedin,website

Dry run (preview without changes):

python enrich_member_orchestrator.py "[Member Name]" --dry-run

Referral Intelligence

A unique feature of the review enrichment: analyzes 1-3★ reviews to identify improvement areas and potential referral opportunities.

For example, if a landscaper's reviews mention "wish they did hardscaping," the system suggests referring a hardscape specialist TO that member.

# Output from enrich_member_reviews.py
{
    "referral_opportunities": [
        {
            "improvement_area": "Response time",
            "potential_referral": "Virtual assistant or scheduling service",
            "reasoning": "Multiple reviews mention delayed responses"
        }
    ]
}

Entity Schema

Member entities include these YAML frontmatter fields:

# === IDENTITY ===
tags: [AimHigh, BNI-Active]
aliases: [Derek]
type: human

# === CONTACT INFO ===
email: member@company.com
phone_mobile: "(555) 123-4567"
121_link: https://calendly.com/member  # BNI 1-2-1 scheduling

# === BUSINESS INFO ===
company_name: "Company Name LLC"
company_website: https://company.com
bni_category: "Business Category"

# === ENRICHMENT STATUS ===
enrichment_status: pending|partial|complete
last_enriched: 2026-01-11
enrichment_sources: [airtable, linkedin, website, reviews]

# === REVIEW DATA ===
google_rating: 4.8
google_review_count: 47
yelp_rating: 4.5
yelp_review_count: 23

Google Drive Integration

OAuth2 authentication provides full read access to Google Drive for accessing historical BNI data (visitor logs, meeting notes, etc.):

# Initial setup (one-time)
python gdrive_oauth.py --authorize

# Search for files
python gdrive_oauth.py --search "BNI dossier"

# List folder contents
python gdrive_oauth.py --list-folder "folder-id"

OAuth Credentials: .credentials/google-oauth-desktop.json
Token Storage: .credentials/google-oauth-token.json

Environment Variables

# Apify (for web scraping)
APIFY_API_TOKEN="your-apify-token"

# Anthropic (for AI synthesis)
ANTHROPIC_API_KEY="your-api-key"

# Google OAuth (for Drive access)
GOOGLE_OAUTH_CREDENTIALS_PATH=".credentials/google-oauth-desktop.json"
GOOGLE_OAUTH_TOKEN_PATH=".credentials/google-oauth-token.json"

Terminology

Advanced Features (Phases 5-7) ⭐ NEW

The Epic Dossier System extends basic enrichment with three advanced intelligence layers:

Phase 5: Cross-Platform (Instagram Integration)

Extracts Instagram handles from cached website data and enriches member profiles:

# Extract Instagram from already-scraped websites (no API calls)
python extract_instagram_from_websites.py

# Full enrichment including Instagram (if handle exists in frontmatter)
python enrich_member_orchestrator.py "Member Name"

Scripts:

How it works: When websites include structured data (JSON-LD), they often list social profiles in sameAs arrays. This script mines that data without additional API calls.

Phase 6: Network Intelligence

Generates "who should meet whom" recommendations using 8 matching algorithms:

# Generate chapter-wide connection recommendations
python network_intelligence.py --chapter AimHigh --write

Matching Algorithms:

1. Power Team Matching - Complementary BNI categories (e.g., roofer ↔ real estate)
2. Referral Reciprocity - Bidirectional referral potential
3. Style Compatibility - Communication style matching (connector ↔ thought_leader)
4. Industry Overlap - Shared industry experience
5. Values Overlap - Mission alignment and shared values
6. Mission Alignment - Charitable/community focus matching
7. Entrepreneur Affinity - Fellow business owner connection
8. Volunteer Affinity - Shared community involvement

Output: Writes "Recommended Connections" section to each member's entity file with Obsidian wiki links:

## Recommended Connections

Based on network intelligence analysis:

1. **[[[Member Name]]]** (Score: 60)
   - Reasons: Power team match, Values overlap, Mission alignment

Phase 7: Predictive Intelligence

Forward-looking insights using FLAGSHIP LLM analysis:

# Generate predictive insights for members with sufficient data
python predictive_intelligence.py --write

Analysis Types:

Output: Writes "Predictive Insights" section to entity files:

## Predictive Insights

**Trajectory:** Expanding (established stage)
**Growth Areas:** Digital marketing, strategic partnerships, community leadership
**Hopes We See:** Scaling impact while maintaining service quality

Updated Enrichment Pipeline (v1.4.0)

The orchestrator now runs 7 steps:

1. LinkedIn profile and posts
2. Website content extraction
3. Google/Yelp reviews
4. AI synthesis
5. Meeting intelligence (from transcripts)
6. Instagram (if handle in frontmatter)
7. Network intelligence (chapter-wide)

# Full pipeline including all phases
python enrich_member_orchestrator.py --all

Visitor Enrichment (Symmetric Intelligence) ⭐ NEW

Enriches BNI visitors with the same depth of intelligence as chapter members, enabling symmetric connection matching.

Problem Solved: Members have rich Epic Dossier profiles, but visitors only had basic registration data. This created asymmetric matching where AI couldn't generate quality icebreakers from limited visitor information.

Solution: enrich_visitor.py runs the same enrichment pipeline on visitors:

# Enrich a specific visitor
python enrich_visitor.py "Michael Dory"

# Enrich all pending visitors
python enrich_visitor.py --pending

# Dry run (no API calls)
python enrich_visitor.py "Michael Dory" --dry-run

Pipeline (4 Steps):

1. LinkedIn Lookup - Find person by name + company using Apify person search
2. Website Extraction - Scrape visitor's company website for services, about, team info
3. Reviews Lookup - Google Places reviews with sentiment analysis
4. AI Synthesis - Generate profile with same fields as member dossiers

Output Fields:

Storage: .tmp/bni_visitors/{meeting_date}_{visitor_name_slug}.json

Integration with Connection Reports:

generate_connection_report.py v2.1.0 automatically loads enriched visitor data when generating reports (with parallel execution for 5x speedup):

# Connection report now receives enriched visitor data
enriched_visitor = find_enriched_visitor(visitor_name)
report = generate_connection_report_ai(visitor_data, member_data, enriched_visitor)

This enables:

• Deeper icebreakers based on visitor's values and personality
• Values alignment section comparing member and visitor missions
• Power team matching from visitor's ideal customer profile
• Bidirectional referral opportunities

Environment Variables:

APIFY_API_TOKEN="your-apify-token"  # LinkedIn person search
OPENROUTER_API_KEY="your-key"       # AI synthesis (FLAGSHIP tier)

MP Student Training Opportunity (Tier 2: Contributor)

Students can learn data enrichment pipeline patterns by:

1. Running visitor enrichment on test data (dry-run mode)
2. Understanding the 4-step pipeline architecture
3. Analyzing how AI synthesis creates structured profiles from unstructured data
4. Comparing member vs visitor enrichment approaches

Learning Objectives:

• API integration with Apify (web scraping as a service)
• LLM prompt engineering for data synthesis
• JSON data transformation and storage patterns
• Pipeline design with graceful degradation (partial enrichment when sources fail)

Full Visitor Pipeline (v3.2.0) ⭐ NEW

The bni_visitor_pipeline.py orchestrates the complete visitor processing workflow from enrichment through email delivery and inbox organization.

6 Pipeline Stages:

Usage:

# Process specific visitor
python bni_visitor_pipeline.py "[Member Name]"

# Process latest pending visitor
python bni_visitor_pipeline.py --latest

# Dry run (no API calls, no emails)
python bni_visitor_pipeline.py "[Member Name]" --dry-run

# Test mode: redirect ALL emails to yourself (safe testing)
python bni_visitor_pipeline.py "[Member Name]" --test-recipient=<ADMIN_EMAIL>

v3.4.0 Change (YAML Deprecated — Phase 7 Complete):
Defense-in-depth opt-out system using the self-service Preference Center:

• Layer 1 (Sole Source): SQLite database via preference_center/db.py v2.1.0 (PreferenceDB)
• Layer 2: Entity file flag (visitor_reports_opt_out: true)
• Layer 3: should_send_report() function checks all layers
• Layer 4: Full audit logging to .tmp/logs/YYYY-MM-DD.log
• Fail-safe: If SQLite is unavailable, email is blocked (not sent). Better to miss one email than to send to someone who opted out.
• Obsidian Dashboard: 005 Operations/Dashboards/Preference-Center-Status.md auto-regenerates on every preference write + daily cron safety net

Self-Service Preference Management:
Users can manage their own preferences via:

1. Ezer Chat: Say "manage my preferences" or "unsubscribe" at terminal.quietlyworking.org
2. Email Footer: All automated emails include a preferences link
3. Direct URL: https://preferences.quietlyworking.org (requires magic link)

Available Products:

Key Files:

• preference_center/db.py - SQLite database operations + auto-dashboard (v2.1.0)
• preference_center/magic_link.py - Token generation/verification (v1.0.0)
• preference_center/email.py - Magic link + confirmation emails (v1.1.0)
• preference_center/api.py - API endpoint handlers (v1.1.0)
• generate_preferences_dashboard.py - Cron safety net for Obsidian dashboard (v1.0.0)
• ez_chat_handler.py - "preferences" intent handling (v3.8.0)
• Dashboard: 005 Operations/Dashboards/Preference-Center-Status.md
• Directive: 005 Operations/Directives/preference_center.md

Missing Pixel Training Opportunity (Tier 2: Contributor)

Component	Skills Taught
SQLite database (db.py)	Python, database design, CRUD operations, indexing
Magic link auth (magic_link.py)	HMAC-SHA256 cryptography, token-based auth, security
Email system (email.py)	MS Graph API, HTML templates, OAuth2
API handlers (api.py)	REST design, rate limiting, error handling
Intent detection	NLP keyword matching, modal flows

Portfolio Value: Full-stack system demonstrating database, security, API, and UX skills.

Email Sending Conventions (System-Wide)

Added: Session 65 (February 8, 2026)

Every email script is classified as Enhancement or Exempt:

Enhancement Scripts (footer + opt-out):

Exempt Scripts (no footer):

Fail-open vs Fail-closed: Fail-open scripts send the email even if the preference check fails (suitable for operational emails like meeting follow-ups). Fail-closed scripts block the email if the preference check fails (required for ongoing automated communications like BNI reports and journey touchpoints).

BCC Monitoring: All 10 email scripts BCC EZER_BCC_EMAIL (<ADMIN_EMAIL>) on every outbound. Guard: BCC skipped if recipient == BCC address.

Name Rule: Her name is Ezer Aión (Hebrew "helper who runs toward" + Greek "eternal age"). Always use the accent on the 'o'. Never write "Aion" without it.

Missing Pixel Training Opportunity (Tier 2: Contributor)

The Email Preference System teaches real-world compliance patterns:

• Opt-out Architecture — Defense-in-depth (database + entity file + self-service), fail-open vs fail-closed behavior
• Magic Link Auth — HMAC-SHA256 token generation, expiry management, rate limiting
• Classification System — Why transactional emails don't need unsubscribe links (CAN-SPAM)
• Database Migration — Auto-adding columns via ALTER TABLE, handling defaults for existing rows

Exercise: Add a new product category to the preference center (add to db.py PRODUCTS, api.py PRODUCTS dict, email.py PRODUCT_NAMES), create a test email script that checks opt-out and appends the footer, verify with dry-run.

v3.1.0 Change (Email Housekeeping):
After sending member emails, the pipeline automatically:

1. Searches for the original registration email by visitor name
2. Marks it with green checkmark (flag status: complete)
3. Moves it to Inbox/BNI/Visitors folder for organization

v3.0.0 Change (Auto-Send):
Previously created Outlook drafts requiring manual review. Now sends emails directly after quality gate validation. User validated quality over multiple production runs before enabling.

Quality Gate: validate_bni_email.py ensures each email has:

• 10 required sections (Profile, Icebreakers, Social Proof, etc.)
• Minimum 10,000 characters
• Minimum 300 unique words
• Emails failing validation are NOT sent

BNI Meeting Recap System ⭐ NEW

Automated weekly meeting recap generation for BNI chapters. Processes Zoom chat logs to extract visitors, referrals, announcements, and engagement data, then generates personalized HTML emails for each chapter member. As of February 2026, supports slide-augmented recaps that combine chat analysis with Claude Vision screenshot analysis from Google Drive meeting folders.

Purpose

After each BNI meeting, generate a comprehensive recap email that:

• Highlights visitors with full contact details and interest levels
• Showcases referrals given with context (not just names)
• Features the week's speakers with their Ideal Customer Profiles
• Lists 1-2-1 connection requests with contact links
• Includes chapter announcements with actionable URLs
• Celebrates chat engagement champions
• Personalizes content for each recipient

Goal: Keep members engaged, reinforce connections made during the meeting, and make follow-up easy.

Architecture

┌─────────────────────────────────────────────────────────────────────┐
│  DATA SOURCES                                                        │
├─────────────────────────────────────────────────────────────────────┤
│  Zoom Chat    │  Speaker       │  [Member Name]'s       │  Entity Files    │
│  Export       │  Schedule      │  Visitor Sheet  │  (003 Entities/) │
│  (.txt)       │  (Google       │  (attendance,   │  (member data,   │
│               │   Sheets)      │   interest)     │   ICP, contact)  │
└──────┬────────┴───────┬────────┴────────┬────────┴─────────┬────────┘
       │                │                 │                  │
       ▼                ▼                 ▼                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│  PROCESSING PIPELINE                                                 │
│  ┌──────────────────┐  ┌────────────────┐  ┌──────────────────────┐ │
│  │ process_bni_chat │  │ read_speaker_  │  │ read_cathie_visitor_ │ │
│  │ .py              │→ │ schedule.py    │→ │ sheet.py             │ │
│  │ - Parse messages │  │ - Get speakers │  │ - Attendance data    │ │
│  │ - Extract data   │  │   for date     │  │ - Interest levels    │ │
│  └──────────────────┘  └────────────────┘  └──────────────────────┘ │
│                                                                      │
│  ┌────────────────────────────────────────────────────────────────┐ │
│  │ generate_bni_meeting_recap.py (v4.3.0)                         │ │
│  │ - Combines all data sources                                     │ │
│  │ - EPIC visitor spotlights with enriched entity data            │ │
│  │ - Builds personalized HTML for each recipient                  │ │
│  │ - Speaker spotlight with ICP and referral triggers             │ │
│  │ - Week-over-week trend tracking                                │ │
│  │ - Discord approval flow + MS Graph email delivery              │ │
│  └────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
       │
       ▼
┌─────────────────────────────────────────────────────────────────────┐
│  OUTPUT                                                              │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────────┐  │
│  │ Discord Preview │  │ HTML Email      │  │ Markdown Archive    │  │
│  │ (approval flow) │  │ (MS Graph API)  │  │ (.tmp/bni_recap/)   │  │
│  └─────────────────┘  └─────────────────┘  └─────────────────────┘  │
└─────────────────────────────────────────────────────────────────────┘

Scripts

Usage

Step 1: Process the Zoom chat export

python process_bni_chat.py --file "path/to/zoom_chat.txt" --json --output processed.json

Step 2: Generate recap (preview mode)

python generate_bni_meeting_recap.py processed.json --preview

Step 3: Post to Discord for approval

python generate_bni_meeting_recap.py processed.json --discord

Step 4: Send test email to yourself

python generate_bni_meeting_recap.py processed.json --test-email <ADMIN_EMAIL>

Step 5: Send to all participants

python generate_bni_meeting_recap.py processed.json --send

Email Personalization

Each recipient receives a customized email with:

Slide-Augmented Recap (v2 — February 2026)

When meeting screenshots are uploaded to a Google Drive folder, the recap can be augmented with visual intelligence:

Step 0: Extract slide intelligence from Google Drive

python extract_slide_intel.py --date 2026-02-26 --folder-id <drive_folder_id>

This uses Claude Vision (FLAGSHIP tier) to analyze each screenshot, then synthesizes:

• Presentation titles, speakers, and key content from each slide
• Attendees spotted in gallery-view screenshots
• Notable moments (reactions, celebrations, achievements)

Output: .tmp/slide_intel/YYYY-MM-DD_slide_intel.json

The slide intel JSON is then combined with chat analysis to produce a richer recap with keynote spotlights, visual context, and attendee cross-referencing.

Data integrity safeguard: Before sending to any recipients, the send script must:

1. Build recipient list from BNI-Active entity tags
2. Call check_send_permission(email, "meeting_recaps", fail_open=False) for each recipient
3. Generate per-recipient preference center footer with magic link
4. Send individually (no BCC) for unique unsubscribe links

Official roster verification: The authoritative member list is at socalbni.com (AJAX POST to /bnicms/v3/frontend/chapterdetail/display with website_type=2, website_id=5197). Cross-reference entity files against this periodically to catch stale BNI-Active tags.

Speaker Spotlight Feature

The speaker spotlight (v4.2.0+) features all speakers from the meeting:

• Speaker 1 and Speaker 2 are treated equally (just presentation order)
• Pulls from the speaker schedule Google Sheet for the meeting date
• Falls back to one random member if no speakers scheduled
• Shows member's company, Ideal Customer Profile, and "When to Refer" triggers
• Uses fuzzy name matching to find entity files (e.g., "Kim Nguyen" → "Kim Nguyen.md")

Spotlight Content (from Entity Files):

## Ideal Customer Profile
- **Industries**: Local Service Businesses, Retail/Boutique Owners...
- **Company Size**: Small-to-medium businesses, $100K-$5M revenue...
- **When to Refer**: Business owner asking about direct mail marketing...

EPIC Visitor Spotlight (v4.3.0+)

Visitor cards now pull enriched data from entity files for symmetric intelligence - visitors get the same rich treatment as members:

Entity Lookup: The lookup_visitor_entity() function searches:

1. Exact match: 003 Entities/People/{Name}.md
2. Draft files: 000 Inbox/___Review/{Name} [DRAFT].md
3. Fuzzy match: Files containing all significant name parts

Result: Instead of "Benjamin Kubo - TBD", recaps now show:

Benjamin Kubo - Bonehead Bookkeeping | Bookkeeping
"Bonehead in Chief at Bonehead Bookkeeping..."
Power Team: CPA / Tax Preparer, Business Broker, Financial Advisor

Data Extraction

The chat parser (process_bni_chat.py v2.3.0) extracts:

Filtering Rules:

• 1-2-1 requests require a specific person target (not "visitors" or "everyone")
• Self-promotional calendly shares are excluded from 1-2-1 requests
• Announcements without actionable URLs are filtered out
• Thank-you/gratitude messages excluded from announcements
• Duplicate announcements from same sender are deduplicated

Visitor Interest Levels

When [Member Name]'s visitor tracking sheet is available, visitors display interest badges:

Output Files

Environment Variables

# MS Graph API (for sending emails)
AZURE_CLIENT_ID="your-client-id"
AZURE_CLIENT_SECRET="your-client-secret"
AZURE_TENANT_ID="your-tenant-id"
OUTLOOK_EMAIL="sender@domain.com"

# Discord (for approval flow)
DISCORD_WEBHOOK_BNI_RECAP="webhook-url"

# Google Sheets (for speaker schedule + visitor tracking)
GOOGLE_SERVICE_ACCOUNT_KEY_PATH=".credentials/google-service-account.json"
SPEAKER_SCHEDULE_SPREADSHEET_ID="spreadsheet-id"
CATHIE_VISITOR_SPREADSHEET_ID="spreadsheet-id"

Directives

MP Training Opportunities

System Architecture Audit ⭐ NEW

A monthly deep-analysis process to evaluate system health, identify gaps, and ensure all components work together effectively.

Purpose

As the QWU Backoffice grows in complexity (38 directives, 73 scripts, 8 agents, 11 skills), it becomes critical to regularly step back and assess:

• Which components are fully integrated
• What systems are dangling or incomplete
• Where gaps exist that need attention
• How well the layers work together

This audit serves both operational health and educational purposes—providing students with a comprehensive view of how a production automation system is structured.

Architecture Overview

┌─────────────────────────────────────────────────────────────────────────────┐
│                         QWU BACKOFFICE SYSTEM                               │
│                      ~45,000 lines | 3-Layer Architecture                   │
└─────────────────────────────────────────────────────────────────────────────┘
                                    │
        ┌───────────────────────────┼───────────────────────────┐
        ▼                           ▼                           ▼
┌───────────────────┐     ┌───────────────────┐     ┌───────────────────┐
│  LAYER 1          │     │  LAYER 2          │     │  LAYER 3          │
│  DIRECTIVES       │     │  ORCHESTRATION    │     │  EXECUTION        │
│  (What to do)     │     │  (Decision-making)│     │  (Doing the work) │
│                   │     │                   │     │                   │
│  38 SOPs          │     │  Claude Agents    │     │  73 Python        │
│  ~10K lines       │     │  8 specialized    │     │  scripts          │
│  005 Operations/  │     │  .claude/agents/  │     │  ~36K lines       │
│  Directives/      │     │                   │     │  005 Operations/  │
│                   │     │                   │     │  Execution/       │
└───────────────────┘     └───────────────────┘     └───────────────────┘

System Component Map

Capture & Ingest (Fully Integrated ✅)

    📱 Phone Captures          📧 Outlook Emails           🎥 Zoom Meetings
         │                          │                           │
         ▼                          ▼                           ▼
   process_inbox.py          outlook_pipeline.py         zoom_pipeline.py
         │                          │                           │
         │                          └───────────┬───────────────┘
         │                                      │
         │                                      ▼
         │                           ┌─────────────────────┐
         │                           │  ENTITY RESOLUTION  │
         │                           │  + SuiteDash CRM    │
         │                           └─────────────────────┘
         │                                      │
         └──────────────────┬───────────────────┘
                            ▼
   ┌─────────────────────────────────────────────────────────┐
   │               VAULT UPDATES                              │
   │  003 Entities/People/   (150+ profiles)                 │
   │  003 Entities/Organizations/   (50+ orgs)               │
   │  001 Daily/   (daily notes)                             │
   │  ___Tasks/   (action items)                             │
   └─────────────────────────────────────────────────────────┘

Intelligence Layer (Fully Integrated ✅)

   8 Thought Leaders                    Wisdom Pipeline
   ┌─────────────────┐                 ┌─────────────────┐
   │ Simon Sinek     │                 │ youtube_        │
   │ Brené Brown     │───(4-12 hrs)───▶│ monitor.py     │
   │ Lex Fridman     │                 │       │         │
   │ Andrej Karpathy │                 │       ▼         │
   │ Dwarkesh Patel  │                 │ wisdom_         │
   │ [+3 others]     │                 │ indexer.py      │──▶ SQLite
   └─────────────────┘                 │       │         │
                                       │       ▼         │
                                       │ wisdom_         │──▶ Attributed
                                       │ synthesizer.py  │    Content
                                       └─────────────────┘

Daily Operations (Fully Integrated ✅)

  06:00 ─────▶ morning_briefing.py ─────▶ Discord #daily-digest
                      │                         │
                      └────────────────────────▶│
                                                ▼
                                         ┌─────────────┐
                                         │ Daily Note  │
                                         └─────────────┘
                                                ▲
  18:00 ─────▶ summarize_session.py ────────────┘

Lead Generation (Partially Integrated 📋)

   Lead Sources (40% Built)              Enrichment (85% Built)
   ┌─────────────────────┐              ┌─────────────────────┐
   │ LinkedIn            │              │ enrich_leads.md     │
   │ Google Maps         │              │ (orchestrator)      │
   │ Apollo        ─?──▶ │  ── ? ──▶   │         │           │
   │ Yellow Pages        │              │ ┌─────────────────┐ │
   │ Yelp                │              │ │friendly_name    │ │
   │ Crunchbase          │              │ │reviews          │ │
   └─────────────────────┘              │ │email            │ │
          ⚠️ Router exists               │ └─────────────────┘ │
          sources need testing          └─────────────────────┘

QWF Creative (Router Built, Execution Light 📋)

                    ┌─────────────────────┐
    Request ─────▶  │ qwf-master-router   │  ✅ Complete
                    └────────┬────────────┘
                             │
        ┌────────────────────┼────────────────────┐
        ▼                    ▼                    ▼
  ┌───────────┐       ┌───────────┐       ┌───────────┐
  │qwf-writer │       │qwf-       │       │qwf-social │
  │📋 Light   │       │creative-  │       │-media-    │
  │execution  │       │director   │       │manager    │
  └───────────┘       │📋 Light   │       │📋 Light   │
                      └───────────┘       └───────────┘

Component Health Scorecard

Known Gaps (January 2026)

Running the Audit

Trigger: Monthly (1st of month) or on-demand

Command:

/audit-system

Or ask Claude: "Run a comprehensive system architecture audit with ultrathink"

Process:

1. Claude explores all directives, scripts, agents, skills
2. Maps dependencies and integrations
3. Identifies gaps and incomplete work
4. Generates health scorecard
5. Produces recommendations

Directive: 005 Operations/Directives/audit_system_architecture.md

Audit Output Template

Each audit produces:

1. Architecture Diagram - Visual map of system components
2. Integration Map - What connects to what (strong/weak)
3. Health Scorecard - Component completeness percentages
4. Gap Analysis - What's missing or broken
5. Recommendations - Prioritized next actions
6. Comparison - Changes since last audit (if available)

Audit History

Student Learning Objectives

This audit system teaches students:

1. Systems Thinking - How components interconnect
2. Technical Debt Awareness - Identifying incomplete work
3. Documentation Discipline - Maintaining living docs
4. Architecture Visualization - Diagramming complex systems
5. Prioritization - Ranking gaps by severity/impact

EPIC Appointment Intelligence System v2.0 ⭐ NEW

Added: Session 22 (January 13, 2026)

The Reframe

What we thought: Build a lead-to-appointment conversion pipeline
What we learned: Appointments don't come from lead generation - they come from speaking engagements, referrals, networking, and relationship reconnections

The Real Opportunity: TIG is often booked 8 months in advance. Those 8 months are not empty waiting time - they're the beginning of Stage One: Hope for a Better Future.

Core Components

Waiting Period Philosophy

"By the time they sit down with TIG, he should know what they love, who shaped them, what they dream about, and what challenges they face. And they should feel known, valued, safe, hopeful, and excited."

The waiting period embodies the first 4 of TIG's 7 Steps of Mentorship:

1. Love them like they've never been loved before ← Every message
2. Come alongside so they know they're not alone ← Consistent presence
3. Help them see hope for a better future ← Stories, wisdom, QWU
4. Help them discover their purpose ← Questions, reflection

Timeline Intelligence

Four Tracks (Entry Points)

The 11 EPIC Capabilities

Key Files

Directives:

• waiting_period_experience.md - THE CORE journey system
• sequence_appointment_followup.md - Pre/post meeting automation
• multi_channel_booking.md - Channel handling
• smart_scheduling_assistant.md - Intelligent scheduling
• meeting_type_templates.md - Pre-configured meetings
• vip_white_glove.md - Inner Circle experience
• appointment_analytics.md - Analytics dashboard
• scheduling_negotiation.md - AI conversation handling
• circle_auto_management.md - Relationship lifecycle

Scripts:

• initiate_waiting_period.py - Start sequence on booking
• calculate_journey_tier.py - Determine timeline tier
• detect_visitor_track.py - Identify track type
• select_journey_content.py - Choose appropriate content
• send_journey_message.py - Deliver touchpoints
• record_journey_response.py - Capture responses
• check_content_history.py - Prevent repeats

Templates:

• waiting_period_questions.md - Question progression (L1→L4)
• waiting_period_content_map.md - Content calendar by phase

Success Metrics

The Ultimate Metric: Do they feel loved, not alone, and hopeful before they ever shake TIG's hand?

Measurable:

• Journey completion rate (target: 60%+)
• Question response rate (target: 40%+)
• Show rate (target: 95%+)
• Circle progression rate

Ezer Aión Assistant System ⭐ NEW

Added: Session 22 (January 13, 2026)

Who Is Ezer Aión?

From the Splinter universe: An ancient companion who has traveled with adventurers across centuries, providing cognitive connection and unwavering support. Not a servant. Not a tool. A partner who runs toward danger alongside you.

In the real world: TIG's AI-powered assistant and the friendly face of QWU's automated operations. She handles outreach, verification, scheduling, and the thousand small tasks that keep the mission moving forward.

The Name

Core Voice Attributes

1. Eternal Companion - Timeless patience, not urgency
2. Warm Transparency - Always honest, even when uncertain
3. Gentle Efficiency - Gets things done without being cold
4. Patient Guide - Never makes anyone feel dumb
5. Quietly Present - Always there when needed

Hemingway Principles

Capabilities

Key Files

Voice Profile: 003 Entities/Voice Profiles/Ezer Aión/Brand Voice.md
FAQ: 004 Knowledge/FAQ/Ezer FAQ.md

Directives:

• ezer_respond.md - Response handler SOP
• enrich_linkedin_url.md - LinkedIn enrichment
• send_linkedin_verification_email.md - Verification workflow
• sms_timing_rules.md - Communication timing

Scripts:

• ezer_respond.py - Main response handler with Claude API
• find_linkedin_url.py - Search for LinkedIn profiles
• prepare_verification_batch.py - Batch preparation
• send_verification_email.py - Send via Microsoft Graph
• update_entity_linkedin.py - Update entity files
• sms_timing.py - SMS delivery timing rules

Standard Signature

Cheers,
Ez 💙

Ezer Aión | Assistant to Chaplain TIG
Quietly Working Foundation
quietlyworking.org

Email Conventions

All outbound emails from Ezer follow the Email Sending Conventions documented in the BNI Visitor Pipeline section. Enhancement emails (automated follow-ups, touchpoints, reports) include a preference management footer and check opt-out status before sending. Exempt emails (transactional, conversational) do not. All emails BCC TIG. See [[#Email Sending Conventions (System-Wide)]] for the full classification table.

The Long Game

Every interaction builds toward a future where "Got an email from Ez" feels normal and welcome across the entire QWU network.

Ezer Omnibus - Unified Communication Gateway ⭐ NEW

Added: Session 24 (January 16, 2026)

Ezer Omnibus is the unified communication intelligence system that routes all incoming messages (SMS, Discord, Voice) through a single intelligent gateway with full access to QWU's knowledge base, calendar, contacts, health tracking, and program operations.

Vision: "One conversation, every channel, complete context."

Architecture

                          INBOUND CHANNELS
    ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
    │    SMS      │     │   Discord   │     │   Voice     │
    │  (Twilio)   │     │    (DM)     │     │  (Whisper)  │
    │             │     │             │     │             │
    │  External   │     │   TIG's     │     │ Voice msgs  │
    │  inquiries  │     │  interface  │     │ transcribed │
    └──────┬──────┘     └──────┬──────┘     └──────┬──────┘
           │                   │                   │
           └───────────────────┼───────────────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │   UNIFIED ROUTER    │
                    │                     │
                    │ • Normalize input   │
                    │ • Identify sender   │
                    │ • Classify intent   │
                    │ • Route to handler  │
                    └──────────┬──────────┘
                               │
           ┌─────────┬─────────┼─────────┬─────────┐
           ▼         ▼         ▼         ▼         ▼
    ┌──────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
    │ Approval │ │Calendar│ │ Health │ │Program │ │General │
    │ Handler  │ │Handler │ │Handler │ │Handler │ │ Query  │
    │          │ │        │ │        │ │        │ │Handler │
    │ YES/NO   │ │ Events │ │BP, meds│ │L4G/WOH │ │Claude  │
    └──────────┘ └────────┘ └────────┘ └────────┘ └────────┘

Intent Classification

Handler Capabilities

Access Levels

Key Scripts

SuiteDash Integration

Program inquiries automatically create CRM leads:

Setting these custom fields triggers SuiteDash Path A automations for student outreach.

Usage Examples

SMS Health Tracking:

→ "BP 118/78 pulse 68"
← "Recorded: 118/78 mmHg, pulse 68 bpm
   7-day avg: 121/79
   Status: Within normal range"

MMS Health Screenshot (v2.8+):

→ [Sends photo of Eufy scale or sleep tracker screenshot]
← "Recorded: 186.1 lbs, BMI 22.0, 11.5% body fat. 7-day avg: 185.8 lbs"
[Automatically extracts metrics using IMAGE tier (Gemini 3 Pro), logs to health tracker]

MMS Reference Image (v2.8+):

→ [Sends photo of a receipt or reference image]
← "Saved! [AI description]. I'll remember this."
[Stores in 000 Inbox/___Capture/ with AI-generated metadata for future search]

SMS Calendar Query:

→ "What's on my calendar tomorrow?"
← "Tomorrow (Thu Jan 16):
   • 9:00 AM - BNI Meeting (1h)
   • 2:00 PM - Client Call (30m)
   2 events, 1.5 hours scheduled"

SMS Program Inquiry:

→ "I'm interested in advertising with L4G"
← "Thank you for your interest in supporting QWF through Locals 4 Good!
   A member of our student outreach team will contact you within 24 hours."
[Creates SuiteDash lead, notifies #l4g-leads Discord]

Discord General Query:

→ "What does the research say about 3D Gaussian Splatting?"
← "Based on recent research from George Drettakis and the INRIA team,
   3DGS offers real-time rendering at 30+ fps while maintaining high
   visual quality comparable to NeRF..."
[Pulls from Wisdom DB with expert attribution]

Master Directive

See: 005 Operations/Directives/ezer_omnibus.md for complete technical specification.

Phase 7: Proactive Intelligence ⭐ NEW

Added: Session 26 (January 16, 2026)

Ezer evolves from reactive (responds when prompted) to proactive (anticipates needs).

New Components

Cross-Channel Memory

All conversations now persist across SMS, Discord, and Email:

# Record a message
from ezer_memory import record_message, get_conversation_context

record_message(channel="sms", user_id="+1234567890", role="user", content="BP 120/80")

# Get context across all channels
context = get_conversation_context(user_id="+1234567890", limit=10, hours_back=24)

Features:

• Commitment extraction ("remind me to..." → tracked)
• User identity linking across channels
• Searchable conversation history

Proactive Scheduler

Automated outbound communications:

# Morning health check-in
python ezer_scheduler.py health-checkin --json

# Send reminder
python ezer_scheduler.py reminder --user "+1234567890" --message "Call John" --json

# Check status
python ezer_scheduler.py status --json

n8n Workflows:

Briefing Engine

Multi-source briefings accessible via CLI or SMS:

# Morning briefing (calendar + health + commitments)
python ezer_briefing.py morning --json

# Brief on a person (SuiteDash + Vault + Memory)
python ezer_briefing.py person "Sarah Chen" --json

# Brief on a topic (Wisdom DB + Memory)
python ezer_briefing.py topic "3D Gaussian Splatting" --json

SMS Usage:

→ "brief me"
← "Friday, January 16, 2026
   📅 8 events (9.75 hours)
   💊 BP: 118/76 (on track)
   📋 0 pending commitments"

Morning Health Check-in Flow

[7:00 AM - Automated SMS from Ezer]
"Good morning! Ready for your BP reading?
Yesterday: 118/78
Reply with: BP [reading] pulse [rate]"

[TIG replies]
"BP 120/80 pulse 70"

[Ezer responds]
"Recorded! 7-day avg: 119/79. You're on track."

Phase 8: Backoffice Agent ⭐ NEW

Added: Session 52 (January 26, 2026)

Ezer can now execute full Claude Code operations via SMS, giving TIG backoffice access from anywhere.

Why This Matters

Previously, fixing a broken script or checking logs required VS Code + SSH. Now TIG can text Ez to:

• Run system audits
• Fix errors in code
• Check logs and system status
• Deploy fixes
• Execute scripts

Architecture

SMS from TIG
    ↓
Intent Classifier (BACKOFFICE_COMMAND)
    ↓
BackofficeHandler
    ↓
ezer_backoffice_agent.py
    ↓
Claude Agent SDK
    ├─ Read (always safe)
    ├─ Glob (always safe)
    ├─ Grep (always safe)
    ├─ Bash (allowlisted commands)
    ├─ Edit (safe paths only)
    └─ Write (safe paths only)
    ↓
Response Summary
    ├─ SMS to TIG (concise)
    └─ Discord #agent-log (full audit)

Safety Controls

Confirmation Flow

Risky operations require explicit confirmation:

TIG: "Push the latest fixes"
Ez: "This will push code to remote repository.
    Reply YES to confirm or NO to cancel."
TIG: "YES"
Ez: "Pushed to origin/main. 2 files changed."

Usage Examples

Simple Query:

→ "What's broken?"
← "System healthy. Last audit: 2 warnings
   (both resolved). No errors in logs."

Run Audit:

→ "Run the audit ez"
← "Audit complete. Found 2 issues:
   1. ✅ Fixed: model_config.py outdated tier
   2. ✅ Fixed: 3 workflows missing publish
   Cost: $0.67 | 5 turns | Report in Discord"

Fix Error:

→ "Fix the broken n8n workflow"
← "Fixed workflow.json - invalid JSON on
   line 47 (missing comma). Deployed.
   Cost: $0.18 | 3 turns"

Check Logs:

→ "What's in the error logs today?"
← "3 entries today:
   - 08:15 n8n timeout (resolved)
   - 11:42 API rate limit (retried)
   - 14:30 Discord 429 (backed off)
   All resolved. No action needed."

Directive & Scripts

Ezer Universal Interface ⭐ NEW

Added: Session 51 (January 25, 2026)

The Ezer Universal Interface is a cross-domain AI chat widget that provides a consistent conversational AI experience across all QWU-affiliated websites with progressive trust tiers and site-specific intelligence.

Key Concept: "The Octopus That Swims Through All Waters"

Ezer appears as a friendly octopus (🐙) toggle button on any QWU site. When clicked, it opens a CRT-styled chat sidebar. The same user identity persists across all domains via a cross-domain cookie bridge.

Trust Tier System

Phase 6: Site-Specific Intelligence

Each QWU site has its own context that shapes Ezer's behavior:

Architecture

┌──────────────────────────────────────────────────────────────┐
│  ANY QWU WEBSITE                                             │
│  ┌───────────────┐    ┌─────────────────────────────────────┐│
│  │   ezer.js     │────│  /api/ezer/context/{site}           ││
│  │   Widget      │    │  Returns: greeting, tools, tone,     ││
│  └───────┬───────┘    │           sensitivity, prompts       ││
│          │            └─────────────────────────────────────┘│
│          ▼                                                    │
│  ┌───────────────┐                                           │
│  │  bridge.html  │ (hidden iframe for cross-domain cookies)  │
│  └───────────────┘                                           │
└──────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌──────────────────────────────────────────────────────────────┐
│  CENTRAL API (twin.quietlyworking.org:8767)                  │
│  ┌─────────────────────────────────────────────────────────┐ │
│  │ /api/ezer            - Chat (site-aware system prompts) │ │
│  │ /api/ezer/identity   - Get/validate device tier         │ │
│  │ /api/ezer/remember   - Upgrade Tier 0 → 1               │ │
│  │ /api/ezer/introduce  - Upgrade Tier 1 → 2               │ │
│  │ /api/ezer/verify     - Send magic link (→ Tier 3)       │ │
│  │ /api/ezer/context/*  - Site-specific intelligence       │ │
│  └─────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘

Key Files

Widget:

• 100 Resources/ezer-widget/ezer.js - Standalone widget (v1.5.0)
• 100 Resources/ezer-widget/bridge.html - Cross-domain identity bridge
• 100 Resources/ezer-widget/demo.html - Testing page

Server:

• 005 Operations/Execution/digital_twin_server.py - Central API (v1.12.0)
• 005 Operations/Execution/ezer_site_contexts.json - Site configurations

Directive:

• 005 Operations/Directives/ezer_universal_interface.md - Full specification

Embedding on External Sites

<script src="https://twin.quietlyworking.org/ezer/ezer.js"></script>
<script>
  Ezer.init({ site: 'l4g' });  // Site-specific context
</script>

Language Rules (Nonprofit Terminology)

Ezer enforces QWF's nonprofit framing:

Missing Pixel Training Opportunity

Skill Level: Intermediate-Advanced

Strategic Goals Framework ⭐ NEW

Added: Session 22 (January 13, 2026)

2026 Strategic Initiatives