CACP spec addendum: two-phase closure, AC compilation, and anti-priming guidelines

[zenprocess]

Background

Production experience with CACP across multiple dispatch engines (Claude Code, Qwen3-coder/vLLM) surfaced three spec-level learnings that should be documented as best practices or normative guidance.

1. Two-Phase Closure (NORMATIVE)

Problem: When the CACP response format (STATUS, FILES_CREATED, etc.) appears in the system prompt during the tool-use phase, some models (notably Qwen3-coder) immediately generate the CACP output as text completion instead of doing work first. The model treats CACP as a completion pattern, not a report-after-work format.

Recommendation: The CACP spec should state:

CACP response format MUST NOT appear in the system prompt during the tool-use phase. The format SHOULD be injected only in the closure turn (tools=None) or as a DONE: field instruction. This prevents models from pattern-matching to the format before performing work.

This is the "two-phase closure" pattern:

1. Working phase (tools available): No CACP format in context
2. Reporting phase (tools=None): CACP format injected as user message

2. Acceptance Criteria Compilation (INFORMATIVE)

Discovery: The ACCEPTANCE field can be pre-compiled into machine-verifiable checks:

• Shell checks: Criteria like "file X exists" or "tests pass" → shell commands
• Semantic checks: Criteria like "implements pagination correctly" → LLM judgment prompts

This compilation step runs pre-dispatch (~$0.001 via cheap model) and the checks run post-dispatch against the worktree + diff. The CACP spec could define an optional ACCEPTANCE_COMPILED field:

ACCEPTANCE_COMPILED:
  SHELL|hello.txt created|test -f hello.txt|exit_0
  SEMANTIC|implements pagination|Does the diff add offset/limit parameters to the query?

3. ACCEPTANCE Field Format Enforcement (NORMATIVE)

Problem: The spec says ACCEPTANCE is a numbered list, but implementations often pass the entire issue body when it contains the word "acceptance." This causes:

• Narrative prose treated as acceptance criteria
• Full body duplicated in both TASK and ACCEPTANCE fields
• Cross-issue contamination (agent builds things mentioned in prose)

Recommendation: The spec should strengthen the ACCEPTANCE field definition:

ACCEPTANCE MUST contain only acceptance criteria items, formatted as a numbered list or checkbox items. The full issue body MUST NOT be used as ACCEPTANCE content. Implementations SHOULD extract the acceptance criteria section from the source document rather than passing raw content.

4. GEPA Scoring Extension (INFORMATIVE)

Discovery: CACP responses contain enough signal to compute 4-dimension quality scores:

Dimension	CACP Signal
Goal	STATUS + ACCEPTANCE pass rate
Effort	Output tokens / FILES_CREATED+MODIFIED count
Plan	Phase timing distribution (if available)
Assumptions	ERROR field presence, LEARNED entries with error patterns

The spec could define an optional QUALITY response field:

QUALITY:goal=95,effort=80,plan=70,assumptions=100

This enables automated quality tracking without external tooling.