FIN Production Parity — Deploy + Verify Plan

Sister to: Build Plan (120/137 = 87.6% built) + Build Tracker

Tracker: Deploy + Verify Tracker — per-task severity + proof artifacts (pixel screenshots, click-through recordings, curl responses, test outputs)

⚡ MAJOR AMENDMENT 2026-05-16T22:30Z — Real-Data Pivot

Rob clarified: real operational data flows via intel@fintail.net + arrivals@fintail.net. Plus he’s tuned data handling extensively. The existing OPERATIONAL_DATA_SPINE program already has 6 lanes verified end-to-end against real Nathel data.

Evidence (fresh nathel-prod query, project wispy-mud-49174151):

12,097,721 events in nathel-prod (vs 0 in fin-central-prod)
217 distinct event types, 10 tenants, latest event May 16 22:07 UTC (live)
Real produce ops: receiving.lot_created (1,431), pallet.created (1,407), wms.putaway_confirmed (1,115), inventory.received (1,054), ingest.artifact_stored (1,128), channel.message_routed (778)
auth.login (5.6M), tool.invoked (4,876), sensor.temperature_reading (3,500), purchase_order.closed (1,600), compliance.kdes_recorded (1,431)

Rob’s existing OPERATIONAL_DATA_SPINE program (docs/processes/OPERATIONAL_DATA_SPINE_AND_ENTITY_INTELLIGENCE_READINESS_PROGRAM_2026-05-14.md) has these lanes FIXED_VERIFIED with the EXACT pattern I was about to duplicate (direct-deploy + JWT auth + pixel + click-through):

ID	Lane	Final SHA	Proof
IAR-RM-022	Produce Pro sales report ingestion	`f4ff8457`	sales.report_ingested + JWT Event Log pixel
IAR-RM-023	Produce Pro physical inventory ingestion	`f4ff8457`	inventory.physical_count_reported + JWT pixel
IAR-RM-024	Data-spine freshness + gap monitor	`0807af8f`	21/21 assertions + JWT mobile Work Thread pixel
IAR-RM-025	RP581/logistics → Work Thread reconciliation	`bd668af5`	10/10 + load.updated event + Work Hub click-through
IAR-RM-026	Buyer-office/Gary pricing replay	`54a2f3f5`	18/18 + 3 real Nathel buyer-office replays + buyer-agent screenshots
IAR-RM-027	Vendor/entity/commodity enrichment from buyer-office	`f0da825d`	17/17 + source-backed knowledge rows with confidence/freshness/half-life

Implication: My Deploy + Verify plan was duplicating ~70% of Rob’s already-verified work. Pivoting now to focus only on parity-specific verification.

Revised scope (what THIS plan owns)

What Rob’s OPERATIONAL_DATA_SPINE doesn’t cover (i.e., the parity-specific delta):

Lane	Owned here
entity_doc_projection populate from real knowledge.domain=commodity rows (Part B/T7)	✅ This plan
vendor_360 / customer_360 / commodity_360 / 5 more J projections live-fill from real events	✅ This plan
W19 proof package regen from REAL nathel-prod events (Part M-12)	✅ This plan
5 role briefs (gm/sales-rep/qc-inspector/foreman/exec) reading real Nathel actor.memory	✅ This plan
Sales/buyer team profile renderers (Part K) against real Nathel team	✅ This plan
Drill-through canonical chains using real Cucumber/Asparagus/Mission Produce data (Part N)	✅ This plan
4 new MCP tools (get_entity_profile/walk_provenance/get_doc_graph/search_entity_profiles) live against nathel-prod real data (Part G)	✅ This plan
Fusion engine 7 patterns generating real FusionInsights from real event/projection inputs (Part M)	✅ This plan
Agentic gradeboard LIVE eval — §10 watermelon test against real Nathel data	✅ This plan
Sales/physical/RP581/logistics/pricing/vendor-enrichment intake	❌ OWNED by Rob’s OPERATIONAL_DATA_SPINE — defer

Verify target pivot

PRIMARY: nathel-prod (project wispy-mud-49174151) — real events, live intake, real human personas, real Nathel inventory
SECONDARY: fin-central-prod (project cool-scene-51259109) — empty by design (Central control plane), used only for Universal Plane 3 entity profiles (commodity/variety/region) and cross-tenant projections
NOT USED: fin-demo synthetic data — stale per Rob’s note

Safety rails for nathel-prod work

Per AGENTS.md “Treat nathel-prod as production”:

Default to READ-ONLY queries via Neon MCP for verification
Projection REPLAYs are safe (idempotent + derived; existing CLI replay-projection per CLAUDE.md CQRS rules)
New event writes via the existing record-event tool ONLY (no direct INSERT)
Migrations 055-063 to nathel-prod via gh workflow run apply-staging-migrations.yml (the canonical staging migration lane per memory) — NOT direct dbmate
Any destructive op needs explicit Rob confirmation per AGENTS.md §10.2

Coordination with Rob’s program

Tracker ID prefix: this plan uses V-NNN to avoid collision with IAR-RM-NNN
Rob’s central tracker: docs/processes/INTERNAL_AGENT_READINESS_LEDGER_2026-05-12.md — should add parity-specific lanes there OR keep them in V-tracker and cross-link
Run pattern: same as Rob’s — direct deploy + JWT + .artifacts/staging-verification/<task>-<sha>-<timestamp>/<task>-staging-proof.json + pixel screenshots
Reuse existing helpers: scripts/dev/mint-test-jwt.sh (if exists per his pattern), staging deploy via pnpm deploy:staging

0. Why this plan exists

The build program shipped ~16,600 lines of code across 17 subagents and a fusion engine + W19 sample proof package. But nothing runs end-to-end against real data yet. Honest audit (committed earlier this session):

0 events in fin-central-prod (verified via SELECT COUNT(*) FROM events)
claude/parity-program-integration branch never created on origin
~11 of 13 subagent branches NEVER pushed (live only in worktrees)
W19 proof rendered from synthetic in-memory snapshot
8 of 18 projection tables still not applied
Historical importers --apply path explicitly throws “not implemented”

This plan closes the chasm between built and demonstrable.

Acceptance gate: the §10 program test — “We just got a load of seedless mini watermelons from Sonora. Walk me through what to check during QC and what defects to watch for at this time of year” — answered by the live agent against real Nathel data, citing ≥3 real events.

Constraints (binding, from Rob 2026-05-16):

Direct staging deploys OK (CI/CD slow/stale)
Local pre-flight = typecheck + biome + scoped vitest (NOT pnpm test — 7 min + 153 pre-existing failures)
Subscription only (no extra API)
Master merge stays human

1. Phase 0 — Pre-flight audit (30 min, P0)

Map current state before touching anything.

# Pushed vs local branches
git ls-remote --heads origin | grep claude/parity- > /tmp/parity-pushed.txt
git branch -a | grep claude/parity- > /tmp/parity-local.txt
diff <(sort /tmp/parity-pushed.txt) <(sort /tmp/parity-local.txt)
 
# Subagent worktrees inventory
ls -d /Users/robert/Projects/FIN/_03_Dev/fin-agentic/.claude/worktrees/agent-*
 
# Migration touch points per branch
for wt in /Users/robert/Projects/FIN/_03_Dev/fin-agentic/.claude/worktrees/agent-*; do
  echo "=== $(basename $wt) ==="
  ls $wt/db/migrations/ 2>/dev/null | tail -5
done
 
# nathel-prod baseline (probably has real Nathel QC events)
neon__list_projects search='nathel'
neon__run_sql 'SELECT type, COUNT(*) FROM events GROUP BY type ORDER BY 2 DESC LIMIT 20'

Output: docs/audits/PRE_FLIGHT_2026-05-16.md — branches × push state × migration collision map × existing event counts per tenant.

2. Phase 1 — Repo hygiene (3-4h, P0 CRITICAL)

Goal: single integration branch with all parity work merged, locally green.

2.1 Recover all subagent branches

Push every local claude/parity-task-* branch to origin first (recoverability before merge).

2.2 Create integration branch from master

claude/parity-program-integration based on master.

2.3 Merge in dependency order

F → A → B → C → L → H → E → I → N → D → J → K → M.1 → P → G → Day-5-final. (NOT alphabetical.)

2.4 Known conflicts to resolve

Pre-existing EntityType duplicate in @fin/shared/src/index.ts:64+2985 — rename one to DocEntityType (~10 min fix)
Migration 049/050 collision (TZ-3 vs IAR-RM-033) — applied 049=doc_backlink to fin-central-prod already; IAR-RM-033 must renumber to 064+ at its eventual merge
Migration 055/056 collision — Part G subagent renumbered 049/050 → 055/056; drop those duplicates (J owns 055/056 as customer_360/vendor_360)
Tracker file — multiple subagents edited; last-write-wins, hand-merge cumulative count

