From d71fdc25eca93694a9bcb3135bcc45bb7c7dcefd Mon Sep 17 00:00:00 2001 From: sepehr-safari Date: Sat, 8 Aug 2026 10:40:53 +0300 Subject: [PATCH] docs: bring CURRENT_STATE forward after #161 and fix the stale ID allocation The station ID allocation claimed 017 was reserved for #108. It was not: refused-authorization.ts took CS-SYNTHETIC-017 when it shipped in 0.4.5, after that line was written, so anyone following #108 would have created the same collision #133 did. #108 now reserves 021, and the line records live allocation with the next free number. Corrects rule coverage from two uncovered rules to one, verified by iterating the registry rather than by reading: 15 of the 16 codes appear in some scenario's expectedFailures and REPEATED_BOOT_NOTIFICATION is the only gap. Corrects the corpus arithmetic from 17 to 19. Records this week: #161 merged as the third external contributor's first merge, both remaining scenario issues assigned, the #108 trap caught before the contributor started, #163 opened for the assertions-coverage gap, and the release automation from #152 handling 0.4.5 unattended. Closes #164 --- CURRENT_STATE.md | 44 ++++++++++++++++++++++++++++++++++---------- 1 file changed, 34 insertions(+), 10 deletions(-) diff --git a/CURRENT_STATE.md b/CURRENT_STATE.md index 1ee2b76..ac047c6 100644 --- a/CURRENT_STATE.md +++ b/CURRENT_STATE.md @@ -385,7 +385,7 @@ these fixes introduce is required across detection. IDs are documented as unique per scenario - ✅ Good-first-issues carry a one-open-claim-at-a-time policy -### External Contribution Pipeline (2026-07-26 to 2026-07-30) +### External Contribution Pipeline (2026-07-26 to 2026-08-08) - ✅ Second `good-first-issue` completed by an outside contributor: #133 for #104, shipped in `0.4.3`. The scenario registry is at 16. Two of the five @@ -405,8 +405,11 @@ these fixes introduce is required across detection. only on negative or decreasing cumulative readings, and a flat series is neither. - ✅ Station IDs allocated per issue so parallel work cannot collide: - `CS-SYNTHETIC-016` shipped in #133, `017` to #108, `018` to #137, `019` - shipped in #147, `020` to #139. + `CS-SYNTHETIC-016` shipped in #133, `018` shipped in #161, `019` shipped in + #147, `020` reserved for #139, `021` reserved for #108. `017` is NOT free: + `refused-authorization.ts` took it in `0.4.5`, which is why #108 moved off it. + Live allocation is 004 through 019 in use, 020 and 021 reserved, so the next + free number is 022. - ✅ #140 landed (PR #148): the standing invariant that every detection rule ships with a scenario in the same PR, added to `CONTRIBUTING.md` as a statement and as step 7 of the rule checklist. This is what stops the coverage gap @@ -420,15 +423,36 @@ these fixes introduce is required across detection. for OCPP 2.0.1. - ✅ Third external contributor arrived (`MayurK-cmd`), assigned #137 (`heartbeat-timeout`). #139 held for them next under the one-claim policy. +- ✅ Fourth `good-first-issue` completed and the third external contributor's + first merge: #137 (`heartbeat-timeout`) by `MayurK-cmd` (Issue #137, PR #161). + The registry is at 19. They also picked up a missing + `getScenario('refused-authorization')` assertion that PR #159 left behind, which + was not asked for and was correct. +- ✅ Both remaining scenario issues are now assigned: #139 to `MayurK-cmd` under + the promise made when they claimed two at once, and #108 to + `YANGCHUNHONG3000`, their third. +- ✅ #108 carried a live trap, caught before the contributor started: it reserved + `CS-SYNTHETIC-017`, which `refused-authorization.ts` had already consumed in + `0.4.5`. Anyone following the issue would have created the same collision #133 + did. Moved to `CS-SYNTHETIC-021`. +- ✅ The release automation from #152 proved itself unattended: `0.4.5` was logged + and the Package Status Table moved with no manual step. Only the narrative here + still needs a human, which is the split by design. - 🔜 #144 proposes a `METER_VALUE_STUCK` rule for a register that never advances, the positive counterpart to #108. - -Rule coverage: after #147, two of the sixteen detection rules still lack a -scenario, `TIMEOUT_NO_HEARTBEAT` (#137, assigned) and `REPEATED_BOOT_NOTIFICATION` -(#139, open). - -Scenario arithmetic to the v1.0 target of 20+: 17 today, plus #108, #137 and #139 -lands at 20, at which point all 16 detection rules are covered. +- 🔜 #163 records that CI never evaluates the scenarios' declared `assertions`. + `evaluateScenario` reaches the registry only through `ocpp-debugkit ci`, which + is not a workflow step, and the one test that touches it builds its scenarios by + hand. Nine scenario files assert things nothing verifies. Found while reviewing + #161; pre-existing and unrelated to that contribution. + +Rule coverage: after #161, one of the sixteen detection rules still lacks a +scenario. Verified by iterating the registry, 15 of the 16 codes appear in some +scenario's `expectedFailures`, and `REPEATED_BOOT_NOTIFICATION` (#139, assigned) +is the sole gap. + +Scenario arithmetic to the v1.0 target of 20+: 19 today, and #108 plus #139 take +it to 21, at which point all 16 detection rules are covered. ### Release Log Automation (Issue #151, PR #152)