cycle.py and records.py both fail on main as it stands, on the same record — 0115-one-assignment-of-a-module-per-node.md, merged in #133.
cycle: an accepted decision nothing in the cycle cites
records: rests on ADR 0112, which is 'proposed'
Three lines fix both.
Nothing cites it
Design 27 already states the rule the record decides, at line 195: "A module is assigned at most once to a node, and that pair is the assignment's identity." It is the home; it just never said so in its frontmatter. #132 amended that document in the same batch, which is likely where the line got dropped.
decisions: now names the record, and the generated index picks up the row it was missing.
It rests on a proposed record
0112, 0113, 0114 and design 27 are all proposed — one batch under review. 0115 was marked accepted while extending 0112, which is what records.py refuses.
The record moves to proposed to match its batch, rather than 0112 moving to accepted. check_rests_on explicitly allows a proposed record to extend a proposed one, and its comment says why the other direction is wrong:
refusing that would mean either drafting out of order or marking records accepted to satisfy a check, which is the failure this repository already made once.
Promoting 0112 would also implicitly accept design 27's whole direction, which is a review decision, not a check-fixing one.
If the batch really was accepted, this is the wrong fix and the right one is larger — accept 0112, 0113, 0114 and design 27 together, deliberately. Say so and I'll redo it that way.
Checks
All three green: 291 documents, 105 records, index current.
Found while rebasing #134, which had to renumber its own record to 0116 after this one took 0115. Kept separate per one change per pull request.
`cycle.py` and `records.py` both fail on `main` as it stands, on the same record — `0115-one-assignment-of-a-module-per-node.md`, merged in #133.
```
cycle: an accepted decision nothing in the cycle cites
records: rests on ADR 0112, which is 'proposed'
```
Three lines fix both.
## Nothing cites it
Design 27 already states the rule the record decides, at line 195: *"A module is assigned at most once to a node, and that pair is the assignment's identity."* It is the home; it just never said so in its frontmatter. #132 amended that document in the same batch, which is likely where the line got dropped.
`decisions:` now names the record, and the generated index picks up the row it was missing.
## It rests on a proposed record
`0112`, `0113`, `0114` and design 27 are all `proposed` — one batch under review. `0115` was marked `accepted` while extending `0112`, which is what `records.py` refuses.
**The record moves to `proposed` to match its batch**, rather than `0112` moving to `accepted`. `check_rests_on` explicitly allows a proposed record to extend a proposed one, and its comment says why the other direction is wrong:
> refusing that would mean either drafting out of order or marking records accepted to satisfy a check, which is the failure this repository already made once.
Promoting `0112` would also implicitly accept design 27's whole direction, which is a review decision, not a check-fixing one.
**If the batch really was accepted**, this is the wrong fix and the right one is larger — accept `0112`, `0113`, `0114` and design 27 together, deliberately. Say so and I'll redo it that way.
## Checks
All three green: 291 documents, 105 records, index current.
Found while rebasing #134, which had to renumber its own record to 0116 after this one took 0115. Kept separate per one change per pull request.
Both repository checks fail on main. 0115 is cited by no design, and it is
marked accepted while resting on 0112, which is proposed.
Design 27 already states the rule the record decides — "a module is assigned
at most once to a node, and that pair is the assignment's identity" — so it
is the home, and now says so. And 0112, 0113, 0114 and design 27 are all
proposed: the batch is under review, so the record is too. Promoting 0112
instead would be marking a record accepted to satisfy a check, which
check_rests_on names as a failure this repository already made once.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
cycle.pyandrecords.pyboth fail onmainas it stands, on the same record —0115-one-assignment-of-a-module-per-node.md, merged in #133.Three lines fix both.
Nothing cites it
Design 27 already states the rule the record decides, at line 195: "A module is assigned at most once to a node, and that pair is the assignment's identity." It is the home; it just never said so in its frontmatter. #132 amended that document in the same batch, which is likely where the line got dropped.
decisions:now names the record, and the generated index picks up the row it was missing.It rests on a proposed record
0112,0113,0114and design 27 are allproposed— one batch under review.0115was markedacceptedwhile extending0112, which is whatrecords.pyrefuses.The record moves to
proposedto match its batch, rather than0112moving toaccepted.check_rests_onexplicitly allows a proposed record to extend a proposed one, and its comment says why the other direction is wrong:Promoting
0112would also implicitly accept design 27's whole direction, which is a review decision, not a check-fixing one.If the batch really was accepted, this is the wrong fix and the right one is larger — accept
0112,0113,0114and design 27 together, deliberately. Say so and I'll redo it that way.Checks
All three green: 291 documents, 105 records, index current.
Found while rebasing #134, which had to renumber its own record to 0116 after this one took 0115. Kept separate per one change per pull request.