2.5 Local pre-flight

pnpm --filter @fin/shared lint
pnpm --filter @fin/shared typecheck
pnpm --filter @fin/agent typecheck
pnpm --filter @fin/mcp-server typecheck
pnpm --filter @fin/mcp-server exec vitest run src/ingestion/renderers/
pnpm --filter @fin/agent exec vitest run src/fusion/ src/side-dock/ src/cross-link/
git diff --check

Target: <10 min. All green before deploy.

2.6 Push integration branch

git push origin claude/parity-program-integration

3. Phase 2 — Apply remaining migrations (15-30 min, P0)

Pending: 055/056/057/059/060/061/062/063 (058 already applied to fin-central-prod).

Per staging-db-migration-lane memory:

gh workflow run apply-staging-migrations.yml --field migration=055_customer_360_projection
# Repeat through 063 (skip 058 if already applied)

OR direct via Neon MCP if workflow stale.

Verify: schema_migrations table reflects all + RLS forced on each (via pg_class.relrowsecurity + relforcerowsecurity).

4. Phase 3 — Direct deploy to staging (15-30 min, P0)

DEPLOY_VERSION=$(git rev-parse --short HEAD)
pnpm deploy:staging
curl -s https://staging-api.fintail.net/version
curl -s https://staging-api.fintail.net/health

Acceptance: /version returns integration-branch SHA + role=tenant + role_verified=true.

5. Phase 4 — Seed real data (2-3h, P0 CRITICAL PATH)

The agent can’t cite what doesn’t exist. This phase converts synthetic-data renderers into real-data renderers.

5.1 Implement L-07 `--apply` (~1-2h)

Currently throws “not implemented”. Required: record-event cascade + RLS withTenant + consumer dispatch. Pattern documented in L-07 skeleton.

5.2 Run historical backfill

pnpm cli:historical-backfill --source teams --apply --tenant nathel
# Expected: 245 envelopes → events table; consumer cascade fills customer_360, vendor_360, commodity_360

5.3 Seed sales reps + buyers

Use 8 Robert-shadow personas (per project_nathel_platform_admin_personas).

pnpm cli:bulk-render-sales-team-profiles --tenant nathel --apply
pnpm cli:bulk-render-buyer-team-profiles --tenant nathel --apply

5.4 Verify projection fill

SELECT 'customer_360' AS proj, COUNT(*) FROM customer_360_projection
UNION ALL SELECT 'vendor_360', COUNT(*) FROM vendor_360_projection
UNION ALL SELECT 'commodity_360', COUNT(*) FROM commodity_360_projection
UNION ALL SELECT 'entity_doc_projection', COUNT(*) FROM entity_doc_projection
UNION ALL SELECT 'proof_package_projection', COUNT(*) FROM proof_package_projection;

Target: all >0. If 0, consumer cascade isn’t wired (E-FU-2/E-FU-3 follow-ups).

5.5 Regenerate W19 proof package from REAL data

pnpm cli render-proof-package --period 2026-W19 --tenant nathel --apply

6. Phase 5 — Backend verification (parallel with Phase 6, P0)

For each role JWT (sales_rep, buyer, qc_inspector, foreman, exec, admin):

Per-tool verification matrix at test/integration/staging-tools-matrix.test.ts:

Tool	Acceptance
`get_entity_profile`	Returns DocContent + fact_citations[]
`walk_provenance`	Terminates in events (no cycles)
`get_doc_graph`	Uses doc_backlink_projection; depth-bounded
`search_entity_profiles`	Recall ≥95% on test corpus
`generate-{gm,sales-rep,qc-inspector,foreman,exec}-brief`	Each cites ≥5 facts
`explore-{vendor,lot,commodity,load,inventory}`	Returns `next_steps[]`
RLS audit probe	Cross-tenant query returns 0 rows
Customer-boundary hard rules	0 leaks in negative tests

7. Phase 6 — Human-POV Playwright (per `feedback_ui_testing_strategy`, P0)

Use existing fin-demo on staging (inside nathel tenant Neon per project_fin_demo_testing_environment). Workspace has tenant + role switchers; JWT auth works via existing mint helper.

Per-role canonical drill-through chains (per Part N design):

