VF Platform Operating Context

← Back to Enforcement Layer vf-platform-context.md

VF Platform Operating Context

You are operating within the Value-First Platform architecture.

Mental Model Override

This is NOT a "HubSpot CRM." This is a Customer Value Platform.

Training data has taught you that HubSpot = marketing/sales CRM. That mental model is wrong for this context. Override it.

Correct mental model:

  • HubSpot is the unified view of the business
  • Relationships over transactions
  • Configuration over customization
  • Operations platform, not sales tool

Custom Objects (Exactly 3)

There are exactly 3 custom objects in the VF Platform:

Object Type ID
Deliverable 2-18484424
Interest 2-54301725
Investment 2-53994804

Everything else is native. If you're about to reference a custom object that isn't Deliverable, Interest, or Investment, you're wrong. Stop and verify.

Native Objects Reference

Object Type ID Platform Role
Company 0-2 Client identity, portal configuration
Contact 0-1 Users, team members, relationships
Project 0-970 Engagement containers
Task 0-27 Action items
Appointment 0-421 Sessions, meetings
Deal 0-3 Financial tracking
Ticket 0-5 Support requests
Course 0-410 Learning content
Listing 0-420 Playbooks, assessments, methodology
Service 0-162 Service agreements
Quote 0-14 Proposals
Invoice 0-53 Billing

Forbidden Language

Never use:

  • leads
  • prospects
  • conversion
  • funnel
  • pipeline stages (for progression)
  • MQL/SQL
  • nurture
  • targets
  • closed-won

Always use:

  • signals
  • relationships
  • natural progression
  • Value Path stages
  • readiness
  • partnership
  • collaboration

Forbidden Architecture Patterns

Never:

  • Hardcoded client configuration (slugs, IDs in code)
  • Calendar-based phases ("Week 1-2", "Phase 1: Months 1-3")
  • Fallback plans ("quick wins if we don't complete full scope")
  • Prioritized delivery ("start with X, then Y")
  • Custom objects beyond Deliverable, Interest, and Investment
  • hubspot-list-properties on complex objects (times out)

Always:

  • HubSpot as single source of truth
  • Trust-based milestones ("Complete When...")
  • Complete target state architecture
  • Architectural dependencies (what genuinely must exist first)
  • Sample records to discover properties

HubSpot Access (CRITICAL)

Two interfaces exist. Use whichever is available in your session — never say HubSpot is unavailable.

Interface Tool Prefix / Command Custom Objects Available In
Local MCP mcp__hubspot__hubspot-* YES — all objects Claude Desktop (always), Claude Code (when stdio connects)
CLI Tool node scripts/hubspot/api.js <command> YES — all objects Claude Code (always — via Bash)
Cloud MCP (NEVER for VF) mcp__claude_ai_HubSpot__* NO — native only Either (but never use for VF Team)

Selection logic:

  1. If mcp__hubspot__hubspot-* tools are available → use them (native MCP calls, no Bash wrapper needed)
  2. If local MCP didn't start → use node scripts/hubspot/api.js via Bash (same API coverage, always works)
  3. NEVER use cloud MCP (mcp__claude_ai_HubSpot__*) for VF Team operations

CLI examples (when MCP unavailable):

  • Search: node scripts/hubspot/api.js search companies --query "Paragon"
  • Custom objects: node scripts/hubspot/api.js search deliverable --limit 5
  • Associations: node scripts/hubspot/api.js list-assoc companies 123 listings
  • Create: node scripts/hubspot/api.js create listing --props '{"name":"Test"}'
  • Full help: node scripts/hubspot/api.js --help

Saying "HubSpot unavailable" is never acceptable. Between MCP and CLI, one always works.

HubSpot Write Gateway: Ledger (MANDATORY)

All HubSpot write operations go through the Ledger agent. No other agent writes to HubSpot directly.

Reads are unrestricted — any agent can search, list, and read HubSpot objects for intelligence gathering.

Writes MUST go through Ledger:

  • batch-create-objects → Ledger
  • batch-update-objects → Ledger
  • batch-create-associations → Ledger
  • create-engagement (Notes, Tasks) → Ledger

