CV-Web vs Pascal Editor Comparison Strategy

Last Updated: March 23, 2026 Owner: Product Planning Canonical linkage: This document supports strategy in 00 and execution in 03.

Purpose

This document captures the current comparison between:

1. The Pascal Editor architecture and workflow model (pascalorg/editor).

2. The local ConstructiVision web implementation (webpage/Simplestruct/cv-web).

The goal is to make an explicit architectural decision for 2026 planning without forcing a risky full-platform migration.

Scope

In scope:

1. Architecture and delivery comparison.

2. Practical modernization recommendations for ConstructiVision.

3. A phased plan for adoption.

Out of scope:

1. Rewriting ConstructiVision desktop AutoLISP product in 2026.

2. Full migration to Pascal Editor monorepo/framework in 2026.

3. Any immediate code changes in this strategy document.

Current State Summary

Pascal Editor

Observed characteristics:

1. Monorepo/package-oriented architecture with clear boundaries between core, viewer, and app layers.

2. Strong separation of state and rendering concerns.

3. Broader platform scope, including cloud-style concerns and release tooling beyond pure local desktop workflows.

4. Emphasis on reusable systems and composable runtime patterns.

ConstructiVision cv-web

Observed characteristics:

1. Single-application Vite + React + TypeScript implementation.

2. Local-first data model with Zustand + Dexie persistence.

3. Custom viewer and dialog-heavy workflow aligned to ConstructiVision business flows.

4. High delivery velocity and lower operational complexity than a large monorepo.

Side-by-Side Comparison

Category	Pascal Editor Pattern	Current cv-web Pattern	Implication
Product scope	Platform-scale editor	Focused workflow application	cv-web can move faster with narrower scope
Repo structure	Monorepo, package boundaries	Single app	Easier today, less reusable long-term
State model	Segmented stores/systems	Broad unified store	cv-web should decompose state incrementally
Persistence	Local + platform-oriented potential	Local-first IndexedDB	Good for early product, needs expansion planning
Rendering pipeline	Layered viewer/core model	App-integrated custom viewer	extract reusable viewer/core services over time
Tooling and ops	Heavier, scalable for larger org	Lean, fast for small team	current stack is correct for 2026 delivery

Decision Framework

Use this decision framework when evaluating architecture moves:

1. Delivery velocity this quarter.

2. Regression risk to desktop and validation workflows.

3. Team capacity (solo-heavy development reality).

4. Maintainability and onboarding cost.

5. Path to future cloud and subscription capabilities.

Recommendation

Primary Recommendation

Adopt Pascal-style architecture patterns incrementally inside ConstructiVision, without a full migration in 2026.

Why

1. A full migration is high risk and would likely delay distribution and validation objectives.

2. cv-web already delivers value and should remain the active web velocity lane.

3. Pattern adoption yields most of the architectural benefits with far less execution risk.

Phased Adoption Plan

Phase A: Internal Boundary Cleanup (Near-term)

1. Decompose store responsibilities into project, viewer, UI, and I/O domains.

2. Extract geometry/business logic from UI components into pure modules.

3. Add typed event boundaries for tool interactions.

Exit criteria:

1. Reduced coupling across dialogs/viewer.

2. No regression in existing cv-web user workflows.

Phase B: Reusable Core Surface (Mid-term)

1. Formalize a core service layer usable by desktop and web planning tools.

2. Introduce stable interfaces for persistence and export pipelines.

3. Add tests for extracted pure logic modules.

Exit criteria:

1. New feature work lands without touching broad shared state.

2. Core modules are independently testable and documented.

Phase C: Optional Packaging Evolution (Later)

1. Reevaluate workspace/monorepo split only if team size and product scope justify it.

2. Keep framework migration optional and evidence-driven.

Exit criteria:

1. Clear ROI case for repo/tooling shift.

2. No impact to release-critical desktop timeline.

Risk and Effort Matrix

Initiative	Effort	Risk	Confidence
Store decomposition in cv-web	Medium	Medium	High
Geometry/core extraction	Medium	Medium	High
Event bus boundary layer	Low-Medium	Low-Medium	Medium-High
Full monorepo migration	High	High	Low-Medium
Framework migration (Vite -> Next)	High	High	Low

Explicit Non-Goals for 2026

1. No full rewrite of desktop ConstructiVision.

2. No forced migration to Pascal Editor framework/repo model.

3. No expansion that delays P0/P1 validation and release gates.

Integration with Program Docs

This strategy affects:

1. 00 vision and success criteria (canonical strategic direction).

2. 03 phase plan (execution alignment and gates).

3. 04 timeline and 10 milestones (dependency and sequencing updates).

4. 07 release and distribution (scope boundaries and release posture).

5. 23 business plan and 08 demo plan (market story and product track alignment).

Team Discussion Checklist

Before approving architectural scope changes, decide:

1. Which 2-3 pattern adoptions are approved this quarter.

2. What will not be changed in 2026.

3. Which milestone in 10 captures each approved adoption.

4. Which risks are added to 05 and who owns them.

Status

Current recommendation status: Proposed for team review.

No implementation work from this document is approved until explicitly accepted in milestone planning.