reference adam tool inventory 2026-05-13

Phase 1A status reminder

Adam cannot share credentials until Executive approval lands (per his 5/12 18:46Z reply). Everything in this catalog stays in scope-only posture this week — no live integration attempts. When credentials drop, this file becomes the action-list for Phase 1B activation.

The 12 tools

1. Google Shared Drives — https://drive.google.com/drive/shared-drives

• What it is: SkyRun corporate shared-drive hierarchy. Houses cross-franchise reference docs, contracts, brand assets, owner-onboarding templates.
• Phase 1A relevance: NO — Adam's own Google Workspace OAuth (also blocked) is the gating dependency.
• Integration path when access comes: OAuth (Google Drive API, scope https://www.googleapis.com/auth/drive.readonly for cross-franchise reads + drive.file for Adam-owned writes). Joseph already has Google Drive MCP working for his Gmail/Drive — same pattern applies to Adam.
• Data shape: Folder hierarchy, file metadata (id, name, mimeType, modifiedTime, owners), file content (PDF/DOCX/PPTX bytes).
• GC architecture plug-point: Mirrors Joseph's existing Google Drive sync (per reference_drive_sync.md). For Adam tenant: AdamBD/Drive Sync/ folder under /Users/josephbowens/Desktop/AdamBD/ (per tenant.json paths.user_root). The live-ea step that proposes file moves for Joseph applies analogously to Adam's tree.

---

2. Reamze — prospect texting

• What it is: Customer messaging platform (note: this is the prospect-texting Reamze — NOT to be confused with RiaMaze which is SkyRun GC's guest-side unified inbox per reference_ops_stack.md). Adam uses Reamze to text PROSPECTS (BD pipeline outbound), not guests. Two distinct vendors, similar names.
• Phase 1A relevance: NO — needs Adam's Reamze API key or session cookie.
• Integration path when access comes: API preferred (Reamze has a documented REST API). Fallback: chrome_bridge with Adam's authenticated session in a dedicated Chrome profile.
• Data shape: Conversations (thread_id, contact_phone, last_message_at, status), messages (direction, body, timestamp), templates, send-event logs.
• GC architecture plug-point: Reamze becomes a 3rd outbound channel for Adam alongside Gmail and (eventually) SmartLead. Slots into the outbound queue in his PWA's Outbound page (mirroring preview-outbound.html shell). On the ingestion side, Reamze inbound texts feed commitments.json + commitment-tracker so promises made over SMS get tracked the same as email promises. Voice-tuner (voice_check.py) also applies to outbound Reamze drafts.

---

3. HubSpot meeting-booking link — https://meetings.hubspot.com/adam-fleckles/schedule-a-meeting-

• What it is: Adam's HubSpot Meetings public booking link. Prospects click through to self-serve schedule.
• Phase 1A relevance: PARTIAL — the link is public (no creds needed to embed it in Adam-facing drafts). Inserting it into Adam's drafts is unblocked. Reading the booking calendar / created-meetings stream is blocked on HS OAuth.
• Integration path when access comes: HS Meetings API (read meetings created via the link); OR Gmail-based detection (HS sends Adam an email when someone books — already covered by gmail-deep-scan style ingestion if Adam grants Gmail OAuth).
• Data shape: Public link is a static URL (already known). Bookings produce meetings records in HS with attendee email, scheduled_at, custom-question answers.
• GC architecture plug-point: Two places. (a) Adam's outbound drafts auto-insert the meeting link when offering a call — voice-tuner template variable {{adam.meeting_link}} reads from tenant.json (add field). (b) New bookings surface on Adam's PWA Today page as decision tiles (mirrors how Joseph's pipeline-forecast surfaces commitments).

---

4. HubSpot call recording (when calling out from HS)

• What it is: Click-to-call from inside HubSpot; HS records the call and stores audio + AI-summary on the contact's timeline.
• Phase 1A relevance: NO — depends on Adam HS OAuth + Adam owner_id.
• Integration path when access comes: HS Calls API (/crm/v3/objects/calls) — list calls by ownerId=Adam, pull recording_url + AI-generated summary.
• Data shape: Call objects with hs_call_recording_url, hs_call_body (summary), hs_call_duration, hs_call_to_number, hs_call_disposition, associated contact_id.
• GC architecture plug-point: Feeds the same transcript pipeline as Fathom (see #5). Once retrieved, the audio URL gets transcribed via the existing transcript-scan chain (already wired for Joseph; adam-bd-transcript-scan/SKILL.md exists in the scheduled-tasks dir). HS-call summaries land in knowledge_graph.json and commitments.json for Adam's tenant.

---

5. Fathom — Google Meet recordings

• What it is: Auto-records Google Meet calls, generates transcript + AI summary, emails the transcript to participants.
• Phase 1A relevance: PARTIAL — Fathom already wired at the email-ingestion level. transcript-scan/SKILL.md and adam-bd-transcript-scan/SKILL.md both have the from:noreply@fathom.video Gmail filter ready. Once Adam grants Gmail OAuth, Fathom transcripts flow in automatically with zero extra work. Standalone Fathom API access is a nice-to-have, not required.
• Integration path when access comes: TIER 1 (preferred): Gmail OAuth → existing transcript-scan pipeline ingests noreply@fathom.video automatically. TIER 2 (nice-to-have): Fathom API token for direct meeting-list pulls (Fathom does have a public API; not currently used by SkyRun code per grep audit — no existing references in /Library/Application Support/SkyRun/ Python/JS files).
• Data shape: Email with VTT/SRT/PDF transcript attachment + body text containing AI summary, participant list, meeting title, date.
• GC architecture plug-point: Directly into the transcript pipeline. Adam's tenant has its own knowledge_graph.json (per tenant.json paths.knowledge_graph), and his transcripts populate Adam's own KG, not Joseph's. The voice-tuner draws from Adam's transcript corpus for Adam's outbound drafts.
• Prior integration scaffolding: Email-side filter (from:noreply@fathom.video) is in 4 scheduled-task SKILL files. No Fathom-API code exists yet (grep audit returned zero Python/JS hits).

---

6. MARQ

• What it is: Brand-design template platform. SkyRun corporate has 3 seats included in franchise fee; Adam uses for owner-deliverable design templates (postcards, presentations, one-pagers).
• Phase 1A relevance: NO — needs Adam's MARQ workspace access (or template export).
• Integration path when access comes: API preferred (MARQ has API docs); fallback chrome_bridge with Adam's session. Most likely workflow: Adam exports template inventory + Joseph pulls the canonical templates into Adam's Property Deliverables/Templates/ analog under /Users/josephbowens/Desktop/AdamBD/.
• Data shape: Template manifest (template_id, name, last_modified), rendered exports (PDF/PNG), brand-asset library (logos, colors, fonts).
• GC architecture plug-point: Adam's tenant analog of Joseph's skyrun-builder skill. Templates power Adam's owner-deliverable builds (PPTX/PDF projections, postcards). MARQ is mostly a design-side tool — the integration is one-directional (read templates, render in Adam's builder skill). NOT a real-time data feed.
• Note: GC already uses MARQ for postcard templates (per reference_spms_replacement_map.md line 33). Adam's MARQ workspace may overlap with the corporate template set or be his own — TBD when access lands.

---

7. SkyRun Data Studio — all-location new-lead submissions

• What it is: Looker Studio (formerly Google Data Studio) dashboard that aggregates new-lead submissions across all SkyRun franchise locations. This is the corporate-level lead-intake firehose; Adam works across all markets so this is his single view.
• Phase 1A relevance: NO — needs Looker Studio share link OR underlying data-source access.
• Integration path when access comes: Looker Studio dashboards are typically backed by Google Sheets or BigQuery. Best path: get the underlying data source (Google Sheet ID or BQ table) and read it directly via the Google Sheets API or BQ API — far more reliable than scraping a Looker dashboard. Fallback: Looker Studio "Schedule & deliver" emails CSV exports daily.
• Data shape: Per-row new-lead submissions (lead_id, source_market, owner_name, property_address, lead_source, submitted_at, contact_email, contact_phone, beds, intent).
• GC architecture plug-point: Adam's new-lead intake pipeline. Mirrors Joseph's property-scout skill but inbound-only (not scraping; ingesting submitted leads). Adam's tenant gets a daily-data-studio-ingestion cron that pulls overnight, dedups against Adam's SoT (if Adam later activates lead-gen) or just routes new leads to Adam's HubSpot via hubspot-lead-push analog. The hot tile on Adam's PWA Today page: "N new leads from Data Studio overnight — review".

---

8. Notion — notes / documentation

• What it is: Adam's note-taking + documentation hub. Likely contains meeting prep, account notes, internal SOPs.
• Phase 1A relevance: NO — needs Notion integration token + workspace share.
• Integration path when access comes: Notion API via integration token. Adam adds the SkyRun integration to his workspace + shares specific databases/pages with it. Read-only initial scope.
• Data shape: Pages (id, title, last_edited_time, parent), blocks (text content), databases (rows with custom property values).
• GC architecture plug-point: Notion becomes Adam's second memory source alongside the ~/.claude/projects/-Users-josephbowens-Desktop-AdamBD/memory/ files. Nightly consolidation can pull Notion pages → graph entities + commitments. If Adam keeps account notes there, those notes flow into knowledge_graph.json so the brief / today-tiles surface relevant Notion context inline. Joseph has no equivalent — this is Adam-tenant-specific. Worth scoping a dedicated adam-bd-notion-sync cron.

---

9. QRCode Tracker (SPMS)

• What it is: SkyRun SPMS (Strategic Portfolio Management Services — the SkyRun corporate marketing services package) tool for tracking QR-code scans on physical collateral (postcards, signage, owner kits). Tells Adam which postcard batches are getting scanned + by whom.
• Phase 1A relevance: NO — needs SPMS portal access.
• Integration path when access comes: Unknown vendor — almost certainly portal-based (no public API). chrome_bridge with Adam's session, scrape scan-event logs as CSV. Fallback: SPMS may email scan-event digests; ingest via Gmail.
• Data shape: Scan events (qr_code_id, scanned_at, scanned_from_location, user_agent), campaign_id mapping (which postcard batch / signage piece each QR ties to).
• GC architecture plug-point: Attribution layer for postcard campaigns. When a QR scan event matches a lead in Adam's SoT or HS, that lead gets a "warm signal" tag — surfaces as a hot tile on Adam's PWA Today page ("J. Smith just scanned the QR from the April postcard batch — call NOW"). Mirrors Joseph's planned in-market-signal scoring in Postcard Targets tab logic.

---

10. Dimaco Mailing Tracker

• What it is: Vendor portal from Dimaco (postcard-print vendor — see reference_spms_replacement_map.md line 34: "Dimaco is the print vendor (Order N9404 came direct)"). Tracks which postcards mailed, when, and delivery confirmation.
• Phase 1A relevance: NO — needs Dimaco portal access.
• Integration path when access comes: Portal-based, almost certainly no API. chrome_bridge with Adam's session, scrape order-status pages. Fallback: Dimaco emails order confirmations + delivery reports — ingest via Gmail.
• Data shape: Orders (order_id, batch_size, mailed_at, recipient_list_csv, delivery_confirmations), per-piece tracking when USPS IMb is enabled.
• GC architecture plug-point: Closes the loop on Adam's postcard campaigns. Mirrors what reference_postcard_ledger.md is for Joseph's GC postcards (Monday 10am cron). For Adam: adam-bd-postcard-ledger cron pulls Dimaco status, updates outbound.json with "postcard delivered to X" events, and feeds the lead-by-lead "last touched" timeline.

---

11. OwnerPoint (legacy, may still have access)

• What it is: STR-industry owner-targeting / lead-gen vendor. Adam was pitched at VRMA per project_bv_silent_fire_diagnostic_2026-04-30.md line 67. Adam may still have legacy access from a prior eval/trial.
• Phase 1A relevance: NO — and not clear it should be activated even when creds land. OwnerPoint and Vintory are vendor-side alternatives to BeenVerified for owner-contact enrichment. SkyRun GC currently uses BeenVerified (per reference_beenverified_rotation.md). Bringing OwnerPoint online is a vendor decision, not just an integration question — bundle with the Phase 2 vendor evaluation noted in project_bv_silent_fire_diagnostic_2026-04-30.md line 79.
• Integration path when access comes: Likely portal-based, possibly API. chrome_bridge with Adam's session OR API if available.
• Data shape: Owner-contact enrichment records (name, email, phone, mailing address, property details).
• GC architecture plug-point: Direct analog of BeenVerified rotation. If activated, would slot into Adam's daily-beenverified-enrichment analog as an alternate or supplementary enrichment source. Recommendation: defer past Phase 1A and Phase 1B; revisit in Phase 2 vendor decision.

---

12. Vintory (legacy, may still have access)

• What it is: STR-industry lead-gen vendor (competitor to OwnerPoint; "bad-blood with Owner Point" per project_bv_silent_fire_diagnostic_2026-04-30.md line 67). Adam may have legacy access.
• Phase 1A relevance: NO — same posture as OwnerPoint. Vendor-decision-first, integration-second.
• Integration path when access comes: Likely portal-based, possibly API.
• Data shape: Owner-contact + property + market-intent records.
• GC architecture plug-point: Same slot as OwnerPoint. Recommendation: defer past Phase 1A and Phase 1B; revisit in Phase 2 vendor decision.

---

Phase 1A action matrix (what we do this week)

Pattern: 6 NEW tools vs 6 already-known tools

NEW tools (need integration spec — see /Users/josephbowens/Desktop/adam-bd-bootstrap/NEW_TOOLS_INTEGRATION_PLAN.md):

• Reamze (#2)
• Fathom (#5) — partially wired via email filter; API integration still net-new
• MARQ (#6)
• SkyRun Data Studio (#7)
• QRCode Tracker SPMS (#9)
• Dimaco Mailing Tracker (#10)

Already-known tools (existing GC pattern applies; no new spec needed):

• Google Shared Drives (#1) — mirrors reference_drive_sync.md
• HS meeting link (#3) — public URL, just a config field
• HS call recording (#4) — uses existing HS Calls API pattern
• Notion (#8) — standard Notion API integration
• OwnerPoint (#11) — defer to Phase 2 vendor decision
• Vintory (#12) — defer to Phase 2 vendor decision

Cross-references

• Status file: project_adam_status_2026-05-13.md — Phase 1A scope + Joseph's directive
• Behavioral rule: feedback_adam_phase_1a_no_credentials_yet.md — don't push Adam for credentials
• New-tools spec: /Users/josephbowens/Desktop/adam-bd-bootstrap/NEW_TOOLS_INTEGRATION_PLAN.md
• Tenant config: ~/Library/Application Support/AdamBD/tenant.json
• Adam transcript-scan skill: ~/.claude/scheduled-tasks/adam-bd-transcript-scan/SKILL.md
• Source email: Adam Fleckles → Joseph Bowens, 2026-05-12 18:46Z (Gmail thread)