GA readiness.

About this dashboard

Quick orientation (read this first)

This page tracks how ready bc-subscriptions is to ship. The product is split into ~28 epics (think: features). Each epic must pass 10 quality gates before it counts as "ready." The grid above shows which gates each epic has passed.

For a stakeholder skimming this in 30 seconds:

• The top-of-matrix counters (Green / Yellow / Red) summarize where the whole project stands.
• Each row is one epic. Each dot is one of its 10 gates.● Green = passed.● Yellow = partial / in progress.● Red = not started.
• The % green column at the right is the epic's overall score.
• Click an epic title to open its full audit document with the evidence behind every gate.

That's the whole dashboard. The rest of this page explains how it works and what each gate means.

What an "epic" is here

An epic is one product capability. Examples from the grid above: "Merchant install & BC app authentication" (Epic 1), "Charge scheduling & execution" (Epic 10), "Subscriber portal access & auth" (Epic 17). The full list lives in the Business Requirements Document (BRD).

Each epic also carries a risk tier (the small P0/P1/P2/P3 chip next to the epic name): P0 = critical (charge engine, payment, install); P1 = important (subscriber portal, dashboards); P2 = useful (advanced flows); P3 = nice-to-have. Higher-risk epics need stricter evidence to pass certain gates.

What each gate means (in plain language)

How are these 10 gates chosen? (vs industry standards)

Short answer: the 10-gate framework is project-specific (custom to bc-subscriptions), but every gate maps to a well-known industry concept. It's an opinionated synthesis, not a published standard.

