workplan-project: split packages have nowhere to record how they relate #74

From the QEP-6 field test (QuantEcon/qeps#19, amendment 10 and its field results).

The gap

The skill's own remedy for an oversized package is to split it:

A package that wants more than ~15 sub-issues is a signal, not an achievement — raise the bar in step 2 or split by phase into separate packages.

That produces the multi-project case, and the skill has no affordance for it. Nothing in step 4's body specification records that package B waits on package A's second phase, or that two items in different packages are coupled. The relationship exists in the author's head at split time and nowhere afterwards.

GitHub does not help here. Cross-references record that a mention happened — automatic, unordered, indistinguishable from someone linking in passing. There is no carrier for "these two projects are deliberately related, and here is how." That is an assertion, and assertions with no native carrier are what the body is for.

Two sections, carrying different kinds of fact

Gates — a constraint. QEP-6 already puts phase-level gates in the body, because no object represents a phase.

The field result sharpens this, and it is the part worth reading. Amendment 10 originally argued that a project-level gate should carry a native dependency edge between the two tracker issues, since a project is an issue. The first genuine two-project case produced no project-level gate at all — the real constraint was phase-to-phase, with the rest of both projects free to proceed. A tracker-to-tracker edge would have asserted something false and parked the whole project in any consumer deriving parked-ness from open blockers.

So the guidance for this skill is the common case, not the exotic one:

State the gate in the body of the package that waits, at the granularity that is actually true — usually one phase waiting on one phase, not one project waiting on one project.

Related work — a relationship with no direction. Two items in different packages that interact without either blocking the other. In the field: one item reading a schema from source and another testing that schema for drift — if the first lands, the second changes meaning but not order. Neither blocks; both authors need to know.

The rule that stops it becoming a mirror

Writing both sides surfaced the question the amendment did not cover: where does the gate's text live when two bodies could hold it? Restating it in both is the duplication QEP-6 spends its Alternatives section rejecting, and the two copies will diverge.

A gate is stated once, in the body of the project it constrains. The other project's Related work entry names the relationship and points at where the gate is stated; it does not restate the constraint.

And the bound that keeps Related work honest: name sibling projects, never work items. Listing individual issues is either the sub-issue list restated or dependency prose — both already forbidden by §6.

Proposed change

1. When step 4 produces more than one package, each package's draft gets a Related work section naming its siblings, one line each.
2. Where one package's phase gates another's, the gate is written in the body of the package that waits, with the sibling's entry pointing at it.
3. Appendix A addition:

**Gates:** … (state the constraint at the granularity that is true — usually
phase-level; a project-level gate also carries a tracker-to-tracker dependency edge)

## Related work

- [Project name](tracker-url) — one line on the relationship.

Why name the sections rather than rely on free sections

QEP-6 already permits this — "Free sections (Findings, Premises, Notes) may follow — the skeleton is a floor, not a ceiling" — so no permission is needed. What naming them buys is convention instead of permission, and the field test's own evidence is the argument: agents fill the slots that exist and invent none. Where the producer is a skill, an unnamed affordance is an unused one.

Acceptance

• A multi-package run drafts Related work in each package
• Gates are written once, on the waiting side, at phase granularity by default
• Related work names projects, never work items