Product Engineering Delivery

Use this once a governed story or execution issue is ready for pickup. For the route into governed work, see Product Engineering Workflow. For Linear status rules, see Product Engineering Workflow in Linear.

Ready To Pick Up

Start only when:

• the issue is a unit user story or focused execution step
• acceptance criteria or completion rules are clear
• the upstream Index Challenge -> Linear Project Specification -> Linear Issue context is traceable
• material dependencies or unresolved questions are visible
• the active Linear issue matches the work actually happening

If that minimum context is missing, shape the missing artifact or issue detail first.

Delivery Loop

1. Start from the active Linear issue.
2. Confirm the issue boundary and upstream governed context.
3. Check relevant ADRs or long-lived system design before changing the implementation path.
4. Implement without silently widening into adjacent stories.
5. Validate changed behaviour in the relevant executable environment.
6. Check observed behaviour against the acceptance criteria.
7. Update release notes, help docs, operational docs, and feature-flag records when the shipped behaviour requires it.
8. Keep Linear current if scope, owner, blockers, dependencies, or status change.
9. Hand off with what was tested, what acceptance criteria were covered, and any remaining gaps.

Done Means

A governed story is done only when:

• implemented behaviour matches the intended issue scope
• acceptance criteria or completion rules are met
• changed behaviour has been run and checked in the relevant executable environment
• Linear reflects the current state, owner, dependencies, and blockers
• release notes are updated when shipped scope should appear in release communication
• user-facing docs or in-app help are updated when users see, expect, notice, or need to do something differently
• feature-flag rollout state, communication, help-doc timing, and retirement expectation are clear when a Manage feature flag is involved

If the work has not been run, checked, and explained, it is not done yet.

Staging Validation

• After the MR deploys to staging, rerun the story's acceptance criteria in staging and check for regressions before treating the story as done.
• Staging validation is mandatory between the Thursday cut-off and the following Tuesday production release.
• When staging validation passes, add the GitLab label Validated in Staging to the MR.
• If staging validation fails or is incomplete, do not add the label; fix and recheck first.
• Use the prefilled GitLab view to find merged staging MRs missing the label: Staging validation MR view.

Handoff States

A successful handoff does not always mean Done. It can mean In Review, blocked, ready for staging validation, or ready for a human decision when that is the true current state. The handoff should make the state explicit.