Parent
Refs #3799
Agent Brief
Type: Feature
Summary: The decompose container body inlines the design artifact produced for the plan's design scope, as a fenced diagram block with a provenance note.
Amended 2026-09-06, after the planning slice #3805 found that the original join key does not exist. The brief matched a design artifact "to a slice by scope". Design scopes are architectural (library, module, data, integration, system); a decomposed slice is a vertical tracer bullet that crosses layers by construction and carries no scope. One design session picks one scope, so an artifact matched every slice or none, and two slices matching one artifact was the normal case rather than an edge case. The target moves to the container body, which decompose already publishes as the Brief verbatim and which stands in a one-to-one relationship with the design session that produced the artifact. That is a real join rather than an inference.
Current behavior:
The slice body template carries a narrow inline carve-out: pressure-test output may be inlined. Everything else is referenced rather than inlined. A design artifact produced for the plan is therefore invisible to whoever picks the work up, even though the tracker renders mermaid natively.
Desired behavior:
Widen the existing carve-out so a design artifact produced by the design skill for the plan's scope is inlined into the container body as a fenced diagram block, followed by a one-line provenance note naming which design scope produced it.
The behavior fires only when such an artifact exists. When the design skill produced none, the container body is unchanged from today. There is no lever, flag, or convention key: existence of the artifact is the whole trigger.
Inline only what the tracker renders. A mermaid artifact is inlined as a rendered fenced block. A DBML, OpenAPI, LikeC4 or C4-PlantUML artifact renders as an unrendered code fence in every bundled tracker provider, so it is inlined as a plain fenced block and the provenance note names its dialect, so a reader knows what they are looking at rather than meeting an unlabelled wall of syntax.
No file path appears in the emitted body. The artifact content is inlined and its provenance described in prose, never by pointing at a location that will go stale, and the contract slice holding the artifact is pruned before merge, so a path would dangle by construction.
Slice bodies are unchanged by this slice. They keep their existing pressure-test carve-out and gain nothing.
Where the change lands, precisely. The carve-out this issue originally spoke of widening is the slice template in plugins/work-items/skills/decompose/SKILL.md, and that is not the file to change. The container body is specified in plugins/work-items/skills/decompose/context/container-lifecycle.md, in the "Publish. Container first." section's Body bullet.
That bullet currently ends with a "No inflation" rule: "the Brief as approved is the spec; do not expand it into a 'long, extensive' document for the tracker's benefit." An inlined diagram is an expansion, so the bullet needs an explicit exception rather than being left to contradict this slice. There is precedent in the same bullet: it already admits an optional ## Testing decisions section and an appended execution-shape line beside the verbatim Brief, so the shape of a stated exception is established.
Key interfaces:
container-lifecycle.md's Body bullet — gains the inlined artifact block as a stated exception to its own no-inflation rule, alongside the existing Testing-decisions and shape-line exceptions.- The container body composition — gains the inlined artifact block, beside the Brief it already carries verbatim.
- The design artifact input — one per design session, matched to the container rather than to a slice.
- The provenance note — one line naming the producing design scope and the artifact's dialect, with no path.
Acceptance criteria:
Out of scope:
Blocked by
3822
Parent
Refs #3799
Agent Brief
Type: Feature
Summary: The decompose container body inlines the design artifact produced for the plan's design scope, as a fenced diagram block with a provenance note.
Current behavior:
The slice body template carries a narrow inline carve-out: pressure-test output may be inlined. Everything else is referenced rather than inlined. A design artifact produced for the plan is therefore invisible to whoever picks the work up, even though the tracker renders mermaid natively.
Desired behavior:
Widen the existing carve-out so a design artifact produced by the design skill for the plan's scope is inlined into the container body as a fenced diagram block, followed by a one-line provenance note naming which design scope produced it.
The behavior fires only when such an artifact exists. When the design skill produced none, the container body is unchanged from today. There is no lever, flag, or convention key: existence of the artifact is the whole trigger.
Inline only what the tracker renders. A mermaid artifact is inlined as a rendered fenced block. A DBML, OpenAPI, LikeC4 or C4-PlantUML artifact renders as an unrendered code fence in every bundled tracker provider, so it is inlined as a plain fenced block and the provenance note names its dialect, so a reader knows what they are looking at rather than meeting an unlabelled wall of syntax.
No file path appears in the emitted body. The artifact content is inlined and its provenance described in prose, never by pointing at a location that will go stale, and the contract slice holding the artifact is pruned before merge, so a path would dangle by construction.
Slice bodies are unchanged by this slice. They keep their existing pressure-test carve-out and gain nothing.
Where the change lands, precisely. The carve-out this issue originally spoke of widening is the slice template in
plugins/work-items/skills/decompose/SKILL.md, and that is not the file to change. The container body is specified inplugins/work-items/skills/decompose/context/container-lifecycle.md, in the "Publish. Container first." section's Body bullet.That bullet currently ends with a "No inflation" rule: "the Brief as approved is the spec; do not expand it into a 'long, extensive' document for the tracker's benefit." An inlined diagram is an expansion, so the bullet needs an explicit exception rather than being left to contradict this slice. There is precedent in the same bullet: it already admits an optional
## Testing decisionssection and an appended execution-shape line beside the verbatim Brief, so the shape of a stated exception is established.Key interfaces:
container-lifecycle.md's Body bullet — gains the inlined artifact block as a stated exception to its own no-inflation rule, alongside the existing Testing-decisions and shape-line exceptions.Acceptance criteria:
container-lifecycle.md's Body bullet states the inlined artifact as an explicit exception to its no-inflation rule.decompose/SKILL.mdis unchanged./skill-quality:checkpasses for the decompose skill.markdownlintpasses on the changed files.Out of scope:
Blocked by
3822