CSA → ADW Handoff Queue Optimization
Internal briefing — CSA-to-ADW handoff formalization with HITL gate, manifest convention, and monitoring integration into GitReport flywheel.
Problem Statement
12%
Conversion Rate
1 / 8
Engagements Converted
6
Issues Created (JuxtMedia)
4
PRs Merged (JuxtMedia)
CSA→ADW conversion tracking is live (vault/pipelines/csa-adw-conversions.md), revealing a 12% structured specification coverage rate — only 1 of 8 client CSA engagements has completed the full CSA→ADW flow.
Evidence: Only JuxtMedia shows complete flow:
juxtmedia-agent-phase3 (CSA) → JuxtMedia-agent (ADW) with 6 issues, 4 PRs, 5 closed, 1 open.
Current State
- 7 spec-only engagements with no ADW handoff: 4 SecondAct, 2 HHE, 1 other
- Handoff is implicit — no manifest, no quality gate, no monitoring
- No structured visibility into what specs are ready for implementation vs. draft
Two Valid Origin Flows
- Claude Code → Issue → ADW — most common today, direct agent-driven issue creation
- CSA → Issue → ADW — structured specification pipeline, needs formalization for visibility and monitoring
Figure 1: CSA Engagement Conversion Status
Architecture
The full CSA→ADW flow introduces a HITL (Human-in-the-Loop) gate between specification completion and ADW pipeline execution. The manifest file (_handoff.json) serves as the structured interface between CSA output and ADW input.
Key principle: Both origin flows (Claude→ADW and CSA→ADW) are co-equal. The manifest convention formalizes the CSA path without disrupting the direct Claude→ADW path.
Figure 2: CSA → ADW Architecture with HITL Gate
Proposed Solution
Hybrid Manifest Convention
A _handoff.json file placed in the CSA engagement folder serves as the structured handoff artifact. It captures specification state, quality gate results, and ADW linkage.
| Field | Type | Description |
|---|---|---|
engagement | string | CSA engagement folder name |
client | string | Client entity name |
status | enum | draft → ready → handed-off |
spec_file | string | Path to primary specification document |
artifacts | string[] | Paths to supporting artifacts (diagrams, schemas) |
target_repo | string | GitHub repo for ADW issue creation |
quality_gate | object | Tiered gate check results |
adw_issues_created | string[] | GitHub issue URLs created by handoff |
HITL Principle: CSA completion NEVER auto-triggers ADW. The user explicitly promotes
draft → ready. This is a non-negotiable safety constraint.
HITL Interaction Patterns
| Pattern | Trigger | Flow | Use Case |
|---|---|---|---|
| In-Session | User says "hand off to ADW" | draft → ready → handed-off (same session) | Spec is complete, user wants immediate handoff |
| Deferred | Agent writes draft; user promotes later | draft → (pause) → ready → handed-off | Spec needs review before implementation |
| Pre-Authorized | /csa-pipeline --adw-handoff |
draft → ready → handed-off (auto) | High-confidence specs with pre-approved handoff |
Figure 3: HITL Interaction Patterns
Tiered Quality Gates
| Tier | Level | Check | Effect |
|---|---|---|---|
| Tier 1 | Blocking | No spec file present | Cannot promote to ready |
| Tier 2 | Warning | Missing diagrams, incomplete sections | Warns user, allows override |
| Tier 3 | Advisory | Spec age > 14 days, stale references | Informational note only |
Target Repositories
- agent-issue-hook — primary ADW target (issue creation + webhook pipeline)
- GitReport — downstream reporting and conversion tracking
- CSA folder — output manifest location (
_handoff.json)
Implementation Plan
CP-1: Manifest Convention
- Define
_handoff.jsonschema (fields, types, validation rules) - Update
/csa-pipelinePhase 10 to emit draft manifest on spec completion - Document convention alongside existing
.adw-*.jsonpattern
CP-2: GitReport Extraction
- Detect
_handoff.jsonfiles in GitReport flywheel scan cycle - Layer 0 matching logic: manifest → client entity → project → repo
- Update
csa-adw-conversions.mdwith manifest-sourced data
CP-3: Monitoring Metrics
- Compute handoff latency, drop-off rate, spec completeness, throughput
- Extend
pipeline-outcome.mdreport with monitoring section - No new cron jobs — integrate into existing 30-min flywheel
CP-1: Manifest Convention
→
CP-2: GitReport Extraction
→
CP-3: Monitoring
Figure 4: Implementation Roadmap
Monitoring Framework
Baseline Metrics
| Metric | Computation | Source |
|---|---|---|
| Handoff Latency | first_issue_created - handoff_created (hours) |
Manifest + issue frontmatter |
| Drop-off Rate | count(ready >14d, no issues) / count(ready) |
Manifest status + issue map |
| Spec Completeness | sum(gate_checks_passed) / total_gate_checks * 100 |
Manifest quality_gate |
| Throughput | count(handed-off) / 30d window |
Manifest status dates |
Figure 5: Monitoring Data Flow via GitReport Flywheel
Decision Summary
| # | Decision | Recommended | Rationale |
|---|---|---|---|
| 1 | Handoff mechanism | Manifest file (_handoff.json) |
Convention-driven, matches existing .adw-*.json pattern |
| 2 | Trigger model | Semi-automated (HITL: draft → ready) | Automated capture, manual approval — safety-first |
| 3 | Quality gate | Tiered (block / warn / advise) | Matches existing safety_gate.py pattern |
| 4 | v1 scope | Minimal manifest convention | Validates pattern before investing in automation |
| 5 | ADW allowlist | Manual (v1), suggest+confirm (v2) | Security-first — no auto-creation to arbitrary repos |
| 6 | Monitoring | Extend GitReport flywheel | No new cron jobs — leverage existing 30-min cycle |
| 7 | Manifest format | JSON | Matches agent-issue-hook convention, machine-readable |