Audit DevClaw dev-to-production lifecycle for missing phases, artifacts, environment gates, and rollback semantics

[fujiwaranosai850]

Problem

The current UAT feature discussion exposed a larger concern: DevClaw may still be under-modeling the path from completed development work to actual production acceptance.

A concrete miss already surfaced:

• first-class UAT likely should not simply sit after Testing without also modeling how a concrete release candidate / promoted build / acceptance environment becomes available for UAT

That suggests broader lifecycle blind spots may still exist beyond UAT alone.

Why this issue exists

The current workflow model is strong on work execution phases such as:

• implementation
• review
• testing

But production delivery is often a broader pipeline involving:

• artifacts/builds
• promotion between lanes or environments
• release-candidate preparation
• stakeholder acceptance
• rollback/demotion after a promoted candidate fails
• post-release verification

If those are left implicit, DevClaw risks making the workflow look complete while still missing critical real-world release steps.

Audit goals

Perform a structured audit of the full development-to-production lifecycle and identify which phases or contracts should be first-class in DevClaw versus optional project-specific overlays.

Specifically audit for gaps around:

1. Release candidate / promotion layer

   • how something becomes the exact candidate for UAT or release
   • whether a first-class promote/release/RC phase is needed between Testing and UAT

2. Artifact provenance

   • how DevClaw should model the exact build/package/image/commit under evaluation
   • whether acceptance and release phases must point to a concrete candidate artifact

3. Environment semantics

   • dev vs test vs staging vs UAT vs prod
   • whether workflow phases should distinguish environment movement explicitly

4. Approval gates

   • technical approval vs release approval vs stakeholder acceptance
   • which of these should be human-only, optional, or agent-supported

5. Rollback / demotion behavior

   • what should happen if a candidate fails at UAT or after promotion
   • whether rollback is a first-class workflow concept or lane-specific policy

6. Deploy-time / migration / operational steps

   • steps that can fail after code review/testing but before actual release acceptance

7. Post-release validation

   • whether DevClaw should model production verification separately from release completion

8. Project-generic vs project-specific boundaries

   • which lifecycle concepts belong in the core workflow product
   • which should remain configurable overlays or runbook-driven release lanes

Expected outcome

• a mapped lifecycle from development through production acceptance
• a list of missing or under-modeled lifecycle concepts
• recommendations for which concepts should become first-class workflow phases
• recommendations for which concepts should remain optional or project-specific
• clear guidance on how this audit affects Add first-class UAT phase support to DevClaw workflow #207 and related workflow feature design

Relation to existing work

• #207 is the root tracker for first-class UAT phase support
• #212 is architect research for UAT phase design
• this issue is broader: it audits the full dev-to-prod lifecycle so we do not solve UAT in isolation while still missing adjacent release-model concepts

[fujiwaranosai850]

🎛️ ORCHESTRATOR: Spawning architect research as a child lane so #214 stays the canonical root tracker for the broader lifecycle audit.

Research issue:

• #215 Research: Audit DevClaw dev-to-production lifecycle for missing phases, artifacts, environment gates, and rollback semantics #214 DevClaw dev-to-production lifecycle audit
• Research: #214 DevClaw dev-to-production lifecycle audit #215

Intent:

• map the full lifecycle from development through production acceptance and rollback
• identify which phases/semantics should be first-class versus optional overlays
• create concrete follow-up implementation tasks if the architect concludes they are needed