ERO Platform Governance & Tooling Strategy

1. Azure DevOps (ADO) Epic Mapping & Hierarchy

To maintain complete lifecycle traceability, the ERO backlog is organized hierarchically:

• Epic: Captures broad product capabilities and major lifecycle releases.
• Feature: Encapsulates specific deployable services, pipelines, or modules.
• User Story: Defines functional user requirements using a standard BDD template.
• Task: Specifies the precise implementation steps required to fulfill a story.

Master Backlog Mappings

• Epic 1: PWA Mobile Core & Offline Engine (ID: #40)
  • Feature 1.1: Schedule Hydration & Local Cache (ID: #41)
• Epic 2: Cloudflare Edge API & SQLite D1 Persistence (ID: #43)
  • Feature 2.1: Master Schedule & User Preference Endpoints (ID: #44)
• Epic 3: Infrastructure as Code (IaC) & Subscription Governance (ID: #46)
  • Feature 3.1: Multi-Environment Azure Landing Zone (ID: #47)
• Epic 4: Platform Developer Experience (DX) & Machine Onboarding (ID: #49)
  • Feature 4.1: Automated Workstation Provisioning (ID: #50)
• Epic 5: Identity & Access Management (IAM) & Social Federation (ID: #52)
  • Feature 5.1: Entra External ID (CIAM) Integration (ID: #53)
  • Feature 5.2: Social Identity Federation (CIAM) (ID: #34)

---

2. BDD User Story Standard

Every User Story in ERO must follow a strict Behavior-Driven Development (BDD) structure to ensure automated validation:

As a <role>
I want <action>
So that <benefit>

Acceptance Criteria:
Given <initial state / context>
When <action / event occurs>
Then <expected result / system state change>

Acceptance criteria are parsed programmatically by agent tools and populated directly into ADO work item descriptions to guarantee alignment between code requirements and backlog records.

---

3. Docs-as-Code ADO Wiki Strategy

All platform documentation (SADs, contracts, setup guides) is stored directly within the /docs directory of the event-route-optimiser Git repository.

• Single Source of Truth: The codebase is the master ledger of architecture design.
• Automated ADO Wiki Integration: The directory is published to the Azure DevOps Wiki via Publish code as wiki referencing the main branch. Any documentation updates pushed to Git are instantly rendered on the ADO Wiki without duplicate manual curation.

---

4. 3-Tier Support Triage Funnel

For operational support, issues are routed through a 3-tier triage model to maximize engineering focus:

graph TD
    A[Incoming Ticket] --> B[Tier 1: Triage & Standard Scripts]
    B -->|Resolved| C[Close Ticket]
    B -->|Complex / Unknown| D[Tier 2: Escalation & Root Cause Analysis]
    D -->|Resolved / Workaround| C
    D -->|Platform Bug / Change| E[Tier 3: Platform Team & Bug Fix]
    E -->|Release Deploy| C

Funnel Definition

• Tier 1 (Frontline Support): Handles user requests, runs basic verification scripts (e.g. bootstrap.ps1 checks), and matches issues against known troubleshooting runs.
• Tier 2 (Engineering Operations): Performs deep diagnostics (e.g. inspecting Cloudflare Worker logs, query performance traces, database connection states).
• Tier 3 (Core Platform Team): Resolves underlying platform bugs, executes Bicep updates, and pushes patches to the main code branch.