Product Management - SimpleStruc<i>t</i>

Product Lineage — Five Generations, One Codebase

ConstructiVision has run continuously in commercial use since the early 2000s. The modernization effort is not a rewrite — it is a disciplined packaging and deployment upgrade of a proven codebase, preserving the production-validated AutoLISP/DCL that field engineers rely on while bringing deployment, installation, and OS compatibility to 2026 standards.

v3.60 Legacy archive — read-only reference

src/x86/v3_60/ — DOS-era build, InstallShield installer, 32-bit only

Original shipping product. Preserved for archaeology. Source of the v7.0 build lineage. Never modified.

v7.0 Production master — XP golden oracle

src/x86/v7.0(patch)/ — compiled VLX bundle, deployed on XP SP3

The currently-shipping product on customer machines. VLX binary contains compiled source that does not exist in this repository — the most critical gap in source archaeology. A pristine unmodified snapshot of this state is preserved as the golden oracle and is never touched.

PB11-00 Production Build 11 — read-only baseline

src/x32/PB11-00x32/ — 134 files, the v11 source reference (closest available to v7.0 VLX)

Used as the reference for TB11-01 development and as the comparison target for XP validation testing. Must never be modified — it is the source truth baseline for the diff-based quality process.

TB11-01 ← ACTIVE DEVELOPMENT

src/x32/TB11-01x32/ + src/x64/TB11-01x64/ — 126 .lsp + 44 .dcl files; deployed to all test and alpha lab nodes

The active test build. Receives all code changes. Deployed nightly via Git sparse checkout to all test and alpha VMs. Validated against the XP golden baseline after every meaningful change cycle.

v11-Release ← TARGET: March 2026

ZIP distributable + self-configuring installer; supports Win10/Win11 x32 and x64

When TB11-01 passes all release gate criteria (see below), it ships as the v11 distributable. No code rewrite — same AutoLISP/DCL codebase that has run for 20+ years, now with a reliable install experience and Win10/Win11 compatibility confirmed.

v12-Beta ← PUBLIC BETA: October 2026

Web application (no AutoCAD required) + AI-assisted design features

v12 introduces two major platform expansions: a web-based version that runs the full ConstructiVision panel design and documentation workflow in any modern browser — no AutoCAD installation needed — and AI-assisted workflows including intelligent panel design suggestions, automated embedment placement, and smart materials optimization. The AutoCAD add-in build continues alongside the web version. Beta access by request: chad@simplestruct.com.

Stakeholder Map

ConstructiVision has a small, clearly defined stakeholder population. Every VM in the test lab corresponds to a specific role in the product management cycle — alpha testers receive exactly the same nightly deployment infrastructure that the dev lab uses.

Product Owner

Product Owner / Lead Developer

Product strategy, architecture decisions, DFMEA sign-off, release gate authority. Defines AI-assisted development policy and governs all automated tooling within the project.

Alpha Tester

Alpha Tester A

Win10 x32 field environment. Real-world usage feedback from active construction project work. Receives nightly builds via sparse git checkout + NTFS junction. Issues raised during field testing flow into GitHub Issues with DFMEA linkage required.

Alpha Tester

Alpha Tester B

Win10 x32 independent validation path — running the same build as Alpha Tester A on a separate machine. Cross-tester disagreements flag edge cases that single-tester workflows miss.

Test Lab

Win10 x32 Test Node

Primary automated test target. Runs AutoIT validation suite on every meaningful build change. OCR comparison against the XP golden baseline. Primary Win10 platform verification.

Test Lab

Win10 x64 Test Node

64-bit validation. Tests Wow6432Node COM path, 64-bit registry redirection, and AutoCAD 2026 compatibility path. Catches x64-specific deployment surprises before alpha rollout.

Test Lab

XP SP3 v11 Reference Node

XP compatibility validation. V11 reference build against the PB11 baseline. Rebuilt by comparing against the golden XP oracle — the reconstruction process itself is validated.

Untouchable Oracle

XP SP3 v7.0 Golden Node

The pristine 2008 production environment. MASTER COPY. Never modified. Defines what "correct" means for every OCR comparison. No development activity permitted — ever.

Alpha Tester Feedback Loop

Alpha testers receive the same build that the dev lab validates — automatically, nightly, with no manual deployment step. The loop from tester observation to shipped fix is five steps, three of which are automated.

Step 1

Code committed

Developer pushes to main; changelog auto-generated by GitHub Actions

→

Step 2 — Auto

CI validates

AutoIT + OCR runs on lab VMs against the golden XP baseline at ≥95% match

→

Step 3 — Auto

Nightly pull

22:00 scheduled task on alpha tester machines pulls latest main via sparse checkout

→

Step 4

Tester finds issue

Field usage produces unexpected result; tester reports via GitHub Issue with screenshot

→

Step 5

Bug filed + fixed

DFMEA ID added to issue; fix committed to TB11-01; loop restarts at Step 2

Turn-Around Time for Alpha Testers

A bug reported by 23:00 reaches a committed fix the same night (AI-assisted development). The fix is on the tester's VM by 22:00 the following night. End-to-end: under 24 hours from field report to deployed fix, with no manual intervention in the deployment step. This is only possible because the deployment infrastructure is entirely automated via Git sparse checkout and a scheduled pull task.

Release Gate Criteria — What Must Be True Before v11 Ships

The v11 distributable targets March 2026. The gate is a set of measurable pass/fail conditions — not a calendar date. Every condition maps to a verifiable test result or a version-controlled document state. "Seems fine" and "I think it works" are not gate conditions. Once v11 ships, the gate framework rolls forward to v12 beta (October 2026) with new criteria covering web deployment and AI feature stability.

AutoIT validation Full suite passes on Win10 x32 and Win10 x64 lab nodes — OCR comparison ≥95% character match against the XP golden baseline for all 11 screenshots per run
Status: progcont routing partially functional — reconstruction of VLX-mode routing in source mode in progress
progcont routing All 13 progcont values produce the correct downstream dialog on Win10 x32 and x64 — verified by au3 menu macro simulation
Status: source-mode routing reconstruction (Bug 18) not yet complete
Weld dialog wc_dlg.lsp passes full OCR validation on all platforms — hardware combination validation active, DFMEA FM-07 at RPN < 200
Status: RPN 360 — required action: hardware combination UI controls not yet shipped
Registry deploy Configure-ConstructiVision.ps1 creates all required keys; verified on clean VM — all Bugs 19, 21 controls in place
Status: PASS — confirmed across all test lab nodes
Installer Self-configuring distributable installs on a clean Win10 x32 and x64 VM with no manual registry editing
Status: not yet started — packaging phase begins after TB11 passes all AutoIT tests
DFMEA clear No open DFMEA entries with RPN ≥ 200 without a documented Recommended Action marked complete
Status: RPN 500 (help system) and RPN 360 (weld dialog) both have open actions
Bug tracker All bugs in doc 32 at status ✅ Fixed, or explicitly deferred with documented rationale and DFMEA entry updated
Status: 21 bugs logged, majority fixed; progcont reconstruction (Bug 18) and weld controls (Bug-related) open
Alpha sign-off Both alpha testers confirm core panel book workflow operates correctly on their machines
Status: alpha VMs receive nightly builds; formal sign-off pending post-routing fix

1/8

Release gate conditions currently passing

3/8

Partial / in-progress gate conditions

4/8

Gate conditions not yet started

Zero-Touch Deployment to All Stakeholders

Every stakeholder — from the dev lab to the alpha testers — receives code updates through the same infrastructure. There are no "alpha builds" produced separately from the dev builds. What ships to the dev lab ships to the alpha testers. This eliminates an entire category of "it works in the lab but not on the customer's machine" failures.

x32 nodes

src/x32/TB11-01x32/ src/Project Files/

Junction: C:\Program Files\ConstructiVision → C:\Repos\Constructivision\src\x32\TB11-01x32

x64 nodes

src/x64/TB11-01x64/ src/Project Files/

Junction: same pattern, x64 path

Trigger

git push main

Nightly scheduled task on each VM pulls at 22:00 via git-pull.bat. Manual pull available anytime.

Credentials

ed25519 deploy key

Read-only SSH deploy key per VM. No password. No write access to repo. Compromised VM cannot push.

The Deployment Model Is Already Production-Grade

The nightly sparse-checkout pull model in use today is essentially what customer delivery will look like — except the final step will be an installer that sets up the junction, configures the registry, and schedules the pull task automatically. The infrastructure is tested daily. The installer is the only remaining gap between the alpha deployment model and a first-customer deployment.

GitHub Issues — The Single Source of Truth for Work Items

Feature requests, bug reports, tech debt, and deployment tasks all flow through GitHub Issues. The issue template is not optional — the DFMEA Reference section is a required field that connects every work item to the risk register. This creates the bidirectional traceability chain that makes risk coverage measurable rather than aspirational.

// Issue filing guarantee

Every GitHub Issue MUST have:
- Title: [Bug #N] or [Feature] prefix
- ## DFMEA Reference section with DFMEA ID + RPN
- Labels: severity + status + dfmea ID

Every closed issue MUST have:
- Commit hash of the fix
- Updated DFMEA Detection (D) rating if fix adds a control
- Confirmed by: OCR comparison result citing the specific screenshots

// An issue that closes without these is not closed — it's abandoned.

Why This Matters for Product Management

Standard product management assumes the feature backlog and the risk register are separate documents maintained by separate teams. When they are structurally the same graph — every feature generates DFMEA rows, every bug links back to a DFMEA row — the product manager can answer questions that are otherwise impossible: What fraction of our known risk surface has been covered by completed work? Which open features carry the highest pre-validated RPN? Which closed bugs improved the overall RPN distribution? The ConstructiVision DFMEA/issue system makes these questions answerable from version-controlled data.

Framework: DFSS CDOV — What Phase We're In

The project follows the Design for Six Sigma CDOV process (Concept → Design → Optimize → Verify) from Creveling, Slutsky & Antis (2003). The current state, with TB11-01 in active validation testing, corresponds to the Verify phase — validating that the designed and optimized build meets all critical-to-function requirements before release.

Concept — product definition, use case analysis, DFMEA initial rows (complete)

Design — source archaeology, VLX routing reconstruction, deployment architecture (largely complete)

Optimize — TB11 regression fixes, progcont routing, registry hardening, Win10/x64 compatibility (in progress)

Verify — AutoIT+OCR multi-VM validation, DFMEA coverage measurement, alpha tester sign-off (active)

Risk & DFMEA → Quality & Validation → Deployment Pipeline →

SimpleStruct — Powered by ConstructiVision | Quality-First AI-Assisted Engineering