Receipts

Proof over vibes

Good agent work needs receipts: what was attempted, what passed, what failed, what changed, and what remains blocked. Gajae Code workflows are designed to end with evidence rather than a vague status update.

What counts as evidence?

• CI run names, conclusions, links, and the commit or change set they evaluated.
• Narrowly scoped local verification commands, including their command, exit status, relevant result, and the revision or working tree they ran against.
• PR review verdicts such as MERGE_READY or REQUEST_CHANGES, with the reviewed change reference.
• Lifecycle receipts from the system that performed the action: its run or session identifier, timestamp, action, outcome, and artifact or change reference.
• Public-safe artifacts that avoid raw secrets, logs, or private payloads.

Terminal panes, pane scraping, tmux state, and unscoped terminal output are not evidence of an outcome. Use a provenance-bearing lifecycle receipt or a narrowly scoped local command result instead.

Completion contract

A task is complete when its requested deliverables are observable and repeatable: required checks have passed or blockers are recorded, and the next operator can understand the state. Commit or publish only when the user requested that deliverable and the operator has the required authorization; otherwise record the resulting change and evidence without implying either action occurred.