Skip to content

[finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds #13642

Open
Open
[finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds#13642
Labels
domain:devxpm:queuepriority:p2Medium: important, M3tooling

Description

@os-steve
os-steve
opened on Aug 31, 2026

Filed by the domain:services PM seat (session session_016ZC5rNQj3WEet5HAmmAkMs), 2026-08-31. Unassigned, ungraded — ⛔ no domain:*, no priority. Recommended lane: domain:devx (the producer is scripts/pm/dispatch-gates.mjs).

⚠️This is NOT a derivation gap. Both suspected gaps were measured and both were false — the tool derived the family correctly each time. The defect is on the consumption side, and it is filed because it recurred twice in one night across independent agents, which is a property of the output rather than of either reader.

The two occurrences, hours apart, different devs, different cards

card / PRwhat was missedwhat actually happened
1#11974 / PR #13514check:system-context-censusThe dev reported 15 derived families, that gate not among them; CI reddened on it. Its own correction: "dispatch-gates.mjs DID derive the census gate; this seat's extraction regex dropped all node-spelled gate lines — seat error, not a tooling defect."
2#13546 / PR #13565check:engine-double-contractThe dev reported 14 derived families, that gate not among them; CI reddened on it. Its own correction: "the original derivation output DID name it in its whole-tree kind-gates section; my extraction grepped only the path-derived block's indentation and dropped the kind section."

⭐ Both devs classified it as their own error, and both were being scrupulous in doing so. But two independent agents making the same class of mistake on the same tool in one night is evidence about the artifact they were both reading.

⚠️ Third data point, same night: the dispatching PM (this seat) propagated occurrence 1 as a suspected tooling gap and instructed the dev to consider filing against dispatch-gates.mjs. That would have been a bogus card. Three readers, one output, three misreadings — one of which nearly became a wrong bug report.

The shape of the defect

The output carries at least two structurally different sections:

  • a path-derived block, indented, listing families matched via a changed path;
  • a whole-tree / kind-gates section, differently shaped, carrying families triggered by the kind of thing the diff contains (occurrence 2's own words: "a new double, or a new test file carrying one, moves it").

⇒ A reader who extracts "the list of gates to run" by matching one section's shape gets a strict subset and cannot tell. And the failure is exactly the wrong shape to be caught:

  1. It is silent. The run reports N families, all green. Nothing says a section was skipped.
  2. It presents as completed work. The report reads "14 families derived, 14 green" — an honest sentence about an incomplete set.
  3. It costs a full CI cycle plus a patch round, and it lands on a PR that is otherwise finished.
  4. ⚠️It defeats the discipline built to prevent exactly this. These devs re-derived from the tree rather than from memory — the correct practice — and still under-ran, because the derivation was right and the reading was lossy.

Suggested shape, not a prescription

The goal is to make the complete family set impossible to under-read:

  • A machine-readable mode — e.g. --json, or a single flat ALL FAMILIES: block that is the whole answer regardless of why each family was pulled in. Consumers then have one thing to read, and the sectioning stays human-facing commentary.
  • Or an explicit count line the consumer can assert against ("N families total: P path-derived, K kind-derived"), so a partial extraction is detectable rather than plausible.
  • ⛔ Do not fix this by asking readers to read more carefully. That was already the standing instruction and it failed twice in one night. This is the 可机械化项 limb: the remedy belongs in the output, ⛔ not in more prose telling agents to be thorough.

What this does NOT claim

  • ⛔ No claim that any derivation is wrong. Twice suspected, twice measured false. The tool derives correctly; consumers under-read it.
  • ⛔ No claim about frequency beyond what was observed — two occurrences, one night, in this lane alone. Whether other lanes hit it is unmeasured, and ⚠️ by construction it is invisible when it happens: the only symptom is a CI red on a family the local run never mentioned. Any count is a lower bound.
  • ⛔ No severity asserted. The observed cost each time was one patch round on a finished PR; whether that warrants priority is triage's call.

Refs: PR #13514 (occurrence 1) · PR #13565 (occurrence 2, its correction in 13546#issuecomment-5473759170) · scripts/pm/dispatch-gates.mjs · #13511 / #13519 / #13536 (other open dispatch-gates findings — all producer-side; this one is consumption-side and does not overlap them)

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain:devxpm:queuepriority:p2Medium: important, M3tooling

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
     blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
[finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds · Issue #13642 · objectstack-ai/objectstack · GitHub
    Skip to content
    [finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds #13642
    Open
    Open
    [finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds#13642
    Labels
    domain:devxpm:queuepriority:p2Medium: important, M3tooling
    Description
    @os-steve
    os-steve
    opened on Aug 31, 2026
    Filed by the domain:services PM seat (session session_016ZC5rNQj3WEet5HAmmAkMs), 2026-08-31. Unassigned, ungraded — ⛔ no domain:*, no priority. Recommended lane: domain:devx (the producer is scripts/pm/dispatch-gates.mjs).
    ⚠️This is NOT a derivation gap. Both suspected gaps were measured and both were false — the tool derived the family correctly each time. The defect is on the consumption side, and it is filed because it recurred twice in one night across independent agents, which is a property of the output rather than of either reader.
    The two occurrences, hours apart, different devs, different cards
    card / PRwhat was missedwhat actually happened
    1#11974 / PR #13514check:system-context-censusThe dev reported 15 derived families, that gate not among them; CI reddened on it. Its own correction: "dispatch-gates.mjs DID derive the census gate; this seat's extraction regex dropped all node-spelled gate lines — seat error, not a tooling defect."
    2#13546 / PR #13565check:engine-double-contractThe dev reported 14 derived families, that gate not among them; CI reddened on it. Its own correction: "the original derivation output DID name it in its whole-tree kind-gates section; my extraction grepped only the path-derived block's indentation and dropped the kind section."
    ⭐ Both devs classified it as their own error, and both were being scrupulous in doing so. But two independent agents making the same class of mistake on the same tool in one night is evidence about the artifact they were both reading.
    ⚠️ Third data point, same night: the dispatching PM (this seat) propagated occurrence 1 as a suspected tooling gap and instructed the dev to consider filing against dispatch-gates.mjs. That would have been a bogus card. Three readers, one output, three misreadings — one of which nearly became a wrong bug report.
    The shape of the defect
    The output carries at least two structurally different sections:
    • a path-derived block, indented, listing families matched via a changed path;
    • a whole-tree / kind-gates section, differently shaped, carrying families triggered by the kind of thing the diff contains (occurrence 2's own words: "a new double, or a new test file carrying one, moves it").
    ⇒ A reader who extracts "the list of gates to run" by matching one section's shape gets a strict subset and cannot tell. And the failure is exactly the wrong shape to be caught:
    1. It is silent. The run reports N families, all green. Nothing says a section was skipped.
    2. It presents as completed work. The report reads "14 families derived, 14 green" — an honest sentence about an incomplete set.
    3. It costs a full CI cycle plus a patch round, and it lands on a PR that is otherwise finished.
    4. ⚠️It defeats the discipline built to prevent exactly this. These devs re-derived from the tree rather than from memory — the correct practice — and still under-ran, because the derivation was right and the reading was lossy.
    Suggested shape, not a prescription
    The goal is to make the complete family set impossible to under-read:
    • A machine-readable mode — e.g. --json, or a single flat ALL FAMILIES: block that is the whole answer regardless of why each family was pulled in. Consumers then have one thing to read, and the sectioning stays human-facing commentary.
    • Or an explicit count line the consumer can assert against ("N families total: P path-derived, K kind-derived"), so a partial extraction is detectable rather than plausible.
    • ⛔ Do not fix this by asking readers to read more carefully. That was already the standing instruction and it failed twice in one night. This is the 可机械化项 limb: the remedy belongs in the output, ⛔ not in more prose telling agents to be thorough.
    What this does NOT claim
    • ⛔ No claim that any derivation is wrong. Twice suspected, twice measured false. The tool derives correctly; consumers under-read it.
    • ⛔ No claim about frequency beyond what was observed — two occurrences, one night, in this lane alone. Whether other lanes hit it is unmeasured, and ⚠️ by construction it is invisible when it happens: the only symptom is a CI red on a family the local run never mentioned. Any count is a lower bound.
    • ⛔ No severity asserted. The observed cost each time was one patch round on a finished PR; whether that warrants priority is triage's call.
    Refs: PR #13514 (occurrence 1) · PR #13565 (occurrence 2, its correction in 13546#issuecomment-5473759170) · scripts/pm/dispatch-gates.mjs · #13511 / #13519 / #13536 (other open dispatch-gates findings — all producer-side; this one is consumption-side and does not overlap them)
    Metadata
    Metadata
    Assignees
    No one assigned
      Labels
      domain:devxpm:queuepriority:p2Medium: important, M3tooling
      Type
      No type
      Projects
      No projects
      Milestone
      No milestone
      Relationships
      None yet
      Development
      No branches or pull requests
      Issue actions
      
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds · Issue #13642 · objectstack-ai/objectstack · GitHub
      Skip to content
      [finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds #13642
      Open
      Open
      [finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds#13642
      Labels
      domain:devxpm:queuepriority:p2Medium: important, M3tooling
      Description
      @os-steve
      os-steve
      opened on Aug 31, 2026
      Filed by the domain:services PM seat (session session_016ZC5rNQj3WEet5HAmmAkMs), 2026-08-31. Unassigned, ungraded — ⛔ no domain:*, no priority. Recommended lane: domain:devx (the producer is scripts/pm/dispatch-gates.mjs).
      ⚠️This is NOT a derivation gap. Both suspected gaps were measured and both were false — the tool derived the family correctly each time. The defect is on the consumption side, and it is filed because it recurred twice in one night across independent agents, which is a property of the output rather than of either reader.
      The two occurrences, hours apart, different devs, different cards
      card / PRwhat was missedwhat actually happened
      1#11974 / PR #13514check:system-context-censusThe dev reported 15 derived families, that gate not among them; CI reddened on it. Its own correction: "dispatch-gates.mjs DID derive the census gate; this seat's extraction regex dropped all node-spelled gate lines — seat error, not a tooling defect."
      2#13546 / PR #13565check:engine-double-contractThe dev reported 14 derived families, that gate not among them; CI reddened on it. Its own correction: "the original derivation output DID name it in its whole-tree kind-gates section; my extraction grepped only the path-derived block's indentation and dropped the kind section."
      ⭐ Both devs classified it as their own error, and both were being scrupulous in doing so. But two independent agents making the same class of mistake on the same tool in one night is evidence about the artifact they were both reading.
      ⚠️ Third data point, same night: the dispatching PM (this seat) propagated occurrence 1 as a suspected tooling gap and instructed the dev to consider filing against dispatch-gates.mjs. That would have been a bogus card. Three readers, one output, three misreadings — one of which nearly became a wrong bug report.
      The shape of the defect
      The output carries at least two structurally different sections:
      • a path-derived block, indented, listing families matched via a changed path;
      • a whole-tree / kind-gates section, differently shaped, carrying families triggered by the kind of thing the diff contains (occurrence 2's own words: "a new double, or a new test file carrying one, moves it").
      ⇒ A reader who extracts "the list of gates to run" by matching one section's shape gets a strict subset and cannot tell. And the failure is exactly the wrong shape to be caught:
      1. It is silent. The run reports N families, all green. Nothing says a section was skipped.
      2. It presents as completed work. The report reads "14 families derived, 14 green" — an honest sentence about an incomplete set.
      3. It costs a full CI cycle plus a patch round, and it lands on a PR that is otherwise finished.
      4. ⚠️It defeats the discipline built to prevent exactly this. These devs re-derived from the tree rather than from memory — the correct practice — and still under-ran, because the derivation was right and the reading was lossy.
      Suggested shape, not a prescription
      The goal is to make the complete family set impossible to under-read:
      • A machine-readable mode — e.g. --json, or a single flat ALL FAMILIES: block that is the whole answer regardless of why each family was pulled in. Consumers then have one thing to read, and the sectioning stays human-facing commentary.
      • Or an explicit count line the consumer can assert against ("N families total: P path-derived, K kind-derived"), so a partial extraction is detectable rather than plausible.
      • ⛔ Do not fix this by asking readers to read more carefully. That was already the standing instruction and it failed twice in one night. This is the 可机械化项 limb: the remedy belongs in the output, ⛔ not in more prose telling agents to be thorough.
      What this does NOT claim
      • ⛔ No claim that any derivation is wrong. Twice suspected, twice measured false. The tool derives correctly; consumers under-read it.
      • ⛔ No claim about frequency beyond what was observed — two occurrences, one night, in this lane alone. Whether other lanes hit it is unmeasured, and ⚠️ by construction it is invisible when it happens: the only symptom is a CI red on a family the local run never mentioned. Any count is a lower bound.
      • ⛔ No severity asserted. The observed cost each time was one patch round on a finished PR; whether that warrants priority is triage's call.
      Refs: PR #13514 (occurrence 1) · PR #13565 (occurrence 2, its correction in 13546#issuecomment-5473759170) · scripts/pm/dispatch-gates.mjs · #13511 / #13519 / #13536 (other open dispatch-gates findings — all producer-side; this one is consumption-side and does not overlap them)
      Metadata
      Metadata
      Assignees
      No one assigned
        Labels
        domain:devxpm:queuepriority:p2Medium: important, M3tooling
        Type
        No type
        Projects
        No projects
        Milestone
        No milestone
        Relationships
        None yet
        Development
        No branches or pull requests
        Issue actions
        
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds · Issue #13642 · objectstack-ai/objectstack · GitHub
        Skip to content
        [finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds #13642
        Open
        Open
        [finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds#13642
        Labels
        domain:devxpm:queuepriority:p2Medium: important, M3tooling
        Description
        @os-steve
        os-steve
        opened on Aug 31, 2026
        Filed by the domain:services PM seat (session session_016ZC5rNQj3WEet5HAmmAkMs), 2026-08-31. Unassigned, ungraded — ⛔ no domain:*, no priority. Recommended lane: domain:devx (the producer is scripts/pm/dispatch-gates.mjs).
        ⚠️This is NOT a derivation gap. Both suspected gaps were measured and both were false — the tool derived the family correctly each time. The defect is on the consumption side, and it is filed because it recurred twice in one night across independent agents, which is a property of the output rather than of either reader.
        The two occurrences, hours apart, different devs, different cards
        card / PRwhat was missedwhat actually happened
        1#11974 / PR #13514check:system-context-censusThe dev reported 15 derived families, that gate not among them; CI reddened on it. Its own correction: "dispatch-gates.mjs DID derive the census gate; this seat's extraction regex dropped all node-spelled gate lines — seat error, not a tooling defect."
        2#13546 / PR #13565check:engine-double-contractThe dev reported 14 derived families, that gate not among them; CI reddened on it. Its own correction: "the original derivation output DID name it in its whole-tree kind-gates section; my extraction grepped only the path-derived block's indentation and dropped the kind section."
        ⭐ Both devs classified it as their own error, and both were being scrupulous in doing so. But two independent agents making the same class of mistake on the same tool in one night is evidence about the artifact they were both reading.
        ⚠️ Third data point, same night: the dispatching PM (this seat) propagated occurrence 1 as a suspected tooling gap and instructed the dev to consider filing against dispatch-gates.mjs. That would have been a bogus card. Three readers, one output, three misreadings — one of which nearly became a wrong bug report.
        The shape of the defect
        The output carries at least two structurally different sections:
        • a path-derived block, indented, listing families matched via a changed path;
        • a whole-tree / kind-gates section, differently shaped, carrying families triggered by the kind of thing the diff contains (occurrence 2's own words: "a new double, or a new test file carrying one, moves it").
        ⇒ A reader who extracts "the list of gates to run" by matching one section's shape gets a strict subset and cannot tell. And the failure is exactly the wrong shape to be caught:
        1. It is silent. The run reports N families, all green. Nothing says a section was skipped.
        2. It presents as completed work. The report reads "14 families derived, 14 green" — an honest sentence about an incomplete set.
        3. It costs a full CI cycle plus a patch round, and it lands on a PR that is otherwise finished.
        4. ⚠️It defeats the discipline built to prevent exactly this. These devs re-derived from the tree rather than from memory — the correct practice — and still under-ran, because the derivation was right and the reading was lossy.
        Suggested shape, not a prescription
        The goal is to make the complete family set impossible to under-read:
        • A machine-readable mode — e.g. --json, or a single flat ALL FAMILIES: block that is the whole answer regardless of why each family was pulled in. Consumers then have one thing to read, and the sectioning stays human-facing commentary.
        • Or an explicit count line the consumer can assert against ("N families total: P path-derived, K kind-derived"), so a partial extraction is detectable rather than plausible.
        • ⛔ Do not fix this by asking readers to read more carefully. That was already the standing instruction and it failed twice in one night. This is the 可机械化项 limb: the remedy belongs in the output, ⛔ not in more prose telling agents to be thorough.
        What this does NOT claim
        • ⛔ No claim that any derivation is wrong. Twice suspected, twice measured false. The tool derives correctly; consumers under-read it.
        • ⛔ No claim about frequency beyond what was observed — two occurrences, one night, in this lane alone. Whether other lanes hit it is unmeasured, and ⚠️ by construction it is invisible when it happens: the only symptom is a CI red on a family the local run never mentioned. Any count is a lower bound.
        • ⛔ No severity asserted. The observed cost each time was one patch round on a finished PR; whether that warrants priority is triage's call.
        Refs: PR #13514 (occurrence 1) · PR #13565 (occurrence 2, its correction in 13546#issuecomment-5473759170) · scripts/pm/dispatch-gates.mjs · #13511 / #13519 / #13536 (other open dispatch-gates findings — all producer-side; this one is consumption-side and does not overlap them)
        Metadata
        Metadata
        Assignees
        No one assigned
          Labels
          domain:devxpm:queuepriority:p2Medium: important, M3tooling
          Type
          No type
          Projects
          No projects
          Milestone
          No milestone
          Relationships
          None yet
          Development
          No branches or pull requests
          Issue actions
          
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
[finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds · Issue #13642 · objectstack-ai/objectstack · GitHub
          Skip to content
          [finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds #13642
          Open
          Open
          [finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds#13642
          Labels
          domain:devxpm:queuepriority:p2Medium: important, M3tooling
          Description
          @os-steve
          os-steve
          opened on Aug 31, 2026
          Filed by the domain:services PM seat (session session_016ZC5rNQj3WEet5HAmmAkMs), 2026-08-31. Unassigned, ungraded — ⛔ no domain:*, no priority. Recommended lane: domain:devx (the producer is scripts/pm/dispatch-gates.mjs).
          ⚠️This is NOT a derivation gap. Both suspected gaps were measured and both were false — the tool derived the family correctly each time. The defect is on the consumption side, and it is filed because it recurred twice in one night across independent agents, which is a property of the output rather than of either reader.
          The two occurrences, hours apart, different devs, different cards
          card / PRwhat was missedwhat actually happened
          1#11974 / PR #13514check:system-context-censusThe dev reported 15 derived families, that gate not among them; CI reddened on it. Its own correction: "dispatch-gates.mjs DID derive the census gate; this seat's extraction regex dropped all node-spelled gate lines — seat error, not a tooling defect."
          2#13546 / PR #13565check:engine-double-contractThe dev reported 14 derived families, that gate not among them; CI reddened on it. Its own correction: "the original derivation output DID name it in its whole-tree kind-gates section; my extraction grepped only the path-derived block's indentation and dropped the kind section."
          ⭐ Both devs classified it as their own error, and both were being scrupulous in doing so. But two independent agents making the same class of mistake on the same tool in one night is evidence about the artifact they were both reading.
          ⚠️ Third data point, same night: the dispatching PM (this seat) propagated occurrence 1 as a suspected tooling gap and instructed the dev to consider filing against dispatch-gates.mjs. That would have been a bogus card. Three readers, one output, three misreadings — one of which nearly became a wrong bug report.
          The shape of the defect
          The output carries at least two structurally different sections:
          • a path-derived block, indented, listing families matched via a changed path;
          • a whole-tree / kind-gates section, differently shaped, carrying families triggered by the kind of thing the diff contains (occurrence 2's own words: "a new double, or a new test file carrying one, moves it").
          ⇒ A reader who extracts "the list of gates to run" by matching one section's shape gets a strict subset and cannot tell. And the failure is exactly the wrong shape to be caught:
          1. It is silent. The run reports N families, all green. Nothing says a section was skipped.
          2. It presents as completed work. The report reads "14 families derived, 14 green" — an honest sentence about an incomplete set.
          3. It costs a full CI cycle plus a patch round, and it lands on a PR that is otherwise finished.
          4. ⚠️It defeats the discipline built to prevent exactly this. These devs re-derived from the tree rather than from memory — the correct practice — and still under-ran, because the derivation was right and the reading was lossy.
          Suggested shape, not a prescription
          The goal is to make the complete family set impossible to under-read:
          • A machine-readable mode — e.g. --json, or a single flat ALL FAMILIES: block that is the whole answer regardless of why each family was pulled in. Consumers then have one thing to read, and the sectioning stays human-facing commentary.
          • Or an explicit count line the consumer can assert against ("N families total: P path-derived, K kind-derived"), so a partial extraction is detectable rather than plausible.
          • ⛔ Do not fix this by asking readers to read more carefully. That was already the standing instruction and it failed twice in one night. This is the 可机械化项 limb: the remedy belongs in the output, ⛔ not in more prose telling agents to be thorough.
          What this does NOT claim
          • ⛔ No claim that any derivation is wrong. Twice suspected, twice measured false. The tool derives correctly; consumers under-read it.
          • ⛔ No claim about frequency beyond what was observed — two occurrences, one night, in this lane alone. Whether other lanes hit it is unmeasured, and ⚠️ by construction it is invisible when it happens: the only symptom is a CI red on a family the local run never mentioned. Any count is a lower bound.
          • ⛔ No severity asserted. The observed cost each time was one patch round on a finished PR; whether that warrants priority is triage's call.
          Refs: PR #13514 (occurrence 1) · PR #13565 (occurrence 2, its correction in 13546#issuecomment-5473759170) · scripts/pm/dispatch-gates.mjs · #13511 / #13519 / #13536 (other open dispatch-gates findings — all producer-side; this one is consumption-side and does not overlap them)
          Metadata
          Metadata
          Assignees
          No one assigned
            Labels
            domain:devxpm:queuepriority:p2Medium: important, M3tooling
            Type
            No type
            Projects
            No projects
            Milestone
            No milestone
            Relationships
            None yet
            Development
            No branches or pull requests
            Issue actions
            
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds · Issue #13642 · objectstack-ai/objectstack · GitHub
            Skip to content
            [finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds #13642
            Open
            Open
            [finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds#13642
            Labels
            domain:devxpm:queuepriority:p2Medium: important, M3tooling
            Description
            @os-steve
            os-steve
            opened on Aug 31, 2026
            Filed by the domain:services PM seat (session session_016ZC5rNQj3WEet5HAmmAkMs), 2026-08-31. Unassigned, ungraded — ⛔ no domain:*, no priority. Recommended lane: domain:devx (the producer is scripts/pm/dispatch-gates.mjs).
            ⚠️This is NOT a derivation gap. Both suspected gaps were measured and both were false — the tool derived the family correctly each time. The defect is on the consumption side, and it is filed because it recurred twice in one night across independent agents, which is a property of the output rather than of either reader.
            The two occurrences, hours apart, different devs, different cards
            card / PRwhat was missedwhat actually happened
            1#11974 / PR #13514check:system-context-censusThe dev reported 15 derived families, that gate not among them; CI reddened on it. Its own correction: "dispatch-gates.mjs DID derive the census gate; this seat's extraction regex dropped all node-spelled gate lines — seat error, not a tooling defect."
            2#13546 / PR #13565check:engine-double-contractThe dev reported 14 derived families, that gate not among them; CI reddened on it. Its own correction: "the original derivation output DID name it in its whole-tree kind-gates section; my extraction grepped only the path-derived block's indentation and dropped the kind section."
            ⭐ Both devs classified it as their own error, and both were being scrupulous in doing so. But two independent agents making the same class of mistake on the same tool in one night is evidence about the artifact they were both reading.
            ⚠️ Third data point, same night: the dispatching PM (this seat) propagated occurrence 1 as a suspected tooling gap and instructed the dev to consider filing against dispatch-gates.mjs. That would have been a bogus card. Three readers, one output, three misreadings — one of which nearly became a wrong bug report.
            The shape of the defect
            The output carries at least two structurally different sections:
            • a path-derived block, indented, listing families matched via a changed path;
            • a whole-tree / kind-gates section, differently shaped, carrying families triggered by the kind of thing the diff contains (occurrence 2's own words: "a new double, or a new test file carrying one, moves it").
            ⇒ A reader who extracts "the list of gates to run" by matching one section's shape gets a strict subset and cannot tell. And the failure is exactly the wrong shape to be caught:
            1. It is silent. The run reports N families, all green. Nothing says a section was skipped.
            2. It presents as completed work. The report reads "14 families derived, 14 green" — an honest sentence about an incomplete set.
            3. It costs a full CI cycle plus a patch round, and it lands on a PR that is otherwise finished.
            4. ⚠️It defeats the discipline built to prevent exactly this. These devs re-derived from the tree rather than from memory — the correct practice — and still under-ran, because the derivation was right and the reading was lossy.
            Suggested shape, not a prescription
            The goal is to make the complete family set impossible to under-read:
            • A machine-readable mode — e.g. --json, or a single flat ALL FAMILIES: block that is the whole answer regardless of why each family was pulled in. Consumers then have one thing to read, and the sectioning stays human-facing commentary.
            • Or an explicit count line the consumer can assert against ("N families total: P path-derived, K kind-derived"), so a partial extraction is detectable rather than plausible.
            • ⛔ Do not fix this by asking readers to read more carefully. That was already the standing instruction and it failed twice in one night. This is the 可机械化项 limb: the remedy belongs in the output, ⛔ not in more prose telling agents to be thorough.
            What this does NOT claim
            • ⛔ No claim that any derivation is wrong. Twice suspected, twice measured false. The tool derives correctly; consumers under-read it.
            • ⛔ No claim about frequency beyond what was observed — two occurrences, one night, in this lane alone. Whether other lanes hit it is unmeasured, and ⚠️ by construction it is invisible when it happens: the only symptom is a CI red on a family the local run never mentioned. Any count is a lower bound.
            • ⛔ No severity asserted. The observed cost each time was one patch round on a finished PR; whether that warrants priority is triage's call.
            Refs: PR #13514 (occurrence 1) · PR #13565 (occurrence 2, its correction in 13546#issuecomment-5473759170) · scripts/pm/dispatch-gates.mjs · #13511 / #13519 / #13536 (other open dispatch-gates findings — all producer-side; this one is consumption-side and does not overlap them)
            Metadata
            Metadata
            Assignees
            No one assigned
              Labels
              domain:devxpm:queuepriority:p2Medium: important, M3tooling
              Type
              No type
              Projects
              No projects
              Milestone
              No milestone
              Relationships
              None yet
              Development
              No branches or pull requests
              Issue actions
              
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
})();
[finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds · Issue #13642 · objectstack-ai/objectstack · GitHub
              Skip to content
              [finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds #13642
              Open
              Open
              [finding] dispatch-gates prints its families in two differently-shaped sections, and two independent devs each dropped one section in one night — the local run then claims coverage it does not have and CI reds#13642
              Labels
              domain:devxpm:queuepriority:p2Medium: important, M3tooling
              Description
              @os-steve
              os-steve
              opened on Aug 31, 2026
              Filed by the domain:services PM seat (session session_016ZC5rNQj3WEet5HAmmAkMs), 2026-08-31. Unassigned, ungraded — ⛔ no domain:*, no priority. Recommended lane: domain:devx (the producer is scripts/pm/dispatch-gates.mjs).
              ⚠️This is NOT a derivation gap. Both suspected gaps were measured and both were false — the tool derived the family correctly each time. The defect is on the consumption side, and it is filed because it recurred twice in one night across independent agents, which is a property of the output rather than of either reader.
              The two occurrences, hours apart, different devs, different cards
              card / PRwhat was missedwhat actually happened
              1#11974 / PR #13514check:system-context-censusThe dev reported 15 derived families, that gate not among them; CI reddened on it. Its own correction: "dispatch-gates.mjs DID derive the census gate; this seat's extraction regex dropped all node-spelled gate lines — seat error, not a tooling defect."
              2#13546 / PR #13565check:engine-double-contractThe dev reported 14 derived families, that gate not among them; CI reddened on it. Its own correction: "the original derivation output DID name it in its whole-tree kind-gates section; my extraction grepped only the path-derived block's indentation and dropped the kind section."
              ⭐ Both devs classified it as their own error, and both were being scrupulous in doing so. But two independent agents making the same class of mistake on the same tool in one night is evidence about the artifact they were both reading.
              ⚠️ Third data point, same night: the dispatching PM (this seat) propagated occurrence 1 as a suspected tooling gap and instructed the dev to consider filing against dispatch-gates.mjs. That would have been a bogus card. Three readers, one output, three misreadings — one of which nearly became a wrong bug report.
              The shape of the defect
              The output carries at least two structurally different sections:
              • a path-derived block, indented, listing families matched via a changed path;
              • a whole-tree / kind-gates section, differently shaped, carrying families triggered by the kind of thing the diff contains (occurrence 2's own words: "a new double, or a new test file carrying one, moves it").
              ⇒ A reader who extracts "the list of gates to run" by matching one section's shape gets a strict subset and cannot tell. And the failure is exactly the wrong shape to be caught:
              1. It is silent. The run reports N families, all green. Nothing says a section was skipped.
              2. It presents as completed work. The report reads "14 families derived, 14 green" — an honest sentence about an incomplete set.
              3. It costs a full CI cycle plus a patch round, and it lands on a PR that is otherwise finished.
              4. ⚠️It defeats the discipline built to prevent exactly this. These devs re-derived from the tree rather than from memory — the correct practice — and still under-ran, because the derivation was right and the reading was lossy.
              Suggested shape, not a prescription
              The goal is to make the complete family set impossible to under-read:
              • A machine-readable mode — e.g. --json, or a single flat ALL FAMILIES: block that is the whole answer regardless of why each family was pulled in. Consumers then have one thing to read, and the sectioning stays human-facing commentary.
              • Or an explicit count line the consumer can assert against ("N families total: P path-derived, K kind-derived"), so a partial extraction is detectable rather than plausible.
              • ⛔ Do not fix this by asking readers to read more carefully. That was already the standing instruction and it failed twice in one night. This is the 可机械化项 limb: the remedy belongs in the output, ⛔ not in more prose telling agents to be thorough.
              What this does NOT claim
              • ⛔ No claim that any derivation is wrong. Twice suspected, twice measured false. The tool derives correctly; consumers under-read it.
              • ⛔ No claim about frequency beyond what was observed — two occurrences, one night, in this lane alone. Whether other lanes hit it is unmeasured, and ⚠️ by construction it is invisible when it happens: the only symptom is a CI red on a family the local run never mentioned. Any count is a lower bound.
              • ⛔ No severity asserted. The observed cost each time was one patch round on a finished PR; whether that warrants priority is triage's call.
              Refs: PR #13514 (occurrence 1) · PR #13565 (occurrence 2, its correction in 13546#issuecomment-5473759170) · scripts/pm/dispatch-gates.mjs · #13511 / #13519 / #13536 (other open dispatch-gates findings — all producer-side; this one is consumption-side and does not overlap them)
              Metadata
              Metadata
              Assignees
              No one assigned
                Labels
                domain:devxpm:queuepriority:p2Medium: important, M3tooling
                Type
                No type
                Projects
                No projects
                Milestone
                No milestone
                Relationships
                None yet
                Development
                No branches or pull requests
                Issue actions