Skip to main content

Delivery Plan And Handoff Packs

After Delivery Plan generation, the initiative UI shows an editable inrelay draft task list with:

  • inrelay task ID.
  • Title.
  • Complexity.
  • Task type.
  • Dependencies.
  • Repository hints, tags, component hints, and acceptance criteria when available.
  • Linear link when available.
  • QA, release, ownership, and acceptance context when available.

Before Linear handoff, users can edit, add, delete, split, merge, reorder, retag, resize, and adjust acceptance criteria. inrelay records those task-shaping deltas as audit context and may use recurring high-signal corrections in future task-generation prompts for the same team.

Use Send to Linear when the inrelay task list is final. Delivery Plan generation itself does not create Linear issues. After successful handoff, Linear owns task content; inrelay freezes task title, description, acceptance criteria, size, and sequencing while still allowing local non-authoritative metadata such as repository hints, tags, component hints, and generation notes for pack preparation.

inrelay can carry forward target-context answers for any initiative when material Delivery Plan target signatures are unchanged. Retained answers appear as known assumptions. Material changes to task title, description, acceptance criteria, grouping, dependencies, repository scope, blueprint scope, or repo/docs evidence reopen the affected review instead of hiding changed requirements.

For medium or high complexity work, inrelay may require explicit Delivery Plan acceptance before Handoff Packs can be prepared or published.

Handoff Pack Candidates​

inrelay groups related delivery work into Handoff Pack candidates. Each candidate shows:

  • Candidate key and title.
  • Included delivery tasks.
  • Inferred repository scope, confidence, freshness, role, and evidence.
  • Discovery search-scope evidence when relevant.
  • Whether repository scope needs confirmation or amendment.
  • Repo/docs refinement status, inspected sources, unresolved questions, contradictions, and proposed documentation updates.
  • Carried-forward repo/docs assumptions, suppressed repeated questions, and hard blockers when material evidence signatures are evaluated.
  • PRD quality metadata, pre-flight signals, task deltas, and Linear issue anchors when available.
  • Blueprint status when blueprint review is enabled.
  • Blueprint PR link when one exists.
  • Prepared pack readiness by target task and repository.
  • The current next state, such as checking repo/docs context, needing a repo/docs decision, drafting or validating a Blueprint PR, waiting for GitHub review, preparing packs, ready, or blocked.
  • Operation progress for automated repo/docs, blueprint, GitHub refresh, and Handoff Pack preparation work.

Available Handoff Pack candidate actions include:

  • Confirm inferred repository scope.
  • Mark repository scope unknown when inrelay cannot safely infer it.
  • Add, remove, or set repositories.
  • Split a candidate into smaller candidates.
  • Merge related candidates.
  • Carry forward actionable repo/docs questions with a reason when inrelay cannot resolve them from confirmed scope.
  • Mark blueprint not required with a reason and explicit repository mapping.
  • Open the Blueprint PR in GitHub when review is required.
  • Generate prepared packs manually when the team uses manual Handoff Pack preparation.

inrelay automatically runs mechanical readiness work after the relevant gates pass:

  • Repo/docs refinement after scope is confirmed or amended.
  • Repeated already-resolved repo/docs question suppression when material evidence is unchanged.
  • Low-risk-only auto-carry-forward for new non-hard repo/docs questions when strict low-risk gates and unchanged material evidence allow it.
  • Blueprint PR creation, update, or approved-scope revision creation.
  • Blueprint validation after inrelay creates or updates the PR.
  • Handoff Pack preparation when preparation mode allows it.

Hard access, stale-index, missing-repo, and implementation-surface blockers always remain visible and actionable. Multi-repo scope, including user-confirmed multi-repo retrieval scope, uses the normal workflow rather than the low-risk lane.

Advanced recovery controls may appear when they are safe:

  • Refresh from GitHub refreshes inrelay from an existing Blueprint PR when displayed state looks stale.
  • Regenerate Blueprint PR recreates or updates the Blueprint PR only when the current gate permits it.

Validate blueprint, Sync blueprint, and normal Create/update PR buttons are not everyday actions. Validation runs automatically after inrelay-created or updated PRs and through GitHub webhook handling.

Blueprint content is edited in GitHub, not in the inrelay UI. Handoff Pack publishing remains explicit after packs are prepared.