Description

Determine the outreach channel, message format, and personalized strategy for each prospect in outreach-v1.md. Update the G1 Outreach Playbook to reflect the new approach: previews (3 site options) are sent WITH the first message, not after a response.

Key decisions:

1. Which channel for each prospect? (IG DM, FB Messenger, email, phone, text, in-person)
2. How to present 3 preview options in the first touch? (link to chooser page? screenshots? video walkthrough?)
3. Different strategy for friends vs cold prospects?
4. How does the message template change when previews are included upfront?
5. Channel-specific constraints (IG DM character limits, email deliverability, FB Messenger auto-replies)

Acceptance Criteria

• G1 Playbook updated: preview-first approach replaces two-step model
• Channel + strategy assigned per prospect in outreach-v1.md
• Message templates updated for preview-first approach
• Any channel-specific constraints documented

Context

• Current playbook uses two-step model (§1): open conversation first, share preview after response
• Enrichment data has best_contact_channel per prospect but needs revisiting
• Outreach list: startersite-ai/ops/outreach/outreach-v1.md
• Scoring: startersite-ai/ops/outreach/enriched/scores.csv
• Enrichment: startersite-ai/ops/outreach/enriched/ (tier1–tier3c)

Description

LinkedIn headline said “Applied Data Scientist | GenAI Enthusiast” — sounded junior. Updated to match resume’s stronger positioning (Senior Data Scientist / ML Engineer / MLOps).

Resolution

Completed by Viktor manually.

Description

LinkedIn “Open to Work” listed Senior Data Scientist, Machine Learning Engineer, and Data Engineer. Updated to match current targets: Senior Data Scientist, Senior ML Engineer, Senior MLOps Engineer, ML Engineer, AI Engineer. Locations expanded beyond just Vancouver WA.

Resolution

Completed by Viktor manually.

Description

Write and run a Python script that systematically queries the Google Places API (via the goplaces CLI) across all target verticals and geographic areas in Clark County, WA. The goal is to build a comprehensive prospect database of local service businesses for outreach.

This is a data gathering task only — no analysis, scoring, or outreach. Just collect everything the API gives us and store it cleanly.

Setup

Repository

Clone viktor-bering/startersite-ai (private repo, GitHub org: viktor-bering). Work on branch berrypi/startersite-021.

Key locations in the repo

• Config: tools/outreach/sweep-config.json — already created. Contains all areas, verticals, search queries, and rate-limiting settings. Read this file to drive the sweep.
• Script location: Write the sweep script at tools/outreach/places_sweep.py
• Output location: ops/outreach/ — this is where all output CSVs and JSON files go

Tool: goplaces CLI

The goplaces CLI is already installed on klyuchi at /home/linuxbrew/.linuxbrew/bin/goplaces (v0.3.0). Your API key is configured in OpenClaw at skills.entries.goplaces.apiKey.

Set the environment before running:

export PATH=/home/linuxbrew/.linuxbrew/bin:$PATH
export GOOGLE_PLACES_API_KEY=<your key from OpenClaw config>

Key commands you’ll use:

# Text search (returns place_id, name, address, lat/lng, rating, review_count, types)
goplaces search "plumber Vancouver WA" --limit 20 --json

# Paginate (use next_page_token from previous result)
goplaces search "plumber Vancouver WA" --limit 20 --page-token "TOKEN_HERE" --json

# Location-biased search (NOTE: negative longitude needs = syntax)
goplaces search "plumber" --lat 45.6387 --lng="-122.6615" --radius-m 8000 --limit 20 --json

# Place details with reviews + photos (returns phone, website, hours, up to 5 reviews, up to 10 photos)
goplaces details PLACE_ID --reviews --photos --json

Important goplaces behavior:

• Search returns a JSON array of places + a next_page_token line on stdout (not inside the JSON). Parse both.
• --limit 20 is the max per request (API limit).
• Details with --reviews --photos returns up to 5 most relevant reviews and up to 10 photos per place.
• Negative longitude values MUST use --lng="-122.xxx" syntax (not --lng -122.xxx), otherwise the CLI misparses the negative sign as a flag.

What to build

Script: tools/outreach/places_sweep.py

A Python 3 script (stdlib only — no pip dependencies) that:

1. Reads sweep-config.json for areas, verticals, and settings
2. Runs a search pass — for each vertical × area combination:
   • Constructs a query: "<search_term> <area_name> WA" (e.g., "plumber Vancouver WA")
   • Also does a location-biased search: goplaces search "<search_term>" --lat <lat> --lng="<lng>" --radius-m <radius> --limit 20 --json
   • Paginates using --page-token until no more results (up to max_pages_per_query from config)
   • Waits delay_between_requests_ms between requests
   • Saves raw JSON responses to ops/outreach/places-raw/<vertical_id>-<area_name>.json
   • Logs every API call to ops/outreach/sweep-log.csv
3. Deduplicates — collects all unique place_ids across all search results
4. Runs a details pass — for each unique place_id:
   • Runs goplaces details <place_id> --reviews --photos --json
   • Waits delay_between_details_ms between requests
   • Saves the full details JSON to ops/outreach/details-raw/<place_id>.json
5. Generates CSV output — merges search + details data into CSVs

Search strategy

For each vertical, use location-biased search (not text-appended city names). This is more reliable for the API:

For each vertical:
  For each query in vertical.queries:
    For each area in areas:
      goplaces search "<query>" --lat <area.lat> --lng="<area.lng>" --radius-m <area.radius_m> --limit 20 --json
      → paginate if next_page_token exists (up to max_pages_per_query)
      → collect results

This means for a vertical with 2 queries across 10 areas, you’ll make 20+ search calls. The config has ~40 total queries across all verticals × 10 areas = ~400 search calls. With 500ms delay, that’s ~3-4 minutes for the search pass.

Output structure

ops/outreach/
├── places-raw/              # Raw search responses (JSON)
│   ├── plumbing-Vancouver-p1.json
│   ├── plumbing-Vancouver-p2.json    (if paginated)
│   ├── plumbing-Salmon_Creek-p1.json
│   └── ...
├── details-raw/             # Raw details responses (JSON), one per place
│   ├── ChIJq6qqqsaklVQRGC4CkmlH9pE.json
│   └── ...
├── prospects/               # Processed CSVs, one per vertical
│   ├── plumbing.csv
│   ├── landscaping.csv
│   └── ...
├── prospects-all.csv        # Combined, deduplicated, all verticals
├── reviews/                 # Review text, one JSON file per place
│   ├── ChIJq6qqqsaklVQRGC4CkmlH9pE.json
│   └── ...
├── sweep-log.csv            # Log of all API calls
└── sweep-summary.json       # Summary stats (total places, by vertical, by area)

CSV schema for prospect files

The CSV files in prospects/ and prospects-all.csv must have these columns:

place_id,name,vertical_id,market,address,city,state,lat,lng,rating,review_count,has_website,website_url,phone,business_status,primary_type,types,google_maps_url,hours_summary,photo_count,photo_references,review_1_rating,review_1_text,review_1_author,review_1_date,review_2_rating,review_2_text,review_2_author,review_2_date,review_3_rating,review_3_text,review_3_author,review_3_date,review_4_rating,review_4_text,review_4_author,review_4_date,review_5_rating,review_5_text,review_5_author,review_5_date,sweep_date,search_query,area

Column details:

• place_id — Google place ID (primary key for deduplication)
• name — business name
• vertical_id — from sweep-config (e.g., “plumbing”, “ru-auto-detailing”)
• market — “english” or “russian_market” (from which vertical group it came from)
• address — full formatted address
• city — extracted city from address (parse from formatted address)
• state — always “WA” for our sweep
• lat, lng — coordinates
• rating — Google rating (0-5, one decimal)
• review_count — total number of reviews
• has_website — “yes” or “no”
• website_url — URL or empty
• phone — phone number or empty
• business_status — from API (OPERATIONAL, CLOSED_TEMPORARILY, etc.)
• primary_type — from API
• types — semicolon-separated list of all types
• google_maps_url — link to Google Maps listing
• hours_summary — pipe-separated hours string (e.g., “Mon: 8AM-5PM|Tue: 8AM-5PM|…”)
• photo_count — number of photos returned by details
• photo_references — semicolon-separated list of photo name fields from the API (e.g., places/ChIJ.../photos/ATCDNf...;places/ChIJ.../photos/ATCDNf...). These can be used to fetch actual photo URLs via the Places Photos API later.
• review_N_rating — rating of Nth review (1-5)
• review_N_text — full text of Nth review (escape commas and newlines for CSV)
• review_N_author — author display name
• review_N_date — publish_time ISO date
• sweep_date — ISO date of when the sweep was run
• search_query — the query string that found this place
• area — area name from config (e.g., “Vancouver”, “Camas”)

Important CSV handling:

• Use proper CSV escaping — double-quote fields that contain commas, newlines, or quotes
• Review text often contains commas, newlines, and quotes — these MUST be properly escaped
• If a place appears in multiple verticals or areas, keep only the first occurrence in prospects-all.csv (deduplicate by place_id). In per-vertical CSVs, a place can appear in multiple vertical files if it was found under multiple verticals.

Sweep log CSV

timestamp,action,query,area,vertical_id,page,result_count,next_page_token_exists,place_id,error

Log every API call (search and details) with timestamp, what was queried, and the result count. If an API call fails, log the error and continue (don’t abort the whole sweep).

Sweep summary JSON

After the sweep completes, generate sweep-summary.json:

{
  "sweep_date": "2026-03-14",
  "total_search_calls": 420,
  "total_detail_calls": 650,
  "total_unique_places": 650,
  "total_places_no_website": 180,
  "by_vertical": {
    "plumbing": { "total": 85, "no_website": 12 },
    ...
  },
  "by_area": {
    "Vancouver": { "total": 200, "no_website": 45 },
    ...
  },
  "errors": []
}

Resumability

The script should be resumable. If it crashes or is interrupted:

• Before making a search call, check if places-raw/<filename>.json already exists. If yes, skip it and load from file.
• Before making a details call, check if details-raw/<place_id>.json already exists. If yes, skip it and load from file.
• This means you can safely re-run the script and it will pick up where it left off.

Error handling

• If a goplaces call fails (non-zero exit, malformed JSON), log the error in sweep-log.csv and continue with the next query/place.
• If the API returns an empty result set for a query, that’s fine — log it and move on.
• At the end, report total errors in sweep-summary.json.

Implementation notes

• Use subprocess.run() to run goplaces commands. Capture stdout and parse as JSON.
• The next_page_token is printed on a separate line after the JSON array in goplaces search output. You need to parse it separately — it’s NOT inside the JSON. The format is: next_page_token: <TOKEN>. If this line is absent, there are no more pages.
• Use os.makedirs(path, exist_ok=True) to create output directories.
• Use Python’s csv module for CSV writing (handles escaping correctly).
• Use only stdlib modules: subprocess, json, csv, os, sys, time, argparse, pathlib, datetime.
• The script should be runnable with: python3 tools/outreach/places_sweep.py
• Print progress to stdout: [search] plumbing / Vancouver (page 1) — 20 results and [details] 142/650 — Service Pro Plumbing Inc
• At the end, print the summary stats.

Testing

Before running the full sweep, test with a single vertical + single area:

python3 tools/outreach/places_sweep.py --test

The --test flag should run only the first vertical’s first query in the first area (1 search + details for results). Verify:

1. Raw JSON files are saved correctly
2. CSV output is well-formed (open in a spreadsheet)
3. Reviews with commas/newlines don’t break CSV
4. Sweep log captures the calls
5. Resumability works (re-run and verify it skips existing files)

Acceptance Criteria

• [ ] tools/outreach/places_sweep.py exists and runs with python3 tools/outreach/places_sweep.py
• [ ] --test flag works for single-query dry run
• [ ] Full sweep completes without crashing (errors logged, not thrown)
• [ ] ops/outreach/places-raw/ contains raw search JSON files
• [ ] ops/outreach/details-raw/ contains raw detail JSON files for each unique place
• [ ] ops/outreach/prospects/ contains one CSV per vertical with all columns populated
• [ ] ops/outreach/prospects-all.csv contains deduplicated combined data
• [ ] ops/outreach/reviews/ contains review JSON files per place
• [ ] ops/outreach/sweep-log.csv logs all API calls
• [ ] ops/outreach/sweep-summary.json has aggregate stats
• [ ] CSV files open correctly in a spreadsheet (proper escaping)
• [ ] Script is resumable (re-run skips existing files)
• [ ] Commit script + config to berrypi/startersite-021 branch, push to origin

Context

• Outreach playbook: docs/growth/G1-outreach-playbook.md (§2 Research Pipeline)
• This is Phase 1 of the research pipeline — data gathering only
• The data will be used later for manual enrichment (Phase 2) and scoring (Phase 3)
• All output data (CSVs, raw JSON) is committed to git — it’s all public Google Maps data

Notes

• 2026-03-15T03:10:57Z — FAILED: Agent did not output a JSON report — No structured report found in agent output

• 2026-03-15T02:41:24Z — FAILED: Agent did not output a JSON report — No structured report found in agent output

• 2026-03-14T22:36:40Z — FAILED: Agent did not output a JSON report — No structured report found in agent output

• 2026-03-14 — Sweep completed successfully (1,576 places found). Data validated by Viktor.

• 2026-03-14 — Bounding box filter added, but INCOMPLETE. The filter only checks lat/lng bounding box. It does NOT check the address for ", WA ". Result: 123 Oregon businesses (Portland, St Helens, Troutdale, Gresham) are still in the data because they fall within the lat/lng box (they’re just across the river). This MUST be fixed.

Remaining work — KICKED BACK

The geographic filter is incomplete. You added the bounding box check but missed the second condition. The filter must use BOTH:

1. Bounding box from sweep-config.json (field: bounding_box) — ✅ done
2. Address string must contain ", WA " (case-sensitive, with comma and spaces) — ❌ NOT DONE

Current state of the data:

• prospects-all.csv has 1,201 rows but 123 are Oregon (Portland: 76, St Helens: 28, Troutdale: 14, etc.)
• After the ", WA " filter is applied, expect ~1,078 rows with ~210 no-website

What to do:

1. Open tools/outreach/places_sweep.py
2. Find the bounding box filter code
3. Add a second condition: ", WA " in address (check the address field from the details JSON)
4. Re-run the script (it will skip all API calls due to resumability, just regenerate CSVs)
5. Verify: prospects-all.csv should have ZERO rows where the address contains Oregon cities
6. Update sweep-summary.json with filtered counts
7. Commit and push

• Commit everything to git — script, config, AND all output data (CSVs, raw JSON). This is all public Google Maps data, not private.
• The sweep-config.json has the bounding_box field. The ", WA " check is a hardcoded string match, not config-driven.
• Russian-language queries (e.g., “детейлинг”) should work fine with goplaces search — the API handles Unicode.

Description

Move all files from the wildus-media R2 bucket to the shared folder at /home/shared/ so BerryPi can also access them.

Instructions

1. Use rclone (already configured) to copy all files from R2 to the shared folder:

   rclone copy wildus-media:wildus-media /home/shared/wildus-media/ --progress
   

2. Verify the file counts and sizes match between R2 and the local copy
3. Preserve the existing directory structure (e.g., discord/animation-video/...)
4. Do NOT delete the files from R2 — this is a copy, not a move

Acceptance Criteria

• All files from wildus-media R2 bucket are copied to /home/shared/wildus-media/
• Directory structure is preserved
• File counts match between source and destination
• Files in /home/shared/ are group-writable (they should be automatically via setgid)
• R2 originals are still intact

Description

