La interfaz está localizada; las descripciones y documentos de las Skills se traducen automáticamente con IA a su idioma. El código, los comandos, rutas y términos técnicos se mantienen en el original, y prevalece el documento del autor.
Explorar Skills
Despliegue y operaciones · SKILL.md

sales-neon

sales-neon

Neon PostgreSQL vault/archive configuration, schema, and operational patterns for the Sales Navigator hub (HUB-SALES-NAV-20260130). Use this skill whenever querying, migrating, debugging, or making data-layer decisions in the sales-navigator repo. Trigger on: Neon, PostgreSQL, Postgres, database, schema, sales_state, sales_factfinder, sales_insurance, sales…

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentación de la Skill

GitHub

name: sales-neon description: > Neon PostgreSQL vault/archive configuration, schema, and operational patterns for the Sales Navigator hub (HUB-SALES-NAV-20260130). Use this skill whenever querying, migrating, debugging, or making data-layer decisions in the sales-navigator repo. Trigger on: Neon, PostgreSQL, Postgres, database, schema, sales_state, sales_factfinder, sales_insurance, sales_systems, sales_quotes, column_registry, migration, connection pooling, NEON_DATABASE_URL, pipeline tracking, prospect data, meeting data, CF D1, CF KV, Cloudflare Workers, or any reference to the sales data layer. Also trigger when discussing CRM intake, 4-meeting process state, quote approval, or PROMOTE_TO_CLIENT events. If the question touches relational data in this repo, this skill applies even if the user does not mention Neon by name. master_skill: IMO-Creator/skills/neon/SKILL.md hub_id: HUB-SALES-NAV-20260130

Sales Navigator -- Neon + CF D1 Skill

Architecture (BAR-100 Shift)

The data layer follows a two-tier model:

TierTechnologyRole
WorkingCF D1 / CF KVActive queries, runtime state, application traffic
VaultNeon Serverless PostgreSQLArchival storage, migrations, canonical schema authority

CF Workers serve as the compute layer. The Figma UI design layer connects to CF Workers, which read/write CF D1 for working data and sync to Neon vault for long-term persistence.

What This Repo Uses

ComponentValue
Hub IDHUB-SALES-NAV-20260130
Hub Namesales-navigator
Working DatabaseCF D1 (Cloudflare Workers runtime)
Vault DatabaseNeon Serverless PostgreSQL
Working KVCF KV (session state, caches)
Schemasales (canonical), sn_* prefix (deprecated)
Compute LayerCF Workers
Design LayerFigma UI
Secrets ProviderDoppler (doppler run -- npm run dev)
Column Registrycolumn_registry.yml (canonical schema spine)
Canonical Migrationsales/migrations/001_sales_schema.sql (targets Neon vault, per ADR-005)
Deprecated Migrationsrc/data/migrations/001_create_sales_navigator_schema.sql (sn_* prefix, DO NOT execute)

Connection Configuration

All secrets are injected via Doppler. No .env files with real values are permitted.

VariablePurposeInjected By
NEON_DATABASE_URLNeon vault connection string (migrations, archive sync)Doppler
CF_D1_DATABASE_IDCF D1 working database identifierDoppler
CF_ACCOUNT_IDCloudflare account identifierDoppler
CF_API_TOKENCloudflare API token for Workers/D1/KVDoppler
COMPOSIO_API_KEYExternal API calls via Composio MCPDoppler

Neon vault connection pattern (migrations and archive only):

# Pooled (archive reads, sync operations)
postgresql://user:pass@ep-xxx-pooler.region.aws.neon.tech/dbname?sslmode=require

# Direct (migrations, admin, pg_dump)
postgresql://user:pass@ep-xxx.region.aws.neon.tech/dbname?sslmode=require

Critical: Neon is vault/archive ONLY. All application-level queries go through CF D1. Use the Neon pooled endpoint for archive sync operations. Use the direct endpoint only for migrations and pg_dump. See master skill IMO-Creator/skills/neon/SKILL.md for full connection pooling rules and PgBouncer transaction-mode constraints.

Schema / Data Model

The canonical schema is defined in column_registry.yml. All generated TypeScript types and Zod schemas are projections of this file and must never be hand-edited.

Spine Table

TablePurpose
sales.sales_statePhase router -- authoritative identity, gates sub-hub access

Columns: sales_id (UUID PK, universal join key), legal_name (TEXT), domicile_state (TEXT), current_phase (TEXT: factfinder/insurance/systems/quotes), status (TEXT), source (TEXT), version (INT), created_at, updated_at

Sub-Hub Tables (4 meetings)

Sub-HubCanonical TableError TableKey Columns
Meeting 1: FactFindersales.sales_factfindersales.sales_factfinder_errorsemployer_name, employee_count, renewal_month, prior_broker
Meeting 2: Insurancesales.sales_insurancesales.sales_insurance_errorsfunding_model, strategy_selected
Meeting 3: Systemssales.sales_systemssales.sales_systems_errorspayroll_system, admin_model, compliance_owner
Meeting 4: Quotessales.sales_quotessales.sales_quotes_errorsquote_version, total_cost (USD_CENTS), approved_flag

All sub-hub tables join to spine via sales_id (TEXT). Each sub-hub has exactly 1 CANONICAL and 1 ERROR table per OWN-10a/OWN-10b.

For the full column-level schema reference, see references/schema.md.

Operational Patterns

Phase Progression

The sales.sales_state.current_phase column gates which sub-hub is active:

factfinder -> insurance -> systems -> quotes -> [PROMOTE_TO_CLIENT]

Query Pattern (Working Layer)

Application queries go through CF Workers reading/writing CF D1. For vault operations (reporting, archival queries), CF Workers connect to Neon via the pooled endpoint.

Schema Changes

  1. Update column_registry.yml
  2. Run ./scripts/codegen-generate.sh
  3. Generated output lands in src/data/hub/generated/ and src/data/spokes/generated/
  4. Pre-commit hook enforces sync between registry and generated output
  5. Apply migration to Neon vault, then sync D1 schema

Error Tables

All error tables are append-only. Columns: id (BIGSERIAL in Neon vault; INTEGER AUTOINCREMENT in D1), sales_id (nullable FK), error_code, payload (JSONB in Neon; TEXT/JSON in D1), process_id, created_at.

Known Issues

  • Deprecated sn_ prefix*: The original migration (001_create_sales_navigator_schema.sql) used sn_prospect, sn_sales_process, sn_meeting, sn_meeting_outcome tables. These are superseded by the sales.* schema per ADR-005. Do not execute the deprecated migration.
  • D1 type mapping: CF D1 uses SQLite under the hood. BIGSERIAL maps to INTEGER AUTOINCREMENT, JSONB maps to TEXT (with JSON validation in application layer), TIMESTAMPTZ maps to TEXT (ISO-8601). The column_registry.yml declares Neon vault types; D1 equivalents are derived at migration time.

Cost Profile

ResourceExpected UsagePlan Consideration
CF D1Low -- sales process is human-paced, not high-throughputFree tier likely sufficient during development
CF KVMinimal -- session state, cachesFree tier covers this
CF WorkersLow compute -- API routing and D1 queriesFree tier (100k req/day) covers dev
Neon Vault< 0.5GB for prospect/meeting archive dataFree tier covers this
Neon BranchesDev/staging branches for safe migration testingLaunch plan if > default branch limit

See master skill IMO-Creator/skills/neon/references/pricing.md for full Neon pricing breakdown.

Skills guardadas