feat(unic-archon-dlc): the work-item hierarchy a Consumer wants becomes config

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.

Read docs/agents/triage-labels.md, commands/tickets.md, and docs/research/2026-08-31-dlc-run-2-findings.md first, then check the status and facts from ADO 42998. Determine whether the hierarchy belongs in config.yaml or the tracker contract, and define how parent handling respects the existing prohibition. Done means the convention, configuration or contract, and /tickets behavior are reconciled and documented.