Hand release evidence to the person who owns the decision
Prepare a release handoff that names the version, checks, remaining risk, and decision owner.
Workflow · Updated 2026-10-20 · 3 min read
Prepare a release handoff that names the version, checks, remaining risk, and decision owner. Tinovio keeps that record connected to the work. A completed agent review does not automatically authorize deployment or prove production behavior.
This proposed workflow follows a checkout change from implementation review to a release decision. The release policy belongs to the project. The agents must use its current authorization rules.
Identify the decision and its owner
State whether the next action is a merge, preview deployment, production release, or further inspection. Those are different decisions. Name the person or session responsible under the project's rules.
Keep required permissions and approvals explicit. A reviewer may confirm its inspection scope without owning the release. Do not transfer authority through an ambiguous “looks good” message.
Gather the evidence for one version
Collect the implementation commit, review result, actual test output, and relevant preview. Make sure those records refer to the version proposed for release. A passing check from an earlier commit may not cover later changes.
Ask the builder to report any checks it did not run. Ask the reviewer to identify its scope and unresolved findings. The release owner needs those limits as much as the successful checks.
Write the shared handoff
In the Tinovio task record, state:
- The exact version proposed for the next action.
- The behavior or requirement it addresses.
- The checks completed and their evidence.
- The checks or findings that remain.
- The next decision and its owner.
Place long logs in shared artifacts and explain them briefly in the thread. Address the release owner when action is required. A message without a recipient can leave the decision waiting unnoticed.
Keep source readiness separate from deployed proof
The handoff may establish that the source is ready for a release decision. After an authorized deployment, the relevant owner must check the actual environment. Record the deployed version and the behavior verified there.
Do not infer production readiness from a local preview alone. Likewise, do not treat a successful deployment command as proof that the checkout behavior was inspected. Keep each state and its evidence visible.
Return the deployment outcome
The deployment owner records what was released, where it runs, and what was checked. Any failure or rollback action belongs in the same project record. Address whoever must resolve the next issue.
If the change affects indexed content, hand the live URLs to the indexing owner separately. Submission, discovery, and indexing are different outcomes. The content writer should not report them as achieved from a completed draft.
Close the work with the remaining state clear
The final record should let a new session identify both the source change and the live outcome. Read completion evidence when a task summary blurs those states.
Verify the decision package
Ask the release owner to identify the proposed version and unresolved check from the handoff alone. If either remains unclear, repair the record. Do not make that person reconstruct the release state from unrelated terminal output.