Deliverables

The promise

Deliverables are the review surface for agent work. They translate the work into artifacts a human can inspect without reconstructing the whole terminal session.

Depending on preferences and task type, deliverables can include an HTML presentation, Markdown summary, screenshots, validation logs, structured data, and narration. The active workspace preferences decide which formats are required. Narration is required only when voice mode and the matching presentation, response, or audit toggle are enabled.

Deliverable types

Type	What it is for	Where it belongs
HTML deck	Visual, navigable explanation of the work and evidence.	.pulse/knowledge/<slug>/artifacts/
Markdown summary	Fast scan, changelog-friendly closeout, or review notes.	Same KI artifacts folder
Narration WAV	Spoken briefing tied to the deck or response.	Same KI artifacts folder
Screenshots/media	Visual proof of product state, KI views, review surfaces, or validation output.	Same KI artifacts folder
Validation artifacts	Logs, JSON, manifests, source maps, or route proof.	Same KI artifacts folder

Pulse MCP is the preferred path because it attaches the KI to the board item and keeps the artifacts discoverable in review. Use pulse.presentation_template_* for template selection, pulse.deliverable_* for deck/markdown/narration/finalization, and pulse.deliverable_open for review.

How deliverables travel into review

The review path is:

1. Work starts from a board item.
2. Phase 1 defines checks and commits the manifest.
3. The task produces evidence.
4. pulse.deliverable_finalize packages the evidence under .pulse/knowledge/.
5. The task frontmatter gets a deliverables entry such as ki:<slug> or a presentation reference.
6. scripts/completion-gate.js validates the package and promotes the task to review.
7. The reviewer opens the task, the KI, and the artifacts before deciding.

If the board item does not link the KI, the reviewer may never see the work. If the KI exists but the deck is stale, the reviewer should reject or request revision.

Example: what the reviewer opens

For a focused sign-in listener cleanup, the reviewer opens:

Review object	Why it matters
Board task	Confirms the original request, completion notes, rubric, and deliverables link.
KI overview	Explains the closeout and the sibling-scope boundary.
HTML deck	Presents the evidence in a reviewable format.
Narration WAV	Gives the spoken summary when voice preferences require it.
Validation checks	Shows which commands were used to prove the listener cleanup.

This is the expected request-to-evidence path: a reviewer should never have to trust an unlinked chat claim.

Useful visual evidence

Deliverables should include media when it improves review quality:

Page or task type	Useful media
Knowledge Item education	Screenshot of the KI artifact list or a deck cover.
Review Queue education	Screenshot of a task in review with findings and attached deliverables.
Completion Gate education	Terminal capture of a passing or failing gate run.
Research education	Research card or diagram that separates product docs from deeper papers.

Do not include screenshots that expose secrets, private paths beyond what the user already sees, or agent governance material that belongs outside public docs.

Recovery

If the task reaches review without its Knowledge Item or presentation link, reopen the task evidence, finalize the package through Pulse AI, and attach the resulting reference before asking for approval. If a generated deck is stale, regenerate it from the final source state rather than editing around the mismatch.

When voice is disabled, do not create narration merely to satisfy an old example. When voice is enabled for the deliverable type, treat a missing or unvalidated WAV as incomplete evidence and use the Pulse Narrate recovery path.

Related links

• Knowledge Items
• Completion Gate
• Review Queue