Make composition decisions chatty and inspectable #8

Closed
opened 2026-07-16 08:01:08 +00:00 by coilyco-ops · 1 comment
Member

Parent

#1

What to build

Make explainability a first-class product surface for agent-compose. Every resolution should produce a structured decision tree while choices are made, retain the deterministic evidence with the bundle, and render it for humans with progressive disclosure. The result should feel chatty and legible during interactive use without flooding unattended launch logs or model context.

Human experience

An interactive compose shows a bounded summary: resolved profile, target repos, cache result, changed outputs, selected source and skill counts, delivery mode, and warnings. A human can then expand the exact branch she cares about instead of paging through undifferentiated debug logs.

The detailed tree should answer:

  • Which person source, agent, role, personality, model class, privacy scope, and repo facts were used?
  • Which policy rules were evaluated, in what order, and from which source?
  • Which source, capability, and skill candidates were considered?
  • Why was each candidate included, excluded, shadowed, or replaced?
  • Which fallback fired and what preferred input was unavailable?
  • Why was content mounted natively, compiled into instructions, or omitted?
  • Which decision changed between two bundles?

Acceptance criteria

  • agent-compose describe renders the stored decision tree in stable, human-scannable sections.
  • agent-compose describe --why <source-or-skill> follows one item from repo facts through policy to its final delivery or rejection.
  • agent-compose diff <left> <right> reports semantic decision changes rather than a raw filesystem diff.
  • Interactive compose prints a one-screen summary by default and offers an explicit full explanation.
  • Launch wrappers emit at most a one-line no-change success, expand on changes or warnings, and show full context on failure.
  • Chatty human output is kept out of generated agent instructions and is not accidentally injected into model context.
  • TTY output uses hierarchy and restrained color, while redirected output is plain, width-safe, and deterministic.
  • Stable machine-readable output exposes the same decision tree rather than a second explanation model.
  • The trace records facts, candidates, rules, outcomes, reasons, and normalized provenance without private content, credentials, opaque host values, or volatile absolute paths.
  • Runtime telemetry such as duration and cache location is visible but excluded from deterministic bundle identity.
  • agent-compose doctor links health failures to the relevant decision-tree node and gives one concrete recovery action.
  • Role and personality selection explains the person source, compatibility rule, allowed alternatives, and why the selected pairing is valid.
  • Capability, harness-delivery, fallback, cache-hit, and profile-difference fixtures exercise the explanation surface.
  • Tests assert decision semantics, ordering, redaction, and bounded default output without committing generated reference renders.

Blocked by

  • Blocked by #4
  • Blocked by #5

Execution type

HITL for terminal information design and terminology review. The trace model, rendering, redaction, and tests are otherwise AFK.

## Parent #1 ## What to build Make explainability a first-class product surface for agent-compose. Every resolution should produce a structured decision tree while choices are made, retain the deterministic evidence with the bundle, and render it for humans with progressive disclosure. The result should feel chatty and legible during interactive use without flooding unattended launch logs or model context. ## Human experience An interactive compose shows a bounded summary: resolved profile, target repos, cache result, changed outputs, selected source and skill counts, delivery mode, and warnings. A human can then expand the exact branch she cares about instead of paging through undifferentiated debug logs. The detailed tree should answer: * Which person source, agent, role, personality, model class, privacy scope, and repo facts were used? * Which policy rules were evaluated, in what order, and from which source? * Which source, capability, and skill candidates were considered? * Why was each candidate included, excluded, shadowed, or replaced? * Which fallback fired and what preferred input was unavailable? * Why was content mounted natively, compiled into instructions, or omitted? * Which decision changed between two bundles? ## Acceptance criteria - [ ] `agent-compose describe` renders the stored decision tree in stable, human-scannable sections. - [ ] `agent-compose describe --why <source-or-skill>` follows one item from repo facts through policy to its final delivery or rejection. - [ ] `agent-compose diff <left> <right>` reports semantic decision changes rather than a raw filesystem diff. - [ ] Interactive compose prints a one-screen summary by default and offers an explicit full explanation. - [ ] Launch wrappers emit at most a one-line no-change success, expand on changes or warnings, and show full context on failure. - [ ] Chatty human output is kept out of generated agent instructions and is not accidentally injected into model context. - [ ] TTY output uses hierarchy and restrained color, while redirected output is plain, width-safe, and deterministic. - [ ] Stable machine-readable output exposes the same decision tree rather than a second explanation model. - [ ] The trace records facts, candidates, rules, outcomes, reasons, and normalized provenance without private content, credentials, opaque host values, or volatile absolute paths. - [ ] Runtime telemetry such as duration and cache location is visible but excluded from deterministic bundle identity. - [ ] `agent-compose doctor` links health failures to the relevant decision-tree node and gives one concrete recovery action. - [ ] Role and personality selection explains the person source, compatibility rule, allowed alternatives, and why the selected pairing is valid. - [ ] Capability, harness-delivery, fallback, cache-hit, and profile-difference fixtures exercise the explanation surface. - [ ] Tests assert decision semantics, ordering, redaction, and bounded default output without committing generated reference renders. ## Blocked by - Blocked by #4 - Blocked by #5 ## Execution type HITL for terminal information design and terminology review. The trace model, rendering, redaction, and tests are otherwise AFK.
coilyco-ops changed title from Explain composition decisions and diagnose bundle health to Make composition decisions chatty and inspectable 2026-07-16 08:07:03 +00:00
Author
Member

