What the Consumer wants
A feature is a User Story named for the slug; its slices are Tasks under it. The maintainer's words: it reads well in Azure DevOps and helps people who are not developers see the shape of the work.
Run 2 did this by hand — User Story 43007 under Feature 42975, Tasks 43008–43014 beneath it — because /tickets sets no parent, by design: commands/tickets.md says "Do NOT close or modify any parent item".
It worked because one person remembered.
The collision it exposed
docs/agents/triage-labels.md § Type maps every slice type onto User Story and says never write Task. Its stated reason is that a DLC-filed Task would be parentless, which the board forbids — and that reason does not apply when a human parents them, which is exactly what the convention prescribes.
So a run following the tracker contract and a run following the work item produce different shapes, and nothing reconciles them.
Blocked by
ADO 42998 in DXP-DesignSystem, "Record the board facts an agent cannot infer", which is where the hierarchy convention gets written down. No native link exists across trackers — check it before starting.
The open question
Is the hierarchy a config.yaml value the Consumer declares, or a fact the tracker contract states? And if /tickets learns to set a parent, what stops it modifying a parent item, which its own prose forbids?
Full evidence: docs/research/2026-08-31-dlc-run-2-findings.md.
What the Consumer wants
A feature is a User Story named for the slug; its slices are Tasks under it. The maintainer's words: it reads well in Azure DevOps and helps people who are not developers see the shape of the work.
Run 2 did this by hand — User Story 43007 under Feature 42975, Tasks 43008–43014 beneath it — because
/ticketssets no parent, by design:commands/tickets.mdsays "Do NOT close or modify any parent item".It worked because one person remembered.
The collision it exposed
docs/agents/triage-labels.md§ Type maps every slice type ontoUser Storyand says never writeTask. Its stated reason is that a DLC-filedTaskwould be parentless, which the board forbids — and that reason does not apply when a human parents them, which is exactly what the convention prescribes.So a run following the tracker contract and a run following the work item produce different shapes, and nothing reconciles them.
Blocked by
ADO 42998 in
DXP-DesignSystem, "Record the board facts an agent cannot infer", which is where the hierarchy convention gets written down. No native link exists across trackers — check it before starting.The open question
Is the hierarchy a
config.yamlvalue the Consumer declares, or a fact the tracker contract states? And if/ticketslearns to set a parent, what stops it modifying a parent item, which its own prose forbids?Full evidence:
docs/research/2026-08-31-dlc-run-2-findings.md.