Should a supersede posted by a SKILL (by != operator) be barred from dissolving a blocking `approval` Pending Decision, so an autonomous run cannot annul the outcome carrying its own human gate and proceed? #422

New issue

Open

opened 2026-08-26 16:20:23 +00:00 by jbr870 · 0 comments

jbr870 commented

2026-08-26 16:20:23 +00:00

Owner

Spawned from finding F-PO-45-2-7 (in-scope-deferrable) on issue #45 during decision D-PO-45-2-7.

Original scope note: Reviewer suggestion acknowledged but not actioned in this SREQ — see Expert Review > Noted (not actioned). The security lens raised it as blocking. It is NOT actioned here because AC-7 states plainly that an annulled outcome's open blocking decisions stop blocking, with no qualification by attribution — narrowing it inside the design would be the design overruling the requirement, which the provenance split exists to prevent. Two mitigations ARE in this slice: by is documented as an unverified self-report, and annulled_count in default read output keeps an annulment visible at a human touchpoint without opting into history. Note also that it grants no NEW capability — an autonomous run can already self-answer a gate through /dev:resolve's structured mode. It is a real product-and-security question that deserves deciding on its own merits, so it warrants a sibling issue rather than a silent narrowing here.

Disposition rationale: This is the one finding with genuine open substance. The security lens raised it as blocking; it was not actioned inside the design because AC-7 states without qualification that an annulled outcome's blocking decisions stop blocking, and narrowing that inside the SREQ would be the design overruling the requirement. Two mitigations did land in this slice — by is documented as an unverified self-report, and annulled_count keeps an annulment visible in default read output at a human touchpoint. It also grants no NEW capability: an autonomous run can already self-answer a gate through /dev:resolve's structured mode. That combination makes it a real product-and-security question that deserves deciding on its own evidence rather than being settled as a side effect of this feature's design. Resolved under the operator's standing instruction of 2026-08-26 ("resolve all decisions as recommended"), which is the authority for taking each producer recommendation as given.

This issue was deferred out of the parent feature's scope; it carries no PREQ yet. Run /dev:requirements --issue={new-number} to flesh it out before planning.

Spawned from finding `F-PO-45-2-7` (in-scope-deferrable) on issue #45 during decision D-PO-45-2-7. **Original scope note:** Reviewer suggestion acknowledged but not actioned in this SREQ — see Expert Review > Noted (not actioned). The security lens raised it as blocking. It is NOT actioned here because AC-7 states plainly that an annulled outcome's open blocking decisions stop blocking, with no qualification by attribution — narrowing it inside the design would be the design overruling the requirement, which the provenance split exists to prevent. Two mitigations ARE in this slice: `by` is documented as an unverified self-report, and `annulled_count` in default read output keeps an annulment visible at a human touchpoint without opting into history. Note also that it grants no NEW capability — an autonomous run can already self-answer a gate through /dev:resolve's structured mode. It is a real product-and-security question that deserves deciding on its own merits, so it warrants a sibling issue rather than a silent narrowing here. **Disposition rationale:** This is the one finding with genuine open substance. The security lens raised it as blocking; it was not actioned inside the design because AC-7 states without qualification that an annulled outcome's blocking decisions stop blocking, and narrowing that inside the SREQ would be the design overruling the requirement. Two mitigations did land in this slice — `by` is documented as an unverified self-report, and `annulled_count` keeps an annulment visible in default read output at a human touchpoint. It also grants no NEW capability: an autonomous run can already self-answer a gate through /dev:resolve's structured mode. That combination makes it a real product-and-security question that deserves deciding on its own evidence rather than being settled as a side effect of this feature's design. Resolved under the operator's standing instruction of 2026-08-26 ("resolve all decisions as recommended"), which is the authority for taking each producer recommendation as given. This issue was deferred out of the parent feature's scope; it carries no PREQ yet. Run `/dev:requirements --issue={new-number}` to flesh it out before planning.

jbr870 added the

labels

2026-08-26 16:20:23 +00:00

jbr870 referenced this issue

2026-08-26 16:20:24 +00:00

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