Deliverables
What Pulse AI agents produce so task work can be inspected, heard, and approved.
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. In this workspace, task deliverables require both HTML and Markdown, and narration is required when voice preferences 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 |
scripts/finalize-deliverable.js is the preferred path because it attaches the KI to the board item and keeps the artifacts discoverable in review.
How deliverables travel into review
The review path is:
- Work starts from a board item.
- Phase 1 defines checks and commits the manifest.
- The task produces evidence.
scripts/finalize-deliverable.jspackages the evidence under.pulse/knowledge/.- The task frontmatter gets a
deliverablesentry such aski:<slug>or a presentation reference. scripts/completion-gate.jsvalidates the package and promotes the task to review.- 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 web-fix-reset-password-memory-leak, 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 required by voice preferences. |
| 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.
Media needs
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.