Two things about #31 that a cockpit-side session can see but a night-shift session would not, so recording them here where the work happens.
1. It is CONFLICTING, not just unreviewed
#31 (chore/security-task-tighten, opened 2026-06-15) has been open seven weeks and is now mergeable: CONFLICTING. It needs a rebase before it can be reviewed at all — so "it just needs a review nudge" is wrong, and anyone picking it up should budget for the rebase first.
It implements all three core asks of the cockpit-side issue that tracks it (threat-actor gate, HSTS-never-bundles, source-layer-first), so it is worth the rebase rather than a rewrite.
2. Its central rule contradicts the bundler, today
#31 encodes HSTS-class-never-bundles. But tasks/morning-ns-bundle.md (dev-cockpit) and workspace canon both classify "security headers" as low-stakes — the bucket that gets bundled automatically every weekday.
So right now the daily bundler can absorb an HSTS-preload commit as routine housekeeping. A preload submission cannot be walked back on a client domain, which makes this the one bundling error with no cheap undo.
Interim mitigation is already in place, cockpit-side: a new verify-ns-bundle job fails any bundle whose diff adds Strict-Transport-Security / hsts / preload, in bash before the model runs. That takes the strict reading deliberately, as a tiebreak — it is not a decision about which document is right.
What is still needed here: the two documents have to agree. Either "security headers" gets split in the low-stakes definition (headers yes, HSTS/preload no), or #31's rule moves into the bundler's own classification step. Until then the mitigation is a patch over a contradiction rather than a resolution.
Filed from the dev-cockpit session, which does not own this repo. Cockpit-side context: havardljohansen/dev-cockpit#71.
Two things about #31 that a cockpit-side session can see but a night-shift session would not, so recording them here where the work happens.
1. It is CONFLICTING, not just unreviewed
#31 (
chore/security-task-tighten, opened 2026-06-15) has been open seven weeks and is nowmergeable: CONFLICTING. It needs a rebase before it can be reviewed at all — so "it just needs a review nudge" is wrong, and anyone picking it up should budget for the rebase first.It implements all three core asks of the cockpit-side issue that tracks it (threat-actor gate, HSTS-never-bundles, source-layer-first), so it is worth the rebase rather than a rewrite.
2. Its central rule contradicts the bundler, today
#31 encodes HSTS-class-never-bundles. But
tasks/morning-ns-bundle.md(dev-cockpit) and workspace canon both classify "security headers" as low-stakes — the bucket that gets bundled automatically every weekday.So right now the daily bundler can absorb an HSTS-preload commit as routine housekeeping. A preload submission cannot be walked back on a client domain, which makes this the one bundling error with no cheap undo.
Interim mitigation is already in place, cockpit-side: a new
verify-ns-bundlejob fails any bundle whose diff addsStrict-Transport-Security/hsts/preload, in bash before the model runs. That takes the strict reading deliberately, as a tiebreak — it is not a decision about which document is right.What is still needed here: the two documents have to agree. Either "security headers" gets split in the low-stakes definition (headers yes, HSTS/preload no), or #31's rule moves into the bundler's own classification step. Until then the mitigation is a patch over a contradiction rather than a resolution.
Filed from the dev-cockpit session, which does not own this repo. Cockpit-side context: havardljohansen/dev-cockpit#71.