[decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp? #14096

Open
Open
[decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp?#14096
Labels
domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3

Description

@claude
claude
bot
opened on Sep 1, 2026

Split out of #13637, whose dispatched half was editorial only: objectql's PLATFORM_NAMESPACE docblock asserted an invariant that #13491 had made false, and that docblock has been rewritten to describe reality. This card carries the half that was deliberately left out of it, because it is a decision about rows already written to disk, not a repair.

Recording only — no severity asserted, routing is triage's.

The state of the tree, measured on origin/main at dda969cd71

Three sites cut the platform namespace /^(sys_|cloud_|ai_)/. After #13491 (PR #13635) they no longer decide the same way:

sitehow it decides today
the runtime write path (Engine.resolveSystemInsertOrganization, packages/objectql/src/engine.ts)per object, via isPlatformObjectOutOfTenantAuditScope — the hand-adjudicated PLATFORM_OBJECT_TENANCY ledger in packages/objectql/src/tenancy/platform-object-tenancy.ts
packages/metadata-protocol/src/seed-loader.tsstill the namespace regexp, at its fallbackOrgId decision
packages/metadata-protocol/src/migrations/seed-tenancy-backfill.tsstill the namespace regexp (its own PLATFORM_NAMESPACE)

The divergence is deliberate: #13491's re-ruling (2026-08-31, 联案 #13497) scoped itself to the runtime control.

The question

Should the two seed paths re-cut per object as well?

Why it is a decision and not a task

Both seed paths WRITE. Changing their cut changes what future seeds and backfills stamp, and says nothing by itself about rows already on disk under the old namespace-wide reading. So an answer has to cover two populations, and the second one is existing data — the manual floor.

⚠️#13491's re-ruling execution point 3 (⛔ 永不静默改写行为) applies to every answer here, including "leave them as they are". The do-nothing answer is still a decision that has to be written down: the tree currently documents the divergence without recording that anyone chose it.

Options

A. Leave both seed paths on the namespace regexp, and record the choice. No code change; the divergence stops being an unadjudicated state and becomes a recorded decision. Cheapest, and it keeps existing rows consistent with the path that wrote them. Cost: two write paths disagree with the runtime one permanently, and every future reader re-asks this question.

B. Re-cut both seed paths per object, for FUTURE writes only. The three converge again for anything written from here on. Existing rows are left exactly as they are and are NOT re-stamped. Cost: one object can then hold rows stamped under both readings, with nothing recording which is which.

C. Re-cut, and repair existing rows. Reaches consistency on disk too. This is the option that hits the manual floor hardest — a migration over existing tenant data, unfixable after release — and #8686's own posture (already-minted duplicates are REPORTED, never rewritten) argues against it.

No recommendation is offered: choosing among these needs the maintainer's knowledge of deployed installs, which this repository cannot supply.

What this card does NOT claim

⛔ No assertion that rows the seed paths wrote are wrong. ⛔ No assertion that anything should be re-stamped. ⛔ No severity asserted. The measurement is only that the three cuts now differ, and that no card records a decision about the two that did not move.

Related

#13637 (the finding this was split out of) · #13491 / PR #13635 (where the divergence arose, deliberately) · #13636 (an adjacent gap in the same classification) · #8686 · #8672 · #8844

Generated by Claude Code

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3

    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)) { injectUserscript("// Add copy buttons to all 
       blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n 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;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

      Skip to content
      [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp? #14096
      Open
      Open
      [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp?#14096
      Labels
      domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3
      Description
      @claude
      claude
      bot
      opened on Sep 1, 2026
      Split out of #13637, whose dispatched half was editorial only: objectql's PLATFORM_NAMESPACE docblock asserted an invariant that #13491 had made false, and that docblock has been rewritten to describe reality. This card carries the half that was deliberately left out of it, because it is a decision about rows already written to disk, not a repair.
      Recording only — no severity asserted, routing is triage's.
      The state of the tree, measured on origin/main at dda969cd71
      Three sites cut the platform namespace /^(sys_|cloud_|ai_)/. After #13491 (PR #13635) they no longer decide the same way:
      sitehow it decides today
      the runtime write path (Engine.resolveSystemInsertOrganization, packages/objectql/src/engine.ts)per object, via isPlatformObjectOutOfTenantAuditScope — the hand-adjudicated PLATFORM_OBJECT_TENANCY ledger in packages/objectql/src/tenancy/platform-object-tenancy.ts
      packages/metadata-protocol/src/seed-loader.tsstill the namespace regexp, at its fallbackOrgId decision
      packages/metadata-protocol/src/migrations/seed-tenancy-backfill.tsstill the namespace regexp (its own PLATFORM_NAMESPACE)
      The divergence is deliberate: #13491's re-ruling (2026-08-31, 联案 #13497) scoped itself to the runtime control.
      The question
      Should the two seed paths re-cut per object as well?
      Why it is a decision and not a task
      Both seed paths WRITE. Changing their cut changes what future seeds and backfills stamp, and says nothing by itself about rows already on disk under the old namespace-wide reading. So an answer has to cover two populations, and the second one is existing data — the manual floor.
      ⚠️#13491's re-ruling execution point 3 (⛔ 永不静默改写行为) applies to every answer here, including "leave them as they are". The do-nothing answer is still a decision that has to be written down: the tree currently documents the divergence without recording that anyone chose it.
      Options
      A. Leave both seed paths on the namespace regexp, and record the choice. No code change; the divergence stops being an unadjudicated state and becomes a recorded decision. Cheapest, and it keeps existing rows consistent with the path that wrote them. Cost: two write paths disagree with the runtime one permanently, and every future reader re-asks this question.
      B. Re-cut both seed paths per object, for FUTURE writes only. The three converge again for anything written from here on. Existing rows are left exactly as they are and are NOT re-stamped. Cost: one object can then hold rows stamped under both readings, with nothing recording which is which.
      C. Re-cut, and repair existing rows. Reaches consistency on disk too. This is the option that hits the manual floor hardest — a migration over existing tenant data, unfixable after release — and #8686's own posture (already-minted duplicates are REPORTED, never rewritten) argues against it.
      No recommendation is offered: choosing among these needs the maintainer's knowledge of deployed installs, which this repository cannot supply.
      What this card does NOT claim
      ⛔ No assertion that rows the seed paths wrote are wrong. ⛔ No assertion that anything should be re-stamped. ⛔ No severity asserted. The measurement is only that the three cuts now differ, and that no card records a decision about the two that did not move.
      Related
      #13637 (the finding this was split out of) · #13491 / PR #13635 (where the divergence arose, deliberately) · #13636 (an adjacent gap in the same classification) · #8686 · #8672 · #8844
      Generated by Claude Code
      Metadata
      Metadata
      Assignees
      No one assigned
        Labels
        domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3
        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)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

          Skip to content
          [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp? #14096
          Open
          Open
          [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp?#14096
          Labels
          domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3
          Description
          @claude
          claude
          bot
          opened on Sep 1, 2026
          Split out of #13637, whose dispatched half was editorial only: objectql's PLATFORM_NAMESPACE docblock asserted an invariant that #13491 had made false, and that docblock has been rewritten to describe reality. This card carries the half that was deliberately left out of it, because it is a decision about rows already written to disk, not a repair.
          Recording only — no severity asserted, routing is triage's.
          The state of the tree, measured on origin/main at dda969cd71
          Three sites cut the platform namespace /^(sys_|cloud_|ai_)/. After #13491 (PR #13635) they no longer decide the same way:
          sitehow it decides today
          the runtime write path (Engine.resolveSystemInsertOrganization, packages/objectql/src/engine.ts)per object, via isPlatformObjectOutOfTenantAuditScope — the hand-adjudicated PLATFORM_OBJECT_TENANCY ledger in packages/objectql/src/tenancy/platform-object-tenancy.ts
          packages/metadata-protocol/src/seed-loader.tsstill the namespace regexp, at its fallbackOrgId decision
          packages/metadata-protocol/src/migrations/seed-tenancy-backfill.tsstill the namespace regexp (its own PLATFORM_NAMESPACE)
          The divergence is deliberate: #13491's re-ruling (2026-08-31, 联案 #13497) scoped itself to the runtime control.
          The question
          Should the two seed paths re-cut per object as well?
          Why it is a decision and not a task
          Both seed paths WRITE. Changing their cut changes what future seeds and backfills stamp, and says nothing by itself about rows already on disk under the old namespace-wide reading. So an answer has to cover two populations, and the second one is existing data — the manual floor.
          ⚠️#13491's re-ruling execution point 3 (⛔ 永不静默改写行为) applies to every answer here, including "leave them as they are". The do-nothing answer is still a decision that has to be written down: the tree currently documents the divergence without recording that anyone chose it.
          Options
          A. Leave both seed paths on the namespace regexp, and record the choice. No code change; the divergence stops being an unadjudicated state and becomes a recorded decision. Cheapest, and it keeps existing rows consistent with the path that wrote them. Cost: two write paths disagree with the runtime one permanently, and every future reader re-asks this question.
          B. Re-cut both seed paths per object, for FUTURE writes only. The three converge again for anything written from here on. Existing rows are left exactly as they are and are NOT re-stamped. Cost: one object can then hold rows stamped under both readings, with nothing recording which is which.
          C. Re-cut, and repair existing rows. Reaches consistency on disk too. This is the option that hits the manual floor hardest — a migration over existing tenant data, unfixable after release — and #8686's own posture (already-minted duplicates are REPORTED, never rewritten) argues against it.
          No recommendation is offered: choosing among these needs the maintainer's knowledge of deployed installs, which this repository cannot supply.
          What this card does NOT claim
          ⛔ No assertion that rows the seed paths wrote are wrong. ⛔ No assertion that anything should be re-stamped. ⛔ No severity asserted. The measurement is only that the three cuts now differ, and that no card records a decision about the two that did not move.
          Related
          #13637 (the finding this was split out of) · #13491 / PR #13635 (where the divergence arose, deliberately) · #13636 (an adjacent gap in the same classification) · #8686 · #8672 · #8844
          Generated by Claude Code
          Metadata
          Metadata
          Assignees
          No one assigned
            Labels
            domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3
            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)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

              Skip to content
              [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp? #14096
              Open
              Open
              [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp?#14096
              Labels
              domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3
              Description
              @claude
              claude
              bot
              opened on Sep 1, 2026
              Split out of #13637, whose dispatched half was editorial only: objectql's PLATFORM_NAMESPACE docblock asserted an invariant that #13491 had made false, and that docblock has been rewritten to describe reality. This card carries the half that was deliberately left out of it, because it is a decision about rows already written to disk, not a repair.
              Recording only — no severity asserted, routing is triage's.
              The state of the tree, measured on origin/main at dda969cd71
              Three sites cut the platform namespace /^(sys_|cloud_|ai_)/. After #13491 (PR #13635) they no longer decide the same way:
              sitehow it decides today
              the runtime write path (Engine.resolveSystemInsertOrganization, packages/objectql/src/engine.ts)per object, via isPlatformObjectOutOfTenantAuditScope — the hand-adjudicated PLATFORM_OBJECT_TENANCY ledger in packages/objectql/src/tenancy/platform-object-tenancy.ts
              packages/metadata-protocol/src/seed-loader.tsstill the namespace regexp, at its fallbackOrgId decision
              packages/metadata-protocol/src/migrations/seed-tenancy-backfill.tsstill the namespace regexp (its own PLATFORM_NAMESPACE)
              The divergence is deliberate: #13491's re-ruling (2026-08-31, 联案 #13497) scoped itself to the runtime control.
              The question
              Should the two seed paths re-cut per object as well?
              Why it is a decision and not a task
              Both seed paths WRITE. Changing their cut changes what future seeds and backfills stamp, and says nothing by itself about rows already on disk under the old namespace-wide reading. So an answer has to cover two populations, and the second one is existing data — the manual floor.
              ⚠️#13491's re-ruling execution point 3 (⛔ 永不静默改写行为) applies to every answer here, including "leave them as they are". The do-nothing answer is still a decision that has to be written down: the tree currently documents the divergence without recording that anyone chose it.
              Options
              A. Leave both seed paths on the namespace regexp, and record the choice. No code change; the divergence stops being an unadjudicated state and becomes a recorded decision. Cheapest, and it keeps existing rows consistent with the path that wrote them. Cost: two write paths disagree with the runtime one permanently, and every future reader re-asks this question.
              B. Re-cut both seed paths per object, for FUTURE writes only. The three converge again for anything written from here on. Existing rows are left exactly as they are and are NOT re-stamped. Cost: one object can then hold rows stamped under both readings, with nothing recording which is which.
              C. Re-cut, and repair existing rows. Reaches consistency on disk too. This is the option that hits the manual floor hardest — a migration over existing tenant data, unfixable after release — and #8686's own posture (already-minted duplicates are REPORTED, never rewritten) argues against it.
              No recommendation is offered: choosing among these needs the maintainer's knowledge of deployed installs, which this repository cannot supply.
              What this card does NOT claim
              ⛔ No assertion that rows the seed paths wrote are wrong. ⛔ No assertion that anything should be re-stamped. ⛔ No severity asserted. The measurement is only that the three cuts now differ, and that no card records a decision about the two that did not move.
              Related
              #13637 (the finding this was split out of) · #13491 / PR #13635 (where the divergence arose, deliberately) · #13636 (an adjacent gap in the same classification) · #8686 · #8672 · #8844
              Generated by Claude Code
              Metadata
              Metadata
              Assignees
              No one assigned
                Labels
                domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3
                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)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

                  Skip to content
                  [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp? #14096
                  Open
                  Open
                  [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp?#14096
                  Labels
                  domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3
                  Description
                  @claude
                  claude
                  bot
                  opened on Sep 1, 2026
                  Split out of #13637, whose dispatched half was editorial only: objectql's PLATFORM_NAMESPACE docblock asserted an invariant that #13491 had made false, and that docblock has been rewritten to describe reality. This card carries the half that was deliberately left out of it, because it is a decision about rows already written to disk, not a repair.
                  Recording only — no severity asserted, routing is triage's.
                  The state of the tree, measured on origin/main at dda969cd71
                  Three sites cut the platform namespace /^(sys_|cloud_|ai_)/. After #13491 (PR #13635) they no longer decide the same way:
                  sitehow it decides today
                  the runtime write path (Engine.resolveSystemInsertOrganization, packages/objectql/src/engine.ts)per object, via isPlatformObjectOutOfTenantAuditScope — the hand-adjudicated PLATFORM_OBJECT_TENANCY ledger in packages/objectql/src/tenancy/platform-object-tenancy.ts
                  packages/metadata-protocol/src/seed-loader.tsstill the namespace regexp, at its fallbackOrgId decision
                  packages/metadata-protocol/src/migrations/seed-tenancy-backfill.tsstill the namespace regexp (its own PLATFORM_NAMESPACE)
                  The divergence is deliberate: #13491's re-ruling (2026-08-31, 联案 #13497) scoped itself to the runtime control.
                  The question
                  Should the two seed paths re-cut per object as well?
                  Why it is a decision and not a task
                  Both seed paths WRITE. Changing their cut changes what future seeds and backfills stamp, and says nothing by itself about rows already on disk under the old namespace-wide reading. So an answer has to cover two populations, and the second one is existing data — the manual floor.
                  ⚠️#13491's re-ruling execution point 3 (⛔ 永不静默改写行为) applies to every answer here, including "leave them as they are". The do-nothing answer is still a decision that has to be written down: the tree currently documents the divergence without recording that anyone chose it.
                  Options
                  A. Leave both seed paths on the namespace regexp, and record the choice. No code change; the divergence stops being an unadjudicated state and becomes a recorded decision. Cheapest, and it keeps existing rows consistent with the path that wrote them. Cost: two write paths disagree with the runtime one permanently, and every future reader re-asks this question.
                  B. Re-cut both seed paths per object, for FUTURE writes only. The three converge again for anything written from here on. Existing rows are left exactly as they are and are NOT re-stamped. Cost: one object can then hold rows stamped under both readings, with nothing recording which is which.
                  C. Re-cut, and repair existing rows. Reaches consistency on disk too. This is the option that hits the manual floor hardest — a migration over existing tenant data, unfixable after release — and #8686's own posture (already-minted duplicates are REPORTED, never rewritten) argues against it.
                  No recommendation is offered: choosing among these needs the maintainer's knowledge of deployed installs, which this repository cannot supply.
                  What this card does NOT claim
                  ⛔ No assertion that rows the seed paths wrote are wrong. ⛔ No assertion that anything should be re-stamped. ⛔ No severity asserted. The measurement is only that the three cuts now differ, and that no card records a decision about the two that did not move.
                  Related
                  #13637 (the finding this was split out of) · #13491 / PR #13635 (where the divergence arose, deliberately) · #13636 (an adjacent gap in the same classification) · #8686 · #8672 · #8844
                  Generated by Claude Code
                  Metadata
                  Metadata
                  Assignees
                  No one assigned
                    Labels
                    domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3
                    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)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

                      Skip to content
                      [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp? #14096
                      Open
                      Open
                      [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp?#14096
                      Labels
                      domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3
                      Description
                      @claude
                      claude
                      bot
                      opened on Sep 1, 2026
                      Split out of #13637, whose dispatched half was editorial only: objectql's PLATFORM_NAMESPACE docblock asserted an invariant that #13491 had made false, and that docblock has been rewritten to describe reality. This card carries the half that was deliberately left out of it, because it is a decision about rows already written to disk, not a repair.
                      Recording only — no severity asserted, routing is triage's.
                      The state of the tree, measured on origin/main at dda969cd71
                      Three sites cut the platform namespace /^(sys_|cloud_|ai_)/. After #13491 (PR #13635) they no longer decide the same way:
                      sitehow it decides today
                      the runtime write path (Engine.resolveSystemInsertOrganization, packages/objectql/src/engine.ts)per object, via isPlatformObjectOutOfTenantAuditScope — the hand-adjudicated PLATFORM_OBJECT_TENANCY ledger in packages/objectql/src/tenancy/platform-object-tenancy.ts
                      packages/metadata-protocol/src/seed-loader.tsstill the namespace regexp, at its fallbackOrgId decision
                      packages/metadata-protocol/src/migrations/seed-tenancy-backfill.tsstill the namespace regexp (its own PLATFORM_NAMESPACE)
                      The divergence is deliberate: #13491's re-ruling (2026-08-31, 联案 #13497) scoped itself to the runtime control.
                      The question
                      Should the two seed paths re-cut per object as well?
                      Why it is a decision and not a task
                      Both seed paths WRITE. Changing their cut changes what future seeds and backfills stamp, and says nothing by itself about rows already on disk under the old namespace-wide reading. So an answer has to cover two populations, and the second one is existing data — the manual floor.
                      ⚠️#13491's re-ruling execution point 3 (⛔ 永不静默改写行为) applies to every answer here, including "leave them as they are". The do-nothing answer is still a decision that has to be written down: the tree currently documents the divergence without recording that anyone chose it.
                      Options
                      A. Leave both seed paths on the namespace regexp, and record the choice. No code change; the divergence stops being an unadjudicated state and becomes a recorded decision. Cheapest, and it keeps existing rows consistent with the path that wrote them. Cost: two write paths disagree with the runtime one permanently, and every future reader re-asks this question.
                      B. Re-cut both seed paths per object, for FUTURE writes only. The three converge again for anything written from here on. Existing rows are left exactly as they are and are NOT re-stamped. Cost: one object can then hold rows stamped under both readings, with nothing recording which is which.
                      C. Re-cut, and repair existing rows. Reaches consistency on disk too. This is the option that hits the manual floor hardest — a migration over existing tenant data, unfixable after release — and #8686's own posture (already-minted duplicates are REPORTED, never rewritten) argues against it.
                      No recommendation is offered: choosing among these needs the maintainer's knowledge of deployed installs, which this repository cannot supply.
                      What this card does NOT claim
                      ⛔ No assertion that rows the seed paths wrote are wrong. ⛔ No assertion that anything should be re-stamped. ⛔ No severity asserted. The measurement is only that the three cuts now differ, and that no card records a decision about the two that did not move.
                      Related
                      #13637 (the finding this was split out of) · #13491 / PR #13635 (where the divergence arose, deliberately) · #13636 (an adjacent gap in the same classification) · #8686 · #8672 · #8844
                      Generated by Claude Code
                      Metadata
                      Metadata
                      Assignees
                      No one assigned
                        Labels
                        domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3
                        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)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

                          Skip to content
                          [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp? #14096
                          Open
                          Open
                          [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp?#14096
                          Labels
                          domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3
                          Description
                          @claude
                          claude
                          bot
                          opened on Sep 1, 2026
                          Split out of #13637, whose dispatched half was editorial only: objectql's PLATFORM_NAMESPACE docblock asserted an invariant that #13491 had made false, and that docblock has been rewritten to describe reality. This card carries the half that was deliberately left out of it, because it is a decision about rows already written to disk, not a repair.
                          Recording only — no severity asserted, routing is triage's.
                          The state of the tree, measured on origin/main at dda969cd71
                          Three sites cut the platform namespace /^(sys_|cloud_|ai_)/. After #13491 (PR #13635) they no longer decide the same way:
                          sitehow it decides today
                          the runtime write path (Engine.resolveSystemInsertOrganization, packages/objectql/src/engine.ts)per object, via isPlatformObjectOutOfTenantAuditScope — the hand-adjudicated PLATFORM_OBJECT_TENANCY ledger in packages/objectql/src/tenancy/platform-object-tenancy.ts
                          packages/metadata-protocol/src/seed-loader.tsstill the namespace regexp, at its fallbackOrgId decision
                          packages/metadata-protocol/src/migrations/seed-tenancy-backfill.tsstill the namespace regexp (its own PLATFORM_NAMESPACE)
                          The divergence is deliberate: #13491's re-ruling (2026-08-31, 联案 #13497) scoped itself to the runtime control.
                          The question
                          Should the two seed paths re-cut per object as well?
                          Why it is a decision and not a task
                          Both seed paths WRITE. Changing their cut changes what future seeds and backfills stamp, and says nothing by itself about rows already on disk under the old namespace-wide reading. So an answer has to cover two populations, and the second one is existing data — the manual floor.
                          ⚠️#13491's re-ruling execution point 3 (⛔ 永不静默改写行为) applies to every answer here, including "leave them as they are". The do-nothing answer is still a decision that has to be written down: the tree currently documents the divergence without recording that anyone chose it.
                          Options
                          A. Leave both seed paths on the namespace regexp, and record the choice. No code change; the divergence stops being an unadjudicated state and becomes a recorded decision. Cheapest, and it keeps existing rows consistent with the path that wrote them. Cost: two write paths disagree with the runtime one permanently, and every future reader re-asks this question.
                          B. Re-cut both seed paths per object, for FUTURE writes only. The three converge again for anything written from here on. Existing rows are left exactly as they are and are NOT re-stamped. Cost: one object can then hold rows stamped under both readings, with nothing recording which is which.
                          C. Re-cut, and repair existing rows. Reaches consistency on disk too. This is the option that hits the manual floor hardest — a migration over existing tenant data, unfixable after release — and #8686's own posture (already-minted duplicates are REPORTED, never rewritten) argues against it.
                          No recommendation is offered: choosing among these needs the maintainer's knowledge of deployed installs, which this repository cannot supply.
                          What this card does NOT claim
                          ⛔ No assertion that rows the seed paths wrote are wrong. ⛔ No assertion that anything should be re-stamped. ⛔ No severity asserted. The measurement is only that the three cuts now differ, and that no card records a decision about the two that did not move.
                          Related
                          #13637 (the finding this was split out of) · #13491 / PR #13635 (where the divergence arose, deliberately) · #13636 (an adjacent gap in the same classification) · #8686 · #8672 · #8844
                          Generated by Claude Code
                          Metadata
                          Metadata
                          Assignees
                          No one assigned
                            Labels
                            domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3
                            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)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

                              Skip to content
                              [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp? #14096
                              Open
                              Open
                              [decision] Should the seed loader and #8686's backfill follow #13491's per-object tenancy classification, or stay on the namespace regexp?#14096
                              Labels
                              domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3
                              Description
                              @claude
                              claude
                              bot
                              opened on Sep 1, 2026
                              Split out of #13637, whose dispatched half was editorial only: objectql's PLATFORM_NAMESPACE docblock asserted an invariant that #13491 had made false, and that docblock has been rewritten to describe reality. This card carries the half that was deliberately left out of it, because it is a decision about rows already written to disk, not a repair.
                              Recording only — no severity asserted, routing is triage's.
                              The state of the tree, measured on origin/main at dda969cd71
                              Three sites cut the platform namespace /^(sys_|cloud_|ai_)/. After #13491 (PR #13635) they no longer decide the same way:
                              sitehow it decides today
                              the runtime write path (Engine.resolveSystemInsertOrganization, packages/objectql/src/engine.ts)per object, via isPlatformObjectOutOfTenantAuditScope — the hand-adjudicated PLATFORM_OBJECT_TENANCY ledger in packages/objectql/src/tenancy/platform-object-tenancy.ts
                              packages/metadata-protocol/src/seed-loader.tsstill the namespace regexp, at its fallbackOrgId decision
                              packages/metadata-protocol/src/migrations/seed-tenancy-backfill.tsstill the namespace regexp (its own PLATFORM_NAMESPACE)
                              The divergence is deliberate: #13491's re-ruling (2026-08-31, 联案 #13497) scoped itself to the runtime control.
                              The question
                              Should the two seed paths re-cut per object as well?
                              Why it is a decision and not a task
                              Both seed paths WRITE. Changing their cut changes what future seeds and backfills stamp, and says nothing by itself about rows already on disk under the old namespace-wide reading. So an answer has to cover two populations, and the second one is existing data — the manual floor.
                              ⚠️#13491's re-ruling execution point 3 (⛔ 永不静默改写行为) applies to every answer here, including "leave them as they are". The do-nothing answer is still a decision that has to be written down: the tree currently documents the divergence without recording that anyone chose it.
                              Options
                              A. Leave both seed paths on the namespace regexp, and record the choice. No code change; the divergence stops being an unadjudicated state and becomes a recorded decision. Cheapest, and it keeps existing rows consistent with the path that wrote them. Cost: two write paths disagree with the runtime one permanently, and every future reader re-asks this question.
                              B. Re-cut both seed paths per object, for FUTURE writes only. The three converge again for anything written from here on. Existing rows are left exactly as they are and are NOT re-stamped. Cost: one object can then hold rows stamped under both readings, with nothing recording which is which.
                              C. Re-cut, and repair existing rows. Reaches consistency on disk too. This is the option that hits the manual floor hardest — a migration over existing tenant data, unfixable after release — and #8686's own posture (already-minted duplicates are REPORTED, never rewritten) argues against it.
                              No recommendation is offered: choosing among these needs the maintainer's knowledge of deployed installs, which this repository cannot supply.
                              What this card does NOT claim
                              ⛔ No assertion that rows the seed paths wrote are wrong. ⛔ No assertion that anything should be re-stamped. ⛔ No severity asserted. The measurement is only that the three cuts now differ, and that no card records a decision about the two that did not move.
                              Related
                              #13637 (the finding this was split out of) · #13491 / PR #13635 (where the divergence arose, deliberately) · #13636 (an adjacent gap in the same classification) · #8686 · #8672 · #8844
                              Generated by Claude Code
                              Metadata
                              Metadata
                              Assignees
                              No one assigned
                                Labels
                                domain:enginepm:blockingpm:queuepriority:p2Medium: important, M3
                                Type
                                No type
                                Projects
                                No projects
                                  Milestone
                                  No milestone
                                  Relationships
                                  None yet
                                  Development
                                  No branches or pull requests
                                  Issue actions