Shipped in fca3be3, built to the calibrated spec agreed in session (tens of lines, not hundreds).

Acceptance criteria:

  • describe renders the stored tree in stable sections (profile / sources / selection / delivery) with one line per decision; exclusion groups of 4+ collapse to a count line, --all expands. A full fixture bundle describes in ~20 lines.
  • describe --why follows one item: considered-by, outcome, reason, plus the counterfactual for excluded personality skills ('would select under: personality X (compatible with role Y)'). Accepts bare names or subject form.
  • diff is semantic, keyed by decision subject: outcome flips render as 'selected -> excluded', same-outcome reason changes as 'still excluded, reason changed', added/removed subjects as +/-, with an unchanged count and 'no semantic differences' for identical bundles.
  • compose keeps the 6-line summary; --explain appends the full tree.
  • Launch already emits one line on success, a warning block on fallback, full diagnostics on failure (shipped with #6).
  • Chatty output is stdout/stderr only and never enters bundle content; trace.json IS the machine-readable surface - no second explanation model.
  • Color (restrained: symbols only) renders only on a TTY with NO_COLOR unset; redirected output is plain and deterministic (asserted in tests).
  • Role and personality pairing now leaves trace evidence: two profile decisions record the person source, the role purpose, and the compatible personality set.

Trimmed against the original text, as discussed: doctor deferred (every failure path already names cause and fix; revisit at v0.2), and the repo-facts/privacy-scope/model-class explanation bullets fell with the #13 review.

Closed by Claude Code working the issue queue.

Shipped in fca3be3, built to the calibrated spec agreed in session (tens of lines, not hundreds). Acceptance criteria: - describe renders the stored tree in stable sections (profile / sources / selection / delivery) with one line per decision; exclusion groups of 4+ collapse to a count line, --all expands. A full fixture bundle describes in ~20 lines. - describe --why <item> follows one item: considered-by, outcome, reason, plus the counterfactual for excluded personality skills ('would select under: personality X (compatible with role Y)'). Accepts bare names or subject form. - diff <left> <right> is semantic, keyed by decision subject: outcome flips render as 'selected -> excluded', same-outcome reason changes as 'still excluded, reason changed', added/removed subjects as +/-, with an unchanged count and 'no semantic differences' for identical bundles. - compose keeps the 6-line summary; --explain appends the full tree. - Launch already emits one line on success, a warning block on fallback, full diagnostics on failure (shipped with #6). - Chatty output is stdout/stderr only and never enters bundle content; trace.json IS the machine-readable surface - no second explanation model. - Color (restrained: symbols only) renders only on a TTY with NO_COLOR unset; redirected output is plain and deterministic (asserted in tests). - Role and personality pairing now leaves trace evidence: two profile decisions record the person source, the role purpose, and the compatible personality set. Trimmed against the original text, as discussed: doctor deferred (every failure path already names cause and fix; revisit at v0.2), and the repo-facts/privacy-scope/model-class explanation bullets fell with the #13 review. Closed by Claude Code working the issue queue.
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-flight-deck/agent-compose#8
No description provided.