Skip to content

The board's double-claim warning counts only plans still in flight - #77

Merged
Tradebaas merged 1 commit into
mainfrom
fix/double-claim-counts-plans-in-flight
Aug 9, 2026
Merged

The board's double-claim warning counts only plans still in flight#77
Tradebaas merged 1 commit into
mainfrom
fix/double-claim-counts-plans-in-flight

Conversation

@Tradebaas

Copy link
Copy Markdown
Owner

What changed and why

The board warned that a scope item is being worked on from 2 plans at once whenever two specs
named it, a finished one included. That is not what the sentence says, and not what a reader needs.
An item worth two rounds of work carries two specs forever, so the heads-up would stand for the
life of the project and teach the reader to skim the one place the board raises its voice.

Closing spec 011 made it concrete. SC-8 was shipped first by the archived baseline spec 000 and has
been owned by 011 since, both done, and no ordering of those two would ever clear the line. The
alternative on the table was dropping SC-8 from 000's Traces to:, which edits what the baseline
says it shipped; the owner chose to fix the gate instead, so the historical record stays as it was.

A later spec supersedes an earlier claim, which is ordinary history. The clash worth reporting is
two unfinished plans on one item, where nobody has decided yet who owns it. The warning now
counts only the specs that have not finished, and names those.

The item's own state is untouched: the furthest spec still wins, so an item one plan already
shipped keeps reading done while a second plan reworks it.

Evidence

  • Three self-tests hold the rule from both sides: two unfinished plans still warn, a finished plan
    plus a later one in flight does not, and two finished plans are history rather than a clash.
  • Two older fixtures paired a building spec with a done one to exercise the clash. That pairing
    is no longer one, so both moved to two unfinished specs rather than being deleted.
  • On this repo: node checks/progress.mjs now prints no heads-up and still reads 12 of the 12
    things done, exit 0.
  • Gates: check.mjs OK, progress 27 (25 before, three added, one rewritten), links 19, cockpit 21,
    code 35.

Scope

One gate and its suite. No document changes: docs/state/STATE.local.md is gitignored and carries
the decision on the maintainer side.

Traces-to: SC-10

…clash

The board warned that a scope item "is being worked on from 2 plans at once" whenever two specs
named it, a finished one included. That is not what the sentence says and not what a reader needs:
an item worth two rounds of work carries two specs forever, so the heads-up would stand for the
life of the project and teach the reader to skim the one place the board raises its voice. Closing
spec 011 made it concrete: SC-8 was shipped first by the archived baseline and owned since by 011,
both done, and no ordering of those two would ever clear the line.

A later spec supersedes an earlier claim, which is ordinary history. The clash worth reporting is
two unfinished plans on one item, where nobody has decided yet who owns it, so the warning now
counts only the specs that have not finished, and names those. The item's own state is untouched:
the furthest spec still wins, so an item one plan already shipped keeps reading done while a
second plan reworks it.

Three self-tests hold the rule from both sides: two unfinished plans still warn, a finished plan
plus a later one in flight does not, and two finished plans are history rather than a clash. The
two older fixtures that paired a building spec with a done one moved to two unfinished specs,
because they were written to exercise the clash and that pairing is no longer one.

Traces-to: SC-10
@Tradebaas
Tradebaas merged commit 48161f3 into main Aug 9, 2026
8 checks passed
@Tradebaas
Tradebaas deleted the fix/double-claim-counts-plans-in-flight branch August 9, 2026 11:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant