Release and Distribution Plan (App Store First)

Last Updated: March 10, 2026 Decision: Autodesk App Store .bundle is the primary release path. MSI installer work is contingency-only.

March 23 Rebaseline

This release plan is synchronized to:

  1. 00-vision-and-success-criteria.md for canonical strategy/status.

  2. 03-phase-plan-p0-p5.md for execution and gate sequencing.

  3. 37-cv-web-vs-pascal-editor-comparison-strategy.md for architecture direction and non-goals.

Current release truth:

  1. App Store .bundle remains the primary distribution channel.

  2. WiX/MSI remains contingency-only.

  3. Release progression is gated by active validation and routing-blocker closure.

Active Release Dependency (Program Routing Blocker)

Current release sequencing includes an active dependency tied to routing parity and validation closure. Release candidate promotion should only proceed when this dependency is closed and documented through the defined gate process.

This dependency must be reflected consistently in:

  1. 04-2026-timeline-weekly.md

  2. 10-milestones-dashboard.md

  3. 05-risk-register.md

Executive Decision

ConstructiVision distribution is now centered on Autodesk App Store publishing.

  • Primary channel: Autodesk App Store package (.bundle + PackageContents.xml)

  • Primary product form: existing validated VLX-based runtime for desktop AutoCAD workflows

  • Primary quality bar: stable install/use experience and clear customer value

  • Contingency path: MSI installer only for enterprise exceptions that cannot use App Store

This update replaces prior WiX-first assumptions and aligns release planning with:

  • docs-developer/AutoDesk/app-store-getting-started-guide.pdf

  • docs-developer/AutoDesk/Autodesk App Store.pdf

Distribution Objectives

  1. Ship a review-ready Autodesk App Store package with complete metadata and support materials.

  2. Prove release stability with repeatable OCR-backed validation on the VM matrix.

  3. Maintain a clean fallback path for non-App Store enterprise deployments.

  4. Preserve traceability from bug discovery to DFMEA and release gate decisions.

Current State

  • Legacy compatibility and deployment archaeology are complete enough for release packaging.

  • TB11 source-mode bug campaign is active and tracked in 32-tb11-bug-tracker.md.

  • App Store submission artifacts are partially ready (code, docs, validation outputs) but not yet assembled into a final package.

  • Licensing/metering implementation is intentionally out of scope for this build (documentation-only architecture).

  • MSI/WiX strategy is intentionally deferred.

Target Distribution Model

Primary Channel: Autodesk App Store

  • Package format: .bundle

  • Manifest: PackageContents.xml

  • Submission model: iterative review cycles with potential rejection and resubmission

  • Success criteria: customer value, stability, and a low-friction install/use experience

Secondary Channel: Controlled Direct Distribution (Contingency)

  • Used only when a customer environment cannot consume App Store packages

  • Must use the same release-quality gates as App Store builds

  • Must not become the default path without explicit decision update in this document

Legacy VM Access

  • Purpose: alpha/beta validation and support triage

  • Not a long-term production distribution channel

App Store Readiness Requirements

The following is required before submission:

  1. Product package

  • .bundle structure validated

  • PackageContents.xml present and accurate

  • Runtime modules and resources correctly referenced

  1. Product quality

  • No known crash/blocker in core workflows

  • No harmful or destabilizing runtime behavior

  • Stable startup, menu load, and command routing on supported targets

  1. Listing materials

  • Clear product description and value proposition

  • Screenshots and release notes aligned to shipped build

  • Support contact path and support documentation

  1. Legal and policy materials

  • EULA

  • Privacy policy URL (if applicable)

  • Terms and publisher details as required by App Store submission fields

  1. Release evidence

  • OCR-based validation report against golden baseline

  • Bug/DFMEA cross-reference updated

  • Explicit go/no-go sign-off note

Release Gates

A release candidate is promoted only when all gates pass.

Note

Parity Prerequisite (Doc 45). Before any release gate is evaluated, the 45-tb11-parity-test-plan scorecard must show ≥95% of 76 testable items at PASS/PARTIAL. G1 (Menu Routing) and G4 (Data Persistence) are zero-FAIL gates — any failure in those gates blocks release regardless of overall percentage. The M2 parity gate (May 19–26, 2026) must close before release gate evaluation begins.

Gate 1: Build Integrity

  • Bundle contents match intended version

  • Manifest references correct modules and metadata

  • No missing runtime dependencies in package

Gate 2: Functional Validation

  • Mandatory OCR workflow executed for required scenarios

  • No instant-fail OCR indicators in target flows

  • Source/VLX behavior differences documented and accepted

  • Doc 45 parity scorecard satisfied (≥95% PASS/PARTIAL across 76 testable items; G1 + G4 zero-FAIL)

Gate 3: Stability and Safety

  • No open critical issues for release workflows

  • High-severity items have either fix or explicit waiver rationale

  • Startup, routing, and file-open paths are verified

Gate 4: Support Readiness

  • Known issues list updated

  • Rollback or downgrade path documented

  • Support handoff notes prepared

Gate 5: Submission Readiness

  • Listing content finalized

  • Legal/policy links valid

  • Submission checklist complete

