IssueRun artifact requirements conflict with umbrella issue workflows

[rochecompaan]

Summary

An Issue run currently expects its issue to have both a specification and an implementation plan. This assumption does not fit work that is organized as an umbrella issue with delivery sub-issues.

The mismatch became visible while decomposing #180. In that structure, the umbrella issue owns the shared specification and each sub-issue owns a smaller implementation plan. Neither level naturally owns both artifacts:

• The umbrella issue coordinates work and does not have one executable implementation plan.
• A delivery sub-issue has a focused implementation plan but relies on the umbrella specification.

Observed problem

The Issue run artifact model treats specification and plan artifacts as if they are both local to the issue being processed. It cannot clearly represent an issue that:

• owns only a specification;
• owns only a plan;
• relies on planning context owned by another issue; or
• coordinates delivery without running implementation itself.

As a result, using the current workflow with umbrella and sub-issues would require duplicate documents, artificial placeholder documents, or manual handling outside the Issue run lifecycle.

Why this matters

• Duplicate specifications can diverge from the umbrella design.
• Placeholder plans make artifact presence an unreliable indication of executable work.
• Approval and provenance become unclear when shared design context is copied between issues.
• Large work becomes harder to decompose into independently reviewable delivery slices.
• The behavior may differ across hosts because issue hierarchy and dependency features are not uniform.

Scenarios that expose the mismatch

1. An umbrella issue owns an approved specification but delegates all implementation to sub-issues.
2. A sub-issue owns a focused plan and needs the umbrella specification as context.
3. Several sibling sub-issues share one specification but have independent plans and implementation lifecycles.
4. A coordination issue reaches a terminal outcome without running an implementation phase.
5. A resumed sub-issue must retain stable planning context even if the umbrella issue changes later.

Selected direction

Complete #180 without expanding its scope. After planning-pr-v1 lands, add
planning flexibility through two independent issue-level mechanisms:

1. Requirement labels select whether the current Issue Run requires a
   specification, specification review, plan, and plan review.
2. Artifact bindings select whether each required specification and plan is
   owned by the current issue or its parent.

The effective requirements and resolved artifact owner, path, and revision must
be saved in durable run state. Coordination-only Issue Runs remain out of scope;
umbrella issues can remain agent-unsuitable while executable children run.

Delivery questions

• What are the requirement label names and migration defaults?
• Where are self and parent artifact bindings declared?
• How is parent review provenance validated and reused?
• How do GitHub and Forgejo expose a reliable parent relationship?
• What happens when labels or parent artifacts change after a run starts?

Delivery overview

• Add per-issue planning artifact requirements #206 — Add per-issue planning artifact requirements
• Resolve planning artifacts from parent issues #207 — Resolve planning artifacts from parent issues

Dependency order

#180 must land first. Then #206 introduces the issue planning contract and
label requirements. #207 extends that contract with parent artifact bindings.

GitHub native sub-issue and blocked-by relationships are authoritative. The
blocked labels mirror those dependencies for Patchmill triage.

Scope

This issue is the post-#180 design and coordination umbrella for per-issue
planning requirements and cross-issue artifact bindings. Implementation belongs
in its child issues. It does not expand #180, add arbitrary workflow definitions,
or add coordination-only Issue Runs.

Related: #180

[rochecompaan]

This was generated by AI during triage.

Triage Notes

What we have established so far:

• The current Issue run contract assumes the processed issue locally owns both a specification and an implementation plan.
• Umbrella and delivery-sub-issue workflows need to distinguish artifact ownership from artifact availability without duplicating planning documents.
• Shared planning context must preserve approval provenance and resume safety, and coordination-only issues may need a non-implementation terminal outcome.
• The issue intentionally records the mismatch without selecting a target artifact, relationship, or lifecycle model, so there is not yet a bounded implementation contract for automation.

What we still need from you:

• What is the first required delivery slice: umbrella-owned specifications referenced by executable sub-issues, coordination-only issue completion, or the full set of scenarios together?
• Should a run reference an approved artifact owned elsewhere, copy/snapshot it into run state, or support both—and what must remain immutable when the owning issue changes?
• What explicit, host-portable source of truth should identify artifact ownership and relationships when native issue hierarchy is unavailable?
• Which artifact combinations are valid for executable runs versus coordination-only issues, and what terminal states should each support?
• What compatibility behavior is required for existing runs that currently discover both artifacts locally?

Once these decisions are recorded, the issue can be reassessed for agent-ready and split into bounded delivery issues if necessary.