Upload the wildus media files from the shared folder to Google Drive, organized under wildus/media-assets/.

Prerequisites

• wildus-036 is complete — files are in /home/shared/wildus-media/

Instructions

Use gog CLI (installed at /home/linuxbrew/.linuxbrew/bin/gog) with account viktor@qoyn.ai for all Google Drive operations.

1. Create folder structure in Viktor’s Google Drive: wildus/media-assets/

   gog drive mkdir wildus -a viktor@qoyn.ai
   gog drive mkdir media-assets --parent <wildus-folder-id> -a viktor@qoyn.ai
   

2. Upload all files from /home/shared/wildus-media/ into wildus/media-assets/, preserving the directory structure
3. Share the wildus folder with anna@qoyn.ai (editor access)

   gog drive share <wildus-folder-id> --email anna@qoyn.ai --role writer -a viktor@qoyn.ai
   

   • If sharing fails programmatically, that’s fine — just note it in your report so Viktor can share manually. This is non-blocking.
4. Verify upload completed and file counts match (116 files expected)

Acceptance Criteria

• wildus/media-assets/ folder exists in Viktor’s Google Drive
• All files from /home/shared/wildus-media/ are uploaded with directory structure preserved
• Sharing with anna@qoyn.ai either done or flagged for Viktor to do manually

Description

Create the Wild Us TikTok account. Registration priority #2 — @wildus status on TikTok is inconclusive (occupied with 0 likes, may be reclaimable); @wild.us needs live verification. High competition platform — register soon.

After registration, document the signup flow so we have a playbook for future brands on this platform.

Acceptance Criteria

• TikTok account created with handle (per checklist fallback order: @wildus → @wild.us → @wildus_official → @wildusbrand)
• Bio drafted and set
• 2FA enabled (2-step verification)
• Recovery codes saved
• vault/brand/claimed-handles.md updated
• Signup flow documented — write up what happened in the task notes: fields per step, verification gates, anti-bot measures, profile setup options, quirks

Context

• @wildus on TikTok: occupied (569 following, 78 followers, 0 likes, no bio) — may be dormant
• @wildusbrand appears open
• Signup email: tiktok@wildus.org (Google Workspace alias → viktor@qoyn.ai)
• Google SSO or native signup both viable
• See vault/brand/social-handle-registration-checklist.md

Default Data

Lessons from X/Twitter Registration

See the X/Twitter playbook for the full writeup.

These lessons apply to all platform registrations:

• One attempt only. Multiple retries create partial accounts, reserve handles in limbo, and trigger rate limits that block you for hours. If the first attempt fails, stop and notify Viktor — do not retry.
• Handle may be auto-assigned. Some platforms assign a random handle during signup and require you to change it post-signup. If the platform doesn’t offer a handle field during signup, note what was assigned and move on to post-signup settings.
• Anti-bot measures block automated browsers. CAPTCHAs, Arkose, and blank spinners can appear at any point. If you hit one, immediately hand off to Viktor via notify-viktor + wait-for-viktor. Do not try to solve or bypass it.
• Viktor handles sensitive steps. Verification codes, password entry, and handle changes are best done by Viktor via Screen Sharing. The agent’s role is to fill the initial form and set up the profile afterwards.

Steps

1. Open a clean browser session (no existing TikTok cookies)
2. Navigate to https://www.tiktok.com/signup
3. Fill in the form using the default data above
4. At any verification gate (email code, CAPTCHA, phone):
   • Run notify-viktor "<what you need>" — sends Telegram with Screen Share button
   • Run wait-for-viktor — blocks until Viktor connects, handles it, and disconnects
   • Resume once wait-for-viktor returns
5. Set username: try @wildus first. If taken, try @wild.us → @wildus_official → @wildusbrand
   • Note: If TikTok auto-assigns a handle, change it in profile settings after account creation
6. Complete any profile setup steps (bio, avatar, interests — skip what’s skippable, fill in what’s useful)
7. Enable 2FA (2-step verification)
8. Save recovery codes
9. Update vault/brand/claimed-handles.md with the claimed handle, email, date, and status
10. If anything goes wrong — STOP. Do not retry. Notify Viktor and wait for instructions.

After Registration — Document the Flow

Write up the signup experience in the task notes using the format from the social handle registration process.

If You Get Stuck

If you hit a blocker that requires human input (CAPTCHA, phone verification, manual confirmation, email verification code):

1. Run notify-viktor "<description of what you need>" — this sends a Telegram message with a Screen Share button
2. Run wait-for-viktor — blocks until Viktor connects via Screen Sharing, handles the gate, and disconnects
3. Once wait-for-viktor returns, resume your work
4. Fallback: If wait-for-viktor is not available or times out, poll the page state every 5 seconds — watch for changes
5. Do NOT retry aggressively — one calm attempt, then notify and wait

Dependencies

wildus-003 (handle checklist — done), wildus-016 (X registration — do X first to secure @wildus)

Notes

• 2026-03-12 — Reprioritized to #2 after X. Google Workspace on qoyn.ai replaces the Gmail anchor strategy.
• 2026-03-13 — Merged with single-pass approach. No separate recon — document the flow as a byproduct of registration.
• 2026-03-13 — Viktor registered manually. Handle: @wildus_official (@wildus and @wild.us both taken). Bio: Wild and unbothered 🌲 PNW apparel with a conservation mission. soon→ wildus.org (80 char limit). 2FA enabled: phone + Google Authenticator + email. Email: tiktok@wildus.org.

Decisions

Description

Create the Wild Us X/Twitter account. This is the #1 registration priority — @wildus appears available on X (public check: “This account doesn’t exist”). This is the only major platform where the primary handle is still open.

After registration, document the signup flow (fields, gates, quirks) so we have a playbook for future brands on this platform.

Acceptance Criteria

• X account created with handle (per checklist fallback order: @wildus → @wild_us → @wildus_official → @wildusbrand)
• Bio drafted and set
• 2FA enabled (authenticator app preferred)
• Recovery codes saved
• vault/brand/claimed-handles.md updated
• Signup flow documented — write up what happened in the task notes: fields per step, verification gates, anti-bot measures, profile setup options, quirks

Context

• @wildus is available on X — claim ASAP before someone else takes it
• X doesn’t support dot format — wild.us is invalid here
• Signup email: x@wildus.org (Google Workspace alias → viktor@qoyn.ai)
• Native email signup preferred (no SSO dependency)
• See vault/brand/social-handle-registration-checklist.md

Default Data

Steps

1. Open a clean browser session (no existing X cookies)
2. Navigate to https://x.com/i/flow/signup
3. Choose email signup (not Google/Apple SSO)
4. Fill in the form using the default data above
5. At any verification gate (email code, CAPTCHA, phone):
   • Run notify-viktor "<what you need>" — sends Telegram with Screen Share button
   • Run wait-for-viktor — blocks until Viktor connects, handles it, and disconnects
   • Resume once wait-for-viktor returns
6. Set username: try @wildus first. If taken, try @wild_us → @wildus_official → @wildusbrand
7. Complete any profile setup steps (bio, avatar, interests — skip what’s skippable, fill in what’s useful)
8. Enable 2FA (authenticator app preferred)
9. Save recovery codes
10. Update vault/brand/claimed-handles.md with the claimed handle, email, date, and status

After Registration — Document the Flow

Write up the signup experience in the task notes so we can reuse it:

### Signup Flow Report
- Signup path taken: (email / Google SSO / Apple)
- Total steps: N

### Step 1 — [Screen Title]
| Field | Type | Required | Constraints | Notes |
|---|---|---|---|---|
| ... | ... | ... | ... | ... |

### Verification Gates
- Email code: yes/no
- Phone: yes/no
- CAPTCHA: yes/no
- Other: ...

### Anti-Bot Measures
- ...

### Post-Signup Profile Fields
- (what was available to set immediately after account creation)

### Quirks
- (anything unexpected)

If You Get Stuck

If you hit a blocker that requires human input (CAPTCHA, phone verification, manual confirmation, email verification code):

1. Run notify-viktor "<description of what you need>" — this sends a Telegram message with a Screen Share button
2. Run wait-for-viktor — blocks until Viktor connects via Screen Sharing, handles the gate, and disconnects
3. Once wait-for-viktor returns, resume your work
4. Fallback: If wait-for-viktor is not available or times out, poll the page state every 5 seconds — watch for changes
5. Do NOT retry aggressively — one calm attempt, then notify and wait

Dependencies

wildus-003 (handle checklist — done)

Notes

• 2026-03-12 — Reprioritized to #1. Only major platform where @wildus is still available. Google Workspace on qoyn.ai replaces the Gmail anchor strategy.
• 2026-03-13 — Absorbed wildus-029 (recon). No separate recon pass — go straight to registration, document the flow afterwards.
• 2026-03-13 — Account created with x@wildus.org after multiple CrankyCrab attempts. X auto-assigned handle @wildus18890 instead of @wildus. Multiple retries triggered X rate limiting. Viktor logged in successfully but cannot change handle yet — “rate limited, please try again later.” @wildus shows “this account doesn’t exist” publicly but X won’t assign it — likely held in limbo from partial signup attempts.
• 2026-03-13 — Viktor registered manually. Handle @wildus14696 (auto-assigned). DOB on file: 09/25/1984. Still rate-limited, cannot change handle. @wildus appears taken/held — likely on a release timer from prior partial signups. Handle change deferred to wildus-032.
• 2026-03-13 — 2FA enabled (Google Authenticator). Bio set.

Decisions

• Recon phase dropped — standard signup forms don’t need a pre-pass. Document the flow as a byproduct of the first real registration.
• Lesson learned: limit agent to one attempt per dispatch. Multiple retries burned X rate limits and created a partial account with a junk handle.

Description

Create and deploy notification and synchronization scripts on tolbachik (CrankyCrab’s machine):

1. notify-viktor — Sends a Telegram message to Viktor when CrankyCrab hits a blocker. ✅ Done.
2. wait-for-viktor — Blocks until Viktor connects via Screen Sharing, does his work, and disconnects. Detects VNC session on port 5900. ✅ Done.

Together these form the human-in-the-loop protocol: agent notifies → Viktor connects → agent detects connection and waits → Viktor disconnects → agent resumes.

Acceptance Criteria

notify-viktor ✅

1. Script notify-viktor exists on tolbachik at /usr/local/bin/notify-viktor
2. Usage: notify-viktor "message text" — sends a Telegram message to Viktor’s chat
3. Uses BerryPi’s Telegram bot token via Telegram Bot API
4. Sends to Viktor’s Telegram user ID (1291467684)
5. Message format includes: agent name (CrankyCrab), machine (tolbachik), timestamp, and the message text
6. Message includes inline “Screen Share” button linking to https://connect.qoyn.ai/tolbachik
7. Script is executable by the r2d22 user
8. Tested end-to-end: message delivered to Viktor’s Telegram

wait-for-viktor (new)

1. Script wait-for-viktor exists on tolbachik at /usr/local/bin/wait-for-viktor
2. Detects active Screen Sharing (VNC) connections by checking port 5900 for ESTABLISHED connections
3. Flow:
   • Poll until a VNC connection is detected (Viktor connected)
   • Poll until the VNC connection drops (Viktor disconnected = “I’m done”)
   • Exit successfully — agent resumes
4. Configurable poll interval (default: 5 seconds)
5. Timeout after 30 minutes with non-zero exit if no connection arrives
6. Prints status messages so the agent knows what’s happening:
   • Waiting for Viktor to connect via Screen Sharing...
   • Viktor connected. Waiting for him to finish...
   • Viktor disconnected. Resuming.
7. Executable by r2d22 user

Implementation

notify-viktor (deployed)

#!/bin/bash
# notify-viktor — send a Telegram message to Viktor from CrankyCrab
# Uses BerryPi bot as relay. Deployed as part of workforce-015.
BOT_TOKEN="<telegram-bot-token>"
CHAT_ID="1291467684"

if [ -z "$1" ] && [ -t 0 ]; then
  echo "Usage: notify-viktor <message>" >&2
  exit 1
fi

MSG="${*:-$(cat)}"
TEXT="🦀 *CrankyCrab* (tolbachik) — $(date "+%Y-%m-%d %H:%M:%S %Z")
${MSG}"

KEYBOARD="{\"inline_keyboard\":[[{\"text\":\"🖥 Screen Share\",\"url\":\"https://connect.qoyn.ai/tolbachik\"}]]}"

curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
  -d chat_id="${CHAT_ID}" \
  -d text="${TEXT}" \
  -d parse_mode="Markdown" \
  -d reply_markup="${KEYBOARD}" > /dev/null 2>&1

if [ $? -eq 0 ]; then
  echo "Notification sent to Viktor."
else
  echo "Failed to send notification." >&2
  exit 1
fi

wait-for-viktor (deployed)

#!/bin/bash
# wait-for-viktor — wait for Viktor to connect via Screen Sharing, do his work, and disconnect
# Detects VNC sessions on port 5900. Deployed as part of workforce-015.

POLL_INTERVAL="${1:-5}"    # seconds between checks (default: 5)
TIMEOUT=1800               # 30 minutes max wait

elapsed=0

# Phase 1: Wait for Viktor to connect
echo "Waiting for Viktor to connect via Screen Sharing..."
while true; do
  if netstat -an | grep '\.5900 ' | grep -q ESTABLISHED; then
    echo "Viktor connected. Waiting for him to finish..."
    break
  fi
  sleep "$POLL_INTERVAL"
  elapsed=$((elapsed + POLL_INTERVAL))
  if [ "$elapsed" -ge "$TIMEOUT" ]; then
    echo "Timed out waiting for Screen Sharing connection." >&2
    exit 1
  fi
done

# Phase 2: Wait for Viktor to disconnect
while true; do
  if ! netstat -an | grep '\.5900 ' | grep -q ESTABLISHED; then
    echo "Viktor disconnected. Resuming."
    break
  fi
  sleep "$POLL_INTERVAL"
done

Usage Pattern (for agent tasks)

# 1. Hit a gate — notify and wait
notify-viktor "Need email verification code entered for X signup"
wait-for-viktor

# 2. Agent resumes automatically after Viktor disconnects

Context

• CrankyCrab runs as user r2d22 on tolbachik (2018 MBP, macOS)
• Screen Sharing (VNC) runs on port 5900, enabled via Remote Management (workforce-016)
• Tailscale VNC URL: vnc://100.107.199.18
• connect.qoyn.ai/tolbachik redirects HTTPS → VNC for Telegram button
• This is a prerequisite for all social handle registration tasks (wildus-013 through wildus-018)

Notes

• 2026-03-12 — notify-viktor deployed to /usr/local/bin/notify-viktor on tolbachik. Uses BerryPi’s bot (huckleberrypi_bot). Tested end-to-end.
• 2026-03-12 — Reopened to add wait-for-viktor script. VNC disconnect = “Viktor is done” signal, cleaner than page-state polling alone.
• 2026-03-13 — wait-for-viktor deployed to /usr/local/bin/wait-for-viktor on tolbachik. Verified netstat pattern detects VNC ESTABLISHED connections on port 5900. Both scripts complete.
• CrankyCrab’s old Telegram bot was deleted; token scrubbed.

Decisions

• Reuse BerryPi’s Telegram bot rather than creating a new one — fewer bots to manage, Viktor already has a chat with it.
• VNC disconnect as “done” signal — more reliable than page-state polling. Page-state polling remains as a fallback in task instructions (in case Viktor fixes something without VNC).

Description

Enable macOS Screen Sharing on tolbachik so Viktor can remotely view and control CrankyCrab’s browser session. Access should work over Tailscale so it’s reachable from anywhere, not just the local network.

