panchicore

Workflow Finding Type Race Condition

Problem

When Workflow A calls Workflow B via a run_workflow node, both workflows must share the same entity_name_type (finding type). This is validated at save time and at every WorkflowManager instantiation. However, entity_name_type lives on the mutable Workflow record — not in the versioned snapshot — so it can be changed at any time via PUT /workflows/<cuid>, breaking running executions.

Root Cause

Two separate API paths update a workflow:

panchicore

SA2 Final Verification — Authorization Request

Ticket: SC-14561 — 25 - Final SA2 verification: zero legacy patterns + docs update

Current State

77 SA1 legacy patterns remain across src/backend/ (76) and tests/ (1). The CI gate already blocks new patterns on every PR. We need to reach zero to close the SA2 migration epic.

Proposed: 9 PRs (one per logical group)

panchicore

Missing Dependency Check on Artifact (Finding) Custom Field Deletion

Summary

Deleting an Artifact Field (finding custom field) skips dependency checking entirely. A user can delete a field that is actively referenced in workflow nodes, breaking running executions. Model Fields have full dependency protection; Artifact Fields have none.

Impact (prod data — vmprod_17feb)

Metric	Count

panchicore

ModelStageParams — add .name back + null-safe

Problem

1. Demo and HLD show params.model_stage.name but pushed code removed .name (only .cuid)
2. params.model_stage is None when no status → AttributeError on .name/.cuid access (Luis's null pointer concern)

Fix

panchicore

TLC Transport TMS - "Mental Peace" Testing Plan

📊 Projected Metrics (Production-Grade)

Category	Current State	Projected State	Impact
Core Service Coverage	22.4%	>95%	Critical: Fixes blind spots in Cost/Price engine.
Isolation Coverage	~0%	100%	Critical: Proves cross-tenant data leaks are impossible.
Soft-Delete Coverage	<10%	100%	High: Ensures deleted data is hidden from all UIs.
Action Redundancy	High	Low	Medium: Leaner, faster, more maintainable test suite.

panchicore

Plan: Production Deploy — /setup bootstrapper + Vercel + Supabase

Goal

Deploy TMS to Vercel prod with Supabase prod DB. Provide a one-time /setup UI to create the first admin user + organization on a blank database.

Files to modify/create

Action	File	Purpose
Create	src/app/(auth)/setup/page.tsx	Server component: checks if any org exists → redirect to /login if yes, else render form

panchicore

Plan v2: Wire Document Outline Editor to Existing Content Block APIs

Discovery

The backend APIs for content block mutations already exist — no new backend code needed.

Existing Backend Endpoints (routes/ui_model_document_blocks.py)

Method	Endpoint	Action	Handler

panchicore

ValidMind Email Usage Count by Pattern

Summary

Pattern	Count	%	Description
1. Celery task .delay()	13	76%	Async from routes/handlers
2. Direct from route	1	6%	Sync, blocks request
3. Direct from Celery task	3	18%	Already async context

panchicore

Async Email Pattern - ValidMind

Pattern for sending emails that follows best practices and is async by default.

Flow

Route/Service                    Celery Task                      Email Notification
────────────                     ───────────                      ──────────────────
1. Call task with .delay()  →   2. Fetch entities by CUID    →   3. Build template data

panchicore

VMConfig: Phasing out export_env

Why it exists

Bridge for gradual migration. Lets vmconfig be source of truth while legacy code still reads env vars.

Real example: Our email config has two code paths:

# NEW (vmconfig)