# Decisions

## Context Collection

- `devflow/index.md` confirms `executor-v2-output-contract`, `executor-gatekeeper-hook`, and `executor-verifier-claim-checks` are archived.
- `openspec/changes` has no active changes before this phase.
- `openspec/specs/chat-verifier-agent/spec.md` is the existing capability that owns verifier routing and audit behavior.
- No existing `chat-composer-agent` capability exists, so this change introduces it.

## Question Pool

| Question | Type | Resolution |
|---|---|---|
| Should Composer be a new capability or folded into `chat-verifier-agent`? | evidence-driven | New `chat-composer-agent` capability plus modified `chat-verifier-agent` routing. Composer is a distinct expression layer, while ChatService routing remains part of the verifier chain. |
| Can Composer call tools or inspect raw tool output? | evidence-driven | No. The issue and prior design require Composer to receive only Verifier-allowed material. |
| Should Gatekeeper, Verifier, or Planner change in this phase? | evidence-driven | No. Stage four is limited to Composer final-answer generation and routing. |
| What is the interface impact level? | evidence-driven | L2 internal contract change: ChatService internal final-answer semantics change, but no external API or database schema changes. |

## Key Decisions

- Composer is implemented as `chat_composer` or an equivalent model call after Verifier.
- Composer input is assembled by ChatService, not by the model.
- `claim_checks` are authoritative for filtering allowed material.
- REJECT input always has `allowed_hypotheses=[]`.
- Composer malformed output falls back to fixed safe templates.
- Fallback must never use Executor `user_facing_answer` or raw Executor JSON.
- Composer audit is persisted under `verifier_evaluation.composer_output`.

## Cross-Artifact Alignment

| Source | Alignment |
|---|---|
| Issue objective | Stage four in `mvp/issues/executor-structured-output-v2.md` requires Composer output final answer from Verifier-allowed material. Covered by proposal, design, specs, and tasks. |
| Proposal -> design | Proposal says Composer owns final expression; design defines input filtering, output parsing, fallback, and audit. |
| Design -> specs | Design decisions are reflected in `chat-composer-agent` requirements and modified `chat-verifier-agent` routing requirements. |
| Specs -> tasks | Each required behavior has implementation and test tasks, including malformed fallback and no raw output leakage. |

## Commit Gate Notes

- Interface impact: L2 internal.
- No unresolved user-interview question identified.
- No database migration required.
- No OpenSpec/devflow conflict found.