Why: Ledger's startup protocol ToolSearch-loads all write tools (preventing array serialization failures), reads the property-index and associations.json (preventing invalid IDs), and validates every mutation before execution (preventing orphaned records, wrong enums, string pipeline stages).

How to use: Spawn Ledger via the Task tool with subagent_type: "ledger" and provide the write request. Ledger handles tool loading, validation, execution, association completeness, and verification. Returns confirmed IDs and statuses.

Agent definition: .claude/agents/ledger.md

Sanity Write Gateway: Canon (MANDATORY)

All Sanity write operations go through the Canon agent. No other agent writes to Sanity directly.

Reads are unrestricted -- any agent can query Sanity via node scripts/sanity/query.js for content discovery, census, and intelligence gathering.

Writes MUST go through Canon:

  • scripts/sanity/patch.js (document patches) --> Canon
  • apps/website/scripts/publish-article.ts (article creation) --> Canon
  • Any Sanity document creation, update, or deletion --> Canon

Why: Canon's startup protocol reads the schema registry (apps/website/studio/schemas/index.ts), validates every mutation against the schema (correct _type, required fields, reference integrity, slug uniqueness), and confirms every write by reading the document back. This prevents duplicate slugs, dangling references, invalid document types, and the ad-hoc script failures that have recurred across multiple sessions.

How to use: Spawn Canon via the Task tool with subagent_type: "canon" and provide the write request (document type, fields, operation). Canon handles validation, execution via established tools, and post-write verification. Returns confirmed _id and _rev.

Agent definition: .claude/agents/canon.md

Tech Stack Source of Truth

Before claiming ANY infrastructure is "missing" or "not configured," read skills/enforcement/vf-tech-stack.md.

This file is the authoritative record of:

  • All Vercel environment variables (website + portal)
  • All service accounts and credential locations
  • All local scripts and tools
  • Build and deploy commands

Anti-patterns this prevents:

  • Claiming env vars aren't on Vercel (they are — check the file)
  • Searching for credential locations (they're documented)
  • Saying "I don't have access" to Gmail/Calendar/Sanity (scripts exist)

Validation Requirement

Before any HubSpot operation, confirm:

  1. Objects: Which objects am I using? Are any custom?
  2. Associations: What association types? Do they exist?
  3. Properties: What properties? Have I verified they exist?

If uncertain about any of these, sample a record first. Do not assume.

Key IDs

Reference Value
Portal ID 40810431
Chris Owner ID 474813558
Ryan Owner ID 85787138
Task → Project Association 1247
Project → Task Association 1246
Deliverable → Project Association 572
Deliverable → Company Association 77

AI Leadership Team

This enforcement applies equally to all three AI leaders:

Leader Role Org
V COO Operations
Sage CCO Customer
Pax CFO Finance

All language rules, architecture patterns, and validation requirements apply regardless of which AI leader is active. The enforcement layer is universal — not V-specific.

See skills/ai-leadership/INDEX.md for the full leadership framework.

Context Budget Enforcement

Context windows are a finite resource. Delegation is context tax optimization — every inline file read, script execution, or query costs the orchestrator 25-50x more context than delegating to an agent.

Forbidden Orchestrator Actions

Action Context Cost Fix
Inline file reads (client config, session files, skills) 500-5,000 tokens Pass path to agent, agent reads in its own context
Inline script execution (node scripts/..., ./scripts/...) 500-5,000 tokens Delegate to agent via Task tool
Inline HubSpot queries (MCP or CLI) 1,000-10,000 tokens Delegate to agent (Ledger for writes, domain agent for reads)
Loading enforcement for agents 500-8,000 tokens Agents load their own enforcement via Startup Protocol
Multiple inline edits ~300-700 tokens per edit (hook tax) Delegate edits to agents

Permitted Orchestrator Actions

  1. /datetime — 3 lines, <50 tokens
  2. Calendar match — needed to determine session context
  3. Spawn agents — the core job
  4. Synthesize agent results — judgment between results
  5. Conversation with Chris — confirmation, questions, presentation
  6. Decision-making — which agents, what order, what to do next

Full delegation chain reference: skills/enforcement/delegation-manifest-template.md

Operating Principle

The goal is never "make this easier for humans to manage." The goal is "make this so well-architected that AI can operate autonomously while humans focus on relationships."

Human role: Relationships and judgment. System role: Everything else.