Submission Workflow

  1. Freeze release candidate branch or commit window.

  2. Build and validate .bundle package.

  3. Run mandatory OCR validation and publish report to reports/.

  4. Update:

  • 32-tb11-bug-tracker.md

  • DFMEA links

  • release notes/version metadata

  1. Prepare App Store listing payload and screenshots.

  2. Submit package.

  3. Triage review findings and resubmit as needed.

Versioning and Channels

Channel Definitions

  • internal: engineering-only, may be unstable

  • beta: controlled external testing

  • rc: feature frozen, bug-fix only

  • ga: production submission build

Version Format

  • MAJOR.MINOR.PATCH[-TAG]

  • Examples: 4.0.0-beta1, 4.0.0-rc1, 4.0.0

Security and Compliance

Code Signing

Code signing remains required for trust and enterprise acceptance.

  • Minimum target: OV code signing for GA

  • Optional upgrade: EV if SmartScreen reputation latency becomes a delivery blocker

App Store Policy Alignment

The release must remain aligned with App Store quality expectations:

  • Customer value and clarity

  • Stable behavior under normal use

  • No harmful material or unsafe behavior

  • Submission artifacts that accurately describe delivered behavior

Monetization and Entitlement Architecture

Scope note: This section defines planned architecture only. No runtime licensing, entitlement enforcement, or pay-per-drawing metering is implemented in the current build.

Proposed Commercial Model

  • App Store listing: free install with time-limited trial (target: 15 days)

  • Post-trial access: controlled by ConstructiVision IDN licensing service

  • Billing model: pay-per-use metering (per drawing processed) as primary revenue model

  • Optional add-on: monthly seat subscription for enterprise customers that cannot operate on pure metered usage

Why Hybrid Is Required

  • Autodesk App Store is expected to handle distribution and discovery well, but usage-level metering and per-drawing billing are likely outside native store controls.

  • ConstructiVision therefore needs app-store-compatible packaging plus an external entitlement/metering backend for monetization logic.

Runtime Enforcement Flow (Target)

  1. User launches ConstructiVision from App Store-installed package.

  2. Plugin resolves Autodesk identity context where available and requests entitlement from IDN service.

  3. IDN returns one of: trial-active, paid-metered, paid-seat, expired, blocked.

  4. Command entry points enforce status:

  • trial-active or paid status: allow command execution

  • expired or blocked: disable write actions and show upgrade/renew path

  1. For billable commands, plugin logs drawing usage event and IDN records metered unit.

Implementation status: Deferred to next build.

Metering Unit Definition (Draft)

  • Unit: one completed drawing workflow (to be finalized in pricing policy)

  • Event capture minimum fields: user/account ID, drawing identifier hash, command type, timestamp, build version

  • Anti-double-charge guard: idempotency key per user + drawing + operation window

Critical Unknowns to Validate With Autodesk

  • Whether Autodesk SSO and App Store entitlement APIs can be used as a trusted upstream signal for subscription/trial status

  • Whether trial eligibility is restricted across related Autodesk accounts or only per account

  • Whether a paid AutoCAD subscription is required for download/install or only for certain product classes

  • Whether App Store policy permits redirecting expired users to an external billing/entitlement service

Until these are confirmed by official Autodesk publisher guidance, ConstructiVision assumes abuse is possible and keeps R24 active.

Next-Build Release Gates for Licensing (Deferred)

  • Licensing gate: startup and command-level entitlement checks pass in trial/paid/expired states

  • Billing gate: per-drawing metering events are recorded once and reconciled against backend logs

  • Abuse gate: repeated trial creation patterns are detected and flagged by telemetry rules

  • UX gate: expired/trial-limit states show clear, non-blocking upgrade guidance

These gates are not required for the current release candidate because licensing is not shipping in this build.

2026 Delivery Plan (Rebased)

Q1-Q2 2026: Validation and Hardening

  • Continue TB11 stabilization and OCR-verified regression control

  • Complete app-store-specific packaging checklist and manifest hardening

  • Finish alpha/beta feedback loop and bug triage

  • Freeze licensing to architecture/spec documentation only for this build

Q3 2026: Submission Preparation

  • Finalize .bundle packaging pipeline

  • Finalize listing assets, legal artifacts, and support materials

  • Execute RC validation and go/no-go process

  • Start implementation of IDN-backed entitlement + pay-per-drawing metering in next build cycle

Q4 2026: Publish and Operate

  • Submit and iterate through review cycles

  • Launch GA via App Store once approved

  • Monitor support load, crash/blocker reports, and update cadence

Metrics

Track these metrics per release cycle:

  • Validation pass rate (OCR-based)

  • Open critical/high issue count at release cut

  • Submission cycle time (submit to approval)

  • Post-release support ticket rate

  • Regression rate by workflow area

Risks and Mitigations

  1. App Store review delays

  • Mitigation: submit early with complete artifacts and leave schedule buffer for rework.

  1. Packaging drift between tested and submitted build

  • Mitigation: hash/version check and release freeze gate.

  1. False confidence from automation logs

  • Mitigation: OCR remains mandatory source of truth for UI validation.

  1. Legacy platform edge cases

  • Mitigation: keep VM comparison baseline and document accepted constraints.

Contingency: Enterprise MSI Path (Deferred)

MSI/WiX work is not active.

It may be reactivated only if:

  • a paying enterprise customer requires managed MSI deployment, and

  • App Store delivery is demonstrably blocked for that customer.

If reactivated, MSI deliverables must still satisfy the same release gates defined above.