Implement Deployer role and align delivery-phase code with documented Deployer contract

[fujiwaranosai850]

Follow-up from #232 and #218.

Overview

Implement the documented Deployer role so the codebase matches the final operator documentation and Deployer contract.

This work should align the workflow, prompt scaffolding, role registry, bootstrap surfaces, and delivery-phase execution model with the documented target shape.

Known spec gaps to resolve during implementation or operator clarification

Before or during implementation, resolve these explicit contract questions:

1. Does the Deployer own both promotion and acceptance states, or only promotion?

   • Current code still models promotion under reviewer-owned states and acceptance under tester-owned states.
   • Current docs now describe a dedicated Deployer prompt surface.

2. What are the Deployer completion results?

   • Examples: done/blocked, or a richer state-specific set.

3. What level model should the Deployer use?

   • Examples: junior/senior like reviewer, or junior/medior/senior like developer/tester.

If these are not already fully specified by the operator before coding starts, stop and refine the issue with the chosen answers before locking the implementation.

Implementation Checklist

Phase 1: Role model and prompt wiring (~1-2 days)

• Add a first-class deployer role to the role registry in lib/roles/registry.ts, including display name, levels, models, completion results, emoji, and session key pattern.
• Update any role-derived helpers and tests so deployer is treated like other first-class roles.
• Ensure default prompt loading and scaffolding consistently include defaults/devclaw/prompts/deployer.md and project-level prompts/deployer.md.
• Update any role lists, prompt trees, or scaffold logic that still assume only developer/reviewer/tester/architect.

Phase 2: Workflow and delivery-state ownership (~2-3 days)

• Align workflow typing and defaults in lib/workflow/defaults.ts, workflow-related types, and supporting helpers so delivery states use the intended Deployer role ownership.
• Update routing/dispatch logic in lib/dispatch/index.ts, lib/services/tick.ts, and any delivery helpers so delivery-phase work dispatches to the Deployer role rather than legacy reviewer/tester ownership where the spec now says otherwise.
• Reconcile queue/active state ownership for To Promote, Promoting, To Accept, and Accepting with the chosen Deployer contract.
• Update any assumptions in workflow label resolution, completion rule derivation, or heartbeat delivery transitions that still hardcode reviewer/tester ownership for delivery phases.

Phase 3: Completion semantics and execution behavior (~2-3 days)

• Implement the chosen Deployer completion contract in work_finish validation and workflow completion handling.
• Update any result-validation logic so Deployer sessions can complete delivery work using the intended results.
• Ensure delivery-phase transitions, candidate provenance updates, acceptance handling, and rollback/demotion paths still behave correctly after the role change.
• Validate that operator/manual docs and runtime behavior agree on whether Deployer handles promotion only or both promotion and acceptance.

Phase 4: Tooling, docs, and tests (~2 days)

• Update any setup, onboarding, status, or admin surfaces that display roles, prompt files, or default role instructions.
• Add or update tests for role registry, template loading, project scaffolding, workflow integrity, delivery dispatch, and completion validation.
• Add tests proving Deployer prompt loading works at both workspace and project override levels.
• Add tests covering the delivery-state role ownership and completion semantics chosen for the Deployer.
• Verify docs remain consistent with the implemented code paths after the role is introduced.

Dependencies & Blockers

• Depends on the documented Deployer contract in Define Deployer operator contract and documentation for policy-controlled lane-aware promotion, acceptance, and proof of release #232.
• Must stay aligned with the broader delivery-phase implementation work from Implement first-class delivery phases for candidate promotion, acceptance, and demotion semantics #218.
• Should not silently preserve reviewer/tester delivery ownership if the chosen contract is Deployer-owned states.
• If the Deployer ownership/result/level questions are still ambiguous, stop and refine rather than guessing.

Estimated Total: 5-8 days

[fujiwaranosai850]

🎛️ ORCHESTRATOR: Operator clarification for implementation:

Resolved contract choices:

1. Deployer owns both promotion and acceptance
2. Deployer completion results: done, blocked
3. Deployer levels: junior, senior

Implementation should treat these as the binding contract unless superseded by a later explicit refinement.