Skip to content

Product 100% Completion Plan

Status: active execution plan Last updated: 2026-05-28

This plan tracks the remaining work required to reach a strict 100% production completion bar before public launch.

Current intent:

  1. Close remaining readiness gaps and document evidence completely
  2. Do not initiate a public release while this plan is being finalized

1. Rule of the Plan

No public production release until every phase below is marked complete and all exit criteria are satisfied.

This document is a readiness and closure tracker. It is not a release trigger.

2. Completion Baseline (Current)

Reference gap sources:

  1. docs/TARGET_ARCH_PROGRESS.md
  2. docs/TARGET_ARCH_MERGE_READINESS.md
  3. docs/PRODUCTION_READINESS.md
  4. docs/PUBLIC_RELEASE_USE_CASES.md

Primary open gaps:

  1. External/manual branch/ruleset closure evidence attachment for release records
  2. Progressive SLO threshold hardening beyond current enforced baseline
  3. Broader same_tenant rollout beyond the current expanded baseline cohort
  4. Strategic architecture migrations (Temporal/Dagster-dbt/OPA productization depth)

3. Phased Execution

Phase A — Release Governance Closure

Objective:

  1. Ensure release decisions are enforceable by one deterministic gate.

Scope:

  1. Cross-workflow release readiness gate
  2. Evidence packaging and release notes requirements
  3. Ruleset operational closure checklist

Tasks:

  1. Implement and run release_readiness_gate job in smoke workflow
  2. Publish artifacts/release_readiness_gate_report.json on every run
  3. Promote release gate from informational to blocking in release branch policy
  4. Verify GitHub rulesets per runbook and attach evidence for release candidate

Done criteria:

  1. Release gate decision is go for candidate runs
  2. No high-severity gate failures
  3. Required branch protection evidence is attached

Status:

  1. Completed baseline (branch protection/required-check verifiers, release-gate integration, and ruleset runbook are in place; external GitHub UI proof remains the manual attachment path)

Phase B — Durability to Temporal-Grade Baseline+

Objective:

  1. Move from durability baseline to stronger orchestration semantics.

Scope:

  1. Workflow-history durability and replay semantics
  2. Restart continuity scenarios
  3. Deterministic checkpoint lineage verification

Tasks:

  1. Define canonical long-running workflow durability scenarios
  2. Add replay equivalence checks for restart and partial progress recovery
  3. Add durability regression suite for failure-injection paths
  4. Publish dedicated durability evidence artifact set in CI

Done criteria:

  1. Replay and restart suites pass under injected failure scenarios
  2. No semantic drift between original execution and replayed execution
  3. Durability evidence artifacts are generated automatically in CI

Status:

  1. Completed baseline (replay determinism, workflow version compatibility, checkpoint schema/provenance, and broader provenance coverage verifiers are integrated into runtime canary and enforced in the release gate with blocking checks)

Phase C — Unified Lineage for Contracts/Artifacts/Promotion

Objective:

  1. Build a first-class lineage model from source checks to release decisions.

Scope:

  1. Contract checks, governance reports, promotion reports, final gate report
  2. Single lineage graph or manifest generated per run

Tasks:

  1. Define lineage schema (inputs, checks, artifacts, decision edges)
  2. Generate lineage artifact from workflow outputs
  3. Validate lineage completeness in CI
  4. Link lineage artifact in release evidence package

Done criteria:

  1. Every required release decision has traceable provenance in one artifact
  2. Missing lineage edges fail CI
  3. Release evidence references one canonical lineage artifact

Status:

  1. Completed baseline (canonical release lineage artifact generation and contract verification now pass with a complete source-to-decision graph)

Phase D — DX SLO Hardening and Enforcement

Objective:

  1. Move from visibility to hard SLO enforcement for release confidence.

Scope:

  1. DX SLO thresholds
  2. CI trend SLO thresholds
  3. Release-blocking policy and temporary exception process

Tasks:

  1. Define target thresholds by stage (warn, soft fail, hard fail)
  2. Enable blocking mode for stable threshold set
  3. Add explicit exception record format for temporary waivers
  4. Add rollback guidance for repeated breaches

Done criteria:

  1. Thresholds are versioned and enforced
  2. Repeated breaches block release unless approved exception exists
  3. SLO policy is documented and auditable

Status:

  1. Completed baseline (versioned release-gate SLO policy and strict/transitional profiles implemented; critical CI trend SLO enforcement is active in CI)

Phase note:

  1. Exception governance format is now documented in docs/RELEASE_EXCEPTIONS_POLICY.md; threshold hardening/enforcement rollout remains pending.

Phase E — same_tenant Rollout Expansion

Objective:

  1. Extend same_tenant guarantees beyond current baseline capabilities.

Scope:

  1. Capability coverage expansion in registry
  2. Runtime test expansion for newly covered capabilities

Tasks:

  1. Select next capability cohorts by risk and channel exposure
  2. Add same_tenant constraints and tests for selected cohorts
  3. Run tenant isolation matrix for expanded set
  4. Update rollout progress and evidence docs

Done criteria:

  1. Expanded cohort coverage reaches agreed target set
  2. Tenant isolation tests pass for expanded cohort
  3. Documentation reflects expanded enforcement scope

Status:

  1. Completed baseline (same_tenant rollout expanded beyond the 5-capability baseline and tenant isolation matrix now covers the expanded cohort)

Phase F — Deployment DX Productization (Vercel-like Outcome)

Objective:

  1. Move from governance-only readiness to a developer-facing deployment product flow.

Scope:

  1. PR preview execution path for runtime verification
  2. Promotion automation across dev -> staging -> prod using immutable release bundles
  3. Fast rollback path with post-rollback verification
  4. Single deploy runbook for daily developer usage

Tasks:

  1. Define immutable release bundle contract (artifact + metadata + checksums + lineage ref)
  2. Add PR preview workflow that provisions a disposable runtime verification target
  3. Add promote workflow that consumes a signed/verified bundle and applies environment gates
  4. Add rollback workflow that restores last-known-good bundle and re-runs canary checks
  5. Publish one operator/developer runbook with preview, promote, and rollback commands

Done criteria:

  1. Every PR can produce verifiable preview evidence for runtime behavior
  2. Promotion to each environment is bundle-based and traceable
  3. Rollback to last-known-good can be executed in one workflow run
  4. Post-rollback canary and release gate return to go
  5. Developers can execute the complete flow without ad hoc manual steps

Status:

  1. Completed baseline (preview, promote, and rollback workflows plus immutable bundle tooling are implemented and lint-clean)

4. Global Exit Criteria (100% Claim)

A strict 100% completion claim is allowed only when all are true:

  1. Phases A-E are complete
  2. Phase F is complete
  3. Release readiness gate decision is go on candidate branch
  4. No unresolved high-severity findings in governance artifacts
  5. Ruleset/branch protection closure evidence is attached
  6. Public release use cases (UC-01 to UC-10) have complete evidence

5. Execution Order

Recommended order:

  1. Phase A
  2. Phase D (in parallel with A hardening)
  3. Phase C
  4. Phase B
  5. Phase E
  6. Phase F

Rationale:

  1. First lock release governance and decision quality
  2. Then harden operational reliability signals
  3. Then complete deeper architecture maturity and rollout scope
  4. Finally productize deployment UX on top of stable governance and reliability controls