/dev:technical-plan 2.4b hardcodes proposed_action: defer-to-issue for PREQ out-of-scope findings, contradicting its own rule four paragraphs below #452

New issue

Open

opened 2026-08-27 07:32:44 +00:00 by jbr870 · 0 comments

jbr870 commented

2026-08-27 07:32:44 +00:00

Owner

Observation

/dev:technical-plan §2.4b builds two finding lists, and gives them contradictory rules for
proposed_action:

Expert-review deferred findings — the skill states the rule explicitly:

proposed_action MUST match the actual disposition described in the reasoning text. Do NOT
default everything to defer-to-issue. […] "accept" […] This is the typical case for the
"Noted (not actioned)" bucket.

PREQ out-of-scope findings — the skill hardcodes the opposite, as a literal template with no
judgement step:

{
  "category": "out-of-scope",
  "summary": "<item text from PREQ>",
  "reasoning": "Flagged as out of scope in the approved PREQ.",
  "proposed_action": "defer-to-issue",
  "target": null
}

§2.7 then mirrors proposed_action into each disposition decision's --recommended, so every
out-of-scope item arrives at /dev:resolve recommending "spawn a sibling issue" — including items
that are standing prohibitions or statements that no work exists, which can never be actioned
and can never be closed as done.

The target: null comment ("lets the orchestrator pick") is not a mitigation: the orchestrator picks
between defer-to-issue and accept, and the skill has already told them which one it recommends.

Evidence

/dev:technical-plan --issue=45, 2026-08-26. The PREQ's Out of Scope section had 5 items; all 5 were
emitted with proposed_action: "defer-to-issue" per the template, and all 5 disposition decisions
(D-PO-45-2-1..-5) carried --recommended defer-to-issue.

The operator then resolved all decisions as recommended. Outcome:

Spawned	Finding	Actionable?
folded into #36	general decision-withdrawal path	yes — correct, and correctly folded rather than duplicated
#418	correcting deliverables	borderline — the mechanism already exists (latest-wins)
#419	"editing or deleting a posted Phase Outcome remains a contract violation"	no — a standing prohibition
#420	a roll-call that sees live agents	yes — genuine watch item
#421	"migrating history"	no — the PREQ says nothing is rewritten

#419 and #421 were closed the same day as not-actionable-by-construction (see their closing
notes). Two tickets were created and closed within minutes, on a shared tracker that parallel
sessions triage.

Note the shape of the two that were wrong: both are boundary statements of the form "X remains
forbidden" / "no work is owed". A PREQ's Out of Scope section is mostly that kind of item —
it is where a requirements author records what was ruled out — so the template's default is
mis-aimed at the common case, not the rare one.

Recurrence

1 measured instance, but structural rather than incidental, on two independent grounds:

The template is unconditional. It fires on every /dev:technical-plan run whose PREQ has a
non-empty Out of Scope section — which is most of them — so the rate is a property of the skill
text, not of this feature.
The identical defect was already found and fixed once in the adjacent bucket of the same
step. The expert-review list's "MUST match the actual disposition / do NOT default everything to
defer-to-issue" paragraph exists because defaulting was observed to be wrong there. The fix was
never carried across to the out-of-scope list four paragraphs above it.

Ground 2 is also an instance of #257 ("a fix lands where the finding pointed, not everywhere the
rule lives").

Hypothesis

Give the out-of-scope list the judgement step the expert-review list already has, rather than a fixed
proposed_action. Roughly: derive it from whether the item names work someone could do.

Names deferrable work (a capability, a follow-up, a known gap) → defer-to-issue.
Is a standing prohibition, a restatement that an existing mechanism already covers it, or an
explicitly accepted limit → accept. The finding still exists and still pairs with a disposition
decision, so nothing is lost from the record — only the spurious ticket is.

The strict finding↔decision pairing (contract v1, Bend 1) is unaffected: every out-of-scope item
still emits a finding and still emits a paired scope-disposition decision. This changes only which
option the skill recommends.

Worth checking in the same pass whether the two buckets should share one recommender rather than two
prose rules that can drift apart again.

Suggested lane

Meta lane / /meta-amend. This is evidence-driven amendment of existing skill text: a bounded
edit to /dev:technical-plan §2.4b, verifiable at HEAD, with the run evidence above as the
requirement. No PREQ/SREQ/QA. Desk-check against this run's five out-of-scope items — the amended
text should recommend accept for the #419 and #421 shapes and defer-to-issue for the #36/#420
shapes.