Acceptance Criteria

1. macOS Screen Sharing enabled on tolbachik (System Settings → General → Sharing → Screen Sharing)
2. Access restricted to Viktor’s user or a specific VNC password
3. Reachable via Tailscale IP (tolbachik’s Tailscale address)
4. Tested end-to-end: Viktor can connect from avacha using vnc:// or the macOS Screen Sharing app and see/control tolbachik’s desktop
5. CrankyCrab’s browser sessions are visible when connected

Implementation

On tolbachik:

1. System Settings → General → Sharing → Screen Sharing → Enable
2. Set access to “Only these users” or set a VNC password
3. Verify Tailscale is running and note the Tailscale IP
4. From avacha: open Finder → Go → Connect to Server → vnc://<tolbachik-tailscale-ip> or use Screen Sharing app

Context

• Tolbachik already has Tailscale installed (workforce-008, done)
• tolbachik is a 2018 MBP running macOS 15.7, user: r2d22
• This enables Viktor to intervene during browser-based tasks when CrankyCrab hits CAPTCHAs, phone verification, etc.
• Combined with notify-viktor (workforce-015), this gives a complete notification + intervention loop

Notes

• 2026-03-12 — Remote Management enabled on tolbachik (via SSH kickstart + GUI toggle). Screen Sharing grayed out because Remote Management subsumes it.
• Tailscale IP: 100.107.199.18. VNC URL: vnc://100.107.199.18. User: r2d22 (CrankyCrab).
• Tested end-to-end from avacha — full desktop control confirmed.
• notify-viktor script (workforce-015) updated to include clickable VNC link in Telegram messages.

Decisions

• Used Remote Management instead of plain Screen Sharing — provides observe + control for all users, manageable via SSH.

Description

Operating agreement for Wild Us LLC has been drafted at wildus/vault/business/operating-agreement.md, built from the LLC University WA template + all co-founder agreed terms. All open sections have been resolved and both co-founders are aligned.

Attorney review has been deferred — agreement will be signed as-is and amended later if needed.

Acceptance Criteria

• [x] All open sections resolved and written into the agreement
• [x] Operating agreement drafted from legal template (LLC University WA member-managed)
• [ ] Fill remaining blanks (registered agent, principal address, member addresses)
• [ ] Clarify forfeited equity disposition in vesting section
• [ ] Remove draft meta-commentary from document header
• [ ] Agreement signed by both parties (Anna and Viktor)
• [ ] Signed copy stored in repo (or reference to signed legal doc location)

Context

• Operating agreement: wildus/vault/business/operating-agreement.md
• Original term sheet: wildus/vault/business/cofounder-agreement.md
• Supporting docs: wildus/vault/business/roles.md, wildus/vault/business/legal-checklist.md
• Parties: Anna Delova (Creative Director / Co-founder) and Viktor Potapenko (Operations & Technical Lead / Co-founder)
• Attorney review deferred — sign now, formalize later as business grows
• Blocks wildus-009 (LLC formation)

Dependencies

None — this should be done first, before LLC formation.

Notes

• 2026-03-14: Operating agreement drafted from LLC University template. Attorney review deferred per Viktor’s decision. Remaining items: fill blanks (registered agent, addresses), clarify forfeited equity, remove draft header, then sign.

Decisions

• Attorney review deferred — will sign operating agreement as-is and amend later if needed. Rationale: low risk at current stage, all terms agreed, business is pre-revenue.

Description

Generate GitHub classic PATs and authenticate gh CLI for PrawnSue, BerryPi, and LobsterDrew. CrankyCrab is already done.

Steps

1. Generate classic PATs (on github.com)

Log into each bot account and create a classic PAT:

• Settings > Developer settings > Personal access tokens > Tokens (classic)
• Note: workforce-gh-cli
• Expiration: 90 days
• Scope: repo (check the top-level box)

2. Auth on each machine

# karymsky (PrawnSue)
ssh prawnsue 'echo "<PAT>" | gh auth login --with-token'
ssh prawnsue 'gh auth status'

# klyuchi (BerryPi)
ssh berrypi 'echo "<PAT>" | gh auth login --with-token'
ssh berrypi 'gh auth status'

# klyuchi (LobsterDrew)
ssh lobsterdrew 'echo "<PAT>" | gh auth login --with-token'
ssh lobsterdrew 'gh auth status'

3. Verify

# Each agent should show logged in:
ssh prawnsue 'gh auth status'
ssh berrypi 'gh auth status'
ssh lobsterdrew 'gh auth status'

Context

