Work Packages
In the local canon workflow, the BA prepares the initial wp/<canon-WP-ID>/ in the shared product documentation repository. It links accepted requirements, changes and readiness checks. The Architect opens that same WP, preserves its identity, and adds technical decisions, change-spec.json, context-slice.md, and architect-developer.handoff.json under design/<canon-WP-ID>/. The Developer receives that prepared scope and implements it in a code checkout. See handoffs.
The current Runtime/Jira workflow also has a local execution WP. Architect materialization creates work-packages/<runtime-WP-ID>/manifest.json and maps it to a Jira Task key. Developer and Quality can select this Runtime WP by its local ID or mapped Jira key. A canon WP folder is not itself a claimable Jira Task, and matching names do not prove these objects are the same.
| Identity | Example | Stored where | Used for |
|---|---|---|---|
| Canon WP | WP-20260914-002 | Product repository wp/WP-20260914-002/ and design/WP-20260914-002/ | BA → Architect → source Developer scope |
| Runtime local WP | WP-20260914-002 in the counter fixture | Selected Runtime root work-packages/<id>/manifest.json | Local claim, completion and review |
| Jira WP | PRX-4 in the counter fixture | Jira Task; key recorded in the Runtime manifest | Remote issue workflow |
Those example IDs happen to match in the fixture. In a real handoff, record the actual canon ID ↔ Runtime ID ↔ Jira key mapping and verify each linked artifact and revision. Do not create a replacement canon ID while enriching a BA WP. Runtime reads its selected project root; a Jira URL or sibling checkout alone does not supply the local manifest, design package and linked inputs.
An Architect preview/apply for one Runtime WP should stay within that selected scope. Before Developer work, inspect the complete input package, not only the Jira ticket.