## Observation `/dev:technical-plan` §2.4b builds two finding lists, and gives them **contradictory** rules for `proposed_action`: - **Expert-review deferred findings** — the skill states the rule explicitly: > **`proposed_action` MUST match the actual disposition** described in the reasoning text. Do NOT > default everything to `defer-to-issue`. […] `"accept"` […] **This is the typical case for the > "Noted (not actioned)" bucket**. - **PREQ out-of-scope findings** — the skill hardcodes the opposite, as a literal template with no judgement step: ```json { "category": "out-of-scope", "summary": "<item text from PREQ>", "reasoning": "Flagged as out of scope in the approved PREQ.", "proposed_action": "defer-to-issue", "target": null } ``` §2.7 then mirrors `proposed_action` into each disposition decision's `--recommended`, so every out-of-scope item arrives at `/dev:resolve` recommending "spawn a sibling issue" — including items that are **standing prohibitions or statements that no work exists**, which can never be actioned and can never be closed as done. The `target: null` comment ("lets the orchestrator pick") is not a mitigation: the orchestrator picks between `defer-to-issue` and `accept`, and the skill has already told them which one it recommends. ## Evidence `/dev:technical-plan --issue=45`, 2026-08-26. The PREQ's Out of Scope section had 5 items; all 5 were emitted with `proposed_action: "defer-to-issue"` per the template, and all 5 disposition decisions (`D-PO-45-2-1`..`-5`) carried `--recommended defer-to-issue`. The operator then resolved all decisions as recommended. Outcome: | Spawned | Finding | Actionable? | |---|---|---| | folded into #36 | general decision-withdrawal path | yes — correct, and correctly folded rather than duplicated | | #418 | correcting deliverables | borderline — the mechanism already exists (latest-wins) | | **#419** | "editing or deleting a posted Phase Outcome remains a contract violation" | **no — a standing prohibition** | | #420 | a roll-call that sees live agents | yes — genuine watch item | | **#421** | "migrating history" | **no — the PREQ says nothing is rewritten** | **#419 and #421 were closed the same day as not-actionable-by-construction** (see their closing notes). Two tickets were created and closed within minutes, on a **shared** tracker that parallel sessions triage. Note the shape of the two that were wrong: both are boundary statements of the form *"X remains forbidden"* / *"no work is owed"*. A PREQ's Out of Scope section is **mostly** that kind of item — it is where a requirements author records what was ruled out — so the template's default is mis-aimed at the common case, not the rare one. ## Recurrence **1 measured instance, but structural rather than incidental**, on two independent grounds: 1. The template is **unconditional**. It fires on every `/dev:technical-plan` run whose PREQ has a non-empty Out of Scope section — which is most of them — so the rate is a property of the skill text, not of this feature. 2. **The identical defect was already found and fixed once in the adjacent bucket of the same step.** The expert-review list's "MUST match the actual disposition / do NOT default everything to `defer-to-issue`" paragraph exists because defaulting was observed to be wrong there. The fix was never carried across to the out-of-scope list four paragraphs above it. Ground 2 is also an instance of #257 (*"a fix lands where the finding pointed, not everywhere the rule lives"*). ## Hypothesis Give the out-of-scope list the judgement step the expert-review list already has, rather than a fixed `proposed_action`. Roughly: derive it from whether the item names **work someone could do**. - Names deferrable work (a capability, a follow-up, a known gap) → `defer-to-issue`. - Is a standing prohibition, a restatement that an existing mechanism already covers it, or an explicitly accepted limit → `accept`. The finding still exists and still pairs with a disposition decision, so nothing is lost from the record — only the spurious ticket is. The strict finding↔decision pairing (contract v1, Bend 1) is unaffected: every out-of-scope item still emits a finding and still emits a paired `scope-disposition` decision. This changes only which option the skill *recommends*. Worth checking in the same pass whether the two buckets should share one recommender rather than two prose rules that can drift apart again. ## Suggested lane **Meta lane / `/meta-amend`.** This is evidence-driven amendment of existing skill text: a bounded edit to `/dev:technical-plan` §2.4b, verifiable at HEAD, with the run evidence above as the requirement. No PREQ/SREQ/QA. Desk-check against this run's five out-of-scope items — the amended text should recommend `accept` for the #419 and #421 shapes and `defer-to-issue` for the #36/#420 shapes.

jbr870 added the

labels

2026-08-27 07:32:44 +00:00

jbr870 referenced this issue

2026-08-27 07:32:46 +00:00

Phase Outcomes: no supersede path when a posted outcome's premise turns out false #45

jbr870 referenced this issue

2026-08-27 07:32:46 +00:00