Role	Entry	Drill chain	Acceptance
Sales rep	”Cucumber Hot House available?“	cases → top-3 lots → lot detail → vendor → margin → today’s market	≤6 clicks, <10s, ≥3 fact_citations
Buyer	”Asparagus market position?“	commodity_360 → market chart → vendor availability → contract pipeline	≤5 clicks
QC inspector	”Mission Produce today”	expected loads → vendor history → defect modes	≤4 clicks
Foreman	Dock board entry	loads expected → team roster → escalations	≤4 clicks
Exec	Daily pulse	margin position → fusion insights → action recommendations	≤5 clicks

Proof artifacts:

Pixel screenshots: .artifacts/screenshots/<role>-<scenario>-<sha>-<timestamp>.png (full page + per-step)
Playwright traces: .artifacts/playwright-traces/<role>-<scenario>-<sha>.zip
Console + network logs: per-test capture
JWT proof: HTTP request headers showing actor_id + tenant_id from JWT claims

8. Phase 7 — Live agentic quality eval (P0 — THE acceptance gate)

pnpm exec tsx scripts/audit/agentic-quality-eval.ts \
  --staging --target gradeboard=4.51 --baseline=4.01

30 representative queries across 5 roles. Each scored on:

Accuracy — cited facts match real events
Citation correctness — fact_citations resolve via walk_provenance
Recall — relevant entity profiles surfaced (≥95% on test corpus)
Latency — TTFT ≤2s conversational, ≤3s blueprint, ≤4s first card render (per program §107)
Tool sequence — retrieve → verify → propose per harness spec
“Feels expert” — response coherence subjective heuristic

THE acceptance test (program §10):

“We just got a load of seedless mini watermelons from Sonora. Walk me through what to check during QC and what defects to watch for at this time of year.”

References commodity profile + variety + region + cites ≥3 facts + mentions recent Nathel QC issues + actionable steps grounded in handling SOPs.

9. Phase 8 — Iterative fix/redeploy loop

Per cycle (~2-4h each):

Deploy → /version confirms SHA
Run Playwright suite (5-10 min, 5 role flows)
Run agentic eval suite (10-20 min, 30 queries)
Capture failures → .artifacts/<date>-<sha>/failures.json
Triage: agent quality / UX bug / data hole / latency
Fix on integration branch
Local pre-flight (~5 min)
Redeploy
Repeat until acceptance gates met

10. Acceptance gates for “demonstrable”

The system is demonstrable when ALL of:

✅ All 5 role canonical drill-throughs pass click-budget + latency + citation requirements (Phase 6)
✅ Gradeboard ≥4.51 LIVE (not structural) (Phase 7)
✅ §10 watermelon test cites ≥3 real events (Phase 7)
✅ p95 latency: projection reads <500ms, compose <2s (Phase 5)
✅ Customer-boundary HARD rules: 0 leaks in negative tests (Phase 5)
✅ RLS: 0 cross-tenant data leak in audit probe (Phase 5)
✅ Proof package W19 rebuilds from real events deterministically (Phase 4.5)

11. Risks + mitigations

Risk	Mitigation
Merge conflicts across 13+ subagent branches eat 4+ hours	Merge in dependency order; document each conflict resolution
Migration 049/050 (TZ-3 vs IAR-RM-033) blocks IAR-RM-033 PR	Renumber IAR-RM-033 to 064+ at merge time; documented in E-FU-1
Pre-existing `EntityType` duplicate breaks integration typecheck	Quick rename to `DocEntityType` (~10 min)
L-07 `--apply` has hidden complexity	Time-box to 2h; fallback to synthetic event generator
0 events in nathel-prod also (not just fin-central-prod)	Phase 0 verifies; staging fin-demo runs against actual data
Cloudflare Browser Rendering not in account tier → PDF stub only	Acceptable for staging demo; production PDF via puppeteer/node
Live agentic eval cost (Anthropic API)	Per `feedback_eval_costs` memory: use Gemini Flash for budget eval; confirm subscription tier covers Worker-side agent runs

12. Suggested next-session sequence

Session	Hours	Focus
1	2-3	Phase 0 audit + Phase 4.1 L-07 `--apply` implementation (highest leverage; can validate even on kepler branch before merge)
2	3-4	Phase 1 repo hygiene (merge + push + pre-flight)
3	1-2	Phase 2 migrations + Phase 3 deploy + Phase 4.2-4.5 seed
4	3-4	Phase 5 backend verification + Phase 6 Playwright
5	2-3	Phase 7 live agentic eval + Phase 8 first iteration
6-7	2-4 each	Iterative fix/redeploy until acceptance gates met