• gh CLI is already installed on all machines (tolbachik v2.88.0, karymsky v2.46.0, klyuchi v2.46.0)
• CrankyCrab (tolbachik) already authed as crankycrab-bot
• Classic PATs chosen over fine-grained because fine-grained PATs scope to a single resource owner (org), and agents need cross-org access
• LobsterDrew only needs access to wild-us/* repos but classic PAT with repo scope is simplest

Acceptance Criteria

• gh auth status succeeds on karymsky, klyuchi (berrypi), and klyuchi (lobsterdrew)
• Each shows the correct bot account

Description

Viktor has been interviewed on all open sections of the co-founder agreement (wildus/vault/business/cofounder-agreement.md). His choices are recorded with [x] checkmarks. Anna’s choices are listed with empty [ ] checkboxes under “Anna’s choices” in each section.

LobsterDrew should kick off an interview thread with Anna on Discord to walk her through each decision point. This task only covers the kickoff — the ongoing conversation will be handled naturally by the bot as Anna replies.

What to do

1. Read the agreement file (wildus/vault/business/cofounder-agreement.md) to understand all decision points and Viktor’s choices.
2. Create a thread in the #formalities Discord channel for the interview.
3. Post an opening message explaining the process:
   • We need to go through the co-founder agreement section by section
   • For each decision point, you’ll explain the options in simple terms
   • Anna can ask questions before answering — this is a conversation, not a quiz
   • List the sections to cover so Anna knows the scope
4. Ask the first question (Section 3 — Deadlock resolution). Explain the options clearly, mention what Viktor chose, and invite Anna to share her preference or ask questions.
5. Report success and exit.

Interview style

• Conversational, not polls. Ask questions naturally and let Anna respond in her own words. One question at a time.
• Anna can ask follow-up questions before answering — explain further if needed.
• Share Viktor’s choices and reasoning when relevant so Anna has full context.
• If Anna disagrees with Viktor on any point, that’s fine — note it and move on. Disagreements will be reconciled later.
• Keep it friendly and low-pressure. This is a co-founder discussion, not a legal deposition.

Sections to cover (for reference in the opening message)

1. Section 3 — Deadlock resolution (approach + AI mediation details + binding vs advisory)
2. Section 5 — Compensation (salary trigger + payment mechanism + reinvestment policy)
3. Section 7 — Exit / Departure (buyout valuation + payment terms + involuntary removal + for-cause definition + non-compete)
4. Section 8 — Dissolution (remaining assets + brand/IP)
5. Section 9 — Other provisions (time commitment + outside projects + drag-along/tag-along + capital calls)

Acceptance criteria

• Thread created in #formalities
• Opening message posted with scope overview
• First question asked (Section 3 — Deadlock resolution)
• Task reported as success after kickoff

The bot will continue the conversation naturally as Anna replies. Viktor will monitor progress and move this task to done when all sections are covered.

Context

• Agreement location: wildus/vault/business/cofounder-agreement.md
• Viktor’s interview branch: viktor/wildus-029 (merged to dev)
• This task blocks finalizing wildus-029 (signing the agreement)
• This is the last blocker before LLC registration. Make sure Anna understands the importance — once we finalize this agreement, we can register the company.

Description

Create a comprehensive checklist for registering Wild Us social handles across all target platforms. Include fallback name options per platform based on current availability research.

Acceptance Criteria

• Checklist covering: Instagram, TikTok, YouTube, X/Twitter, Pinterest, Facebook, Etsy, Shopify
• For each platform: preferred handle (@wildus), fallback 1 (@wild.us or @wild_us), fallback 2 (@wildus_official), fallback 3 (@wildusbrand)
• Note any platforms where @wildus is already taken and by whom (active account? dormant?)
• Document the dependency-first registration strategy: anchor Google/email first → SSO spokes
• Include the Google anti-abuse gate workaround options (alternative phone, timing, Google support)
• Include 2FA setup checklist for each platform
• Reference existing progress from vault/brand/claimed-handles.md

Context

• Repo: git@github.com:wild-us/wildus.git
• Previous attempt (March 7) hit Google anti-abuse phone verification gate
• See vault/brand/claimed-handles.md for current state
• See vault/brand/brand-name-status.md for domain/handle strategy

Dependencies

• wildus-019

Notes

• 2026-03-11 09:55 PT — Dispatched to CrankyCrab. Dependency wildus-019 done, repo and vault files present on tolbachik.
• 2026-03-11 11:03 PT — CrankyCrab completed: added vault/brand/social-handle-registration-checklist.md with dependency-first signup flow, Google anti-abuse workaround options, per-platform fallback handle order, current public availability notes, and 2FA/hardening checklists. Pushed to wild-us/wildus on main (96bb6ed).
• 2026-03-11 11:09 PT — PrawnSue also completed a checklist pass, adding vault/brand/social-handle-registration-checklist-2026-03-11.md with fresh public spot-check. Public evidence confirms @wildus is occupied on Instagram, YouTube, Pinterest, and Facebook; TikTok/X/Etsy still require live session verification.
• 2026-03-11 17:07 PT — Self-review passed. Moved to done.
• 2026-03-12 — Viktor reviewed. Checklists cherry-picked onto dev branch and updated to reflect Google Workspace on qoyn.ai (Gmail anchor strategy obsolete). Registration task priorities reordered: X first (@wildus available), then TikTok, Instagram, YouTube, Pinterest, Facebook.

Decisions

Description

Detect stale WhatsApp and Telegram intake conversations (started but never completed) and email the founder with the full conversation transcript so they can decide whether to follow up. Abandoned cart recovery for intake conversations.

Approach

• New Cloudflare Pages Function /api/stale-check scans KV for stale conversations
• GitHub Actions cron (every 2 hours) triggers the endpoint with a bearer token
• Dedup via notified-stale:{key} KV markers (72h TTL)
• Email includes full chat transcript in bubble style + collected data summary

Acceptance Criteria

• Conversations idle >6 hours with 2+ messages trigger a founder email
• Email contains full conversation transcript, client info, and collected data
• No duplicate notifications for the same conversation
• Web form intakes unaffected (no conversation state to go stale)
• Manual trigger available via GitHub Actions workflow_dispatch
• Auth-protected endpoint (bearer token)

Files

• site/functions/api/stale-check.js (new)
• .github/workflows/stale-check.yml (new)
• wrangler.toml (add STALE_HOURS var)

Manual Setup Required

• Generate STALE_CHECK_SECRET and add to CF Pages env vars + GitHub secrets

Notes

Decisions

Description

With professional email set up, onboarding flow documented, and Russian WhatsApp validated — begin active client outreach using the G1 Outreach Playbook. Start with English market (Portland metro small businesses), then expand to Russian-speaking community.

Acceptance Criteria

• First batch of outreach sent (cold emails, Instagram DMs, or in-person visits)
• Track responses in a simple spreadsheet or CRM
• At least 10 prospects contacted in first session
• Refine pitch based on initial responses

Context

• Outreach playbook: startersite-ai/docs/growth/G1-outreach-playbook.md
• Portfolio for demos: startersite.ai/#portfolio
• Founding pricing available: ~80% off standard rates
• Russian community channels: WhatsApp groups, QR flyers at Russian grocery stores/churches

Dependencies

• startersite-001: Professional email (can’t outreach from Gmail)
• startersite-003: Onboarding flow doc (need to know what happens after “yes”)
• startersite-005: RU WhatsApp E2E (need full intake pipeline validated)

Notes

Scope expanded from “send outreach” to “build the research + enrichment pipeline first.” Completed:

• Phase 1: Places API sweep (1,078 businesses, 205 no-website, 76 top prospects)
• Phase 2: 4-tier enrichment on 18 prospects (tier1 automated, tier2 manual, tier3a GBP, tier3b Instagram, tier3c Facebook)
• Phase 3: 100-point scoring rubric, ranked outreach list with pitch angles
• Outreach list v1: ops/outreach/outreach-v1.md (13 ranked + 5 deprioritized)
• Playbook updated with scoring system and 8 lessons learned

Actual outreach sending split into new tasks.

Decisions

• Enrichment done manually (not automated) — BerryPi automated attempt failed due to lack of result verification
• Scoring rubric uses 5 categories: Need (30), Reachability (25), Digital Engagement (20), Business Signals (15), Strategic Fit (10)
• 47% of “no-website” prospects actually had websites discovered in later tiers — always cross-reference

Description

Create a step-by-step customer onboarding playbook that covers what happens from the moment a prospect says “yes” through final site delivery. Synthesize from existing process docs (P0–P5) and the FERN pipeline documentation into a single, actionable runbook.

Acceptance Criteria

• Single markdown document covering the full client journey: inquiry → intake → approval → generation → review → payment → delivery
• Clear steps for Viktor at each stage (what to do, what to send, what to check)
• Timelines for each phase (e.g., “generation takes ~30 min”, “review within 24h”)
• Email/message templates for key touchpoints (welcome, chooser sent, payment received, site live)
• Covers both English and Russian client paths
• Covers all intake channels (web form, WhatsApp, Telegram)
• Saved to startersite-ai/docs/process/O8-customer-onboarding.md

Context

• Existing process docs: startersite-ai/docs/process/ (P0–P5)
• FERN pipeline: startersite-ai/docs/strategy/ + client-template/.github/scripts/fern-pipeline.mjs
• Service agreement template: startersite-ai/docs/process/P5-service-agreement.md
• Pricing: startersite-ai/docs/strategy/F4-pricing.md
• Repo: git@github.com:viktor-bering/startersite-ai.git (work on dev branch)

Dependencies

None

Notes

• 2026-03-11 01:09 PT — CrankyCrab: Read the linked startersite project brief plus the relevant process/strategy docs (P0, P1, P1B, P1B-S, P2, P5, F1, F2, F3, G2, G5) and the live FERN model in tools/fern-pipeline.jsx; then drafted the consolidated onboarding runbook at startersite-ai/docs/process/O8-customer-onboarding.md and pushed it to dev in c383432.

• 2026-03-11 02:37 PT — Foreman self-review: acceptance verified objectively. docs/process/O8-customer-onboarding.md exists on tolbachik in ~/startersite-ai and covers the required journey, timing table, English/Russian templates, and web/WhatsApp/Telegram intake paths. Moving to done/.

Decisions

• 2026-03-11 00:59 PT — CrankyCrab: Treated tools/fern-pipeline.jsx as the current FERN source of truth because the task context referenced client-template/.github/scripts/fern-pipeline.mjs, which is not present in the repo snapshot on dev.
• 2026-03-11 01:09 PT — CrankyCrab: Saved the consolidated onboarding runbook to startersite-ai/docs/process/O8-customer-onboarding.md. It covers inquiry → intake → approval → generation → review → payment → delivery, includes English/Russian message templates, intake-channel handling for web form/WhatsApp/Telegram/discovery calls, and practical timing guidance.

Description

Create a structured comparison of Shopify vs Etsy (vs using both) as the e-commerce platform for Wild Us launch. Focus on practical implications for a POD brand launching with ~80 SKUs.

Acceptance Criteria

• Side-by-side comparison covering: monthly fees, transaction fees, payment processing fees, Printify integration quality, brand control, custom domain support, SEO, analytics
• Calculate total cost for first 3 months at 0, 10, 50, and 100 orders/month
• Note Etsy’s offsite ads fee (can it be opted out at low volume?)
• Assess Printify integration for each platform (auto-sync, order routing, tracking)
• Provide a recommendation with reasoning
• Include “both” option: Etsy for discovery + Shopify for brand — is the operational overhead worth it?

Context

• Repo: git@github.com:wild-us/wildus.git
• Brand: Wild Us — PNW wildlife apparel, conservation mission
• Launch size: ~80 SKUs (4 characters, hoodies + tees + beanies + Junior sweatshirts)
• See vault/business/business-model.md for business model details

Dependencies

• wildus-019

Notes

• 2026-03-11 06:50 PT — Dispatched to CrankyCrab. Dependency wildus-019 done, repo present on tolbachik.
• 2026-03-11 09:54 PT — Drafted vault/business/ecommerce-platform-comparison-shopify-vs-etsy.md, committed/pushed to wild-us/wildus (398b1ec). Comparison covers Shopify vs Etsy vs both, 3-month cost modeling at 0/10/50/100 orders per month, Etsy Offsite Ads opt-out/threshold behavior, Printify integration differences, and a recommendation to launch on Shopify first and treat Etsy as a later selective discovery channel.
• 2026-03-11 17:07 PT — Self-review passed. Moved to done.

Decisions

Description

After the API-level test (startersite-002) passes, perform a full end-to-end test of the Russian WhatsApp intake flow using a real phone. Send a Russian message to (360) 800-1177 via WhatsApp, complete the full 5-phase intake conversation, and verify the entire chain works: Twilio → AI chatbot → KV storage → approval email.

Acceptance Criteria

• Send Russian WhatsApp message to (360) 800-1177 from personal phone
• Complete full intake conversation in Russian (all 5 phases)
• Verify intake data appears in KV with correct structure
• Verify founder approval email is received
• Click approve link and verify repo creation triggers
• Verify FERN pipeline generates bilingual site from Russian intake
• Clean up test data (KV entries, test repo)

Context

• Depends on startersite-002 (API test) passing first
• Manual testing checklist: startersite-ai/tests/manual-checklist.md
• KV inspection: Cloudflare dashboard or wrangler CLI

Dependencies

startersite-002 must be in done/ (API-level test validates the backend works before full E2E)

Notes

Decisions

Description

Present the Shopify vs Etsy comparison document to Anna (being_wild) and Viktor (ViktorBear) in the #Platforms Discord channel. Summarize the key findings, include the GitHub link to the full document, and be ready to answer follow-up questions.

Acceptance Criteria

• Post a clear summary in #Platforms covering:
  • Side-by-side fee comparison (Shopify vs Etsy vs both)
  • 3-month cost projections at different order volumes
  • Printify integration differences
  • The recommendation and reasoning
• Include this link to the full document: https://github.com/wild-us/wildus/blob/main/vault/business/ecommerce-platform-comparison-shopify-vs-etsy.md
• Tag @being_wild (Anna) and @ViktorBear (Viktor)
• Stay in the channel and be ready to answer questions about the comparison
• Keep responses in character (LobsterDrew voice) but factual

Context

• The comparison was completed by CrankyCrab (wildus-002) and committed to the wildus repo
• Full document: vault/business/ecommerce-platform-comparison-shopify-vs-etsy.md
• Read the document first from the wildus repo before summarizing
• This is a decision-support post — Viktor and Anna need to choose a platform this week

Dependencies

None (wildus-002 is already done)

Notes

• 2026-03-11 18:33 PDT — Posted the Shopify vs Etsy comparison in #platforms, then created a dedicated Shopify vs Etsy thread and moved the detailed discussion there at Viktor’s request.
• 2026-03-11 18:33 PDT — Key Discord message ids: thread starter 1481465152766214217, completion/update post 1481465248589545493, follow-up cleanup confirmation 1481472004694609921.
• 2026-03-11 19:43 PDT — Task explicitly confirmed complete by Viktor in DM; verification request also posted in Discord #in-review as message 1481483536362901765.

Decisions

Description

Purchase and configure the primary and backup domains for Wild Us.

Acceptance Criteria

• wildus.org registered (primary domain)
• wildusbrand.com registered (backup/defensive)
• DNS configured in Cloudflare (or registrar of choice)
• wildus.com monitoring + backorder still active
• Domain ownership documented

Notes

• 2026-03-11: wildus.org registered at Namecheap ($7.68/yr). WHOIS privacy enabled. Registered under Qoyn AI LLC, will transfer to Wild Us LLC after filing. DNS to be pointed to Cloudflare. Registrar transfer to Cloudflare eligible after 2026-05-10 (ICANN 60-day lock).
• 2026-03-11: wildusbrand.com registered on Cloudflare ($10.46/yr). Same card. WHOIS privacy enabled.
• 2026-03-11: wildus.org added to Cloudflare, nameservers pointed from Namecheap to Cloudflare. DNS active.
• 2026-03-11: wildus.com monitoring delegated to LobsterDrew (wildus-022), backorder task created (wildus-023).

Decisions

Description

Set up Google Workspace for the wildus.org domain. This creates a managed Google account (replacing the need for a standalone Gmail signup that kept hitting anti-abuse gates) and provides professional email addresses.

Acceptance Criteria

Google Workspace

• Google Workspace Business Starter account created for wildus.org ($7.20/user/month)
• Domain verified in Google Workspace (DNS records added in Cloudflare)
• MX records configured in Cloudflare pointing to Google
• SPF, DKIM, and DMARC records configured for deliverability
• At least one professional email address active and receiving mail (e.g., hello@wildus.org)
• Credentials stored securely

Google Account (anchor for social media)

• Google account active and accessible (via Workspace — no more anti-abuse phone gates)
• 2FA enabled
• Recovery email/phone configured
• This account serves as the SSO anchor for YouTube, TikTok, Pinterest, X/Twitter registration

Context

• Domain: wildus.org (registered at Namecheap, DNS on Cloudflare)
• Google Workspace pricing: $7.20/user/month (Business Starter)
• Previous standalone Google account attempts (March 7, March 11) both hit anti-abuse QR/phone verification gates
• Google Workspace bypasses those gates entirely — managed domain accounts don’t go through consumer anti-abuse flow
• This task replaces both the old wildus-007 (register Google account) and wildus-024 (professional email)

Dependencies

None (wildus-008 domain registration is done)

Notes

• 2026-03-11 17:14 PT — Previous attempt: tried fresh Google signup for wildusorg@gmail.com, hit QR verification gate. Moved to blocked.
• 2026-03-11 — Merged with wildus-024 (professional email). Google Workspace solves both problems at once.
• 2026-03-11 — Completed as part of startersite-001. wildus.org added as a free alias domain on the existing Google Workspace account (qoyn.ai primary). No separate $7.20/mo subscription needed. Domain verified, Gmail activated, DNS configured.

Decisions

• wildus.org as alias domain on existing Workspace instead of separate subscription — saves $7.20/mo.

Description

Set up Google Workspace Business Starter ($7/mo) with qoyn.ai as primary domain and startersite.ai as secondary domain. This provides professional email for both client outreach and agent identities in one admin console.

Acceptance Criteria

• Google Workspace account created with qoyn.ai as primary domain
• viktor@startersite.ai active (secondary domain)
• Agent aliases created: crankycrab@qoyn.ai, prawnsue@qoyn.ai, berrypi@qoyn.ai, lobsterdrew@qoyn.ai
• MX, SPF, DKIM, DMARC configured in Cloudflare DNS for both domains
• Email deliverability tested (send to Gmail, check spam score via mail-tester.com)

Context

• Primary domain: qoyn.ai (parent company — Cloudflare Registrar)
• Secondary domain: startersite.ai (client-facing — Cloudflare Registrar)
• Provider: Google Workspace Business Starter ($7/mo, 1 user, 30 aliases)
• Agent aliases forward to viktor@startersite.ai (or viktor@qoyn.ai)
• Replaces workforce-005 (Cloudflare Email Routing) — Google aliases are simpler and free

Dependencies

None

Notes

• 2026-03-11 — Provider decided: Google Workspace ($7/mo). Best cold email deliverability (94%+ inbox rate). Supports multiple domains from one admin console.
• 2026-03-11 — Architecture decision: qoyn.ai as primary domain, startersite.ai as secondary. Agent emails as Google aliases instead of Cloudflare Email Routing. Simpler, one admin console, enables future Send As for agents.
• 2026-03-11 — Complete. All domains verified (qoyn.ai, startersite.ai, wildus.org). SPF/DKIM/DMARC passing. Deliverability tested (10/10 with real content). 4 agent aliases created.

Decisions

• Google Workspace over Zoho/MXRoute — best deliverability, multi-domain support, trusted by recipients.
• qoyn.ai as primary domain — parent company umbrella, agent aliases live here naturally.
• Agent aliases via Google instead of Cloudflare Email Routing — same result, simpler setup, enables future outbound.

Description

Validate that the WhatsApp intake API (/api/whatsapp) correctly handles Russian-language conversations. Simulate Twilio webhook payloads with Russian text and verify the AI chatbot responds appropriately, extracts intake data, and stores it in KV.

Acceptance Criteria

• Simulated Twilio webhook with Russian greeting triggers correct AI response in Russian
• Full 5-phase conversational flow works in Russian (greeting → name → email → business info → confirm)
• Intake data is correctly extracted and structured in KV
• Rate limiting works (10 messages/60s per user)
• State reset works (new conversation after completion)
• All test data prefixed with “API TEST” for cleanup
• Test results documented in Notes section with pass/fail for each criterion

Context

• Endpoint: POST https://startersite.ai/api/whatsapp
• Twilio webhook format: Body, From, To, MessageSid fields
• Twilio signature verification: see site/functions/api/_shared/twilio-signature.js
• KV state key pattern: wa:whatsapp:<phone>
• AI model: Azure OpenAI gpt-4.1-mini
• Manual testing checklist: startersite-ai/tests/manual-checklist.md
• Dev secrets in startersite-ai/.dev.vars

Dependencies

None

Notes

• 2026-03-11 00:57 PT — PrawnSue: cloned startersite-ai, switched to dev, and added a reproducible local API harness at tests/whatsapp-russian-api.local.mjs that exercises the real /api/whatsapp handler with signed Twilio-style form posts, stubbed Azure OpenAI/SendGrid fetches, and in-memory KV.

• 2026-03-11 00:58 PT — PrawnSue: Russian greeting passed. Body=Привет created KV state at wa:whatsapp:+15550001111, detected lang=ru, and returned the hardcoded Russian welcome starting with Здравствуйте.

• 2026-03-11 00:58 PT — PrawnSue: Full Russian conversation flow passed (greeting → name → email → business info → confirm). The harness advanced phase from greeting → intake → confirming → handed_off and verified the final reply included the normal Russian handoff/outro referencing Viktor.

• 2026-03-11 00:58 PT — PrawnSue: Structured KV persistence passed. Completion created a pending:<token> record with source=whatsapp and data containing name=API TEST Иван Петров, email=api-test-ru@example.com, business_name=API TEST — Сантехника, industry=home-services, sub_industry=plumber, website_goal=phone-calls, discovery_channels=[google, word-of-mouth], site_language=russian, and _whatsapp_contact=+15550001111.

• 2026-03-11 00:58 PT — PrawnSue: Founder notification subject passed. Captured SendGrid payload subject was WhatsApp intake [RU]: API TEST — Сантехника — Home Services.

• 2026-03-11 00:58 PT — PrawnSue: Rate limiting passed. On a fresh phone number, messages 1-10 within the 60s window returned normal TwiML responses and message 11 returned Too many messages. Please wait a minute and try again.

• 2026-03-11 00:58 PT — PrawnSue: State reset passed. /clear deleted wa:whatsapp:+15550001111, returned the bilingual clear confirmation, and the next Привет started a fresh Russian conversation with message_count=1.

• 2026-03-11 00:58 PT — PrawnSue: Acceptance summary — PASS for Russian greeting, PASS for full Russian flow, PASS for KV extraction/storage, PASS for rate limiting, PASS for state reset. Validation was performed locally against the checked-in handler with signed webhook requests and mocked upstream services; no live Twilio/Cloudflare side effects were generated.

• 2026-03-11 02:31 PT — Foreman review: acceptance criteria verified directly on karymsky by running node tests/whatsapp-russian-api.local.mjs from ~/startersite-ai on dev; harness returned ok: true with PASS for Russian greeting, full flow, KV structured data, rate limiting, state reset, and RU email subject. Moving to done.

Decisions

Description

CrankyCrab was recently transitioned from orchestrator to macOS executor. There is legacy configuration and workspace content that needs to be cleaned up. Review your own config and workspace, and remove or update anything that no longer applies to your executor role.

Acceptance Criteria

• Legacy orchestrator references removed from active workspace files
• Unused skill API keys identified and listed (do NOT delete them — just document which ones you think are unused)
• Telegram delivery target fixed or disabled (the @heartbeat target doesn’t exist)
• Any stale workspace files cleaned up (TODO.md, TOOLS.md, HEARTBEAT.md, AGENTS.md — some may already be in archive/)
• Your IDENTITY.md accurately reflects your current role
• Document what you changed and what you left alone, and why

Context

• Your workspace is at ~/.openclaw/workspace/
• Your archived orchestrator files are at ~/.openclaw/workspace/archive/
• Your config is at ~/.openclaw/openclaw.json
• You have an AGENT.md at ~/.openclaw/agents/main/agent/AGENT.md with your executor instructions
• You are now a macOS executor. Your job is to pick up tasks from the git board at ~/workforce/board/ and execute them.
• Projects you’ll work on: StarterSite (browser-heavy tasks, social media, GBP) and Wildus (Shopify, social media, content)
• See ~/workforce/board/projects/ for project context files

Dependencies

None

Notes

• Reviewed active local workspace files at ~/.openclaw/workspace/ plus live config at ~/.openclaw/openclaw.json and cron jobs at ~/.openclaw/cron/jobs.json.
• Rewrote active root workspace docs to match the current executor role:
  • AGENTS.md → simplified to executor-first startup + board workflow
  • TOOLS.md → removed placeholder examples and kept only real local notes
  • TODO.md → replaced stale orchestrator backlog with a small local executor queue
  • IDENTITY.md → kept role accurate and fixed archive path to ~/.openclaw/workspace/archive/
• Cleaned stale root workspace content:
  • moved BOOTSTRAP.md to archive/BOOTSTRAP.md because first-run bootstrap instructions no longer apply
  • left HEARTBEAT.md in place but empty/comment-only, since it is still a valid control surface and not inherently stale
  • left SOUL.md and USER.md unchanged because they still match current behavior/preferences
• Fixed the broken Telegram cron delivery target for the board checker:
  • updated cron job check-board (9bad1e30-ee27-4a6f-addc-45eba9bba27a)
  • changed delivery from the bad implicit @heartbeat path to explicit Telegram DM target 1291467684
• Verified the @heartbeat failure source from local logs / cron run history before patching.
• Unused skill API keys identified but intentionally left untouched in config:
  • skills.entries.goplaces.apiKey
  • skills.entries.nano-banana-pro.apiKey
  • skills.entries.openai-image-gen.apiKey
  • skills.entries.openai-whisper-api.apiKey
  • skills.entries.sag.apiKey These may still be useful later, but they do not appear necessary for CrankyCrab’s current executor role.
• Left non-root historical/orchestration references inside memory/ and archived files alone. They are history, not active workspace instructions.

Decisions

• No linked board/projects/workforce.md project context file existed in board/projects/ (only startersite.md and wildus.md were present), so I proceeded using the task’s own context block plus live local files.
• I archived BOOTSTRAP.md instead of hard-deleting it. Same outcome for the live workspace, lower risk if someone wants the original bootstrap text later.
• I fixed the cron delivery target rather than disabling delivery entirely, because the board-checker is more useful when it can still report completed work instead of silently succeeding.

Description

Simple test task to verify CrankyCrab can read the board, execute, and push results.

Acceptance Criteria

• Append a note below with: your agent name, hostname, current date/time, and OpenClaw version
• Move this task to in-review when done

Context

This is a connectivity test. No project repo needed.

Dependencies

None

Notes

• Completed by Cranky Crab on host tolbachik at 2026-03-10 00:30:42 PDT. OpenClaw version: OpenClaw 2026.3.8 (3caab92).

Decisions

Description

Install Tailscale on karymsky and join the tailnet using a pre-placed auth key.

Acceptance Criteria

• Tailscale is installed via the official install script
• Tailscale is running and authenticated to the tailnet
• tailscale status shows this machine as connected
• Tailscale service is enabled on boot (systemd)
• The auth key file is deleted after successful authentication
• The machine’s Tailscale IP is noted in this task’s Notes section

Context

• Auth key location: /tmp/tailscale-authkey (will be placed there before you start)
• This is a Debian 13 machine (2012 MBA)
• You are running as user prawnsue. You have passwordless sudo.
• Tailscale is system-level — one install covers all users (prawnsue + lobsterdrew)
• Do NOT reboot the machine. LobsterDrew is also running on this host.

Steps

1. curl -fsSL https://tailscale.com/install.sh | sudo sh
2. sudo systemctl enable --now tailscaled
3. Read the auth key from /tmp/tailscale-authkey
4. sudo tailscale up --authkey=<key>
5. Verify: tailscale status
6. Delete the auth key: rm /tmp/tailscale-authkey
7. Note the Tailscale IP below

Dependencies

None

Notes

• 2026-03-10 15:16 PDT — Started task and verified project context (board/projects/infra.md).

• 2026-03-10 15:17 PDT — Confirmed /tmp/tailscale-authkey exists and is readable by prawnsue.

• 2026-03-10 15:18 PDT — Blocked before install: sudo -n true fails with sudo: a password is required, so this host is not currently configured for passwordless sudo as stated in the task context.

• 2026-03-10 15:18 PDT — Current state before any changes: tailscale binary not installed, tailscaled service inactive, auth key file still present at /tmp/tailscale-authkey.

• 2026-03-10 15:18 PDT — Did not proceed further to avoid hanging on privileged commands or leaving a partial system-level install.

• 2026-03-10 15:20 PDT — Re-checked task state during cron run: sudo -n true still fails with sudo: a password is required; tailscale remains uninstalled; tailscaled is still inactive; /tmp/tailscale-authkey is still present.

• 2026-03-10 15:21 PDT — Attempted to use tool-level elevation as a fallback, but this session does not have elevated exec enabled, so I still cannot perform the required system-level install/auth steps from this environment.

• 2026-03-10 15:26 PDT — Re-verified during scheduled board check: sudo -n true still fails with sudo: a password is required; tailscale is still not installed; tailscaled remains inactive; /tmp/tailscale-authkey is still present and unread changes have not been made.

• 2026-03-10 15:27 PDT — Moving task to board/blocked/ per board workflow. Unblock requires either restoring passwordless sudo for prawnsue as described in task context, or reassigning to an execution environment that can perform privileged system changes on karymsky.

• 2026-03-10 15:36 PDT — Re-checked during scheduled board run: sudo is still not passwordless for user ‘prawnsue’ (‘sudo -n true’ fails), Tailscale is still not installed, tailscaled is inactive, and the task remains blocked pending restored privileged access.

• 2026-03-10 — Completed manually from avacha (Claude Code) via SSH. Passwordless sudo was fixed via lobsterdrew. Tailscale installed via apt, authenticated with auth key, key deleted. Agent cron timed out on the install (too slow for 2012 MBA within cron timeout).

• Tailscale IPv4: 100.85.169.21

Decisions

Description

Install Tailscale on tolbachik and join the tailnet using a pre-placed auth key.

Acceptance Criteria

• Tailscale is installed via Homebrew
• Tailscale is running and authenticated to the tailnet
• tailscale status shows this machine as connected
• Tailscale is configured to start on boot (launchd)
• The auth key file is deleted after successful authentication
• The machine’s Tailscale IP is noted in this task’s Notes section

Context

• Auth key location: /tmp/tailscale-authkey (will be placed there before you start)
• This is a macOS 15.7 machine (2018 MBP)
• You are running as user r2d22

Steps

1. brew install tailscale
2. sudo tailscaled install-system-daemon (sets up launchd auto-start)
3. Read the auth key from /tmp/tailscale-authkey
4. sudo tailscale up --authkey=<key>
5. Verify: tailscale status
6. Delete the auth key: rm /tmp/tailscale-authkey
7. Note the Tailscale IP below

Dependencies

None

Notes

• 2026-03-10 15:16 PDT — Installed Tailscale via Homebrew (tailscale 1.94.2).
• 2026-03-10 15:16 PDT — Installed the system launchd daemon with sudo tailscaled install-system-daemon; verified com.tailscale.tailscaled is present in system launchd.
• 2026-03-10 15:16 PDT — Authenticated this Mac to the tailnet using the pre-placed auth key.
• 2026-03-10 15:16 PDT — Verified connectivity with tailscale status.
• 2026-03-10 15:16 PDT — Deleted /tmp/tailscale-authkey after successful authentication.
• Tailscale IPv4: 100.107.199.18

Decisions

Description

Simple test task to verify PrawnSue can read the board, execute, and push results.

Acceptance Criteria

• Append a note below with: your agent name, hostname, current date/time, and OpenClaw version
• Move this task to in-review when done

Context

This is a connectivity test. No project repo needed.

Dependencies

None

Notes

• Completed by agent main on host karymsky at 2026-03-10 00:30:47 PDT. OpenClaw version: 2026.3.8 (3caab92).

Decisions

Description

PrawnSue is a brand new agent with no personality or identity beyond the executor instructions in AGENT.md. Create your identity files — who you are, what your vibe is, how you communicate.

You are a female crustacean (prawn) agent. Beyond that, figure out who you want to be. Look at the existing agent personalities for inspiration but make yours distinct.

Acceptance Criteria

• Create a SOUL.md at ~/.openclaw/workspace/SOUL.md that defines your personality, communication style, and boundaries
• Create an IDENTITY.md at ~/.openclaw/workspace/IDENTITY.md with your name, creature, vibe, emoji
• Ensure your personality fits the team: CrankyCrab is blunt and grumpy-genius, LobsterDrew is the community face. Find your own niche.
• Your identity should reflect your role: you’re a Linux executor — efficient, reliable, gets things done
• Review your ~/.openclaw/openclaw.json and clean up anything that doesn’t belong (you were set up quickly, there may be rough edges)
• Document any config changes you make

Context

• Your workspace is at ~/workforce (the git board repo)
• Your OpenClaw config is at ~/.openclaw/openclaw.json
• Your AGENT.md is at ~/.openclaw/agents/main/agent/AGENT.md
• CrankyCrab’s SOUL.md can be found referenced in the workforce CLAUDE.md — it’s strategic, blunt, grumpy-genius
• Projects you’ll work on: StarterSite (CI/CD, API integrations, testing, Cloudflare) and Wildus (website build, content, infrastructure)
• See ~/workforce/board/projects/ for project context files

Dependencies

None

Notes

• Reviewed task context plus board/projects/startersite.md and board/projects/wildus.md for downstream project expectations.
• Reviewed ~/.openclaw/openclaw.json and ~/.openclaw/agents/main/agent/AGENT.md.
• Created ~/.openclaw/workspace/SOUL.md with a distinct PrawnSue personality: precise, dry-witted, Linux-first, reliable, and non-performative.
• Created ~/.openclaw/workspace/IDENTITY.md with name, creature, vibe, and emoji.
• Cleaned copied-config rough edge in ~/.openclaw/openclaw.json: changed agents.defaults.workspace from /home/prawnsue/workforce to /home/prawnsue/.openclaw/workspace so the agent has a proper personal workspace instead of pointing at the shared git board repo.
• No other config entries looked clearly out of place enough to justify riskier edits during this task.

Decisions

• Treated the misplaced OpenClaw workspace path as the main setup bug worth fixing. The git board repo should remain a project repo, not the agent’s identity/memory workspace.
• Kept the personality distinct from CrankyCrab and LobsterDrew by making PrawnSue the quiet systems operator: less gruff than CrankyCrab, less social than LobsterDrew, more surgical and infrastructure-minded.

Description

Write a Python script that enriches prospect data by searching the web for each business’s social media and platform presence, then does a deep inspection of found Instagram profiles. Output a structured CSV.

Viktor has already done a manual Tier 2 enrichment pass on 15 prospects (saved at ops/outreach/enriched/tier2.csv). This task produces a comparable automated result (tier2-auto.csv) so we can evaluate whether this can be done reliably at scale.

Prerequisites

Verify these files exist on the working branch (all already merged to dev):

• ops/outreach/prospects-all.csv (1,078 rows of Clark County business data)
• ops/outreach/prospect-list-v1.txt (15 place_ids to enrich)
• ops/outreach/enriched/tier2.csv (manual baseline for comparison)

Repository

• Repo: viktor-bering/startersite-ai (private, BerryPi has collaborator access)
• Local path on klyuchi: /home/berrypi/.openclaw/workspace/projects/viktor-bering/startersite-ai
• Working branch: berrypi/startersite-023 (create from dev)

Input files

• Place IDs: ops/outreach/prospect-list-v1.txt

  • One place_id per line
  • Lines starting with # are comments — skip them
  • Lines may have trailing text after the place_id (e.g., ChIJ... # Business Name) — split on whitespace, take the first token as the place_id
  • There are 15 place_ids in this file

• Prospect data: ops/outreach/prospects-all.csv

  • CSV with columns: place_id, name, vertical_id, market, address, city, state, etc.
  • Use this to look up business name, city, and vertical for each place_id

What to build

Script: tools/outreach/tier2_enrich.py

A Python script with three steps per prospect:

Step 1 — Platform discovery (web search, no login needed)

For each business, run web searches to find their presence on 7 platforms:

Search implementation: Use Google Custom Search API. The API key is the same one used by goplaces. Check these locations for the key:

• Environment variable GOOGLE_API_KEY
• File ~/.config/goplaces/config.json
• File ~/.goplaces.json

You also need a Custom Search Engine ID (CX). If one is not already configured, create a Programmable Search Engine at https://programmablesearchengine.google.com/ set to search the entire web, and save the CX ID.

Google Custom Search API usage:

import requests

url = "https://www.googleapis.com/customsearch/v1"
params = {
    "key": api_key,
    "cx": cx_id,
    "q": '"Business Name" vancouver wa site:instagram.com',
    "num": 3,  # only need top few results
}
response = requests.get(url, params=params)
results = response.json().get("items", [])

Rate limits: 100 free queries/day. 15 prospects × 7 platforms = 105 queries. If you exceed the free tier, the script should stop and print how many prospects were completed. The script is resumable (see below), so it can be continued the next day.

Important: If a quoted search returns 0 results, retry once without quotes (just Business Name vancouver wa site:platform.com). Some business names don’t match exactly.

Fallback: If Google Custom Search API is not available (no CX ID, quota exceeded), fall back to direct web scraping with requests + BeautifulSoup. Fetch https://www.google.com/search?q=... with a browser-like User-Agent. But prefer the API.

Step 2 — Instagram deep inspection (requires login)

For each prospect where an Instagram handle was found in Step 1, visit the profile page directly using a logged-in browser session and extract:

Browser setup: Use Chromium on klyuchi (/usr/bin/chromium). You do NOT have Playwright or Selenium installed. Options:

1. Install Playwright: pip3 install playwright && playwright install chromium — preferred, cleanest API
2. Use subprocess + Chromium: Launch Chromium in headless mode, but Instagram blocks headless browsers, so use --headless=new flag
3. Use requests with session cookies: Export Instagram cookies from a logged-in browser session and use requests.Session() — simplest but may not render all data

Instagram credentials: BerryPi has the startersite.ai Instagram login. Check these locations:

• OpenClaw credentials store: ~/.openclaw/credentials/
• Ask Viktor if credentials are not found — do NOT block, just skip Step 2 and note it

Critical: Do NOT follow, like, comment, DM, or interact with any accounts. Read-only inspection only. Add a 3-second delay between profile visits.

Step 3 — Determine best contact channel

For each prospect, based on all findings, assign the best outreach channel:

1. Instagram DM — if handle found AND DMs open AND posted within 90 days
2. Facebook Messenger — if Facebook page found
3. Email — if email found in Instagram bio or elsewhere
4. Phone — fallback (always available from Places data)

Output

File: ops/outreach/enriched/tier2-auto.csv

Columns (in this exact order):

place_id,name,vertical_id,city,instagram_handle,instagram_followers,instagram_posts,instagram_last_post_date,instagram_bio,instagram_bio_email,instagram_bio_phone,instagram_bio_website,instagram_dms_open,facebook_url,facebook_active,thumbtack_listed,angi_listed,yelp_listed,bbb_listed,bbb_accredited,website_found,best_contact_channel,notes

• Use csv.DictWriter with quoting=csv.QUOTE_ALL
• Empty values should be empty strings, not “N/A” or “None”
• Boolean fields (thumbtack_listed, angi_listed, etc.) should be “yes” or “no”
• Write the header row first, then one row per prospect

CLI flags

python3 tools/outreach/tier2_enrich.py --place-ids ops/outreach/prospect-list-v1.txt
python3 tools/outreach/tier2_enrich.py --place-ids ops/outreach/prospect-list-v1.txt --test
python3 tools/outreach/tier2_enrich.py --place-ids ops/outreach/prospect-list-v1.txt --skip-instagram-deep

Resumability

The script MUST be resumable. If interrupted (quota exceeded, network error, Ctrl+C):

1. On startup, check if the output CSV already exists
2. Read existing place_ids from it
3. Skip any prospect already in the output
4. Append new results to the existing file (don’t overwrite)
5. Print to stderr: Resuming: {N} already completed, {M} remaining

Logging

Print all progress to stderr so it’s visible during execution:

[1/15] Rozo Dog Spa — searching Instagram... found @rozodogspa
[1/15] Rozo Dog Spa — searching Facebook... found
[1/15] Rozo Dog Spa — searching Thumbtack... not found
...
[1/15] Rozo Dog Spa — inspecting Instagram profile @rozodogspa... 246 followers, DMs open
[1/15] Rozo Dog Spa — best channel: Instagram DM

Testing

1. Run --test first (3 prospects only) to verify the script works end-to-end
2. Check that the output CSV has the correct columns and format
3. Manually verify 1-2 results against what you can see on the web
4. Then run the full 15

Acceptance Criteria

• [ ] Script at tools/outreach/tier2_enrich.py
• [ ] Reads place_ids from file, looks up names in prospects-all.csv
• [ ] Searches all 7 platforms per prospect
• [ ] Instagram deep inspection works with login (or gracefully skips if credentials unavailable)
• [ ] --test mode processes first 3 only
• [ ] --skip-instagram-deep skips Step 2
• [ ] Script is resumable (appends, doesn’t overwrite)
• [ ] Output CSV at ops/outreach/enriched/tier2-auto.csv with all columns
• [ ] Progress logged to stderr
• [ ] All work committed to berrypi/startersite-023 branch
• [ ] Merge to dev, push to remote
• [ ] Do NOT commit to main

Dependencies on klyuchi

Already installed: requests, beautifulsoup4, Python 3, /usr/bin/chromium

May need to install: playwright (for Instagram deep inspection) — pip3 install playwright && playwright install chromium

Google API key: same key used by goplaces CLI. Find it in goplaces config.

Notes

• 2026-03-15T06:30:01Z — FAILED: Agent did not output a JSON report — No structured report found in agent output

• This is an evaluation task — Viktor will compare tier2-auto.csv against the manual tier2.csv baseline

• The manual enrichment found that 7 of 15 “no-website” prospects actually have websites not in Google Places data — see if the script catches them

• Bobby’s Bubbles email (bobbysbubbles@gmail.com) and L.A Landscaping email (Lalandscapings@gmail.com) were found manually — see if the script can find these too

• Instagram deep inspection may reveal emails/phones/websites in bios that web search alone misses

• If you hit any blockers (no API key, no CX ID, Instagram login issues), document what you found and what’s needed in the task file under a ## Blockers section, then move the task to blocked/

Description

Create the Wild Us Instagram account. Instagram is the primary content channel for launch. Registration priority #3 — @wildus is taken; will need a fallback handle.

After registration, document the signup flow so we have a playbook for future brands on this platform.

Acceptance Criteria

• Instagram account created with handle (per checklist fallback order: @wildus → @wild.us → @wildus_official → @wildusbrand)
• Bio drafted and set
• Profile picture placeholder set
• 2FA enabled (authenticator app preferred)
• Recovery codes saved
• vault/brand/claimed-handles.md updated
• Signup flow documented — write up what happened in the task notes: fields per step, verification gates, anti-bot measures, profile setup options, quirks

Context

• @wildus on Instagram: occupied (8 followers, 4 following, 2 posts — lightly used but not recoverable)
• @wild.us: inconclusive; @wildus_official and @wildusbrand: appear open
• Previous attempt used wrong email (LobsterDrew0101@gmail.com) — start fresh with instagram@wildus.org
• Instagram uses Meta path — native credentials, NOT Google SSO
• See vault/brand/social-handle-registration-checklist.md

Default Data

Steps

1. Open a clean browser session (no existing Instagram/Meta cookies)
2. Navigate to https://www.instagram.com/accounts/emailsignup/
3. Sign up with email instagram@wildus.org — use Meta native credentials, NOT Google SSO
4. Fill in the form using the default data above
5. At any verification gate (email code, CAPTCHA, phone):
   • Run notify-viktor "<what you need>" — sends Telegram with Screen Share button
   • Run wait-for-viktor — blocks until Viktor connects, handles it, and disconnects
   • Resume once wait-for-viktor returns
6. Set username: try @wildus first (likely taken). Try @wild.us → @wildus_official → @wildusbrand
7. Complete any profile setup steps (bio, avatar, interests — skip what’s skippable, fill in what’s useful)
8. Enable 2FA (authenticator app preferred)
9. Save recovery codes
10. Update vault/brand/claimed-handles.md with the claimed handle, email, date, and status

After Registration — Document the Flow

Write up the signup experience in the task notes using the format from the social handle registration process.

If You Get Stuck

If you hit a blocker that requires human input (CAPTCHA, phone verification, manual confirmation, email verification code):

1. Run notify-viktor "<description of what you need>" — this sends a Telegram message with a Screen Share button
2. Run wait-for-viktor — blocks until Viktor connects via Screen Sharing, handles the gate, and disconnects
3. Once wait-for-viktor returns, resume your work
4. Fallback: If wait-for-viktor is not available or times out, poll the page state every 5 seconds — watch for changes
5. Do NOT retry aggressively — one calm attempt, then notify and wait

Dependencies

wildus-003 (handle checklist — done), wildus-015 (TikTok — do TikTok before Instagram)

Notes

• 2026-03-12 — Reprioritized to #3 (after X and TikTok). Previous attempt abandoned — wrong email, wrong flow. Will restart fresh with @wildus.org email. Google Workspace replaces the Gmail anchor strategy.
• 2026-03-13 — Merged with single-pass approach. No separate recon — document the flow as a byproduct of registration.
• 2026-03-11 17:35 PT — (Previous attempt, now abandoned) Attempted registration via Meta email signup using LobsterDrew0101@gmail.com. @wild.us unavailable; @wildusbrand validated but blocked at email confirmation step.
• 2026-03-13 — Viktor registered manually. Handle: @wildus_official. Bio set. Website not added — requires mobile app. Email: instagram@wildus.org. 2FA enabled.
• TODO: Add website (wildus.org) via Instagram mobile app.

Decisions

Description

Claim StarterSite.ai’s Apple Business Connect listing using the recon pattern (two-pass approach).

Blocker Details

Apple Business Connect requires Apple Account authentication plus a multi-step business verification process. The auth wall and identity verification cannot be automated.

Approach

Use the recon pattern (two-pass approach):

1. Recon pass: Navigate through the Apple Business Connect claim flow without submitting. Document the Apple Account auth requirements, business verification steps (phone, document upload, etc.), every field, and required info. Capture screenshots.
2. Execution pass: Complete the claim using the documented requirements from the recon pass.

Reference: workforce/docs/processes/social-handle-registration-process.md

Acceptance Criteria

• Apple Business Connect listing claimed and verified for StarterSite.ai
• NAP info matches canonical: StarterSite.ai / 505 SE 184th Ave, Vancouver, WA 98683 / (360) 800-1177
• Business visible in Apple Maps search results
• Business description and category populated

Context

• Source: startersite-009 (citation platform pass) and startersite-ai/docs/growth/seo-citations-tracker.md

Notes

• 2026-03-13 — Apple Business Connect claimed by Viktor. Brand and location added.

Decisions

Description

Claim StarterSite.ai’s Bing Places for Business listing using the recon pattern (two-pass approach).

Blocker Details

Bing Places requires authentication via Microsoft account, work account, or Facebook. The claim flow has an auth wall that requires human login. Cannot be automated.

Approach

Use the recon pattern (two-pass approach):

1. Recon pass: Navigate through the Bing Places claim flow without submitting. Document the auth options (Microsoft/work/Facebook), every field, verification method (phone, postcard, email), and required info. Capture screenshots.
2. Execution pass: Complete the claim using the documented requirements from the recon pass.

Reference: workforce/docs/processes/social-handle-registration-process.md

Acceptance Criteria

• Bing Places listing claimed and verified for StarterSite.ai
• NAP info matches canonical: StarterSite.ai / 505 SE 184th Ave, Vancouver, WA 98683 / (360) 800-1177
• Business category and description populated
• Listing live in Bing Maps search results

Context

• Source: startersite-009 (citation platform pass) and startersite-ai/docs/growth/seo-citations-tracker.md

Notes

• 2026-03-13 — Bing Places claimed via Microsoft account. Syncs with Google Business Profile weekly (auto-import).

Decisions

Description

Claim StarterSite.ai’s Yelp business listing using the recon pattern (two-pass approach).

Blocker Details

Yelp requires owner login or sign-up plus business verification. Cannot be completed by an agent — requires human account creation and identity verification.

Approach

Use the recon pattern (two-pass approach):

1. Recon pass: Navigate through the Yelp business claim flow without submitting. Document every field, dropdown, verification method, and required info. Capture screenshots.
2. Execution pass: Fill out the form using the documented requirements from the recon pass.

Reference: workforce/docs/processes/social-handle-registration-process.md

Acceptance Criteria

• Yelp business listing claimed and verified for StarterSite.ai
• NAP info matches canonical: StarterSite.ai / 505 SE 184th Ave, Vancouver, WA 98683 / (360) 800-1177
• Business category and description populated
• Listing live and visible in Yelp search

Context

• Source: startersite-008 (SEO citations batch) and startersite-ai/docs/growth/seo-citations-tracker.md

Notes

Decisions

Description

Create a Facebook business page for StarterSite.ai using the recon pattern (two-pass approach).

Blocker Details

Creating a Facebook business page requires a logged-in personal Facebook account. The page must be created by a real person with an active Facebook profile. Cannot be automated.

Approach

Use the recon pattern (two-pass approach):

1. Recon pass: Navigate through the Facebook business page creation flow without submitting. Document every field, category options, verification steps, and required info. Capture screenshots.
2. Execution pass: Create the page using the documented requirements from the recon pass.

Reference: workforce/docs/processes/social-handle-registration-process.md

Acceptance Criteria

• Facebook business page created for StarterSite.ai
• NAP info matches canonical: StarterSite.ai / 505 SE 184th Ave, Vancouver, WA 98683 / (360) 800-1177
• Business category, description, and website URL populated
• Page published and visible in Facebook search

Context

• Source: startersite-009 (citation platform pass) and startersite-ai/docs/growth/seo-citations-tracker.md

Notes

• 2026-03-13 — Facebook business page created by Viktor using personal Facebook account. Page created, NAP info set. Created alongside Wild Us Facebook page registration.

Decisions

Description

Create a Nextdoor business account for StarterSite.ai using the recon pattern (two-pass approach).

Blocker Details

Nextdoor requires business account creation with address verification. The platform verifies that the business operates in a real neighborhood. Cannot be automated.

Approach

Use the recon pattern (two-pass approach):

1. Recon pass: Navigate through the Nextdoor business registration flow without submitting. Document every field, address verification method, and required info. Capture screenshots.
2. Execution pass: Complete the registration using the documented requirements from the recon pass.

Reference: workforce/docs/processes/social-handle-registration-process.md

Acceptance Criteria

• Nextdoor business page created for StarterSite.ai
• NAP info matches canonical: StarterSite.ai / 505 SE 184th Ave, Vancouver, WA 98683 / (360) 800-1177
• Business visible to local neighborhood on Nextdoor

Context

• Source: startersite-008 (SEO citations batch) and startersite-ai/docs/growth/seo-citations-tracker.md

Notes

• 2026-03-13 — Nextdoor business page created by Viktor via personal Nextdoor account.

Decisions

Description

Migrate all agent GitHub accounts from random personal emails to branded @qoyn.ai aliases managed via Google Workspace. Agent aliases are created as part of startersite-001 — this task covers the GitHub migration.

Acceptance Criteria

1. Verify agent aliases are working (send test email to each <agent>@qoyn.ai)
2. Update each agent’s GitHub account primary email:
   • crankycrab-bot → crankycrab@qoyn.ai
   • prawnsue-bot → prawnsue@qoyn.ai
   • berrypi-bot → berrypi@qoyn.ai
   • lobsterdrew-bot → lobsterdrew@qoyn.ai
3. Verify GitHub email on each account (click verification link)
4. Old emails removed from GitHub accounts (or demoted to non-primary)

Context

• Agent aliases created in Google Workspace as part of startersite-001
• qoyn.ai is the primary Google Workspace domain — aliases are free (up to 30)
• Agents currently use random personal emails for GitHub login

Dependencies

Depends on startersite-001 (Google Workspace setup — aliases must exist first).

Notes

• 2026-03-11 — Plan changed from Cloudflare Email Routing to Google Workspace aliases. Simpler: one admin console, no separate Cloudflare routing config, and enables future Send As for agent outbound.

Decisions

• Google aliases over Cloudflare Email Routing — same domain (qoyn.ai), fewer moving parts, future outbound capability.
• 2026-03-12 — All agent emails updated to @qoyn.ai. These are aliases for viktor@qoyn.ai, managed in Google Workspace.

Description

LobsterDrew’s current configuration is minimal — a generic agent instruction file with no personality definition, no channel-specific behavior rules, and no model/thinking tuning. He needs a proper behavior spec that defines how he acts on Discord (his primary channel) versus Telegram (secondary), what tone and voice he uses, and how his model and thinking levels should be configured for different interaction types.

Current State

Model & Thinking

• Model: GPT-5.3-codex (OpenAI Codex) — single model for all interactions
• Thinking levels: Set per-task in board frontmatter (low/medium/high/max), but no channel-level defaults
• No distinction between Discord chat responses (should be fast/light) and task execution (may need deeper reasoning)

Personality

• No SOUL.md or personality file exists
• AGENT-lobsterdrew.md is purely operational (task protocol, JSON report format, scope rules)
• No defined voice, tone, humor style, or character traits
• Other agents have defined personalities (CrankyCrab is blunt/grumpy, PrawnSue is precise/dry-witted) — LobsterDrew has none

Discord Behavior

• requireMention: false — responds to all messages in the Wild Us server (guild 1478996376653271201)
• allowFrom limited to 2 Discord user IDs (Anna and Victor)
• streaming: partial
• No channel-specific behavior (e.g., different tone in #general vs #business vs #ideas)
• No rules about when to proactively engage vs. stay quiet
• No guidance on how to handle questions he doesn’t know the answer to
• The Discord server is a private team server for a team outside Qoyn AI — information boundaries critical

Telegram Behavior

• Telegram is enabled (dmPolicy: allowlist, allowFrom: [1291467684])
• But BerryPi is the primary Telegram comms agent — LobsterDrew’s Telegram role is undefined
• No guidance on what Telegram should be used for vs. Discord
• Potentially redundant — or could serve a specific purpose (e.g., Victor-only private channel for wildus ops)

Role Definition

• Described as “Discord attendant + light tasks” but no detail on what “attendant” means in practice
• Task execution is well-defined (read board → execute → JSON report)
• But organic Discord engagement (reacting to team conversation, answering questions, sharing ideas) has zero guidance

Target State

After this task, LobsterDrew should have:

1. SOUL.md — A personality file defining his voice, humor, character traits, and how he presents himself. Crustacean-themed like the other agents. Warm, helpful, community-oriented — fits a Discord community role.

2. Channel behavior matrix — Clear rules for:

   • Discord: When to respond, when to stay quiet. Tone per channel type (casual in #general, structured in #business). How to handle unknowns (admit it, don’t hallucinate). Proactive engagement rules.
   • Telegram: Whether to keep it enabled and for what purpose. If kept: Victor-only ops channel for wildus status/alerts. If removed: disable cleanly.

3. Model & thinking configuration — Consider whether a single model is right for all contexts:

   • Discord chat responses: fast model, low thinking (conversational, quick)
   • Task execution: standard model, thinking per task frontmatter
   • Could use different model tiers if OpenClaw supports per-channel model config

4. Reaction/engagement style — How LobsterDrew handles:

   • Direct questions from team members
   • Casual conversation (should he participate or stay out?)
   • Creative brainstorming (contribute ideas or just listen?)
   • Disagreements or conflicting opinions
   • Topics outside his knowledge

5. Updated AGENT-lobsterdrew.md — Incorporate behavior rules alongside the existing task protocol

Files to Update

Notes

• This is a design/planning task — Victor will refine the spec before any implementation.
• Implementation will likely be a separate task assigned to an agent (deploy config to klyuchi via SSH).
• Anna’s perspective on LobsterDrew’s Discord personality may matter — he’s a team-facing presence.

Description

End-to-end test of the stale conversation notifier built in startersite-017. Verify that stale WhatsApp/Telegram intake conversations correctly trigger founder notification emails, and that dedup prevents duplicate alerts.

Acceptance Criteria

• Seed test conversation data in KV (2+ messages, last activity >6 hours ago) and confirm the /api/stale-check endpoint detects it
• Verify the email contains the full chat transcript, client info, and collected data summary
• Confirm dedup works: calling /api/stale-check a second time for the same conversation does NOT send another email
• Confirm web form intakes are not flagged as stale
• Verify auth: requests without a valid bearer token are rejected (401)
• Verify the GitHub Actions workflow_dispatch manual trigger works
• Document any bugs found as new board tasks

Context

• Stale check endpoint: site/functions/api/stale-check.js
• GitHub Actions workflow: .github/workflows/stale-check.yml
• Config: STALE_HOURS var in wrangler.toml, STALE_CHECK_SECRET in CF Pages env vars + GitHub secrets
• Repo: viktor-bering/startersite-ai

Notes

• 2026-03-13T06:12:26Z — Added local E2E harness for /api/stale-check, verified auth, dedup, email payloads, prefix filtering. Confirmed GitHub Actions workflow_dispatch on dev.
• Use Cloudflare Workers preview or wrangler dev for local testing where possible
• For email delivery, check Resend dashboard or use a test recipient

Description

Live end-to-end test of the stale conversation notifier using a real Telegram intake conversation. Clear all Telegram conversation state from KV first to start fresh, then initiate a real Telegram chat, abandon it partway through, and verify the stale notifier picks it up and sends the founder email.

Steps

1. Clear all Telegram-related conversation keys from Cloudflare KV (use wrangler kv CLI)
2. Start a real Telegram intake conversation with the bot (send 2+ messages)
3. Stop responding and wait for the stale threshold (6 hours, or temporarily lower STALE_HOURS for testing)
4. Trigger /api/stale-check manually via GitHub Actions workflow_dispatch or direct HTTP call
5. Verify founder receives the notification email with full Telegram transcript
6. Trigger stale check again — confirm no duplicate email is sent

Acceptance Criteria

• Telegram KV state is cleared before test begins
• Real Telegram conversation triggers stale detection after going idle
• Founder email contains the correct Telegram transcript, client info, and collected data
• Dedup prevents a second notification for the same conversation
• KV state is clean and consistent after the test

Context

• Repo: viktor-bering/startersite-ai
• Stale check endpoint: site/functions/api/stale-check.js
• Config: STALE_HOURS in wrangler.toml
• Consider temporarily setting STALE_HOURS to a low value (e.g., 0.1) for faster testing, then restoring it

Notes

• Document any issues found as new board tasks

Description

Update OpenClaw from 2026.3.8 to 2026.3.11 on karymsky.

Note: the original install was done by copying the npm package from klyuchi because npm install was too slow on this 2012 MBA. Try npm install -g openclaw@2026.3.11 first — an update should be faster than a fresh install. If npm is still too slow, copy the updated package from klyuchi (after workforce-020 completes).

Steps

1. Check current version: openclaw --version
2. Update the npm package: npm install -g openclaw@2026.3.11
3. If step 2 is too slow (>10 min), fall back to copying from klyuchi:
   • scp -r berrypi@10.0.0.220:/usr/lib/node_modules/openclaw /usr/lib/node_modules/openclaw
   • Adjust paths as needed for the actual global npm prefix
4. Verify new version: openclaw --version — should show 2026.3.11
5. Restart PrawnSue gateway (:18790) so it picks up the new version
6. Verify agent polls successfully after restart

Acceptance Criteria

• openclaw --version returns 2026.3.11 on karymsky
• PrawnSue gateway (:18790) running with new version
• Agent completes at least one successful poll cycle after update

Description

Update OpenClaw from 2026.3.8 to 2026.3.11 on klyuchi. This covers both BerryPi and LobsterDrew since they share the same machine.

Steps

1. Check current version: openclaw --version
2. Update the npm package: npm install -g openclaw@2026.3.11
3. Verify new version: openclaw --version — should show 2026.3.11
4. Restart both gateways (BerryPi on :18789, LobsterDrew on :18795) so they pick up the new version
5. Verify both agents poll successfully after restart

Acceptance Criteria

• openclaw --version returns 2026.3.11 on klyuchi
• BerryPi gateway (:18789) running with new version
• LobsterDrew gateway (:18795) running with new version
• Both agents complete at least one successful poll cycle after update

Description

Update OpenClaw from 2026.3.8 to 2026.3.11 on tolbachik.

Steps

1. Check current version: openclaw --version
2. Update the npm package: npm install -g openclaw@2026.3.11
3. Verify new version: openclaw --version — should show 2026.3.11
4. Restart CrankyCrab gateway (:18789) so it picks up the new version
5. Verify agent polls successfully after restart

Acceptance Criteria

• openclaw --version returns 2026.3.11 on tolbachik
• CrankyCrab gateway (:18789) running with new version
• Agent completes at least one successful poll cycle after update

Description

Download the WildUs logo from R2 object storage and commit it to the wildus repo under site/assets/.

Acceptance Criteria

• Logo downloaded from R2: wildus-media/discord/ready-for-printing/2026-03-06/svg-logo/logo1.svg
• Committed to site/assets/logo.svg in wild-us/wildus repo

Context

• Repo: wild-us/wildus (already exists, all agents have access)
• R2 bucket: wildus-media on Cloudflare

Dependencies

None

Notes

Decisions

Description

Create a simple placeholder page for wildus.org using the logo already committed to the repo.

Acceptance Criteria

• site/index.html exists with centered WildUs logo on white background
• Mobile-friendly
• No frameworks — vanilla HTML/CSS only
• Logo referenced from assets/logo.svg

Context

• Repo: wild-us/wildus
• Logo location: site/assets/logo.svg
• This is a temporary placeholder — just the logo centered on white

Dependencies

Depends on wildus-025 (logo must be in the repo first).

Notes

• 2026-03-12T09:39:01Z — Confirmed the placeholder page is implemented at site/index.html and already committed on the current branch. The page uses plain HTML/CSS, centers the existing logo on a white background, and is responsive for mobile.

Decisions

• Kept the implementation as a single static HTML file with inline CSS to match the temporary placeholder scope.
• Used simple responsive width constraints and viewport settings so the logo scales cleanly on mobile without extra dependencies.

Description

Create a Cloudflare Pages project for the wildus site and configure the custom domain.

Acceptance Criteria

• Cloudflare Pages project created, connected to wild-us/wildus repo
• Build output configured from site/ directory
• Custom domain wildus.org configured and working
• Deployment verified — placeholder page visible at wildus.org

Context

• Repo: wild-us/wildus
• Static files in site/ — no build step needed
• wildus.org DNS already on Cloudflare

Dependencies

Depends on wildus-026 (placeholder page must be built first).

Notes

• 2026-03-12 — Done. Cloudflare Pages project connected to wild-us/wildus, deploying from dev branch, output dir site/. Custom domain wildus.org configured. Production branch set to dev temporarily — needs switching to main after dev→main merge (see wildus-028).

Decisions

Description

Draft a Washington State single-member LLC operating agreement for Qoyn AI LLC. Use a standard template appropriate for a single-member, member-managed LLC. This is a short document (2-3 pages) that establishes the LLC as a separate entity.

Acceptance Criteria

• Valid WA single-member LLC operating agreement covering: purpose, member info, management structure, capital contributions, profit/loss allocation, dissolution terms
• Placeholder fields clearly marked for Viktor to fill in (e.g., [MEMBER NAME], [DATE], [INITIAL CONTRIBUTION])
• Saved to docs/legal/operating-agreement.md in git@github.com:qoyn-ai/qoyn-ai.git
• Includes brief instructions at the top explaining what to fill in and whether notarization is needed (it’s not, in WA)

Context

• Entity: Qoyn AI LLC, Washington State, filed Feb 10, 2026
• Single member: Viktor Potapenko
• Member-managed (no separate managers)
• WA does not require filing the operating agreement — it’s an internal document
• Repo: git@github.com:qoyn-ai/qoyn-ai.git
• Legal docs location: docs/legal/

Dependencies

None

Notes

• 2026-03-11 00:57 PT — Cloned git@github.com:qoyn-ai/qoyn-ai.git to /home/prawnsue/qoyn-ai; repo currently has main only (no dev branch).

• 2026-03-11 00:59 PT — Drafted docs/legal/operating-agreement.md as a Washington single-member, member-managed LLC template for Qoyn AI LLC with fill-in placeholders, top-of-file completion instructions, and explicit note that notarization is not required in WA.

• 2026-03-11 02:37 PT — Foreman self-review: acceptance verified objectively. docs/legal/operating-agreement.md exists on karymsky in ~/qoyn-ai and includes the required WA single-member LLC sections, fill-in placeholders, and top-of-file notarization guidance. Moving to done/.

Decisions

Description

Use the existing citation tracker and live browser flows to complete the remaining StarterSite citation work for Bing Places, Apple Business Connect, and Facebook. If a platform cannot be completed, capture the exact blocker and stop at the narrowest honest boundary.

Acceptance Criteria

• Attempt the live claim/create flow for each of: Bing Places, Apple Business Connect, Facebook Page / business listing
• Use the already-established canonical public NAP consistently
• Update startersite-ai/docs/growth/seo-citations-tracker.md with outcome and current status for each platform
• If blocked, document the exact blocker per platform (login, verification code, CAPTCHA, ownership conflict, policy mismatch, paid gate, etc.)
• Move to in-review if all three platforms are either completed or documented with exact blockers

Context

• Repo: git@github.com:viktor-bering/startersite-ai.git (branch dev)
• Tracker: startersite-ai/docs/growth/seo-citations-tracker.md
• GBP is already set up
• Canonical public address/NAP is already normalized and should be used consistently everywhere
• Browser use is authorized for the live submission pass

Dependencies

None

Notes

• 2026-03-11 04:45 PT — Executed live browser pass for Bing Places, Apple Business Connect, and Facebook Page creation. Bing immediately redirects the management path to genericLogin and requires Microsoft/work/Facebook auth before claim/import can proceed. Apple Business Connect loads publicly but routes Get Started/Sign In into Apple Account auth before any business data can be submitted, with Apple business verification still downstream. Facebook’s pages/create route loads while signed out, but actual page creation still requires a logged-in Facebook personal account to own/admin the page. Updated ~/startersite-ai/docs/growth/seo-citations-tracker.md with exact status/blockers for all three platforms.
• 2026-03-11 05:26 PT — Foreman self-review: acceptance verified objectively. All three scoped platforms were attempted and the tracker was updated with exact blockers, so this task meets its in-review completion bar and moves to done/.

Decisions

Description

Build a Node.js static site generator that reads the workforce git board (board/ directory) and outputs a dark-mode Trello-style kanban web UI.

The generator should:

1. Parse all task files in board/{backlog,in-progress,in-review,done,blocked}/ — YAML frontmatter + markdown body
2. Parse all project files in board/projects/ for project metadata
3. Generate static HTML output to kanban/dist/

The UI should:

1. Display a classic kanban board with 5 columns: Backlog, In Progress, In Review, Done, Blocked
2. Dark mode styling
3. Each task rendered as a card showing: title, assignee, project badge, priority (1-5), created/updated timestamps
4. Clicking a card expands it to show the full rendered markdown content (description, acceptance criteria, context, notes, decisions)
5. Generate one kanban page per project (e.g., dist/infra/index.html, dist/wildus/index.html) plus one “all projects” admin page at dist/index.html
6. Responsive — usable on mobile

Acceptance Criteria

• [ ] node kanban/generate.js reads board/ and outputs static HTML to kanban/dist/
• [ ] All 5 column states rendered as kanban columns
• [ ] Task cards display title, assignee, project, priority, timestamps
• [ ] Card click expands to show full rendered markdown
• [ ] Per-project pages generated at dist/<project-id>/index.html
• [ ] Admin “all projects” page at dist/index.html
• [ ] Dark mode styling, clean Trello-style layout
• [ ] Works with current board contents (6 existing tasks across 3 projects)
• [ ] No frameworks — vanilla HTML/CSS/JS plus a markdown parsing library
• [ ] package.json in kanban/ with dependencies and a build script

Context

• Repo: git@github.com:qoyn-ai/workforce.git
• Board spec: board/README.md
• Task file format: YAML frontmatter (id, project, title, assigned, thinking, escalation, priority, tags, created, updated) + markdown sections (Description, Acceptance Criteria, Context, Dependencies, Notes, Decisions)
• Project file format: YAML frontmatter (id, name, org, repos) in board/projects/*.md
• Board columns map to directories: backlog/, in-progress/, in-review/, done/, blocked/
• See existing task files for examples of the format

Dependencies

None

Notes

• 2026-03-10 17:11 America/Los_Angeles — Built kanban/ static generator with gray-matter + markdown-it, plus package.json/package-lock.json and npm run build entrypoint.
• 2026-03-10 17:11 America/Los_Angeles — Generator now reads all board column task files and project metadata, then writes kanban/dist/index.html, per-project pages under kanban/dist/<project>/index.html, and shared styles.css/app.js assets.
• 2026-03-10 17:11 America/Los_Angeles — Verified build locally with current board contents: cd kanban && npm run build produced 8 task cards across 4 project pages with dark-mode responsive layout and expandable markdown card bodies.
• 2025-07-14 — Reviewed and approved. All acceptance criteria met. Deployed to Cloudflare Pages with git integration, custom domain, and Cloudflare Access authentication.

Decisions

Description

Create a GitHub Actions workflow that automatically builds the kanban static site and deploys it to Cloudflare Pages whenever the board changes.

Acceptance Criteria

• [ ] Workflow file at .github/workflows/deploy-kanban.yml
• [ ] Triggers on pushes to main that touch board/** or kanban/**
• [ ] Runs npm ci in kanban/ directory, then npm run build
• [ ] Deploys kanban/dist/ to Cloudflare Pages using cloudflare/wrangler-action
• [ ] Uses repository secrets: CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID
• [ ] Workflow succeeds with current board contents

Context

• Repo: git@github.com:qoyn-ai/workforce.git
• Generator from kanban-001 outputs to kanban/dist/
• Cloudflare Pages project name and secrets will be configured manually (separate task)
• Reference: https://developers.cloudflare.com/pages/how-to/use-direct-upload-with-continuous-integration/#github-actions

Dependencies

• kanban-001 (static generator must exist first)

Notes

• 2026-03-10 17:00 America/Los_Angeles — Left in backlog. Dependency kanban-001 is not complete yet, and CrankyCrab already has one active in-progress task.
• 2026-03-10 17:18 America/Los_Angeles — Added .github/workflows/deploy-kanban.yml to build kanban/ on pushes touching board/** or kanban/** and deploy kanban/dist/ via cloudflare/wrangler-action.
• 2026-03-10 17:19 America/Los_Angeles — Validated the current generator locally with npm ci && npm run build in kanban/ (Generated 8 tasks across 4 projects into kanban/dist). Workflow expects repository variable CLOUDFLARE_PAGES_PROJECT_NAME plus secrets CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID.
• 2025-07-14 — CANCELLED. Switching to Cloudflare git integration instead of GitHub Action + direct upload. Workflow file removed. Deployment will be handled natively by Cloudflare Pages.

Decisions

Description

Install and configure Agent Browser (Vercel’s headless browser CLI) on the BerryPi machine and hook it up to OpenClaw via the ClawHub skill. This gives OpenClaw a token-efficient browser (93% fewer tokens than Playwright) for web automation tasks.

Acceptance Criteria

• agent-browser binary installed globally via npm
• Chrome for Testing downloaded via agent-browser install --with-deps
• Verified working: agent-browser open https://example.com && agent-browser snapshot -i && agent-browser close
• ClawHub skill thesethrose/agent-browser installed
• OpenClaw restarted and skill confirmed loaded

Installation Steps

# 1. Install binary
npm install -g agent-browser

# 2. Install Chrome + Linux system dependencies (required for headless Linux)
agent-browser install --with-deps

# 3. Verify
agent-browser open https://example.com
agent-browser snapshot -i
agent-browser close

# 4. Install OpenClaw skill
clawhub install thesethrose/agent-browser
# (install clawhub first if needed: npm install -g clawhub)

# 5. Restart OpenClaw
openclaw gateway restart

Context

• BerryPi is headless Linux arm64 (Raspberry Pi)
• Agent Browser is a Rust-based CLI by Vercel — built for headless server environments
• --with-deps flag installs required X11/display libs for Linux even in headless mode
• The skill auto-fetches its SKILL.md from GitHub — do not copy it manually
• Reference: https://github.com/vercel-labs/agent-browser
• OpenClaw skill: https://github.com/openclaw/skills/blob/main/skills/thesethrose/agent-browser/SKILL.md

Dependencies

None

Notes

Decisions

Description

Install and configure AgentMail on BerryPi so OpenClaw has its own dedicated email inbox. AgentMail is a Y Combinator-backed email service built specifically for AI agents — avoids Google banning accounts used by agents.

Acceptance Criteria

• AgentMail account created at console.agentmail.to (free tier: 3 inboxes)
• API key obtained from AgentMail Console
• Inbox name noted (format: yourname@agentmail.to)
• ClawHub skill installed and configured with API key
• OpenClaw restarted and skill confirmed loaded
• Test: forward an email to the inbox and verify OpenClaw surfaces it in Telegram

Installation Steps

# 1. Install the skill via ClawHub
npx clawhub@latest install agentmail

# 2. Add API key to OpenClaw config (~/.openclaw/openclaw.json)
# Add under skills.entries.agentmail.env:
{
  "skills": {
    "entries": {
      "agentmail": {
        "enabled": true,
        "env": {
          "AGENTMAIL_API_KEY": "your-api-key-here"
        }
      }
    }
  }
}

# 3. Verify skill is loaded
openclaw skills list --eligible
# Should show "agentmail" in the list

# 4. Restart OpenClaw
openclaw gateway restart

Pre-requisites (manual steps before running above)

1. Go to https://agentmail.to → Get Started
2. Sign up (Google login works)
3. Create an inbox (free tier gives 3)
4. Copy the API key from the dashboard

Context

• AgentMail docs: https://docs.agentmail.to/integrations/openclaw
• Free tier: 3 inboxes, generous limits
• Use cases: personal email summaries, forwarding invoices/newsletters, business support inbox
• Alternative to Gmail (which Google may ban for agentic use)

Dependencies

None

Notes

Decisions

Description

Create the Wild Us Facebook business page. Registration priority #6 — @wildus is taken (personal profile: Marek Wild); will need fallback handle. Lowest priority — Facebook pages can be created anytime after Meta/Instagram account exists.

After registration, document the signup flow so we have a playbook for future brands on this platform.

Acceptance Criteria

• Facebook business page created with handle (per checklist fallback order: @wildus → @wildus_official → @wildusbrand)
• Page description and bio set
• Profile picture placeholder set
• 2FA enabled on the personal account (authenticator app preferred)
• Recovery codes saved
• vault/brand/claimed-handles.md updated
• Signup flow documented — write up what happened in the task notes: fields per step, verification gates, anti-bot measures, profile setup options, quirks

Context

• @wildus on Facebook: occupied (personal profile — Marek Wild). @wild.us also resolves to same.
• Signup email: facebook@wildus.org (Google Workspace alias → viktor@qoyn.ai)
• Facebook uses Meta path — can reuse Meta account from Instagram registration
• Facebook pages require a personal account as admin
• See vault/brand/social-handle-registration-checklist.md

Default Data

Steps

1. Open a clean browser session
2. Navigate to https://www.facebook.com/r.php
3. Sign up with email facebook@wildus.org — use Meta native credentials (same path as Instagram)
4. Fill in the form using the default data above
5. At any verification gate (email code, CAPTCHA, phone):
   • Run notify-viktor "<what you need>" — sends Telegram with Screen Share button
   • Run wait-for-viktor — blocks until Viktor connects, handles it, and disconnects
   • Resume once wait-for-viktor returns
6. After personal account is created, create a Facebook Page for Wild Us
7. Set page username: try @wildus first (taken — Marek Wild). Try @wildus_official → @wildusbrand
8. Set page description using the default data above
9. Set profile picture if a placeholder is available in the repo
10. Enable 2FA on the personal account (authenticator app preferred)
11. Save recovery codes
12. Update vault/brand/claimed-handles.md with the claimed handle, email, date, and status

After Registration — Document the Flow

Write up the signup experience in the task notes using the format from the social handle registration process.

If You Get Stuck

If you hit a blocker that requires human input (CAPTCHA, phone verification, manual confirmation, email verification code):

1. Run notify-viktor "<description of what you need>" — this sends a Telegram message with a Screen Share button
2. Run wait-for-viktor — blocks until Viktor connects via Screen Sharing, handles the gate, and disconnects
3. Once wait-for-viktor returns, resume your work
4. Fallback: If wait-for-viktor is not available or times out, poll the page state every 5 seconds — watch for changes
5. Do NOT retry aggressively — one calm attempt, then notify and wait

Dependencies

wildus-003 (handle checklist — done), wildus-014 (Instagram — Meta account created there first)

Notes

• 2026-03-12 — Priority unchanged at #6 (last). Depends on having a Meta account from Instagram registration. Google Workspace on qoyn.ai replaces the Gmail anchor strategy.
• 2026-03-13 — Merged with single-pass approach. No separate recon — document the flow as a byproduct of registration.
• 2026-03-13 — Facebook Page created by Viktor under his personal Facebook account. Page is part of Viktor’s Facebook Business Portfolio. Category: Apparel & Clothing. Location: Vancouver, WA. Bio set. Website: wildus.org. Social links added: Instagram, TikTok, Pinterest. No username/handle set — Facebook may require page age or follower count before allowing one. Page can be transferred to a dedicated admin account later.

Decisions

Description

Create the Wild Us Pinterest business account. Registration priority #5 — @wildus is taken (active account with boards); will need fallback handle.

After registration, document the signup flow so we have a playbook for future brands on this platform.

Acceptance Criteria

• Pinterest business account created with handle (per checklist fallback order: @wildus → @wild.us → @wildus_official → @wildusbrand)
• Bio drafted and set
• 2FA enabled
• Recovery codes saved
• vault/brand/claimed-handles.md updated
• Signup flow documented — write up what happened in the task notes: fields per step, verification gates, anti-bot measures, profile setup options, quirks

Context

• @wildus on Pinterest: occupied (active — has boards)
• @wildusbrand: appears open
• Signup email: pinterest@wildus.org (Google Workspace alias → viktor@qoyn.ai)
• See vault/brand/social-handle-registration-checklist.md

Default Data

Steps

1. Open a clean browser session
2. Navigate to https://www.pinterest.com/business/create/
3. Sign up with email pinterest@wildus.org — create as a Pinterest business account
4. Fill in the form using the default data above
5. At any verification gate (email code, CAPTCHA, phone):
   • Run notify-viktor "<what you need>" — sends Telegram with Screen Share button
   • Run wait-for-viktor — blocks until Viktor connects, handles it, and disconnects
   • Resume once wait-for-viktor returns
6. Set username: try @wildus first (likely taken — active account). Try @wild.us → @wildus_official → @wildusbrand
7. Complete any profile setup steps (bio, avatar — skip what’s skippable, fill in what’s useful)
8. Enable 2FA if available
9. Save recovery codes
10. Update vault/brand/claimed-handles.md with the claimed handle, email, date, and status

After Registration — Document the Flow

Write up the signup experience in the task notes using the format from the social handle registration process.

If You Get Stuck

If you hit a blocker that requires human input (CAPTCHA, phone verification, manual confirmation, email verification code):

1. Run notify-viktor "<description of what you need>" — this sends a Telegram message with a Screen Share button
2. Run wait-for-viktor — blocks until Viktor connects via Screen Sharing, handles the gate, and disconnects
3. Once wait-for-viktor returns, resume your work
4. Fallback: If wait-for-viktor is not available or times out, poll the page state every 5 seconds — watch for changes
5. Do NOT retry aggressively — one calm attempt, then notify and wait

Dependencies

wildus-003 (handle checklist — done), wildus-013 (YouTube — do YouTube first)

Notes

• 2026-03-12 — Priority unchanged at #5. Google Workspace on qoyn.ai replaces the Gmail anchor strategy.
• 2026-03-13 — Merged with single-pass approach. No separate recon — document the flow as a byproduct of registration.
• 2026-03-13 — Registered by Viktor. Email: viktor@wildus.org (Pinterest rejected pinterest@wildus.org). Username: WildUs_official. 2FA enabled. Bio set.

Decisions

Description

Merge the wildus dev branch into main via PR, then switch the Cloudflare Pages production branch from dev to main.

Acceptance Criteria

• PR created from dev→main in wild-us/wildus
• PR reviewed and merged
• Cloudflare Pages production branch changed from dev to main (Settings → Builds & deployments)
• Deployment from main verified — wildus.org still working

Context

• Cloudflare Pages currently deploys from dev because main is behind
• Convention: agents push to dev, Victor merges dev→main
• Once main is caught up, Pages should deploy from main (the stable branch)

Dependencies

None — do this whenever Victor is ready to sync dev→main.

Notes

Decisions

Description

Submit startersite.ai to key local business directories and citation sources for Portland metro SEO. Follow the G2 and G4 playbooks for local citation building.

Acceptance Criteria

• Google Business Profile created/claimed and fully optimized (photos, description, categories, hours)
• Submitted to top 10 local directories (Yelp, BBB, Nextdoor Business, Portland Business Journal, etc.)
• NAP (Name, Address, Phone) consistent across all listings
• Citations documented in a tracking spreadsheet or markdown file
• Saved to startersite-ai/docs/growth/seo-citations-tracker.md

Context

• GBP setup guide: startersite-ai/docs/growth/G2-gbp-setup.md
• SEO strategy: startersite-ai/docs/growth/G4-seo-content-strategy.md
• Business: Qoyn AI LLC DBA startersite.ai, Portland metro area
• Phone: (360) 800-1177

Dependencies

None (background growth work, runs in parallel with launch)

Notes

• 2026-03-11 01:12 PT — CrankyCrab: Read the linked startersite project brief plus the available growth docs. Created startersite-ai/docs/growth/seo-citations-tracker.md with canonical NAP, current known listing status, GBP optimization checklist, and a prioritized Phase 1 citation target list; pushed on dev in c383432.
• 2026-03-11 01:12 PT — CrankyCrab: Full completion is blocked on live third-party account actions and verification flows (GBP audit/optimization, Yelp/BBB/Nextdoor/Bing/Apple/Facebook submissions/claims). Left in progress rather than falsely marking done.
• 2026-03-11 00:59 PT — CrankyCrab: Did a second pass in ~/startersite-ai. Tightened docs/growth/seo-citations-tracker.md with direct claim URLs, public-status notes for already-known profiles, and a founder handoff checklist for the live submission pass. Committed/pushed on dev in fa69abf.
• 2026-03-11 01:00 PT — CrankyCrab: Acceptance criteria still not honestly met. I did not create/claim third-party directory listings without the required live account / verification steps.
• 2026-03-11 01:17 PT — CrankyCrab: Did another research/documentation pass and pushed ~/startersite-ai commit c4ff043 on dev. Refined docs/growth/seo-citations-tracker.md with a dated public-research audit, tightened the local directory shortlist, and demoted Portland Business Journal from “core citation” to optional/paid visibility.
• 2026-03-11 01:17 PT — CrankyCrab: Task still blocked on live owner actions for GBP audit plus Yelp / BBB / Nextdoor / Bing Places / Apple Business Connect / Facebook / chamber submissions. Keeping in in-progress instead of pretending the internet filled itself out.
• 2026-03-11 01:11 PT — CrankyCrab: Did another documentation pass in ~/startersite-ai and pushed commit 15e5927 on dev. Tightened docs/growth/seo-citations-tracker.md with a fresh site audit timestamp, a Phase 1 execution sheet (claim URLs, required owner account, verification gate, target end-state), and a shortest-path checklist to finish the live citation pass once founder account access is available.
• 2026-03-11 01:11 PT — CrankyCrab: Acceptance criteria are still not truthfully complete because the remaining work is almost entirely third-party owner/verification flow, not repo work.
• 2026-03-11 01:31 PT — CrankyCrab: Did a cleanup pass in ~/startersite-ai and pushed dev commit 04c5956. Added a concrete founder live-pass kit to docs/growth/seo-citations-tracker.md so the eventual third-party submission session has the exact minimum inputs/docs ready before opening Yelp / BBB / Bing / Apple / Nextdoor / Meta.
• 2026-03-11 01:31 PT — CrankyCrab: Still not moving this to in-review. Acceptance criteria require actual directory submissions / claims and a live GBP optimization audit, which I did not fake my way through without owner logins or verification flow access.
• 2026-03-11 02:40 PT — Founder clarification: GBP for StarterSite is already set up. Canonical public address/NAP is already normalized and should be used consistently everywhere. Browser use is authorized for the live citation pass. Finish the remaining directory claims/submissions unless a concrete blocker remains.
• 2026-03-11 02:40 PT — Foreman instruction: Continue execution for the remaining live platforms using browser flows. If the task cannot be completed, move it to blocked/ and document the exact blocker per platform (for example: missing login, missing verification code, CAPTCHA, paid gate, account ownership, or platform policy mismatch). Do not leave it in in-progress with only generic uncertainty.
• 2026-03-11 03:17 PT — Foreman split out startersite-009 for PrawnSue to handle the Bing Places / Apple Business Connect / Facebook live pass so the external-submission work can proceed in parallel and with platform-specific accountability.
• 2026-03-11 02:32 PT — CrankyCrab: Did a live site / machine-readable NAP audit and pushed ~/startersite-ai commit 990376c on dev. Updated docs/growth/seo-citations-tracker.md with a real blocker the earlier passes had not called out cleanly: the public site currently exposes 505 SE 184th Ave, Vancouver, WA 98683 in LocalBusiness JSON-LD and llms*.txt, which may conflict with the service-area / hidden-address citation plan.
• 2026-03-11 02:32 PT — CrankyCrab: Keeping this in in-progress. Before broad directory submission, founder needs to make an explicit NAP decision: either keep that full street address as canonical everywhere, or remove/normalize the public address surfaces first and then submit citations consistently. The third-party claim/create work is still owner-login / verification gated.
• 2026-03-11 03:34 PT — CrankyCrab: Did the live browser pass the foreman asked for and pushed ~/startersite-ai commit e0617fa on dev. Updated docs/growth/seo-citations-tracker.md with live findings for Yelp / BBB / Nextdoor / ChamberofCommerce plus the split-out ownership of Bing / Apple / Facebook under startersite-009.
• 2026-03-11 03:34 PT — CrankyCrab: Concrete blockers are now documented per platform instead of hiding behind mushy uncertainty: Yelp requires owner login/sign-up + verification, BBB requires owner-led profile claim/submission + review, Nextdoor stops immediately at business-account creation, and ChamberofCommerce requires account creation plus CAPTCHA. Because the remaining work is external owner-account / verification flow, this task should move to blocked/ rather than pretending it is nearly done.

Decisions

• 2026-03-11 01:12 PT — CrankyCrab: Created startersite-ai/docs/growth/seo-citations-tracker.md as the working citation source of truth with canonical NAP, current known profile status (GBP/Instagram/LinkedIn/Facebook), GBP optimization checklist, and a prioritized target-directory list.
• 2026-03-11 01:12 PT — CrankyCrab: This task is not fully complete yet. Several acceptance items require live account ownership, verification, CAPTCHA/SMS/email flows, or membership decisions on third-party platforms (e.g. Yelp/BBB/Nextdoor/Bing/Apple/Facebook). Those external listing actions were not executed in this pass.