The canonical gate-to-framework mapping + per-framework reference extracts live at docs/rag/sdlc-frameworks/ (filed via Hive #1244). The summary below is a snapshot; the corpus is the source of truth.

Where each gate comes from:

What's distinctive about this framework (vs typical 3-5 gate DoD checklists):

• 10 gates instead of 5 — Most teams collapse Gates 2/3/4 into one "Quality" gate, or combine Gates 6/7/9 into one "Documentation" gate. We split them so each can be measured independently.
• Evidence-based, not checkbox-based — Most DoD frameworks are "the team agrees this is done." Ours requires a specific committed artifact (test file, runbook, security doc) before a gate flips green.
• Two-phase signal, not self-reported — Most checklists collapse "evidence exists" and "evidence is good" into one signal. We split them: mechanical CI confirms artifacts are present (and caps at yellow); the operator audit confirms quality. Drift between the two layers is surfaced, not hidden.
• Gate 8 (Demo) is unusual — Marketing-readiness isn't a typical engineering gate. We include it because we ship as a marketplace app, so a feature isn't actually "shippable" until it can be demonstrated to merchants.

What this framework deliberately doesn't gate (some industry checklists do):

• Accessibility (WCAG) — Not currently gated. Covered partially via Gate 7 (merchant guide) but no explicit WCAG audit per epic.
• Internationalization (i18n) — Implicit (all admin strings flow through an i18n layer per ADR-0006) but not gated per-epic.
• Backwards compatibility — Tracked at the API-versioning level, not as an epic-level gate.
• Disaster recovery — Backup/restore testing is currently project-level, not gated per epic.
• Cost/economics — Per-epic cost dimensions are tracked (Gate 10 sub-criterion) but not a primary gate.

Alignment with BigCommerce Engineering DoD

Because bc-subscriptions ships as a BigCommerce marketplace app, BigCommerce's own Engineering DoD is the most-relevant framework — not just an industry reference. Every gate either aligns with a BigEng mandate, diverges deliberately, or carries an honest gap.

Full alignment matrix + per-gate analysis lives at docs/rag/sdlc-frameworks/bigcommerce-bigeng.md. Summary:

Distribution-model context for gaps:

• If we stay a marketplace app: WCAG 2.2 AA + localization gaps are LOW severity (marketplace apps aren't audited the way native features are).
• If we ever graduate to a native BC feature: WCAG, localization, merchant-facing audit log, phased rollouts, and postmortem cadence all become HIGH severity — they're hard requirements.
• If we ever expose a public API: BC's API DoD applies (p95 < 100ms, snake_case keys, cursor pagination, 1-year sunset rule for internal-with-path-to-public).

The full gate definitions + sub-criteria + rationale live in the Definition-of-Done methodology doc (v0.4).

How states are computed

Every gate is a two-stage check. A gate is green only when both stages pass:

1. Stage 1 — Mechanical check. Runs on every push to main. Boolean: passed or failed. For Gate 1 it reads _state.json and confirms every matching capability is COMPLIANT or MANUAL_REVIEW (no PARTIAL, no NON_COMPLIANT, no ABSENT). For Gates 2-10 it confirms the required artifacts exist on disk (runbook present, E2E spec present, etc.). Self-updates with every commit.
2. Stage 2 — Human attestation. A checkbox written to the audit doc frontmatter (attested: block). The operator reads the artifacts Stage 1 found, confirms they're real quality (not just present), and records the date + git commit they audited against. The attestation is bound to that commit: if any of the gate's dependent files change after the attestation, the checkbox auto-invalidates and the gate falls back to yellow with a ↻ re-attestation indicator until checked again.

Color computation:

• Green — Stage 1 ✓ + Stage 2 ✓ (attestation fresh: dependent files unchanged since checkbox).
• Yellow — Stage 1 ✓ + Stage 2 ☐ (no attestation) or Stage 1 ✓ + Stage 2 ↻ (attestation stale because files changed).
• Red — Stage 1 ✗ (required artifacts missing). Stage 2 doesn't matter — gate is red until the mechanical check passes.
• ↻ badge — gate is yellow specifically because the attestation went stale (mechanical passes, files moved); the operator needs to re-check the box.

The header counters break the 280 cells down by the four combinations of the two booleans. The actionable signals are Mech ✓, awaiting attestation (Stage 1 done; needs a human checkbox) and ↻ Needs re-attestation (the file the attestation depended on has been edited since).

Glossary

Technical terms used above and in the audit docs, for non-developer readers:

BigEng / BigCommerce Engineering DoD

BigCommerce's internal Definition-of-Done for engineering teams. Mandates include WCAG 2.2 AA accessibility conformance, localization for storefront + control panel strings, <2s page load (or <200ms TTFB), audit-log events for all merchant-facing actions, fault tolerance / graceful degradation, deployments controlled by experiment flags with phased rollouts, postmortem within ~2 business days, and use of BigDesign UI components.

STRIDE

A standard security threat-modeling framework developed at Microsoft. Acronym for six attack categories: Spoofing (pretending to be someone else), Tampering (modifying data illegitimately), Repudiation (denying an action you took), Information disclosure (leaking data), Denial of service (crashing the system), Elevation of privilege (gaining permissions you shouldn't have).

k6

An open-source load-testing tool from Grafana Labs. You write a script that simulates many concurrent users; k6 runs it and reports response-time statistics. Used for Gate 4 to prove the feature handles realistic traffic.

p95 latency

"95th percentile response time." If we say "p95 ≤ 800ms," it means 95% of requests complete in 800 milliseconds or less. Industry-standard way to talk about performance because the slowest 5% often matter most for user experience.

PCI / GDPR / SOC2

Three compliance frameworks bc-subscriptions must respect. PCI DSS (Payment Card Industry Data Security Standard) regulates how systems handle credit card data. GDPR (EU General Data Protection Regulation) governs personal data handling and subscriber rights (deletion, export). SOC2 (Service Organization Control 2) is an audit framework for security controls — used by enterprise customers to vet vendors.

SRE / SLI / SLO

SRE = Site Reliability Engineering, the discipline Google formalized for operating production services. SLI = Service Level Indicator (a metric you measure, e.g., "% of requests under 500ms"). SLO = Service Level Objective (the target for an SLI, e.g., "99.5% under 500ms"). Defining SLIs/SLOs before launch is the SRE prerequisite for production readiness.

Definition of Done (DoD)

An agile concept: the shared checklist a team uses to decide if work is actually finished. Most teams have 3-7 items; ours has 10 gates and a heavier evidence requirement.

ISO/IEC 25010

The international standard for software quality attributes. Lists 8 top-level dimensions including reliability, performance, security, maintainability, and usability. Our 10 gates map to several of these dimensions.

OWASP ASVS

Application Security Verification Standard, published by the Open Web Application Security Project. A checklist of security controls organized by risk level. Our Gate 3 (Security reviewed) implicitly references ASVS-level controls.

ITIL

Information Technology Infrastructure Library, the most widely-adopted IT service management framework. Includes change-management discipline relevant to our Gate 10.

ADR (Architecture Decision Record)

A short document capturing one significant architectural decision (e.g., "we chose Cloudflare Workers over AWS Lambda because…"). ADRs live in docs/decisions/ and are numbered sequentially (ADR-0001, ADR-0002, …).

BRD (Business Requirements Document)

The product spec. Defines every epic and its acceptance criteria. BRD.md in the repository root.

Runbook

The on-call playbook for when something goes wrong in production. Lists known failure modes, how to diagnose them, and what to do about each.

Webhook

A way for two systems to notify each other automatically. Example: when a subscriber checks out on BigCommerce, BC sends a webhook to bc-subscriptions saying "this order just happened," and bc-subscriptions creates the subscription record.

OpenAPI

An industry-standard format for documenting an API. Defines every endpoint, what it accepts, and what it returns.

End-to-end (E2E) test

An automated test that drives the actual user interface (clicks buttons, fills forms) and verifies the whole flow works. Heavier than a unit test but catches things unit tests miss.

Sandbox-scenario CI

An automated test that runs nightly against a real BigCommerce test store (called a "sandbox"). Catches integration issues that mocked tests miss. CI = "Continuous Integration" = the automated build/test pipeline.

Cloudflare Workers / D1 / KV

Cloud infrastructure components bc-subscriptions runs on. Workers = the code execution platform. D1 = a SQL database. KV = a key-value cache.

Phase 1a / 1b / 2 / 3

The cohorts (groups) of epics, ordered by delivery sequence. Phase 1a = foundation features. Phase 1b = lifecycle features. Phase 2 = full feature set. Phase 3 = advanced. Phasing per ADR-0021.

Wave 1 / Wave 3 / cold-read

Project-specific terminology for the close-out methodology. Each epic goes through multiple "waves" of work: Wave 1 lands the artifacts; Wave 3 is when an independent reviewer cold-reads the work to catch drift before sign-off.

Stage 1 / Stage 2 / re-attestation

Every gate is two booleans. Stage 1 is the automated check — did the required artifacts exist as of the last push? Boolean, computed deterministically. Stage 2 is the human checkbox — does a person attest the artifacts are good (not just present)? Bound to a git commit. When the dependent files change after the attestation, the checkbox auto-invalidates → "needs re-attestation" — not because anyone made a mistake, but because the evidence beneath the audit shifted.

For developers / engineering reviewers

Methodology references for the gate definitions, derivation logic, and walk-back procedures:

• epic-definition-of-done.md — full 10-gate spec, v0.4 (sub-criteria, evidence requirements, edge cases)
• ADR-0021 — why epics are sequenced into these specific phase cohorts
• METHODOLOGY.md — dual-track agile, trust axioms, derive-first principle
• Trust-restoration lessons (2026-05-13) — why we derive evidence mechanically rather than trusting prose audits