Found while building survey (#181), which reuses inception's render_plan.
The mechanism
render_plan emits a phase as ## P0 Upgrade. That matches the plan parser's
item pattern — P0 is a well-formed id — so each phase becomes a work item
as well as a container, and its brief is the phase's why field:
## P0 Upgrade
because the runtime is out of support
The item P0 therefore has the brief "because the runtime is out of support".
Why it is defensible
It is deliberate and documented, in test_the_proposal_becomes_a_plan_the_parser_can_read:
The phase heading is an item too. That is the parser working as intended
rather than a leak: real plans track phases as work (NGMS has P0..P7 as
issues), and a generated plan should behave the same way a hand-written one
does.
Phases-as-issues is a real pattern, and a hand-written plan that does it has a
real brief under the heading.
Why it may still be wrong
- A rationale is not a specification. An agent that claims
P0 is being
asked to implement a reason. In a hand-written plan a human wrote a brief
there; in a generated one the field is why.
- It has no dependency on its own children. Nothing stops
P0 being
claimed before T1..T4, which is the opposite of what a phase means.
- The two roles want opposite things. A tracking umbrella should be an
issue and never a queue row. A work item should be both. Today it is both,
and only one of those is wanted.
What would settle it
Not an argument — data. In a deployment that has run a generated plan:
- are phase items ever claimed and completed, or do they sit
pending while
their children finish around them?
- when one is claimed, what does the agent produce from a
why as its brief?
If they never get worked, they are issues pretending to be items and should
stop being items. If they do, the current behaviour is right and this issue
closes.
Current state
render_plan(proposal, name, phases_as_items=True) — unchanged default, so
inception behaves exactly as it did. survey passes False, because its
output is meant to go straight to adopt and be executed.
That split is a holding position, not a design. The same renderer producing
two different plan shapes for two callers is worse than either answer applied
consistently, and it should collapse to one once the question above is
answered.
Found while building
survey(#181), which reusesinception'srender_plan.The mechanism
render_planemits a phase as## P0 Upgrade. That matches the plan parser'sitem pattern —
P0is a well-formed id — so each phase becomes a work itemas well as a container, and its brief is the phase's
whyfield:## P0 Upgrade because the runtime is out of supportThe item
P0therefore has the brief "because the runtime is out of support".Why it is defensible
It is deliberate and documented, in
test_the_proposal_becomes_a_plan_the_parser_can_read:Phases-as-issues is a real pattern, and a hand-written plan that does it has a
real brief under the heading.
Why it may still be wrong
P0is beingasked to implement a reason. In a hand-written plan a human wrote a brief
there; in a generated one the field is
why.P0beingclaimed before
T1..T4, which is the opposite of what a phase means.issue and never a queue row. A work item should be both. Today it is both,
and only one of those is wanted.
What would settle it
Not an argument — data. In a deployment that has run a generated plan:
pendingwhiletheir children finish around them?
whyas its brief?If they never get worked, they are issues pretending to be items and should
stop being items. If they do, the current behaviour is right and this issue
closes.
Current state
render_plan(proposal, name, phases_as_items=True)— unchanged default, soinceptionbehaves exactly as it did.surveypassesFalse, because itsoutput is meant to go straight to
adoptand be executed.That split is a holding position, not a design. The same renderer producing
two different plan shapes for two callers is worse than either answer applied
consistently, and it should collapse to one once the question above is
answered.