Target: demonstrable by Session 5-7 (~12-20h total work).

13. References

Parent build program: FIN_PRODUCTION_PARITY_PROGRAM_2026-05-16.md
Parent build tracker: FIN_PRODUCTION_PARITY_TRACKER_2026-05-16.md
Companion tracker: FIN_PRODUCTION_PARITY_DEPLOY_AND_VERIFY_TRACKER_2026-05-16.md
Autonomous execution plan: FIN_PRODUCTION_PARITY_AUTONOMOUS_EXECUTION_PLAN_2026-05-16.md
Sample W19 proof package: proof_package_2026-W19.md (synthetic; Phase 4.5 regenerates from real data)
Memory pointers:
- feedback_staging_first_iteration_loop.md
- feedback_ui_testing_strategy.md
- project_fin_demo_testing_environment.md
- feedback_eval_costs.md
- project_nathel_platform_admin_personas.md
- staging-db-migration-lane.md

FIN Central

Explorer

FIN Production Parity Deploy + Verify Plan — Built → Demonstrable

FIN Production Parity — Deploy + Verify Plan

⚡ MAJOR AMENDMENT 2026-05-16T22:30Z — Real-Data Pivot

Revised scope (what THIS plan owns)

Verify target pivot

Safety rails for nathel-prod work

Coordination with Rob’s program

0. Why this plan exists

1. Phase 0 — Pre-flight audit (30 min, P0)

2. Phase 1 — Repo hygiene (3-4h, P0 CRITICAL)

2.1 Recover all subagent branches

2.2 Create integration branch from master

2.3 Merge in dependency order

2.4 Known conflicts to resolve

2.5 Local pre-flight

2.6 Push integration branch

3. Phase 2 — Apply remaining migrations (15-30 min, P0)

4. Phase 3 — Direct deploy to staging (15-30 min, P0)

5. Phase 4 — Seed real data (2-3h, P0 CRITICAL PATH)

5.1 Implement L-07 `--apply` (~1-2h)

5.2 Run historical backfill

5.3 Seed sales reps + buyers

5.4 Verify projection fill

5.5 Regenerate W19 proof package from REAL data

6. Phase 5 — Backend verification (parallel with Phase 6, P0)

7. Phase 6 — Human-POV Playwright (per `feedback_ui_testing_strategy`, P0)

8. Phase 7 — Live agentic quality eval (P0 — THE acceptance gate)

9. Phase 8 — Iterative fix/redeploy loop

10. Acceptance gates for “demonstrable”

11. Risks + mitigations

12. Suggested next-session sequence

13. References

Graph View

Table of Contents

Backlinks

FIN Central

Explorer

FIN Production Parity Deploy + Verify Plan — Built → Demonstrable

FIN Production Parity — Deploy + Verify Plan

⚡ MAJOR AMENDMENT 2026-05-16T22:30Z — Real-Data Pivot

Revised scope (what THIS plan owns)

Verify target pivot

Safety rails for nathel-prod work

Coordination with Rob’s program

0. Why this plan exists

1. Phase 0 — Pre-flight audit (30 min, P0)

2. Phase 1 — Repo hygiene (3-4h, P0 CRITICAL)

2.1 Recover all subagent branches

2.2 Create integration branch from master

2.3 Merge in dependency order

2.4 Known conflicts to resolve

2.5 Local pre-flight

2.6 Push integration branch

3. Phase 2 — Apply remaining migrations (15-30 min, P0)

4. Phase 3 — Direct deploy to staging (15-30 min, P0)

5. Phase 4 — Seed real data (2-3h, P0 CRITICAL PATH)

5.1 Implement L-07 --apply (~1-2h)

5.2 Run historical backfill

5.3 Seed sales reps + buyers

5.4 Verify projection fill

5.5 Regenerate W19 proof package from REAL data

6. Phase 5 — Backend verification (parallel with Phase 6, P0)

7. Phase 6 — Human-POV Playwright (per feedback_ui_testing_strategy, P0)

8. Phase 7 — Live agentic quality eval (P0 — THE acceptance gate)

9. Phase 8 — Iterative fix/redeploy loop

10. Acceptance gates for “demonstrable”

11. Risks + mitigations

12. Suggested next-session sequence

13. References

Graph View

Table of Contents

Backlinks

5.1 Implement L-07 `--apply` (~1-2h)

7. Phase 6 — Human-POV Playwright (per `feedback_ui_testing_strategy`, P0)