PP SDLC - Process & Roles (v2)

Same as v1, but the Customer lane is split into three: Buyer (Mike) / Power user (Evan) / End customer (insured). Three signal types, three cadences, separate accountability lines. Continuous-discovery shading still applies across all phases.

Lane / Role
Discovery
Spec
Build
Test
Release
Always loaded
Standing context, not phase-gated
Loaded as agent context every session · Authored at project setup, updated when stack / conventions / registry change
Constitution (CLAUDE.md)
Tech stack, conventions, security & compliance posture, "done" criteria, agent ownership rules.
Authored once, revised when stack changes
Glossary
Domain terms: distribution hierarchy (IMO / FMO / BGA / MGA / writing agent), product types (FEX, IUL, GI), comp grid + levels, A2P, MCP, Hermes. Currently lives inside `right-quote-app-spec.md` §8.
Grows as new domain terms emerge
Prior-bug registry
Named regression tests preserved across tickets. The "prior fixes to preserve" field on every ticket reads from here.
Empty in greenfield, grows after each fix
Severity model
P0/P1/P2/P3 definitions, triage owner, escalation paths, log consumer. Required for Gate 2 bypass to be falsifiable.
Authored once, revised after each major incident class
Gate 0
PM owns
bypass: explicit Mario sign-off
Gate 1
PM + QA co-sign
bypass: P0 hotfix only
Gate 2
QA owns
bypass: severity P3 + log
Customer 1 of 3
Buyer
Mike at Safe Life · IMO / agency owner
Economic problem signal
"Give me something" pressure, IMO P&L
discovery note
Reviews scope, pricing, commercial fit
Sensitive-data sign-off (level-zero comp)
Status pings, demo asks
Demo + commercial readiness signoff
Renewal / invoice acceptance
Board-level reference
renewal
Customer 2 of 3
Power user
Evan, Richie, multi-product agents
Workflow pain
Ride-along, scripts, swivel-chair friction
discovery note
Pressure-tests AC ("would I use this?")
Script-integration concerns
Touches prototypes, quick reactions
Real-world edge cases surfaced
Beta tester on real calls
Pass / fail per scenario
beta signal
Daily-use adoption
Calls/day, completion rate
adoption
Customer 3 of 3
End customer
The insured · measurement-only, sensed via telemetry
Baseline telemetry
Safe Life Zendesk: call duration, completion, abandonment
baseline metric
No direct input mechanism
No direct input mechanism
No direct input mechanism
future: A/B lead-split cohort
Conversion outcomes
Time-to-quote, SMS-handoff success, sale rate
funnel
PM
Aaron
Validate problem, user, evidence
One-line problem statement
Drafts spec stack
App Spec = full PRD
+ Tickets per feature, concrete-value AC
TicketsAC
Defines outcome metric + telemetry per feature
metric spec
Unblocks agents on ambiguity
No new scope mid-build
Validates AC was the right AC
Owns outcome metric
Post-release loop back to Discovery
Engineering
Ben, Avi
Reviews architecture, stack call
Sizes "in-scope files"
PR review
Scope enforcement at merge
Fixes regressions
Deploy-agent approval
QA
Lead TBD
Co-signs Gate 1
Test design feasibility check
test design
Observes Build for AC drift
Spot-checks AC→agent prompt translation
AC execution + exploratory + regression
test execution
Severity-model triage on bugs
Agent fleet
Hermes framework · MCP orchestrator
MCP receives ticket
AC -> agent prompt translation
Implementation agent runs
Test agent writes & runs tests
unit/integration
Test agent runs regression
Deploy agent ships
Mario's baseline gate (March 2026 SDLC doc)
Aaron's proposed expansion
Customer-lane peak (named loud moment)
Spec artifact
Test artifact
Outcome artifact

Source baseline: Mario's SDLC Process Audit (March 2026). Expansions sourced from `research/2026-05-05-sdlc-critique-personas.md` synthesis + Product Coach critique of v1 (May 7).
Customer lane split addresses the v1 critique that conflated three distinct signal types under one label. Buyer (Mike) drives commercial signoff; Power user (Evan) drives workflow validation; End customer (insured) is measurement-only - signal flows in at Discovery (baseline telemetry) and Release (conversion outcomes), with no direct input mechanism in lead-based distribution because callers can't be hand-selected.
Future-state: A/B lead-split routing (random cohort assignment via Twilio or Zendesk routing) would create a real test cohort without violating the can't-pre-select constraint.
P0 = Priority Zero. Highest-severity incident class: production down, customer impact, all hands stop.
Agent-fleet roles (implementation / test / deploy) shown by function. Specific agent names within Hermes pending confirmation with Mario.