Maintain a cross-system launch readiness checklist

Why use this

1. A launch lead may have specifications, issue trackers and discussions that tell different stories about readiness. A closed ticket can coexist with a pending decision, while an owner mentioned in chat may never have accepted the responsibility.

2. This job could reconcile the evidence into a checklist that makes blockers and changes reviewable. Keeping ownership and readiness provisional where necessary helps the team resolve disagreements before treating the checklist as a release decision.

Why an agent / simpler alternative

Useful judgment

Connect requirements, issue status and discussion context, identifying contradictions and uncertain ownership.

Simpler alternative

Use a single maintained release checklist when all teams already update one source reliably.

Unsuitable when

The workflow would declare a launch ready, assign people or change issue states without authorization.

Proposed inputs

1. Name

   Launch scope

   Owner

   Launch owner

   Minimum scope

   Release goals, criteria and relevant workstream IDs

   Quality check

   Distinguish launch blockers from follow-up improvements

2. Name

   Authorized evidence pack

   Owner

   Team owners

   Minimum scope

   Specifications, issue snapshots, discussions and prior lessons

   Quality check

   Record date, source authority and explicit ownership

Access and setup — proposed or unknown

Proposed minimum

1. Read scoped copies and draft a checklist/change log; no scheduled access, shared writes or notifications.

Compatibility unknowns

1. Current connector coverage, issue semantics, schedule support and runtime compatibility are unknown.

External actions requiring approval

1. Shared checklist updates, owner assignments, notifications or recurring routines require explicit authorization.

Expected deliverable and review checks

Proposed artifact

Readiness candidate with blocker evidence, proposed owners, changed status and unresolved decisions.

Critical checks

1. Trace each blocker to a criterion; preserve conflicting status; distinguish proposed owner from accepted responsibility.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   A closed issue is treated as verified completion

   Why it matters

   Closure may not satisfy the launch criterion

   Proposed response

   Check the evidence against acceptance requirements.

2. Signal

   An old retrospective rule is applied indiscriminately

   Why it matters

   Past context creates an irrelevant blocker

   Proposed response

   Confirm that the lesson applies to this release.

Effort and cost — unknown

Setup work

1. Define readiness criteria and authoritative status sources.

Ongoing review

1. Owners resolve contradictions and approve material checklist changes.

Unknowns

1. Source freshness, coverage, coordination effort and service costs are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent a launch with three criteria, a closed-but-unverified issue, an owner suggestion and an irrelevant past lesson; draft the checklist.

Acceptance checks

1. Keep verification pending; label ownership proposed; exclude unsupported blockers; make no release decision.

Stop conditions

1. Stop if criteria, status authority or permission to assign work is unresolved.

Limits

1. An updated checklist cannot establish release safety, accepted ownership or authorization to launch.